JP4426443B2 - ネットワークを経て通信するための改善セキュリティ方法及び装置 - Google Patents

Description

発明の分野

本発明は、一般に、ネットワークを経て通信するための改善セキュリティ(enhanced security)に係る。

発明の背景

インターネットは、いまだに成長を続けるパブリックネットワークである。多くの会社は、自身の営業活動を容易にするためにインターネットを経ての通信に依存している。しかしながら、パブリックアクセスは、セキュリティの危険も伴う。インターネットにおけるセキュリティを改善するために、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）は、インターネットプロトコルセキュリティ（「ＩＰＳｅｃ」）として集合的に知られている１組のプロトコルを設計した。このＩＰＳｅｃは、インターネット等のネットワークを経て通信するための認証及び暗号化を与えるように設計されている。ネットワークアドレス変換（ＮＡＴ）も、インターネットの成長における大きな要因となっているが、不都合なことに、ＮＡＴのオペレーションは、ＩＰＳｅｃと合致していない。

ＮＡＴは、ローカル内部ネットワークトラフィックに使用される１つ以上のプライベートＩＰ（インターネットプロトコル）アドレスのセットと、内部アドレスが外部マシンとトラフィックを交換したいときに動的に選択されるべき１つ以上の「パブリック」ＩＰアドレスとの間を変換する。ＮＡＴゲートウェイにおける変換テーブルは、組織のインターネットトラフィックが、その組織に指定された１つ（又はそれ以上）のパブリックアドレスを共有するのを許す。新たな接続のための出て行くパケットは、新たなＮＡＴ変換テーブルエントリーをゲートウェイに生成させる。ＮＡＴ変換テーブルは、逆方向に到着するトラフィック（即ち、パブリックインターネットから到来するトラフィック）に対して逆変換を実行するように使用される。

ＬＡＮのクライアントコンピュータは、静的に指定されたローカルＩＰアドレスを有してもよいが、従来、ダイナミックホストコンフィギュレーションプロトコル（ＤＨＣＰ）サーバーエンティティが、ＬＡＮのクライアントコンピュータにプライベートＩＰアドレスを動的に指定する。このようなプライベートアドレスは、使用可能なプライベートＩＰアドレスのプールから独特に選択される。ＤＨＣＰサーバープロセスは、しばしばＮＡＴゲートウェイに同一配置されるが、プライベートネットワーク内の個別装置においてホストとすることができる。従って、例えば、ＮＡＴゲートウェイに対して（「背後の」）ローカル又はプライベートドメインの一部分であるクライアントコンピュータ又は他のローカルマシンからのＩＰパケットは、ＩＰソース及び行先アドレスをパケットのＩＰヘッダに含むと共に、ソース及び行先ポートアドレスをパケットのユーザデータグラムプロトコル又は送信制御プロトコル（ＵＤＰ又はＴＣＰ）ヘッダに含む。従来、パケットのＩＰソースアドレスフィールドは、クライアントコンピュータに静的に又は動的に指定されたプライベートＩＰアドレスを含むが、パケットのＩＰ行先アドレスフィールドは、ＮＡＴゲートウェイの背後にある別のマシンを行先とするパケットについてはプライベートＩＰアドレスを含み、或いはインターネットに接続されたリモートコンピュータのような、ＮＡＴゲートウェイの背後にない別のマシンを行先とするパケットについてはパブリックＩＰアドレスを含む。

後者の例では、ＮＡＴゲートウェイは、出て行くパケットのＩＰソースアドレスフィールドを、ローカルに独特のプライベートＩＰアドレスから、パブリック又はグローバルに独特のＩＰアドレスに変更する。パケットの新たなソースアドレス、ここではパブリックＩＰソースアドレスは、従来、ＮＡＴゲートウェイの外部インターフェイスのＩＰアドレスであるか、又はＮＡＴゲートウェイにより管理される使用可能なパブリックアドレスのプールから割り当てられたＩＰアドレスである。

更に、ＮＡＴゲートウェイは、更に多くの接続が同じＩＰアドレスを共有するのを許すために、トランスポート層アドレス（即ちＴＣＰ又はＵＤＰポート）の変換を必要とすることがある。ＮＡＴゲートウェイが、それ自身のパブリックＩＰアドレスを、ローカルマシンから出て行くパケットに対するパブリックＩＰアドレスとして使用する場合には、外部接続がＮＡＴゲートウェイコンピュータから出て来るように見える。２つのローカルクライアントマシンが同じリモートＩＰアドレスと通信して同じ行先ＴＣＰ又はＵＤＰポートを選択し、どのクライアントがトラフィックを返送すべきかＮＡＴゲートウェイが決定できないようにするのを防止するために、ＮＡＴゲートウェイコンピュータの各接続を変換して、出て行くトラフィックが、独特に識別可能なＩＰパブリックアドレス及びＴＣＰ又はＵＤＰソースポート対から出て来るように見えるようにする。このような事態が生じる機会は、微々たるものと思われるが、特に、ローカルクライアントの数が増加するにつれて考えられ、ＩＰアドレス変換に加えてＴＣＰ又はＵＤＰポート変換を実行することにより回避できる状態である。ＮＡＴゲートウェイは、プライベート／パブリックＩＰアドレス関連性だけでなく、到来するトラフィックを変換及び転送するためのＴＣＰ又はＵＤＰポート関連性も記憶するので、ＮＡＴは、時々、ネットワークアドレス及びポート変換（ＮＡＰＴ）とも称される。

ＩＰＳｅｃは、改善セキュリティを要求する接続を支配するパラメータのネゴシエーションに一部依存する。ピアステーション間のネゴシエーションされたセキュリティパラメータを支配する他の既知のアイテムの中でも、認証及び／又は暗号化セッションキー、キーライフライム、暗号化又は認証アルゴリズムのような例示的アイテムを含むパラメータの集合は、セキュリティアソシエーション（ＳＡ）として集合的に知られている。ＳＡネゴシエーションは、オークリーキー決定アルゴリズムを使用するインターネットセキュリティアソシエーション及びキーマネージメントプロトコル（ＩＳＡＫＭＰ）として知られているプロトコルに基づいて実行される。ＩＳＡＫＭＰ／オークリーは、より一般的には、インターネットキー交換（ＩＫＥ）として知られている。ＩＫＥネゴシエーションの１つの結果は、暗号化及び暗号解読、及び／又はデジタル符牒メッセージ（即ちＩＰパケット）に使用されるべきランダム選択セッションキーに対するプライベートアグリーメントである。ＩＳＡＫＭＰ、ＩＰＳｅｃ制御プロトコルに対してＵＤＰポート５００が指定される。

ＩＰＳｅｃ保護のＩＰパケットは、ＩＫＥにおいて認証がネゴシエーションされたか、暗号化がネゴシエーションされたか又はその両方がネゴシエーションされたかに基づいて、ＩＰＳｅｃセキュリティプロトコルヘッダの２つの形式の少なくとも１つを合体する。これらＩＰＳｅｃセキュリティプロトコルヘッダを明瞭化のために要約すると、認証がネゴシエーションされたときには「認証ヘッダ」（ＡＨ）が使用され、暗号化がネゴシエーションされたときには「カプセル化セキュリティペイロード」（ＥＳＰ）ヘッダが使用され、ＩＰパケットがＡＨ及びＥＳＰの両ヘッダを含むとき、例えば、ＥＳＰがＡＨと共にネゴシエーションされたときには、ＥＳＰヘッダをカプセル化するＡＨが使用される。

ＩＰＳｅｃセキュリティアソシエーションが確立されると、各ＩＰＳｅｃ保護のパケットのインターネットプロトコルヘッダは、使用するセキュリティプロトコルの形式、即ちＡＨ又はＥＳＰ、その組合せを含む、を指定する。ＩＰバージョン４（「ＩＰｖ４」）では、ＩＰｖ４ヘッダに８ビットの「プロトコル」フィールドがあり、これは、論理的にＩＰ層の上にある次の上位層プロトコルを指示する。ＩＰバージョン６（「ＩＰｖ６」）では、ＩＰｖ４ヘッダにおけるプロトコルフィールドと同様の機能を果たす８ビットの「次のヘッダ」フィールドがある。ＩＰｖ４及びＩＰｖ６の両方において、０ｘ３２の値は、ＥＳＰを意味し、そして０ｘ３３は、ＡＨを意味する。ＡＨ及びＥＳＰの両ヘッダは、セキュリティパラメータインデックス（ＳＰＩ）として知られている数値に対して３２ビットフィールドを含む。ＩＰパケットにデジタル符牒が付けられた（ＡＨを使用して）場合には、このようなＩＰパケットのＩＰヘッダのある重要な部分を変更しなくてもよく、さもなければ、このようなＩＰパケットを受信するＩＰＳｅｃピアステーションは、ＩＰパケットのデジタル符牒が正しいことを確認できない。しかし、従来のオペレーション中には、ＮＡＴゲートウェイが、出て行く（即ちローカルからリモート又はプライベートからパブリックへの）パケットに対するパケットのＩＰソースアドレス、又は到来する（即ちリモートからローカル又はパブリックからプライベートへの）パケットに対するパケットの行先アドレスを変更する。いずれの方向においても、ＩＰヘッダのＮＡＴ変換は、ＡＨデジタル符牒を確認するＩＰＳｅｃピアステーションの能力を妨げる。出て行くトラフィックの例では、介在するＮＡＴゲートウェイ又はルーターがパケットのプライベートＩＰソースアドレスをグローバル又はパブリックＩＰアドレスに変換すると、受信側コンピュータにおける認証が失敗となる。というのは、プライベートＩＰアドレスが、デジタル符牒の確認に、受信器にもはや得られないからである。これまで、ＮＡＴゲートウェイを経て移動する間にＩＰパケットに必要な変更がなされるために、ＩＰＳｅｃ ＡＨがＮＡＴに適合しない。

暗号化されたが符牒が付けられないパケット（即ちＡＨを伴わずにＥＳＰにより保護されたＩＰＳｅｃパケット）の場合には、トランスポート層ヘッダが、ＮＡＴゲートウェイを含む第三者に暗号解読できず（たとえ暗号解読できてもパケット内の通常の位置にはなく）、従って、出て行く及び／又は到来する変換のプロセスに使用するためのＴＣＰ又はＵＤＰポート番号がＮＡＴゲートウェイに得られない。従って、ＩＰＳｅｃ ＥＳＰ単独（即ちＡＨを伴わずにＥＳＰのみ）でも、認証ヘッダの存在に関わらず、基本的ＮＡＴオペレーションの妨げとなる。拡張すると、ＡＨ及びＥＳＰの両方で保護されたＩＰパケットの場合、そのソースＩＰアドレスは変更しなくてよいが、ポート番号が暗号化される。

要約すれば、ＩＰパケットには、ＡＨヘッダ、ＥＳＰヘッダ又はその両方が追加されてもよい。ＮＡＴについて重要なこととして、ＡＨ保護されたパケットのＩＰソースアドレスフィールドは、デジタル符牒アルゴリズムへの入力の一部分であるので、変更できない。ＥＳＰ保護されたパケットについて重要なこととして、ピアステーションが受信パケットを暗号解読する能力を妨げずにＩＰソースアドレスを変更してもよいが、ソース及び行先ポート番号が暗号化され、従って、ＮＡＴゲートウェイにより暗号解読することができない。従って、ＥＳＰについては、ＮＡＴゲートウェイによりＴＣＰ又はＵＤＰポート番号を暗号解読できないので、これまで、戻りトラフィックルートを明確にし、即ちＥＳＰ保護されたパケットをどのプライベートステーションが受信すべきか決定するメカニズムが存在しない。更に、バーチャルプライベートネットワーク（ＶＰＮ）に対するＥＳＰ保護されたトラフィックは、これまで、ＶＰＮセッションの数を同じリモートＩＰアドレスに制限するか、或いは当該非標準変更をＶＰＮクライアントに制限していた。

従って、著しいオーバーヘッドを追加することがなく、且つＩＰＳｅｃのセキュリティアルゴリズムに適合しないＩＰソース又は行先アドレス及び／又はＴＣＰ又はＵＤＰソース又は行先ポート変換を必要とすることもないＮＡＴ及びＩＰＳｅｃの一体化を提供することが要望され且つ有用となる。

発明の概要

本発明の態様は、アドレス変換構成のゲートウェイコンピュータの背後にあるクライアントコンピュータと、リモートコンピュータとの間でネットワークを経て通信するときの改善セキュリティ方法に係る。ゲートウェイコンピュータのクライアントコンピュータにはパブリックアドレスが与えられ、このパブリックアドレスは、ゲートウェイコンピュータパブリックアドレスと、ゲートウェイコンピュータパブリックアドレスのプールとの一方である。ゲートウェイコンピュータは、リモートコンピュータとのセキュリティアソシエーションネゴシエーションに参加する。ゲートウェイコンピュータは、クライアントコンピュータのローカルアドレスをリモートコンピュータの行先アドレスに関連して記録するための指示子としてセキュリティアソシエーションネゴシエーションを使用し、ローカルアドレス及び行先アドレスは、セキュリティアソシエーションネゴシエーションから得られて、ゲートウェイコンピュータによりアクセスできるデータ構造体に記憶される。

