JP2016218827A - セッション管理装置、セッション管理方法及びプログラム - Google Patents

Abstract

【課題】端末が行う通信のセッション情報を認証信号から収集し、迅速に外部装置に提供することが可能な技術を提供する。【解決手段】端末の認証及びセッション管理を行う認証サーバと、前記端末及び前記認証サーバの間に接続されるアクセスサーバとの間で送受信される複数種別の認証信号をキャプチャすることで、前記端末が行う通信のセッションを管理するセッション管理装置であって、前記複数種別の認証信号をキャプチャするキャプチャ手段と、キャプチャされた前記複数種別の認証信号を用いて、前記セッションを一意に特定するセッション情報を取得して管理するセッション管理手段と、前記セッション情報を所定の装置に送信する送信手段と、を有するセッション管理装置を提供する。【選択図】図９

Description

本発明は、セッション管理装置、セッション管理方法及びプログラムに関する。

所定のサービスにアクセスする端末が正規のユーザの端末であるかを確認するための認証処理に用いられるプロトコルとして、Radiusプロトコルが知られている。Radiusプロトコルは、ユーザの認証を行う機能に加え、認証されたユーザの端末にＩＰアドレスを払い出す機能、認証されたユーザの端末が行う一連の通信に関するセッション情報を管理する機能などを有している（例えば、非特許文献１及び非特許文献２参照）。

ITEF RFC2865 Remote Authentication Dial In User Service (RADIUS) IETF RFC2866 RADIUS Accounting

端末が行う通信のセッション情報を外部装置と連携させる（外部装置に流通させる）ことで、外部装置において、セッション情報を新たなサービス及び機能を提供する際の基礎データとして活用することが可能になると考えられる。

例えば、端末が行う通信のセッション情報をネットワークの帯域制御装置と連携させることで、ユーザの契約等に基づいた帯域制御機能が実現できると考えられる。また、例えば、端末が行う通信のセッション情報をプリペイド課金装置と連携させることで、ユーザに対してプリペイド課金機能を提供することができると考えられる。また、ＩＰＳｅｃ（Security Architecture for Internet Protocol）などのＶＰＮ（Virtual Private Network）を利用した通信に対する課金や、ホットスポットなどのＷｉＦｉ（登録商標）サービスを提供する際の基礎データとして活用することも考えられる。

ここで、端末が行う通信のセッション情報（ユーザ名、端末のＩＰアドレス等）を収集する方法として、Radiusサーバ又はRadiusプロキシサーバそのものをカスタマイズすることで、これらのサーバからセッション情報を外部システムに出力可能にする方法が考えられる。しかしながら、Radiusサーバ又はRadiusプロキシサーバは、認証機能という極めて重要な役割を担っているため、搭載されているソフトウェア自体をカスタマイズすることはリスクが高いという問題がある。また、Radiusサーバ又はRadiusプロキシサーバは、そもそもカスタマイズが困難なアプライアンス製品であることも多い。

別の方法として、端末が行う通信のセッション情報を収集するために、端末とRadiusサーバとの間におけるネットワーク経路上に、セッション情報を取得するための専用の装置を設置することが考えられる。しかしながら、ネットワーク経路上に新たな装置を導入する場合、導入の際にネットワークの切断を伴うことになるという問題、及びネットワーク経路上の故障個所が増えてしまうという問題がある。また、ネットワーク経路上にRadiusプロキシサーバが設置されている場合、RadiusプロキシサーバにてRadiusパケットに含まれるユーザ名が変更されることがある。そのため、ネットワーク上に新たな装置を導入したとしても、新たな装置の設置場所によっては収集できるセッション情報が限定されてしまうという問題がある。

更に別の方法として、Radiusサーバ又はRadiusプロキシサーバのログからセッション情報を収集することが考えられる。しかしながら、ログからセッション情報をリアルタイムに収集することは困難であるため、リアルタイム性が高いサービス及び機能を提供する際の基礎データには適さないという問題がある。

開示の技術は上記に鑑みてなされたものであって、端末が行う通信のセッション情報を認証信号から収集し、迅速に外部装置に提供することが可能な技術を提供することを目的とする。

開示の技術のセッション管理装置は、端末の認証及びセッション管理を行う認証サーバと、前記端末及び前記認証サーバの間に接続されるアクセスサーバとの間で送受信される複数種別の認証信号をキャプチャすることで、前記端末が行う通信のセッションを管理するセッション管理装置であって、前記複数種別の認証信号をキャプチャするキャプチャ手段と、キャプチャされた前記複数種別の認証信号を用いて、前記セッションを一意に特定するセッション情報を取得して管理するセッション管理手段と、前記セッション情報を所定の装置に送信する送信手段と、を有する。

開示の技術によれば、端末が行う通信のセッション情報を認証信号から収集し、迅速に外部装置に提供することが可能な技術が提供される。

実施の形態に係る通信ネットワークの全体構成の一例を示す図である。 実施の形態に係るセッション管理装置が収集するRadiusパケットを説明するための図である。 実施の形態に係るセッション管理装置のハードウェア構成の一例を示す図である。 実施の形態に係るセッション管理装置のソフトウェア構成の一例を示す図である。 キャッシュテーブルの一例を示す図である。 アクセスリクエストキャッシュテーブルの状態遷移を説明するための図である。 アクセス信号キャッシュテーブルの状態遷移を説明するための図である。 タイムアウト設定情報の一例を示す図である。 セッション管理装置が行うセッション管理処理の処理手順の一例を説明するためのシーケンス図である。 認証プロキシサーバの前でAccess-Requestパケットを受信した場合に行われるキャッシュテーブル操作の一例を示すフローチャートである。 認証プロキシサーバの後でAccess-Requestパケットを受信した場合に行われるキャッシュテーブル操作の一例を示すフローチャートである。 Access-Acceptパケット又はAccess-Rejectパケットを受信した場合に行われるキャッシュテーブル操作の一例を示すフローチャートである。 Accounting-Requestパケットを受信した場合に行われるキャッシュテーブル操作の一例を示すフローチャートである。

以下、図面を参照して実施の形態について説明する。各図面において、同一構成部分には同一符号を付し、重複した説明を省略する場合がある。なお、以下の説明において、セッション管理装置は、端末と認証サーバとの間で送受信されるRadiusパケットを収集して、端末が行う通信のセッション情報を管理する前提で説明するが、本実施の形態におけるセッション管理装置は、他の認証プロトコルに対しても適用することができる。

＜概要＞
（ネットワーク構成）
図１は、実施の形態に係る通信ネットワークの全体構成の一例を示す図である。実施の形態に係る通信ネットワークは、端末１と、ＮＡＳ（Network Access Server）２と、認証プロキシサーバ３と、認証サーバ４と、ＳＷ（Switch）５ａと、ＳＷ５ｂと、セッション管理装置１０と、外部装置１１とを有する。

端末１は、ユーザが所定のサービスの提供を受けるために用いる端末であり、例えば、ＰＣ（Personal Computer）、携帯端末、スマートフォン、タブレット、画像処理装置、プリンタ、スキャナ、プロジェクタ、デジタルサイネージ、又はゲーム機器などである。端末１は、通信を行う装置であればどのような装置であってもよい。所定のサービスとは、通信を用いたサービス全般を含み、例えば、ＰＰＰｏＥ（Point to Point Protocol over Ethernet（登録商標））を用いたインターネット接続サービスなどである。端末１は、ＮＡＳ２にアクセスすることで所定のサービスの提供を受けることができる。

ＮＡＳ２は、端末１に所定のサービスを提供するシステムの入り口に設置されるサーバである。ＮＡＳ２は、例えば、端末１からＰＰＰ（Point to Point Protocol）接続を受け付けるサーバである。ＮＡＳ２は、端末１からのアクセスを受け付けると、認証サーバ４に対してRadiusパケットを送信することで認証処理を開始する。また、ＮＡＳ２は、認証サーバ４から正しく認証されたことを示すRadiusパケットを受信すると、端末１に対して所定のサービスの提供を開始すると共に、端末１が行う通信のセッションが開始されたこと及びセッションが終了したことを示すRadiusパケットを認証サーバ４に送信する。

