JP5171245B2 - プロトコル遅延測定装置及びプロトコル遅延測定方法 - Google Patents

Description

本発明は、暗号化通信環境におけるプロトコル遅延（protocol latency）を測定する装置及び方法に関する。

データ通信ネットワークシステムの監視又は管理には、ネットワークシステムの処理パフォーマンスについての情報の収集が必要であり、そのために、例えば暗号化通信環境でのプロトコル遅延が測定される。

プロトコル遅延を測定する従来の方法としては、例えば特許文献１に記載されたものがある。この方法では、通信端末におけるカーネル層（通信プロトコルスタック）での暗号化処理に起因するプロトコル遅延を測定するために、通信端末において、先ず、当該暗号化処理適用前の未処理データと同一のデータを、アプリケーション層で暗号化し、その際に得られる署名を保存する。そして、カーネル層で未処理データを暗号化し、その際に得られる署名と、保存した署名とを比較することにより、カーネル層で暗号化される前後のデータの同一性を保証する。そして、同一性が保証されたデータについて、プロトコル遅延の測定が実施される。
米国特許第６３６３４７７号明細書

しかしながら、上記従来のプロトコル遅延測定方法においては、遅延測定対象の暗号化処理が適用される前後のデータの同一性を保証するための暗号化処理が別途実行されるため、通信端末において処理オーバヘッドが増加するという問題がある。これは、通信端末においてＣＰＵ（Central Processing Unit）負荷が単純に２倍となることを意味し、ネットワークプロトコルの送受信処理に十分なリソースが割り当てられない可能性も増大する。すなわち、上記プロトコル測定は、実環境と大きく相違する環境下で行われ得るため、測定精度については必ずしも高精度とはいえない。

本発明は、かかる点に鑑みてなされたもので、プロトコル遅延測定に伴う通信端末の処理オーバヘッド増加を抑制することができるプロトコル遅延測定装置及びプロトコル遅延測定方法を提供することを目的とする。

本発明の一態様に係るプロトコル遅延測定装置は、通信端末におけるＩＰｓｅｃ（Internet Protocol Security）処理によるプロトコル遅延を測定するプロトコル遅延測定装置であって、未処理パケットの識別子を生成する識別子生成手段と、生成された識別子を、第１のタイムスタンプと共に記憶するデータベースと、生成された識別子を、前記通信端末においてＩＰｓｅｃ処理前後で同一に維持する記憶領域に書き込む書き込み手段と、前記記憶領域に書き込まれた識別子を読み出す読み出し手段と、読み出された識別子と同一の識別子と共に前記データベースに記憶された第１のタイムスタンプを抽出する抽出手段と、抽出された第１のタイムスタンプと、第２のタイムスタンプとの差分を、プロトコル遅延として算出する算出手段と、を有する構成を採る。

本発明の一態様に係るプロトコル遅延測定方法は、通信端末におけるＩＰｓｅｃ（Internet Protocol Security）処理によるプロトコル遅延を測定するプロトコル遅延測定方法であって、未処理パケットの識別子を生成する識別子生成ステップと、生成された識別子を、第１のタイムスタンプと共にデータベースに記憶させる記憶ステップと、生成された識別子を、前記通信端末においてＩＰｓｅｃ処理前後で同一に維持する記憶領域に書き込む書き込みステップと、前記記憶領域に書き込まれた識別子を読み出す読み出しステップと、読み出された識別子と同一の識別子と共に前記データベースに記憶させた第１のタイムスタンプを抽出する抽出ステップと、抽出された第１のタイムスタンプと、第２のタイムスタンプとの差分を、プロトコル遅延として算出する算出ステップと、を有するようにした。

本発明によれば、プロトコル遅延測定に伴う通信端末の処理オーバヘッド増加を抑制することができる。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

図１は、本発明の一実施の形態に係るデータ通信ネットワークシステムの構成を示す図である。図１のデータ通信ネットワークシステムは、通信端末１がネットワーク２を介して通信端末３とパケット通信を行うことができるよう構成されている。

通信端末１は、ネットワークアプリケーション１１を含むユーザモジュール（図示せず）と、ＴＣＰ（Transmission Control Protocol）／ＵＤＰ（User Datagram Protocol）スタック１２及びＩＰ（Internet Protocol）スタック１３を含むプロトコルスタックモジュール（図示せず）と、を含むように構成されている。ユーザモジュール及びプロトコルスタックモジュールは、ソフトウェア単体として構成することも、ソフトウェアとハードウェアとの組合せとして構成することもできる。また、通信端末１は、ネットワーク２との接続を行う物理デバイス（図示せず）を制御するネットワークデバイスドライバ１４と、後でより詳細に説明するプロトコル遅延測定装置１００と、をさらに含むように構成されている。

ＩＰスタック１３は、ＩＰｓｅｃ（Internet Protocol Security）処理１５を含む。ＩＰｓｅｃ処理１５は、送信データパケット及び受信データパケットにＩＰパケット単位で適用される暗号化処理（暗号化及び復号化を含む）であり、データの改ざん防止・秘匿機能を提供するものである。本実施の形態においては、ＩＰｓｅｃ処理１５がプロトコル遅延の測定対象である。

通信端末３は、ネットワークアプリケーション３１を含むユーザモジュール（図示せず）と、ＴＣＰ（Transmission Control Protocol）／ＵＤＰ（User Datagram Protocol）スタック３２及びＩＰ（Internet Protocol）スタック３３を含むプロトコルスタックモジュール（図示せず）と、を含むように構成されている。ユーザモジュール及びプロトコルスタックモジュールは、ソフトウェア単体として構成することも、ソフトウェアとハードウェアとの組合せとして構成することもできる。また、通信端末３は、ネットワーク２との接続を行う物理デバイス（図示せず）を制御するネットワークデバイスドライバ３４をさらに含むように構成されている。

なお、本実施の形態では、プロトコル遅延測定装置１００が通信端末１にのみ設けられているが、通信端末３にも設けてもよい。また、本実施の形態では、プロトコル遅延測定装置１００が通信端末１と一体として実施されているが、これらを別体として実施し必要時にのみプロトコル遅延測定装置１００を通信端末１、３に接続するようにしてもよい。