本発明の別の態様は、インターネットプロトコルセキュリティ（ＩＰＳｅｃ）パケットをネットワークアドレス変換（ＮＡＴ）ゲートウェイコンピュータで処理するための方法に係る。ＩＰＳｅｃパケットのためのパブリックインターネットプロトコル（ＩＰ）ソースアドレスをＮＡＴゲートウェイコンピュータで指定できることをＮＡＴゲートウェイにおいてチェックし、そしてパブリックＩＰソースアドレスをＮＡＴゲートウェイコンピュータにより指定できることに応答して、ＩＰＳｅｃパケットがローカルコンピュータにより送信されたものかどうかの確認がなされる。ＩＰＳｅｃパケットがローカルコンピュータにより送信されたという確認に応答して、ＩＰＳｅｃパケットは、パブリックＩＰソースアドレスを変換せずに行先アドレスへ送信される。

本発明の別の態様は、ソースアドレス及びゲートウェイコンピュータのパブリックアドレスを有する受信パケットをルーティングするための方法に係る。ゲートウェイコンピュータのパブリックアドレスに関連してリストされたマッピングテーブルのソースアドレスについてチェックし、受信パケットからセキュリティパラメータインデックスを得る。マッピングテーブルのセキュリティパラメータインデックスが受信パケットのソースアドレスに関連していることをチェックする。マッピングテーブルのセキュリティパラメータインデックスが受信パケットのソースアドレスに関連しているのを見つけるのに応答して、受信パケットは、マッピングテーブルにおけるセキュリティパラメータインデックス及びソースアドレスに関連したローカルアドレスへルーティングされ、ここで、ローカルアドレスは、ゲートウェイコンピュータのパブリックアドレスではない。

本発明の別の態様は、インターネットキー交換（ＩＫＥ）制御方法に係る。マッピングテーブルと共に構成されたゲートウェイコンピュータが設けられる。ローカルクライアントコンピュータからゲートウェイコンピュータにパケットが受け取られ、このパケットがＩＫＥパケットであるかどうか決定するためのチェックがなされる。パケットがＩＫＥパケットであるのに応答して、マッピングテーブルにおけるＩＫＥパケットのインターネットプロトコル（ＩＰ）行先アドレス及びローカル媒体アクセス制御（ＭＡＣ）アドレスの両方に一致するマッピングテーブルの記録に対してチェックが行われる。マッピングテーブルの記録を識別するのに応答して、マッピングテーブルの記録に関連したセキュリティパラメータインデックスについてチェックが行われる。

本発明の別の態様は、ゲートウェイコンピュータのためのセキュリティネゴシエーション制御方法に係る。ゲートウェイコンピュータには、データ構造体へのアクセスが与えられる。ゲートウェイコンピュータにおいてパケットが受信され、そのパケットがセキュリティネゴシエーションパケットであるかどうか決定される。データ構造体は、パケットがセキュリティネゴシエーションの一部分であることに応答して、媒体アクセス制御（ＭＡＣ）ソースアドレス及び行先アドレスについてチェックされる。データ構造体に行先アドレスが見つかり且つデータ構造体にその行先アドレスに関連したＭＡＣソースアドレスが見つからないのに応答して、行先アドレスのセキュリティ値がデータ構造体にあるかどうか決定される。行先アドレスのセキュリティ値がデータ構造体に見つからないのに応答して、セキュリティネゴシエーションパケットの送信が抑制される。

本発明の別の態様は、クライアントコンピュータによってパケットを形成する方法に係る。ネットワークアドレス変換ゲートウェイコンピュータからクライアントコンピュータに対するパブリックアドレスが得られる。得られたパブリックアドレスは、パケットに対するソースアドレスとして使用される。

本発明の別の態様は、インターネットプロトコルセキュリティ（ＩＰＳｅｃ）保護されたパケットとのネットワークアドレス変換（ＮＡＴ）一体化のためのマッピングテーブルを生成する方法に係る。ゲートウェイコンピュータには、マッピングテーブルへのアクセスが与えられる。ゲートウェイコンピュータにおいて、媒体アクセス制御アドレスに関連したクライアントコンピュータからパケットが受信され、媒体アクセス制御アドレスは、パケットのソースアドレスに加えて、パケットと共に送信される。ソースアドレスは、ゲートウェイコンピュータのパブリックアドレスである。ゲートウェイコンピュータは、パケットがセキュリティネゴシエーションパケットであるかどうか決定し、そしてパケットがセキュリティネゴシエーションパケットであるのに応答して、媒体アクセス制御アドレスは、この媒体アクセス制御アドレスに関連したパケットの行先アドレスと、これら媒体アクセス制御アドレス及び行先アドレスの少なくとも一方に関連したイニシエータ指示子と共に、マッピングテーブルに記録される。

本発明の別の態様は、認証ヘッダ（ＡＨ）保護されたパケットとのネットワークアドレス変換（ＮＡＴ）一体化のための方法に係る。クライアントコンピュータには、ＮＡＴゲートウェイコンピュータからのパブリックアドレスが与えられる。クライアントコンピュータは、パブリックアドレスをソースアドレスとしてもつＡＨ保護のパケットを形成し、そのＡＨ保護のパケットをクライアントコンピュータからＮＡＴゲートウェイコンピュータへ送信する。

本発明の別の態様は、ゲートウェイコンピュータのためのデータ構造体に係る。媒体アクセス制御アドレスフィールドと、この媒体アクセス制御アドレスフィールドに関連したローカルパブリックアドレスフィールドと、媒体アクセス制御アドレスフィールドに関連した非ローカルアドレスフィールドと、この非ローカルアドレスフィールドに関連したセキュリティパラメータインデックスフィールドとが設けられる。このセキュリティパラメータインデックスフィールドは、非ローカルマシンからの通信に関連したセキュリティパラメータインデックスを記憶するためのものである。

本発明の別の態様は、ネットワークアドレス変換がソースアドレスセキュリティと一体化されたかどうか決定するためにクライアントコンピュータによりゲートウェイコンピュータを探査する方法に係る。第１クライアント識別子をもつクライアントコンピュータによりゲートウェイコンピュータについて第１アドレスに対する第１要求がなされる。この第１要求に応答してゲートウェイコンピュータにより第１アドレスが送信される。第２クライアント識別子をもつクライアントコンピュータによりゲートウェイコンピュータから第２アドレスについて第２要求がなされ、ここで、第２クライアント識別子は、第１クライアント識別子と同様である。第２アドレスは、第２要求に応答してゲートウェイコンピュータからクライアントコンピュータにより受信される。クライアントコンピュータは、要求された第２アドレスから、ネットワークアドレス変換がゲートウェイコンピュータに対するソースアドレスセキュリティと一体化されたかどうか決定する。

本発明の別の態様は、ソースアドレス保護のパケットに対するネットワークアドレス変換方法に係る。クライアントコンピュータは、アドレスサーバーコンピュータと通信するように設けられる。クライアントコンピュータからの第１要求が、アドレスサーバーコンピュータからの第１アドレスに対してなされ、クライアントコンピュータは、アドレスサーバーコンピュータにより媒体アクセス制御番号で識別できる。この第１要求に応答してアドレスサーバーコンピュータによりクライアントコンピュータにプライベートアドレスが与えられる。媒体アクセス制御番号の変更がクライアントコンピュータにより発生され、変更された媒体アクセス制御番号が与えられる。アドレスサーバーからの第２アドレスがクライアントコンピュータにより要求され、クライアントコンピュータは、アドレスサーバーコンピュータにより、変更された媒体アクセス制御番号で識別できる。アドレスサーバーコンピュータは、媒体アクセス制御番号をその変更された媒体アクセス制御番号に関係付けることにより、クライアントコンピュータと第１要求及び第２要求とを関連付けると共に、第２要求に応答してパブリックアドレスをクライアントコンピュータに与える。

本発明の前記特徴、効果及び目的がいかに達成されるかを詳細に理解するために、前記で簡単に要約した本発明を、添付図面に示されたその実施形態を参照して詳細に述べる。

しかしながら、添付図面は、本発明の典型的な実施形態を示すに過ぎず、その範囲をこれに限定するものではなく、本発明は他のやり方でも等しく有効に実施できることに注意されたい。

詳細な説明

本発明は、ＩＰＳｅｃ及びＮＡＴを共存させる方法及び装置であって、クライアントコンピュータの外部を行先とするパケットがプライベートＩＰソースアドレスを使用しないように構成されたときに、ＩＰＳｅｃに適合しないＮＡＴのＩＰアドレス或いはＴＣＰ又はＵＤＰポート変換をパケットに対して実行する必要がないメカニズムを生成するような方法及び装置を提供する。むしろ、クライアントのＩＰＳｅｃソフトウェアは、その外部を行先とするパケットを、ＮＡＴ装置により与えられるパブリックＩＰアドレスを使用して生成する。

各リモートＩＰアドレスから各ローカルピアクライアントマシンへのトラフィックは、ＡＨ又はＥＳＰヘッダに独特のセキュリティパラメータインデックスを有し、これを、ＴＣＰ又はＵＤＰポートに代わって使用して、どのローカルステーションにＩＰＳｅｃ保護のパケットを送信すべきかＮＡＴが判断するのを許すことができる。各ローカルクライアントが１つのリモートＩＰアドレスに話をし、他のクライアントがその同じリモートＩＰアドレスに話をしない限り、変換は、ＩＰソースアドレスフィールドのみを含む従来のＮＡＴ変換でよい。しかしながら、多数のローカルクライアントマシンが、同じリモートＩＰアドレスと通信するように向けられた場合には、ＩＰＳｅｃ可能なＮＡＴゲートウェイは、ローカル／リモート対のマシン間で一度に１つのＳＡしかネゴシエーションされないよう確保するためにＩＫＥ抑制を実行する必要がある。セキュリティパラメータインデックスは、平文で使用されるが、プライベートにネゴシエーションされるという事実においてここには難解さが存在し、従って、ＮＡＴゲートウェイは、リモートステーションが第１のＩＰＳｅｃ保護のパケットをローカルステーションへ送信するまで使用中のネゴシエーションされたセキュリティパラメータインデックスへアクセスできない。そのセキュリティパラメータインデックスが分かると、他のローカルステーションは、そのリモートステーションとの自身のセキュリティアソシエーションを、一度に１つ、ネゴシエーションしてもよい。

本発明の一態様は、ＮＡＴゲートウェイがクライアントコンピュータとリモートコンピュータとの間に配置された状況においてＩＰＳｅｃのＡＨの使用を許すための方法に係る。クライアントコンピュータは、ゲートウェイコンピュータからのパブリックアドレスを要求し、それに応答して、パブリックアドレスがクライアントコンピュータへ与えられる。ＩＰＳｅｃセキュリティアソシエーションがリモートコンピュータとネゴシエーションされる。セキュリティアソシエーションのネゴシエーションは、クライアントのローカルアドレス（ＮＡＴ／ＡＨ共存の場合のそのＭＡＣアドレス、ＮＡＴ／ＥＳＰ共存の場合のそのプライベートＩＰアドレス）と、リモートコンピュータのＩＰアドレスとの間の関連性を記録するためのトリガーとしてゲートウェイコンピュータにより使用され、ここで、ローカルアドレス及び行先アドレスは、第１の出て行くセキュリティアソシエーションネゴシエーションパケットから得られる。リモートコンピュータとのセキュリティアソシエーションネゴシエーションから生じるセキュリティパラメータインデックス値は、将来使用するためのローカルアドレスに関連して得られて記憶され、即ちリモートステーションがＩＰＳｅｃ保護のトラフィックをローカルクライアントに向けて送信し始めるときに得られて記憶される。

本発明の一態様は、ゲートウェイコンピュータのためのデータ構造体に係る。このデータ構造体は、ローカルアドレス（媒体アクセス制御（ＭＡＣ）又はＩＰアドレス）フィールドと、前記ローカルアドレスフィールドに関連したリモートＩＰアドレスフィールドと、ローカルアドレスフィールドに関連したリモート対ローカルセキュリティパラメータインデックス（ＳＰＩ）フィールドと、リモートアドレスからローカルアドレスへ流れるトラフィックを特に識別するためのリモートアドレスフィールドとを備えている。リモート対ローカルＳＰＩフィールドは、リモート配置のマシンからの少なくとも１つのセキュリティパラメータインデックスを記憶するためのものである。

本発明の一態様は、インターネットキー交換（ＩＫＥ）抑制方法に係る。ゲートウェイコンピュータは、マッピングテーブルと共に構成される。受信したパケットは、ＩＫＥパケットであるかどうか決定するようにチェックされる。ＩＫＥパケットである場合には、マッピングテーブルをチェックして、行先（リモート）ＩＰアドレスが、パケットのソースＭＡＣ又はＩＰアドレスにも一致するマッピングテーブルのエントリーに一致するかどうか調べる。更に、ＩＳＡＫＭＰ「イニシエータクッキー」値（６４ビット）を、このマッピングテーブルのエントリー、即ちクライアントのＭＡＣ又はＩＰアドレスとリモートＩＰアドレスである一対のアドレスに一致するエントリー、との一致に対してチェックする。マッピングテーブルにおける一致するエントリーが見つかるのに応答して、ローカルクライアントとリモートＩＰアドレスとの間のセキュリティネゴシエーションが進行中であるか又は完了したという指示に対してチェックがなされる。リモート対ローカルのセキュリティパラメータインデックスがまだマッピングテーブルにない場合には、ＩＫＥパケットの送信が抑制される。