認証プロキシサーバ３は、例えば、Radius Proxyサーバであり、ＮＡＳ２から認証サーバ４に送信されるRadiusパケットを中継するサーバである。また、認証プロキシサーバ３は、複数の認証サーバ４に接続され、Radiusパケットに含まれるユーザ名の一部であるドメイン名に基づいてRadiusパケットを適切な認証サーバ４に振り分ける役割を有する。なお、認証プロキシサーバ３は、Radiusパケットを認証サーバ４に送信する際、ユーザ名の一部であるドメイン名を削除して認証サーバ４に送信する場合がある。また、認証プロキシサーバ３は、ＮＡＳ２から送信されるRadiusパケットが不正なパケットである場合に、当該Radiusパケットを破棄する。不正なパケットとは、例えば、攻撃パケット、適切な認証サーバが存在しないRadiusパケットである。

認証サーバ４は、例えば、Radiusサーバであり、Radiusパケットにより認証を行う機能を有する。また、認証サーバ４は、端末１が用いるＩＰアドレスを払い出す機能、及び、端末が行う通信のセッション情報を管理する機能などを有する。

ＳＷ５ａは、ＮＡＳ２と認証プロキシサーバ３との間のネットワーク経路上に設置されているスイッチである。ＳＷ５ａは、例えば、レイヤ２スイッチ、レイヤ３スイッチ、又はルータ、仮想スイッチ等である。ＳＷ５ａはミラーポートを有しており、ＮＡＳ２と認証プロキシサーバ３との間のネットワーク経路上を流れるパケットをミラーポートからそのまま出力する機能を有する。

ＳＷ５ｂは、認証プロキシサーバ３と認証サーバ４との間のネットワーク経路上に設置されているスイッチである。ＳＷ５ｂは、例えば、レイヤ２スイッチ、レイヤ３スイッチ、又はルータ、仮想スイッチ等である。ＳＷ５ｂはミラーポートを有しており、認証プロキシサーバ３と認証サーバ４との間のネットワーク経路上を流れるパケットをミラーポートからそのまま出力する機能を有する。

セッション管理装置１０は、ＳＷ５ａ及びＳＷ５ｂのミラーポートに接続されており、ＮＡＳ２と認証プロキシサーバ３との間のネットワーク経路上を流れるRadiusパケット、及び、認証プロキシサーバ３と認証サーバ４との間のネットワーク経路上を流れるRadiusパケットをキャプチャし、キャプチャしたRadiusパケットから端末１が行う通信のセッション情報を取得して管理する。また、セッション管理装置１０は、取得したセッション情報を外部装置１１に送信する機能を有する。

ここで、セッション管理装置１０が管理するセッション情報とは、端末１が行う通信のセッションを一意に特定するための情報であり、例えば、端末１のユーザ名、端末１のＩＰアドレス、ＮＡＳ２のＩＰアドレス等である。

外部装置１１は、セッション管理装置１０と接続されており、セッション管理装置１０から通知されたセッション情報を用いて任意のサービス及び機能を提供する装置である。本実施の形態において、外部装置１１が提供する任意のサービス及び機能は特に限定されないが、例えば、帯域制御機能、プリペイド課金機能等があげられる。

（Radiusパケット）
図２は、実施の形態に係るセッション管理装置が収集するRadiusパケットを説明するための図である。

セッション管理装置１０は、ＮＡＳ２から認証サーバ４に送信されるAccess-Requestパケット、認証サーバ４からＮＡＳ２に送信されるAccess-Acceptパケット及びAccess-Rejectパケット、及びＮＡＳ２から認証サーバ４に送信されるAccounting-Requestパケットを収集する。

これらのRadiusパケットには、種別コードが割り振られている。種別コードは、Radiusパケットの種類を一意に識別するためのコードであり、ＲＦＣ（Request For Comments）により規定されているコードである。Access-Requestパケット、Access-Acceptパケット、Access-Rejectパケット、及び、Accounting-Requestパケットの種別コードは、それぞれ、１、２、３及び４である。

Radiusパケットには、図２に示すように複数の属性（Attribute）が含まれている。図２において「○」が付与されている箇所は、各種Radiusパケットに含まれる（又は含まれる可能性のある）属性を示している。

「User-Name」には、端末１のユーザ名が設定される。端末１のユーザ名には、例えば、「User1@example.com」といったように、ユーザ名部分（User1）及びドメイン名（@example.com）が含まれている。「NAS-IP-Address」には、ＮＡＳ２のＩＰアドレスが設定される。

「Framed-IP-Address」には、端末１に払い出されるＩＰアドレスが設定される。ここで、「Framed-IP-Address」に所定のＩＰアドレス（２５５．２５５．２５５．２５４）が設定されている場合、端末１に払い出されるＩＰアドレスを、認証サーバ４の代わりにＮＡＳ２が払い出すことを意味する。なお、以下の説明において、端末１に払い出されるＩＰアドレスを認証サーバ４の代わりにＮＡＳ２が払い出すことを、便宜上「動的ＩＰアドレス払い出し」と呼ぶことがある。

「Framed-IP-Netmask」には、端末１に払い出されるＩＰアドレスのサブネットマスクが設定される。ここで、「Framed-IP-Netmask」に２５５．２５５．２５５．２５５（又は／３２）以外のサブネットマスクが設定されている場合、端末１に対して、複数のＩＰアドレスが払い出される（使用が許可される）ことを意味する。例えば、「Framed-IP-Address」に１９２．１６８．２．０が設定され、かつ「Framed-IP-Netmask」に２５５．２５５．２５５．２４８（又は／２９）が設定されている場合、端末１に対して、ネットワークアドレス（１９２．１６８．２．０）及びブロードキャストアドレス（１９２．１６８．２．７）を除いた１９２．１６８．２．１〜１９２．１６８．２．６までのＩＰアドレスが払い出されることを意味する。なお、以下の説明において、端末１に対して複数のＩＰアドレスが払い出されることを、便宜上「複数固定ＩＰアドレス払い出し」と呼ぶことがある。

「Framed-IP-Netmask」に２５５．２５５．２５５．２５５（又は／３２）のサブネットマスクが設定されている場合、端末１には、「Framed-IP-Address」に設定される１つのＩＰアドレスが払い出されることを意味する。なお、以下の説明において、端末１に１つのＩＰアドレスが払い出されることを、便宜上「固定ＩＰアドレス払い出し」と呼ぶことがある。

「Proxy-State」は、認証プロキシサーバ３を通過したAccess-Requestパケット及びその応答であるAccess-Acceptパケット又はAccess-Rejectパケットに設定される属性であり、認証プロキシサーバ３が付与する。Access-Requestパケット及びその応答であるAccess-Acceptパケット又はAccess-Rejectパケットに同一の値又は文字列が設定される。また、認証プロキシサーバ３は、Access-Acceptパケット又はAccess-RejectパケットをＮＡＳ２に転送する場合、自身が設定した「Proxy-State」属性を削除する。

「Acct-Status-Type」は、Accounting-Requestパケットが、セッションの開始（サービスの開始）を意味するのか、セッションの終了（サービスの終了）を意味するのかを示す属性である。「Acct-Status-Type」に１が設定されている場合、Accounting-Requestパケットはセッションの開始（サービスの開始）を意味し、「Acct-Status-Type」に２が設定されている場合、Accounting-Requestパケットはセッションの終了（サービスの終了）を意味する。なお、以下の説明において、「Acct-Status-Type」に１が設定されているAccounting-Requestパケットを「Accounting-Request(start)パケット」と呼び、「Acct-Status-Type」に２が設定されているAccounting-Requestパケットを「Accounting-Request(stop)パケット」と呼ぶことがある。

「Acct-Session-Id」は、Accounting-Request(start)パケットと、Accounting-Request(stop)パケットとを対応づけるために用いられるＩＤである。なお、「Acct-Session-Id」をAccess-Requestパケットに含めることもできる。

上記の各属性には、各属性を一意に識別するための属性番号が振られている。属性番号はＲＦＣにより規定されている。「User-Name」、「NAS-IP-Address」、「Framed-IP-Address」、「Framed-IP-Netmask」、「Proxy-State」、「Acct-Status-Type」、及び「Acct-Session-Id」の属性番号は、それぞれ、１、４、８、９、３３、４０及び４４である。

（動作概要）
セッション管理装置１０は、ＮＡＳ２から認証サーバ４に送信されるAccess-Requestパケット、認証サーバ４からＮＡＳ２に送信されるAccess-Acceptパケット及びAccess-Rejectパケット、及びＮＡＳ２から認証サーバ４に送信されるAccounting-Requestパケットをキャプチャし、キャプチャしたパケットに含まれる各属性の設定値を順次キャッシュテーブルに格納する。