図２は、プロトコル遅延測定装置１００の内部構成を示すブロック図である。プロトコル遅延測定装置１００は、インターセプト部１０２、認識処理部１０４、タイムスタンプデータベース（以下「タイムスタンプＤＢ」という。）１０６、相関処理部１０８、算出処理部１１０及び統計データベース（以下「統計ＤＢ」という。）を有する。

インターセプト部１０２は、通信端末１において処理される送信データパケット又は受信データパケットを、カーネル層に設けられたインターセプトポイント１６、１７、１８、１９にてインターセプトする。インターセプトポイント１６〜１９は、例えばＬｉｎｕｘ（登録商標）ネットフィルタモジュールにより提供されるNF_IP_LOCAL_OUT、NF_IP_POSTROUTING、NF_IP_LOCAL_IN及びNF_IP_PRE_ROUTINGといったフックポイントである。インターセプト部１０２によるインターセプトは、上記各フックポイントについてインターセプト機能をＬｉｎｕｘ（登録商標）ネットフィルタモジュールに登録することにより、実現可能である。インターセプトポイント１６〜１９が、例えば上記各フックポイントのように、ＩＰｓｅｃ処理１５の直前又は直後に配置されたものである場合は、プロトコル遅延を正確に測定することができる。

インターセプト部１０２は、インターセプトポイント１６にて、未だＩＰｓｅｃ処理１５を適用されていない送信データパケットをインターセプトし、インターセプトポイント１７にて、既にＩＰｓｅｃ処理１５を適用されている送信データパケットをインターセプトし、インターセプトポイント１８にて、未だＩＰｓｅｃ処理１５を適用されていない受信データパケットをインターセプトし、インターセプトポイント１９にて、既にＩＰｓｅｃ処理１５を適用されている受信データパケットをインターセプトする。また、インターセプト部１０２は、インターセプトポイント１６でインターセプトしたデータパケットを、インターセプトポイント１６に返戻し、インターセプトポイント１７でインターセプトしたデータパケットを、インターセプトポイント１７に返戻し、インターセプトポイント１８でインターセプトしたデータパケットを、インターセプトポイント１８に返戻し、インターセプトポイント１９でインターセプトしたデータパケットを、インターセプトポイント１９に返戻する。

インターセプトされるデータパケットは、通信端末１に設けられたバッファに格納されている。図３には、そのバッファの一例として、ソケットバッファ４０の構成が示されている。ソケットバッファ４０は、ＴＣＰ／ＵＤＰスタック１２及びＩＰスタック１３で処理されるデータパケットと、その処理の管理・制御に用いる各種の情報とを格納するバッファであり、例えばＬｉｎｕｘ（登録商標）カーネルソケットバッファ（sk_buff）である。本実施の形態では、ソケットバッファ４０にはデータパケット５０が格納される他、後述する認識情報６０が、ソケットバッファ４０に格納される。Ｌｉｎｕｘ（登録商標）カーネルソケットバッファ（sk_buff）の場合、認識情報６０の格納は、認識情報６０の値を例えばnfmark又はnfcacheに記録することにより実現可能である。

データパケット５０が送信データパケットの場合は、必要なＩＰｓｅｃ処理１５は暗号化であり、したがって、ＩＰｓｅｃ処理１５を未だ適用されていない送信データパケットは、図４（ａ）に示すようにＩＰヘッダ５１と非暗号化データ５２とを有する非暗号化データパケット５０ａであり、ＩＰｓｅｃ処理１５を既に適用されている送信データパケットは、図４（ｂ）に示すようにＩＰヘッダ５１と暗号化データ５３とを有する暗号化データパケット５０ｂである。一方、データパケット５０が受信データパケットの場合は、必要なＩＰｓｅｃ処理１５は復号化であり、したがって、ＩＰｓｅｃ処理１５を未だ適用されていない受信データパケットは、暗号化データパケット５０ｂであり、ＩＰｓｅｃ処理１５を既に適用されている受信データパケットは、非暗号化データパケット５０ａである。

ＩＰヘッダ５１は、図４（ｃ）に示すように、パケット長５４、プロトコル情報５５及びフラグ５６をそれぞれ表示するフィールドを有する。パケット長５４は、データパケット５０の全体の長さを示すものであり、プロトコル情報５５は、データパケット５０が非暗号化データパケット５０ａであるか暗号化データパケット５０ｂであるかを判断するのに用いる情報である。データパケット５０が暗号化データパケット５０ｂである場合には、ＩＰヘッダ５１には、プロトコル情報５５として、ＩＰセキュリティプロトコル（例えば、ＡＨ（Authentication Header）プロトコル、ＥＳＰ（Encapsulating Security Payload）プロトコル）の表示が含まれる。フラグ５６は、フラグメント化されたデータパケットに関して「０」又は「１」に設定されるフラグである。例えば、後続のフラグメントが存在し、当該データパケットが最終データパケットでないことを、フラグ５６を「０」に設定することによって示し、後続のフラグメントが存在せず、当該データパケットが最終データパケットであることを、フラグ５６を「１」に設定することによって示す。

識別子生成手段、書き込み手段及びタイムスタンプ生成手段としての認識処理部１０４は、プロトコル遅延測定プログラムを記憶装置（図示せず）に記憶し、これをＣＰＵ（図示せず）で実行することにより実現される。認識処理部１０４は、インターセプトされたデータパケットに対して認識処理を実行し、認識処理により認識情報を生成してこれをソケットバッファ４０に書き込み、また、認識処理によりタイムスタンプ等を含むタイムスタンプレコードを生成してこれをタイムスタンプＤＢ１０６に記憶させる。認識処理については、後でより具体的に説明する。

ここで、図５に示すように、認識情報６０は、トラックマーク６１及びインデックス番号６２を含む。

トラックマーク６１は、データパケット５０がプロトコル遅延測定のための処理を施されているか否かを判断するのに用いられる情報であり、例えば「ＡＡ５５」のような定数であってもよいし、例えば「４０００」のようなフラグであってもよい。トラックマーク６１は、異なるストリームに属するデータパケット５０にも同じ値のトラックマーク６１が付される。