本発明の一態様は、ゲートウェイルーティング方法にある。リモート対ローカルパケットは、マッピングテーブルエントリーに対する有効なセキュリティパラメータインデックスが、パケットのリモートＩＰアドレス（リモート対ローカルパケットのＩＰソースアドレス）及びそのＩＰ行先アドレスに一致するかどうかについてチェックされ、これは、ゲートウェイマシンがローカルクライアントのＭＡＣアドレスを使用してマシンに割り当てたパブリックＩＰアドレスでなければならない。このリモートＩＰアドレスに関連した一致するリモート対ローカルセキュリティパラメータインデックスが見つかった場合には、マッピングテーブルのその行のコンテンツで指示されるように、そのパブリックＩＰ行先アドレス及びそのＭＡＣアドレス、又はそのプライベートＩＰアドレスを使用して、パケットがローカルクライアントへ転送される。プライベートＩＰアドレスフィールドがいっぱいになると、パブリックＩＰアドレス及びＭＡＣアドレスフィールドのコンテンツがブランクになる。

本発明の一態様は、ＮＡＴゲートウェイコンピュータによりＩＰＳｅｃのＡＨパケットを処理するための方法に係る。ローカル対リモートのＩＰＳｅｃパケットに対するＩＰソースアドレスフィールドは、パケットのＭＡＣソースアドレスフィールドに見つかったＭＡＣアドレスを処理するステーションに指定されたプライベートアドレスを含むかパブリックアドレスを含むかを調べるようにチェックされる。パケットのＩＰソースアドレスがパブリックアドレスであることをゲートウェイが発見し、このパブリックアドレスは、パケットのＭＡＣソースアドレスフィールドにおけるＭＡＣアドレスと同じＭＡＣアドレスを有するマシンに指定したものであることもゲートウェイが知っている場合には、ＩＰＳｅｃパケットは、ＮＡＴゲートウェイコンピュータにより不変のまま（ＩＰｖ４パケットの場合にはＴＴＬを減少し、ＩＰチェック和を更新することを除いて；ＩＰｖ６パケットは、ＮＡＴが要求されないほど豊富であり、従って、ＩＰｖ６の場合ＩＰＳｅｃ対ＮＡＴの問題はない）送信される。

リモート対ローカルＩＰＳｅｃパケットのＩＰソースアドレスフィールドは、マッピングテーブルにおけるリモートＩＰアドレス列に対して一致がとられ、パケットのＳＰＩは、このリモートＩＰアドレスに関連したマッピングテーブルの行に記憶された予想されるリモート対ローカルＳＰＩに対して一致がとられる。一致するマッピングテーブルエントリーが見つかった場合は、マッピングテーブルの一致する行から抽出されたローカルクライアントのＭＡＣアドレス（又はプライベートＩＰアドレス）へパケットが転送される。

以下の説明では、本発明をより完全に理解するために多数の特定の細部について述べる。しかしながら、当業者であれば、本発明は、これら特定の細部の１つ以上を伴わずに実施できることが明らかであろう。他の場合に、本発明が不明瞭になるのを回避するために良く知られた特徴は説明しない。

図１は、本発明の１つ以上の態様に基づくコンピュータシステム１０の実施形態を示すブロック図である。このコンピュータシステム１０は、ＣＰＵ１１と、システムメモリ１３と、入力／出力（Ｉ／Ｏ）インターフェイス１２と、ＮＩＣ１００とを備えている。ＮＩＣ１００は、Ｉ／Ｏとしてネットワーク１１０から／へ結合されてもよい。ＮＩＣ１００は、ローカルメモリ１１２を含む。

図２は、本発明の１つ以上の態様に基づくネットワーク１１０の実施形態を示すネットワーク図である。ネットワーク１１０は、ワイドエリアネットワーク（ＷＡＮ）１０４を備えている。このＷＡＮ１０４は、インターネットでもよいし、インターネットサブネットワーク（「サブネット」）でもよいし、又は他のワイドエリアネットワークでもよい。１つ以上のコンピュータシステム１０１をＷＡＮ１０４に時々ログオンすることができる。重要なことに、１つ以上のコンピュータシステム１０１がサーバーとなってもよい。更に、ＤＨＣＰサーバー／ＮＡＴゲートウェイ（「ゲートウェイ」）１０６及び１０７は、各々ＬＡＮ１０２及び１０３に結合される。クライアントコンピュータ１０６−Ａ、１０６−Ｂ及び１０６−Ｃは、ＬＡＮ１０２を経てゲートウェイ１０６との通信状態に入ってもよい。同様に、クライアントコンピュータ１０７−Ａ、１０７−Ｂ及び１０７−Ｃは、ＬＡＮ１０３を経てゲートウェイ１０７との通信状態に入ってもよい。ＮＡＴゲートウェイ１０６及び１０７は、ルーター１０８を経てＷＡＮ１０４に結合されてもよい。或いはまた、ゲートウェイ１０６及び１０７は、ゲートウェイ−ルーター、即ちＮＡＴゲートウェイとルーターとの組合体でもよく、また、その一体化装置にＤＨＣＰサーバーファンクションが組み込まれてもよい。

ネットワーク１１０は、単なる実施例に過ぎず、より少数の又は多数のコンピュータ、ゲートウェイ、ＬＡＮ又はＷＡＮ、及びその組合体が使用されてもよい。更に、クライアントコンピュータ１０６−Ａ、１０６−Ｂ及び１０６−Ｃは、その各々がＮＩＣ１００をローカルメモリ１１２と共に有するという点で図１のコンピュータシステム１０と同様に構成されてもよい。明瞭化のため、他の構成体をここに述べるように使用してもよいが、この説明の残り部分は、リモートサーバー１０１と通信するためにルーター１０８を経てインターネット１０４に結合されたＤＨＣＰ／ＮＡＴゲートウェイ１０６の背後にあるクライアントコンピュータ１０６−Ａについてである。このようなネットワークの従来の例は、インターネットを経て会社のサーバーに接続するスモールオフィス／ホームオフィス（ＳＯＨＯ）ネットワークの社員でよい。明瞭化のため、ローカルアドレスは、ゲートウェイにより指定されるアドレスを指し、非ローカルアドレスは、他の全てのアドレスを指す。

図３は、本発明の１つ以上の態様に基づくＩＰＳｅｃ／ＮＡＴ一体化プロセス２００一部分の実施形態を示すフローチャートである。一体化プロセス２００は、ＩＰＳｅｃ／ＮＡＴクライアント側一体化サブプロセス２９９と、ＩＰＳｅｃ／ＮＡＴゲートウェイ側一体化サブプロセス２９８とを含む。図３を参照すると共に、図１及び２を再度参照して、一体化プロセス２００について説明する。

ステップ２０１において、クライアントコンピュータ（又は「クライアント」）１０６−Ａのようなクライアントコンピュータは、ゲートウェイ１０６のようなゲートウェイからＩＰアドレスを要求する。ステップ２０１におけるこのような要求は、クライアントコンピュータ１０６−Ａにプログラムされたソフトウェアによって行なわれてもよいし、更に詳細には、「ネットワークインターフェイスカード」即ち「ＮＩＣ」１００のようなネットワークインターフェイスのためのドライバの一部分であってもよいし、或いはローカルメモリ１１２に記憶されたプログラムコード２９９（これに限定されないが）を含むＮＩＣのハードウェア又はファームウェアの一部分であってもよい。

クライアント１０６−ＡがプライベートＩＰアドレスを受信した場合に、クライアント１０６Ａは、クライアント１０６Ａがプライベートアドレスドメインの外部にトラフィックを送信できるのでＮＡＴゲートウェイが使用されることを知る。プライベートＩＰアドレスのリストは良く知られているので、クライアント１０６Ａは、それにプライベートＩＰアドレスが指定されたかどうか決定するテストを行うことができる。ステップ２０２において、クライアント１０６Ａは、ＩＰアドレスに対する別の要求を提出し、このときには、そのＤＨＣＰクライアント識別子（そのＭＡＣアドレスとしても知られている）におけるローカルビットを反転する。良く知られたように、ゲートウェイ及びクライアントの両方を含むＬＡＮの各コンピュータには、このようなＬＡＮに対する独特の番号、即ちＭＡＣアドレスが指定される。従来のＭＡＣアドレスは、組織独特の識別子（ＯＵＩ）及び製造者独特の識別子として知られている２つの２４ビットセグメントに分割された４８ビット番号である。ＯＵＩの第１バイトは、最下位ビット（ＬＳＢ）がマルチキャストビットである。最上位バイトにおける最下位の次のビットがローカルビットである。

例えば、ＮＡＴゲートウェイ１０６におけるＤＨＣＰプロセスは、ＬＡＮ１０２のようなＬＡＮにログオンされたクライアントコンピュータ１０６−Ａに、ステップ２０１からの第１クライアント識別子を伴う第１ＤＨＣＰ要求に応答して、ステップ２５１でプライベートＩＰアドレスを指定し、次いで、第２ＤＨＣＰ要求が、ステップ２０２において、ＬＡＮ１０２にログオンされたクライアントコンピュータ１０６−Ａからの異なるクライアント識別子と共に、ＮＡＴゲートウェイ１０６へ行なわれてもよい。この第２のクライアント識別子が、それに関連する第１クライアント識別子から導出されるのが重要である。従って、ゲートウェイ１０６が、ステップ２５２における暗示的チェックで示されるように、ＮＡＴ以上にＩＰＳｅｃをサポートする場合には、２つのＭＡＣアドレスが同じ要求ステーションからのものであると認識できる。ＡＨ ＩＰＳｅｃをサポートするように構成されたＮＡＴゲートウェイがこの決定を行い、従って、第２のプライベートＩＰアドレスを送信せず、むしろ、ステップ２５５においてパブリックＩＰアドレスを送信する。しかしながら、このようなＮＡＴゲートウェイがＡＨ ＩＰＳｅｃをサポートしない場合には、ＤＨＣＰサーバーがステップ２５３において第２のプライベートＩＰアドレスを指定する。というのは、これは、各ローカルビット値のみが異なる２つのＭＡＣアドレス間の関係に起因しないからである。

ゲートウェイ１０６がＡＨ ＩＰＳｅｃをＮＡＴと共に実行するように構成された場合には、ステップ２５４において、ゲートウェイ１０６は、クライアントコンピュータ１０６−ＡのＭＡＣアドレスを、マッピングテーブルに、パブリックＩＰソースアドレスと共にゲートウェイ１０６のパケットを送信するのに適格なものとして記録してもよい。或いはまた、ゲートウェイ１０６は、以下に詳細に述べるように、ＩＫＥを待機してもよい。

ステップ２０１の後のプライベートＩＰアドレスの指定に基づいて、クライアント１０６−Ａは、ＮＡＴゲートウェイ１０６の存在を予め推測することができる。第２のプライベートＩＰアドレスの指定は、ステップ２０４において、クライアント１０６−Ａに、ＮＡＴゲートウェイ１０６がＡＨ ＩＰＳｅｃをサポートしないことを指示する。しかしながら、クライアント１０６−Ａが、ステップ２０２からのＤＨＣＰ要求に応答して、非プライベート（即ちパブリック）ＩＰアドレスを受信した場合には、クライアント１０６−Ａは、それに応答して、ステップ２０６で、ＮＡＴゲートウェイ１０６がＡＨ ＩＰＳｅｃをサポートすることを知り、ステップ２０６において、以下に詳細に述べるように、ＭＡＣアドレスに関連してパブリックＩＰアドレスを記録する。更に、ＮＡＴゲートウェイ１０６がＡＨ ＩＰＳｅｃをサポートする場合には、クライアント１０６−Ａがその後にＩＫＥを使用してＡＨ及び／又はＥＳＰをネゴシエーションしてもよく、この能力は、ステップ２０７に示すように注目又は記録されてもよい。一方、クライアント１０６−Ａは、ＮＡＴゲートウェイ１０６がＡＨ ＩＰＳｅｃをサポートしないことが検出された場合には、ＥＳＰをＩＫＥのみとネゴシエーションすることに制限される。

ＮＡＴゲートウェイ１０６におけるＤＨＣＰサーバーは、最初のＤＨＣＰ要求で供給されたクライアント識別子が、ローカルビットが反転している点だけ、その後のＤＨＣＰクライアント識別子と相違するときに、２つのＭＡＣアドレスを同じクライアントコンピュータ１０６−Ａに対応するものとして相関するように構成される。換言すれば、ローカルビットを除くと、各ＤＨＣＰクライアント識別子は、他の点で同一である。このようなＤＨＣＰサーバーは、マッピングテーブルに記憶された２つのＭＡＣアドレスがローカルビットだけ異なることに応答して、ゲートウェイ１０６に得られるパブリックアドレス（の１つ）をクライアントコンピュータ１０６−Ａへ送信するようにプログラムされ、これにより、このようなパブリックＩＰアドレスを、以下に詳細に述べるように、ＡＨ又はＥＳＰとＡＨ ＩＰＳｅｃとのセッションに使用することができる。