続いて、セッション管理装置１０は、キャッシュテーブルを用いて端末１及び認証サーバ４の間におけるRadiusパケットの送受信状態を把握する。また、セッション管理装置１０は、Radiusパケットの送受信状態及び属性の設定値が所定の条件を満たす場合に、端末１が行う通信のセッション情報を外部装置１１に送信する。

＜ハードウェア構成＞
図３は、実施の形態に係るセッション管理装置のハードウェア構成の一例を示す図である。実施の形態に係るセッション管理装置１０は、ＣＰＵ１０１と、ＲＯＭ１０２と、ＲＡＭ１０３と、ＨＤＤ１０４と、操作部１０５と、表示部１０６と、ドライブ装置１０７と、ＮＩＣ（Network Interface card）１０８とを有する。

ＣＰＵ１０１は、セッション管理装置１０の全体制御を行うプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０４等に記憶されたオペレーティングシステム、アプリケーション、各種サービス等のプログラムを実行し、セッション管理装置１０の各種機能を実現する。ＲＯＭ１０２には、各種のプログラムやプログラムによって利用されるデータ等が記憶される。ＲＡＭ１０３は、プログラムをロードするための記憶領域や、ロードされたプログラムのワーク領域等として用いられる。また、ＲＡＭ１０３は、匿名化処理を行う際に用いるインメモリデータベースを保持する。ＨＤＤ１０４には、各種情報及びプログラム等が記憶される。

操作部１０５は、ユーザからの入力操作を受け付けるためのハードウェアであり、例えばキーボード又はマウスである。表示部１０６は、利用者に向けた表示を行うハードウェアである。

ドライブ装置１０７は、プログラムを記録した記憶媒体１０９からプログラムを読み取る。ドライブ装置１０７によって読み取られたプログラムは、例えば、ＨＤＤ１０４にインストールされる。ＮＩＣ１０８は、セッション管理装置１０をネットワークに接続し、データの送受信を行うための通信インタフェースである。

なお、記憶媒体１０９とは、非一時的（non-transitory）な記憶媒体を言う。記憶媒体１０９の例としては、磁気記憶媒体、光ディスク、光磁気記憶媒体、不揮発性メモリなどがある。

＜ソフトウェア構成＞
図４は、実施の形態に係るセッション管理装置のソフトウェア構成の一例を示す図である。セッション管理装置１０は、キャプチャ部２０１と、セッション管理部２０２と、一時記憶部２０３と、記憶部２０４と、セッション情報通知部２０５と、信号送信部２０６とを有する。また、セッション管理部２０２は、アクセスリクエスト処理部２１１と、アクセス信号処理部２１２と、アカウンティング信号処理部２１３とを有する。

これら各手段は、セッション管理装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０１に実行させる処理により実現され得る。また、セッション管理装置１０は、一時記憶部２０３を利用する。一時記憶部２０３は、例えばインメモリデータベースであり、ＲＡＭ１０３を用いて実現可能である。また、セッション管理装置１０は、記憶部２０４を利用する。記憶部２０４は、ＲＯＭ１０２、ＲＡＭ１０３、ＨＤＤ１０４又はセッション管理装置１０にネットワークを介して接続される記憶装置等を用いて実現可能である。

キャプチャ部２０１は、ＳＷ５ａ及びＳＷ５ｂから送信されるＩＰパケットのうち、ＵＤＰパケット、ＩＰヘッダの送信元アドレス又は宛先アドレスが認証プロキシサーバのＩＰアドレスであるパケット、ＵＤＰヘッダの宛先ポート番号が１６４５、１６４６、１８１２及び１８１３のうちいずれかであるパケット、Radiusヘッダの種別コードが１、２、３及び４のいずれかであるパケットを収集する機能を有する。また、キャプチャ部２０１は、これらの条件のうち一部の条件を満たさないパケット（ＴＣＰパケットなど）は収集せずに破棄する。また、キャプチャ部２０１は、キャプチャしたＩＰパケットが、ＳＷ５ａから送信されたＩＰパケットなのか、又は、ＳＷ５ｂから送信されたＩＰパケットなのかを認識する機能を有する。

セッション管理部２０２は、キャプチャ部で収集されたRadiusパケットに含まれる属性の設定値を、各Radiusパケットに対応するキャッシュテーブルに格納すると共に、キャッシュテーブルを用いて、端末１及び認証サーバ４の間におけるRadiusパケットの送受信状態を把握する。また、セッション管理部２０２は、記憶部２０４に記憶されているタイムアウト設定情報に基づいて、キャッシュテーブルに格納されている各レコードの有効期間を確認し、各レコードの有効期間が、タイムアウト設定情報に設定されている有効期間を超えている場合は、当該レコードをキャッシュテーブルから削除する。

一時記憶部２０３には、アクセスリクエストキャッシュテーブル、アクセス信号キャッシュテーブル、及びアカウンティング信号キャッシュテーブルが格納される。ここで、図５〜図７を用いて、アクセスリクエストキャッシュテーブル、アクセス信号キャッシュテーブル、アカウンティング信号キャッシュテーブルの具体例について説明する。

図５は、キャッシュテーブルの一例を示す図である。まず、アクセスリクエストキャッシュテーブルの具体例について説明する。図５（ａ）は、アクセスリクエストキャッシュテーブルの一例を示している。図５（ａ）に示すように、アクセスリクエストキャッシュテーブルは、「管理ＩＤ」カラムと、「状態」カラムと、「User-Name」カラムと、「NAS-IP-Address」カラムと、「Proxy-State」カラムと、「Acct-Session-Id」カラムと、「生成日時」カラムとを有する。

「管理ＩＤ」カラムには、アクセスリクエストキャッシュテーブルの各レコードを一意に識別するためのＩＤが格納される。「状態」カラムには、キャプチャされたAccess-Requestパケットの状態遷移を管理する情報が格納される。「User-Name」カラム、「NAS-IP-Address」カラム、「Proxy-State」カラム、及び「Acct-Session-Id」カラムには、キャプチャされたAccess-Requestパケットに含まれる各属性の設定値が格納される。「生成日時」カラムには、レコードが生成された日時が格納される。

アクセスリクエストキャッシュテーブルは、認証プロキシサーバ３を通過したAccess-Requestパケットのうち、認証プロキシサーバ３を通過する前のAccess-Requestパケットに含まれる「User-Name」属性を取得するために用いられる。また、アクセスリクエストキャッシュテーブルは、何らかの理由でAccess-Requestパケットが再送された場合に、再送されたAccess-Requestパケットが重複して処理されないようにするためにも用いられる。

前述の通り、認証プロキシサーバ３は、Access-Requestパケットの「User-Name」属性に設定されているユーザ名のうち、ドメイン名の部分を削除してしまうことがある。具体的には、例えば、「User-Name」属性に設定されているユーザ名が「User1@example.com」である場合、認証プロキシサーバ３は、「User-Name」属性に設定されているユーザ名を、「User1」に書き換えてしまうことがある。従って、セッション管理装置１０は、認証プロキシサーバ３の前後でAccess-RequestパケットをキャプチャすることでAccess-Requestパケットが認証プロキシサーバ３を通過したことを確認すると共に、認証プロキシサーバ３を通過する前のAccess-Requestパケットに含まれる「User-Name」属性からドメイン名を含むユーザ名を取得するようにしている。

図６は、アクセスリクエストキャッシュテーブルの状態遷移を説明するための図である。図６を用いて、アクセスリクエストキャッシュテーブルの「状態」カラムに格納される状態遷移を管理する情報について具体的に説明する。

「Ａ−Ｓ０」は、Access-Requestパケットを受信する前の初期状態を示している。なお、「Ａ−Ｓ０」は初期状態であるため、アクセスリクエストキャッシュテーブルの「状態」カラムに「Ａ−Ｓ０」が設定されることはない。

続いて、認証プロキシサーバ３の前に設置されているＳＷ５ａから送信されたAccess-Requestパケットがキャプチャされた場合、「Ａ−Ｓ０」の状態は「Ａ−Ｓ１」に遷移する。この状態で、認証プロキシサーバ３の後に設置されているＳＷ５ｂで、認証プロキシサーバ３を通過したAccess-Requestパケットがキャプチャされた場合、「Ａ−Ｓ１」の状態は「Ａ−Ｓ３」に遷移する。