インデックス番号６２は、タイムスタンプＤＢ１０６において検索を行う際に用いられる、データパケット５０の識別子としての情報である。例えば、同じストリームに属するデータパケット５０には同じ値のインデックス番号６２が付され、異なるストリームに属するデータパケット５０には、例えば「１１１１」、「２２２２」のように、異なる値のインデックス番号６２が付される。これにより、通信端末１で複数のストリームを同時に収容する場合にも、それぞれのストリームについてプロトコル遅延測定を行うことができる。

トラックマーク６１及びインデックス番号６２はいずれも、複雑な演算を全く伴わない単純な処理により生成可能なデータであるため、ＣＰＵ負荷を増加させることはない。

また、タイムスタンプＤＢ１０６に記憶されるタイムスタンプレコードは、図６に示すように、インデックス番号７１と第１タイムスタンプ７２と非暗号化パケットサイズ７３とをそれぞれ示すフィールドを含むタイムスタンプデータフォーマット７０を有する。インデックス番号７１は、インデックス番号６２と同一である。第１タイムスタンプ７２は、ＩＰｓｅｃ処理１５の適用開始タイミングを規定するタイムスタンプである。非暗号化パケットサイズ７３は、非暗号化データパケット５０ａの全体の長さを示すものである。

タイムスタンプＤＢ１０６は、認識処理で得られたタイムスタンプレコードを記憶する記憶装置により構成される。

読み出し手段、抽出手段及びタイムスタンプ生成手段としての相関処理部１０８は、プロトコル遅延測定プログラムを記憶装置（図示せず）に記憶し、これをＣＰＵ（図示せず）で実行することにより実現される。相関処理部１０８は、インターセプトされたデータパケットに対して相関処理を実行し、相関処理により第２タイムスタンプを生成する。第２タイムスタンプは、後述する算出処理に用いられる。相関処理については、後でより具体的に説明する。

算出手段としての算出処理部１１０は、プロトコル遅延測定プログラムを記憶装置（図示せず）に記憶し、これをＣＰＵで実行することにより実現される。算出処理部１１０は、第１タイムスタンプと第２タイムスタンプとの差分を算出することによりプロトコル遅延を測定する算出処理を実行し、その測定結果を示す統計レコードを生成してこれを統計ＤＢ１１２に記憶させる。算出処理については、後でより具体的に説明する。

統計ＤＢ１１２は、プロトコル遅延測定結果を示す統計レコードを記憶する記憶装置により構成される。統計ＤＢ１１２は、処理パフォーマンスの評価が行われる場合等に、内部に記憶されている統計レコードを送出することにより、プロトコル遅延測定結果を報告することができる。

ここで、統計ＤＢ１１２に記憶される統計レコードは、図７に示すように、インデックス番号８１と経過時間８２と合計パケットサイズ８３とをそれぞれ示すフィールドを含む統計データフォーマット８０を有する。インデックス番号８１は、インデックス番号６２、７１と同一である。経過時間８２は、第２タイムスタンプの値から第１タイムスタンプの値を減算することにより得られる値（フラグメントの場合は、その累計）であり、プロトコル遅延の値に相当する。合計パケットサイズ８３は、同じインデックス番号８１を付され、経過時間８２の算出に用いられたパケットのサイズ（フラグメントの場合は、その累計）である。

以下、認識処理部１０４による認識処理と相関処理部１０８による相関処理と算出処理部１１０による算出処理とを含む、プロトコル遅延測定のための一連の処理について、２つのケースに大別して説明する。第１のケースでは、送信データパケットに適用されるＩＰｓｅｃ処理１５、つまり暗号化によるプロトコル遅延が測定され、第２のケースでは、受信データパケットに適用されるＩＰｓｅｃ処理１５、つまり復号化によるプロトコル遅延が測定される。

先ず、第１のケースについて説明する。図８は、第１のケースにおける処理フローを示す図である。送信データパケットは、経路９０を辿って上位層から下位層に送られる途中で、２度にわたってインターセプトされる。１度目のインターセプトは暗号化前に行われる。より具体的には、送信データパケットは、暗号化前に、インターセプトポイント１６でインターセプトされ、プロトコル遅延測定装置１００において処理され、インターセプトポイント１６に戻される（インターセプト経路９１）。２度目のインターセプトは暗号化後に行われる。より具体的には、送信データパケットは、暗号化後に、インターセプトポイント１７でインターセプトされ、プロトコル遅延測定装置１００において処理され、インターセプトポイント１７に戻される（インターセプト経路９２）。

インターセプト経路９１を辿る送信データパケット、すなわち非暗号化データパケットに対しては、プロトコル遅延測定装置１００において、図９に示されるように、認識処理部１０４による認識処理を含む動作が実行される。

図９は、インターセプト経路９１を辿る非暗号化データパケットについての、プロトコル遅延測定装置１００における動作を説明するためのフロー図である。

先ず、ステップＳ１０１では、インターセプト部１０２は、インターセプトポイント１６からデータパケットをインターセプトする。これは、例えばプロトコル遅延測定の要求を受けたときに開始される。

なお、本実施の形態では、インターセプト部１０２は、インターセプトポイント１６にて暗号化前の送信データパケットのみをインターセプトするよう構成されているが、インターセプトポイント１６にて暗号化後のものもインターセプトし得る場合には、インターセプト部１０２は、ソケットバッファに格納されたデータパケットのプロトコル情報を参照することにより、データパケットが暗号化前のものか暗号化後のものかを判定することができる。

そしてステップＳ１０２では、認識処理部１０４は、タイムスタンプ（第１タイムスタンプ）を生成すると共に、インターセプトされた非暗号化データパケットの識別子としてインデックス番号を生成する。このように、ＩＰｓｅｃ処理適用前の非暗号化データパケットがインターセプトされたタイミングに合わせて第１タイムスタンプが生成されるため、ＩＰｓｅｃ処理適用開始タイミングをより正確に特定することができ、ひいてはプロトコル遅延の測定精度を向上させることができる。

そしてステップＳ１０３では、認識処理部１０４は、予め定められたトラックマークと、生成されたインデックス番号とを組み合わることにより、認識情報を生成する。図１１（ａ）に、生成される認識情報の一例を示す。

そしてステップＳ１０４では、認識処理部１０４は、生成された認識情報をソケットバッファに書き込む。

そしてステップＳ１０５では、認識処理部１０４は、ソケットバッファに格納されたデータパケットのＩＰヘッダ内のパケット長を読み出すことにより、非暗号化データパケットのパケットサイズを取得する。