しかしながら、ＤＨＣＰサーバーが、上述したように、クライアント識別子のローカルビット値だけが相違するという同じクライアントコンピュータ１０６−Ａからの２つのＤＨＣＰ要求の相関をサポートしない場合には、第２のプライベートＩＰアドレスが、要求を発しているクライアントコンピュータ１０６−Ａへ送信される。クライアントコンピュータ１０６−Ａは、第２のプライベートアドレスを受信すると、ＤＨＣＰを使用して、ステップ２０４において、プライベートＩＰアドレスの一方を解除してプライベートアドレスのプールへ戻し、それを別のローカルステーションに指定できるようにする。従って、第２のプライベートＩＰアドレスがＤＨＣＰサーバーから送信された場合には、これが、クライアントコンピュータ１０６−Ａに、ＮＡＴが使用されていること、及びパブリックＩＰアドレス指定能力が設けられていないことを通知する。換言すれば、ゲートウェイ１０６は、ＮＡＴをサポートするが、ここに定義するアルゴリズムに基づくＡＨ ＩＰＳｅｃ及びＮＡＴをサポートしない。従って、ステップ２０５において、クライアントコンピュータは、以下に詳細に述べる理由で、ＥＳＰベースのセキュリティアソシエーションのＩＫＥネゴシエーションしか安全にサポートできないことを決定する。

注目すべきことに、ＥＳＰのみのＩＰＳｅｃに対する本発明の１つ以上の態様ではパブリックＩＰアドレスが必要とされない。しかしながら、従来は、ＩＫＥネゴシエーションの結果として、ＡＨのみ、ＥＳＰのみ、又はＡＨを伴うＥＳＰのいずれのＩＰＳｅｃが使用されようとするか前もって分からない。従って、プロセス２００は、ＩＫＥに対してＡＨのみ又はＡＨを伴うＥＳＰのＩＰＳｅｃが合意される場合のようにパブリックＩＰアドレスを前もって要求する。もし入手できれば、パブリックＩＰソースアドレスを使用して、ＩＰＳｅｃ通信が実行されているというフラグをゲートウェイ１０６に立てる。また、ゲートウェイ１０６は、クライアント１０６ＡがパブリックＩＰアドレスを要求するためにローカルビットが反転されたＤＨＣＰクライアント識別子を送信したこと（及びゲートウェイ１０６により１つが指定されたこと）を観察することにより、且つクライアント１０６−ＡからのＩＫＥ交換の開始に基づいて、ＩＰＳｅｃ通信が実行されているという手掛りを得ることもできる。更に、ここに述べるパブリックＩＰソースアドレスは、ＥＳＰのみのＩＰＳｅｃ、並びにＡＨのみ又はＡＨを伴うＥＳＰのＩＰＳｅｃのトラフィックに対して作用するので、ＩＫＥ及び他の全てのＩＰＳｅｃトラフィックに対してパブリックＩＰソースアドレスが入手できるときにそれを使用することにより、首尾良いＩＰＳｅｃオペレーションの見込みが高くなる。ステップ２１０では、クライアントコンピュータ１０６−ＡがＩＫＥネゴシエーションを開始する。ＩＫＥネゴシエーションは、プロトコルスタックがプライベートＩＰアドレスでスタートしてＩＫＥ開始パケットを生成するという従来のやり方で進められる。注目すべきことに、ＩＫＥネゴシエーションの場合に、ＩＫＥが「ＮＡＴ保安」プロトコルであるので、プライベートＩＰアドレスは、ＩＰソースアドレスとして使用されてもよい。クライアント１０６−Ａは、パブリックＩＰアドレスが入手できる場合には、ＩＫＥネゴシエーションを開始するときにパブリックＩＰアドレスをＩＰソースアドレスとして使用するように選択してもよい。

或いはまた、クライアントコンピュータ１０６−Ａは、パブリックＩＰアドレスを得る前にＩＫＥでスタートしてもよい。しかしながら、ゲートウェイ１０６がパブリックＩＰアドレスを与えるように構成されていない（又はこのような動作を行なうことができない）場合には、このようなゲートウェイ１０６に合致しないＡＨのみ又はＡＨを伴うＥＳＰを使用するための合意を含んでもよいＩＫＥネゴシエーションが完了するまで、このことが発見されない。従って、新たなＩＫＥを実行することが必要になる。クライアントコンピュータ１０６−Ａは、ゲートウェイ自身のパブリックアドレスであるか或いはゲートウェイ１０６が管理するパブリックアドレスのプールから選択されたアドレスであるパブリックアドレスをそのＩＰソースアドレスとして有するパケットを形成してもよい。クライアントコンピュータ１０６Ａは、プライベートＩＰソースアドレスを有するパケットを形成してもよい。換言すれば、クライアントコンピュータ１０６−Ａは、プライベートＩＰアドレスとパブリックＩＰアドレスとの間で選択を行うように構成されてもよく、この選択は、ある場合にはその利用性を前提とし、別の場合には、もし入手できれば、ＩＰＳｅｃプロトコルを使用すべきかどうかを前提とする。パブリックアドレスが得られると、このようなパブリックアドレスをソースアドレスとしてパケットを形成することが従来のやり方で行なわれてもよい。後者の場合に、ＡＨ ＩＰＳｅｃ ＮＡＴが許されれば、ＩＰＳｅｃ保護のトラフィック及び非ＩＰＳｅｃ保護のトラフィックの両方が流れてもよい。非ＩＰＳｅｃ保護のトラフィックは、従来のＮＡＴを使用してもよいことを想起されたい。また、ＬＡＮのようなプライベートドメイン内で、クライアント１０６−Ａは、別のローカルクライアントとのＩＰＳｅｃ保護通信に参加してもよいし、しなくてもよい。ＩＰＳｅｃとのイントラドメイン通信のこのような例では、たとえＩＰＳｅｃが使用されていても、ＩＰ行先アドレスがクライアントコンピュータ１０６−Ａと同じプライベートアドレスドメイン内にあるので、パブリックＩＰアドレスを使用する必要はない。従って、クライアント１０６−Ａのユーザは、ＩＰＳｅｃをもつピアステーションと通信すべきかどうか決定し、更に、このようなピアステーションが、このような通信の場合に、クライアントコンピュータ１０６−Ａのプライベートアドレスドメインに対して内部であり即ちローカルドメインアドレスを有するかどうか決定してもよい。

クライアントコンピュータによりステップ２１０においてＩＫＥが開始されるのに応答して、ゲートウェイ１０６は、ステップ２６０において、ＩＫＥ初期化パケットの受信を使用して、このようなクライアントコンピュータのＭＡＣアドレスと、このようなＩＫＥ初期化パケットの行先ＩＰアドレスとを記録してもよい。ＮＡＴゲートウェイ１０６は、パケットが、ソースポート及び行先ポートの両方が５００に等しいＵＤＰパケットであることをチェックすることにより、パケットがＩＫＥパケットであることを決定してもよい。このＭＡＣアドレスをもつＩＫＥに対する出て行くトラフィックが送信されたことを指示するために、ステップ２６０において、ビット即ちペンディングビットがセットされてもよい。このＩＫＥパケットの行先ＩＰアドレスは、上述したリモートサーバーのようなリモートマシンに対するものである。ゲートウェイ１０６は、ＩＫＥネゴシエーションにはいずれにせよ直接的に参加しないが、その他ＩＫＥパケットのＮＡＴ変換も考えられ、これは、クライアント１０６−ＡがＩＫＥパケットのソースアドレスのようなプライベートＩＰアドレスを使用する場合だけである。ＩＰＳｅｃをサポートするＮＡＴゲートウェイは、ＩＫＥ抑制をサポートしなければならず、これは、いかなる所与の時間にも１つのＩＫＥネゴシエーションしか進行せず、従って、ＩＫＥパケットをネットワークアドレス変換するときには、ＩＰアドレス変換だけで充分であるから、ポート変換は必要でないことを意味する点に注意されたい。

図５Ａ及び５Ｂには、本発明の１つ以上の態様に基づく異なる時間におけるＩＰＳｅｃ割り当てマッピングテーブル（ＩＰＳＡＭＴ）３００の実施形態が示されている。このＩＰＳＡＭＴ３００は、開始される各ＩＫＥに対する行と、タイムスタンプ３０５、ＩＳＡＫＭＰイニシエータクッキー３０７、ＩＰＳｅｃプロトコル識別子、ローカルクライアントＭＡＣアドレス３０１、ローカルクライアントパブリックＩＰアドレス３０９、ローカルクライアントプライベートＩＰアドレス３０６、リモート対ローカルセキュリティパラメータインデックス３０２、ペンディングビット３０３、及びリモートＩＰアドレス３０４の各フィールドに対する列とを備えている。

タイムスタンプフィールド３０５は、ペンディングビットフィールド３０３の状態に基づいて解釈される。ペンディングビットフィールド３０３がセットされた場合には、タイムスタンプフィールド３０５は、リモートＩＰアドレスフィールド３０４のアドレスとローカルクライアントＭＡＣアドレスフィールド３０１の関連アドレスとの間の最新のＩＫＥパケットの時間で集団構成される。ペンディングビットフィールド３０３の状態がクリアである場合には、タイムスタンプフィールド３０５は、マッピングテーブル３００の行におけるリモートＩＰアドレスフィールド３０４のアドレスに一致するリモートＩＰアドレスから最新のＩＰＳｅｃ保護パケットが受信された時間を含む。マッピングテーブル３００がいっぱいになった場合には、最も長い時間アイドル状態であった行が、タイムスタンプフィールド３０５からの情報を使用して最初の削除ラインとされる。

ＩＰＳｅｃプロトコルフィールド３０８は、２ビットフィールドとしてエンコードすることができ、００のパターンは無効パターンを示し、１０はＡＨを示し、０１はＥＳＰを示し、更に、１１はＡＨを伴うＥＳＰを示すが、他のエンコードも考えられることを理解されたい。リモート対ローカルセキュリティパラメータインデックスフィールド３０２は、リモートＩＰアドレスフィールド３０４のアドレスから、ＭＡＣアドレス及びパブリック又はプライベートＩＰアドレスにより識別された特定のローカルクライアントに向けられたトラフィックに関連したセキュリティパラメータインデックス値を記憶するためのものである。

図５Ａ及び５Ｂを参照し続けると共に、図１、２及び３を再び参照すると、ＮＡＴゲートウェイ１０６が、クライアントコンピュータ１０６−ＡのＭＡＣアドレスを、マッピングテーブルに記録された第１リモートＩＰアドレスに一致させるようにマッピングテーブルに記録した後に、「ＩＫＥ抑制」を使用して、ローカルクライアントマシンとリモートＩＰアドレスとの間に一度に１つのＩＫＥ交換しか生じないように確保することができる。ローカルクライアントとリモートＩＰアドレスとの間で所与の時間に未決着であるＩＫＥネゴシエーションは１つだけであるから、所与の時間にマッピングテーブルの行に対して不完全の欠落したセキュリティパラメータインデックスエントリーは１つだけである。多数のローカルマシンがＩＰＳｅｃを使用して同じリモートＩＰアドレスにアクセスするよう向けられる場合には、ＩＫＥネゴシエーションが先着・先処理ベースで処理される。最も以前のＩＫＥネゴシエーションが完了し、即ち新たに到来するセキュリティパラメータインデックスがそのリモートＩＰアドレスから記録されると、別のＩＫＥネゴシエーションを開始することが許される。より詳細には、ゲートウェイ１０６は、リモートＩＰアドレスからそのパブリックＩＰアドレスの１つを宛先とするパケットを受信し、これは、１）マッピングテーブルの行にセットされたペンディングビット３０３を有し、２）マッピングテーブルのその行にセキュリティパラメータインデックスエントリーをもたない。ゲートウェイ１０６は、このパケットのセキュリティパラメータインデックスを、ＩＰＳＡＭＴ３００のようなマッピングテーブルのこの行におけるこの空きスロットに記録し、次いで、このパケットを、マッピングテーブルの同じ行から取り出されたクライアントアドレスへ転送する。

注目すべきことに、ＡＨ及びＥＳＰは、各々のセキュリティパラメータインデックス形式を有し、到来する及び出て行く、の両方のセキュリティパラメータインデックス形式が存在する。従って、マッピングテーブルは、ＡＨ又はＥＳＰトラフィックに対する列を有してもよく、ここで、ＡＨは、ＡＨを伴うＥＳＰを含む。しかしながら、ローカルマシンと、リモートＩＰアドレスに関連したリモートマシンとの間のＩＫＥ交換を監視することによりマッピングテーブルに行が追加される。