一方、何らかの理由で受信パケットの逆転が発生し、認証プロキシサーバ３の後に設置されているＳＷ５ｂから送信されたAccess-Requestパケットが最初にキャプチャされた場合、「Ａ−Ｓ０」の状態は「Ａ−Ｓ２」に遷移する。この状態で、認証プロキシサーバ３の前に設置されているＳＷ５ａから送信されたAccess-Requestパケットを受信した場合、「Ａ−Ｓ２」の状態は「Ａ−Ｓ３」に遷移する。

続いて、「Ａ−Ｓ１」、「Ａ−Ｓ２」及び「Ａ−Ｓ３」の状態が継続し、有効期間が経過した場合（タイムアウトした場合）、これらの状態は「Ａ−Ｓ０」に戻る。「Ａ−Ｓ１」の状態が継続して有効期間が経過する場合とは、例えば、Access-Requestパケットが不正なパケット等であり、当該Access-Requestパケットが認証プロキシサーバ３で破棄された等の場合が想定される。「Ａ−Ｓ２」の状態が継続して有効期間が経過する場合とは、例えば、何かしらの理由により、ＳＷ５ａでミラーリングされたAccess-Requestパケットが欠損してセッション管理装置１０でキャプチャされなかった場合等が想定される。

次に、アクセス信号キャッシュテーブルの具体例について説明する。図５（ｂ）は、アクセス信号キャッシュテーブルの一例を示している。図５（ｂ）に示すように、アクセス信号キャッシュテーブルは、「管理ＩＤ」カラムと、「状態」カラムと、「User-Name」カラムと、「NAS-IP-Address」カラムと、「Framed-IP-Address」カラムと、「Framed-IP-Netmask」カラムと、「Proxy-State」カラムと、「Acct-Session-Id」カラムと、「生成日時」カラムとを有する。

「管理ＩＤ」カラムには、アクセス信号キャッシュテーブルの各レコードを一意に識別するためのＩＤが格納される。「状態」カラムには、キャプチャされたAccess-Requestパケット、Access-Acceptパケット又はAccess-Rejectパケットの全体の状態遷移を管理する情報が格納される。「User-Name」カラム、「NAS-IP-Address」カラム、「Framed-IP-Address」カラム、「Framed-IP-Netmask」カラム、「Proxy-State」カラム、及び「Acct-Session-Id」カラムには、Access-Requestパケット及びAccess-Acceptパケットに含まれる各属性の設定値が格納される。「生成日時」カラムには、レコードが生成された日時が格納される。

アクセス信号キャッシュテーブルは、複数固定ＩＰアドレス払い出しにより払い出された端末１のＩＰアドレスを取得するために用いられる。また、アクセス信号キャッシュテーブルは、何らかの理由でAccess-Requestパケット、Access-Acceptパケット、又はAccess-Rejectパケットが再送された場合に、再送されたパケットが重複して処理されないようにするためにも用いられる。

セッション管理装置１０は、アクセス信号キャッシュテーブルを用いて、Access-Requestパケットに対応するAccess-Acceptパケットが認証サーバ４から送信されたことを認識する。また、セッション管理装置１０は、「Framed-IP-Netmask」属性に２５５．２５５．２５５．２５５（又は／３２）以外が設定されている場合、端末１に対して複数固定ＩＰアドレス払い出しが行われていると認識する。

図７は、アクセス信号キャッシュテーブルの状態遷移を説明するための図である。図７を用いて、アクセス信号キャッシュテーブルの「状態」カラムに格納される状態遷移を管理する情報について具体的に説明する。

「Ｂ−Ｓ０」はアクセス信号キャッシュテーブルの状態遷移の初期状態を示している。なお、「Ｂ−Ｓ０」は初期状態であるため、アクセス信号キャッシュテーブルの「状態」カラムに「Ｂ−Ｓ０」が設定されることはない。

続いて、Access-Requestパケットが認証プロキシサーバ３を通過したことが検出された場合、「Ｂ−Ｓ０」の状態は「Ｂ−Ｓ１」に遷移する。この状態で、当該Access-Requestパケットに対応するAccess-Acceptパケットがキャプチャされた場合、「Ｂ−Ｓ１」の状態は「Ｂ−Ｓ３」に遷移し、当該Access-Acceptパケットに対応するAccess-Rejectパケットがキャプチャされた場合、「Ｂ−Ｓ１」の状態は「Ｂ−Ｓ４」に遷移する。

一方、何らかの理由で受信パケットの逆転が発生し、Access-Requestパケットが認証プロキシサーバ３を通過したことが検出される前に、Access-Acceptパケットがキャプチャされた場合、「Ｂ−Ｓ０」の状態は「Ｂ−Ｓ２」に遷移する。この状態で、Access-Requestパケットが認証プロキシサーバ３を通過したことが検出された場合、「Ｂ−Ｓ２」の状態は「Ｂ−Ｓ３」に遷移する。また、何らかの理由で受信パケットの逆転が発生し、Access-Requestパケットが認証プロキシサーバ３を通過したことが検出される前に、Access-Rejectパケットを受信した場合、「Ｂ−Ｓ０」の状態は「Ｂ−Ｓ４」に遷移する。

続いて、「Ｂ−Ｓ１」、「Ｂ−Ｓ２」、「Ｂ−Ｓ３」及び「Ｂ−Ｓ４」の状態が継続し、有効期間が経過した場合（タイムアウトした場合）、これらの状態は「Ｂ−Ｓ０」に戻る。「Ｂ−Ｓ１」の状態が継続して有効期間が経過する場合とは、例えば、何かしらの理由により、Access-Acceptパケット又はAccess-Rejectパケットが認証サーバ４から送信されていない場合等が想定される。「Ａ−Ｓ２」の状態が継続して有効期間が経過する場合とは、何かしらの理由によりAccess-Requestパケットが認証プロキシサーバ３を通過したことが検出されなかった場合等が想定される。

次に、アカウンティング信号キャッシュテーブルの具体例について説明する。図５（ｃ）は、アカウンティング信号キャッシュテーブルの一例を示している。図５（ｃ）に示すように、アカウンティング信号キャッシュテーブルは、「管理ＩＤ」カラムと、「User-Name」カラムと、「NAS-IP-Address」カラムと、「Framed-IP-Address」カラムと、「Acct-Status-Type」カラムと、「Acct-Session-Id」カラムと、「生成日時」カラムとを有する。

「User-Name」カラム、「NAS-IP-Address」カラム、「Framed-IP-Address」カラム、「Acct-Status-Type」カラム、及び「Acct-Session-Id」カラムには、Accounting-Requestパケットに含まれる各属性の設定値が格納される。「生成日時」カラムには、レコードが生成された日時が格納される。

アカウンティング信号キャッシュテーブルは、何らかの理由でAccounting-Requestパケットが再送された場合に、再送されたパケットが重複して処理されないようにするために用いられる。

図４に戻り説明を続ける。記憶部２０４にはタイムアウト設定情報が格納される。タイムアウト設定情報は、アクセスリクエストキャッシュテーブル、アクセス信号キャッシュテーブル及びアカウンティング信号キャッシュテーブルに格納される各レコードの有効期間を設定するための情報である。

図８は、タイムアウト設定情報の一例を示す図である。タイムアウト設定情報は、「キャッシュテーブル名」カラムと、「状態」カラムと、「有効期間」カラムとを有する。「キャッシュテーブル名」カラムには、該当するキャッシュテーブルの名称が格納される。「状態」カラムには、アクセスリクエストキャッシュテーブル及びアクセス信号キャッシュテーブルにおける各状態が格納される。「有効期間」カラムには、各状態の各々に対応づけられた有効期間、及びアカウンティング信号キャッシュテーブルに対応づけられた有効期間が格納される。例えば、図８に示すように、状態が「Ａ−Ｓ１」に対応する有効期間には「３ｓｅｃ」が設定されている。これは、アクセスリクエストキャッシュテーブルのレコードのうち、「状態」カラムに「Ａ−Ｓ１」が設定されているレコードの有効期間は３秒であることを示している。すなわち、「状態」カラムに「Ａ−Ｓ１」が設定されているレコードは、３秒経過すると削除されることになる。なお、図８に示す有効期間はあくまで一例であり、他の値が設定されていてもよい。

セッション情報通知部２０５は、セッション管理部２０２の指示により、端末１が行う通信のセッション情報を、信号送信部２０６を介して外部装置１１に通知する。

信号送信部２０６は、外部装置１１との間で規定されたプロトコルに従って各種信号を送信する。

