(57)【要約】【課題】ＩＰｓｅｃパケットのリプレイ防止処理において、当該パケットに設定された優先度によって受信順序が入れ替わった場合でも、パケット廃棄を防ぐリプレイ防止処理を提供すること。【解決手段】受信処理部１３０は、受信パケットのうちでＩＰｓｅｃに保護された情報から当該パケットの優先度を求め、当該パケットの優先度に対応したリプレイ防止ウィンドウ１４１〜１４２を用いて当該パケットのリプレイ防止処理を行うことにより、優先度による受信順序が入れ替わった場合でも、パケット廃棄を防ぐリプレイ防止処理を行える。【選択図】図３
2006005425.tif 000002
【特許請求の範囲】
【請求項１】
セキュリティプロトコルによって値の書き換えから保護された保護領域を含むパケットを受信する受信処理方法であって、
前記パケットは、
前記セキュリティプロトコルが用いるセキュリティパラメータの組ごとに定まるシーケンス番号と、
通信経路上の中継装置において、前記パケットを転送する際の優先順位を示す優先度を含み、
前記保護領域は、
前記シーケンス番号と、
前記優先度を特定する優先度特定情報を含み、
前記受信処理方法は、
前記保護領域が書き換えられていないことを確認する認証ステップと、
前記優先度特定情報から前記パケットの優先度を特定する優先度特定ステップと、
パケットの優先度に対応させて設けた１つ以上のリプレイ防止ウィンドウから、前記優先度特定ステップにおいて特定した前記パケットの優先度に対応したリプレイ防止ウィンドウを選択するウィンドウ選択ステップと、
前記ウィンドウ選択ステップにおいて選択したリプレイ防止ウィンドウを用いて、前記パケットがリプレイ攻撃であるか否かを判定し、リプレイ攻撃である場合は前記パケットを廃棄するリプレイ防止処理ステップを含むこと、
を特徴とする受信処理方法。
【請求項２】
前記保護領域の一部または全てはさらにブロック暗号によって暗号化されており、
前記優先度特定ステップは、前記優先度特定情報を含むブロックと、前記優先度特定情報を含むブロックを特定するための情報を含むブロックのみを復号し、前記優先度特定情報を得ること、
を特徴とする請求項１記載の受信処理方法。
【請求項３】
前記優先度特定情報は、前記保護領域に含まれる第３層ヘッダに含まれる情報と第４層ヘッダに含まれる情報のいずれかまたは双方であること、
を特徴とする請求項１または請求項２記載の受信処理方法。
【請求項４】
前記パケットは、第１のヘッダと第１のデータから構成される第１のパケットを、前記第１のヘッダと同じレイヤーのヘッダである第２のヘッダによってカプセル化されたパケットであって、
前記保護領域は前記第１のパケットを含み、
前記優先度特定情報は、前記第１のヘッダに含まれる優先度情報であること、
を特徴とする請求項１または請求項２記載の受信処理方法。
【請求項５】
前記リプレイ防止ウィンドウのウィンドウサイズは、優先度の高いものほど大きいこと、を特徴とする請求項１〜請求項４のいずれか１項に記載の受信処理方法。
【請求項６】
前記リプレイ防止ウィンドウのウィンドウサイズは、優先度の高いものほど小さいこと、を特徴とする請求項１〜請求項４のいずれか１項に記載の受信処理方法。
【請求項７】
前記受信処理方法は、
演算用リソースの使用量が第１の閾値を超える場合、優先度の低い前記リプレイ防止ウィンドウのウィンドウサイズを縮小するウィンドウ縮小ステップを含むこと、
を特徴とする請求項１〜請求項６のいずれか１項に記載の受信処理方法。
【請求項８】
前記受信処理方法は、
前記演算用リソースの使用量が第２の閾値を下回った場合、前記縮小したウィンドウサイズを元のサイズに戻すこと、
を特徴とする請求項７記載の受信処理方法。
【請求項９】
前記演算用リソースは受信処理を行うＣＰＵ負荷であること、
を特徴とする請求項７または請求項８記載の受信処理方法。
【請求項１０】
前記演算用リソースは、受信処理を開始するまで受信したパケットをキューイングする受信キューにキューイングされたパケット数であること、
を特徴とする請求項７または請求項８記載の受信処理方法。
【請求項１１】
前記演算用リソースは、受信処理を行うための作業用メモリ量であること、
を特徴とする請求項７または請求項８記載の受信処理方法。
【請求項１２】
前記セキュリティプロトコルはＩＰｓｅｃであること、
を特徴とする請求項１〜請求項１１のいずれか１項に記載の受信処理方法。
【請求項１３】
セキュリティプロトコルによって値の書き換えから保護された保護領域を含むパケットを受信する受信処理装置であって、
前記パケットは、
前記セキュリティプロトコルが用いるセキュリティパラメータの組ごとに定まるシーケンス番号と、
通信経路上の中継装置において、前記パケットを転送する際の優先順位を示す優先度を含み、
前記保護領域は、
前記シーケンス番号と、
前記優先度を特定する優先度特定情報を含み、
前記受信処理装置は、
前記セキュリティパラメータを蓄積するセキュリティデータベースと、
前記優先度特定情報と前記パケットの優先度の対応を蓄積する優先度決定データベースと、
前記パケットの受信処理を行う受信処理部を備え、
前記受信処理部は、
前記セキュリティデータベースが保持するセキュリティパラメータを用いて、前記パケットに含まれる保護領域が書き換えられていないことを確認する認証手段と、
前記優先度特定情報をキーに前記優先度決定データベースを検索し、前記パケットの優先度を求める優先度特定手段と、
１つ以上のリプレイ防止ウィンドウから、前記優先度特定手段において求めた優先度に対応した前記リプレイ防止ウィンドウを選択するウィンドウ選択手段と、
前記ウィンドウ選択手段において選択したリプレイウィンドウを用いて、前記パケットがリプレイ攻撃によるものか否かを判断し、リプレイ攻撃によるものであれば前記パケットを廃棄するリプレイ防止手段を備えること、
を特徴とする受信処理装置。
【請求項１４】
前記保護領域の一部または全てはブロック暗号によって暗号化されており、
前記優先度特定手段は、
前記優先度特定情報を含むブロックと、前記優先度特定情報を含むブロックを特定するための情報を含むブロックを、前記セキュリティパラメータを用いて復号することによって前記優先度特定情報を得ること、
を特徴とする請求項１３記載の受信処理装置。
【請求項１５】
前記優先度特定情報は、第３層ヘッダに含まれる情報と第４層ヘッダに含まれる情報のいずれかまたは双方であること、
を特徴とする請求項１３または請求項１４記載の受信処理装置。
【請求項１６】
前記パケットは、第１のヘッダと第１のデータから構成される第１のパケットを前記第１のヘッダと同じレイヤーのヘッダである第２のヘッダによってカプセル化されたパケットであり、
前記保護領域は前記第１のパケットを含み、
前記優先度特定情報は、前記第１のヘッダに含まれる優先度情報であること、
を特徴とする請求項１３または請求項１４記載の受信処理装置。
【請求項１７】
前記リプレイ防止ウィンドウのウィンドウサイズは、優先度の高いものほど大きいこと、を特徴とする請求項１３〜請求項１６のいずれか１項に記載の受信処理装置。
【請求項１８】
前記リプレイ防止ウィンドウのウィンドウサイズは、優先度の低いものほど大きいこと、を特徴とする請求項１３〜請求項１６のいずれか１項に記載の受信処理装置。
【請求項１９】
前記受信処理装置はさらに、前記受信処理装置が保有する演算用リソースの使用量を監視し、前記演算用リソースの使用量が第１の閾値を超えた場合にこれを通知するリソース監視部を備え、
前記受信処理部は、前記リソース監視部からの通知を受けると、優先度の低いリプレイ防止ウィンドウのウィンドウサイズを縮小すること、
を特徴とする請求項１３〜請求項１８のいずれか１項に記載の受信処理装置。
【請求項２０】
前記リソース監視部は、前記演算用リソースの使用量が第２の閾値を下回った場合にこれを通知し、
前記受信処理部は、前記リソース監視部からの通知を受けると、優先度の低いリプレイ防止ウィンドウのウィンドウサイズを元のサイズに戻すこと、
を特徴とする請求項１９記載の受信処理装置。
【請求項２１】
前記演算用リソースは、受信処理を行うＣＰＵのＣＰＵ負荷であること、
を特徴とする請求項１９または請求項２０記載の受信処理装置。
【請求項２２】
前記受信処理装置は、受信処理を開始するまで受信したパケットをキューイングする受信キューを備え、
前記演算用リソースは、前記受信キューにキューイングされたパケット数であること、
を特徴とする請求項１９または請求項２０記載の受信処理装置。
【請求項２３】
前記演算用リソースは、受信処理を行う作業用メモリ量であること、
を特徴とする請求項１９または請求項２０記載の受信処理装置。
【請求項２４】
前記セキュリティプロトコルはＩＰｓｅｃであること、
を特徴とする請求項１３〜請求項２３のいずれか１項に記載の受信処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、暗号化されたパケットを受信する際の受信方法に関するものである。
【背景技術】
【０００２】
近年、パーソナルコンピュータやインターネットの普及により、インターネット上で公開されるホームページによる容易かつ安価な情報提供や情報収集が可能になってきている。また、インターネットや企業間のイントラネットを介した電子メールの交換や、映像・音声の配信、電子商取引や電子決済が一般化しつつある。このようなサービスを利用する場合、特に重要な情報を含む通信や、個人のプライバシーに関わる情報の通信には専用線並みのセキュリティ確保が求められる。
【０００３】
上述したようなセキュリティを確保する技術の一例として、ＩＰｓｅｃが挙げられる。ＩＰｓｅｃとは、ネットワーク層（ＯＳＩ参照モデル第３層）で暗号化、認証を行うセキュリティプロトコルであって、インターネット技術標準委員会（ＩＥＴＦ）で標準化されている（ＲＦＣ２４０１〜２４１２、２４５１）。
【０００４】
ＩＰｓｅｃ機能を搭載したコンピュータやルータ等のネットワーク接続機器を介してインターネットに接続することで、インターネットのような広域ネットワーク上に仮想私設網（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ；ＶＰＮ）を構築できる。つまり、ユーザが暗号化等の特別な処理を実施することなく、安全にインターネットを利用することができる。
【０００５】
ＩＰｓｅｃを利用した通信を行うにあたっては、どのような暗号化アルゴリズムや認証アルゴリズムを使用するか、どのような暗号鍵や認証鍵を使用するかなどを事前に送信側と受信側のＩＰｓｅｃ機能を搭載したコンピュータやネットワーク接続装置間で一致させなければならない。この暗号化、認証アルゴリズム等をセキュリティパラメータと呼び、暗号化アルゴリズム、暗号鍵、認証アルゴリズム、認証鍵、ＳＰＩ値（Ｓｅｃｕｒｉｔｙ  Ｐａｒａｍｅｔｅｒ  Ｉｎｄｅｘ）、プロトコル（ＥＳＰやＡＨ）、モード（トランスポート、トンネル）等から構成される。このセキュリティパラメータ値を一致させるためにＩＫＥ（Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ）と呼ばれるアプリケーションが相互通信を行う。相互通信の結果、送信側と受信側で一致させたセキュリティパラメータ値は、ＳＡ（Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｃｉｓａｔｉｏｎ）と呼ばれる枠組みによって保持され、ＩＰｓｅｃ処理部に通知される。なお、ＩＫＥを用いて相互通信を行う代わりに、何からの方法−例えば、送信側と受信側とが電話等を用いてセキュリティパラメータを通知しあう等−によって整合性のとれたＳＡを手動でそれぞれのＩＰｓｅｃ処理部に設定しても構わない。
【０００６】
ＩＰｓｅｃ処理を行う機能部はこのＳＡで規定された暗号化アルゴリズムや認証アルゴリズム、暗号鍵、認証鍵等に基づいて、送信するＩＰパケットをＩＰｓｅｃパケットに変換したり、受信したＩＰｓｅｃパケットをＩＰパケットに復元したりすることで通信を行う。
【０００７】
またＩＰｓｅｃには、リプレイ攻撃を防御するための仕組みが備えられている。リプレイ攻撃とは、やりとりされているＩＰパケットを通信経路上で取り込み、そのコピーを通信経路上に送信する攻撃である。やりとりされているＩＰパケットは、本来、正常に受信されるはずのＩＰパケットであるため、リプレイ攻撃によって、受信側の端末の処理負荷を増加させることができる。このリプレイ攻撃を防御するために、ＩＰｓｅｃでは以下のリプレイ防止処理を行う。まず、ＩＰｓｅｃパケットを送信する装置では、ＩＰｓｅｃヘッダ内にセキュリティパラメータごとに定まるシーケンス番号を付与する。ＩＰｓｅｃパケットを受信する装置では、受信したＩＰｓｅｃパケットに含まれるシーケンス番号が以前受信したものと重複していないことを確認する。もしシーケンス番号が重複している場合、このパケットがリプレイ攻撃によるものであると判断し、同パケットを廃棄する。ここで、シーケンス番号の重複を調べるために、それまでに受信した全てのＩＰｓｅｃパケットのシーケンス番号を記憶すると、非常に大きな記憶容量が必要となり、現実的でない。そこで、ＩＰｓｅｃでは受信したパケットのうちで、最大のシーケンス番号から一定数以内のシーケンス番号を持つパケットの受信の有無をリプレイ防止ウィンドウとして記憶する。
【０００８】
では、受信したＩＰｓｅｃパケットについてリプレイ防止処理を行う受信処理装置の一例を図９および図１０を用いて説明する。
【０００９】
まず図９を用いてネットワーク構成を説明する。図９において、６００は従来の受信処理装置、２００は中継装置、７００は対向の暗号通信装置、８００はリプレイ攻撃を行う攻撃端末である。暗号通信装置７００は、ＩＰｓｅｃパケットを従来の受信処理装置６００に送信し、従来の受信処理装置６００はこれを受信して、リプレイ防止処理を含むＩＰｓｅｃの受信処理を行う。ここでは暗号通信装置７００はＰ１、Ｐ２の順にＩＰｓｅｃパケットを送信する。Ｐ１〜Ｐ２のシーケンス番号は順に１０１、１０３である。また、攻撃端末８００はＰ１のリプレイ攻撃であるＰ３（シーケンス番号はＰ１と同じ１０１）を従来の受信処理装置６００に対して送信する。この結果、従来の受信処理装置６００は、Ｐ１、Ｐ２、Ｐ３の順にパケットを受信するものとする。
【００１０】
次に、従来の受信処理装置６００の構成の一例を、図１０を用いて説明する。図１０において、６１０はパケットを受信するためのネットワークＩ／Ｆ、６２０は受信キュー、６３０は受信したパケットの受信処理を行う受信処理部、６４０は受信パケットに対応したリプレイ防止ウィンドウであり、説明の簡単化のためにウィンドウサイズを３とする。６５０は受信パケットのセキュリティパラメータを蓄積したＳＡＤＢ（セキュリティアソシエーションデータベース）である。ここで、従来の受信処理装置６００がＩＰｓｅｃパケットを受信すると、受信処理部６３０はネットワークＩ／Ｆ６１０と受信キュー６２０を介してＩＰｓｅｃパケットを受け取り、当該パケットに含まれるＡＨヘッダまたはＥＳＰヘッダからＳＰＩ値を取り出し、これを検索キーとしてＳＡＤＢ６５０を検索する。検索の結果、ＳＰＩ値に対応した暗号アルゴリズムや、暗号鍵、認証アルゴリズム、認証鍵などのセキュリティパラメータと共に、ＳＰＩ値に対応したリプレイ防止ウィンドウ６４０を獲得する。次いで、セキュリティパラメータを用いてＩＰｓｅｃパケットの復号処理や認証処理を行って、通常のＩＰパケットに復元するための受信処理を行う。この受信処理の際に行うリプレイ防止処理について、図１１を用いて説明する。
【００１１】
図１１はリプレイ防止ウィンドウ６４０の状態を示した図面である。図１１において、１は受信済みであることを、０は受信していないことを示す。図１１（ａ）はパケットＰ１〜Ｐ３を受信する前の状態を示しており、シーケンス番号１００、１０２のＩＰｓｅｃパケットを受信しており、シーケンス番号１０１のＩＰｓｅｃパケットを受信していないことを示している。
【００１２】
リプレイ防止ウィンドウ６４０が図１１（ａ）の場合に、シーケンス番号９９以下のＩＰｓｅｃパケットを受信した場合、リプレイ防止ウィンドウ６４０の管理外のため、そのパケットは廃棄される。また、リプレイ防止ウィンドウ６４０においてすでに受信済みであるパケット（図ではシーケンス番号１００と１０２）を受信すると、そのパケットはリプレイ攻撃であると判断され、廃棄される。
【００１３】
ここでまずパケットＰ１（シーケンス番号１０１）を受信すると、当該シーケンス番号はリプレイ防止ウィンドウ６４０で管理されており、かつ受信していない状態であるので、当該パケットは正常に受信され、リプレイ防止ウィンドウ６４０は図１１（ｂ）のように更新される。
【００１４】
次にパケットＰ２（シーケンス番号１０３）を受信すると、当該シーケンス番号はリプレイ防止ウィンドウ６４０で管理されている最大のシーケンス番号１００よりも大きいので、ウィンドウをスライドし、図１１（ｃ）のように更新して正常に受信される。
【００１５】
最後に、パケットＰ１のリプレイ攻撃であるパケットＰ３（シーケンス番号１０１）を受信すると、当該シーケンス番号はリプレイ防止ウィンドウ６４０で管理されているが、すでに受信済みであるため、当該パケットは廃棄される。当該パケットが廃棄された場合、リプレイ防止ウィンドウ６４０の状態は変化せず、図１１（ｃ）のままである。
【００１６】
以上示したように、パケットの入れ替わりが限定されている場合においては、リプレイ防止ウィンドウを用いることで、効果的なリプレイ防止処理を行うことができる。
【非特許文献１】標準仕様書「ＲＦＣ２４０１」、ＩＥＴＦ、〔平成１６年３月８日検索〕、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/2401.txt＞
【非特許文献２】標準仕様書「ＲＦＣ２４０２」、ＩＥＴＦ、〔平成１６年３月８日検索〕、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/2402.txt＞
【非特許文献３】標準仕様書「ＲＦＣ２４０６」、ＩＥＴＦ、〔平成１６年３月８日検索〕、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/2406.txt＞
【非特許文献４】標準仕様書「ＲＦＣ２４７５」、ＩＥＴＦ、〔平成１６年３月８日検索〕、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/2475.txt＞
【発明の開示】
【発明が解決しようとする課題】
【００１７】
ところで、ＩＰｓｅｃパケットはＩＰパケットの一種であるため、ＩＰｓｅｃパケットに含まれるＩＰヘッダ内に優先度情報が設定されている場合、当該ＩＰｓｅｃパケットは、通常のＩＰパケットと同様に通信経路上のルータ装置等によって上記優先度情報に基づいて転送処理の優先制御が行われる。このような優先制御を行う技術の一例としてＲＦＣ２４７５で規定されたＤｉｆｆＳｅｒｖがある。ＤｉｆｆＳｅｒｖでは、優先度情報としてＩＰヘッダ内のＴＯＳフィールドに設定された値を使用し、ＴＯＳフィールド値に基づいて転送すべきパケットの転送順序を制御する。よってＤｉｆｆＳｅｒｖに対応した中継装置は、転送すべき複数のパケットのうち、ＴＯＳフィールドに優先度の高い値が設定されたパケットを、優先度の低い値が設定されたパケットよりも優先的に転送する。その結果、ＩＰｓｅｃパケットを送信する装置が送信した順序と、ＩＰｓｅｃパケットを受信する装置が受信する順序が、ＩＰｓｅｃパケット内の優先度情報に応じて変化する。しかしながら、前記従来の構成では、リプレイ防止ウィンドウは１つのＳＡにつき１つしか存在しないため、ＩＰヘッダ内の優先度情報に基づいて受信順序が入れ替わった場合、リプレイ攻撃によるパケットでないにもかかわらず、リプレイ防止処理によって当該パケットを廃棄してしまう場合があった。以下にこの問題について説明する。
【００１８】
図９において、暗号通信装置７００が従来の受信処理装置６００に対して、Ｐ１１、Ｐ１２、Ｐ１３、Ｐ１４の順にＩＰｓｅｃパケットを送信するものとする。Ｐ１１〜Ｐ１４のシーケンス番号はそれぞれ１００、１０１、１０２、１０３であり、優先度はそれぞれ２、１、１、１である。優先度１は優先度が高いことを、優先度２は優先度が低いことを表す。この場合、パケットＰ１は優先度が低いため中継装置２００において転送が遅延し、従来の受信処理装置６００はＰ１２、Ｐ１３、Ｐ１４、Ｐ１１の順にパケットを受信する。この結果、パケットＰ１４を受信した後のリプレイ防止ウィンドウ６４０は図１１（ｃ）と等しくなる。その後Ｐ１１（シーケンス番号１００）を受信すると、当該シーケンス番号はリプレイ防止ウィンドウ６４０の管理外のため、リプレイ攻撃によるパケットでないにもかかわらず、Ｐ１１は廃棄されてしまう。
【００１９】
このように、従来の受信処理装置では、パケットに設定された転送処理の優先度によってパケットの受信順序が入れ替わった場合に、リプレイ攻撃によるパケットでないにもかかわらず、当該パケットを廃棄してしまう場合があった。本発明は、前記従来の課題を解決するもので、転送処理の優先制御によってＩＰｓｅｃパケットの到着順序が入れ替わった場合においても、パケット廃棄を防ぐリプレイ防止処理を備えた暗号通信装置を提供することを目的とする。
【課題を解決するための手段】
【００２０】
前記従来の課題を解決するために、本発明の請求項１に記載の受信処理方法は、受信パケットに含まれる保護領域が書き換えられていないことを確認する認証ステップと、受信パケットの優先度を優先度特定情報から特定する優先度特定ステップと、複数のリプレイ防止ウィンドウから受信パケットの優先度に対応したリプレイ防止ウィンドウを選択するウィンドウ選択ステップと、選択したリプレイ防止ウィンドウを用いて受信パケットがリプレイ攻撃であるか否かを判断し、リプレイ攻撃であれば前記パケットを破棄するリプレイ防止処理ステップを含む。
【００２１】
本発明の請求項１によれば、受信パケットに含まれる転送処理の優先度によって受信順序が入れ替わっても、パケット廃棄を防ぐリプレイ防止処理を行うことが可能となる。
【００２２】
また本発明の請求項２に記載の受信処理方法における優先度特定ステップは、受信パケット内の保護領域の一部または全てがブロック暗号によって暗号化されていても、優先度特定情報を含むブロックと、優先度特定情報を含むブロックを特定するために必要な情報を含むブロックのみを復号することにより、前記受信パケットの優先度特定情報を獲得する。
【００２３】
本発明の請求項２によれば、優先度特定情報がブロック暗号によって暗号化されていても、全てのブロックを復号することなく、前記受信パケットのリプレイ防止処理を行うことが可能となる。
【００２４】
また本発明の請求項３に記載の受信処理方法は、受信パケットの優先度特定情報として第３層ヘッダ内の情報と、第４層ヘッダ内の情報のいずれかまたは双方を用いる。
【００２５】
本発明の請求項３によれば、第３層ヘッダに含まれる情報と第４層ヘッダに含まれる情報を用いて、優先度に対応したリプレイ防止処理を行うことが可能となる。
【００２６】
また本発明の請求項４に記載の受信処理方法は、第１のヘッダと第１のデータからなる第１のパケットを第２のヘッダによってカプセル化したパケットを受信した場合、当該受信パケットの第１のヘッダに含まれる優先度情報から当該パケットの優先度を特定するステップを含む。
【００２７】
本発明の請求項４によれば、カプセル化されたパケットのヘッダに含まれる優先度情報を用いて、優先度に対応したリプレイ防止処理を行うことが可能となる。
【００２８】
また本発明の請求項５に記載の受信処理方法は、優先度の高いものほどウィンドウサイズが大きいリプレイ防止ウィンドウを用いる。
【００２９】
本発明の請求項５によれば、経路途中のルータによってパケットの遅配が発生しても、優先度の高いパケットを誤って廃棄することを防ぐことが可能となる。
【００３０】
また本発明の請求項６に記載の受信処理方法は、優先度の高いものほどウィンドウサイズが小さいリプレイ防止ウィンドウを用いる。
【００３１】
本発明の請求項６によれば、リアルタイム性を要するパケットにもかかわらず、大きく遅延した高優先度のパケットを廃棄することで、処理負荷を低減させることが可能となる。
【００３２】
また本発明の請求項７に記載の受信処理方法は、演算に用いるリソースの使用量が一定の閾値を超える場合、優先度の低いリプレイ防止ウィンドウのウィンドウサイズを縮小するステップを含む。
【００３３】
本発明の請求項７によれば、演算用リソースの使用量が多くなった場合、優先度の低いパケットを廃棄しやすくすることにより、リソースの使用量を減少させることが可能となる。
【００３４】
また本発明の請求項８に記載の受信処理方法は、演算に用いるリソースの使用量が一定の閾値以下となった場合、一旦縮小したリプレイ防止ウィンドウのウィンドウサイズを元のサイズに戻すステップを含む。
【００３５】
本発明の請求項８によれば、演算用リソースの使用量が減少した場合、パケット廃棄を抑えることが可能となる。
【００３６】
また本発明の請求項９に記載の受信処理方法は、受信処理を行うＣＰＵ負荷が一定の閾値以下の場合にリプレイ防止ウィンドウのウィンドウサイズを縮小し、一定の閾値以上の場合に縮小したウィンドウサイズを元に戻すステップを含む。
【００３７】
本発明の請求項９によれば、ＣＰＵ負荷が上昇した場合は低優先度のパケットを廃棄しやすくすることによってＣＰＵ負荷を低減し、ＣＰＵ負荷が減少した場合は低優先度のパケットも廃棄しないようにリプレイ防止処理を行うことが可能となる。
【００３８】
また本発明の請求項１０に記載の受信処理方法は、受信キューにキューイングされたパケット数が第１の閾値以下の場合にリプレイ防止ウィンドウのウィンドウサイズを縮小し、第２の閾値以上の場合に縮小したウィンドウサイズを元に戻すステップを含む。
【００３９】
本発明の請求項１０によれば、受信キューにキューイングされたパケット数が増加した場合には、低優先度のパケットを廃棄しやすくすることによって処理負荷を削減し、パケット数が減少した場合には低優先度のパケットも廃棄しないようにリプレイ防止処理を行うことが可能となる。
【００４０】
また本発明の請求項１１に記載の受信処理方法は、受信処理に用いる作業用メモリ量が第１の閾値以下の場合にリプレイ防止ウィンドウのウィンドウサイズを縮小し、第２の閾値以上の場合に縮小したウィンドウサイズを元に戻すステップを含む。
【００４１】
本発明の請求項１１によれば、受信処理に用いる作業用メモリ量が増加した場合には、低優先度のパケットを廃棄しやすくすることによって処理負荷を削減し、作業用メモリ量が減少した場合には低優先度のパケットも廃棄しないようにリプレイ防止処理を行うことが可能となる。
【００４２】
また本発明の請求項１２に記載の受信処理方法は、ＩＰｓｅｃによって保護されたパケットを受信する場合のリプレイ防止処理を行う。
【００４３】
本発明の請求項１２によれば、受信パケットに含まれる優先度によって受信順序が入れ替わったＩＰｓｅｃパケットに対しても、正しくリプレイ防止処理を行うことができる。
【００４４】
また本発明の請求項１３に記載の受信処理装置は、セキュリティパラメータを蓄積するセキュリティデータベースと、受信パケットに含まれる優先度情報と前記パケットの優先度の対応を保持する優先度決定データベースと、前記パケットの受信処理を行う受信処理部を備え、受信処理部は、前記パケットの保護領域が書き換えられていないことを確認する認証手段と、優先度特定情報をキーに優先度決定データベースを検索して前記パケットの優先度を特定する優先度特定手段と、各優先度に対応したリプレイ防止ウィンドウから優先度特定手段が特定した優先度に対応するリプレイ防止ウィンドウを選択するウィンドウ選択手段と、ウィンドウ選択手段で選択したリプレイ防止ウィンドウを用いて、前記パケットがリプレイ攻撃によるものか否かを判断し、リプレイ攻撃によるパケットであれば前記パケットを破棄するリプレイ防止手段を備える。
【００４５】
本発明の請求項１３によれば、受信パケットに含まれる優先度によって受信順序が変動しても、誤ったパケット廃棄を防ぐことが可能な受信処理装置を実現できる。
【００４６】
また本発明の請求項１４に記載の受信処理装置の優先度特定手段は、保護領域の一部または全てがブロック暗号によって暗号化された受信パケットについて、優先度特定情報を含むブロックと、優先度特定情報を含むブロックを特定するための情報を含むブロックのみを復号することで、優先度特定情報を得る。
【００４７】
本発明の請求項１４によれば、優先度特定情報が暗号化されていても、受信パケットすべてを復号することなく、受信パケットのリプレイ防止処理を行うことが可能な受信処理装置を実現できる。
【００４８】
また本発明の請求項１５に記載の受信処理装置は、受信パケットに含まれる第３層ヘッダ内の情報と第４層ヘッダ内の情報のいずれかまたは双方から、受信パケットの優先度を特定する。
【００４９】
本発明の請求項１５によれば、第３層ヘッダに含まれる情報と第４層ヘッダに含まれる情報を用いて、優先度に対応したリプレイ防止処理を行うことが可能となる。
【００５０】
また本発明の請求項１６に記載の受信処理装置は、第１のヘッダと第２のデータからなる第１のパケットを第１のヘッダと同じレイヤーに属するヘッダである第２のヘッダによってカプセル化したパケットを受信した場合、前記受信パケットの第１のヘッダに含まれる優先度情報から前記パケットの優先度を特定する。
【００５１】
本発明の請求項１６によれば、カプセル化されたパケットのヘッダに含まれる優先度情報から前記受信パケットの優先度を特定する受信処理装置を実現できる。
【００５２】
また本発明の請求項１７に記載の受信処理装置は、優先度の高いものほどウィンドウサイズが大きいリプレイ防止ウィンドウを用いてリプレイ防止処理を行う受信処理部を備える。
【００５３】
本発明の請求項１７によれば、経路途中のルータによってパケットの遅配が発生しても、優先度の高いパケットを誤って廃棄することを防ぐことが可能な受信処理装置を実現できる。
【００５４】
また本発明の請求項１８に記載の受信処理装置は、優先度の高いものほどウィンドウサイズが小さいリプレイ防止ウィンドウを用いてリプレイ防止処理を行う受信処理部を備える。
【００５５】
本発明の請求項１８によれば、厳密なリアルタイム性を要するパケットにもかかわらず、大きく遅延した高優先度のパケットを廃棄することで、処理負荷を低減させることが可能な受信処理装置を実現できる。
【００５６】
また本発明の請求項１９に記載の受信処理装置は、演算に用いるリソースの使用量が一定の閾値を超える場合にこれを通知するリソース監視部と、この通知を受けると優先度の低いリプレイ防止ウィンドウのウィンドウサイズを縮小する受信処理部を備える。
【００５７】
本発明の請求項１９によれば、演算用リソースの使用量が多くなった場合、優先度の低いパケットを廃棄しやすくし、リソースの使用量を減少させることが可能な受信処理装置を実現できる。
【００５８】
また本発明の請求項２０に記載の受信処理装置は、演算に用いるリソースの使用量が一定の閾値を下回る場合にこれを通知するリソース監視部と、この通知を受けると一旦縮小した優先度の低いリプレイ防止ウィンドウのウィンドウサイズを、元のサイズに戻す受信処理部を備える。
【００５９】
本発明の請求項２０によれば、演算用リソースの使用量が減少した場合、優先度の低いパケットの廃棄を抑えることが可能な受信処理装置を実現できる。
【００６０】
また本発明の請求項２１に記載の受信処理装置は、受信処理を行うＣＰＵ負荷の値が一定の閾値を上回る場合や下回る場合にこれを通知するリソース監視部と、この通知を受けると優先度の低いリプレイ防止ウィンドウのウィンドウサイズを縮小、または元のサイズに戻す受信処理部を備える。
【００６１】
本発明の請求項２１によれば、ＣＰＵ負荷が大きい場合には低優先度のパケットを廃棄しやすくすることでＣＰＵ負荷を下げ、ＣＰＵ負荷が小さい場合には低優先度のパケットも廃棄しにくくする受信処理装置を実現できる。
【００６２】
また本発明の請求項２２に記載の受信処理装置は、受信処理を開始するまで受信したパケットをキューイングする受信キューと、受信キューの長さが一定の閾値を上回る場合や下回る場合にこれを通知するリソース監視部と、この通知を受けると優先度の低いリプレイ防止ウィンドウのウィンドウサイズを縮小、または元のサイズに戻す受信処理部を備える。
【００６３】
本発明の請求項２２によれば、受信キューにキューイングされたパケット数が多い場合に低優先度のパケットを廃棄しやすくすることで処理負荷を低減し、パケット数が少なくなった時点で低優先度のパケットも廃棄しにくくする受信処理装置を実現できる。
【００６４】
また本発明の請求項２３に記載の受信処理装置は、受信処理に要する作業用メモリ量が一致の閾値を上回る場合や下回る場合にこれを通知するリソース監視部と、この通知を受けると優先度の低いリプレイ防止ウィンドウのウィンドウサイズを縮小、または元のサイズに戻す受信処理部を備える。
【００６５】
本発明の請求項２３によれば、受信処理に要する作業メモリ量が増加した場合に低優先度のパケットを廃棄しやすくすることで処理負荷を低減し、作業メモリ量が減少した場合に低優先度のパケットも廃棄しにくくする受信処理装置を実現できる。
【００６６】
また本発明の請求項２４に記載の受信処理装置は、ＩＰｓｅｃにより保護されたパケットの受信処理を行う受信処理部を備える。
【００６７】
本発明の請求項２４によれば、受信パケットに含まれる優先度によって受信順序が入れ替わったＩＰｓｅｃパケットに対しても、正しくリプレイ防止処理を行うことが可能な受信処理装置を実現できる。
【発明の効果】
【００６８】
以上のように、本発明の受信処理方法は、パケットに含まれる優先度によって受信順序が変動しても、その受信順序の変動による影響を取り除くことができ、低優先度のパケットの廃棄を防ぐことが可能となる。
【発明を実施するための最良の形態】
【００６９】
以下本発明の実施の形態について、図面を参照しながら説明する。
【００７０】
（実施の形態１）
図１は、本発明の実施の形態１に係る受信処理装置を含むネットワーク構成を示す図面である。図１において、１００は本実施の形態に係る受信処理装置であり１３２．１８２．１．１０のＩＰアドレスを備える。２００はルータ等のネットワーク中継装置である。４００は映像や音声情報等のリアルタイム処理を要するパケットを受信処理装置１００に送信する第１のサーバ装置であり、１３２．１８２．３．１０のＩＰアドレスを備える。５００は電子メール等のリアルタイム処理を要しないパケットを受信処理装置１００に送信する第２のサーバ装置であり、１３２．１８２．３．１１のＩＰアドレスを備える。３００は第１のサーバ装置ならびに第２のサーバ装置が受信処理装置１００宛に送信したパケットを一旦受け取り、暗号化して受信処理装置１００に送信するセキュリティゲートウェイである。セキュリティゲートウェイ３００は、第１のサーバ装置４００や第２のサーバ装置５００とのパケット送受信のために１３２．１８２．３．１のＩＰアドレスを備え、また受信処理装置１００とのパケット送受信のために１３２．１８２．２．１０のＩＰアドレスを備える。
【００７１】
第１のサーバ装置４００は、映像データを、第４層のプロトコルがＵＤＰ、宛先ポート番号が２０００であるＩＰパケットとして受信処理装置１００に送信する。同様に、第２のサーバ装置５００は、電子メールのデータを、第４層のプロトコルがＴＣＰ、宛先ポート番号が３０００であるＩＰパケットとして受信処理装置１００に送信する。
【００７２】
次に、セキュリティゲートウェイ３００を介して、受信処理装置１００が第１のサーバ装置４００および第２のサーバ装置５００から受信するパケットを、図２を用いて説明する。受信処理装置１００とセキュリティゲートウェイ３００との間の通信にはＳＡが設定されており、ＩＰｓｅｃによる暗号化通信が行われる。ここでの暗号化に用いられるＳＡは、ＳＰＩが１０００、暗号アルゴリズムがＤＥＳ−ＣＢＣ、暗号鍵が“ａｂｃｄｅｆｇｈ”、認証アルゴリズムがＨＭＡＣ−ＭＤ５、認証鍵が“ＯＰＱＲＳＴＵＶＷ”である。この結果、第１のサーバ装置４００が受信処理装置１００に送信したＩＰパケットは、セキュリティゲートウェイ３００によって、図２（ａ）に示すＩＰｓｅｃパケットとして、受信処理装置１００に送信される。以下、このＩＰｓｅｃパケットをパケットＨと示す。図２（ａ）において、パケットＨは第２のＩＰヘッダ、ＥＳＰヘッダ、ＩＶ、第１のＩＰヘッダ、第４層プロトコルヘッダ、ペイロード、ＥＳＰトレーラ、ＩＣＶから構成される。第１のＩＰヘッダ、第４層プロトコルヘッダ、ペイロードの部分が第１のサーバ装置４００が送信したパケットである。セキュリティゲートウェイ３００は第２のＩＰヘッダを付加してパケットをカプセル化すると共に、ＥＳＰヘッダ、ＥＳＰトレーラ、ＩＣＶを付加して、元のＩＰパケット全体をＩＰｓｅｃにより保護する。その結果、ＥＳＰヘッダからＥＳＰトレーラまでが認証アルゴリズム（ＨＭＡＣ−ＭＤ５）によって値の書き換えから保護され、第１のＩＰヘッダからＥＳＰトレーラまでが暗号アルゴリズム（ＤＥＳ−ＣＢＣ）によって暗号化される。第２のＩＰヘッダは送信元ＩＰアドレスが１３２．１８２．２．１０、宛先ＩＰアドレスが１３２．１８２．１．１０であり、ＴＯＳフィールド値にはＩＰｓｅｃ仕様によって、後述する第１のＩＰヘッダのＴＯＳフィールド値と同じ値である１が設定される。ＥＳＰヘッダはシーケンス番号とＳＰＩから構成され、ＳＰＩは１０００であり、シーケンス番号は送信された順に連続した番号が振られる。ＩＶは暗号化の際に用いられた乱数が格納される。第１のＩＰヘッダは送信元ＩＰアドレスが１３２．１８２．３．１０、宛先ＩＰアドレスが１３２．１８２．１．１０、ＴＯＳフィールドが１である。第４層プロトコルヘッダはＵＤＰヘッダであり、宛先ポート番号には２０００が格納される。ペイロードには映像データが格納される。ＥＳＰトレーラは第４層プロトコルのプロトコル種別を示す次ヘッダを含み、ここではＵＤＰが格納される。ＩＣＶには、認証範囲のデータを認証アルゴリズムに従って認証鍵（本実施の形態では“ＯＰＱＲＳＴＵＶＷ”）を用いて計算したハッシュ値が格納される。
【００７３】
同様に、第２のサーバ装置５００が受信処理装置１００に対して送信したＩＰパケットは、セキュリティゲートウェイ３００によって、図２（ｂ）に示すＩＰｓｅｃパケットとして、受信処理装置１００に送信される。以下、このＩＰｓｅｃパケットをパケットＬと示す。図２（ｂ）において、第２のサーバ装置５００が送信したパケットに相当する部分、ならびに暗号化された領域および認証によって保護された領域はパケットＨと同様であり、パケットＬの第２のＩＰヘッダの送信元ＩＰアドレスは１３２．１８２．２．１０、宛先ＩＰアドレスは１３２．１８２．１．１０、ＴＯＳフィールドは２である。第１のＩＰヘッダは送信元ＩＰアドレスが１３２．１８２．３．１１、宛先ＩＰアドレスが１３２．１８２．１．１０、ＴＯＳフィールドが２である。第４層プロトコルヘッダはＴＣＰヘッダであり、宛先ポート番号は３０００である。ペイロードには電子メール等のリアルタイム処理を要しないデータが格納され、ＥＳＰトレーラの次ヘッダにはＴＣＰが格納される。上記以外のＥＳＰヘッダ、ＩＶ、ＩＣＶの内容はパケットＨと同様である。
【００７４】
以上示したように、セキュリティゲートウェイ３００から送信されるＩＰｓｅｃパケットは、パケットＨとパケットＬとでは、以下に示す相違点がある。すなわち、第１のＩＰヘッダ内のＴＯＳフィールド値は、パケットＨが１であるのに対し、パケットＬが２である。また第２のＩＰヘッダ内の送信元ＩＰアドレスは、パケットＨが１３２．１８２．３．１０であるのに対し、パケットＬが１３２．１８２．３．１１である。また第２のＩＰヘッダ内のＴＯＳフィールド値は、パケットＨが１であるのに対し、パケットＬでは２である。また、第４層プロトコルヘッダは、パケットＨが宛先ポート番号２０００であるＵＤＰヘッダであり、パケットＬが宛先ポート番号３０００であるＴＣＰヘッダである。また、ＥＳＰトレーラ内の次ヘッダの値は、パケットＨがＵＤＰであるのに対し、パケットＬがＴＣＰである。
【００７５】
次に受信処理装置１００の構成を図３に示す。図３において、１１０はネットワークＩ／Ｆ、１２０は受信したＩＰｓｅｃパケットをキューイングするための受信キュー、１３０は受信したＩＰｓｅｃパケットの受信処理を行う受信処理部、１４０は受信したＩＰｓｅｃパケットに適用されたＳＡに対応したリプレイ防止ウィンドウであり、当該受信パケットの優先度に応じて１４１〜１４２から構成される。１５０はＳＡを蓄積するデータベースであるＳＡＤＢであり、１６０は受信したＩＰｓｅｃパケットの優先度を決定するためのデータベースである優先度決定ＤＢである。
【００７６】
ここで、ＳＡＤＢ１５０の構成を図４に示す。ＳＡＤＢ１５０は、構成要素としてＳＰＩ値、暗号アルゴリズム、暗号鍵、認証アルゴリズム、認証鍵、リプレイ防止ウィンドウの状態を備える。図４には１つのＳＡが登録されており、そのＳＰＩ値は１０００、暗号アルゴリズムはＤＥＳ−ＣＢＣ、暗号鍵は“ａｂｃｄｅｆｇｈ”、認証アルゴリズムはＨＭＡＣ−ＭＤ５、認証鍵は“ＯＰＱＲＳＴＵＶＷ”である。またリプレイ防止ウィンドウは優先度１および優先度２に対応したものが登録されており、優先度１のウィンドウはウィンドウサイズが３、シーケンス番号９４、９５、９６のパケットについて受信済みであり、優先度２のウィンドウはウィンドウサイズが３、シーケンス番号９７、９８、９９のパケットについて受信済みであることを示している。
【００７７】
また、優先度決定ＤＢ１６０の構成を図５に示す。図５において、優先度決定ＤＢ１６０は、第４層プロトコルのプロトコル種別、送信元ポート番号、宛先ポート番号、優先度の項目を備えており、少なくとも２つのエントリが登録されている。１つ目のエントリは、プロトコル種別がＵＤＰ、送信元ポート番号が“＊”（これは全ての送信元ポート番号を示す記号である）、宛先ポート番号が２０００、優先度が１であり、２つ目のエントリはプロトコル種別がＴＣＰ、送信元ポート番号が“＊”、宛先ポート番号が３０００、優先度が２である。
【００７８】
では次に、受信処理装置１００の受信処理時の動作について説明する。図１において、セキュリティゲートウェイ３００は、第２のサーバ装置５００から受信したパケット、ならびに第１のサーバ装置４００から受信したパケット４００をＩＰｓｅｃによって保護し、受信処理装置１００宛てのトンネルモードＩＰｓｅｃパケットＰ１〜Ｐ４を送信する。ここでパケットＰ４は第２のサーバ装置５００から生成したＩＰｓｅｃパケットであり、ＳＰＩ値は１０００、優先度は２、シーケンス番号は１００である。またパケットＰ１〜Ｐ３は第１のサーバ装置４００から生成したＩＰｓｅｃパケットであり、ＳＰＩ値は１０００、優先度は１、シーケンス番号は順に１０１、１０２、１０３である。セキュリティゲートウェイ３００は受信処理装置１００に向けて、Ｐ４、Ｐ１、Ｐ２、Ｐ３の順にパケットを送信する。
【００７９】
次に、パケットＰ１〜Ｐ４を受け取った中継装置２００は、パケットに含まれる優先度情報を参照し、パケットの優先度順に受信処理装置１００に転送する。すなわち、中継装置２００は受信処理装置１００宛てに、Ｐ１、Ｐ２、Ｐ３、Ｐ４の順にパケットを送信する。この結果、セキュリティゲートウェイ３００がＰ４、Ｐ１、Ｐ２、Ｐ３の順に送信したＩＰｓｅｃパケットを、受信処理装置１００はＰ１、Ｐ２、Ｐ３、Ｐ４の順に受信することとなる。では、受信処理装置１００がＰ１〜Ｐ４を受信した場合の受信動作を図６および図７を用いて説明する。
【００８０】
（初期状態）
まず初期状態において、受信処理装置１００はシーケンス番号が９４、９５、９６である３つのＩＰｓｅｃパケットＨと、９７、９８、９９である３つのＩＰｓｅｃパケットＬを受信しているものとする。したがってリプレイ防止ウィンドウ１４１および１４２は図７（ａ）に示す状態である。すなわち、優先度１に対応したリプレイ防止ウィンドウ１４１はシーケンス番号９４、９５、９６が受信済み、優先度２に対応したリプレイ防止ウィンドウ１４２はシーケンス番号９７、９８、９９が受信済みとして登録されている。
【００８１】
（パケットＰ１の受信）
パケットＰ１を受信すると、図６に示すフローチャートに従い、当該パケットの受信処理を行う。
【００８２】
＜ステップ１＞
ステップ１では受信したパケットの認証処理を行う。ネットワークＩ／Ｆ１１０によってパケットを受信すると、受信処理部１３０は受信キュー１２０を介して当該パケットを受け取る。次に、受信処理部１３０は当該パケットからＳＰＩ値を取り出し、ＳＰＩ値を検索キーとしてＳＡＤＢを検索する。検索の結果、ＳＰＩ値に対応した暗号アルゴリズム、暗号鍵、認証アルゴリズム、認証鍵、リプレイ防止ウィンドウの状態を得る。本実施の形態ではパケットＰ１のＳＰＩ値は１０００であるため、ＳＡＤＢを検索した結果として、「ＤＥＳ−ＣＢＣ」、“ａｂｃｄｅｆｇｈ”、「ＨＭＡＣ−ＭＤ５」、“ＯＰＱＲＳＴＵＶＷ”、「優先度１用が９４〜９６が受信済み、優先度２用が９７〜９９受信済み」を獲得する。
【００８３】
＜ステップ２＞
ステップ２では、ステップ１で得られた認証アルゴリズムと認証鍵を用いて受信パケットのハッシュ値を計算し、ＩＣＶと一致することを確認する。ＩＣＶと一致した場合、当該パケットのうち認証アルゴリズムによって保護された領域が第３者によって書き換えられていないことが確認できる。ハッシュ値がＩＣＶと一致しない場合、当該パケットの当該領域が第３者によって書き換えられた可能性があるため、当該パケットを廃棄する。
【００８４】
本実施の形態では、パケットＰ１についてハッシュ値とＩＣＶが一致し、第３者による書き換えはなかったと判断する。
【００８５】
＜ステップ３＞
ステップ３では受信したパケットの優先度を特定する。ステップ１のＳＡＤＢ検索によって得られた暗号アルゴリズムと暗号鍵を用いて、まず第２のＩＰヘッダ内のＩＨＬとプロトコルの値を得る。すなわち、先頭のブロックと２番目のブロックを復号し、ＩＨＬとプロトコルの値を得る。次に、ＩＨＬの値から第２のＩＰヘッダ長を特定し、第４層プロトコルヘッダ内の送信元ポート番号と宛先ポート番号の値を得る。本実施の形態ではＩＨＬは５（２０バイトを示す値）であり、３番目ならびに４番目のブロックを復号し、両ポート番号を得る。以上から、第４層プロトコルの種別、送信元ポート番号、宛先ポート番号が得られる。さらにこれらの値をキーに優先度決定ＤＢ１６０を検索し、当該パケットの優先度を特定する。
【００８６】
パケットＰ１の場合、暗号アルゴリズムはＤＥＳ−ＣＢＣのため、１ブロックのサイズは８バイトである。よって、先頭、２番目、３番目、４番目のブロックを復号してＵＤＰ、１０００、２０００を得る。さらに、これらの情報をキーに優先度決定ＤＢ１６０を検索した結果、当該パケットの優先度として１を得る。
【００８７】
なお当該パケットが暗号化されていない場合、復号処理そのものはスキップされ、当該パケットに含まれる第４層プロトコルの種別、送信元ポート番号、宛先ポート番号の値を直接参照する。
【００８８】
＜ステップ４＞
ステップ４では、ステップ１で求めた複数のリプレイ防止ウィンドウのうちで、ステップ３で求めた優先度に対応したリプレイ防止ウィンドウを用いてリプレイ防止処理を行う。リプレイ防止処理は従来の受信処理装置における処理と同様である。
【００８９】
パケットＰ１の場合、優先度１に対応したリプレイ防止ウィンドウ１４１を用いてリプレイ防止処理を行う。リプレイ防止処理を行った結果、当該パケットは正常に受理され、リプレイ防止ウィンドウ１４１は図７（ｂ）に示す状態に更新される。
【００９０】
＜ステップ５＞
ステップ４において受信パケットを廃棄しなかった場合、受信処理部１３０は残りの受信処理を行う。すなわち、ステップ１にて検索したＳＡを用い、復号していない残りのブロックの復号を行った後、第１のＩＰヘッダ、ＥＳＰヘッダ、ＩＶ、ＥＳＰトレーラ、ＩＣＶを除去する。こうして第２のＩＰヘッダ、第４層プロトコルヘッダ、ペイロードから構成される、ＩＰｓｅｃパケットに変換される前のＩＰパケットが復元される。受信処理部１３０はこの復元されたＩＰパケットの受信処理を行う。
【００９１】
なお、当該パケットが暗号化されていない場合、残りのブロックの復号は不要である。
【００９２】
以上がパケットＰ１を受信した場合における、受信処理部１３０の受信処理動作である。この結果、パケットＰ１は正常に受信され、優先度１に対応したリプレイ防止ウィンドウ１４１は、図７（ｂ）に示すように、シーケンス番号１０１が受信済みとして登録される。
【００９３】
（ＩＰｓｅｃパケットＰ２受信後）
ＩＰｓｅｃパケットＰ２（優先度１、シーケンス番号１０２）を受信すると、受信処理部１３０はパケットＰ１の場合と同様に、図６に示すフローチャートに従って受信処理を行う。その結果、パケットＰ２も正常に受信され、パケットＰ２の優先度１に対応したリプレイ防止ウィンドウ１４１は、図７（ｃ）に示すように、シーケンス番号１０２、１０１が受信済みとして登録される。
【００９４】
（ＩＰｓｅｃパケットＰ３受信後）
ＩＰｓｅｃパケットＰ３（優先度１、シーケンス番号１０３）を受信した場合も同様である。その結果、パケットＰ３は正常に受信され、パケットＰ１の優先度１に対応したリプレイ防止ウィンドウ１４１は、図７（ｄ）に示すように、シーケンス番号１０３、１０２、１０１が受信済みとして登録される。
【００９５】
（ＩＰｓｅｃパケットＰ４受信後）
ＩＰｓｅｃパケットＰ４（優先度２、シーケンス番号１００）を受信した場合も同様に、受信処理部１３０は図６に示すフローチャートに従って受信処理を行う。パケットＰ４はステップ３において優先度２と判定されるため、受信処理部１３０は、優先度２に対応したリプレイ防止ウィンドウ１４２を用いて、ステップ４のリプレイ防止処理を実行する。
【００９６】
従来技術ではこの場合においても、パケットの優先度に関わらず単一のリプレイ防止ウィンドウを用いていた。そのため、パケットＰ１〜Ｐ３を受信する際に用いたリプレイ防止ウィンドウ１４１を用いてリプレイ防止処理を行うために、パケットＰ４は廃棄されていた。なぜならパケットＰ４のシーケンス番号は１００であり、リプレイ防止ウィンドウ１４１が管理するシーケンス番号１０１〜１０３よりも古いためである。
【００９７】
これに対し、本発明では、パケットＰ４のリプレイ防止処理に際し、優先度２に対応するリプレイ防止ウィンドウ１４２を用いる。その結果、パケットＰ４は正常に受理される。なぜなら、パケットＰ４のシーケンス番号１００は、リプレイ防止ウィンドウ１４２が管理するシーケンス番号９７〜９９よりも新しいためである。以上の受信処理の結果、パケットＰ４は正常に受信され、リプレイ防止ウィンドウ１４２は、図７（ｅ）に示すように、シーケンス番号１００、９９、９８が受信済みとして登録される。
【００９８】
以上のように、受信パケットの優先度に対応したリプレイ防止ウィンドウを用いて当該パケットのリプレイ防止処理を行うことによって、受信パケットに含まれる優先度によって受信順序が入れ替わった場合においても、当該パケットを廃棄することなく、正常に受信することができる。
【００９９】
なお、本実施の形態では受信パケットの優先度を、第４層のプロトコル種別とポート番号から求めたが、第２のヘッダに含まれる送信元アドレスや宛先アドレスから求めてもよいし、第４層のプロトコル種別とポート番号ならびに第２のＩＰヘッダに含まれる送信元アドレスと宛先アドレスとから求めても良い。また、第２のＩＰヘッダに含まれる優先度情報（ＩＰｖ４ヘッダの場合、ＴＯＳフィールドに相当）から求めても良い。また、第２のＩＰヘッダがＩＰｖ６ヘッダである場合、優先度情報としてＤＳフィールドを用いても構わない。さらには第１のＩＰヘッダ、第２のＩＰヘッダ、第４層プロトコルヘッダに含まれるいずれかの情報を元に、当該パケットの優先度を求めてもよい。例えば、本実施の形態で説明した第４層プロトコルのプロトコル種別、送信元ポート番号、宛先ポート番号に加え、第２のＩＰヘッダに含まれる送信元ＩＰアドレスと宛先ＩＰアドレスから優先度を求めても構わない。
【０１００】
また、本実施の形態ではセキュアなパケットとしてＩＰｓｅｃトンネルモードによるパケットを用いて説明したが、トランスポートモードによるパケットであっても構わない。トランスポートモードでは第２のＩＰヘッダは存在しないため、当該ＩＰヘッダに含まれる情報以外から当該パケットの優先度を求めればよい。
【０１０１】
また、本実施の形態では受信パケットはＥＳＰによって暗号化および認証が施されていたが、当該パケットは暗号化されていなくてもよい。暗号化されていない場合、本実施の形態で説明した全ての復号処理は不要である。また当該パケットがＥＳＰの代わりにＡＨによって保護されていてもかまわない。ＡＨでは暗号化は行わないため、本実施の計値亜で説明した全ての復号処理は不要である。
【０１０２】
また、本実施の形態ではパケットの優先度を２段階として説明したが、３段階以上であっても構わない。
【０１０３】
また、本実施の形態ではリプレイ防止ウィンドウのウィンドウサイズを３として説明したが、本発明はウィンドウサイズを制限するものではない。
【０１０４】
また、本実施の形態ではパケットがＩＰｓｅｃによって保護されている場合について説明したが、本発明は、当該パケットが優先度を特定するための情報と、パケットを区別するシーケンス番号を含み、両者が認証によって保護されているパケット全般に適用可能であり、保護する技術としてＩＰｓｅｃに限定されるわけではない。
【０１０５】
（実施の形態２）
次に、本発明における別の実施の形態について、以下に説明する。ネットワーク構成は実施の形態１と同様であるので、説明を省略する。
【０１０６】
本実施の形態における受信処理装置１００の構成は、以下の点において実施の形態１と相違する。実施の形態２における優先度１に対応するリプレイウィンドウ１４１のウィンドウサイズは５であり、優先度２に対応するリプレイウィンドウ１４２のウィンドウサイズ３よりも大きい。
【０１０７】
このような受信処理装置１００に対し、セキュリティゲートウェイ３００が優先度１、シーケンス番号が順に１１１、１１２、１１３、１１４、１１５であるパケットＰ１１〜Ｐ１５を送信した場合における、受信処理装置１００の受信処理動作について説明する。
【０１０８】
本実施の形態では、通信経路途中において、同じ優先度を持つパケットＰ１１〜１５間で転送順序が入れ替わり、Ｐ１２、Ｐ１３、Ｐ１４、Ｐ１５、Ｐ１１の順に受信処理装置１００に到着したものとする。この場合、シーケンス番号は受信する順に、１１２、１１３、１１４、１１５、１１１となる。本実施の形態において、優先度１に対応するリプレイウィンドウ１４１のウィンドウサイズは５であるため、上記のように５つ分のシーケンス番号の入れ替わりに対しても、正しく受信することが可能である。このように、優先度の高いパケットに対するリプレイウィンドウのウィンドウサイズを大きく設定することによって、優先度の高いパケットを廃棄しづらい受信処理装置を実現できる。
【０１０９】
なお、本実施の形態では、優先度１に対応したリプレイ防止ウィンドウ１４１の方がリプレイ防止ウィンドウ１４２よりもウィンドウサイズが大きかったが、優先度２に対応したリプレイ防止ウィンドウ１４２のウィンドウサイズの方が大きくても構わない。音声情報を含むパケットは許容できる遅延時間が小さく、かつ高い優先度が設定されることが多い。したがって、大きく遅延したこのようなパケットをリプレイ防止処理の段階で廃棄することにより、受信処理装置の負荷軽減を図ることが可能となる。
【０１１０】
また優先度決定ＤＢ１６０において、パケットの優先度に加えて、パケットのリアルタイム性を指し示す指標であるリアルタイム指標を保持し、各リプレイ防止ウィンドウのウィンドウサイズをリアルタイム指標に応じて設定しても構わない。また、各リプレイ防止ウィンドウのウィンドウサイズを、パケットの優先度と、パケットのリアルタイム指標と、基本となるウィンドウサイズを入力とする、特定の計算式によって決定しても構わない。この特定の計算式の一例として、「ウィンドウサイズ＝基本となるウィンドウサイズ×優先度／リアルタイム指標」が挙げられる。この特定の計算式は、ここに示した一例に限ることなく、任意に定めても構わない。
【０１１１】
（実施の形態３）
次に、本発明における別の実施の形態について、以下に説明する。ネットワーク構成は実施の形態１と同様である。
【０１１２】
本実施の形態における受信処理装置１００の構成を図８に示す。図８において、受信処理装置１００は実施の形態１の構成に加え、受信キュー長監視部１７０を備える。受信キュー長監視部１７０は、受信キュー１２０にキューイングされている受信パケットの個数を計測する。受信キュー長監視部１７０は第１の閾値と第２の閾値を備える。本実施の形態において、第１の閾値は２、第２の閾値は３であり、受信キュー長監視部１７０は、受信キューにキューイングされたパケット数が第１の閾値を超えた場合、受信処理部に対してこれを通知する。これを受けた受信処理部１３０は、優先度２に対応するウィンドウ１４２のウィンドウサイズを１に縮小する。また受信キュー長監視部１７０は、同様にパケット数が第２の閾値を下回った場合、受信処理部に対してこれを通知する。これを受けた受信処理部１３０は、優先度２に対応するウィンドウ１４２のウィンドウサイズを元のサイズである３に戻す。本実施の形態において、第１の閾値は３、第２の閾値は２である。
【０１１３】
ここで優先度１、シーケンス番号が順に２１１、２１２であるＩＰｓｅｃパケットＰ２１〜Ｐ２２と、優先度２、シーケンス番号が順に２１５、２１４、２１３であるＩＰｓｅｃパケットＰ２５、Ｐ２４、Ｐ２３を受信処理装置１００が一度に受信した場合について、その動作を説明する。
【０１１４】
上記に示したパケットＰ２１〜Ｐ２５を一度に受信すると、受信キューのキュー長は５となり、第１の閾値３を超える。そのため、受信キュー長監視部１７０は、受信パケット数が第１の閾値を超えたことを受信処理部１３０に通知し、受信処理部１３０はウィンドウ１４２のウィンドウサイズを１に縮小する。受信処理部１３０は、リプレイ防止ウィンドウ１４２のウィンドウサイズが１の状態で、パケットＰ２１〜Ｐ２２の受信処理を行う。パケットＰ２１〜Ｐ２２は全て優先度が１であるから、受信処理部１３０はリプレイ防止ウィンドウ１４１を用いてリプレイ防止リプレイ防止処理を行い、全て正しく受信処理を完了する。
【０１１５】
パケットＰ２２の受信処理が完了した時点では、受信キューのキュー長は３であり、キュー長監視部１７０が保持する第２の閾値；２を下回っていない。ゆえに受信処理部１３０はリプレイ防止ウィンドウ１４２のウィンドウサイズを１に設定したまま、パケットＰ２３〜Ｐ２５のリプレイ防止処理を行う。
【０１１６】
次にパケットＰ２５の受信処理を行う。パケットＰ２５のシーケンス番号は２１５であるから、受信処理部１３０はリプレイ防止ウィンドウ１４２のシーケンス番号２１５を「受信済み」に更新すると共に、当該パケットの受信処理を完了する。この時点においても、受信キューのキュー長は第２の閾値を下回っていないため、リプレイ防止ウィンドウ１４２のウィンドウサイズは１のままである。
【０１１７】
次にパケットＰ２４の受信処理を行う。パケットＰ２４のシーケンス番号は２１４であるから、受信処理部１３０はウィンドウ１４２より、当該パケットはリプレイ攻撃であると判定し、パケットＰ２４を廃棄する。この時点において、受信処理部１３０は、受信キュー長監視部１７０から受信キューのキュー長が第２の閾値を下回ったことを通知され、リプレイ防止ウィンドウ１４２のウィンドウサイズを３に戻す。
【０１１８】
最後にパケットＰ２３の受信処理を行う。パケットＰ２３のシーケンス番号は２１３であるから、受信処理部１３０はウィンドウ１４２のシーケンス番号２１３を「受信済み」に更新すると共に、当該パケットの受信処理を完了する。
【０１１９】
以上説明したように、受信キューのキュー長によって、低優先度に対応したリプレイ防止ウィンドウのウィンドウサイズを縮小することによって、一度に多くのパケットを受信した場合に低優先度のパケットが廃棄されやすくなり、処理負荷を低減させることが可能となる。またキュー長が短くなった場合は処理負荷も軽減されていると考えられるので、低優先度に対応したリプレイ防止ウィンドウのウィンドウサイズを元の値に戻すことによって、低優先度のパケットが廃棄されにくくなる。
【０１２０】
なお、本実施の形態では、受信キューのキュー長によって低優先度に対応したリプレイ防止ウィンドウ１４２のウィンドウサイズを変更したが、受信処理のＣＰＵ負荷や受信処理に使用する作業メモリ使用量などの演算リソースの使用量によって、ウィンドウサイズを変更しても構わない。同様に、受信処理装置全体のＣＰＵ負荷や作業メモリ使用量によってウィンドウサイズを変更しても構わない。
【０１２１】
また、本実施の形態では、第１の閾値と第２の閾値とは異なる値であったが、同じ値であっても構わない。
【０１２２】
なお、上記した各実施の形態は、記憶装置（ＲＯＭ、ＲＡＭ、ハードディスク等）に格納された上述した処理手順を実行可能な所定のプログラムデータが、ＣＰＵによって解釈実行されることで実現される。この場合、プログラムデータは、記録媒体を介して記憶装置内に導入されてもよいし、記録媒体上から直接実行されてもよい。なお、記録媒体は、ＲＯＭ、ＲＡＭ、フラッシュメモリ等の半導体メモリ、フレキシブルディスクやハードディスク等の磁気ディスクメモリ、ＣＤ−ＲＯＭやＤＶＤ、ＢＤ等の光ディスク、メモリカード等の記録媒体をいう。また、記録媒体は、電話回線や搬送路等の通信媒体も含む概念である。
【０１２３】
また、上記した各実施の形態の各鍵交換装置あるいは各機能部は典型的には集積回路であるＬＳＩとして実現することができる。これらは個別に１チップ化されても良いし、一部又は全てを含むように１チップ化されても良い。
【０１２４】
ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１２５】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用しても良い。
【０１２６】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。
【産業上の利用可能性】
【０１２７】
本発明にかかる受信処理方法は、パケットの優先度を特定するステップと、特定したパケットの優先度に対応したリプレイ防止ウィンドウを用いてリプレイ防止処理を行うステップを有し、セキュリティプロトコルによって保護された、映像や音声等のリアルタイム情報と、ＷＥＢや制御情報等の非リアルタイム情報を受信する受信端末等として有用である。
【図面の簡単な説明】
【０１２８】
【図１】本発明の実施の形態１におけるネットワーク構成を示す図
【図２】本発明の実施の形態１における受信パケットの構成を示す図
【図３】本発明の実施の形態１における受信処理装置１００の構成を示す図
【図４】本発明の実施の形態１におけるＳＡＤＢ１５０の構成を示す図
【図５】本発明の実施の形態１における優先度決定ＤＢ１６０の構成を示す図
【図６】本発明の実施の形態１における受信処理のフローチャート
【図７】本発明の実施の形態１におけるリプレイ防止ウィンドウの状態を示す図
【図８】本発明の実施の形態３における受信処理装置１００の構成を示す図
【図９】従来技術におけるネットワーク構成を示す図
【図１０】従来の受信処理装置６００の構成を示す図
【図１１】リプレイ防止ウィンドウの状態を示す図
【符号の説明】
【０１２９】
１００    受信処理装置
１１０    ネットワークインタフェース
１２０    受信キュー
１３０    受信処理部
１４０    リプレイ防止ウィンドウ
１４１    リプレイ防止ウィンドウ
１４２    リプレイ防止ウィンドウ
１５０    ＳＡＤＢ（セキュリティデータベース）
１６０    優先度決定ＤＢ
２００    中継装置
３００    セキュリティゲートウェイ
４００    第１のサーバ装置
５００    第２のサーバ装置
６００    従来の受信処理装置
６１０    ネットワークインタフェース
６２０    受信キュー
６３０    受信処理部
６４０    リプレイ防止ウィンドウ
６５０    セキュリティアソシエーションデータベース（ＳＡＤＢ）
７００    暗号通信装置
８００    リプレイ攻撃装置
【図１】
2006005425.tif 000003
【図２】
2006005425.tif 000004
【図３】
2006005425.tif 000005
【図４】
2006005425.tif 000006
【図５】
2006005425.tif 000007
【図６】
2006005425.tif 000008
【図７】
2006005425.tif 000009
【図８】
2006005425.tif 000010
【図９】
2006005425.tif 000011
【図１０】
2006005425.tif 000012
【図１１】
2006005425.tif 000013