ＩＫＥピアのリモートＩＰアドレスと、このようなＩＫＥピアとのＩＫＥ会話に参加するローカルクライアントのＭＡＣアドレスとを有するマッピングテーブルを使用して、このようなＩＫＥピアからセキュリティパラメータインデックスを記憶する。注目すべきことに、ＩＫＥネゴシエーションが完了した後、このようなセキュリティパラメータインデックスは、ＩＰＳｅｃ保護されたトラフィックがこのようなリモートＩＰアドレスに対するリモートマシンからＮＡＴゲートウェイ１０６へ実際に流れるまで、このようなマッピングテーブルに追加することができない。セキュリティパラメータインデックスは、ＩＫＥ中に暗号化され、そしてこのようなＩＰＳｅｃセッションに対する真のデータが送信されるとき、即ちＩＫＥセッションが首尾良く完了した後でなければ、非暗号即ち「平文」で現われない。リモートアドレスからのセキュリティパラメータインデックス間の関連性に関する上述した理由に加えて、セキュリティパラメータインデックスはＩＫＥ中に暗号化されて、真の暗号化データが流れ始めたときしか平文で現われないので、ＩＫＥ抑制の一部分として実際のデータが流れ始めるまで、同じ行先ＩＰアドレスに対して一度に１つのみのオープンのリモート対ローカルセキュリティパラメータインデックスエントリーがマッピングテーブルに許されてもよい。各アクティブなクライアントが異なるリモートＩＰアドレスとネゴシエーションする限り、ゲートウェイ１０６を経て多数のＩＫＥセッションが行なわれてもよい。首尾良くネゴシエーションされたＩＫＥに対するセキュリティパラメータインデックスがリモートＩＰアドレスに対して得られると、その同じリモートＩＰアドレスに対して別のＩＫＥセッションが開始されてもよい。

従って、多数の通信モードがあることを理解されたい。クライアント１０６−Ａが、そのＩＫＥ又はＩＰＳｅｃ保護トラフィックを送信するときにパブリックＩＰアドレスをソースアドレスとして使用した場合には、その戻りトラフィックは、マッピングテーブルを使用して、クライアントのＭＡＣアドレスに対してセキュリティパラメータインデックスが得られるときにはそこへマップされ、そしてこのようなセキュリティパラメータインデックスが得られるまでは、戻りトラフィックは、マッピングテーブルを使用して、クライアントのＭＡＣアドレスに対してオープンのペンディングビットを有するリモートＩＰアドレスへマップされる。

クライアント１０６−Ａが、そのＥＳＰのみのＩＰＳｅｃトラフィックを送信するときにプライベートＩＰアドレスを使用し、そのトラフィックがその後にネットワークアドレス変換される場合には、到来するトラフィックに対して、ＮＡＴ ＩＰアドレス変換は、クライアントのプライベートＩＰアドレスと、マッピングテーブルに記憶されたリモートＩＰアドレス（即ち到来するトラフィックに対するソースアドレス）との関連付けにより実行され、更に、ポートアドレス変換は、マッピングテーブルを使用して、クライアントのプライベートＩＰアドレスに対してセキュリティパラメータインデックスが得られるときにはそこへマッピングされる。このようなリモートＩＰアドレスに対してセキュリティパラメータインデックスが得られない場合には、このようなリモートＩＰアドレスに関連したオープンのペンディングビットを有するクライアントのプライベートＩＰアドレスが使用される。ゲートウェイ１０６は、ローカルクライアント１０６−Ａにより開始されたＩＳＡＫＭＰネゴシエーションが首尾良く完了したかどうか明確なやり方で決定できない。しかしながら、不必要なペンディング状態がマッピングテーブルに維持されないよう保つ助けをする上で使用できる２つの暗示的な手掛りがある。ローカルクライアントがＩＳＡＫＭＰメインモード交換を開始する場合には、このようなメインモード交換の直後にクイックモード交換が続かねばならない。クイックモードパケットが見られない状態で５秒以上経過した場合には、このネゴシエーションが失敗となり、このようなＩＳＡＫＭＰメインモード交換に応答して生成された行をこのようなマッピングテーブルから除去することができる。

或いはまた、ローカルクライアントが、常に３つのパケットを取り上げるアグレッシブモード交換を開始するも考えられる。２つのパケットが見られ、次いで、第３のパケットを見ずに５秒が経過した場合には、このようなネゴシエーションが失敗となり、このようなＩＳＡＫＭＰアグレッシブモード交換に応答して生成された行をこのようなマッピングテーブルから除去することができる。従って、マッピングテーブルにおいてタイムスタンプをＩＳＡＫＭＰイニシエータクッキーに関連付けることを使用して、このような時間限界が経過したかどうか決定してもよい。従って、ポート番号ではなく、セキュリティパラメータインデックスが逆変換に使用されるので、多数のＶＰＮ接続を同時にサポートするのに特殊な又は変更型のＶＰＮが必要とされないことが明らかであろう。それ故、ここに述べるように逆変換のためにＴＣＰ又はＵＤＰヘッダにアクセスできる必要はない。更に、セキュリティパラメータインデックスは固定のオフセットであるから、マッピングテーブルに対するインデックスとして使用するためにパケットにおいてそれにアクセスすることが容易にされる。或いはまた、パブリックＩＰアドレスを得るための第２のＤＨＣＰ要求を実行するように構成されたプログラム製品のドライバによりローカルクライアントのＮＩＣを変更するのではなく、ＥＳＰのみのＶＰＮが使用される場合には、ゲートウェイ１０６は、マッピングテーブルで構成されるが、クライアント１０６−Ａは、ＩＫＥ及びＥＳＰのみのＩＰＳｅｃがＮＡＴに合致するので、変更を必要としない。

ＩＫＥ抑制は、ＥＳＰのみのＩＰＳｅｃを使用して多数の個別のリモートＩＰアドレスと通信しているクライアントには使用されない。ＩＫＥ抑制は、同じリモートＩＰアドレスと通信している多数のローカルマシンをサポートするのに使用される。しかしながら、ＶＰＮを変更せずにＶＰＮセッションのためにローカル対リモートマシンに対して多数対１のマッピングをもたせる能力が実質的に効果的である。その一例は、会社の同じサーバーへ通信することを全てが希望する会社用のテレコミュターである。

パブリックＩＰアドレスをネットワークインターフェイスレベルで得ることを組み込むことにより、オペレーティングシステム（ＯＳ）を含む必要がなくなる。換言すれば、ＯＳレベルにおいて、ＩＫＥが開始され、このような開始に応答して、ＮＩＣ１００がパブリックＩＰアドレスを自動的に要求する。この要求は、ＩＫＥ開始以外のＯＳアクションを必要としない。更に、ＮＩＣ１００は、ＩＰＳｅｃに対して構成され、従って、パブリックアドレスが得られた場合には、それがＩＰＳｅｃパケットに自動的に使用されてもよい。更に、クライアント及びゲートウェイによりサポートされる既知のプロトコルは、付加的な信号チャンネルを導入せずに使用されてもよい。

図３Ａには、本発明の１つ以上の態様に基づくＩＫＥ抑制を伴うＩＰＳｅｃ／ＮＡＴゲート側一体化サブプロセス２９８の実施形態を示すフローチャートである。ステップ２１７において、ＮＡＴゲートウェイ１０６は、パケットを受信する。このパケットは、図３のステップ２１０からのＩＫＥ開始パケットでよい。ステップ２１８において、ＮＡＴゲートウェイ１０６は、このようなパケットをチェックして、それがＩＫＥパケットであるかどうか決定する。

図３Ａを参照し続けると共に、図１、２、５Ａ及び５Ｂを再度参照すると、ステップ２１８において、受信パケットがＩＫＥパケットでない場合には、ステップ２１９において、このようなパケットがソースＩＰアドレスとしてパブリック又はプライベートＩＰアドレスを有するかどうか決定するチェックが行われる。ＮＡＴゲートウェイ１０６は、ＩＰＳｅｃ及び非ＩＰＳｅｃパケットを受信できるが、ＬＡＮ１０２のクライアントコンピュータ１０６−ＡからＣのようなクライアントコンピュータは、ＩＰＳｅｃセッションに関する通信についてのみＮＡＴゲートウェイ１０６へＩＰソースアドレスとしてパブリックＩＰアドレスを送信する。注目すべきことに、ＥＳＰのみのＩＰＳｅｃをネゴシエーションすることは問題でない。というのは、ＮＡＴゲートウェイ１０６を通るＥＳＰのみのトラフィックに対してパブリックＩＰアドレスがＩＰソースアドレスとして使用されてもよいからである。ステップ２１９において、ソースＩＰアドレスが、ＮＡＴゲートウェイ１０６に得られるパブリックＩＰアドレスである場合には、これが、ＮＡＴゲートウェイ１０６に、このような受信パケットをＩＰＳｅｃセッションに対して処理すべきことを指示する。従って、パブリックＩＰソースアドレスをもつパケットがステップ２１９において見つかった場合には、それがステップ２５６においてＮＡＴを伴わずに処理される。換言すれば、ＮＡＴゲートウェイ１０６は、パブリックＩＰアドレスをソースＩＰアドレスとしてもつがＮＡＴを伴わないパケットを送信する。プライベートＩＰソースアドレスをもつパケットがステップ２１９において見つかった場合には、それがステップ２５７においてＮＡＴを伴って処理される。換言すれば、ＮＡＴゲートウェイ１０６は、このパケットをＷＡＮ１０４に送信する前に、パブリックＩＰアドレスをこのようなプライベートＩＰソースアドレスに置き換える。

ステップ２１８において、受信パケットがＩＫＥパケットである場合には、ステップ２２１において、このようなパケットの行先ＩＰアドレスがＩＫＥ抑制サブルーチン２９７の一部分としてマッピングテーブルにあるかどうか決定するチェックがなされる。ＩＫＥ制御又は抑制により、ＩＫＥ抑制されたパケットは、以下に詳細に述べるように、リモート対ローカルＳＰＩが記憶され且つペンディングビットが反転されるまで、ゲートウェイ１０６により送信されることを理解されたい。換言すれば、所与のローカルクライアントＭＡＣアドレスと所与のリモートＩＰアドレスとの間に１つのＩＫＥ「会話」だけが進行中であってもよい。

仮定により、ＮＡＴが全ての外部トラフィックをローカルクライアントにより開始するように強制するので、ＩＫＥトラフィックは、常に、クライアント１０６−Ａのようなローカルクライアントにより開始される。これは、直感的には、パブリックアドレスをプライベートアドレスに置き換えねばならず、従って、トラフィックは、最初、ＮＡＴを経て一方向に、即ちローカル（プライベート）側からリモート（パブリック）側へしか流れ得ないからである。クライアント１０６−Ａの最初のＩＫＥ「メインモード」トランザクション、及びそれに続くＩＫＥ「クイックモード」トランザクション（或いは、メイン及びクイックに代わって、クライアントは「アグレッシブモード」トランザクションを選択してもよい）は、同じクライアント選択６４ビットイニシエータクッキーをＩＳＡＫＭＰヘッダに使用する。その後の再キーイングがローカルクライアント１０６−Ａの判断で行われ、これは、更に別のクイックモード交換又は新たなメインモード交換のいずれかで構成できる（これは、クライアントが新たなイニシエータクッキーを選択して、ＩＰＳＡＭＰ３００に新たな行を生成させることを要求し、この行は、ローカルクライアントのＩＰ又はＭＡＣアドレス、リモートＩＰアドレス、及びクライアントのイニシエータクッキーにより最初に定義される）。

ステップ２２１では、このような行先ＩＰアドレスがＩＰＳＡＭＴ３００に現われず、次いで、ステップ２２２において、ＩＰＳＡＭＴ３００に行が生成され、更に、ステップ２６０において、クライアントコンピュータ１０６−ＡのＭＡＣアドレス及びリモートコンピュータシステム１０１の行先ＩＰアドレスが関連状態で記憶され、このような行に対するペンディングビットがセットされ、例えば、マッピングテーブルにおいて１にセットされると、リモートＩＰアドレスに関連したリモート対ローカルのセキュリティパラメータインデックス（ローカルクライアントのＩＫＥパケットに見つかった最初のＩＰ行先アドレス）がまだ観察されないことを指示する。ＩＫＥパケットはＮＡＴに適合するので、ＮＡＴ処理は、次いで、ステップ２５７で実行される。

ステップ２２１において、受信パケットの行先ＩＰアドレスがＩＰＳＡＭＴ３００に既に存在する場合には、ローカルクライアントＭＡＣアドレス又はプライベートＩＰアドレスとリモートＩＰアドレスとの間のセキュリティネゴシエーションが既に進行中であるという指示に対してＩＳＡＫＭＰ「イニシエータクッキー」のチェックが行われる。従来、ＩＳＡＫＭＰイニシエータクッキーは、６４ビットの２進数であるが、ＩＳＡＫＭＰ規格の将来の改定で、このフィールドのサイズをクライアントマシンによりランダムに選択して変更し、このようなクライアントとそのＩＳＡＫＭＰピアとの間の全ての後続ＩＳＡＫＭＰ会話を独特に識別できるようになる。このクッキーは、ウェブサーバーがウェブブラウザによりクライアントコンピュータに記憶する従来の小さなテキストファイルであるウェブクッキーではない。このフィールドの使用は、多数のＩＳＡＫＭＰネゴシエーションを相関するのを許す。ステップ２２１において、このようなイニシエータクッキーがこのようなマッピングテーブルに現われない場合には、ステップ２２２において、ＩＰＳＡＭＴ３００に行が生成される。