＜処理手順＞
図９は、セッション管理装置が行うセッション管理処理の処理手順の一例を説明するためのシーケンス図である。図９を用いて、ネットワーク上を流れるRadiusパケットの具体例を説明すると共に、セッション管理装置１０がネットワーク上で送受信されるRadiusパケットをキャプチャし、キャプチャしたRadiusパケットに従ってセッション情報を外部装置１１に通知するまでの一連の処理手順を具体的に説明する。

ステップＳ３０１で、端末１からのアクセスを受け付けたＮＡＳ２は、Access-RequestパケットをＳＷ５ａに送信する。

ステップＳ３０２で、ＳＷ５ａのミラーポートから、Access-Requestパケットがセッション管理装置１０に送信される。

ステップＳ３０３で、セッション管理装置１０のキャプチャ部２０１は、認証プロキシサーバ３の前でAccess-Requestパケットをキャプチャしたことをセッション管理部２０２に通知する。続いて、セッション管理部２０２は、キャプチャされたAccess-Requestパケットに含まれる各属性の設定値をキャッシュテーブルに格納する処理を行う。ここで、ステップＳ３０３でセッション管理部２０２が行う処理手順の詳細を説明する。

図１０は、認証プロキシサーバの前でAccess-Requestパケットを受信した場合に行われるキャッシュテーブル操作の一例を示すフローチャートである。

ステップＳ４０１で、セッション管理部２０２は、キャプチャされたAccess-Requestパケットに含まれる各属性のうち、「NAS-IP-Address」及び「Acct-Session-Id」の設定値と同一の値を有するレコードがアクセスリクエストキャッシュテーブルに格納されているか否かを確認する。同一の値を有するレコードが格納されていない場合、ステップＳ４０２の処理手順に進み、同一の値を有するレコードが既に格納されている場合、ステップＳ４０３の処理手順に進む。

なお、セッション管理部２０２は、ステップＳ４０１の処理手順を行う前に、キャプチャされたAccess-Requestパケットに含まれる全ての属性の設定値と同一の値を有するレコードがアクセスリクエストキャッシュテーブルに既に格納されているか否かを確認し、全ての属性の設定値と同一の値を有するレコード格納されている場合、Access-Requestパケットが再送されたと判断して処理を終了するようにしてもよい。

ステップＳ４０２で、セッション管理部２０２は、アクセスリクエストキャッシュテーブルに新たなレコードを追加し、キャプチャされたAccess-Requestパケットに含まれる各属性（「User-Name」、「NAS-IP-Address」、「Proxy-State」、「Acct-Session-Id」）の設定値を新たなレコードに格納する。また、セッション管理部２０２は、新たなレコードの「生成日時」カラムに生成日時を設定すると共に、「状態」カラムに「Ａ−Ｓ１」を設定して処理を終了する。

ステップＳ４０３の処理手順は、何らかの理由で受信パケットの逆転が発生し、既に認証プロキシサーバ３の後に設置されているＳＷ５ｂを通過したAccess-Requestパケットがキャプチャされていた場合に行われることになる処理手順である。ステップＳ４０３で、セッション管理部２０２は、「NAS-IP-Address」及び「Acct-Session-Id」の設定値と同一の値を有するレコードの「User-Name」カラムを、キャプチャされたAccess-Requestパケットに含まれる「User-Name」属性の設定値に更新する。この更新処理により、認証プロキシサーバ３によりドメイン名が削除されている場合であっても、当該レコードの「User-Name」カラムに設定されているユーザ名を、ドメイン名を含むユーザ名に更新することができる。

ステップＳ４０４乃至ステップＳ４０７の処理手順は、何らかの理由で受信パケットの逆転が発生し、既にAccess-Acceptパケットがキャプチャされていた場合に行われる処理手順である。ステップＳ４０４及びステップＳ４０５の処理手順は、後述する図１１のステップＳ５０４及びステップＳ５０５の処理手順と同一であるため、説明は省略する。また、ステップＳ４０６及びステップＳ４０７の処理手順は、後述する図１２のステップＳ６０５及びステップＳ６０６の処理手順と同一であるため説明は省略する。図９に戻り説明を続ける。

ステップＳ３０４で、ＳＷ５ａはAccess-Requestパケットを認証プロキシサーバ３に送信する。

ステップＳ３０５で、認証プロキシサーバ３は、Access-RequestパケットをＳＷ５ｂに送信する。

ステップＳ３０６で、ＳＷ５ｂのミラーポートから、Access-Requestパケットがセッション管理装置１０に送信される。

ステップＳ３０７で、セッション管理装置１０のキャプチャ部２０１は、認証プロキシサーバ３の後でAccess-Requestパケットをキャプチャしたことをセッション管理部２０２に通知する。セッション管理部２０２は、アクセスリクエストキャッシュテーブルに格納されているレコードの「状態」カラムを更新する処理を行う。ここで、ステップＳ３０７でセッション管理部２０２が行う処理手順の詳細を説明する。

図１１は、認証プロキシサーバの後でAccess-Requestパケットを受信した場合に行われるキャッシュテーブル操作の一例を示すフローチャートである。

ステップＳ５０１で、セッション管理部２０２は、キャプチャされたAccess-Requestパケットに含まれる各属性のうち、「NAS-IP-Address」及び「Acct-Session-Id」の設定値と同一の値を有するレコードがアクセスリクエストキャッシュテーブルに格納されているか否かを確認する。同一の値を有するレコードが既に格納されている場合、ステップＳ５０３の処理手順に進み、同一の値を有するレコードが格納されていない場合、ステップＳ５０２の処理手順に進む。

なお、セッション管理部２０２は、ステップＳ５０１の処理手順を行う前に、キャプチャされたAccess-Requestパケットに含まれる全ての属性の設定値と同一の値を有するレコードがアクセスリクエストキャッシュテーブルに既に格納されているか否かを確認し、全ての属性の設定値と同一の値を有するレコード格納されている場合、Access-Requestパケットが再送されたと判断して処理を終了するようにしてもよい。

ステップＳ５０２の処理手順は、何らかの理由で受信パケットの逆転が発生し、認証プロキシサーバ３の前に設置されているＳＷ５ａを通過したAccess-Requestパケットがキャプチャされていない場合に行われることになる。ステップＳ５０２で、セッション管理部２０２は、アクセスリクエストキャッシュテーブルに新たなレコードを追加し、キャプチャされたAccess-Requestパケットに含まれる各属性（「User-Name」、「NAS-IP-Address」、「Proxy-State」、「Acct-Session-Id」）の設定値を新たなレコードに格納する。また、セッション管理部２０２は、新たなレコードの「生成日時」カラムに生成日時を設定すると共に、「状態」カラムに「Ａ−Ｓ２」を設定して処理を終了する。

ステップＳ５０３で、セッション管理部２０２は、「NAS-IP-Address」及び「Acct-Session-Id」の設定値と同一の値を有するレコードの「状態」カラムを「Ａ−Ｓ３」に更新する。なお、ステップＳ５０３の処理手順では、ステップＳ４０３の処理手順ように、当該レコードの「User-Name」カラムの更新処理は行われない。認証プロキシサーバ３によりドメイン名が削除されている場合、ドメイン名が削除されたユーザ名に更新されてしまうことを防止するためである。

ステップＳ５０４で、セッション管理部２０２は、認証プロキシサーバの後でキャプチャされたAccess-Requestパケットに含まれる「Proxy-State」の設定値と同一の値を有するレコードがアクセス信号キャッシュテーブルに格納されているか否かを確認する。同一の値を有するレコードが既に格納されている場合、ステップＳ５０６の処理手順に進み、同一の値を有するレコードが格納されていない場合、ステップＳ５０５の処理手順に進む。

ステップＳ５０５で、セッション管理部２０２は、アクセス信号キャッシュテーブルに新たなレコードを追加する。また、セッション管理部２０２は、ステップＳ５０３の処理手順で「状態」カラムを「Ａ−Ｓ３」に更新したアクセスリクエストキャッシュテーブルのレコードの各カラムのうち、「状態」カラム以外の各カラム（すなわち、「User-Name」、「NAS-IP-Address」、「Proxy-State」、「Acct-Session-Id」、「受信日時」）の設定値を当該新たなレコードにコピーする。また、セッション管理部２０２は、新たなレコードの「生成日時」カラムに生成日時を設定すると共に、「状態」カラムに「Ｂ−Ｓ１」を設定して処理を終了する。