そしてステップＳ１０６では、認識処理部１０４は、予め定められたタイムスタンプデータフォーマットにおいて、生成されたインデックス番号をインデックス番号フィールドに、生成された第１タイムスタンプを第１タイムスタンプフィールドに、取得されたパケットサイズを非暗号化パケットサイズフィールドに、それぞれ設定することにより、タイムスタンプレコードを生成する。図１１（ｂ）に、生成されるタイムスタンプレコードの一例を示す。そして、認識処理部１０４は、生成されたタイムスタンプレコードをタイムスタンプＤＢ１０６に記憶させることにより、新規のレコードをタイムスタンプＤＢ１０６に追加する。

そしてステップＳ１０７では、インターセプト部１０２は、ステップＳ１０１でインターセプトされた非暗号化データパケットを、インターセプトポイント１６に返戻する。返戻された非暗号化データパケットは、ＩＰｓｅｃ処理１５に送られ、そこで暗号化されて、暗号化データパケットとなる。

このように、送信データパケットがＩＰｓｅｃ処理１５を適用される前にインターセプト経路９１を辿った結果として、ＩＰｓｅｃ処理１５の適用開始タイミングを特定するタイムスタンプが取得され、さらに、その送信データパケットの認識情報が、その送信データパケットのソケットバッファに格納される。

インターセプト経路９２を辿る送信データパケット、すなわち暗号化データパケットに対しては、プロトコル遅延測定装置１００において、図１０に示されるように、相関処理部１０８による相関処理と算出処理部１１０による算出処理とを含む動作が実行される。

図１０は、インターセプト経路９２を辿る暗号化データパケットについての、プロトコル遅延測定装置１００における動作を説明するためのフロー図である。

先ず、ステップＳ２０１では、インターセプト部１０２は、インターセプトポイント１７からデータパケットをインターセプトする。これは、図９を用いて説明した動作と同様、プロトコル遅延測定の要求を受けたときに開始される。

なお、本実施の形態では、インターセプト部１０２は、インターセプトポイント１７にて暗号化後の送信データパケットのみをインターセプトするよう構成されているが、インターセプトポイント１７にて暗号化前のものもインターセプトし得る場合には、インターセプト部１０２は、ソケットバッファに格納されたデータパケットのプロトコル情報を参照することにより、データパケットが暗号化前のものか暗号化後のものかを判定することができる。

そしてステップＳ２０２では、相関処理部１０８は、インターセプトされた暗号化データパケットのソケットバッファにおいて、所定の記憶領域の設定値が予め定められた値に設定されているか否かを判定することにより、トラックマークの有無を判定する。トラックマークがある場合は、ステップＳ２０３に進み、トラックマークがない場合は、ステップＳ２１０に進む。このように、予め定められた値を有するトラックマークの有無の判定を行うことにより、認識情報の有無を容易に確認することができる。

ステップＳ２０３では、相関処理部１０８は、ソケットバッファからインデックス番号を読み出す。このインデックス番号は、図９を用いて説明した動作において、ＩＰｓｅｃ処理適用前の非暗号化データパケットについて生成されたものである。非暗号化データパケットは、ＩＰｓｅｃ処理１５を適用されると、暗号化データパケットとなるのに対し、ソケットバッファに格納された認識情報はＩＰｓｅｃ処理適用後も不変のまま維持されるものであるため、暗号化データパケットのソケットバッファから読み出されたインデックス番号は、その暗号化データパケットが暗号化される前に生成されたインデックス番号と同一である。したがって、相関処理部１０８は、ソケットバッファに格納されたインデックス番号を、暗号化データパケットのインデックス番号として取得することができる。

そしてステップＳ２０４では、相関処理部１０８は、読み出されたインデックス番号を検索条件として用いて、タイムスタンプＤＢ１０６においてタイムスタンプレコードの検索を行う。具体的には、相関処理部１０８は、タイムスタンプＤＢ１０６に記憶された少なくとも１つのタイムスタンプレコードのうち、読み出されたインデックス番号と同一のインデックス番号を有するものを検索する。検索の結果、そのようなタイムスタンプレコードが、タイムスタンプＤＢ１０６において特定された場合には、ステップＳ２０５に進み、タイムスタンプＤＢ１０６において特定されなかった場合には、ステップＳ２０９に進む。

そしてステップＳ２０５では、相関処理部１０８は、特定されたタイムスタンプレコードを読み出すことにより、タイムスタンプＤＢ１０６から第１タイムスタンプと非暗号化パケットサイズとを抽出し、これらを算出処理部１１０に通知する。好ましくはこのとき、相関処理部１０８は、読み出されたタイムスタンプをタイムスタンプＤＢ１０６から削除する。これにより、タイムスタンプＤＢ１０６に割り当てられる記憶領域を効率的に使用することができる。

そしてステップＳ２０６では、相関処理部１０８は、第２タイムスタンプを生成し、これを算出処理部１１０に通知する。図１１（ｃ）に、生成される第２タイムスタンプの一例を示す。このように、ＩＰｓｅｃ処理適用後の暗号化データパケットがインターセプトされたタイミングに合わせて第２タイムスタンプが生成されるため、ＩＰｓｅｃ処理適用終了タイミングをより正確に特定することができ、ひいてはプロトコル遅延の測定精度を向上させることができる。

そしてステップＳ２０７では、算出処理部１１０は、第１タイムスタンプと第２タイムスタンプとの差分を算出する。第１タイムスタンプはＩＰｓｅｃ処理適用開始タイミングを特定するものであり、第２タイムスタンプはＩＰｓｅｃ処理適用終了タイミングを特定するものであるため、算出された差分は、ＩＰｓｅｃ処理１５の適用開始から適用終了までの経過時間に相当する。