ステップ２２１において、マッピングテーブルのＩＳＡＫＭＰイニシエータクッキーが受信ＩＳＡＫＭＰクッキーに一致する場合には、ステップ２２３において、ペンディングビットが、このようなマッピングテーブルの関連する行、即ちクライアントのＭＡＣアドレス、リモートＩＰアドレス、及び処理されているこの受信ＩＫＥパケットに一致するイニシエータクッキーにより関連付けられた行に対してセットされたかどうか決定するチェックがなされる。注目すべきことに、ペンディングビットは任意である。というのは、それに代わってセキュリティパラメータインデックスのチェックを行なってもよいからである。ローカルクライアント１０６−ＡとリモートＩＰアドレスとの間の新たなＩＫＥ会話の場合には、セキュリティパラメータインデックスフィールド３０２は、この行に対してオープン即ち空のエントリーとなる。というのは、このＩＫＥ交換から生じるＩＰＳｅｃ保護トラフィックがゲートウェイ１０６によってまだ観察されていないからである。注目すべきことに、その後の又は新たなＩＫＥ会話において、再キーイングは、新たなＩＫＥ会話で、古いセキュリティパラメータインデックスが期限切れとなったときに引き継がれる新たなセキュリティパラメータインデックスをネゴシエーションするのを許すことができる。ペンディングビットフィールド３０３のペンディングビットがセットされ、且つリモート対ローカルＳＰＩフィールド３０２にセキュリティパラメータインデックス値が存在する場合には、そのセキュリティパラメータインデックス値が間もなく期限切れになることがあり、それ故、ゲートウェイ１０６は、ＩＰＳｅｃ保護トラフィックにおけるこのようなセキュリティパラメータインデックスが新たな値に変化することを予想してもよい。このペンディングビットは、このような新たなセキュリティパラメータインデックスがリモート対ローカルＩＰＳｅｃ保護パケットにおいて検出されたときにクリアされる。

ステップ２２３において、ペンディングビットフィールド３０３のペンディングビットがセットされ、例えば、１にセットされると、リモート対ローカルセキュリティパラメータインデックスが、行先ＩＰアドレスが得られてＩＰＳＡＭＴ３００に記録されたマシンからのものであることを指示する。このようなビットがセットされて、リモート対ローカルセキュリティパラメータインデックスがその行先ＩＰアドレスに関連したマシンに対して得られたものであることを指示する場合には、ステップ２２２において、このようなマッピングテーブルに行が生成される。これは、以前のＩＫＥに対するリモート対ローカルセキュリティパラメータインデックス（異なるローカルクライアントからの）が得られているので、別のＩＫＥが同じリモートＩＰアドレスに対して抑制されないことを意味する。しかしながら、ステップ２２３において、ペンディングビットフィールド３０３におけるリモート対ローカルセキュリティパラメータインデックスペンディングビットがその初期設定値から反転されておらず即ち依然ゼロ（０）である場合には、これは、他のローカルクライアントがＩＫＥを使用して同じリモートＩＰアドレスとネゴシエーションできないことを指示する。というのは、指示されたリモートＩＰアドレスからのリモート対ローカルセキュリティパラメータインデックスが使用中に観察されていないからである。従って、ステップ２２４では、このようなＩＫＥパケット又はより詳細にはＩＫＥ初期パケットが任意に待ち行列に入れられ、そしてステップ２２３でチェックを繰り返すことにより以前のＩＰＳｅｃセッションに対してリモート対ローカルセキュリティパラメータインデックスペンディングビット３０３がセットされたときにステップ２２２においてそれが解除されてマッピングテーブルに行が生成される。ＩＳＡＫＭＰパケットを待ち行列に入れる以外のオプションは、ローカルクライアントに、サブコード＝＝３（ポート不到達）でＩＣＭＰ行先不到達（形式＝＝３）を送信するか、又はサブコード＝＝９（行先ホストとの通信が管理上禁止される）でＩＣＭＰ行先不到達（形式＝＝３）を送信することである。

図４は、本発明の１つ以上の態様に基づくＩＰＳｅｃ／ＮＡＴ一体化プロセス２００の受信器側の実施形態を示すフローチャートである。図４を参照し続けると共に、図１及び２を更に参照して、一体化プロセス２００の受信器側について説明する。ステップ４０７において、ＩＰパケットは、コンピュータシステム１０１からＮＡＴゲートウェイ１０６により受信される。ステップ４０８では、このように受信したパケットにセキュリティパラメータインデックスが存在するかどうか決定するための比較が行なわれる。換言すれば、ＡＨのみ、ＥＳＰのみ、及びＡＨを伴うＥＳＰの１つを使用するＩＰＳｅｃ保護パケットである。

ＩＫＥネゴシエーションがローカルクライアントによりあるリモートＩＰアドレスに対して開始された場合には、ペンディングビットフィールド３０３のペンディングビットがセットされる。というのは、リモートコンピュータシステム１０１から、このようなＩＫＥネゴシエーションを開始したローカルクライアント１０６−Ａへのトラフィックに関連したリモート対ローカルセキュリティパラメータが観察及び記録されていないからである。ローカルクライアント１０６−ＡのＩＫＥパケットのＩＰソースアドレスがプライベートアドレスである場合には、そのクライアントのプライベートＩＰアドレスが、ローカルクライアントＩＰアドレスフィールド３０６に記憶される。このフィールドが占有されたときには、ゲートウェイ１０６は、ＩＰＳｅｃトラフィックに対して、クライアント１０６−Ａと、このリモートＩＰアドレスに関連したリモートマシンとの間にＥＳＰのみのトラフィックが割り当てられねばならないことを知る。しかしながら、ローカルクライアント１０６−ＡがパブリックＩＰアドレスをＩＫＥパケットにおけるＩＰソースアドレスとして使用する場合には、ゲートウェイ１０６は、このクライアントのＭＡＣアドレスをローカルクライアントＭＡＣアドレスフィールド３０１に記憶することによりこれを忘れないようにしなければならない。このＩＫＥローカルクライアントＭＡＣアドレスのフィールドが占有されたときには、クライアント１０６−Ａは、ＩＰＳｅｃのＡＨのみ、ＥＳＰのみ、又はＡＨを伴うＥＳＰの形態を使用できる。注目すべきことに、このような場合に、クライアント１０６−Ａは、ゲートウェイ１０６により指定されたパブリックＩＰアドレスを使用することになり、ステップ２５４で記憶されているので、このＭＡＣアドレスをもつマシンにパブリックＩＰアドレスが指定されたことを想起できる。ステップ２５４で記録されたＭＡＣアドレスだけが、それに関連したパブリックＩＰアドレスの使用を許されねばならない。

ＩＫＥ抑制が使用され、且つＩＰＳｅｃ保護データが、ＩＫＥネゴシエーション後に、関連リモートＩＰアドレスをもつマシンからマッピングテーブル内のローカルクライアントへ流れない場合には、ペンディングビットフィールド３０３のペンディングビットが例えば１にセットされたままとなり、他のクライアントが同じ行先ＩＰアドレスとＩＫＥネゴシエーションを開始するのを防止する。従って、タイムスタンプ３０５を使用し、リモート対ローカルセキュリティパラメータインデックスフィールド３０２におけるリモート対ローカルセキュリティパラメータインデックスが、決定された時間内に得られず、従って、このようなペンディングビットを例えばゼロ（０）にクリアする場合には、期限切れとなった行をＩＰＳＡＭＴ３００から除去して、同じリモートＩＰアドレスへの別のＩＫＥを実行するのを許すことができる。この行は、別のステーションが実際に同じリモートＩＰアドレスとのＩＫＥネゴシエーションを開始するよう試み、この時点で衝突が通知されるまで、除去される必要はない。従って、ペンディングビットフィールド３０３のペンディングビットは１にセットされることが確認され、そしてタイムスタンプフィールド３０５の関連タイムスタンプは、この行又はこれらの行エントリーがパージするに充分なほど古いことを確認するようチェックされる。

ペンディングビット３０３がクリアされ、即ちゼロ（０）にセットされた場合には、同じ２つのアドレス、即ちローカルＭＡＣ又はローカルクライアントプライベートＩＰアドレスとリモートＩＰアドレスとの間に別のＩＫＥセッションが開始されるまで、その関連行がＩＰＳＡＭＴ３００に保たれる。リモート対ローカルセキュリティパラメータインデックスが得られたＩＫＥセッションを既に有するマシン間に別のＩＫＥセッションが開始された場合には、これら２つのマシン間の以前のＩＫＥセッションに対する関連行は、たとえリモート対ローカルセキュリティパラメータインデックスが既知であっても、ペンディングビットフィールド３０３のビットをセットしている。この場合に、このようなペンディングビットを例えば１にセットすると、関連行が削除ペンディング中であることを指示する。

リモート対ローカルセキュリティパラメータインデックスが得られた既存のＩＫＥに新たなＩＫＥが取って代わる状況においては、リモートＩＰアドレスからローカルクライアントへのトラフィックに対して新たなリモート対ローカルセキュリティパラメータインデックスを使用し始めることが予想され、この時点で、リモート対ローカルセキュリティパラメータインデックスの値だけが異なる新たな行を古い行からクローン生成することができる。このような新たな行が生成されると、古い行のペンディングビットフィールド３０３のペンディングビットを再びクリアし、即ちゼロ（０）にセットすることができる。より一般的には、パケットがテーブルエントリーに一致するように見えるたびに、タイムスタンプフィールド３０５が更新されるが、古い行は、古いリモート対ローカルセキュリティパラメータインデックスを使用してトラフィックを到達させ、時間経過と共に行を益々古くさせてしまうのを直ちに止めねばならない。この行は、充分古くなると、通常の「廃物収集」動作により排除される。例えば、交換したキーが期限切れになりつつあるか又は期限切れしたために、新たなＩＫＥを開始することができる。

新たなＩＫＥネゴシエーションは、新たなＩＫＥ通信を開始するローカルクライアントの判断でいつでも行ない得る。ＩＫＥネゴシエーションは、確立されたＩＫＥセッションであっても、リモートマシンやリモートＩＰアドレスでは開始されない。ＮＡＴの場合に常にローカルクライアントでなければならないセッションオリジネータは、全ての更に別のＩＫＥ会話、例えば、再キーイングネゴシエーションを開始する。図５Ａ及び５Ｂを参照し続けると共に、図４を再度参照すれば、ステップ４０８において、ＩＰＳｅｃで保護されないパケットのような受信パケットにセキュリティパラメータインデックスがない場合には、このようなパケットが、ステップ４０９において、ＩＰＳＡＭＴ３００を調べずにルーティングされる。このようなルーティングの判断は、ゲートウェイ１０６の非ＩＰＳｅｃ ＮＡＴファンクションを推進するゲートウェイＮＡＴテーブルにより推進されてもよい。ＮＡＴは良く知られているので、ＮＡＴの詳細な説明は、明瞭化のため省略する。

ステップ４０８において、ステップ４０７で受信されたパケットにセキュリティパラメータインデックスが見つかった場合には、ステップ４１０において、ＩＰＳＡＭＴ３００のチェックを行なって、リモートＩＰアドレスフィールド３０４のアドレスに一致するパケットのＩＰソースアドレスに対してリモート対ローカルセキュリティパラメータインデックスが存在するかどうか決定する。ステップ４１０において、ＩＳＡＭＴ３００からのリモート対ローカルセキュリティパラメータインデックスフィールド３０２に値が存在する場合には、ステップ４１１において、そのような一致するパケットが、そのような受信パケットで見つかったＩＰＳＡＭＴ３００からのリモート対ローカルセキュリティパラメータインデックスフィールド３０２におけるそのような値に関連したローカルクライアントＭＡＣアドレスフィールド３０１又はローカルクライアントプライベートＩＰアドレスフィールド３０６の関連アドレスへルーティングされる。

ゲートウェイ１０６が、マッピングテーブルのＭＡＣアドレスを使用してクライアントコンピュータを識別するときには、このローカルクライアントが、ゲートウェイ供給されたパブリックＩＰアドレスを、そのローカル対リモートパケットにおけるＩＰソースアドレスとして使用している。このような場合、ゲートウェイ１０６は、ローカルクライアントパブリックＩＰアドレスフィールド３０９からのこのようなローカルクライアントアドレスを、想起し又は忘れないために記憶し、従って、ゲートウェイ１０６は、（そのローカルビットを反転することにより）このようなパブリックＩＰアドレスを得るためにＤＨＣＰを最初に使用したこのドメインにおけるＭＡＣアドレスしかこのパブリックＩＰアドレスを使用できないように確保することができる。このようなローカル対リモートパケットのＩＰソースアドレスは、既にパブリックＩＰアドレスであるから、ゲートウェイは、パケットのＮＡＴ変換を実行する必要がない。それ故、ＡＨ保護されたパケットは、ＩＰアドレス変換に遭遇せずにローカルドメインを脱出することがあり、従って、リモート側では、ＡＨヘッダに埋め込まれたデジタル符牒を確認することができる。ローカルクライアントアドレスは、プライベートＩＰアドレスであるか又は（パブリックＩＰアドレス、ＭＡＣアドレス）対であるかに関わらず、ローカルクライアントからリモートＩＰアドレスへの初期トラフィックから記録され、従って、ゲートウェイ１０６は、どのローカルクライアントへ戻りトラフィックを転送すべきか決定することができる。ローカルクライアントのＭＡＣアドレスは、リモートＩＰアドレスを行先とした第１のローカル対リモートパケットのＭＡＣソースアドレスフィールドから抽出される。