ステップＳ５０６乃至ステップＳ５０８の処理手順は、何らかの理由で受信パケットの逆転が発生し、既にAccess-Acceptパケットがキャプチャされていた場合に行われる処理手順である。ステップＳ５０６乃至ステップＳ５０８の処理手順は、後述する図１２のステップＳ６０４乃至ステップＳ６０６の処理手順と同一であるため、説明は省略する。図９に戻り説明を続ける。

ステップＳ３０８で、ＳＷ５ｂはAccess-Requestパケットを認証サーバ４に送信する。

ステップＳ３０９で、認証サーバ４は、端末１の認証を行う。認証に成功した場合、認証サーバ４はAccess-AcceptパケットをＳＷ５ｂに送信する。認証に失敗した場合、認証サーバ４はAccess-RejectパケットをＳＷ５ｂに送信する。

ステップＳ３１０で、ＳＷ５ｂのミラーポートから、Access-Acceptパケット又はAccess-Rejectパケットがセッション管理装置１０に送信される。

ステップＳ３１１で、セッション管理装置１０のキャプチャ部２０１は、Access-Acceptパケット又はAccess-Rejectパケットをキャプチャしたことをセッション管理部２０２に通知する。セッション管理部２０２は、キャプチャされたAccess-Acceptパケットに含まれる各属性の設定値をアクセス信号キャッシュテーブルに格納されているレコードに追加する処理等を行う。ここで、ステップＳ３１１でセッション管理部２０２が行う処理手順の詳細を説明する。

図１２は、Access-Acceptパケット又はAccess-Rejectパケットを受信した場合に行われるキャッシュテーブル操作の一例を示すフローチャートである。

ステップＳ６０１で、セッション管理部２０２は、キャプチャされたAccess-Acceptパケット又はAccess-Rejectパケットに含まれる「Proxy-State」の設定値と同一の値を有するレコードがアクセス信号キャッシュテーブルに格納されているか否かを確認する。同一の値を有するレコードが既に格納されている場合、ステップＳ６０３の処理手順に進み、同一の値を有するレコードが格納されていない場合、ステップＳ６０２の処理手順に進む。なお、ステップＳ６０２の処理手順は、何らかの理由で受信パケットの逆転が発生し、Access-Requestパケットがキャプチャされる前にAccess-Acceptパケットがキャプチャされた場合に行われる処理手順である。

なお、セッション管理部２０２は、ステップＳ６０１の処理手順を行う前に、キャプチャされたAccess-Acceptパケット又はAccess-Rejectパケットに含まれる全ての属性の設定値と同一の値を有するレコードがアクセス信号キャッシュテーブルに既に格納されているか否かを確認し、全ての属性の設定値と同一の値を有するレコード格納されている場合、Access-Acceptパケット又はAccess-Rejectパケットが再送されたと判断して処理を終了するようにしてもよい。

ステップＳ６０２で、セッション管理部２０２は、アクセス信号キャッシュテーブルに新たなレコードを追加し、「生成日時」カラムに生成日時を設定する。また、セッション管理部２０２は、キャプチャされたパケットがAccess-Acceptパケットである場合、Access-Acceptパケットに含まれる各属性（「Framed-IP-Address」、「Framed-IP-Netmask」、「Proxy-State」）の設定値を当該新たなレコードに格納すると共に、当該新たなレコードの「状態」カラムを「Ｂ−Ｓ２」に設定して処理を終了する。セッション管理部２０２は、キャプチャされたパケットがAccess-Rejectパケットである場合、当該新たなレコードの「状態」カラムを「Ｂ−Ｓ４」に設定して処理を終了する。

ステップＳ６０３で、セッション管理部２０２は、キャプチャされたパケットがAccess-Acceptパケットなのか、又は、Access-Rejectパケットなのかを判断する。Access-Acceptパケットである場合、ステップＳ６０４の処理手順に進み、Access-Rejectパケットである場合、ステップＳ６０７の処理手順に進む。

ステップＳ６０４で、セッション管理部２０２は、キャプチャされたAccess-Acceptパケットに含まれる「Proxy-State」の設定値と同一の値を有するアクセス信号キャッシュテーブルのレコードに、キャプチャされたAccess-Acceptパケットに含まれる各属性（「Framed-IP-Address」、「Framed-IP-Netmask」）の設定値を追加する。また、当該レコードの「状態」カラムを「Ｂ−Ｓ３」に更新する。

ステップＳ６０５で、セッション管理部２０２は、ステップＳ６０４の処理手順で「状態」カラムを更新したレコードの「Framed-IP-Address」に、２５５．２５５．２５５．２５４が設定されているか否かを確認する。２５５．２５５．２５５．２５４以外の値が設定されている場合、複数固定ＩＰアドレス払い出し、又は固定ＩＰアドレス払い出しが行われていると判断してステップＳ６０６の処理手順に進み、２５５．２５５．２５５．２５４が設定されている場合、動的ＩＰ払い出しが行われていると判断して処理を終了する。

ステップＳ６０６で、セッション情報通知部２０５は、外部装置１１にセッション情報を含むセッション開始通知を送信する。より具体的には、セッション情報通知部２０５は、アクセス信号キャッシュテーブルの「状態」カラムが「Ｂ−Ｓ３」であり、かつ、「Framed-IP-Address」に、２５５．２５５．２５５．２５４以外の値が設定されているレコードの「User-Name」カラム、「NAS-IP-Address」カラム、「Framed-IP-Address」カラム、「Framed-IP-Netmask」カラム及び「Acct-Session-Id」カラムの各設定値を、セッション開始通知に含めて外部装置１１に送信する。

ステップＳ６０７で、セッション管理部２０２は、キャプチャされたAccess-Rejectパケットに含まれる「Proxy-State」の設定値と同一の値を有する、アクセス信号キャッシュテーブルのレコードの「状態」カラムを「Ｂ−Ｓ４」に更新して処理を終了する。図９に戻り説明を続ける。

ステップＳ３１２の処理手順は、図１２のステップＳ６０６で行われる処理手順を、説明の便宜上再掲したものであるため説明は省略する。

ステップＳ３１３で、ＳＷ５ｂは、Access-Acceptパケット又はAccess-Rejectパケットを認証プロキシサーバ３に送信する。認証プロキシサーバ３から送信されたAccess-Acceptパケット又はAccess-Rejectパケットは、ＳＷ５ａを経由してＮＡＳ２に送信される（Ｓ３１４、Ｓ３１５）。

ステップＳ３１６で、ＮＡＳ２は、Access-Acceptパケットを受信した場合、認証に成功したと判断し、端末１が行う通信のセッションが開始されたことを認証サーバ４に通知するために、Accounting-Request(start)パケットをＳＷ５ａに送信する。続いて、ＳＷ５ａは、当該パケットを認証プロキシサーバ３に送信し、認証プロキシサーバ３は、当該パケットをＳＷ５ｂに送信する（Ｓ３１７、Ｓ３１８）。

ステップＳ３１９で、ＳＷ５ｂのミラーポートから、Accounting-Request(start)パケットがセッション管理装置１０に送信される。

ステップＳ３２０で、セッション管理装置１０のキャプチャ部２０１は、Accounting-Request(start)パケットをキャプチャしたことをセッション管理部２０２に通知する。セッション管理部２０２は、キャプチャされたAccounting-Request(start)パケットに含まれる各属性の設定値をアカウンティング信号テーブルに格納する処理を行う。ここで、ステップＳ３２０でセッション管理部２０２が行う処理手順の詳細を説明する。

図１３（ａ）は、Accounting-Request(start)パケットを受信した場合に行われるキャッシュテーブル操作の一例を示すフローチャートである。

ステップＳ７０１で、セッション管理部２０２は、キャプチャされたAccounting-Request(start)パケットに含まれる各属性の設定値と同一の値を有するレコードがアカウンティング信号キャッシュテーブルに格納されているか否かを確認する。同一の値を有するレコードが既に格納されている場合、Accounting-Request(start)パケットが再送されたと判断して処理を終了する。同一の値を有するレコードが格納されていない場合、ステップＳ７０２の処理手順に進む。

ステップＳ７０２で、セッション管理部２０２は、アカウンティング信号キャッシュテーブルに新たなレコードを追加し、キャプチャされたAccounting-Request(start)パケットに含まれる各属性（「User-Name」、「NAS-IP-Address」、「Framed-IP-Address」、「Acct-Status-Type」、「Acct-Session-Id」）の設定値を当該新たなレコードに格納する。