そしてステップＳ２０８では、算出処理部１１０は、予め定められた統計データフォーマットにおいて、通知されたインデックス番号をインデックス番号フィールドに、算出された経過時間を経過時間フィールドに、通知された非暗号化パケットサイズを合計パケットサイズフィールドに、それぞれ設定することにより、統計レコードを生成する。図１１（ｄ）に、生成される統計レコードの一例を示す。なお、例えば同じインデックス番号を有する統計レコードが既に統計ＤＢ１１２に記憶されている場合等、経過時間を合算する必要がある場合は、統計ＤＢ１１２に記憶されている統計レコードの経過時間及び合計パケットサイズを読み出し、これらに、算出された経過時間及び通知された非暗号化パケットサイズを合算することにより、統計レコードを生成する。そして、算出処理部１１０は、生成された統計レコードを統計ＤＢ１１２に記憶させることにより、統計ＤＢ１１２を更新する。

そしてステップＳ２０９では、インターセプト部１０２は、ステップＳ２０１でインターセプトされた暗号化データパケットを、インターセプトポイント１７に返戻する。返戻された暗号化データパケットは、ネットワークデバイスドライバ１４に送られる。

このように、送信データパケットがＩＰｓｅｃ処理１５を適用された後にインターセプト経路９２を辿った結果として、ＩＰｓｅｃ処理１５の適用終了タイミングを特定するタイムスタンプが取得され、さらに、その送信データパケットの認識情報が、その送信データパケットのソケットバッファから取得される。

既述の通り、送信データパケットの認識情報は、その送信データパケットがＩＰｓｅｃ処理１５を適用されても不変であるため、送信データパケットを容易に同定することができる。

ここで、インターセプトポイント１６からインターセプトされた送信データパケットが、ＭＴＵ（Maximum Transmission Unit）よりも大きいパケットサイズを有する場合について、説明する。

ＭＴＵよりも大きいサイズを有する送信データパケットは、ＩＰｓｅｃ処理適用前にフラグメント化される。そこで、本実施の形態では、インターセプト部１０２は、ＭＴＵよりも大きいサイズを有する送信データパケットについては、フラグメント化の前にインターセプトする。また、これを実現し得る位置に、インターセプトポイント１６が配置される。これにより、大サイズの送信データパケットについて、ＩＰｓｅｃ処理適用開始タイミングを特定する第１タイムスタンプを無駄なく１つだけ生成することができ、また、認識情報及びタイムスタンプレコードも無駄なく１つずつだけ生成することができる。図１２（ａ）及び図１２（ｂ）に、認識情報及びタイムスタンプレコードの一例を示す。

１つの非暗号化データパケットをフラグメント化することにより得られるＮ個（Ｎは２以上の整数）のフラグメントは、ＩＰｓｅｃ処理１５の適用後、Ｎ個の暗号化データパケットとなる。これらの暗号化データパケットは、インターセプトポイント１７から順次インターセプトされる。

相関処理部１０８は、順次インターセプトされたＮ個の暗号化データパケットに対して個々に第２タイムスタンプを生成する。例えば、Ｎ＝４の場合は、図１２（ｃ）に示すように、４つの第２タイムスタンプが生成される。

相関処理部１０８は、第２タイムスタンプの生成に並行して、順次インターセプトされた個々の暗号化データパケットが、最終パケットであるか否かを判定する。この判定には、パケットサイズを判定基準とするものや、フラグを判定基準とするもの等がある。

前者の場合は、相関処理部１０８は、順次インターセプトされた個々の暗号化データパケットのサイズを順次測定し、これを順次積算する。そして、積算値が、タイムスタンプＤＢ１０６から抽出された非暗号化パケットサイズに到達したときに、最後に積算された暗号化データパケットを最終パケットと判定することができる。

後者の場合は、相関処理部１０８は、順次インターセプトされた個々の暗号化データパケットのフラグを参照する。そして、後続パケットがなく最終パケットである旨を示すフラグが立っている暗号化データパケットを最終パケットと判定することができる。

相関処理部１０８は、最終パケットが特定されたとき、その最終パケットがインターセプトされたときに生成された第２タイムスタンプを算出処理部１１０に通知する。よって、算出処理部１１０は、Ｎ個の第２タイムスタンプが生成されていても、図１２（ｄ）に示すように経過時間を１回算出するだけで、Ｎ個のセグメント化データパケットについてのプロトコル遅延の測定を完了することができる。

なお、算出処理部１１０は、Ｎ個の第２タイムスタンプの全てが通知された場合でも、どの第２タイムスタンプが最終パケットのものであるかが相関処理部１０８から通知されれば、Ｎ個のセグメント化データパケットについてのプロトコル遅延の測定を行うことができ、また、最終パケットの第２タイムスタンプのみが通知された場合と同じタイミングで、プロトコル遅延の測定を完了することができる。

また、Ｎ個のセグメント化データパケットについてのプロトコル遅延を測定する場合には、図１０を用いて説明した動作のステップＳ２０７において、第１タイムスタンプと第２タイムスタンプとの差分を算出するのに加えて、連続してインターセプトされた２つのセグメント化データパケットについてそれぞれ生成された第２タイムスタンプの差分を算出し、これを積算してもよい。Ｎ＝４の場合を例にとり、図１２（ｅ）を用いて説明する。１番目のセグメント化データパケットについては、当該パケットについての第２タイムスタンプと、第１タイムスタンプとの差分（４３２）を算出し、この算出結果を新規レコードとして統計ＤＢ１１２に保持させる。２番目のセグメント化データパケットについては、当該パケットについての第２タイムスタンプと、１番目のセグメント化データパケットについての第２タイムスタンプとの差分（４２４）を算出し、これを積算し（４３２＋４２４＝８５６）、この算出結果によりレコードを更新する。３番目のセグメント化データパケットについては、当該パケットについての第２タイムスタンプと、２番目のセグメント化データパケットについての第２タイムスタンプとの差分（４３２）を算出し、これを積算し（８５６＋４３２＝１２８８）、この算出結果によりレコードを更新する。４番目のセグメント化データパケットについては、当該データパケットについての第２タイムスタンプと、３番目のセグメント化データパケットについての第２タイムスタンプとの差分（４２８）を算出し、これを積算し（１２８８＋４２８＝１７１６）、この算出結果によりレコードを更新する。４番目のセグメント化データパケットが最終パケットであることが相関処理部１０８から通知されたとき、算出処理部１１０は、これらのセグメント化データパケットについてのプロトコル遅延の測定を完了することができる。