ゲートウェイ管理されるパブリックＩＰアドレスよりアクティブなクライアントが存在する状況では、リモートＩＰアドレス対ローカルクライアントの多数対１のマッピングが存在し、この場合、リモート対ローカルセキュリティパラメータインデックスを使用して、テーブルのどの行が適切なローカルクライアントに対応するか識別する。ゲートウェイ１０６は、ローカルステーションへ最終的に配送するために行先アドレスのどの形態を使用すべきかを、想起のために記憶する。ＭＡＣアドレス及びパブリックＩＰアドレスが記録されたローカルクライアントマシンについては、戻りトラフィックにおけるＩＰ行先アドレスも、ゲートウェイ１０６がこのようなローカルクライアントマシンに各々指定した同じパブリックＩＰアドレスである。従って、ゲートウェイ１０６は、クライアントのパブリックＩＰアドレスを宛先とするパケットを、変更せずに（ＭＡＣフレームのＭＡＣソースアドレスがローカルサブネットワークにおけるゲートウェイのＬＡＮインターフェイスのアドレスとなり、且つフレームのＭＡＣ行先アドレスが、ゲートウェイ１０６がテーブルの一致する行に記録したローカルクライアントＭＡＣアドレスとなることを除いて）安全に送信できることを知る。

プライベートＩＰアドレスが記録されているローカルクライアントへのトラフィック（ＥＳＰのみのトラフィックだけがこのカテゴリーに入る）については、ゲートウェイ１０６は、リモートＩＰアドレスフィールド３０４のアドレスと、リモート対ローカルセキュリティパラメータインデックスフィールド３０２の値とを使用して、マッピングテーブルにおける適切な行を識別し、そこから、ローカルクライアントプライベートＩＰアドレスフィールド３０６のアドレスを抽出し、これにより、パケットのＩＰ行先アドレスをこのようなローカルクライアントのプライベートＩＰアドレスに変換する。

ステップ４１０において、リモートＩＰアドレスフィールド３０４のアドレスが受信パケットのＩＰソースアドレスに一致するマッピングテーブルの行に関連したリモート対ローカルセキュリティパラメータインデックスフィールド３０２に値が存在せず、且つこのようなマッピングテーブルのこの行のペンディングビットフィールド３０３のビットが例えば１にセットされる場合には、ステップ４１２において、このようなＩＰソースアドレスを有すると共にこのようなペンディング値を有する受信パケットからリモート対ローカルセキュリティパラメータインデックスフィールド３０２に追加される値を加算することによりＩＰＳＡＭＴ３００が更新される。これに応答して、ペンディングビットフィールド３０３のビットがこの行に対してクリアされ（即ち、ゼロ（０）にセットされ）、ペンディング中のリモート対ローカルセキュリティパラメータインデックス値の受信を指示する。パケットがテーブルの行に一致するたびに、タイムスタンプフィールド３０５がその行に対して更新される。

図５Ｂでは、リモート対ローカルセキュリティパラメータインデックスフィールド３０２の値と、ペンディングビットフィールド３０３の値が、一例として、リモート対ローカルセキュリティパラメータインデックス列即ちフィールド３０２と、ペンディングビット列即ちフィールド３０３とに各々書き込まれ、ＩＰＳｅｃ ＩＰＳＡＭＴ３００を更新する。更に、ＩＫＥ抑制がアクティブである場合には、ペンディングビットフィールド３０３のビットを、例えば、ゼロ（０）に反転することによりクリアすると、別のローカルクライアントが、以前にセキュリティパラメータインデックス値の受信ペンディング状態にあった同じリモートＩＰアドレスへのＩＫＥセッションを開始するのを許す。ステップ４１２における更新の後に、ステップ４１１において、このような受信ＩＰパケットは、ＮＡＴゲートウェイ１０６により、アドレスに基づいて、ＩＰＳＡＭＴ３００におけるローカルクライアントＭＡＣアドレスフィールド３０１又はローカルクライアントプライベートＩＰアドレスフィールド３０６から、それに関連したクライアントコンピュータ１０６−Ａへルーティングされる。

注目すべきことに、受信パケットに対して一致するリモート対ローカルセキュリティパラメータインデックス３０２をもつ行がない場合には、ＮＡＴゲートウェイ１０６は、このようなリモートＩＰアドレスと通信するのが１つのローカルクライアントＭＡＣアドレスだけであるとすれば、このような受信パケットを依然として正しくルーティングすることができる。或いはまた、同じリモートＩＰアドレスに対して２つ以上のオープンのリモート対ローカルセキュリティパラメータインデックスが許された場合には、このようなパケットは、このようなリモートＩＰアドレスと通信する各ローカルクライアントＭＡＣアドレスへ送信されてもよいし、或いはＬＡＮ１０２上の全てのクライアントコンピュータに対するブロードキャストＭＡＣアドレスへ送信されてもよく、次いで、ＮＡＴゲートウェイ１０６は、適切なローカルクライアントをそのリモートＩＰアドレスに対する適切なリモート対ローカルセキュリティパラメータインデックスとリンクできるように両方向応答を待機することができる。

２つの異なるローカルクライアントは、同じリモートＩＰアドレスとのＩＫＥネゴシエーションに参加するときには同じリモート対ローカルセキュリティパラメータインデックス値を選択し得ることが考えられる。これは、全てのクライアントが同じパブリックＩＰアドレスを共有している場合にはたとえＩＫＥ抑制が使用されても考えられることである。

しかしながら、２つのクライアントが、同じリモート対ローカルセキュリティパラメータインデックス値を選択すると共に、それらに異なるローカルクライアントパブリックＩＰアドレスが指定されている場合には、受信パケットとの４個の関連性、即ちリモートＩＰアドレス、リモート対ローカルセキュリティパラメータインデックス、ＩＰＳｅｃプロトコル、及びローカルクライアントパブリックＩＰアドレスに基づいて、パケットを転送することができる。

ローカルクライアントが同じパブリックＩＰアドレスを有する場合には、最初にＩＰＳＡＭＴ３００に入るどちらかのＭＡＣアドレスが、そのリモート対ローカルセキュリティパラメータインデックス３０２に対する全ての関連トラフィックを受信する。というのは、ゲートウェイ１０６が、あるステーションに対するトラフィックを、同じ４個の関連性をもつ別のステーションのトラフィックとは別に輪郭定めする方法がないからである。しかしながら、第２のローカルクライアントとこのリモートＩＰアドレスとの間の通信は成功とならず、従って、それらの通信当事者は新たなＩＫＥネゴシエーションを試みることになり、これは、あらゆる可能性において、独特のリモート対ローカルセキュリティパラメータインデックス値の選択を生じることになろう。というのは、リモート対ローカルセキュリティパラメータインデックスは、０から２５５までが指定済みで、２５６から４，２９４，９６７，２９５までの範囲からランダムに選択された番号だからである。重畳するリモート対ローカルセキュリティパラメータインデックスの選択を防止する１つの方法は、最終ステーションがそれらの現在のＩＰアドレス及びセキュリティパラメータインデックスをＬＡＮにブロードキャストするようにさせ、従って、ドメインの他のステーションが重複をチェックできるようにすることである。しかしながら、このような構成は、クライアントソフトウェアの著しい変更を必要とし、従って、通信セッションを失敗させ、低い確率の事象を生じ、且つ最終ステーションで無効となったＩＫＥセッションの回復を別のＩＫＥセッションの開始により行なうことに比して、かなり複雑になる。

注目すべきことに、成功したＩＫＥネゴシエーションの後に、ＩＰＳｅｃパケットは、プロトコル情報の上位層を暗号化し、従って、この情報は、ＮＡＴゲートウェイには得られない。しかしながら、セキュリティパラメータインデックスは、ＩＰＳｅｃセッションに対して暗号化されていないので、ゲートウェイに得られる。更に、セキュリティパラメータインデックスは、各ヘッダ形式、即ちＥＳＰヘッダ及びＡＨにおいて得ることができ、ＡＨは、ＡＨを伴うＥＳＰを含むがこれに限定されない。従って、ＩＫＥがクライアントコンピュータ及び行先コンピュータにより完了となり、且つ暗号化データがキーを用いて交換されると、ＮＡＴゲートウェイは、いずれか又は両方の形式のＩＰＳｅｃ、即ちＥＳＰ及びＡＨとの通信に使用できるリモート対ローカルセキュリティパラメータインデックス値を伴う更新されたＩＰＳＡＭＴ３００を備える。注目すべきことに、ＩＰＳＡＭＴ構造体は、ここでは、単一のエンティティとして説明するが、このようなＩＰＳＡＭＴを多数のテーブルに分割して、１つ以上の列を複写してもよいことが明らかであろう。これは、１つ以上のテーブルをハードウェア、ファームウェア、ソフトウェア又はその組合せで形成できるという効果がある。従って、マッピングテーブルとは、単一のマッピングテーブル、及び関連性を有する複数のマッピングテーブルを包含するものとする。更に、ここで述べる収集されて関連付けされた情報は、テーブル以外の形態で記憶されてもよく、これは、データベース等のデータ構造体を含むが、これらに限定されない。

また、ＡＨ又はＥＳＰパケットにおける新たなセキュリティパラメータインデックスは、このようなパケットにおけるシーケンス番号フィールドの使用により識別されてもよい。新たなセキュリティアソシエーション（ＳＡ）における第１パケットは、常に、シーケンス番号「０ｘ００−００−００−０１」を有する。ヘッダのフォーマットは異なるが、ＡＨ及びＥＳＰの各々は、その両方の場合にシーケンス番号が「０ｘ００−００−００−０１」でスタートし、送信された各パケットに対して１だけ増加され、且つ０ｘＦＦ−ＦＦ−ＦＦ−ＦＦを越えることがないという点で、シーケンス番号フィールドを同様に使用する。第１のリモート対ローカルセキュリティパラメータインデックスは、シーケンス番号「０ｘ００−００−００−０１」で到着しなければならず、２つのステーションが再キーイングに参加するときには、新たなリモート対ローカルセキュリティパラメータインデックスが、「０ｘ００−００−００−０１」にセットされたシーケンス番号フィールドで到着しなければならない。新たなセキュリティパラメータインデックス値を含むがそのシーケンス番号が「０ｘ００−００−００−０１」より大きいパケットは、無効パケットであり、ゲートウェイは、これを破棄するように選択することができる。しかしながら、クライアントは、このようなエラー状態を同等に検出できるので、このようなパケットを転送してもおそらくほとんど害はない。

ゲートウェイが実施のために選択できる別のエラー状態は、リモート対ローカルセキュリティパラメータインデックスが０ｘＦＦ−ＦＦ−ＦＦ−ＦＦから０ｘ００−００−００−００へとラップするパケットを阻止することである。ゲートウェイがこの制限を実施するために、ゲートウェイは、マッピングテーブルから一致する行を削除して、将来トラフィックを転送できないようにすることで、マッピングテーブルにおける各行のシーケンス番号を追跡するか、又は０ｘＦＦ−ＦＦ−ＦＦ−ＦＦのシーケンス番号値をトリガーしなければならない。この場合にも、ローカルクライアントもこの制限を実施できねばならず、従って、ゲートウェイがクライアントをこの状態からシールドする必要はないが、このようなシールドは、もし可能にされた場合でも、ここに述べるアルゴリズムの妨げとはならない。