ステップＳ７０３で、セッション情報通知部２０５は、外部装置１１にセッション情報を含むセッション開始通知を送信する。より具体的には、セッション情報通知部２０５は、ステップＳ７０２で追加した新たなレコードの「User-Name」カラム、「NAS-IP-Address」カラム、「Framed-IP-Address」カラム及び「Acct-Session-Id」カラムの各設定値をセッション開始通知に含めて外部装置１１に送信する。なお、セッション情報通知部２０５は、更に「Acct-Status-Type」カラムの設定値をセッション開始通知に含めて外部装置１１に送信するようにしてもよい。図９に戻り説明を続ける。

ステップＳ３２１の処理手順は、図１３のステップＳ７０３で行われる処理手順を説明の便宜上再掲したものであるため説明は省略する。

ステップＳ３２２で、ＳＷ５ｂは、Accounting-Request(start)パケットを認証サーバ４に送信する。

ステップＳ３２３で、ＮＡＳ２は、端末１が行う通信のセッションが終了したことを検出した場合、端末１が行う通信のセッションが終了したことを認証サーバ４に通知するために、Accounting-Request(stop)パケットをＳＷ５ａに送信する。続いて、ＳＷ５ａは、当該パケットを認証プロキシサーバ３に送信し、認証プロキシサーバ３は、当該パケットをＳＷ５ｂに送信する（Ｓ３２４、Ｓ３２５）。

ステップＳ３２６で、ＳＷ５ｂのミラーポートから、Accounting-Request(stop)パケットがセッション管理装置１０に送信される。

ステップＳ３２７で、セッション管理装置１０のキャプチャ部２０１は、Accounting-Request(stop)パケットをキャプチャしたことをセッション管理部２０２に通知する。セッション管理部２０２は、キャプチャされたAccounting-Request(stop)パケットに含まれる各属性の設定値をアカウンティング信号テーブルに格納する処理を行う。ここで、ステップＳ３２６でセッション管理部２０２が行う処理手順の詳細を説明する。

図１３（ｂ）は、Accounting-Request(stop)パケットを受信した場合に行われるキャッシュテーブル操作の一例を示すフローチャートである。

ステップＳ８０１で、セッション管理部２０２は、キャプチャされたAccounting-Request(stop)パケットに含まれる各属性の設定値と同一の値を有するレコードがアカウンティング信号キャッシュテーブルに格納されているか否かを確認する。同一の値を有するレコードが既に格納されている場合、Accounting-Request(stop)パケットが再送されたと判断して処理を終了する。同一の値を有するレコードが格納されていない場合、ステップＳ８０２の処理手順に進む。

ステップＳ８０２で、セッション管理部２０２は、アカウンティング信号キャッシュテーブルに新たなレコードを追加し、キャプチャされたAccounting-Request(stop)パケットに含まれる各属性（「User-Name」、「NAS-IP-Address」、「Framed-IP-Address」、「Acct-Status-Type」、「Acct-Session-Id」）の設定値を当該新たなレコードに格納する。

ステップＳ８０３で、セッション情報通知部２０５は、外部装置１１にセッション情報を含むセッション終了通知を送信する。より具体的には、セッション情報通知部２０５は、ステップＳ７０２で追加した新たなレコードの「User-Name」カラム、「NAS-IP-Address」カラム、「Framed-IP-Address」カラム、「Acct-Status-Type」カラム及び「Acct-Session-Id」カラムの各設定値を、セッション終了通知に含めて外部装置１１に送信する。図９に戻り説明を続ける。

ステップＳ３２８の処理手順は、図１３のステップＳ８０３で行われる処理手順を説明の便宜上再掲したものであるため説明は省略する。

ステップＳ３２９で、ＳＷ５ｂは、Accounting-Request(stop)パケットを認証サーバ４に送信する。

なお、図９の処理手順において、ステップＳ３１９乃至ステップＳ３２１の処理手順は、ステップＳ３１６とステップＳ３１７との間で行われるようにしてもよい。つまり、ＳＷ５ａのミラーポートからセッション管理装置１０に送信されるAccounting-Request(start)パケットを用いて、ステップＳ３１９乃至ステップＳ３２１の処理手順が行われるようにしてもよい。また、キャプチャ部２０１は、ＳＷ５ａのミラーポート及びＳＷ５ｂミラーポートの両方から送信されるAccounting-Request(start)パケットをキャプチャすると共に、セッション管理部２０２は、両方のAccounting-Request(start)パケットを比較することで、Accounting-Request(start)パケットが認証プロキシサーバ３を通過したことを確認するようにしてもよい。

また、ステップＳ３２６乃至ステップＳ３２８の処理手順は、ステップＳ３２３とステップＳ３２４との間で行われるようにしてもよい。つまり、ＳＷ５ａのミラーポートからセッション管理装置１０に送信されるAccounting-Request(stop)パケットを用いて、ステップＳ３２６乃至ステップＳ３２８の処理手順が行われるようにしてもよい。また、キャプチャ部２０１は、ＳＷ５ａのミラーポート及びＳＷ５ｂミラーポートの両方から送信されるAccounting-Request(stop)パケットをキャプチャすると共に、セッション管理部２０２は、両方のAccounting-Request(stop)パケットを比較することで、Accounting-Request(stop)パケットが認証プロキシサーバ３を通過したことを確認するようにしてもよい。

また、ステップＳ３１２、ステップＳ３２１、ステップＳ３２８の処理手順で送信されるセッション開始通知及びセッション終了通知の信号フォーマットは共通であってもよい。すなわち、セッション開始通知及びセッション終了通知の信号フォーマットには、予め「User-Name」、「NAS-IP-Address」、「Framed-IP-Address」、「Framed-IP-Netmask」、「Acct-Status-Type」及び「Acct-Session-Id」を格納可能な領域を設けるようにしてもよい。セッション管理装置１０と外部装置１１との間のインタフェースを簡易にすることができる。

＜まとめ、効果＞
以上、セッション管理装置１０が行うセッション管理処理の処理手順について説明した。ＮＡＳ２及び認証サーバ４との間で行われる認証処理において動的ＩＰ払い出しが行われる場合、セッション管理装置１０は、Access-Acceptパケットをキャプチャしたタイミング（図９のステップＳ３１０）ではセッション開始通知を外部装置１１に送信せずに、Accounting-Requestパケットをキャプチャしたタイミング（図９のステップＳ３１９）でセッション開始通知を外部装置１１に送信するようにした。

また、ＮＡＳ２及び認証サーバ４との間で行われる認証処理において複数固定ＩＰ払い出し及び固定ＩＰ払い出しが行われる場合、セッション管理装置１０は、Access-Acceptパケットをキャプチャしたタイミング（図９のステップＳ３１０）、及び、Accounting-Requestパケットをキャプチャしたタイミング（図９のステップＳ３１９）でセッション開始通知を外部装置１１に送信するようにした。

動的ＩＰアドレス払い出しが行われる場合、Access-Acceptパケットに含まれる「Framed-IP-Netmask」属性には、実際に端末１に払い出されるＩＰアドレスではなく、動的ＩＰアドレス払い出しが行われることを示す所定のＩＰアドレス（２５５．２５５．２５５．２５４）が格納されている。言い換えると、Access-Acceptパケットをキャプチャしたタイミングでセッション開始通知が外部装置１１に送信された場合、外部装置１１は不完全なセッション情報を受け取ることになってしまう。従って、セッション管理装置１０は、動的ＩＰアドレス払い出しが行われる場合、Access-Acceptパケットをキャプチャした時点ではセッション開始通知を外部装置１１に送信しないようにしている。これにより、セッション管理装置１０は、外部装置１１に不完全なセッション情報を通知してしまうのを防止することができる。

一方、複数固定ＩＰアドレス払い出しが行われる場合、端末１に払い出される複数のＩＰアドレスを示す「Framed-IP-Netmask」属性はAccess-Acceptパケットのみに含まれており、Accounting-Requestパケットには含まれていない。言い換えると、動的ＩＰアドレス払い出しが行われる場合のように、Accounting-Requestパケットをキャプチャしたタイミングのみでセッション開始通知が外部装置１１に送信されるようにした場合、外部装置１１は、端末１に払い出された全てのＩＰアドレスを把握することができなくなってしまう。従って、セッション管理装置１０は、複数固定ＩＰアドレス払い出しが行われる場合、Access-Acceptパケットをキャプチャした時点で一旦セッション開始通知を外部装置１１に送信するようにしている。これにより、セッション管理装置１０は、外部装置１１に適切なセッション情報を通知することができる。