次いで、第２のケースについて説明する。図１３は、第２のケースにおける処理フローを示す図である。受信データパケットは、経路９５を辿って下位層から上位層に送られる途中で、２度にわたってインターセプトされる。１度目のインターセプトは復号化前に行われる。より具体的には、受信データパケットは、復号化前に、インターセプトポイント１８でインターセプトされ、プロトコル遅延測定装置１００において処理され、インターセプトポイント１８に戻される（インターセプト経路９６）。２度目のインターセプトは復号化後に行われる。より具体的には、受信データパケットは、復号化後に、インターセプトポイント１９でインターセプトされ、プロトコル遅延測定装置１００において処理され、インターセプトポイント１９に戻される（インターセプト経路９７）。

インターセプト経路９６を辿る受信データパケット、すなわち暗号化データパケットに対しては、プロトコル遅延測定装置１００において、図１４に示されるように、認識処理部１０４による認識処理を含む動作が実行される。

図１４は、インターセプト経路９６を辿る暗号化データパケットについての、プロトコル遅延測定装置１００における動作を説明するためのフロー図である。

先ず、ステップＳ３０１では、インターセプト部１０２は、インターセプトポイント１８からデータパケットをインターセプトする。これは、例えばプロトコル遅延測定の要求を受けたときに開始される。

なお、本実施の形態では、インターセプト部１０２は、インターセプトポイント１８にて復号化前の受信データパケットのみをインターセプトするよう構成されているが、インターセプトポイント１８にて復号化後のものもインターセプトし得る場合には、インターセプト部１０２は、ソケットバッファに格納されたデータパケットのプロトコル情報を参照することにより、データパケットが復号化前のものか復号化後のものかを判定することができる。

そしてステップＳ３０２では、認識処理部１０４は、タイムスタンプ（第１タイムスタンプ）を生成すると共に、インターセプトされた暗号化データパケットの識別子としてインデックス番号を生成する。このように、ＩＰｓｅｃ処理適用前の暗号化データパケットがインターセプトされたタイミングに合わせて第１タイムスタンプが生成されるため、ＩＰｓｅｃ処理適用開始タイミングをより正確に特定することができ、ひいてはプロトコル遅延の測定精度を向上させることができる。

そしてステップＳ３０３では、認識処理部１０４は、予め定められたトラックマークと、生成されたインデックス番号とを組み合わることにより、認識情報を生成する。図１６（ａ）に、生成される認識情報の一例を示す。

そしてステップＳ３０４では、認識処理部１０４は、生成された認識情報をソケットバッファに書き込む。

そしてステップＳ３０５では、認識処理部１０４は、予め定められたタイムスタンプデータフォーマットにおいて、生成されたインデックス番号をインデックス番号フィールドに、生成された第１タイムスタンプを第１タイムスタンプフィールドに、それぞれ設定することにより、タイムスタンプレコードを生成する。図１６（ｂ）に、生成されるタイムスタンプレコードの一例を示す。そして、認識処理部１０４は、生成されたタイムスタンプレコードをタイムスタンプＤＢ１０６に記憶させることにより、新規のレコードをタイムスタンプＤＢ１０６に追加する。

そしてステップＳ３０６では、インターセプト部１０２は、ステップＳ３０１でインターセプトされた暗号化データパケットを、インターセプトポイント１８に返戻する。返戻された暗号化データパケットは、ＩＰｓｅｃ処理１５に送られ、そこで復号化されて、非暗号化データパケットとなる。

このように、受信データパケットがＩＰｓｅｃ処理１５を適用される前にインターセプト経路９６を辿った結果として、ＩＰｓｅｃ処理１５の適用開始タイミングを特定するタイムスタンプが取得され、さらに、その受信データパケットの認識情報が、その受信データパケットのソケットバッファに格納される。

インターセプト経路９７を辿る受信データパケット、すなわち非暗号化データパケットに対しては、プロトコル遅延測定装置１００において、図１５に示されるように、相関処理部１０８による相関処理と算出処理部１１０による算出処理とを含む動作が実行される。

図１５は、インターセプト経路９７を辿る暗号化データパケットについての、プロトコル遅延測定装置１００における動作を説明するためのフロー図である。

先ず、ステップＳ４０１では、インターセプト部１０２は、インターセプトポイント１９からデータパケットをインターセプトする。これは、図１４を用いて説明した動作と同様、プロトコル遅延測定の要求を受けたときに開始される。

なお、本実施の形態では、インターセプト部１０２は、インターセプトポイント１９にて復号化後の受信データパケットのみをインターセプトするよう構成されているが、インターセプトポイント１９にて復号化前のものもインターセプトし得る場合には、インターセプト部１０２は、ソケットバッファに格納されたデータパケットのプロトコル情報を参照することにより、データパケットが復号化前のものか復号化後のものかを判定することができる。

そしてステップＳ４０２では、相関処理部１０８は、インターセプトされた非暗号化データパケットのソケットバッファにおいて、所定の記憶領域の設定値が予め定められた値に設定されているか否かを判定することにより、トラックマークの有無を判定する。トラックマークがある場合は、ステップＳ４０３に進み、トラックマークがない場合は、ステップＳ４１０に進む。このように、予め定められた値を有するトラックマークの有無の判定を行うことにより、認識情報の有無を容易に確認することができる。

ステップＳ４０３では、相関処理部１０８は、ソケットバッファからインデックス番号を読み出す。このインデックス番号は、図１５を用いて説明した動作において、ＩＰｓｅｃ処理適用前の暗号化データパケットについて生成されたものである。暗号化データパケットは、ＩＰｓｅｃ処理１５を適用されると、非暗号化データパケットとなるのに対し、ソケットバッファに格納された認識情報はＩＰｓｅｃ処理適用後も不変のまま維持されるものであるため、非暗号化データパケットのソケットバッファから読み出されたインデックス番号は、その非暗号化データパケットが復号化される前に生成されたインデックス番号と同一である。したがって、相関処理部１０８は、ソケットバッファに格納されたインデックス番号を、非暗号化データパケットのインデックス番号として取得することができる。

そしてステップＳ４０４では、相関処理部１０８は、読み出されたインデックス番号を検索条件として用いて、タイムスタンプＤＢ１０６においてタイムスタンプレコードの検索を行う。具体的には、相関処理部１０８は、タイムスタンプＤＢ１０６に記憶された少なくとも１つのタイムスタンプレコードのうち、読み出されたインデックス番号と同一のインデックス番号を有するものを検索する。検索の結果、そのようなタイムスタンプレコードが、タイムスタンプＤＢ１０６において特定された場合には、ステップＳ４０５に進み、タイムスタンプＤＢ１０６において特定されなかった場合には、ステップＳ４１０に進む。

