(57)【特許請求の範囲】
【請求項１】
ネットワークを介してインターネット鍵交換（ＩＫＥ）データパケットを伝送する方法であって、
受信ノードからベンダ識別値を受信するステップと、
前記ベンダ識別値の受信に応じて、該ベンダ識別値を使用して前記受信ノードがＩＫＥフラグメント能力を有するかを決定するステップと、
ネットワーク上で元のＩＫＥヘッダを有するＩＫＥデータパケットを生成し、かつ受信ノードに対して伝送するステップと、
所定の時間間隔内で前記ＩＫＥデータパケットに対する応答を受信したか否かを決定するステップと、
前記ネットワークの最大伝送ユニットサイズを決定するステップと、
前記ＩＫＥデータパケットを、前記最大伝送ユニットサイズを超えない複数のより小さなパケットにフラグメント化するステップであって、前記複数のより小さなパケットの各々はＩＫＥプロトコルにしたがってフォーマットされたヘッダを含むステップと、
前記ネットワークを介して前記複数のより小さなパケットの各々を伝送するステップと
を備えたことを特徴とする方法。
【請求項２】
前記ヘッダの各々は、対応するＩＫＥデータパケットと前記複数のより小さなパケットとを関連付けるために使用することができる識別子を含むことを特徴とする請求項１に記載の方法。
【請求項３】
インターネット鍵交換（ＩＫＥ）プロトコルにしたがって他のネットワークノードと通信するネットワークノードであって、
ネットワークとインタフェースをとるためのネットワークインタフェースカードと、
ネットワークを介して伝送するために、ユーザデータグラムプロトコル（ＵＤＰ）データパケットを生成する能力を有するＵＤＰプロトコルスタックと、
ＵＤＰプロトコルスタックによって、続いて処理されるＩＫＥデータパケットを生成するＩＫＥプロトコルスタックと、
フラグメントモジュールであって、
ネットワークノードからベンダ識別値を受信し、前記ベンダ識別値の受信に応じて該ベンダ識別値を使用して前記ネットワークノードがＩＫＥフラグメント能力を有するかを決定し、
前記ネットワークの最大伝送ユニットサイズを決定し、
ＵＤＰプロトコルスタックによって処理される前にＩＫＥデータパケットをインターセプトし、かつＵＤＰプロトコルによって、続いてフォーマットされるであろう複数のより小さなデータパケットに、前記ＩＫＥデータパケットを分割し、前記複数のより小さなデータパケットは前記ＩＫＥプロトコルにしたがってフォーマットされたヘッダおよびネットワークアドレス変換処理のための状態情報を含み、前記フラグメントモジュールは、以前に送信されたＩＫＥデータパケットに対する応答が所定の時間間隔内で首尾よく受信されていた場合、前記ＩＫＥデータパケットを分割しない、
フラグメントモジュールと
を備えたことを特徴とするネットワークノード。
【請求項４】
ネットワークを介してインターネット鍵交換（ＩＫＥ）プロトコルデータパケットを伝送するシステムであって、
ＩＫＥデータパケットを生成する手段と、
ＩＫＥデータパケットを記憶する手段と、
タイマーを初期化し、稼動し、かつ監視する手段と、
意図された受信ノードにおいて、前記タイマーが満了する前に前記ＩＫＥパケットの受信に成功したか否かを検出するための手段と、
前記受信ノードからベンダ識別値を受信し、かつ前記ベンダ識別値を使用して該受信ノードがＩＫＥフラグメント能力を有するかを決定する手段と、
前記受信器ノードにおいて、前記ＩＫＥデータパケットの受信に成功しなかったときは、前記ＩＫＥデータパケットをより小さなパケットにフラグメントする手段と、
前記より小さいパケットのそれぞれに対して別々のＩＫＥフラグメントヘッダを追加する手段と、
ネットワークアドレス変換処理のために前記より小さいパケットのそれぞれに対して状態情報を追加する手段と、
複数の前記より小さいパケットのそれぞれに対して別々のユーザデータグラムプロトコル（ＵＤＰ）ヘッダを追加する手段と、
前記ネットワークを介して前記複数のより小さいパケットのそれぞれを伝送する手段と
を備えたことを特徴とするシステム。
【請求項５】
前記受信ノードの、フラグメント化されたパケットを受信する能力を決定するための手段をさらに備えたことを特徴とする請求項４に記載のシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般的に、データパケットのフラグメント化および再組み立てに関し、より具体的には、インターネット鍵交換（「ＩＫＥ」）プロトコルを実装するプロトコルスタックを介して生成されるデータパケットのフラグメント化および再組み立てに関する。
【０００２】
【従来の技術】
インターネットを含む公衆網を介して伝送されるデータには、しばしば、機密データや私用データが含まれる。例えば、オンライン商取引で商品やサービスを購入しようとする個人は、業者へ資金移動および／またはクレジットカードや預金の情報の提供を要求されるであろう。加えて、認証された送信者と受信者が、例えば企業の戦略文書など、機密とされる情報をインターネットを介して伝送したい場合もある。秘密データおよび／または私用データを傍受（ｉｎｔｅｒｃｅｐｔ）することに非常に関心のある犯罪者その他の盗聴者にとって、このような情報は、明らかに極めて魅力的であろう。
【０００３】
インターネットや他の公衆網の性質から、意図された受信者のみが、デリケートな情報にアクセスしようとすることを保証するのは不可能である。データ転送では普通、暗号化やスクランブル処理は行われず、盗聴者は、選ばれた個人やグループのためにのみ、意図された情報を容易に傍聴できるだろう。したがって、一定の予防措置、例えばデータの暗号化などがとられない限り、伝送媒体としてインターネットや公共のネットワークを用いる個人にとって、デリケートな情報を危うくする危険がある。
【０００４】
この危険を軽減するため、多くのコンピュータユーザはデータを暗号化してネットワークを伝送させ、それにより認証されていない聴取者がそのデータを傍聴したり読み取ったりする危険を軽減している。暗号化は、普通、理解が容易な数字の列を、判読が容易ではない形式に変化させるための適切な数学の関数を使用することで達成される。解読は、このプロセスを逆にすることで達成される。暗号化とこれに続く解読は、「鍵」の組を使用することによって実行することができる。この２つの鍵は、１つのオペレーション、例えば暗号化は、この組から１つの鍵を用いて実行されるが、逆変換は、この組のもう１つの鍵を用いてのみ計算することができるといったように関連している。情報を暗号化し解読するために用いられたキーのセットにアクセスしない（権限のない）盗聴者は、通常、機密データにアクセスすることが不可能だと思うであろう。したがって、鍵の交換は、データネットワーク上で安全な通信を確立するうえで決定的な部分である。
【０００５】
一般的に言えばコンピュータ産業界、具体的にはインターネット技術標準化委員会（ＩＥＴＦ）によって、実装する際、データの暗号化に有用なセキュリティ標準やプロトコルが採用されてきた。さらに、インターネットプロトコルセキュリティ（ＩＰｓｅｃ）ワーキンググループが、ＩＥＴＦによって設立され、多くの標準やＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ）を発行してきた。これらのドキュメントは、提案された、またはデファクトの工業標準暗号技術に関する詳細を提供する。特に、このワーキンググループは、Ｄ．ＨａｒｋｉｎｓとＤ．Ｃａｒｒｅｌによる「ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）」（ＲＦＣ−２４０９、１９９８年１１月）を公開したが、これは参照によりこの明細書に組み込まれる。
【０００６】
ＩＫＥプロトコルは、セキュリティアソシエーション（「ＳＡ」）のための証明済みの鍵材料をネゴシエートし、および提供するため設計された。ＩＫＥプロトコルは、とりわけ、２つのコンピュータ間における暗号鍵の安全な交換に特に有効である。ＩＫＥプロトコルによって交換された鍵は、次いで公衆網やプライベートネットワーク上で伝送される情報を暗号化し解読するために使用することができる。
【０００７】
ＩＫＥプロトコルは、インターネットＳＡと鍵管理手順（ＩＳＡＫＭＰ）およびインターネットＩＰセキュリティ翻訳ドメイン（ＤＯＩ）によって特定される鍵管理手順のための高レベルの意味論に忠実である。ＩＫＥプロトコルは、通常一組のネットワークプロトコルスタックのうちの高位レイヤ上に実装される。ネットワークノード内のアプリケーションは、一般にＩＫＥプロトコルスタックを起動し、次に一連の明確に定義されたメッセージを生成する。ＩＫＥプロトコルを実装するコード、すなわちＩＫＥプロトコルスタックは、さらに意図された受信ノードにメッセージを伝送するという責任をもつ。しかし、ＩＫＥプロトコルスタックは、ネットワークで通信するのに必要なオペレーションを全て実装するわけではない。むしろ、他の高レベルなサービスやアプリケーションのように、ＩＫＥプロトコルスタックは、ユーザデータグラムプロトコル（ＵＤＰ）やインターネットプロトコル（ＩＰ）のようなプロトコルを実装してネットワーク通信を容易にする、より低レベルのスタックを信頼する。
【０００８】
ＩＰネットワーク上の全ての通信は、固定サイズのデータパケットを伝送し、およびスイッチすることによって達成される。このネットワークにしたがって、ＩＰプロトコルスタックは、最大伝送ユニット（ＭＴＵ）として識別される長さをもつ最大長のパケットを伝送しようとする。このＭＴＵは、ネットワークあるいはネットワークにおけるアプリケーションに対して指定することができる。いくつかのＩＰネットワークとアプリケーションは、そのＭＴＵを明らかにし、または明示的に提供するための仕組みを提供する。例えば、伝送アプリケーションからなされるクエリへの応答でＭＴＵ値が提供されるであろう。加えて、ＩＰプロトコルは、それ自身所与のネットワークまたはアプリケーションに対してＭＴＵを決定するための、ＭＴＵ探索機能として知られる限定された規定（ｌｉｍｉｔｅｄ  ｐｒｏｖｉｓｉｏｎ）を含む。しかし、所与のネットワークまたはアプリケーションに対し、そのＭＴＵを決定することが、常に可能ではないかもしれない。もしＭＴＵが既知であるか公開されており、ユーザがＩＰネットワークを介して送信しようとするデータがそのＭＴＵを超えているなら、ＩＰプロトコルスタックはその関連するＭＴＵを超えない、より小さなパケットにそのデータを再パッケージする。再パッケージのステップは、フラグメント化としても知られている。ＭＴＵを超えない、より小さなフラグメント化されたデータパケットは、その後、意図された受信者にネットワークを介して伝送され、さらに元のデータに再組み立てされる。
【０００９】
【発明が解決しようとする課題】
他のいかなるデータとも同じように、ＩＫＥパケットに含まれる情報は、ＩＫＥペイロードとしても知られるが、ときおり所与のネットワークまたはアプリケーションに対するＭＴＵを超えることがある。したがって、ＩＫＥ対応の伝送アプリケーションにおいて動作するＩＰプロトコルスタックは、そのＭＴＵを超えないサイズにＩＫＥペイロードをフラグメント化する。事実、ＩＫＥプロトコルスタックは、ＩＫＥメッセージの一部として含まれるＤＦ（フラグメントなし）フラグをセットしない。その結果、ＩＫＥプロトコルは、いかなるＩＰスタックにもＩＫＥペイロードを適正にフラグメント化する権限を与える。
【００１０】
さらに、ローカルＩＰスタックは、最初のＩＫＥノードの下流にあるノードまたはリンクにおけるＭＴＵの最低値を知らない場合もある。このため、最初のノードのＩＰスタックがＩＫＥペイロードをフラグメント化したとしても、結果生成されたフラグメントが、一定のネットワークまたはアプリケーションにとっては、まだ大きすぎる場合がありうる。このような場合、ＩＫＥペイロードをさらにフラグメント化する必要がある。
【００１１】
既知の手法、例えば、ＩＰスタックを用いた手法などによるＩＫＥペイロードのフラグメント化では、ネットワークを介したＩＫＥメッセージでは信頼性のある伝送はできないであろう。これは、通常のＩＫＥペイロードが、フラグメント化されたＩＰパケットを追跡しない、ＵＤＰプロトコルにしたがって伝送されるからである。さらに、多くのネットワークコンポーネント、例えばネットワークアドレス変換器（ＮＡＴ）もまた、ＩＰフラグメントを追跡しない。したがって、ＩＫＥペイロードのいずれかのフラグメントが消失すると、ＩＫＥペイロード全体が危うくなる。この結果、受信側のＩＫＥピアは、送信側ＩＫＥピアからのメッセージの検証や応答を行うことができないであろう。
【００１２】
種々の理由から、意図されたＩＫＥピアが伝送されたＩＫＥパケットを受信しない可能性がある。例えば、ＩＫＥピア間のネットワーク基盤による問題、すなわち接続線障害、データ衝突、ソフトウェア問題などによって、パケットは一見無作為に消失するかもしれない。この種の通信問題に対しては、消失したＩＫＥパケットを再送し、これにより、メッセージの交換の実現に成功する。もう一つの例として、例えばＮＡＴのようなアプリケーションは、ＩＫＥパケットを扱う際の体系的問題を有することがある。これは、ＩＫＥパケットに関するＩＰフラグメントが、ＮＡＴに適切なデータのフォーマットまたは送信をさせるのに十分な情報を含まないことがあるからである。多くのＩＰフラグメントは、通常、ＮＡＴがアドレスおよびソース変換を実行するのに必要とするポート情報やその他の状態情報を含まない。したがって、ＩＰフラグメントは、一定のＮＡＴでは日常的に消失する可能性がある。
【００１３】
したがって、既存のＩＫＥプロトコルによって生成されたデータパケットを扱うための改良された方法およびシステムが必要である。より具体的に言うと、所与のＭＴＵを超えるＩＫＥペイロードを、そのＭＴＵを超えないより小さなパケットにフラグメント化するための方法およびシステムが必要である。ＩＫＥペイロードは、ＩＫＥパケットが受信ノードにおいて再組み立てすることができる方法によってフラグメント化処理されなければならない。
【００１４】
【課題を解決するための手段】
以上の必要性から、本発明のシステムおよび方法は、データパケットをフラグメント化し、および再組み立てするための、より具体的には、インターネット鍵交換（「ＩＫＥ」）プロトコルを実装するプロトコルスタックを通して生成されたデータパケットをフラグメント化し、および再組み立てするための仕組みを提供する。本発明によれば、ＩＫＥペイロードをフラグメント化し、あるいは再組み立てするために、ＩＫＥプロトコルは実質上変更する必要はない。そうする代わりに、本発明のシステムおよび方法では、伝送するノードにとって送出されるＩＫＥデータパケットをフラグメント化する必要があるか否か、および受信ノードがフラグメント化されたパケットを受信する能力があるか否かが決められる。本発明のシステムおよび方法は、さらに、パケットのサイズが、定められた閾値を超えており、受信ノードが、フラグメント化されたパケットを受信する能力がある場合、送出されるＩＫＥデータパケットを送信側ノード上でインターセプトする。ＩＫＥパケットは、ネットワークを伝送する、より小さなパケットにフラグメント化され、受信ノードにおいて受信される。フラグメント化されたパケットを格納し、元のＩＫＥペイロードに再組み立てする受信ノード内のモジュールは、フラグメント化されたＩＫＥパケットを消費（ｃｏｎｓｕｍｅ）する。本発明のシステムおよび方法は、さらに、種々の攻撃からネットワーク上のノードを保護する非常に多くの実施形態を含む。
【００１５】
本発明の更なる実施形態および優位性は、添付図面を参照してなされる以下の例示された実施例の詳細な説明により明らかになるであろう。
【００１６】
【発明の実施の形態】
特許請求の範囲が本発明の形態を具体的に説明するが、本発明は、添付する図面を用いた以下の詳細な説明によって最もよく理解されるであろう。
【００１７】
本発明は、コンピュータによって実行されるコードモジュールをプログラムすることによって実施することができる。一般的に、プログラムモジュールには、ルーチン、オブジェクト、コンポーネント、データ構造その他の特定のタスクを実行するかまたは一定のアブストラクトデータタイプを実装するものが含まれる。本明細書で用いられる用語「プログラム」および「モジュール」は、単一のプログラムモジュールまたは協働して動作する複数のプログラムモジュールを意味する場合がある。本発明は、パーソナルコンピュータ（ＰＣ）、電話、ハンドヘルド機器、マルチプロセッサシステム、マイクロプロセッサ搭載のプログラム可能なコンシューマ電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ等を含む、種々のコンピュータ上で実施することができる。本発明はまた、シンクライアントおよび分散コンピューティング環境においても実施することができ、この場合、タスクは通信ネットワークを介して接続された遠隔処理装置によって実行される。分散コンピューティング環境において、モジュールはローカルおよび遠隔の双方のメモリ記憶装置に置くことができる。
【００１８】
図１を参照して、本発明が実施されるネットワーク接続された環境の例を示す。例示のネットワークは、雲形で示されるネットワーク１０２を介して相互に接続される数個のコンピュータ１００を含む。ネットワーク１０２は、よく知られた多くのコンポーネント、例えばルータ、ゲートウェイ、ハブなどを含み、コンピュータ１００は有線および／または無線で通信することができる。
【００１９】
図２を参照すると、本明細書に記載されたシステムは、例示された基本構成を有するコンピュータ１００上で実施することができることが示される。この最も基本的な構成において、コンピュータ１００は通常、少なくとも１つの処理ユニット１１２およびメモリ１１４を含む。コンピュータ１００の正確な構成とタイプに従い、メモリ１１４は、（ＲＡＭのような）揮発性のメモリ、（ＲＯＭまたはフラッシュメモリのような）不揮発性のメモリ、または双方を組み合わせたメモリとすることができる。この最も基本的な構成は、図２中の線１０６で囲まれた部分に示される。加えて、コンピュータ１００は追加の形態／機能を有することができる。例えば、コンピュータ１００はまた、追加の（取外し可能なおよび／または固定の）記憶装置を有することができ、これには磁気または光ディスクまたはテープが含まれるがこれに限られない。コンピュータ記憶媒体には、揮発性および不揮発性、取外し可能および固定の媒体が含まれ、これには、コンピュータ読み取り可能な命令、データ構造、プログラムモジュールその他のデータといった情報を記憶するための、いかなる方法または技術によって実現される媒体も含まれる。コンピュータ記憶媒体には、ＲＡＭ，ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリあるいは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）あるいはその他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク装置あるいはその他の磁気記憶装置、または所望の情報を記憶するために用いられ、コンピュータ１００によりアクセスすることが可能な、いかなるその他の媒体が含まれるがこれに限られない。いかなるこのような記憶媒体も、コンピュータ１００の一部とすることができる。
【００２０】
コンピュータ１００はまた、他の装置と通信を行う通信コネクションを含む。通信コネクションは、通信媒体の一例である。通信媒体は、通常、コンピュータ読み取り可能な命令、データ構造、プログラムモジュールまたは搬送波やその他の移送メカニズムなどの変調されたデータ信号内のその他のデータを実現するものであり、いかなる情報配信媒体をも含む。一例として、これには限定されないが、通信媒体は、有線ネットワークやディレクト−ワイヤードコネクションのような有線媒体、および音響、ＲＦ、赤外線その他のような無線媒体を含む。本明細書で使用される用語「コンピュータ読み取り可能な媒体」には、記憶媒体と通信媒体の双方が含まれる。
【００２１】
コンピュータ１００はまた、入力装置、例えばキーボード、マウス、ペン、音声入力装置、タッチ入力装置などを有することができる。表示部１１６、スピーカ、プリンタ、などの出力装置もまた含むことができる。以上の装置は全て、本技術分野ではよく知られたものであり、詳細に記述する必要はない。
【００２２】
図３は、コンピュータ１００にネットワークを介した通信を可能にさせる、論理デバイス、アプリケーションおよびプログラムされたコードモジュールを示す図であり、これらはあわせて符号１２０で示す。図３は、とりわけ、符号１２２〜１２６で示される一連のプロトコルスタックの例を示す。図３の物理的コンポーネント／ハードウェアコンポーネント１２１は、例えば、ネットワークインタフェースカード（ＮＩＣ）およびハードウェアコンポーネントのための種々のデバイスドライバを含むことができる。物理レイヤおよびハードウェアレイヤの上位には、インターネットプロトコル（ＩＰ）を実現するネットワークＩＰスタック１２２がある。ＩＰスタック１２２は、ネットワーク内またはネットワーク間の通信経路管理のために設計されるアドレッシングプロトコルを実装する。
【００２３】
ＩＰスタック１２２の上位には、追加のいくつかのプロトコルスタックがあり、これには、送信制御プロトコル（ＴＣＰ）スタック１２３、ユーザデータグラムプロトコル（ＵＤＰ）スタック１２４およびインターネット制御メッセージプロトコル（ＩＣＭＰ）スタック１２５が含まれる。ＴＣＰスタック１２３は、コネクション型で、終端間信頼性のある（ｅｎｄ−ｔｏ−ｅｎｄ  ｒｅｌｉａｂｌｅ）プロトコルを実現するためのコードを提供する。ＴＣＰスタック１２３は、さらにネットワーク装置間で高信頼性のプロセス間通信を保証する。ＵＤＰスタック１２４は、コンピュータネットワークの相互接続されたセットにおける、データグラムによる通信のコネクションレスモードを実現するためのコードを提供する。ＵＤＰのプロトコルは、パケットの配信を保証しない。すなわち、その複製パケットは送信されない。最後に、ＩＣＭＰスタック１２５は、インターネットプロトコル制御のために必要なコードを含む。ＩＣＭＰスタック１２５の主な機能には、エラー通知、経路変更の通知、パフォーマンス、サブネットアドレッシングおよびその他の保守が含まれる。コンポーネント１２２〜１２５は好ましい実施形態の一部として示されているが、本発明を実施する上で絶対的に必要なものではない。これらのプロトコルスタックに代替するものとして、上述の種々のプロトコルスタックが各々個別に、あるいは組み合わされて使用され、ネットワークのノード間におけるネットワーク接続を構成することができる。より多くのまたはより少ないプロトコルスタックを用いることも可能である。
【００２４】
アプリケーションおよび高レベルのサービスは、最上位レイヤ１２６に位置する。これは、ネットワーク装置のための所望の機能を実行するためのアプリケーションプログラムが存在するところである。例えば、コンピュータ１００のためのアプリケーションプログラムは、プリンタのアプリケーションプログラムを含むかもしれない。これはまた、ＩＫＥプロトコルスタック１２７が存在するところでもある。ＩＫＥプロトコルスタック１２７は、２つのコンピュータ間で安全な暗号鍵の交換を可能にする。ＩＫＥプロトコルスタック１２７を介して交換された鍵は、次いで、公衆網あるいはプライベートネットワーク上のコンピュータ間で伝送される情報を暗号化する。セキュリティアソシエーション（ＳＡ）を構築しようとするアプリケーションは、ＩＫＥプロトコルスタック１２７を動作させ、鍵交換およびその他の関連する情報の処理を開始することができる。
【００２５】
ＩＰｓｅｃは、ノード間でＳＡを構築する際の細部を提供するいくつかのドキュメントを発行してきた。このようなドキュメントの一つに、Ｓ．ＫｅｎｔとＲ．Ａｔｏｋｉｎｓｏｎによる「Ｓｅｃｕｒｉｔｙ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ」（ＲＦＣ−２４０１、１９９８年１１月）があり、これは参照により本明細書に組み込まれる。２つのネットワークノード間に接続が存在しない状態からはじめて、各端点が接続の安全を信頼することが可能となり、各ノードの同一性がもう一方のノードに認められるように、ＳＡが構築される。ＩＰｓｅｃは、保護するＩＰパケットに追加される関連するヘッダを各々有する、２つのセキュリティサービス：認証ヘッダ（「ＡＨ」）および暗号化ヘッダ（「ＥＳＰ」）を特に定義する。ＩＰｓｅｃドキュメント、Ｓ．ＫｅｎｔとＲ．Ａｔｏｋｉｎｓｏｎによる「ＩＰ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｈｅａｄｅｒ」（ＲＦＣ−２４０２、１９９８年１１月）には、ＡＨヘッダが記載されており、参照により本明細書に組み込まれる。ＩＰｓｅｃドキュメント、Ｓ．ＫｅｎｔとＲ．Ａｔｏｋｉｎｓｏｎによる「ＩＰ  Ｅｎｃａｐｓｕｌａｔｉｎｇ  Ｓｅｃｕｒｉｔｙ  Ｐａｙｌｏａｄ（ＥＳＰ）」（ＲＦＣ−２４０６、１９９８年１１月）には、ＥＳＰヘッダが記載されており、参照により本明細書に組み込まれる。
【００２６】
ＩＰｓｅｃプロトコルは、ＳＡを構築し、これを用いて２つの端点間の安全な仮想接続を識別する。１つのＳＡは、２つの端点間の一方向接続であり、一つのＩＰｓｅｃプロトコルモードの組み合わせを示している。一つのＳＡの２つの末端、すなわち、ネットワーク装置は、ＩＰｓｅｃサービスによって保護される安全な仮想接続を定める。端点の一つがＩＰパケットを送信し、他方の端点がそれらを受信する。ＳＡが一方向であることから、安全な双方向通信のため最低２つのＳＡが必要となる。複数のＳＡを組み合わせることによって、２つの端点間において、ＩＰｓｅｃプロトコルの複数のレイヤを構成することも可能となる。
【００２７】
ＩＰｓｅｃＳＡを構築するプロセスは、ネゴシエーションと認証の双方を含む。ネゴシエーションの結果、特定の暗号手法と関連するパラメータに加え、いかなるセキュリティプロトコルおよびモードを使用すべきかに関し、２つの端点間において同意がなされる。認証は、各端点がネゴシエーションの間、したがって、ＳＡが確立された後、もう一方の端点の同一性を信頼することを保証する。
【００２８】
ＩＫＥプロトコルは、ＳＡを構築するための標準として提案されてきた。上記で指摘したように、ＩＫＥプロトコルはＩＳＡＫＭＰ意味論に忠実である。これは、Ｄ．Ｍａｕｇｈａｎ、Ｍ．Ｓｃｈｅｒｔｌｅｒ、Ｍ．ＳｃｈｎｅｉｄｅｒおよびＪ．Ｔｕｒｎｅｒによる「Ｉｎｔｅｒｎｅｔ  Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ」（ＲＦＣ−２４０８、１９９８年１１月）に記載されており、参照により本明細書に組み込まれる。ＳＡネゴシエーションは、ネットワーク上のノード間で交換される一連のメッセージとして実現される。
【００２９】
図４は、ＩＳＡＭＫＰおよびＩＫＥプロトコルにしたがって交換される、典型的な一組のメッセージを示す図である。図４において、ネットワークノードは、始動（ｉｎｉｔｉａｔｏｒ）ノード１３１および応答（ｒｅｓｐｏｎｄｅｒ）ノード１３２として表されている。符号１３４で示される最初のメッセージの組において、始動ノード１３１は、メッセージ１３５でセキュリティプロトコルおよび暗号アルゴリズムを提案する。メッセージ１３５は、ＩＫＥヘッダ、ラベル付けされたＨＤＲおよび適正なＳＡメッセージに対応するデータを含む。応答は、最初のメッセージ１３５に対する受領または逆提案を表す応答メッセージ１３６を送信する。応答メッセージもまた、ＩＫＥヘッダ、ラベル付けされたＨＤＲおよび適正なＳＡメッセージに対応するデータを含む。最初の一連のメッセージが完結すると、始動ノード１３１と応答ノード１３２の双方がネゴシエートされた細部に合意したこととなる。
【００３０】
符号１３８で示される、次のメッセージの組には鍵の交換が含まれる。始動ノード１３１はまず、ＩＫＥヘッダ、鍵交換ペイロードおよびノンスを含むメッセージ１３９を伝送する。応答ノード１３２は、鍵交換ペイロードおよびノンスを含む、自身のメッセージ１４０を供給する。この情報から排他的にシェアされた秘密情報が引き出され、その結果、鍵の生成とその後の管理を行う。
【００３１】
最後のメッセージの組１４２はまた、始動ノード１３１からのメッセージ１４３および応答ノード１３２からのメッセージ１４４を含む。最後のメッセージの組１４２は、通信ノードの証明を提供する。したがって、始動ノードのメッセージ１４３は、始動ノード１３１のＩＫＥヘッダとＩＤペイロードを含む。応答ノードのメッセージ１４４もまた、始動ノード１３１のＩＫＥヘッダとＩＤペイロードを含む。それぞれのノード間で交換することができる、可能なメッセージに関する更なる詳細は、上述のＨａｒｋｉｎｓのＲＦＣおよびＰ．Ｃ．Ｃｈｅｎｇによる「Ａｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｆｏｒ  ｔｈｅ  ＩｎｔｅｒｎｅｔＫｅｙ  Ｅｘｃｈａｎｇｅ  Ｐｒｏｔｏｃｏｌ」（ＩＢＭ  Ｓｙｓｔｅｍ  Ｊｏｕｒｎａｌ、Ｖｏｌ．４０、Ｎｏ．３、２００１年）に含まれ、参照により本明細書に組み込まれる。加えて、種々のＩＰｓｅｃプロトコル、ＳＡメッセージなどが米国特許第６，０５５，２３６号明細書で議論されており、参照により本明細書に組み込まれる。
【００３２】
ＩＫＥプロトコルにしたがって伝送されたメッセージは、データの容量（ｃｏｎｔｅｎｔ）および長さの双方について可変である。最初のＩＫＥプロトコルメッセージの組１３４でなされたネゴシエーションの結果によって、続くメッセージは異なってくる。加えて、ＩＫＥのＩＤメッセージ１４２の一部として交換される証明チェーンの長さは、認証局および始動ノードと応答ノードの制御が及ばないその他の要因に依存して変更され得る。結果として、メッセージが最大伝送ユニット（ＭＴＵ）を超えることが可能である。
【００３３】
既知の手法に従って、ローカルＩＰプロトコルスタックは、ＭＴＵを超えないサイズにＩＫＥペイロードをフラグメント化する。加えて、送信側ノードからさらに下流に位置する他のルータおよびネットワーク装置は、さらにＩＫＥペイロードをフラグメント化しようとする。これは、全てのフラグメントが適切に伝送されれば問題を生じさせない。しかし、ＩＫＥペイロードのフラグメントのいずれかが消失すると、始動ノードと応答ノードのいずれも消失したフラグメントを追跡する方法がない。この結果、ＩＫＥピアは、もう一方のＩＫＥピアからのメッセージに対し、検証または応答を行うことができない。これは、ある種のＮＡＴのように、ＩＫＥパケットを扱う際に体系的な問題を抱える可能性のある装置にとってとりわけ問題となる。既知の手法に従ってフォーマットされるＩＫＥフラグメントは、十分な情報を含まず、ＮＡＴは、そのフラグメントまたは関連する他のいずれかのフラグメントのための適切な経路設定をすることができないであろう。
【００３４】
本発明のシステムおよび方法は、応答ノードが、送出されるＩＫＥペイロードを受信しているか否かを検出することによってこの問題を解決する。検出しない場合、本発明を実現するコードは、少なくとももう１回、そのＩＫＥペイロードを伝送させることができる。本発明のこの形態は、無作為的または突発的な伝送の場合に対処し、ＩＫＥパケットの不必要なフラグメントを回避する。伝送されたパケットが、それでもまだ応答ノードで受信されなかったと見なされる場合、本発明の形態では、ネットワーク上を的確に伝送することができる、より小さなサイズにＩＫＥペイロードをフラグメント化する。
【００３５】
図５は、本発明の好ましい実施形態を実現するコードモジュール間の論理的関係を示す図である。図５は、図３に示した一般的なネットワーク環境のうち、アプリケーションおよび高レベルのレイヤ１２６を複写したものであるが、ＩＫＥプロトコルスタック１２７に加え、フラグメント／再組み立て部コードモジュール１５０（以下、「フラグメント部１５０」という。）をさらに含む。フラグメント部１５０は、アプリケーションレイヤ１２６内に存在し、論理的にはＩＫＥプロトコルスタック１２７の下位にあたる。ＩＫＥのフラグメント化に対応する環境下では、フラグメント部１５０は始動ノードおよび応答ノードの双方に存在するであろう。
【００３６】
フラグメント部１５０は、伝送モジュール１５１を介してＩＫＥデータパケットをフラグメント化し、受信モジュール１５２を介してＩＫＥデータパケットを再組み立てする。さらに、フラグメント部１５０は、ＩＫＥデータパケットが応答ノードにおいて受信されたか否かを検出し、必要に応じてＩＫＥペイロードの再送をさせるのに必要なロジックを含む。したがって、フラグメント部１５０は、フラグメント化やパケットの再組み立て以外の多くの機能を実行することができ、このモジュールの記述的な名称に表された内容に限定して解釈してはならない。
【００３７】
ＩＫＥプロトコルスタックの下位にフラグメント部１５０を位置付けることによって、本発明を実装するために必要となるＩＫＥプロトコルへの変更が不要か、あっても小さくすることが保証される。これは、本発明が既存のシステムで実施することができるようになるため、特に有利な点であろう。加えて、ＩＫＥプロトコルスタックの下位に本発明のコードを配置することによって、容易に、消失したＩＫＥフラグメントの問題を的確に解決することができる。最後に、ＩＫＥプロトコルステートマシンを変更しないことによって、ＩＫＥプロトコルの基本的なセキュリティが侵されない。
【００３８】
実際には、フラグメント部１５０は、あるノード上で送出されるＩＫＥパケットをインターセプトし、またもう一方のノード上で到来するＩＫＥパケットをインターセプトする。必要な場合、これらのインターセプトされたパケットは、送出されるノードではフラグメント化され、もう一方のノードでは再組み立てされる。したがって、ＩＫＥペイロードのフラグメント化または再組み立てを達成するためになされなければならない処理は全て、ＩＫＥプロトコルスタックにとってトランスペアレントである。
【００３９】
図６は、ＩＫＥのＩＤパケット１６０を示す図であり、例えば図４のメッセージ１４３に対応する。このパケットは、ＩＫＥヘッダ１６１を含み、それは、特にペイロード内のデータが暗号化されているか否かを示すフラグを含む。さらに、それは、続くＩＫＥパケットを識別する情報を含む。加えて、ＩＫＥパケットは、ＩＤペイロードを構成する実際のデータを含む。特に、このデータには、ＳＡを確立し維持するために必要な証明チェーンが含まれる。
【００４０】
図７は、図６に示したものと同じデータだが、フラグメント部１５０によってフラグメント化されたものを示す図である。以下により詳細に記載するように、フラグメント部１５０は、ＭＴＵを超える１つのメッセージをより小さな複数のメッセージに変換するために動作することができる。さらに、より小さな各メッセージにはＩＫＥヘッダが追加され、各メッセージは、元のＩＫＥペイロードの一部だけを含む。図７に示されるパケットの集合は、もとのＩＫＥのＩＤペイロードを構成するデータ１６２の全てを含む。加えて、最初のフラグメント１７１はまた、元のＩＫＥヘッダ１６１も含む。したがって、フラグメント部１５０は、ＩＫＥプロトコルスタック１２７によって提供された元のデータ全てを保持する。特に、ＩＫＥのＩＤペイロードについて、しかしこれに限られないが、ＩＫＥペイロードのデータ部分は先頭が切り取られ、そのデータは、選択されたＭＴＵを超えない長さをもつ、新たなより小さいパケットにカプセル化される。他のパケットには、先頭が切り取られたデータの残りが含まれることになる。
【００４１】
図８は、フラグメント部１５０を実現するコードモジュールの論理フローを示す図である。このフロー図は、好ましい一実施形態のために提供されるものであり、当業者が理解し得る変更可能な全ての形態を包含するものではないことを理解しなければならない。さらに、図８で表現されるロジックは、主にフラグメント部１５０内の送信器モジュール１５１にあわせたものであるが、一定のステップについては、受信モジュール１５２でも実行することができることが理解されるべきである。
【００４２】
図８のステップ１８１において始まり、応答ノードとＳＡを確立しようとするＩＫＥアプリケーションの始動ノードは、ＩＫＥメッセージを伝送する。このメッセージは、図４に示されたいずれかのメッセージでもよく、またＩＫＥプロトコルスタックによるいずれかのメッセージとすることもできる。フラグメント部１５０は、メッセージを監視し、適切な時間間隔の後、正式な応答が受信されたか否かを決定する（ステップ１８２）。
【００４３】
適当な応答が受信されていた場合、フラグメント部１５０は、ＩＫＥプロトコルにしたがって単に処理を継続させる（ステップ１８３）。このロジックにしたがって、ＩＫＥペイロードが的確に伝送される場合、フラグメント化は行われない。
【００４４】
しかし、ステップ１８２において適当な応答が受信されない場合、フラグメント部１５０は、適正なＩＫＥペイロードを再送する（ステップ１８４）。このステップは、１回以上繰り返すことが可能であるが、通信問題がＩＫＥペイロードのサイズによって引き起こされなかった場合を処理するため実装される。例えば、ＩＫＥペイロードは、一時的な装置不調によって偶然に消失したのかもしれず、この場合、本発明によるフラグメント化は必要ないであろう。元のＩＫＥペイロードをまず再送することによって、フラグメント部１５０は、元のＩＫＥペイロードをフラグメント化することなく適当な応答を受信することができるか否かを検証する。ステップ１８４とステップ１８５を結ぶ破線は、送信器モジュール１５１が、ステップ１８６に進む前に、例えば３回あるいは４回ＩＫＥペイロードを再送しようとする可能性があることを示している。したがって、このステップは、ネットワークの帯域幅を節約し、さらにＩＫＥフラグメント部が不必要に起動されないことを保証する。再送の後、適当な応答が受信された場合（ステップ１８５）、フラグメント部１５０は、さらにフラグメント化することなく、ＩＫＥプロトコルスタックは、再び処理を継続する。
【００４５】
しかし、フラグメント部１５０が、元のＩＫＥペイロードを１回または２回以上再送しようとした後もまだ、適当な応答を受信できない場合（ステップ１８５）、ＩＫＥペイロードが特定のネットワークまたはアプリケーションに対するＭＴＵを超えていると判断される。この場合、送信器モジュール１５１は、フラグメント化のプロセスを開始するか、始動ノードのＩＫＥプロトコルスタックに応答ノードとのＳＡ確立処理を打ち切らせる（ａｂｏｒｔ）。この判断のステップは、符号１８６で示される。ステップ１８６で、送信器モジュール１５１は、受信モジュールがフラグメント化されたパケットを受信する能力を有するか否かを判断する。受信する能力がない場合、フラグメント部１５０は、ＩＫＥペイロードを再び１回または２回以上再送する（ステップは図示せず）ことができるか、さもなければプロセス全体を打ち切る（ステップ１８７）。一方、受信ノードが自身のフラグメント部および有効な受信モジュールを有する場合、送信器モジュールは、伝送のためにＩＫＥペイロードをフラグメント化する処理を開始する。
【００４６】
好ましい一実施形態では、フラグメント部１５０は、ＳＡ確立処理における最初のメッセージ交換の一つの際に伝送されるベンダ識別値（ベンダＩＤ）を参照することによって、受信ノードのフラグメント受信能力を決定する。このベンダＩＤは、通常、ＩＫＥプロトコルの一部として交換される。ルックアップテーブルを参照するかまたは他の類似の手法によって、送信器モジュール１５１は、受信モジュール１５２が、フラグメント化されたＩＫＥペイロードを扱う能力があるか否かを判断する。
【００４７】
適当な受信モジュールが存在すると決定した後、フラグメント部１５０の送信器モジュール１５１は、元のＩＫＥペイロードのフラグメント化を開始する。フラグメント化処理の最初のステップは、ＭＴＵについて適正な値を定めることである（ステップ１８８）。好ましい一実施形態においては、フラグメント化処理で使用する適正なＭＴＵは、始動ノードと応答ノードが通信を行う特定のネットワークに対して指定され得る最小の伝送ユニットである。例えば、あるネットワークとアプリケーションのための最小のダイヤルアップ伝送ユニットは、５７６バイトである。したがって、ステップ１８８で、ＭＴＵサイズは、５７６バイトであると定められる。
【００４８】
代替の実施形態においては、フラグメント部１５０は、的確な応答が受信されるまで、次第に、より小さなパケットサイズが選択されるという反復処理を通してＭＴＵを定める。この反復処理は、図８のロジックには示されていないが、上記の記載に基づいて、当業者によって容易に実装されるであろう。最善の値が反復処理によって定められるか絶対値によるかによらず、適正なＭＴＵが定められた後、フラグメント部１５０は、今後のＩＫＥ関連通信のために使用されるＭＴＵをそれに応じて減少させるであろう。
【００４９】
次のステップにおいて、フラグメント部１５０は元のＩＫＥペイロードをフラグメント化する（ステップ１８９）。この処理は、元のＩＫＥペイロードのカプセル化および切り取りを含む。図７に示すように、元のＩＫＥヘッダ１６１は、カプセル化され、そのペイロードデータは、ＩＫＥヘッダとデータをあわせて新たに定められたＭＴＵサイズを超えないような別のパケットに分割される（ステップ１８９）。
【００５０】
ある好ましい実施形態では、フラグメント化されたＩＫＥパケットに含まれるデータは、新しいＩＫＥペイロードタイプＩＳＡ＿ＦＲＡＧとして以下のように定義される：
【００５１】
【表１】
0004271451.tif 000002
【００５２】
したがって、各フラグメントは、元のＩＫＥペイロードおよびその元のＩＫＥペイロード内における位置を一意的に識別する情報（メタデータ）を含むことになる。例えば、メッセージ１７１のように最初のフラグメント化されたメッセージで伝送されるメタデータは、以下のよう定義することができる：｛ｉｄ＝１，ｎｕｍ＝１，ｆｌａｇｓ，ｌａｓｔ＿ｐａｃｋｅｔ＿ｆｌａｇ＝ｆａｌｓｅ｝。メッセージ１７４のように、二番目のメッセージで伝送されるデータは、以下のように定義することができる：｛ｉｄ＝１，ｎｕｍ＝２，ｆｌａｇｓ，ｌａｓｔ＿ｐａｃｋｅｔ＿ｆｌａｇ＝ｆａｌｓｅ｝。最後に、メッセージ１７６のように、三番目のメッセージで伝送されるデータは、以下のように定義することができる：｛ｉｄ＝１，ｎｕｍ＝３，ｆｌａｇｓ，ｌａｓｔ＿ｐａｃｋｅｔ＿ｆｌａｇ＝ｔｒｕｅ｝。以下に記載するように、受信モジュール１５２は、この情報を用いて、元のＩＫＥペイロードを再組み立てする。この情報を用いて、始動ノードおよび／または応答ノードで第三者からの攻撃を防御することもできる。
【００５３】
ステップ１９０では、全てのフラグメントがネットワーク上を伝送されるが、各フラグメントは定められたＭＴＵの値を超えない。これは、先行技術のＩＫＥフラグメントには対応できないか対応するのが困難な、ある種のＮＡＴまたはファイヤウォールによっても、本発明に基づいて生成されたフラグメントが効果的に処理されるため、有効な点である。これらの装置および他の同様な装置では、既知の手法によって生成されたＩＫＥフラグメントは、ＮＡＴまたはファイヤウォールにとって必要な状態情報の全てを有してはおらず、フラグメントを処理し、経路設定することができない。これは、順序が狂ったフラグメントには特に該当する。例えば、既知の手法で生成された二番目のフラグメントが最初のＩＫＥフラグメントの前に到達した場合、ＮＡＴやファイヤウォールの多くは、十分な情報を有さず、その正規の下流にあるノードへ送信することができない。したがって、ＮＡＴやファイヤウォールは、フラグメントを消失し、ＩＫＥパケットは、その意図されたノードにおいて的確に受信されないであろう。
【００５４】
本発明はこの問題を解決するため、とりわけ、より小さなサイズのパケットを伝送し、および各ＩＫＥフラグメントに状態情報を含む。本発明に基づいて生成された各ＩＫＥフラグメントは、ＩＫＥヘッダを有する。加えて、伝送ノードはさらに、各ＩＫＥフラグメントに関するＵＤＰヘッダを含む。ＵＤＰヘッダは、ＮＡＴ、ファイヤウォールおよびその他の類似の装置がフラグメントを処理するための特定の情報を有する。したがって、本発明では、各ＩＫＥフラグメントはＮＡＴやファイヤウォールの処理で必要とされる情報を有することが保証され、ある種のＮＡＴやファイヤウォールが自身のフラグメント化および再組み立ての処理を行う必要を軽減しおよび／またはあるいは回避する。
【００５５】
好ましい一実施形態では、送信器モジュール１５１は、意図された受信ノードにフラグメントを伝送した後、応答待ちのタイマを設定する（ステップ１９０）。送信器モジュール１５１はまた、応答モジュールが否定応答（ｎｏ  ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）メッセージ（ＮＡＫ）を送信したか否かを決定するため調査する（ステップ１９１）。ＮＡＫが、以下に記載する条件に基づいて、受信ノードによって送信され、および送信ノードによって受信された場合、適当なフラグメントが再送される（ステップ１９２）。送信器モジュール１５１は、ＮＡＫが受信されるかタイマが切れるまで応答を待ちつづける（ステップ１９３）。タイマが切れた場合、全てのフラグメントが、また再送され新たにタイマが設定される（ステップ１９０）。
【００５６】
フラグメントを伝送し、タイマを設定する処理（ステップ１９０）、ＮＡＫが受信されたか否かを判断する処理（ステップ１９１）およびタイマが切れたか否かを判断する処理（ステップ１９３）の各処理は、応答が受信されるまで続けられる。これを一定の回数繰り返した後、送信器モジュールは、結局、フラグメントされたＩＫＥペイロードを伝送しようとする処理を断念する。これは、ステップ１９３における破線で示される。
【００５７】
しかし、応答が受信されると、送信処理の最後のステップであるステップ１９４では、それが元のＩＫＥペイロードに対する適正な応答であるか否かが判断される。そうである場合、制御はＩＫＥプロトコルスタックに引き渡され、そのプロトコルにしたがって、再び処理が続けられる（ステップ１８３）。一方、応答ノードがまだ適当な応答をしていない場合（ステップ１９４）、フラグメント部１５０は、ＳＡを確立する処理を断念する（ステップ１８７）。この好ましい実施形態では、フラグメント部１５０は、全ての処理を打ち切る前に２回または３回以上、全てのフラグメントを再送する。したがって、適当な応答が、ステップ１９４において受信されない場合、送信器モジュール１５１は、処理を打ち切る前に予め定められた回数ステップ１９０に戻ることになる。
【００５８】
図９は、受信ノード、特に受信モジュール１５２上に、フラグメント部１５０を実装するコードモジュールの論理フローを示す図である。図８の場合と同様、このフロー図は、ある好ましい実施形態のために提供されるものであり、当業者が理解し得る、全ての変更可能な形態を包含するものではないことが理解されなければならない。さらに、図９で特定されるステップは、フラグメント部１５０内の送信器モジュール１５１および／または受信モジュール１５２によって実行することができることが理解されるべきである。
【００５９】
図９に示される最初のステップは、フラグメント部１５０内の受信モジュールに対する最初のオペレーションである必要はないが、本発明に基づいてフラグメント化されるＩＫＥメッセージを扱うための容量を公開（ｐｕｂｌｉｓｈ）する（ステップ１９６）。このステップは、この好ましい実施形態では、受信ノードのベンダＩＤを伝送することによって実行される。これと代えて、特定のクエリに対する応答であるか否かによらず、フラグメント部１５０の受信モジュール１５２が、フラグメントされたＩＫＥペイロードを扱う能力を示す特定のメッセージを伝送することが可能である（図示せず）。このステップは、始動ノードがＳＡを確立しようとする場合の初期に、あるいは問題を検出したときにのみ実行することができる。
【００６０】
フラグメント部モジュール１５０の好都合な配置のため、その受信モジュール１５２は、ＩＫＥプロトコルスタック１２７を宛先とする全てのパケットを受信またはインターセプトする。元のＩＫＥペイロードがフラグメント化されることなく的確に受信される場合、受信モジュールは通常の処理を行い、元のペイロードを応答ノードのＩＫＥプロトコルスタック１２７まで通過させる（ステップは図示せず）。しかし、本発明に基づいてフラグメント化された全てのＩＫＥパケットは、受信モジュール１５２によりインターセプトされ、および消費される（ステップ１９７）。その後、受信モジュール１５２は、それ自身で、フラグメントのメタデータを用いてフラグメントを処理する。
【００６１】
本発明の一実施形態で、受信モジュールは、受信したフラグメントのフラグメント識別子（フラグメントＩＤ）を確認する（ステップ１９８）。上述のデータ構造は、このステップで使用することができるフラグメントＩＤのためのフィールドを含む。単一のフラグメント化されていないＩＫＥペイロードに相当する各フラグメントは、同一のフラグメントＩＤを有する。フラグメント部１５０の受信モジュールは、適当なフラグメントＩＤを含まない如何なるパケットフラグメントも廃棄する（ステップ１９９）。好ましい一実施形態の受信モジュールは、他の処理を行う前には、それがフラグメント化されたＩＫＥペイロードであっても、時間内であればいつでも、予め定められた数のＩＫＥペイロードのみ処理することができる。ある好ましい実施形態では、この予め定められた数は１である。したがって、受信モジュールは、単一のＩＫＥペイロードに相当する全てのフラグメント、すなわち同一のフラグメントＩＤを持つ全てのフラグメントを受信した後でなければ、異なるフラグメントＩＤを持つフラグメントの処理をしようとすることはできない。
【００６２】
さらに、本発明の好ましい一実施形態に含まれる受信モジュール１５２は、各受信したフラグメントのシーケンス番号を検査して、そのフラグメントのシーケンス番号が正しい順序であるか否かを判断する（ステップ２００）。正しい順序であれば、そのフラグメントは更なる処理のためにバッファに格納される（ステップ２０３）。正しい順序でなければ、受信モジュールは、順序違いエラーの状態と評価する（ステップ２０１）。このステップでは、受信モジュールは、一定のフラグメントを格納する、廃棄する、および／または始動ノードにＮＡＫメッセージを送信するか否かを決定する。例えば、２番目ではないシーケンスの中の最初と３番目のフラグメントを受信した場合、受信ノードは、適当なフラグメントが再送されるように、始動ノードにある送信器モジュール１５１にＮＡＫを送信することができる（ステップ１９２）。一方、事前に受信したフラグメントと同一のシーケンス番号を含むフラグメントを受信した場合、受信モジュール１５２は、そのフラグメントまたは特定のフラグメントＩＤを含む全てのフラグメントを廃棄することができる。さらにもう１つの選択肢として、受信モジュールは、一連の予め定められた規則にしたがって、更なる処理のために、その順序違いのフラグメントを格納すべきであると決定することができる（ステップ２０３）。この最後の選択肢では、以前に受信したフラグメントのシーケンス番号と異なるシーケンス番号を有する少なくとも１つのフラグメントを少量でも格納することが望ましいであろう。順序違いのフラグメントのいずれを格納し、いずれを廃棄すべきかを決定するための規則は、特定のシステムの所望の応答に依存して作成し、柔軟に適用することができる。
【００６３】
フラグメントが格納された後、受信モジュール１５２は、受信されおよび格納されたフラグメントの全体の長さが、予め定められたサイズの閾値を超えているか否かを判断するであろう（ステップ２０４）。好ましい一実施形態で、任意の所与のIKEペイロードについての最大サイズから、この閾値は６４Kバイトである。この判断は、柔軟に実装および変更され、サービス妨害攻撃またはその他類似の攻撃、例えば仲介者攻撃に付随する攻撃などを回避しまたは軽減することができる。全体のサイズの制限を越える場合、受信モジュール１５２は、同じフラグメントIDを有する全てのフラグメントを廃棄する(ステップ１９９)。
【００６４】
その後、受信モジュール１５２は、格納されたフラグメントのフラグを評価し、それがフラグメントのシーケンスの最後であるか否かを決定する。そうでない場合、受信モジュール１５２は次のフラグメントの待ちに戻る(ステップ１９７)。シーケンスの最後のフラグメントの場合、受信モジュール１５２は、次に、あるフラグメントＩＤに相当するフラグメントがすべて受信されたか否かを決定する(ステップ２０６)。あるＩＫＥペイロードに含まれるフラグメントがすべて受信されてはいない場合、受信モジュール１５２は、再び更なるフラグメントの待ちに戻る(ステップ１９７)。入力されたパケットは、あるＩＫＥペイロードに相当する全てのフラグメントが受信されるか、または新たなフラグメントＩＤを有するフラグメントが受信されるまで、上述のように評価される。後者の場合、上述のように、その時点の組み立てられたフラグメントは、ステップ１９８および１９９にしたがって廃棄される。しかし、そのシーケンスの全てのフラグメントが受信される場合、パケットは正確な順序で組み立てられる(ステップ２０７)。パケットを組み立てるこのステップには、フラグメント化の処理に関する全てのデータのストリッピングを含む、元のＩＫＥペイロードの再パッケージ化（ｒｅｐａｃｋａｇｅ）のために必要な全てのオペレーションが含まれると理解されなければならない。最後のステップ２０８では、受信モジュール１５２は、その通常の処理のため、再組み立てされたＩＫＥペイロードをＩＫＥプロトコルスタック１２７に送る。
【００６５】
上述の好ましい実施形態において、受信モジュール１５２は、より後の時間のフラグメントＩＤを持つフラグメントを受信する場合、組み立て中のフラグメントを廃棄するであろう。言い換えれば、ある時点で処理されるのは１つのＩＫＥペイロードのみである。この処理は、セキュリティを最大化し、サービス妨害攻撃やその他の同様の攻撃の影響を軽減する。しかし、これに代わる実施形態においては、１つ以上のＩＫＥペイロードを受信モジュール１５２によって処理することができるであろう。例えば、固定の数、２、３、１５、２７個などのＩＫＥペイロードが、受信されたものとして追跡することができる。
【００６６】
さらに、受信モジュール１５２のもう１つの可能な実施形態においては、フラグメントデータのコンテンツが検証され、既知の手法によって事前に再組み立てされる。この検証は、受信されるフラグメントが有効なピアから伝送されたもであるか否かを、受信処理の早い段階において、判断する助けとなる。
【００６７】
以上により、ＩＫＥメッセージを伝送するための新しい有用な方法と装置が提供されたことを理解することができる。本発明の原理を適用することができる多くの可能な実施形態に鑑み、図面に関連して本明細書に記載された実施形態は単なる例示の意味しかもたず、本発明の範囲を限定するものと取るべきではないことが理解されなければならない。例えば、当業者は、ソフトウェアとして例示された実施形態の一部はハードウェアに実装することあるいはその逆が可能であり、また例示された実施形態は、本発明の精神から離れない限り調整や細部への変更を加えることができるであろう。したがって、本明細書に記載された本発明は、特許請求の範囲およびその均等の範囲内にある全ての実施形態を意図したものとなる。
【図面の簡単な説明】
【図１】実施例にかかるコンピュータネットワークを示すブロック図である。
【図２】実施例にかかるコンピュータを示すブロック図である。
【図３】コンピュータにネットワークを介して通信することを可能にする、論理デバイス、アプリケーションおよびプログラムされたコードモジュールを示す図である。
【図４】ＩＳＡＭＫＰおよびＩＫＥプロトコルにしたがって交換される、典型的な一組のメッセージを示す図である。
【図５】本発明の好ましい実施形態を実現するコードモジュール間の論理的関係を示す図である。
【図６】ＩＫＥのＩＤパケットを示す図である。
【図７】ＩＫＥのＩＤパケットがフラグメント部によってフラグメント化されたものを示す図である。
【図８】フラグメント部を実現するコードモジュールの論理フローを示す図である。
【図９】受信ノード、特に受信モジュール上に、フラグメント部を実装するコードモジュールの論理フローを示す図である。
【符号の説明】
１００  コンピュータ
１０２  ネットワーク
１０６  コンピュータ内の基本的構成
１１２  プロセシングユニット
１１４  メモリ
１１８  ディスプレイ
１２０  論理デバイス、アプリケーションおよびコードモジュール
１２１  物理的コンポーネント／ハードウェアコンポーネント
１２２  ネットワークＩＰスタック
１２３  送信制御プロトコルスタック
１２４  ユーザデータグラムプロトコルスタック
１２５  インターネット制御メッセージプロトコルスタック
１２６  アプリケーションおよび高レベルのサービスレイヤ
１２７  ＩＫＥプロトコルスタック
１３１  始動ノード
１３２  応答ノード
１３４  最初のＩＫＥプロトコルメッセージの組
１３５、１３６、１３９、１４０、１４３、１４４  メッセージ
１３８  次のＩＫＥプロトコルメッセージの組
１４２  最後のＩＫＥプロトコルメッセージの組
１５０  フラグメント／再組み立て部コードモジュール
１５１  伝送モジュール
１５２  受信モジュール
１６０  ＩＫＥのＩＤパケット
１６１  ＩＫＥヘッダ
１６２  データ
１７１、１７４、１７６  フラグメント
【図１】
0004271451.tif 000003
【図２】
0004271451.tif 000004
【図３】
0004271451.tif 000005
【図４】
0004271451.tif 000006
【図５】
0004271451.tif 000007
【図６】
0004271451.tif 000008
【図７】
0004271451.tif 000009
【図８】
0004271451.tif 000010
【図９】
0004271451.tif 000011