更に、ＳＡ再ネゴシエーションをゲートウェイにより予め決定するか又は予想してもよい。というのは、上述したように、シーケンス番号フィールドは、０ｘＦＦ−ＦＦ−ＦＦ−ＦＦから０ｘ００−００−００−００へとラップすることが許されないからである。シーケンス番号値が０ｘＦＦ−ＦＦ−ＦＦ−ＦＦの３３％以下になると、ゲートウェイは、新たなＩＫＥ交換を見て新たなＳＡを設定するように合理的に予想できる。もちろん、２つの当事者は、シーケンス番号空間がラップし得るより即座に新たなＳＡをネゴシエーションすることを選択でき、即ちＳＡのネゴシエーションされたライフタイムは、おそらく、ピアが４，２９４，９６７，２９５個のパケットを送信するに要する時間よりかなり短いものとなる。しかしながら、ＳＡが非常に長いライフタイムでネゴシエーションされ、その間にパケット送信レートが非常に高かった場合には、シーケンス番号は、新たなＩＫＥ交換が切迫しているというキューを与える。ローカルクライアントとリモートマシンとの間には多数のＳＡが存在することがある。ＡＨのみ、ＥＳＰのみ、又はＡＨを伴うＥＳＰがあり、その各々が独特のセキュリティパラメータインデックスを有する。従って、マッピングテーブル３００は、リモート対ローカルセキュリティパラメータインデックス値がＡＨに関連するか、ＥＳＰに関連するか又はその両方に関連するかを指示する「ＩＰＳｅｃプロトコル」値列３０８を備えている。更に、マッピングテーブル３００は、ＡＨ及びＥＳＰの両セキュリティパラメータインデックスを独立して、例えば、テーブル３００の別々の行に記録してもよい。というのは、リモート対ローカルセキュリティパラメータインデックス値がＡＨ及びＥＳＰに対して同じになる機会があり、従って、どちらがどちらであるか知らせるために、ＡＨ又はＥＳＰプロトコル形式を記録することが必要になる。注目すべきことに、２つのローカルクライアントが同じリモートＩＰアドレスと話をし、更に、その両方が同じＩＰＳｅｃプロトコルに対して同じリモート対ローカルセキュリティパラメータインデックスを選択した場合には、ゲートウェイ１０６は、両セキュリティアソシエーションに対する全てのトラフィックを、そのリモート対ローカルセキュリティパラメータインデックスを最初にネゴシエーションしたクライアントへ転送する。

ＳＡは、ＩＫＲ初期交換の後又は再キーイング交換の後に長時間アイドル状態であることが考えられ、たとえ各側で新たなセキュリティパラメータインデックスについて合意しても、それらがＩＰＳｅｃ保護データを通信しないことがあり、従って、マッピングテーブル３００内のリモート対ローカルセキュリティパラメータインデックスフィールド３０２を集団構成するのを許すようにＩＰＳｅｃ保護データがゲートウェイ１０６に到達しないことになる。この静寂な時間中に、第三者が、ランダムに選択された（無効）セキュリティパラメータインデックスにおいて模造で偽物のパケットをシーケンス番号０ｘ００−００−００−０１で送信し得ることが考えられる。ゲートウェイ１０６は、到来するパケットにおける意図されたＩＰソースアドレスに一致する行についてのＩＫＥが内部マシンと外部マシンとの間で実行されないことが分かった場合に（即ち、ペンディングビットフィールド３０３が１にセットされているが、リモート対ローカルセキュリティパラメータインデックスフィールド３０６にセキュリティパラメータインデックス値をもたない行がマッピングテーブル３００に存在しない場合に）、このようなパケットを直ちに拒絶することができる。しかしながら、ＩＫＥ交換が行なわれたが、ＩＰＳｅｃトラフィックがゲートウェイ１０６を経てまだ流れていない場合には、セキュリティパラメータインデックスが有効であるかどうか確実に分かるのは、ＩＫＥ接続のエンドポイントだけである。それ故、ゲートウェイ１０６は、新たなリモート対ローカルセキュリティパラメータインデックスをフィールド３０２に記録する前に、ＩＫＥピア間の完全な両方向ＩＰＳｅｃ保護トラフィック交換を監視しなければならない。

模造パケットが上述したように送信された場合には、ローカルクライアント１０６−Ａは、このような模造パケットを破棄するか、エラーメッセージを送信するか、或いは新たなＩＫＥ交換をスタートして、既存のＳＡを確認し、又は新たなネゴシエーションを行なう。クライアント１０６−ＡはＩＰＳｅｃ保護パケットで応答するが、リモートＩＰアドレスがその応答に異なるセキュリティパラメータインデックスを使用する場合には、ゲートウェイ１０６は、それが見た第１セキュリティパラメータインデックスが模造のリモート対ローカルセキュリティパラメータインデックスであったことを知る。

ゲートウェイ１０６は、外部マシンと内部マシンとの間に両方向のＩＰＳｅｃ保護交換を見るまでペンディングビット３０３をクリアすることができない。ゲートウェイ１０６は、それが正しいリモート対ローカルセキュリティパラメータインデックス値を有することの付加的な証拠として初期シーケンス番号を使用することができる。偽物のパケットが受け取られ、このような偽物のパケットのセキュリティパラメータインデックスがマッピングテーブル３００にない場合には、ゲートウェイ１０６は、既知のセキュリティパラメータインデックスをもたないリモートＩＰアドレスからのものとされるＩＰＳｅｃ保護パケットを破棄することができる。但し、これは、ＩＫＥ交換が行なわれず、マッピングテーブル３００の既存のセキュリティパラメータインデックスを正当に無効であるとしてもよいことをゲートウェイ１０６が知っている場合である。ゲートウェイ１０６は、このようなパケットを、シーケンス番号フィールドの値に関わらず破棄することができる。簡単に述べると、不一致のセキュリティパラメータインデックスがリモートＩＰアドレスから到達し、そのＩＰアドレスに一致する行で、ペンディングビット３０３がセットされた行がない場合には、パケットが削除されてもよい。

本発明のある実施形態は、ゲートウェイ及び／又はクライアントコンピュータに完全に又は部分的に常駐できるプログラム製品である。メモリは、揮発性及び／又は不揮発性メモリであって、磁気的に読み取り可能なメモリ（例えば、フロッピーディスク、ハードディスク等）、光学的に読み取り可能なメモリ（例えば、ＣＤ−ＲＯＭ、−ＲＷ、ＤＶＤ−ＲＯＭ、−ＲＡＭ等）、並びに電気的に読み取り可能なメモリ（例えば、ＤＲＡＭ、ＳＲＡＭ、ＥＥＰＲＯＭ、レジスタ、ラッチ等）を含むが、これらに限定されない。従って、本発明のある実施形態は、マシン読み取り可能なプログラムを含むプログラム製品である。プログラム製品のプログラム（１つ又は複数）は、これら実施形態のファンクションを定義するもので、種々の信号／保持媒体に含ませることができ、これらは、（ｉ）書き込み不能の記憶媒体（例えば、ＣＤ−ＲＯＭドライブにより読み取り可能なＣＤ−ＲＯＭディスクのようなコンピュータ内のリードオンリメモリ装置）に永久的に記憶された情報、（ii）書き込み可能な記憶媒体（例えば、ディスケットドライブ又はハードディスクドライブ内のフロッピーディスク）に記憶される変更可能な情報、或いは（iii）ワイヤレス通信を含むコンピュータ又は電話ネットワークのような通信媒体によりコンピュータへ搬送される情報を含むが、これらに限定されない。後者の実施形態は、特に、インターネット及び他のネットワークからダウンロードされる情報を含む。このような信号保持媒体は、本発明のファンクションを指令するコンピュータ読み取り可能な命令を搬送するときには、本発明の実施形態を表わす。

以上、本発明の好ましい実施形態を説明したが、本発明の基本的範囲から逸脱せずに本発明の他の及び更に別の実施形態を案出することもでき、それ故、本発明の範囲は、特許請求の範囲により規定される。ステップを記載した請求項は、ステップの順序が明確に指示されない限りその順序を意味するものではない。全ての商標は、各々所有者の財産である。

本発明の１つ以上の態様に基づくコンピュータシステムの実施形態を示すブロック図である。 本発明の１つ以上の態様に基づくネットワークの実施形態を示すネットワーク図である。 本発明の１つ以上の態様に基づくＩＰＳｅｃ／ＮＡＴ一体化プロセスの各部分の実施形態を示すフローチャートである。 本発明の１つ以上の態様に基づくＩＰＳｅｃ／ＮＡＴ一体化プロセスの各部分の実施形態を示すフローチャートである。 本発明の１つ以上の態様に基づくＩＰＳｅｃ／ＮＡＴ一体化プロセスの各部分の実施形態を示すフローチャートである。 本発明の１つ以上の態様に基づくＩＰＳｅｃ関連付けマッピングテーブル（ＩＰＳＡＭＴ）の実施形態を示すテーブル図である。 本発明の１つ以上の態様に基づくＩＰＳｅｃ関連付けマッピングテーブル（ＩＰＳＡＭＴ）の実施形態を示すテーブル図である。

符号の説明

１０・・・コンピュータシステム、１１・・・ＣＰＵ、１３・・・システムメモリ、１２・・・入力／出力（Ｉ／Ｏ）インターフェイス、１００・・・ＮＩＣ、１０１・・・コンピュータシステム、１０２、１０３・・・ＬＡＮ、１０４・・・ワイドエリアネットワーク（ＷＡＮ）、１０６、１０７・・・ＤＨＣＰサーバー／ＮＡＴゲートウェイ（ゲートウェイ）、１０６−Ａ、１０６−Ｂ、１０６−Ｃ・・・クライアントコンピュータ、１０７−Ａ、１０７−Ｂ、１０７−Ｃ・・・クライアントコンピュータ、１０８・・・ルーター、１１０・・・ネットワーク、１１２・・・ローカルメモリ、２００・・・ＩＰＳｅｃ／ＮＡＴ一体化プロセス、２９８・・・ＩＰＳｅｃ／ＮＡＴゲートウェイ側一体化サブプロセス、２９９・・・ＩＰＳｅｃ／ＮＡＴクライアント側一体化サブプロセス、３００・・・ＩＰＳｅｃ割り当てマッピングテーブル（ＩＰＳＡＭＴ）

Claims (10)

1. ネットワークアドレス変換（ＮＡＴ）が可能であり、リモートコンピュータとクライアントコンピュータとの間にセキュア通信チャネルを確立するゲートウェイコンピュータであって、
   メモリと、
   前記メモリに結合されたプロセッサと、
   を備え、
   前記プロセッサが、
   ゲートウェイコンピュータパブリックアドレスのプールの中の一つのゲートウェイコンピュータパブリックアドレスを前記クライアントコンピュータに提供し、
   前記リモートコンピュータに対応するインターネットプロトコル（ＩＰ）アドレスに関する第１の要求を前記クライアントコンピュータから受信し、
   前記リモートコンピュータとセキュリティアソシエーションについてネゴシエーションすることでセキュリティパラメータインデックス（ＳＰＩ）値を取得し、
   前記ＳＰＩ値に基づいて、ネゴシエーションされた前記セキュリティアソシエーションから得られる前記クライアントコンピュータのローカルアドレスと、該セキュリティアソシエーションから得られる前記リモートコンピュータの行先アドレスと、マッピングテーブル内の媒体アクセス制御（ＭＡＣ）アドレスとを前記メモリに記憶し、
   前記リモートコンピュータから受信したデータパケットを前記マッピングテーブルに基づいて前記クライアントコンピュータに向けることで、前記リモートコンピュータと前記クライアントコンピュータとの間にセキュア通信チャネルを確立する、
   ことを特徴とするゲートウェイコンピュータ。
2. 前記プロセッサが、更に、ネゴシエーションされた前記セキュリティアソシエーションに関連付けられたネゴシエーションステータスビットを含むイニシエータ指示子を前記クライアントコンピュータから取得する、
   ことを特徴とする請求項１に記載のゲートウェイコンピュータ。
3. 前記プロセッサが、更に、前記イニシエータ指示子と、タイムスタンプと、前記第１の要求のセキュリティプロトコルヘッダに関連付けられたセキュリティプロトコルタイプ識別子とを前記マッピングテーブルに記憶する、
   ことを特徴とする請求項２に記載のゲートウェイコンピュータ。
4. 前記プロセッサが、更に、
   前記ＳＰＩ値が前記マッピングテーブルに記憶されていないことを示すフラグビットをセットし、
   前記ＳＰＩ値を取得した後に前記フラグビットをクリアする、
   ことを特徴とする請求項１に記載のゲートウェイコンピュータ。
5. 前記プロセッサが、更に、所定時間を経過しても新たな情報を取得できなかった場合に前記マッピングテーブルに記憶されている情報を除去する、
   ことを特徴とする請求項１に記載のゲートウェイコンピュータ。
6. 前記プロセッサが、更に、
   第１のクライアント識別子を前記第１の要求に割り当て、
   異なるＩＰアドレスに関する第２の要求を前記クライアントコンピュータから受信し、
   前記第１のクライアント識別子から導出される第２のクライアント識別子を前記第２の要求に割り当てる、
   ことを特徴とする請求項１に記載のゲートウェイコンピュータ。
7. 前記マッピングテーブルが、更に、前記クライアントコンピュータにより確立された、前記クライアントコンピュータと前記リモートコンピュータとの間の更なる通信を識別するイニシエータクッキーを記憶する、
   ことを特徴とする請求項１に記載のゲートウェイコンピュータ。
8. 前記クライアントコンピュータのみが前記提供されたゲートウェイコンピュータパブリックアドレスを使用可能である、
   ことを特徴とする請求項１に記載のゲートウェイコンピュータ。
9. 前記ＳＰＩ値が前記マッピングテーブル内の一意の行を指定する、
   ことを特徴とする請求項１に記載のゲートウェイコンピュータ。
10. インターネットプロトコルセキュリティ（ＩＰＳｅｃ）が前記ゲートウェイコンピュータと前記リモートコンピュータとの間のトランザクションを管理し、
    前記トランザクションが、認証ヘッダ（ＡＨ）又はカプセル化セキュリティペイロード（ＥＳＰ）を有するヘッダを含む、
    ことを特徴とする請求項１に記載のゲートウェイコンピュータ。

Images