そしてステップＳ４０５では、相関処理部１０８は、特定されたタイムスタンプレコードを読み出すことにより、タイムスタンプＤＢ１０６から第１タイムスタンプを抽出し、これらを算出処理部１１０に通知する。好ましくはこのとき、相関処理部１０８は、読み出されたタイムスタンプをタイムスタンプＤＢ１０６から削除する。これにより、タイムスタンプＤＢ１０６に割り当てられる記憶領域を効率的に使用することができる。

そしてステップＳ４０６では、相関処理部１０８は、第２タイムスタンプを生成し、これを算出処理部１１０に通知する。図１６（ｃ）に、生成される第２タイムスタンプの一例を示す。このように、ＩＰｓｅｃ処理適用後の非暗号化データパケットがインターセプトされたタイミングに合わせて第２タイムスタンプが生成されるため、ＩＰｓｅｃ処理適用終了タイミングをより正確に特定することができ、ひいてはプロトコル遅延の測定精度を向上させることができる。

そしてステップＳ４０７では、算出処理部１１０は、第１タイムスタンプと第２タイムスタンプとの差分を算出する。第１タイムスタンプはＩＰｓｅｃ処理適用開始タイミングを特定するものであり、第２タイムスタンプはＩＰｓｅｃ処理適用終了タイミングを特定するものであるため、算出された差分は、ＩＰｓｅｃ処理１５の適用開始から適用終了までの経過時間に相当する。

そしてステップＳ４０８では、認識処理部１０４は、ソケットバッファに格納されたデータパケットのＩＰヘッダ内のパケット長を読み出すことにより、非暗号化データパケットのパケットサイズを取得し、これを算出処理部１１０に通知する。

そしてステップＳ４０９では、算出処理部１１０は、予め定められた統計データフォーマットにおいて、通知されたインデックス番号をインデックス番号フィールドに、算出された経過時間を経過時間フィールドに、通知された非暗号化パケットサイズを合計パケットサイズフィールドに、それぞれ設定することにより、統計レコードを生成する。図１６（ｄ）に、生成される統計レコードの一例を示す。なお、例えば同じインデックス番号を有する統計レコードが既に統計ＤＢ１１２に記憶されている場合等、経過時間を合算する必要がある場合は、統計ＤＢ１１２に記憶されている統計レコードの経過時間及び合計パケットサイズを読み出し、これらに、算出された経過時間及び通知された非暗号化パケットサイズを合算することにより、統計レコードを生成する。そして、算出処理部１１０は、生成された統計レコードを統計ＤＢ１１２に記憶させることにより、統計ＤＢ１１２を更新する。

そしてステップＳ４１０では、インターセプト部１０２は、ステップＳ４０１でインターセプトされた非暗号化データパケットを、インターセプトポイント１９に返戻する。返戻された非暗号化データパケットは、ＴＣＰ／ＵＤＰスタック１２に送られる。

このように、受信データパケットがＩＰｓｅｃ処理１５を適用された後にインターセプト経路９７を辿った結果として、ＩＰｓｅｃ処理１５の適用終了タイミングを特定するタイムスタンプが取得され、さらに、その受信データパケットの認識情報が、その受信データパケットのソケットバッファから取得される。

既述の通り、受信データパケットの認識情報は、その受信データパケットがＩＰｓｅｃ処理１５を適用されても不変であるため、受信データパケットを容易に同定することができる。

なお、インターセプトポイント１８からインターセプトされた受信データパケットがフラグメントである場合、このフラグメントは、ＩＰスタック１３においてＩＰｓｅｃ処理後に他のフラグメントと結合される。そこで、本実施の形態では、インターセプト部１０２は、フラグメント化された受信データパケットについては、結合後にインターセプトする。また、これを実現し得る位置に、インターセプトポイント１９が配置される。これにより、フラグメント化された受信データパケットについて、ＩＰｓｅｃ処理適用終了タイミングを特定する第２タイムスタンプを無駄なく１つだけ生成することができる。

以上のように、本実施の形態によれば、ＩＰｓｅｃ処理適用前のデータパケットのインデックス番号を生成し、生成したインデックス番号を、ＩＰｓｅｃ処理適用前後で同一に維持するソケットバッファの領域に格納する。したがって、インデックス番号の生成においては、ＩＰｓｅｃ処理１５の影響を全く考慮する必要がないため、複雑な演算を行うことなく非常に容易に生成し得ることとなり、プロトコル遅延測定に伴う処理オーバヘッド増加を抑制することができる。これにより、ユーザは、リアルタイムで通信状況を把握し、様々な利用状況や利用環境に応じたＱｏＳ（Quality of Service）制御を実施するのに不可欠な測定情報を通信端末内で取得することができる。

以上、本発明の実施の形態について説明した。なお、以上の説明は本発明の好適な実施の形態の例証であり、本発明はこれに限定されるべきものでなく、種々変更して実施することが可能である。

本発明のプロトコル遅延測定装置及びプロトコル遅延測定方法は、プロトコル遅延測定に伴う通信端末の処理オーバヘッド増加を抑制することができる効果を有し、暗号化通信環境においてプロトコル遅延を測定する装置及び方法として有用である。