また、セッション管理装置１０は、認証プロキシサーバ３の前後でAccess-Requestパケットをキャプチャすることで、Access-Requestパケットが認証プロキシサーバ３を通過したことを確認すると共に、認証プロキシサーバ３を通過する前のAccess-Requestパケットに含まれる「User-Name」属性からドメイン名を含むユーザ名を取得するようにした。これにより、認証プロキシサーバ３によりAccess-Requestパケットに含まれる「User-Name」属性のドメイン名が削除された場合であっても、セッション管理装置１０はドメイン名を含むユーザ名を外部装置１１に通知することができる。

また、セッション管理装置１０は、キャプチャした各種Radiusパケットを一旦キャッシュに格納し、処理に必要なRadiusパケットを全て受信してからセッション情報を外部装置１１に通知するようにした。これにより、セッション管理装置１０は、万が一Radiusパケットのキャプチャ順序が入れ替わった場合であっても、不完全なセッション情報を外部装置１１に通知することなく、より正確なセッション情報を外部装置１１に通知することができる。

また、セッション管理装置１０は、キャプチャした各種Radiusパケットを一旦キャッシュに格納し、一定時間経過後にキャッシュ内のレコードを削除するようにした。これにより、Radiusパケットの喪失が発生した場合、又は不正なRadiusパケットをキャプチャした場合等において、キャッシュ内に不要なレコードが蓄積してセッション管理装置１０のリソースを消費してしまうことを防止することができる。また、これにより、セッション管理装置１０は、Radiusパケットが再送された場合において、一定時間経過前であれば再度セッション情報を外部装置１１に通知しないようにすることができる。

＜実施形態の補足＞
セッション管理装置１０は、ＮＡＳ２が存在しないようなネットワーク環境にも適用できる。例えば、端末１が認証サーバ４との間でRadiusプロトコルを送受信するようなネットワーク環境にも適用することができる。

また、セッション管理装置１０は、認証プロキシサーバ３が存在せず、ＮＡＳ２（又は端末１）と認証サーバ４との間で直接Radiusプロトコルが送受信されるようなネットワーク環境にも適用することができる。この場合、アクセスリクエストキャッシュテーブルに係る一連の処理手順を省略することができる。

セッション管理装置１０の構成は、ＣＰＵとメモリを備える当該装置において、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在していてもよい。

セッション管理装置１０は、仮想ＯＳ上に実装されるようにしてもよい。仮想ＯＳに実装されることで、セッション管理機能に対してスケーラビリティ及び可用性を確保することができる。また、認証プロキシサーバ３、ＳＷ５ａ、ＳＷ５ｂ、及びセッション管理装置１０は、まとめて仮想ＯＳに実装されるようにしてもよい。キャプチャ機能及びセッション管理機能全体に対してスケーラビリティ及び可用性を確保することができる。

以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。

実施の形態で述べたシーケンス及びフローチャートは、矛盾の無い限り順序を入れ替えてもよい。処理説明の便宜上、セッション管理装置１０はソフトウェア構成図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってセッション管理装置１０が有するプロセッサにより動作するソフトウェアは、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。

本発明は上記実施形態に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。

なお、以上実施の形態において、Radiusパケットは認証信号の一例である。キャプチャ部２０１は、キャプチャ手段の一例である。セッション管理部２０２は、セッション管理手段の一例である。セッション情報通知部２０５及び信号送信部２０６は、送信手段の一例である。外部装置１１は、所定の装置の一例である。Access-Requestパケットは、所定の認証信号の一例である。Radiusパケットに含まれる属性の設定値は、複数種別の認証信号に含まれる情報の一例である。一時記憶部２０３は、第一の記憶手段の一例である。記憶部２０４は、第二の記憶手段の一例である。タイムアウト設定情報は、設定情報の一例である。

１ 端末
２ ＮＡＳ
３ 認証プロキシサーバ
４ 認証サーバ
５ａ ＳＷ
５ｂ ＳＷ
１０ セッション管理装置
１１ 外部装置
２０１ キャプチャ部
２０２ セッション管理部
２０３ 一時記憶部
２０４ 記憶部
２０５ セッション情報通知部
２０６ 信号送信部

Claims (9)

1. 端末の認証及びセッション管理を行う認証サーバと、前記端末及び前記認証サーバの間に接続されるアクセスサーバとの間で送受信される複数種別の認証信号をキャプチャすることで、前記端末が行う通信のセッションを管理するセッション管理装置であって、
   前記複数種別の認証信号をキャプチャするキャプチャ手段と、
   キャプチャされた前記複数種別の認証信号を用いて、前記セッションを一意に特定するセッション情報を取得して管理するセッション管理手段と、
   前記セッション情報を所定の装置に送信する送信手段と、
   を有するセッション管理装置。
2. 前記セッション管理手段は、キャプチャされた前記複数種別の認証信号を用いて、前記端末が行う通信のセッションが開始されたこと、又は、前記端末が行う通信のセッションが終了したことを検出し、
   前記送信手段は、前記端末が行う通信のセッションが開始されたことが検出された場合、前記セッション情報を含むセッション開始通知信号を所定の装置に送信し、前記端末が行う通信のセッションが終了したことが検出された場合、前記セッション情報を含むセッション終了通知信号を前記所定の装置に送信する、請求項１に記載のセッション管理装置。
3. 前記キャプチャ手段は、前記アクセスサーバと前記認証サーバの間に接続される認証プロキシサーバの前後で前記複数種別の認証信号のうち所定の認証信号をキャプチャし、
   前記セッション管理手段は、前記認証プロキシサーバの前でキャプチャされた所定の認証信号と、前記認証プロキシサーバの後でキャプチャされた所定の認証信号とを用いて、前記セッション情報を取得する、請求項１又は２に記載のセッション管理装置。
4. 前記複数種別の認証信号に含まれる情報を記憶する第一の記憶手段、を有し、
   前記セッション管理手段は、キャプチャされた前記複数種別の認証信号に含まれる情報を前記第一の記憶手段に格納し、前記第一の記憶手段に格納された情報を用いて前記セッション情報を取得する、請求項１乃至３のいずれか一項に記載のセッション管理装置。
5. 前記第一の記憶手段に格納された情報の有効期間を示す設定情報を記憶する第二の記憶手段、を有し、
   前記セッション管理手段は、前記第一の記憶手段に格納された情報が前記有効期間を経過した場合に、当該情報を前記第一の記憶手段から削除する、請求項４に記載のセッション管理装置。
6. 前記送信手段は、前記複数種別の認証信号のうちアカウンティング要求信号を受信した場合、前記アカウンティング要求信号に含まれている属性情報から前記セッション情報を取得し、取得した前記セッション情報を前記所定の装置に送信する、請求項１乃至５のいずれか一項に記載のセッション管理装置。
7. 前記送信手段は、前記複数種別の認証信号のうちアクセス許可信号を受信した場合であって、かつ、当該アクセス許可信号に含まれている属性情報に、予め定められた所定のＩＰアドレスが設定されていない場合、当該アクセス許可信号に含まれている属性情報から前記セッション情報を取得し、取得した前記セッション情報を前記所定の装置に送信する、請求項１乃至６のいずれか一項に記載のセッション管理装置。
8. 端末の認証及びセッション管理を行う認証サーバと、前記端末及び前記認証サーバの間に接続されるアクセスサーバとの間で送受信される複数種別の認証信号をキャプチャすることで、前記端末が行う通信のセッションを管理するセッション管理装置が行うセッション管理方法であって、
   前記複数種別の認証信号をキャプチャするキャプチャステップと、
   キャプチャされた前記複数種別の認証信号を用いて、前記セッションを一意に特定するセッション情報を取得して管理するセッション管理ステップと、
   前記セッション情報を所定の装置に送信する送信ステップと、
   を有するセッション管理方法。
9. 端末の認証及びセッション管理を行う認証サーバと、前記端末及び前記認証サーバの間に接続されるアクセスサーバとの間で送受信される複数種別の認証信号をキャプチャすることで、前記端末が行う通信のセッションを管理するセッション管理装置におけるプログラムであって、
   前記セッション管理装置に、
   前記複数種別の認証信号をキャプチャするキャプチャステップと、
   キャプチャされた前記複数種別の認証信号を用いて、前記セッションを一意に特定するセッション情報を取得して管理するセッション管理ステップと、
   前記セッション情報を所定の装置に送信する送信ステップと、
   を実行させるプログラム。

Images