本発明の一実施の形態に係る通信ネットワークシステムの構成を示すブロック図 本発明の一実施の形態に係るプロトコル遅延測定装置の構成を示すブロック図 本発明の一実施の形態に係るソケットバッファの構成を示す図 （ａ）非暗号化データパケットのフォーマットを示す図、（ｂ）暗号化データパケットのフォーマットを示す図、（ｃ）ＩＰヘッダのフォーマットを示す図 本発明の一実施の形態に係る認識情報のフォーマットを示す図 本発明の一実施の形態に係るタイムスタンプデータフォーマットを示す図 本発明の一実施の形態に係る統計データフォーマットを示す図 本発明の一実施の形態に係る、パケット送信の場合の処理フローを示す図 本発明の一実施の形態に係る、パケット送信の場合のＩＰｓｅｃ処理適用前の、プロトコル遅延測定装置の動作を説明するフロー図 本発明の一実施の形態に係る、パケット送信の場合のＩＰｓｅｃ処理適用後の、プロトコル遅延測定装置の動作を説明するフロー図 （ａ）送信データパケットについて得られる認識情報の一例を示す図、（ｂ）送信データパケットについて得られるタイムスタンプレコードの一例を示す図、（ｃ）送信データパケットについて得られる第２タイムスタンプの一例を示す図、（ｄ）送信データパケットについて得られる統計レコードの一例を示す図 （ａ）大サイズの送信データパケットについて得られる認識情報の一例を示す図、（ｂ）大サイズの送信データパケットについて得られるタイムスタンプレコードの一例を示す図、（ｃ）大サイズの送信データパケットについて得られる複数の第２タイムスタンプの一例を示す図、（ｄ）大サイズの送信データパケットについて得られる統計レコードの一例を示す図、（ｅ）大サイズの送信データパケットについて更新される統計レコードの一例を示す図 本発明の一実施の形態に係る、パケット受信の場合の処理フローを示す図 本発明の一実施の形態に係る、パケット受信の場合のＩＰｓｅｃ処理適用前の、プロトコル遅延測定装置の動作を説明するフロー図 本発明の一実施の形態に係る、パケット受信の場合のＩＰｓｅｃ処理適用後の、プロトコル遅延測定装置の動作を説明するフロー図 （ａ）受信データパケットについて得られる認識情報の一例を示す図、（ｂ）受信データパケットについて得られるタイムスタンプレコードの一例を示す図、（ｃ）受信データパケットについて得られる第２タイムスタンプの一例を示す図、（ｄ）受信データパケットについて得られる統計レコードの一例を示す図

符号の説明

１２ ＴＣＰ／ＵＤＰスタック
１３ ＩＰスタック
１４ ネットワークデバイスドライバ
１５ ＩＰｓｅｃ処理
１６、１７、１８、１９ インターセプトポイント
４０ ソケットバッファ
１００ プロトコル遅延測定装置
１０２ インターセプト部
１０４ 認識処理部
１０６ タイムスタンプＤＢ
１０８ 相関処理部
１１０ 算出処理部
１１２ 統計ＤＢ

Claims (6)

1. 通信端末におけるＩＰｓｅｃ（Internet Protocol Security）処理によるプロトコル遅延を測定するプロトコル遅延測定装置であって、
   未処理パケット及び処理済パケットをインターセプトするインターセプト手段と、
   前記未処理パケットがインターセプトされたときに第１のタイムスタンプを生成し、前記処理済パケットがインターセプトされたときに第２のタイムスタンプを生成するタイムスタンプ生成手段と、
   前記未処理パケットの識別子を生成する識別子生成手段と、
   生成された前記識別子を、前記第１のタイムスタンプと共に記憶するデータベースと、
   生成された前記識別子を、前記通信端末においてＩＰｓｅｃ処理前後で同一に維持する記憶領域に書き込む書き込み手段と、
   前記記憶領域に書き込まれた前記識別子を読み出す読み出し手段と、
   読み出された前記識別子と同一の識別子と共に前記データベースに記憶された前記第１のタイムスタンプを抽出する抽出手段と、
   抽出された前記第１のタイムスタンプと、前記第２のタイムスタンプとの差分を、プロトコル遅延として算出する算出手段と、
   を有するプロトコル遅延測定装置。
2. 前記インターセプト手段は、未処理パケットを、ＩＰｓｅｃ処理直前のインターセプトポイントでインターセプトし、処理済パケットを、ＩＰｓｅｃ処理直後のインターセプトポイントでインターセプトする請求項１記載のプロトコル遅延測定装置。
3. 未処理パケットがＩＰｓｅｃ処理前に複数の分割パケットに分割される場合には、ＩＰｓｅｃ処理により当該複数の分割パケットから複数の処理済パケットが得られ、
   前記インターセプト手段は、未処理パケットを、分割前にインターセプトし、得られた複数の処理済パケットを、順次インターセプトし、
   前記算出手段は、得られた複数の処理済パケットのうち最終パケットがインターセプトされたときに生成された第２のタイムスタンプを用いて差分を算出することにより、プロトコル遅延の算出を完了する請求項２記載のプロトコル遅延測定装置。
4. 未処理パケットのサイズが所定値よりも大であることにより、未処理パケットがＩＰｓｅｃ処理前に複数の分割パケットに分割され、
   順次インターセプトされた複数の処理済パケットのサイズを、積算値が未処理パケットのサイズに到達するまで順次積算し、最後に積算された処理済パケットを最終パケットを判定する判定手段をさらに有する請求項３記載のプロトコル遅延測定装置。
5. 得られた複数の処理済パケットはそれぞれ、得られた複数の処理済パケットの最終パケットであるか否かを示すフラグを有し、
   順次インターセプトされた複数の処理済パケットに含まれるフラグを参照し、最終パケットである旨を示すフラグを有する処理済パケットを最終パケットと判定する判定手段をさらに有する請求項３記載のプロトコル遅延測定装置。
6. 通信端末におけるＩＰｓｅｃ（Internet Protocol Security）処理によるプロトコル遅延を測定するプロトコル遅延測定方法であって、
   未処理パケット及び処理済パケットをインターセプトするステップと、
   前記未処理パケットがインターセプトされたときに第１のタイムスタンプを生成し、前記処理済パケットがインターセプトされたときに第２のタイムスタンプを生成するステップと、
   前記未処理パケットの識別子を生成する識別子生成ステップと、
   生成された前記識別子を、前記第１のタイムスタンプと共にデータベースに記憶させる記憶ステップと、
   生成された前記識別子を、前記通信端末においてＩＰｓｅｃ処理前後で同一に維持する記憶領域に書き込む書き込みステップと、
   前記記憶領域に書き込まれた前記識別子を読み出す読み出しステップと、
   読み出された前記識別子と同一の識別子と共に前記データベースに記憶させた前記第１のタイムスタンプを抽出する抽出ステップと、
   抽出された前記第１のタイムスタンプと、前記第２のタイムスタンプとの差分を、プロトコル遅延として算出する算出ステップと、
   を有するプロトコル遅延測定方法。

Images