発明の分野
本発明は、一般に、ネットワークを経て通信するための改善セキュリティ(enhanced security)に係る。
発明の背景
インターネットは、いまだに成長を続けるパブリックネットワークである。多くの会社は、自身の営業活動を容易にするためにインターネットを経ての通信に依存している。しかしながら、パブリックアクセスは、セキュリティの危険も伴う。インターネットにおけるセキュリティを改善するために、インターネット・エンジニアリング・タスク・フォース(IETF)は、インターネットプロトコルセキュリティ(「IPSec」)として集合的に知られている1組のプロトコルを設計した。このIPSecは、インターネット等のネットワークを経て通信するための認証及び暗号化を与えるように設計されている。ネットワークアドレス変換(NAT)も、インターネットの成長における大きな要因となっているが、不都合なことに、NATのオペレーションは、IPSecと合致していない。
NATは、ローカル内部ネットワークトラフィックに使用される1つ以上のプライベートIP(インターネットプロトコル)アドレスのセットと、内部アドレスが外部マシンとトラフィックを交換したいときに動的に選択されるべき1つ以上の「パブリック」IPアドレスとの間を変換する。NATゲートウェイにおける変換テーブルは、組織のインターネットトラフィックが、その組織に指定された1つ(又はそれ以上)のパブリックアドレスを共有するのを許す。新たな接続のための出て行くパケットは、新たなNAT変換テーブルエントリーをゲートウェイに生成させる。NAT変換テーブルは、逆方向に到着するトラフィック(即ち、パブリックインターネットから到来するトラフィック)に対して逆変換を実行するように使用される。
LANのクライアントコンピュータは、静的に指定されたローカルIPアドレスを有してもよいが、従来、ダイナミックホストコンフィギュレーションプロトコル(DHCP)サーバーエンティティが、LANのクライアントコンピュータにプライベートIPアドレスを動的に指定する。このようなプライベートアドレスは、使用可能なプライベートIPアドレスのプールから独特に選択される。DHCPサーバープロセスは、しばしばNATゲートウェイに同一配置されるが、プライベートネットワーク内の個別装置においてホストとすることができる。従って、例えば、NATゲートウェイに対して(「背後の」)ローカル又はプライベートドメインの一部分であるクライアントコンピュータ又は他のローカルマシンからのIPパケットは、IPソース及び行先アドレスをパケットのIPヘッダに含むと共に、ソース及び行先ポートアドレスをパケットのユーザデータグラムプロトコル又は送信制御プロトコル(UDP又はTCP)ヘッダに含む。従来、パケットのIPソースアドレスフィールドは、クライアントコンピュータに静的に又は動的に指定されたプライベートIPアドレスを含むが、パケットのIP行先アドレスフィールドは、NATゲートウェイの背後にある別のマシンを行先とするパケットについてはプライベートIPアドレスを含み、或いはインターネットに接続されたリモートコンピュータのような、NATゲートウェイの背後にない別のマシンを行先とするパケットについてはパブリックIPアドレスを含む。
後者の例では、NATゲートウェイは、出て行くパケットのIPソースアドレスフィールドを、ローカルに独特のプライベートIPアドレスから、パブリック又はグローバルに独特のIPアドレスに変更する。パケットの新たなソースアドレス、ここではパブリックIPソースアドレスは、従来、NATゲートウェイの外部インターフェイスのIPアドレスであるか、又はNATゲートウェイにより管理される使用可能なパブリックアドレスのプールから割り当てられたIPアドレスである。
更に、NATゲートウェイは、更に多くの接続が同じIPアドレスを共有するのを許すために、トランスポート層アドレス(即ちTCP又はUDPポート)の変換を必要とすることがある。NATゲートウェイが、それ自身のパブリックIPアドレスを、ローカルマシンから出て行くパケットに対するパブリックIPアドレスとして使用する場合には、外部接続がNATゲートウェイコンピュータから出て来るように見える。2つのローカルクライアントマシンが同じリモートIPアドレスと通信して同じ行先TCP又はUDPポートを選択し、どのクライアントがトラフィックを返送すべきかNATゲートウェイが決定できないようにするのを防止するために、NATゲートウェイコンピュータの各接続を変換して、出て行くトラフィックが、独特に識別可能なIPパブリックアドレス及びTCP又はUDPソースポート対から出て来るように見えるようにする。このような事態が生じる機会は、微々たるものと思われるが、特に、ローカルクライアントの数が増加するにつれて考えられ、IPアドレス変換に加えてTCP又はUDPポート変換を実行することにより回避できる状態である。NATゲートウェイは、プライベート/パブリックIPアドレス関連性だけでなく、到来するトラフィックを変換及び転送するためのTCP又はUDPポート関連性も記憶するので、NATは、時々、ネットワークアドレス及びポート変換(NAPT)とも称される。
IPSecは、改善セキュリティを要求する接続を支配するパラメータのネゴシエーションに一部依存する。ピアステーション間のネゴシエーションされたセキュリティパラメータを支配する他の既知のアイテムの中でも、認証及び/又は暗号化セッションキー、キーライフライム、暗号化又は認証アルゴリズムのような例示的アイテムを含むパラメータの集合は、セキュリティアソシエーション(SA)として集合的に知られている。SAネゴシエーションは、オークリーキー決定アルゴリズムを使用するインターネットセキュリティアソシエーション及びキーマネージメントプロトコル(ISAKMP)として知られているプロトコルに基づいて実行される。ISAKMP/オークリーは、より一般的には、インターネットキー交換(IKE)として知られている。IKEネゴシエーションの1つの結果は、暗号化及び暗号解読、及び/又はデジタル符牒メッセージ(即ちIPパケット)に使用されるべきランダム選択セッションキーに対するプライベートアグリーメントである。ISAKMP、IPSec制御プロトコルに対してUDPポート500が指定される。
IPSec保護のIPパケットは、IKEにおいて認証がネゴシエーションされたか、暗号化がネゴシエーションされたか又はその両方がネゴシエーションされたかに基づいて、IPSecセキュリティプロトコルヘッダの2つの形式の少なくとも1つを合体する。これらIPSecセキュリティプロトコルヘッダを明瞭化のために要約すると、認証がネゴシエーションされたときには「認証ヘッダ」(AH)が使用され、暗号化がネゴシエーションされたときには「カプセル化セキュリティペイロード」(ESP)ヘッダが使用され、IPパケットがAH及びESPの両ヘッダを含むとき、例えば、ESPがAHと共にネゴシエーションされたときには、ESPヘッダをカプセル化するAHが使用される。
IPSecセキュリティアソシエーションが確立されると、各IPSec保護のパケットのインターネットプロトコルヘッダは、使用するセキュリティプロトコルの形式、即ちAH又はESP、その組合せを含む、を指定する。IPバージョン4(「IPv4」)では、IPv4ヘッダに8ビットの「プロトコル」フィールドがあり、これは、論理的にIP層の上にある次の上位層プロトコルを指示する。IPバージョン6(「IPv6」)では、IPv4ヘッダにおけるプロトコルフィールドと同様の機能を果たす8ビットの「次のヘッダ」フィールドがある。IPv4及びIPv6の両方において、0x32の値は、ESPを意味し、そして0x33は、AHを意味する。AH及びESPの両ヘッダは、セキュリティパラメータインデックス(SPI)として知られている数値に対して32ビットフィールドを含む。IPパケットにデジタル符牒が付けられた(AHを使用して)場合には、このようなIPパケットのIPヘッダのある重要な部分を変更しなくてもよく、さもなければ、このようなIPパケットを受信するIPSecピアステーションは、IPパケットのデジタル符牒が正しいことを確認できない。しかし、従来のオペレーション中には、NATゲートウェイが、出て行く(即ちローカルからリモート又はプライベートからパブリックへの)パケットに対するパケットのIPソースアドレス、又は到来する(即ちリモートからローカル又はパブリックからプライベートへの)パケットに対するパケットの行先アドレスを変更する。いずれの方向においても、IPヘッダのNAT変換は、AHデジタル符牒を確認するIPSecピアステーションの能力を妨げる。出て行くトラフィックの例では、介在するNATゲートウェイ又はルーターがパケットのプライベートIPソースアドレスをグローバル又はパブリックIPアドレスに変換すると、受信側コンピュータにおける認証が失敗となる。というのは、プライベートIPアドレスが、デジタル符牒の確認に、受信器にもはや得られないからである。これまで、NATゲートウェイを経て移動する間にIPパケットに必要な変更がなされるために、IPSec AHがNATに適合しない。
暗号化されたが符牒が付けられないパケット(即ちAHを伴わずにESPにより保護されたIPSecパケット)の場合には、トランスポート層ヘッダが、NATゲートウェイを含む第三者に暗号解読できず(たとえ暗号解読できてもパケット内の通常の位置にはなく)、従って、出て行く及び/又は到来する変換のプロセスに使用するためのTCP又はUDPポート番号がNATゲートウェイに得られない。従って、IPSec ESP単独(即ちAHを伴わずにESPのみ)でも、認証ヘッダの存在に関わらず、基本的NATオペレーションの妨げとなる。拡張すると、AH及びESPの両方で保護されたIPパケットの場合、そのソースIPアドレスは変更しなくてよいが、ポート番号が暗号化される。
要約すれば、IPパケットには、AHヘッダ、ESPヘッダ又はその両方が追加されてもよい。NATについて重要なこととして、AH保護されたパケットのIPソースアドレスフィールドは、デジタル符牒アルゴリズムへの入力の一部分であるので、変更できない。ESP保護されたパケットについて重要なこととして、ピアステーションが受信パケットを暗号解読する能力を妨げずにIPソースアドレスを変更してもよいが、ソース及び行先ポート番号が暗号化され、従って、NATゲートウェイにより暗号解読することができない。従って、ESPについては、NATゲートウェイによりTCP又はUDPポート番号を暗号解読できないので、これまで、戻りトラフィックルートを明確にし、即ちESP保護されたパケットをどのプライベートステーションが受信すべきか決定するメカニズムが存在しない。更に、バーチャルプライベートネットワーク(VPN)に対するESP保護されたトラフィックは、これまで、VPNセッションの数を同じリモートIPアドレスに制限するか、或いは当該非標準変更をVPNクライアントに制限していた。
従って、著しいオーバーヘッドを追加することがなく、且つIPSecのセキュリティアルゴリズムに適合しないIPソース又は行先アドレス及び/又はTCP又はUDPソース又は行先ポート変換を必要とすることもないNAT及びIPSecの一体化を提供することが要望され且つ有用となる。
発明の概要
本発明の態様は、アドレス変換構成のゲートウェイコンピュータの背後にあるクライアントコンピュータと、リモートコンピュータとの間でネットワークを経て通信するときの改善セキュリティ方法に係る。ゲートウェイコンピュータのクライアントコンピュータにはパブリックアドレスが与えられ、このパブリックアドレスは、ゲートウェイコンピュータパブリックアドレスと、ゲートウェイコンピュータパブリックアドレスのプールとの一方である。ゲートウェイコンピュータは、リモートコンピュータとのセキュリティアソシエーションネゴシエーションに参加する。ゲートウェイコンピュータは、クライアントコンピュータのローカルアドレスをリモートコンピュータの行先アドレスに関連して記録するための指示子としてセキュリティアソシエーションネゴシエーションを使用し、ローカルアドレス及び行先アドレスは、セキュリティアソシエーションネゴシエーションから得られて、ゲートウェイコンピュータによりアクセスできるデータ構造体に記憶される。
本発明の別の態様は、インターネットプロトコルセキュリティ(IPSec)パケットをネットワークアドレス変換(NAT)ゲートウェイコンピュータで処理するための方法に係る。IPSecパケットのためのパブリックインターネットプロトコル(IP)ソースアドレスをNATゲートウェイコンピュータで指定できることをNATゲートウェイにおいてチェックし、そしてパブリックIPソースアドレスをNATゲートウェイコンピュータにより指定できることに応答して、IPSecパケットがローカルコンピュータにより送信されたものかどうかの確認がなされる。IPSecパケットがローカルコンピュータにより送信されたという確認に応答して、IPSecパケットは、パブリックIPソースアドレスを変換せずに行先アドレスへ送信される。
本発明の別の態様は、ソースアドレス及びゲートウェイコンピュータのパブリックアドレスを有する受信パケットをルーティングするための方法に係る。ゲートウェイコンピュータのパブリックアドレスに関連してリストされたマッピングテーブルのソースアドレスについてチェックし、受信パケットからセキュリティパラメータインデックスを得る。マッピングテーブルのセキュリティパラメータインデックスが受信パケットのソースアドレスに関連していることをチェックする。マッピングテーブルのセキュリティパラメータインデックスが受信パケットのソースアドレスに関連しているのを見つけるのに応答して、受信パケットは、マッピングテーブルにおけるセキュリティパラメータインデックス及びソースアドレスに関連したローカルアドレスへルーティングされ、ここで、ローカルアドレスは、ゲートウェイコンピュータのパブリックアドレスではない。
本発明の別の態様は、インターネットキー交換(IKE)制御方法に係る。マッピングテーブルと共に構成されたゲートウェイコンピュータが設けられる。ローカルクライアントコンピュータからゲートウェイコンピュータにパケットが受け取られ、このパケットがIKEパケットであるかどうか決定するためのチェックがなされる。パケットがIKEパケットであるのに応答して、マッピングテーブルにおけるIKEパケットのインターネットプロトコル(IP)行先アドレス及びローカル媒体アクセス制御(MAC)アドレスの両方に一致するマッピングテーブルの記録に対してチェックが行われる。マッピングテーブルの記録を識別するのに応答して、マッピングテーブルの記録に関連したセキュリティパラメータインデックスについてチェックが行われる。
本発明の別の態様は、ゲートウェイコンピュータのためのセキュリティネゴシエーション制御方法に係る。ゲートウェイコンピュータには、データ構造体へのアクセスが与えられる。ゲートウェイコンピュータにおいてパケットが受信され、そのパケットがセキュリティネゴシエーションパケットであるかどうか決定される。データ構造体は、パケットがセキュリティネゴシエーションの一部分であることに応答して、媒体アクセス制御(MAC)ソースアドレス及び行先アドレスについてチェックされる。データ構造体に行先アドレスが見つかり且つデータ構造体にその行先アドレスに関連したMACソースアドレスが見つからないのに応答して、行先アドレスのセキュリティ値がデータ構造体にあるかどうか決定される。行先アドレスのセキュリティ値がデータ構造体に見つからないのに応答して、セキュリティネゴシエーションパケットの送信が抑制される。
本発明の別の態様は、クライアントコンピュータによってパケットを形成する方法に係る。ネットワークアドレス変換ゲートウェイコンピュータからクライアントコンピュータに対するパブリックアドレスが得られる。得られたパブリックアドレスは、パケットに対するソースアドレスとして使用される。
本発明の別の態様は、インターネットプロトコルセキュリティ(IPSec)保護されたパケットとのネットワークアドレス変換(NAT)一体化のためのマッピングテーブルを生成する方法に係る。ゲートウェイコンピュータには、マッピングテーブルへのアクセスが与えられる。ゲートウェイコンピュータにおいて、媒体アクセス制御アドレスに関連したクライアントコンピュータからパケットが受信され、媒体アクセス制御アドレスは、パケットのソースアドレスに加えて、パケットと共に送信される。ソースアドレスは、ゲートウェイコンピュータのパブリックアドレスである。ゲートウェイコンピュータは、パケットがセキュリティネゴシエーションパケットであるかどうか決定し、そしてパケットがセキュリティネゴシエーションパケットであるのに応答して、媒体アクセス制御アドレスは、この媒体アクセス制御アドレスに関連したパケットの行先アドレスと、これら媒体アクセス制御アドレス及び行先アドレスの少なくとも一方に関連したイニシエータ指示子と共に、マッピングテーブルに記録される。
本発明の別の態様は、認証ヘッダ(AH)保護されたパケットとのネットワークアドレス変換(NAT)一体化のための方法に係る。クライアントコンピュータには、NATゲートウェイコンピュータからのパブリックアドレスが与えられる。クライアントコンピュータは、パブリックアドレスをソースアドレスとしてもつAH保護のパケットを形成し、そのAH保護のパケットをクライアントコンピュータからNATゲートウェイコンピュータへ送信する。
本発明の別の態様は、ゲートウェイコンピュータのためのデータ構造体に係る。媒体アクセス制御アドレスフィールドと、この媒体アクセス制御アドレスフィールドに関連したローカルパブリックアドレスフィールドと、媒体アクセス制御アドレスフィールドに関連した非ローカルアドレスフィールドと、この非ローカルアドレスフィールドに関連したセキュリティパラメータインデックスフィールドとが設けられる。このセキュリティパラメータインデックスフィールドは、非ローカルマシンからの通信に関連したセキュリティパラメータインデックスを記憶するためのものである。
本発明の別の態様は、ネットワークアドレス変換がソースアドレスセキュリティと一体化されたかどうか決定するためにクライアントコンピュータによりゲートウェイコンピュータを探査する方法に係る。第1クライアント識別子をもつクライアントコンピュータによりゲートウェイコンピュータについて第1アドレスに対する第1要求がなされる。この第1要求に応答してゲートウェイコンピュータにより第1アドレスが送信される。第2クライアント識別子をもつクライアントコンピュータによりゲートウェイコンピュータから第2アドレスについて第2要求がなされ、ここで、第2クライアント識別子は、第1クライアント識別子と同様である。第2アドレスは、第2要求に応答してゲートウェイコンピュータからクライアントコンピュータにより受信される。クライアントコンピュータは、要求された第2アドレスから、ネットワークアドレス変換がゲートウェイコンピュータに対するソースアドレスセキュリティと一体化されたかどうか決定する。
本発明の別の態様は、ソースアドレス保護のパケットに対するネットワークアドレス変換方法に係る。クライアントコンピュータは、アドレスサーバーコンピュータと通信するように設けられる。クライアントコンピュータからの第1要求が、アドレスサーバーコンピュータからの第1アドレスに対してなされ、クライアントコンピュータは、アドレスサーバーコンピュータにより媒体アクセス制御番号で識別できる。この第1要求に応答してアドレスサーバーコンピュータによりクライアントコンピュータにプライベートアドレスが与えられる。媒体アクセス制御番号の変更がクライアントコンピュータにより発生され、変更された媒体アクセス制御番号が与えられる。アドレスサーバーからの第2アドレスがクライアントコンピュータにより要求され、クライアントコンピュータは、アドレスサーバーコンピュータにより、変更された媒体アクセス制御番号で識別できる。アドレスサーバーコンピュータは、媒体アクセス制御番号をその変更された媒体アクセス制御番号に関係付けることにより、クライアントコンピュータと第1要求及び第2要求とを関連付けると共に、第2要求に応答してパブリックアドレスをクライアントコンピュータに与える。
本発明の前記特徴、効果及び目的がいかに達成されるかを詳細に理解するために、前記で簡単に要約した本発明を、添付図面に示されたその実施形態を参照して詳細に述べる。
しかしながら、添付図面は、本発明の典型的な実施形態を示すに過ぎず、その範囲をこれに限定するものではなく、本発明は他のやり方でも等しく有効に実施できることに注意されたい。
詳細な説明
本発明は、IPSec及びNATを共存させる方法及び装置であって、クライアントコンピュータの外部を行先とするパケットがプライベートIPソースアドレスを使用しないように構成されたときに、IPSecに適合しないNATのIPアドレス或いはTCP又はUDPポート変換をパケットに対して実行する必要がないメカニズムを生成するような方法及び装置を提供する。むしろ、クライアントのIPSecソフトウェアは、その外部を行先とするパケットを、NAT装置により与えられるパブリックIPアドレスを使用して生成する。
各リモートIPアドレスから各ローカルピアクライアントマシンへのトラフィックは、AH又はESPヘッダに独特のセキュリティパラメータインデックスを有し、これを、TCP又はUDPポートに代わって使用して、どのローカルステーションにIPSec保護のパケットを送信すべきかNATが判断するのを許すことができる。各ローカルクライアントが1つのリモートIPアドレスに話をし、他のクライアントがその同じリモートIPアドレスに話をしない限り、変換は、IPソースアドレスフィールドのみを含む従来のNAT変換でよい。しかしながら、多数のローカルクライアントマシンが、同じリモートIPアドレスと通信するように向けられた場合には、IPSec可能なNATゲートウェイは、ローカル/リモート対のマシン間で一度に1つのSAしかネゴシエーションされないよう確保するためにIKE抑制を実行する必要がある。セキュリティパラメータインデックスは、平文で使用されるが、プライベートにネゴシエーションされるという事実においてここには難解さが存在し、従って、NATゲートウェイは、リモートステーションが第1のIPSec保護のパケットをローカルステーションへ送信するまで使用中のネゴシエーションされたセキュリティパラメータインデックスへアクセスできない。そのセキュリティパラメータインデックスが分かると、他のローカルステーションは、そのリモートステーションとの自身のセキュリティアソシエーションを、一度に1つ、ネゴシエーションしてもよい。
本発明の一態様は、NATゲートウェイがクライアントコンピュータとリモートコンピュータとの間に配置された状況においてIPSecのAHの使用を許すための方法に係る。クライアントコンピュータは、ゲートウェイコンピュータからのパブリックアドレスを要求し、それに応答して、パブリックアドレスがクライアントコンピュータへ与えられる。IPSecセキュリティアソシエーションがリモートコンピュータとネゴシエーションされる。セキュリティアソシエーションのネゴシエーションは、クライアントのローカルアドレス(NAT/AH共存の場合のそのMACアドレス、NAT/ESP共存の場合のそのプライベートIPアドレス)と、リモートコンピュータのIPアドレスとの間の関連性を記録するためのトリガーとしてゲートウェイコンピュータにより使用され、ここで、ローカルアドレス及び行先アドレスは、第1の出て行くセキュリティアソシエーションネゴシエーションパケットから得られる。リモートコンピュータとのセキュリティアソシエーションネゴシエーションから生じるセキュリティパラメータインデックス値は、将来使用するためのローカルアドレスに関連して得られて記憶され、即ちリモートステーションがIPSec保護のトラフィックをローカルクライアントに向けて送信し始めるときに得られて記憶される。
本発明の一態様は、ゲートウェイコンピュータのためのデータ構造体に係る。このデータ構造体は、ローカルアドレス(媒体アクセス制御(MAC)又はIPアドレス)フィールドと、前記ローカルアドレスフィールドに関連したリモートIPアドレスフィールドと、ローカルアドレスフィールドに関連したリモート対ローカルセキュリティパラメータインデックス(SPI)フィールドと、リモートアドレスからローカルアドレスへ流れるトラフィックを特に識別するためのリモートアドレスフィールドとを備えている。リモート対ローカルSPIフィールドは、リモート配置のマシンからの少なくとも1つのセキュリティパラメータインデックスを記憶するためのものである。
本発明の一態様は、インターネットキー交換(IKE)抑制方法に係る。ゲートウェイコンピュータは、マッピングテーブルと共に構成される。受信したパケットは、IKEパケットであるかどうか決定するようにチェックされる。IKEパケットである場合には、マッピングテーブルをチェックして、行先(リモート)IPアドレスが、パケットのソースMAC又はIPアドレスにも一致するマッピングテーブルのエントリーに一致するかどうか調べる。更に、ISAKMP「イニシエータクッキー」値(64ビット)を、このマッピングテーブルのエントリー、即ちクライアントのMAC又はIPアドレスとリモートIPアドレスである一対のアドレスに一致するエントリー、との一致に対してチェックする。マッピングテーブルにおける一致するエントリーが見つかるのに応答して、ローカルクライアントとリモートIPアドレスとの間のセキュリティネゴシエーションが進行中であるか又は完了したという指示に対してチェックがなされる。リモート対ローカルのセキュリティパラメータインデックスがまだマッピングテーブルにない場合には、IKEパケットの送信が抑制される。
本発明の一態様は、ゲートウェイルーティング方法にある。リモート対ローカルパケットは、マッピングテーブルエントリーに対する有効なセキュリティパラメータインデックスが、パケットのリモートIPアドレス(リモート対ローカルパケットのIPソースアドレス)及びそのIP行先アドレスに一致するかどうかについてチェックされ、これは、ゲートウェイマシンがローカルクライアントのMACアドレスを使用してマシンに割り当てたパブリックIPアドレスでなければならない。このリモートIPアドレスに関連した一致するリモート対ローカルセキュリティパラメータインデックスが見つかった場合には、マッピングテーブルのその行のコンテンツで指示されるように、そのパブリックIP行先アドレス及びそのMACアドレス、又はそのプライベートIPアドレスを使用して、パケットがローカルクライアントへ転送される。プライベートIPアドレスフィールドがいっぱいになると、パブリックIPアドレス及びMACアドレスフィールドのコンテンツがブランクになる。
本発明の一態様は、NATゲートウェイコンピュータによりIPSecのAHパケットを処理するための方法に係る。ローカル対リモートのIPSecパケットに対するIPソースアドレスフィールドは、パケットのMACソースアドレスフィールドに見つかったMACアドレスを処理するステーションに指定されたプライベートアドレスを含むかパブリックアドレスを含むかを調べるようにチェックされる。パケットのIPソースアドレスがパブリックアドレスであることをゲートウェイが発見し、このパブリックアドレスは、パケットのMACソースアドレスフィールドにおけるMACアドレスと同じMACアドレスを有するマシンに指定したものであることもゲートウェイが知っている場合には、IPSecパケットは、NATゲートウェイコンピュータにより不変のまま(IPv4パケットの場合にはTTLを減少し、IPチェック和を更新することを除いて;IPv6パケットは、NATが要求されないほど豊富であり、従って、IPv6の場合IPSec対NATの問題はない)送信される。
リモート対ローカルIPSecパケットのIPソースアドレスフィールドは、マッピングテーブルにおけるリモートIPアドレス列に対して一致がとられ、パケットのSPIは、このリモートIPアドレスに関連したマッピングテーブルの行に記憶された予想されるリモート対ローカルSPIに対して一致がとられる。一致するマッピングテーブルエントリーが見つかった場合は、マッピングテーブルの一致する行から抽出されたローカルクライアントのMACアドレス(又はプライベートIPアドレス)へパケットが転送される。
以下の説明では、本発明をより完全に理解するために多数の特定の細部について述べる。しかしながら、当業者であれば、本発明は、これら特定の細部の1つ以上を伴わずに実施できることが明らかであろう。他の場合に、本発明が不明瞭になるのを回避するために良く知られた特徴は説明しない。
図1は、本発明の1つ以上の態様に基づくコンピュータシステム10の実施形態を示すブロック図である。このコンピュータシステム10は、CPU11と、システムメモリ13と、入力/出力(I/O)インターフェイス12と、NIC100とを備えている。NIC100は、I/Oとしてネットワーク110から/へ結合されてもよい。NIC100は、ローカルメモリ112を含む。
図2は、本発明の1つ以上の態様に基づくネットワーク110の実施形態を示すネットワーク図である。ネットワーク110は、ワイドエリアネットワーク(WAN)104を備えている。このWAN104は、インターネットでもよいし、インターネットサブネットワーク(「サブネット」)でもよいし、又は他のワイドエリアネットワークでもよい。1つ以上のコンピュータシステム101をWAN104に時々ログオンすることができる。重要なことに、1つ以上のコンピュータシステム101がサーバーとなってもよい。更に、DHCPサーバー/NATゲートウェイ(「ゲートウェイ」)106及び107は、各々LAN102及び103に結合される。クライアントコンピュータ106−A、106−B及び106−Cは、LAN102を経てゲートウェイ106との通信状態に入ってもよい。同様に、クライアントコンピュータ107−A、107−B及び107−Cは、LAN103を経てゲートウェイ107との通信状態に入ってもよい。NATゲートウェイ106及び107は、ルーター108を経てWAN104に結合されてもよい。或いはまた、ゲートウェイ106及び107は、ゲートウェイ−ルーター、即ちNATゲートウェイとルーターとの組合体でもよく、また、その一体化装置にDHCPサーバーファンクションが組み込まれてもよい。
ネットワーク110は、単なる実施例に過ぎず、より少数の又は多数のコンピュータ、ゲートウェイ、LAN又はWAN、及びその組合体が使用されてもよい。更に、クライアントコンピュータ106−A、106−B及び106−Cは、その各々がNIC100をローカルメモリ112と共に有するという点で図1のコンピュータシステム10と同様に構成されてもよい。明瞭化のため、他の構成体をここに述べるように使用してもよいが、この説明の残り部分は、リモートサーバー101と通信するためにルーター108を経てインターネット104に結合されたDHCP/NATゲートウェイ106の背後にあるクライアントコンピュータ106−Aについてである。このようなネットワークの従来の例は、インターネットを経て会社のサーバーに接続するスモールオフィス/ホームオフィス(SOHO)ネットワークの社員でよい。明瞭化のため、ローカルアドレスは、ゲートウェイにより指定されるアドレスを指し、非ローカルアドレスは、他の全てのアドレスを指す。
図3は、本発明の1つ以上の態様に基づくIPSec/NAT一体化プロセス200一部分の実施形態を示すフローチャートである。一体化プロセス200は、IPSec/NATクライアント側一体化サブプロセス299と、IPSec/NATゲートウェイ側一体化サブプロセス298とを含む。図3を参照すると共に、図1及び2を再度参照して、一体化プロセス200について説明する。
ステップ201において、クライアントコンピュータ(又は「クライアント」)106−Aのようなクライアントコンピュータは、ゲートウェイ106のようなゲートウェイからIPアドレスを要求する。ステップ201におけるこのような要求は、クライアントコンピュータ106−Aにプログラムされたソフトウェアによって行なわれてもよいし、更に詳細には、「ネットワークインターフェイスカード」即ち「NIC」100のようなネットワークインターフェイスのためのドライバの一部分であってもよいし、或いはローカルメモリ112に記憶されたプログラムコード299(これに限定されないが)を含むNICのハードウェア又はファームウェアの一部分であってもよい。
クライアント106−AがプライベートIPアドレスを受信した場合に、クライアント106Aは、クライアント106Aがプライベートアドレスドメインの外部にトラフィックを送信できるのでNATゲートウェイが使用されることを知る。プライベートIPアドレスのリストは良く知られているので、クライアント106Aは、それにプライベートIPアドレスが指定されたかどうか決定するテストを行うことができる。ステップ202において、クライアント106Aは、IPアドレスに対する別の要求を提出し、このときには、そのDHCPクライアント識別子(そのMACアドレスとしても知られている)におけるローカルビットを反転する。良く知られたように、ゲートウェイ及びクライアントの両方を含むLANの各コンピュータには、このようなLANに対する独特の番号、即ちMACアドレスが指定される。従来のMACアドレスは、組織独特の識別子(OUI)及び製造者独特の識別子として知られている2つの24ビットセグメントに分割された48ビット番号である。OUIの第1バイトは、最下位ビット(LSB)がマルチキャストビットである。最上位バイトにおける最下位の次のビットがローカルビットである。
例えば、NATゲートウェイ106におけるDHCPプロセスは、LAN102のようなLANにログオンされたクライアントコンピュータ106−Aに、ステップ201からの第1クライアント識別子を伴う第1DHCP要求に応答して、ステップ251でプライベートIPアドレスを指定し、次いで、第2DHCP要求が、ステップ202において、LAN102にログオンされたクライアントコンピュータ106−Aからの異なるクライアント識別子と共に、NATゲートウェイ106へ行なわれてもよい。この第2のクライアント識別子が、それに関連する第1クライアント識別子から導出されるのが重要である。従って、ゲートウェイ106が、ステップ252における暗示的チェックで示されるように、NAT以上にIPSecをサポートする場合には、2つのMACアドレスが同じ要求ステーションからのものであると認識できる。AH IPSecをサポートするように構成されたNATゲートウェイがこの決定を行い、従って、第2のプライベートIPアドレスを送信せず、むしろ、ステップ255においてパブリックIPアドレスを送信する。しかしながら、このようなNATゲートウェイがAH IPSecをサポートしない場合には、DHCPサーバーがステップ253において第2のプライベートIPアドレスを指定する。というのは、これは、各ローカルビット値のみが異なる2つのMACアドレス間の関係に起因しないからである。
ゲートウェイ106がAH IPSecをNATと共に実行するように構成された場合には、ステップ254において、ゲートウェイ106は、クライアントコンピュータ106−AのMACアドレスを、マッピングテーブルに、パブリックIPソースアドレスと共にゲートウェイ106のパケットを送信するのに適格なものとして記録してもよい。或いはまた、ゲートウェイ106は、以下に詳細に述べるように、IKEを待機してもよい。
ステップ201の後のプライベートIPアドレスの指定に基づいて、クライアント106−Aは、NATゲートウェイ106の存在を予め推測することができる。第2のプライベートIPアドレスの指定は、ステップ204において、クライアント106−Aに、NATゲートウェイ106がAH IPSecをサポートしないことを指示する。しかしながら、クライアント106−Aが、ステップ202からのDHCP要求に応答して、非プライベート(即ちパブリック)IPアドレスを受信した場合には、クライアント106−Aは、それに応答して、ステップ206で、NATゲートウェイ106がAH IPSecをサポートすることを知り、ステップ206において、以下に詳細に述べるように、MACアドレスに関連してパブリックIPアドレスを記録する。更に、NATゲートウェイ106がAH IPSecをサポートする場合には、クライアント106−Aがその後にIKEを使用してAH及び/又はESPをネゴシエーションしてもよく、この能力は、ステップ207に示すように注目又は記録されてもよい。一方、クライアント106−Aは、NATゲートウェイ106がAH IPSecをサポートしないことが検出された場合には、ESPをIKEのみとネゴシエーションすることに制限される。
NATゲートウェイ106におけるDHCPサーバーは、最初のDHCP要求で供給されたクライアント識別子が、ローカルビットが反転している点だけ、その後のDHCPクライアント識別子と相違するときに、2つのMACアドレスを同じクライアントコンピュータ106−Aに対応するものとして相関するように構成される。換言すれば、ローカルビットを除くと、各DHCPクライアント識別子は、他の点で同一である。このようなDHCPサーバーは、マッピングテーブルに記憶された2つのMACアドレスがローカルビットだけ異なることに応答して、ゲートウェイ106に得られるパブリックアドレス(の1つ)をクライアントコンピュータ106−Aへ送信するようにプログラムされ、これにより、このようなパブリックIPアドレスを、以下に詳細に述べるように、AH又はESPとAH IPSecとのセッションに使用することができる。
しかしながら、DHCPサーバーが、上述したように、クライアント識別子のローカルビット値だけが相違するという同じクライアントコンピュータ106−Aからの2つのDHCP要求の相関をサポートしない場合には、第2のプライベートIPアドレスが、要求を発しているクライアントコンピュータ106−Aへ送信される。クライアントコンピュータ106−Aは、第2のプライベートアドレスを受信すると、DHCPを使用して、ステップ204において、プライベートIPアドレスの一方を解除してプライベートアドレスのプールへ戻し、それを別のローカルステーションに指定できるようにする。従って、第2のプライベートIPアドレスがDHCPサーバーから送信された場合には、これが、クライアントコンピュータ106−Aに、NATが使用されていること、及びパブリックIPアドレス指定能力が設けられていないことを通知する。換言すれば、ゲートウェイ106は、NATをサポートするが、ここに定義するアルゴリズムに基づくAH IPSec及びNATをサポートしない。従って、ステップ205において、クライアントコンピュータは、以下に詳細に述べる理由で、ESPベースのセキュリティアソシエーションのIKEネゴシエーションしか安全にサポートできないことを決定する。
注目すべきことに、ESPのみのIPSecに対する本発明の1つ以上の態様ではパブリックIPアドレスが必要とされない。しかしながら、従来は、IKEネゴシエーションの結果として、AHのみ、ESPのみ、又はAHを伴うESPのいずれのIPSecが使用されようとするか前もって分からない。従って、プロセス200は、IKEに対してAHのみ又はAHを伴うESPのIPSecが合意される場合のようにパブリックIPアドレスを前もって要求する。もし入手できれば、パブリックIPソースアドレスを使用して、IPSec通信が実行されているというフラグをゲートウェイ106に立てる。また、ゲートウェイ106は、クライアント106AがパブリックIPアドレスを要求するためにローカルビットが反転されたDHCPクライアント識別子を送信したこと(及びゲートウェイ106により1つが指定されたこと)を観察することにより、且つクライアント106−AからのIKE交換の開始に基づいて、IPSec通信が実行されているという手掛りを得ることもできる。更に、ここに述べるパブリックIPソースアドレスは、ESPのみのIPSec、並びにAHのみ又はAHを伴うESPのIPSecのトラフィックに対して作用するので、IKE及び他の全てのIPSecトラフィックに対してパブリックIPソースアドレスが入手できるときにそれを使用することにより、首尾良いIPSecオペレーションの見込みが高くなる。ステップ210では、クライアントコンピュータ106−AがIKEネゴシエーションを開始する。IKEネゴシエーションは、プロトコルスタックがプライベートIPアドレスでスタートしてIKE開始パケットを生成するという従来のやり方で進められる。注目すべきことに、IKEネゴシエーションの場合に、IKEが「NAT保安」プロトコルであるので、プライベートIPアドレスは、IPソースアドレスとして使用されてもよい。クライアント106−Aは、パブリックIPアドレスが入手できる場合には、IKEネゴシエーションを開始するときにパブリックIPアドレスをIPソースアドレスとして使用するように選択してもよい。
或いはまた、クライアントコンピュータ106−Aは、パブリックIPアドレスを得る前にIKEでスタートしてもよい。しかしながら、ゲートウェイ106がパブリックIPアドレスを与えるように構成されていない(又はこのような動作を行なうことができない)場合には、このようなゲートウェイ106に合致しないAHのみ又はAHを伴うESPを使用するための合意を含んでもよいIKEネゴシエーションが完了するまで、このことが発見されない。従って、新たなIKEを実行することが必要になる。クライアントコンピュータ106−Aは、ゲートウェイ自身のパブリックアドレスであるか或いはゲートウェイ106が管理するパブリックアドレスのプールから選択されたアドレスであるパブリックアドレスをそのIPソースアドレスとして有するパケットを形成してもよい。クライアントコンピュータ106Aは、プライベートIPソースアドレスを有するパケットを形成してもよい。換言すれば、クライアントコンピュータ106−Aは、プライベートIPアドレスとパブリックIPアドレスとの間で選択を行うように構成されてもよく、この選択は、ある場合にはその利用性を前提とし、別の場合には、もし入手できれば、IPSecプロトコルを使用すべきかどうかを前提とする。パブリックアドレスが得られると、このようなパブリックアドレスをソースアドレスとしてパケットを形成することが従来のやり方で行なわれてもよい。後者の場合に、AH IPSec NATが許されれば、IPSec保護のトラフィック及び非IPSec保護のトラフィックの両方が流れてもよい。非IPSec保護のトラフィックは、従来のNATを使用してもよいことを想起されたい。また、LANのようなプライベートドメイン内で、クライアント106−Aは、別のローカルクライアントとのIPSec保護通信に参加してもよいし、しなくてもよい。IPSecとのイントラドメイン通信のこのような例では、たとえIPSecが使用されていても、IP行先アドレスがクライアントコンピュータ106−Aと同じプライベートアドレスドメイン内にあるので、パブリックIPアドレスを使用する必要はない。従って、クライアント106−Aのユーザは、IPSecをもつピアステーションと通信すべきかどうか決定し、更に、このようなピアステーションが、このような通信の場合に、クライアントコンピュータ106−Aのプライベートアドレスドメインに対して内部であり即ちローカルドメインアドレスを有するかどうか決定してもよい。
クライアントコンピュータによりステップ210においてIKEが開始されるのに応答して、ゲートウェイ106は、ステップ260において、IKE初期化パケットの受信を使用して、このようなクライアントコンピュータのMACアドレスと、このようなIKE初期化パケットの行先IPアドレスとを記録してもよい。NATゲートウェイ106は、パケットが、ソースポート及び行先ポートの両方が500に等しいUDPパケットであることをチェックすることにより、パケットがIKEパケットであることを決定してもよい。このMACアドレスをもつIKEに対する出て行くトラフィックが送信されたことを指示するために、ステップ260において、ビット即ちペンディングビットがセットされてもよい。このIKEパケットの行先IPアドレスは、上述したリモートサーバーのようなリモートマシンに対するものである。ゲートウェイ106は、IKEネゴシエーションにはいずれにせよ直接的に参加しないが、その他IKEパケットのNAT変換も考えられ、これは、クライアント106−AがIKEパケットのソースアドレスのようなプライベートIPアドレスを使用する場合だけである。IPSecをサポートするNATゲートウェイは、IKE抑制をサポートしなければならず、これは、いかなる所与の時間にも1つのIKEネゴシエーションしか進行せず、従って、IKEパケットをネットワークアドレス変換するときには、IPアドレス変換だけで充分であるから、ポート変換は必要でないことを意味する点に注意されたい。
図5A及び5Bには、本発明の1つ以上の態様に基づく異なる時間におけるIPSec割り当てマッピングテーブル(IPSAMT)300の実施形態が示されている。このIPSAMT300は、開始される各IKEに対する行と、タイムスタンプ305、ISAKMPイニシエータクッキー307、IPSecプロトコル識別子、ローカルクライアントMACアドレス301、ローカルクライアントパブリックIPアドレス309、ローカルクライアントプライベートIPアドレス306、リモート対ローカルセキュリティパラメータインデックス302、ペンディングビット303、及びリモートIPアドレス304の各フィールドに対する列とを備えている。
タイムスタンプフィールド305は、ペンディングビットフィールド303の状態に基づいて解釈される。ペンディングビットフィールド303がセットされた場合には、タイムスタンプフィールド305は、リモートIPアドレスフィールド304のアドレスとローカルクライアントMACアドレスフィールド301の関連アドレスとの間の最新のIKEパケットの時間で集団構成される。ペンディングビットフィールド303の状態がクリアである場合には、タイムスタンプフィールド305は、マッピングテーブル300の行におけるリモートIPアドレスフィールド304のアドレスに一致するリモートIPアドレスから最新のIPSec保護パケットが受信された時間を含む。マッピングテーブル300がいっぱいになった場合には、最も長い時間アイドル状態であった行が、タイムスタンプフィールド305からの情報を使用して最初の削除ラインとされる。
IPSecプロトコルフィールド308は、2ビットフィールドとしてエンコードすることができ、00のパターンは無効パターンを示し、10はAHを示し、01はESPを示し、更に、11はAHを伴うESPを示すが、他のエンコードも考えられることを理解されたい。リモート対ローカルセキュリティパラメータインデックスフィールド302は、リモートIPアドレスフィールド304のアドレスから、MACアドレス及びパブリック又はプライベートIPアドレスにより識別された特定のローカルクライアントに向けられたトラフィックに関連したセキュリティパラメータインデックス値を記憶するためのものである。
図5A及び5Bを参照し続けると共に、図1、2及び3を再び参照すると、NATゲートウェイ106が、クライアントコンピュータ106−AのMACアドレスを、マッピングテーブルに記録された第1リモートIPアドレスに一致させるようにマッピングテーブルに記録した後に、「IKE抑制」を使用して、ローカルクライアントマシンとリモートIPアドレスとの間に一度に1つのIKE交換しか生じないように確保することができる。ローカルクライアントとリモートIPアドレスとの間で所与の時間に未決着であるIKEネゴシエーションは1つだけであるから、所与の時間にマッピングテーブルの行に対して不完全の欠落したセキュリティパラメータインデックスエントリーは1つだけである。多数のローカルマシンがIPSecを使用して同じリモートIPアドレスにアクセスするよう向けられる場合には、IKEネゴシエーションが先着・先処理ベースで処理される。最も以前のIKEネゴシエーションが完了し、即ち新たに到来するセキュリティパラメータインデックスがそのリモートIPアドレスから記録されると、別のIKEネゴシエーションを開始することが許される。より詳細には、ゲートウェイ106は、リモートIPアドレスからそのパブリックIPアドレスの1つを宛先とするパケットを受信し、これは、1)マッピングテーブルの行にセットされたペンディングビット303を有し、2)マッピングテーブルのその行にセキュリティパラメータインデックスエントリーをもたない。ゲートウェイ106は、このパケットのセキュリティパラメータインデックスを、IPSAMT300のようなマッピングテーブルのこの行におけるこの空きスロットに記録し、次いで、このパケットを、マッピングテーブルの同じ行から取り出されたクライアントアドレスへ転送する。
注目すべきことに、AH及びESPは、各々のセキュリティパラメータインデックス形式を有し、到来する及び出て行く、の両方のセキュリティパラメータインデックス形式が存在する。従って、マッピングテーブルは、AH又はESPトラフィックに対する列を有してもよく、ここで、AHは、AHを伴うESPを含む。しかしながら、ローカルマシンと、リモートIPアドレスに関連したリモートマシンとの間のIKE交換を監視することによりマッピングテーブルに行が追加される。
IKEピアのリモートIPアドレスと、このようなIKEピアとのIKE会話に参加するローカルクライアントのMACアドレスとを有するマッピングテーブルを使用して、このようなIKEピアからセキュリティパラメータインデックスを記憶する。注目すべきことに、IKEネゴシエーションが完了した後、このようなセキュリティパラメータインデックスは、IPSec保護されたトラフィックがこのようなリモートIPアドレスに対するリモートマシンからNATゲートウェイ106へ実際に流れるまで、このようなマッピングテーブルに追加することができない。セキュリティパラメータインデックスは、IKE中に暗号化され、そしてこのようなIPSecセッションに対する真のデータが送信されるとき、即ちIKEセッションが首尾良く完了した後でなければ、非暗号即ち「平文」で現われない。リモートアドレスからのセキュリティパラメータインデックス間の関連性に関する上述した理由に加えて、セキュリティパラメータインデックスはIKE中に暗号化されて、真の暗号化データが流れ始めたときしか平文で現われないので、IKE抑制の一部分として実際のデータが流れ始めるまで、同じ行先IPアドレスに対して一度に1つのみのオープンのリモート対ローカルセキュリティパラメータインデックスエントリーがマッピングテーブルに許されてもよい。各アクティブなクライアントが異なるリモートIPアドレスとネゴシエーションする限り、ゲートウェイ106を経て多数のIKEセッションが行なわれてもよい。首尾良くネゴシエーションされたIKEに対するセキュリティパラメータインデックスがリモートIPアドレスに対して得られると、その同じリモートIPアドレスに対して別のIKEセッションが開始されてもよい。
従って、多数の通信モードがあることを理解されたい。クライアント106−Aが、そのIKE又はIPSec保護トラフィックを送信するときにパブリックIPアドレスをソースアドレスとして使用した場合には、その戻りトラフィックは、マッピングテーブルを使用して、クライアントのMACアドレスに対してセキュリティパラメータインデックスが得られるときにはそこへマップされ、そしてこのようなセキュリティパラメータインデックスが得られるまでは、戻りトラフィックは、マッピングテーブルを使用して、クライアントのMACアドレスに対してオープンのペンディングビットを有するリモートIPアドレスへマップされる。
クライアント106−Aが、そのESPのみのIPSecトラフィックを送信するときにプライベートIPアドレスを使用し、そのトラフィックがその後にネットワークアドレス変換される場合には、到来するトラフィックに対して、NAT IPアドレス変換は、クライアントのプライベートIPアドレスと、マッピングテーブルに記憶されたリモートIPアドレス(即ち到来するトラフィックに対するソースアドレス)との関連付けにより実行され、更に、ポートアドレス変換は、マッピングテーブルを使用して、クライアントのプライベートIPアドレスに対してセキュリティパラメータインデックスが得られるときにはそこへマッピングされる。このようなリモートIPアドレスに対してセキュリティパラメータインデックスが得られない場合には、このようなリモートIPアドレスに関連したオープンのペンディングビットを有するクライアントのプライベートIPアドレスが使用される。ゲートウェイ106は、ローカルクライアント106−Aにより開始されたISAKMPネゴシエーションが首尾良く完了したかどうか明確なやり方で決定できない。しかしながら、不必要なペンディング状態がマッピングテーブルに維持されないよう保つ助けをする上で使用できる2つの暗示的な手掛りがある。ローカルクライアントがISAKMPメインモード交換を開始する場合には、このようなメインモード交換の直後にクイックモード交換が続かねばならない。クイックモードパケットが見られない状態で5秒以上経過した場合には、このネゴシエーションが失敗となり、このようなISAKMPメインモード交換に応答して生成された行をこのようなマッピングテーブルから除去することができる。
或いはまた、ローカルクライアントが、常に3つのパケットを取り上げるアグレッシブモード交換を開始するも考えられる。2つのパケットが見られ、次いで、第3のパケットを見ずに5秒が経過した場合には、このようなネゴシエーションが失敗となり、このようなISAKMPアグレッシブモード交換に応答して生成された行をこのようなマッピングテーブルから除去することができる。従って、マッピングテーブルにおいてタイムスタンプをISAKMPイニシエータクッキーに関連付けることを使用して、このような時間限界が経過したかどうか決定してもよい。従って、ポート番号ではなく、セキュリティパラメータインデックスが逆変換に使用されるので、多数のVPN接続を同時にサポートするのに特殊な又は変更型のVPNが必要とされないことが明らかであろう。それ故、ここに述べるように逆変換のためにTCP又はUDPヘッダにアクセスできる必要はない。更に、セキュリティパラメータインデックスは固定のオフセットであるから、マッピングテーブルに対するインデックスとして使用するためにパケットにおいてそれにアクセスすることが容易にされる。或いはまた、パブリックIPアドレスを得るための第2のDHCP要求を実行するように構成されたプログラム製品のドライバによりローカルクライアントのNICを変更するのではなく、ESPのみのVPNが使用される場合には、ゲートウェイ106は、マッピングテーブルで構成されるが、クライアント106−Aは、IKE及びESPのみのIPSecがNATに合致するので、変更を必要としない。
IKE抑制は、ESPのみのIPSecを使用して多数の個別のリモートIPアドレスと通信しているクライアントには使用されない。IKE抑制は、同じリモートIPアドレスと通信している多数のローカルマシンをサポートするのに使用される。しかしながら、VPNを変更せずにVPNセッションのためにローカル対リモートマシンに対して多数対1のマッピングをもたせる能力が実質的に効果的である。その一例は、会社の同じサーバーへ通信することを全てが希望する会社用のテレコミュターである。
パブリックIPアドレスをネットワークインターフェイスレベルで得ることを組み込むことにより、オペレーティングシステム(OS)を含む必要がなくなる。換言すれば、OSレベルにおいて、IKEが開始され、このような開始に応答して、NIC100がパブリックIPアドレスを自動的に要求する。この要求は、IKE開始以外のOSアクションを必要としない。更に、NIC100は、IPSecに対して構成され、従って、パブリックアドレスが得られた場合には、それがIPSecパケットに自動的に使用されてもよい。更に、クライアント及びゲートウェイによりサポートされる既知のプロトコルは、付加的な信号チャンネルを導入せずに使用されてもよい。
図3Aには、本発明の1つ以上の態様に基づくIKE抑制を伴うIPSec/NATゲート側一体化サブプロセス298の実施形態を示すフローチャートである。ステップ217において、NATゲートウェイ106は、パケットを受信する。このパケットは、図3のステップ210からのIKE開始パケットでよい。ステップ218において、NATゲートウェイ106は、このようなパケットをチェックして、それがIKEパケットであるかどうか決定する。
図3Aを参照し続けると共に、図1、2、5A及び5Bを再度参照すると、ステップ218において、受信パケットがIKEパケットでない場合には、ステップ219において、このようなパケットがソースIPアドレスとしてパブリック又はプライベートIPアドレスを有するかどうか決定するチェックが行われる。NATゲートウェイ106は、IPSec及び非IPSecパケットを受信できるが、LAN102のクライアントコンピュータ106−AからCのようなクライアントコンピュータは、IPSecセッションに関する通信についてのみNATゲートウェイ106へIPソースアドレスとしてパブリックIPアドレスを送信する。注目すべきことに、ESPのみのIPSecをネゴシエーションすることは問題でない。というのは、NATゲートウェイ106を通るESPのみのトラフィックに対してパブリックIPアドレスがIPソースアドレスとして使用されてもよいからである。ステップ219において、ソースIPアドレスが、NATゲートウェイ106に得られるパブリックIPアドレスである場合には、これが、NATゲートウェイ106に、このような受信パケットをIPSecセッションに対して処理すべきことを指示する。従って、パブリックIPソースアドレスをもつパケットがステップ219において見つかった場合には、それがステップ256においてNATを伴わずに処理される。換言すれば、NATゲートウェイ106は、パブリックIPアドレスをソースIPアドレスとしてもつがNATを伴わないパケットを送信する。プライベートIPソースアドレスをもつパケットがステップ219において見つかった場合には、それがステップ257においてNATを伴って処理される。換言すれば、NATゲートウェイ106は、このパケットをWAN104に送信する前に、パブリックIPアドレスをこのようなプライベートIPソースアドレスに置き換える。
ステップ218において、受信パケットがIKEパケットである場合には、ステップ221において、このようなパケットの行先IPアドレスがIKE抑制サブルーチン297の一部分としてマッピングテーブルにあるかどうか決定するチェックがなされる。IKE制御又は抑制により、IKE抑制されたパケットは、以下に詳細に述べるように、リモート対ローカルSPIが記憶され且つペンディングビットが反転されるまで、ゲートウェイ106により送信されることを理解されたい。換言すれば、所与のローカルクライアントMACアドレスと所与のリモートIPアドレスとの間に1つのIKE「会話」だけが進行中であってもよい。
仮定により、NATが全ての外部トラフィックをローカルクライアントにより開始するように強制するので、IKEトラフィックは、常に、クライアント106−Aのようなローカルクライアントにより開始される。これは、直感的には、パブリックアドレスをプライベートアドレスに置き換えねばならず、従って、トラフィックは、最初、NATを経て一方向に、即ちローカル(プライベート)側からリモート(パブリック)側へしか流れ得ないからである。クライアント106−Aの最初のIKE「メインモード」トランザクション、及びそれに続くIKE「クイックモード」トランザクション(或いは、メイン及びクイックに代わって、クライアントは「アグレッシブモード」トランザクションを選択してもよい)は、同じクライアント選択64ビットイニシエータクッキーをISAKMPヘッダに使用する。その後の再キーイングがローカルクライアント106−Aの判断で行われ、これは、更に別のクイックモード交換又は新たなメインモード交換のいずれかで構成できる(これは、クライアントが新たなイニシエータクッキーを選択して、IPSAMP300に新たな行を生成させることを要求し、この行は、ローカルクライアントのIP又はMACアドレス、リモートIPアドレス、及びクライアントのイニシエータクッキーにより最初に定義される)。
ステップ221では、このような行先IPアドレスがIPSAMT300に現われず、次いで、ステップ222において、IPSAMT300に行が生成され、更に、ステップ260において、クライアントコンピュータ106−AのMACアドレス及びリモートコンピュータシステム101の行先IPアドレスが関連状態で記憶され、このような行に対するペンディングビットがセットされ、例えば、マッピングテーブルにおいて1にセットされると、リモートIPアドレスに関連したリモート対ローカルのセキュリティパラメータインデックス(ローカルクライアントのIKEパケットに見つかった最初のIP行先アドレス)がまだ観察されないことを指示する。IKEパケットはNATに適合するので、NAT処理は、次いで、ステップ257で実行される。
ステップ221において、受信パケットの行先IPアドレスがIPSAMT300に既に存在する場合には、ローカルクライアントMACアドレス又はプライベートIPアドレスとリモートIPアドレスとの間のセキュリティネゴシエーションが既に進行中であるという指示に対してISAKMP「イニシエータクッキー」のチェックが行われる。従来、ISAKMPイニシエータクッキーは、64ビットの2進数であるが、ISAKMP規格の将来の改定で、このフィールドのサイズをクライアントマシンによりランダムに選択して変更し、このようなクライアントとそのISAKMPピアとの間の全ての後続ISAKMP会話を独特に識別できるようになる。このクッキーは、ウェブサーバーがウェブブラウザによりクライアントコンピュータに記憶する従来の小さなテキストファイルであるウェブクッキーではない。このフィールドの使用は、多数のISAKMPネゴシエーションを相関するのを許す。ステップ221において、このようなイニシエータクッキーがこのようなマッピングテーブルに現われない場合には、ステップ222において、IPSAMT300に行が生成される。
ステップ221において、マッピングテーブルのISAKMPイニシエータクッキーが受信ISAKMPクッキーに一致する場合には、ステップ223において、ペンディングビットが、このようなマッピングテーブルの関連する行、即ちクライアントのMACアドレス、リモートIPアドレス、及び処理されているこの受信IKEパケットに一致するイニシエータクッキーにより関連付けられた行に対してセットされたかどうか決定するチェックがなされる。注目すべきことに、ペンディングビットは任意である。というのは、それに代わってセキュリティパラメータインデックスのチェックを行なってもよいからである。ローカルクライアント106−AとリモートIPアドレスとの間の新たなIKE会話の場合には、セキュリティパラメータインデックスフィールド302は、この行に対してオープン即ち空のエントリーとなる。というのは、このIKE交換から生じるIPSec保護トラフィックがゲートウェイ106によってまだ観察されていないからである。注目すべきことに、その後の又は新たなIKE会話において、再キーイングは、新たなIKE会話で、古いセキュリティパラメータインデックスが期限切れとなったときに引き継がれる新たなセキュリティパラメータインデックスをネゴシエーションするのを許すことができる。ペンディングビットフィールド303のペンディングビットがセットされ、且つリモート対ローカルSPIフィールド302にセキュリティパラメータインデックス値が存在する場合には、そのセキュリティパラメータインデックス値が間もなく期限切れになることがあり、それ故、ゲートウェイ106は、IPSec保護トラフィックにおけるこのようなセキュリティパラメータインデックスが新たな値に変化することを予想してもよい。このペンディングビットは、このような新たなセキュリティパラメータインデックスがリモート対ローカルIPSec保護パケットにおいて検出されたときにクリアされる。
ステップ223において、ペンディングビットフィールド303のペンディングビットがセットされ、例えば、1にセットされると、リモート対ローカルセキュリティパラメータインデックスが、行先IPアドレスが得られてIPSAMT300に記録されたマシンからのものであることを指示する。このようなビットがセットされて、リモート対ローカルセキュリティパラメータインデックスがその行先IPアドレスに関連したマシンに対して得られたものであることを指示する場合には、ステップ222において、このようなマッピングテーブルに行が生成される。これは、以前のIKEに対するリモート対ローカルセキュリティパラメータインデックス(異なるローカルクライアントからの)が得られているので、別のIKEが同じリモートIPアドレスに対して抑制されないことを意味する。しかしながら、ステップ223において、ペンディングビットフィールド303におけるリモート対ローカルセキュリティパラメータインデックスペンディングビットがその初期設定値から反転されておらず即ち依然ゼロ(0)である場合には、これは、他のローカルクライアントがIKEを使用して同じリモートIPアドレスとネゴシエーションできないことを指示する。というのは、指示されたリモートIPアドレスからのリモート対ローカルセキュリティパラメータインデックスが使用中に観察されていないからである。従って、ステップ224では、このようなIKEパケット又はより詳細にはIKE初期パケットが任意に待ち行列に入れられ、そしてステップ223でチェックを繰り返すことにより以前のIPSecセッションに対してリモート対ローカルセキュリティパラメータインデックスペンディングビット303がセットされたときにステップ222においてそれが解除されてマッピングテーブルに行が生成される。ISAKMPパケットを待ち行列に入れる以外のオプションは、ローカルクライアントに、サブコード==3(ポート不到達)でICMP行先不到達(形式==3)を送信するか、又はサブコード==9(行先ホストとの通信が管理上禁止される)でICMP行先不到達(形式==3)を送信することである。
図4は、本発明の1つ以上の態様に基づくIPSec/NAT一体化プロセス200の受信器側の実施形態を示すフローチャートである。図4を参照し続けると共に、図1及び2を更に参照して、一体化プロセス200の受信器側について説明する。ステップ407において、IPパケットは、コンピュータシステム101からNATゲートウェイ106により受信される。ステップ408では、このように受信したパケットにセキュリティパラメータインデックスが存在するかどうか決定するための比較が行なわれる。換言すれば、AHのみ、ESPのみ、及びAHを伴うESPの1つを使用するIPSec保護パケットである。
IKEネゴシエーションがローカルクライアントによりあるリモートIPアドレスに対して開始された場合には、ペンディングビットフィールド303のペンディングビットがセットされる。というのは、リモートコンピュータシステム101から、このようなIKEネゴシエーションを開始したローカルクライアント106−Aへのトラフィックに関連したリモート対ローカルセキュリティパラメータが観察及び記録されていないからである。ローカルクライアント106−AのIKEパケットのIPソースアドレスがプライベートアドレスである場合には、そのクライアントのプライベートIPアドレスが、ローカルクライアントIPアドレスフィールド306に記憶される。このフィールドが占有されたときには、ゲートウェイ106は、IPSecトラフィックに対して、クライアント106−Aと、このリモートIPアドレスに関連したリモートマシンとの間にESPのみのトラフィックが割り当てられねばならないことを知る。しかしながら、ローカルクライアント106−AがパブリックIPアドレスをIKEパケットにおけるIPソースアドレスとして使用する場合には、ゲートウェイ106は、このクライアントのMACアドレスをローカルクライアントMACアドレスフィールド301に記憶することによりこれを忘れないようにしなければならない。このIKEローカルクライアントMACアドレスのフィールドが占有されたときには、クライアント106−Aは、IPSecのAHのみ、ESPのみ、又はAHを伴うESPの形態を使用できる。注目すべきことに、このような場合に、クライアント106−Aは、ゲートウェイ106により指定されたパブリックIPアドレスを使用することになり、ステップ254で記憶されているので、このMACアドレスをもつマシンにパブリックIPアドレスが指定されたことを想起できる。ステップ254で記録されたMACアドレスだけが、それに関連したパブリックIPアドレスの使用を許されねばならない。
IKE抑制が使用され、且つIPSec保護データが、IKEネゴシエーション後に、関連リモートIPアドレスをもつマシンからマッピングテーブル内のローカルクライアントへ流れない場合には、ペンディングビットフィールド303のペンディングビットが例えば1にセットされたままとなり、他のクライアントが同じ行先IPアドレスとIKEネゴシエーションを開始するのを防止する。従って、タイムスタンプ305を使用し、リモート対ローカルセキュリティパラメータインデックスフィールド302におけるリモート対ローカルセキュリティパラメータインデックスが、決定された時間内に得られず、従って、このようなペンディングビットを例えばゼロ(0)にクリアする場合には、期限切れとなった行をIPSAMT300から除去して、同じリモートIPアドレスへの別のIKEを実行するのを許すことができる。この行は、別のステーションが実際に同じリモートIPアドレスとのIKEネゴシエーションを開始するよう試み、この時点で衝突が通知されるまで、除去される必要はない。従って、ペンディングビットフィールド303のペンディングビットは1にセットされることが確認され、そしてタイムスタンプフィールド305の関連タイムスタンプは、この行又はこれらの行エントリーがパージするに充分なほど古いことを確認するようチェックされる。
ペンディングビット303がクリアされ、即ちゼロ(0)にセットされた場合には、同じ2つのアドレス、即ちローカルMAC又はローカルクライアントプライベートIPアドレスとリモートIPアドレスとの間に別のIKEセッションが開始されるまで、その関連行がIPSAMT300に保たれる。リモート対ローカルセキュリティパラメータインデックスが得られたIKEセッションを既に有するマシン間に別のIKEセッションが開始された場合には、これら2つのマシン間の以前のIKEセッションに対する関連行は、たとえリモート対ローカルセキュリティパラメータインデックスが既知であっても、ペンディングビットフィールド303のビットをセットしている。この場合に、このようなペンディングビットを例えば1にセットすると、関連行が削除ペンディング中であることを指示する。
リモート対ローカルセキュリティパラメータインデックスが得られた既存のIKEに新たなIKEが取って代わる状況においては、リモートIPアドレスからローカルクライアントへのトラフィックに対して新たなリモート対ローカルセキュリティパラメータインデックスを使用し始めることが予想され、この時点で、リモート対ローカルセキュリティパラメータインデックスの値だけが異なる新たな行を古い行からクローン生成することができる。このような新たな行が生成されると、古い行のペンディングビットフィールド303のペンディングビットを再びクリアし、即ちゼロ(0)にセットすることができる。より一般的には、パケットがテーブルエントリーに一致するように見えるたびに、タイムスタンプフィールド305が更新されるが、古い行は、古いリモート対ローカルセキュリティパラメータインデックスを使用してトラフィックを到達させ、時間経過と共に行を益々古くさせてしまうのを直ちに止めねばならない。この行は、充分古くなると、通常の「廃物収集」動作により排除される。例えば、交換したキーが期限切れになりつつあるか又は期限切れしたために、新たなIKEを開始することができる。
新たなIKEネゴシエーションは、新たなIKE通信を開始するローカルクライアントの判断でいつでも行ない得る。IKEネゴシエーションは、確立されたIKEセッションであっても、リモートマシンやリモートIPアドレスでは開始されない。NATの場合に常にローカルクライアントでなければならないセッションオリジネータは、全ての更に別のIKE会話、例えば、再キーイングネゴシエーションを開始する。図5A及び5Bを参照し続けると共に、図4を再度参照すれば、ステップ408において、IPSecで保護されないパケットのような受信パケットにセキュリティパラメータインデックスがない場合には、このようなパケットが、ステップ409において、IPSAMT300を調べずにルーティングされる。このようなルーティングの判断は、ゲートウェイ106の非IPSec NATファンクションを推進するゲートウェイNATテーブルにより推進されてもよい。NATは良く知られているので、NATの詳細な説明は、明瞭化のため省略する。
ステップ408において、ステップ407で受信されたパケットにセキュリティパラメータインデックスが見つかった場合には、ステップ410において、IPSAMT300のチェックを行なって、リモートIPアドレスフィールド304のアドレスに一致するパケットのIPソースアドレスに対してリモート対ローカルセキュリティパラメータインデックスが存在するかどうか決定する。ステップ410において、ISAMT300からのリモート対ローカルセキュリティパラメータインデックスフィールド302に値が存在する場合には、ステップ411において、そのような一致するパケットが、そのような受信パケットで見つかったIPSAMT300からのリモート対ローカルセキュリティパラメータインデックスフィールド302におけるそのような値に関連したローカルクライアントMACアドレスフィールド301又はローカルクライアントプライベートIPアドレスフィールド306の関連アドレスへルーティングされる。
ゲートウェイ106が、マッピングテーブルのMACアドレスを使用してクライアントコンピュータを識別するときには、このローカルクライアントが、ゲートウェイ供給されたパブリックIPアドレスを、そのローカル対リモートパケットにおけるIPソースアドレスとして使用している。このような場合、ゲートウェイ106は、ローカルクライアントパブリックIPアドレスフィールド309からのこのようなローカルクライアントアドレスを、想起し又は忘れないために記憶し、従って、ゲートウェイ106は、(そのローカルビットを反転することにより)このようなパブリックIPアドレスを得るためにDHCPを最初に使用したこのドメインにおけるMACアドレスしかこのパブリックIPアドレスを使用できないように確保することができる。このようなローカル対リモートパケットのIPソースアドレスは、既にパブリックIPアドレスであるから、ゲートウェイは、パケットのNAT変換を実行する必要がない。それ故、AH保護されたパケットは、IPアドレス変換に遭遇せずにローカルドメインを脱出することがあり、従って、リモート側では、AHヘッダに埋め込まれたデジタル符牒を確認することができる。ローカルクライアントアドレスは、プライベートIPアドレスであるか又は(パブリックIPアドレス、MACアドレス)対であるかに関わらず、ローカルクライアントからリモートIPアドレスへの初期トラフィックから記録され、従って、ゲートウェイ106は、どのローカルクライアントへ戻りトラフィックを転送すべきか決定することができる。ローカルクライアントのMACアドレスは、リモートIPアドレスを行先とした第1のローカル対リモートパケットのMACソースアドレスフィールドから抽出される。
ゲートウェイ管理されるパブリックIPアドレスよりアクティブなクライアントが存在する状況では、リモートIPアドレス対ローカルクライアントの多数対1のマッピングが存在し、この場合、リモート対ローカルセキュリティパラメータインデックスを使用して、テーブルのどの行が適切なローカルクライアントに対応するか識別する。ゲートウェイ106は、ローカルステーションへ最終的に配送するために行先アドレスのどの形態を使用すべきかを、想起のために記憶する。MACアドレス及びパブリックIPアドレスが記録されたローカルクライアントマシンについては、戻りトラフィックにおけるIP行先アドレスも、ゲートウェイ106がこのようなローカルクライアントマシンに各々指定した同じパブリックIPアドレスである。従って、ゲートウェイ106は、クライアントのパブリックIPアドレスを宛先とするパケットを、変更せずに(MACフレームのMACソースアドレスがローカルサブネットワークにおけるゲートウェイのLANインターフェイスのアドレスとなり、且つフレームのMAC行先アドレスが、ゲートウェイ106がテーブルの一致する行に記録したローカルクライアントMACアドレスとなることを除いて)安全に送信できることを知る。
プライベートIPアドレスが記録されているローカルクライアントへのトラフィック(ESPのみのトラフィックだけがこのカテゴリーに入る)については、ゲートウェイ106は、リモートIPアドレスフィールド304のアドレスと、リモート対ローカルセキュリティパラメータインデックスフィールド302の値とを使用して、マッピングテーブルにおける適切な行を識別し、そこから、ローカルクライアントプライベートIPアドレスフィールド306のアドレスを抽出し、これにより、パケットのIP行先アドレスをこのようなローカルクライアントのプライベートIPアドレスに変換する。
ステップ410において、リモートIPアドレスフィールド304のアドレスが受信パケットのIPソースアドレスに一致するマッピングテーブルの行に関連したリモート対ローカルセキュリティパラメータインデックスフィールド302に値が存在せず、且つこのようなマッピングテーブルのこの行のペンディングビットフィールド303のビットが例えば1にセットされる場合には、ステップ412において、このようなIPソースアドレスを有すると共にこのようなペンディング値を有する受信パケットからリモート対ローカルセキュリティパラメータインデックスフィールド302に追加される値を加算することによりIPSAMT300が更新される。これに応答して、ペンディングビットフィールド303のビットがこの行に対してクリアされ(即ち、ゼロ(0)にセットされ)、ペンディング中のリモート対ローカルセキュリティパラメータインデックス値の受信を指示する。パケットがテーブルの行に一致するたびに、タイムスタンプフィールド305がその行に対して更新される。
図5Bでは、リモート対ローカルセキュリティパラメータインデックスフィールド302の値と、ペンディングビットフィールド303の値が、一例として、リモート対ローカルセキュリティパラメータインデックス列即ちフィールド302と、ペンディングビット列即ちフィールド303とに各々書き込まれ、IPSec IPSAMT300を更新する。更に、IKE抑制がアクティブである場合には、ペンディングビットフィールド303のビットを、例えば、ゼロ(0)に反転することによりクリアすると、別のローカルクライアントが、以前にセキュリティパラメータインデックス値の受信ペンディング状態にあった同じリモートIPアドレスへのIKEセッションを開始するのを許す。ステップ412における更新の後に、ステップ411において、このような受信IPパケットは、NATゲートウェイ106により、アドレスに基づいて、IPSAMT300におけるローカルクライアントMACアドレスフィールド301又はローカルクライアントプライベートIPアドレスフィールド306から、それに関連したクライアントコンピュータ106−Aへルーティングされる。
注目すべきことに、受信パケットに対して一致するリモート対ローカルセキュリティパラメータインデックス302をもつ行がない場合には、NATゲートウェイ106は、このようなリモートIPアドレスと通信するのが1つのローカルクライアントMACアドレスだけであるとすれば、このような受信パケットを依然として正しくルーティングすることができる。或いはまた、同じリモートIPアドレスに対して2つ以上のオープンのリモート対ローカルセキュリティパラメータインデックスが許された場合には、このようなパケットは、このようなリモートIPアドレスと通信する各ローカルクライアントMACアドレスへ送信されてもよいし、或いはLAN102上の全てのクライアントコンピュータに対するブロードキャストMACアドレスへ送信されてもよく、次いで、NATゲートウェイ106は、適切なローカルクライアントをそのリモートIPアドレスに対する適切なリモート対ローカルセキュリティパラメータインデックスとリンクできるように両方向応答を待機することができる。
2つの異なるローカルクライアントは、同じリモートIPアドレスとのIKEネゴシエーションに参加するときには同じリモート対ローカルセキュリティパラメータインデックス値を選択し得ることが考えられる。これは、全てのクライアントが同じパブリックIPアドレスを共有している場合にはたとえIKE抑制が使用されても考えられることである。
しかしながら、2つのクライアントが、同じリモート対ローカルセキュリティパラメータインデックス値を選択すると共に、それらに異なるローカルクライアントパブリックIPアドレスが指定されている場合には、受信パケットとの4個の関連性、即ちリモートIPアドレス、リモート対ローカルセキュリティパラメータインデックス、IPSecプロトコル、及びローカルクライアントパブリックIPアドレスに基づいて、パケットを転送することができる。
ローカルクライアントが同じパブリックIPアドレスを有する場合には、最初にIPSAMT300に入るどちらかのMACアドレスが、そのリモート対ローカルセキュリティパラメータインデックス302に対する全ての関連トラフィックを受信する。というのは、ゲートウェイ106が、あるステーションに対するトラフィックを、同じ4個の関連性をもつ別のステーションのトラフィックとは別に輪郭定めする方法がないからである。しかしながら、第2のローカルクライアントとこのリモートIPアドレスとの間の通信は成功とならず、従って、それらの通信当事者は新たなIKEネゴシエーションを試みることになり、これは、あらゆる可能性において、独特のリモート対ローカルセキュリティパラメータインデックス値の選択を生じることになろう。というのは、リモート対ローカルセキュリティパラメータインデックスは、0から255までが指定済みで、256から4,294,967,295までの範囲からランダムに選択された番号だからである。重畳するリモート対ローカルセキュリティパラメータインデックスの選択を防止する1つの方法は、最終ステーションがそれらの現在のIPアドレス及びセキュリティパラメータインデックスをLANにブロードキャストするようにさせ、従って、ドメインの他のステーションが重複をチェックできるようにすることである。しかしながら、このような構成は、クライアントソフトウェアの著しい変更を必要とし、従って、通信セッションを失敗させ、低い確率の事象を生じ、且つ最終ステーションで無効となったIKEセッションの回復を別のIKEセッションの開始により行なうことに比して、かなり複雑になる。
注目すべきことに、成功したIKEネゴシエーションの後に、IPSecパケットは、プロトコル情報の上位層を暗号化し、従って、この情報は、NATゲートウェイには得られない。しかしながら、セキュリティパラメータインデックスは、IPSecセッションに対して暗号化されていないので、ゲートウェイに得られる。更に、セキュリティパラメータインデックスは、各ヘッダ形式、即ちESPヘッダ及びAHにおいて得ることができ、AHは、AHを伴うESPを含むがこれに限定されない。従って、IKEがクライアントコンピュータ及び行先コンピュータにより完了となり、且つ暗号化データがキーを用いて交換されると、NATゲートウェイは、いずれか又は両方の形式のIPSec、即ちESP及びAHとの通信に使用できるリモート対ローカルセキュリティパラメータインデックス値を伴う更新されたIPSAMT300を備える。注目すべきことに、IPSAMT構造体は、ここでは、単一のエンティティとして説明するが、このようなIPSAMTを多数のテーブルに分割して、1つ以上の列を複写してもよいことが明らかであろう。これは、1つ以上のテーブルをハードウェア、ファームウェア、ソフトウェア又はその組合せで形成できるという効果がある。従って、マッピングテーブルとは、単一のマッピングテーブル、及び関連性を有する複数のマッピングテーブルを包含するものとする。更に、ここで述べる収集されて関連付けされた情報は、テーブル以外の形態で記憶されてもよく、これは、データベース等のデータ構造体を含むが、これらに限定されない。
また、AH又はESPパケットにおける新たなセキュリティパラメータインデックスは、このようなパケットにおけるシーケンス番号フィールドの使用により識別されてもよい。新たなセキュリティアソシエーション(SA)における第1パケットは、常に、シーケンス番号「0x00−00−00−01」を有する。ヘッダのフォーマットは異なるが、AH及びESPの各々は、その両方の場合にシーケンス番号が「0x00−00−00−01」でスタートし、送信された各パケットに対して1だけ増加され、且つ0xFF−FF−FF−FFを越えることがないという点で、シーケンス番号フィールドを同様に使用する。第1のリモート対ローカルセキュリティパラメータインデックスは、シーケンス番号「0x00−00−00−01」で到着しなければならず、2つのステーションが再キーイングに参加するときには、新たなリモート対ローカルセキュリティパラメータインデックスが、「0x00−00−00−01」にセットされたシーケンス番号フィールドで到着しなければならない。新たなセキュリティパラメータインデックス値を含むがそのシーケンス番号が「0x00−00−00−01」より大きいパケットは、無効パケットであり、ゲートウェイは、これを破棄するように選択することができる。しかしながら、クライアントは、このようなエラー状態を同等に検出できるので、このようなパケットを転送してもおそらくほとんど害はない。
ゲートウェイが実施のために選択できる別のエラー状態は、リモート対ローカルセキュリティパラメータインデックスが0xFF−FF−FF−FFから0x00−00−00−00へとラップするパケットを阻止することである。ゲートウェイがこの制限を実施するために、ゲートウェイは、マッピングテーブルから一致する行を削除して、将来トラフィックを転送できないようにすることで、マッピングテーブルにおける各行のシーケンス番号を追跡するか、又は0xFF−FF−FF−FFのシーケンス番号値をトリガーしなければならない。この場合にも、ローカルクライアントもこの制限を実施できねばならず、従って、ゲートウェイがクライアントをこの状態からシールドする必要はないが、このようなシールドは、もし可能にされた場合でも、ここに述べるアルゴリズムの妨げとはならない。
更に、SA再ネゴシエーションをゲートウェイにより予め決定するか又は予想してもよい。というのは、上述したように、シーケンス番号フィールドは、0xFF−FF−FF−FFから0x00−00−00−00へとラップすることが許されないからである。シーケンス番号値が0xFF−FF−FF−FFの33%以下になると、ゲートウェイは、新たなIKE交換を見て新たなSAを設定するように合理的に予想できる。もちろん、2つの当事者は、シーケンス番号空間がラップし得るより即座に新たなSAをネゴシエーションすることを選択でき、即ちSAのネゴシエーションされたライフタイムは、おそらく、ピアが4,294,967,295個のパケットを送信するに要する時間よりかなり短いものとなる。しかしながら、SAが非常に長いライフタイムでネゴシエーションされ、その間にパケット送信レートが非常に高かった場合には、シーケンス番号は、新たなIKE交換が切迫しているというキューを与える。ローカルクライアントとリモートマシンとの間には多数のSAが存在することがある。AHのみ、ESPのみ、又はAHを伴うESPがあり、その各々が独特のセキュリティパラメータインデックスを有する。従って、マッピングテーブル300は、リモート対ローカルセキュリティパラメータインデックス値がAHに関連するか、ESPに関連するか又はその両方に関連するかを指示する「IPSecプロトコル」値列308を備えている。更に、マッピングテーブル300は、AH及びESPの両セキュリティパラメータインデックスを独立して、例えば、テーブル300の別々の行に記録してもよい。というのは、リモート対ローカルセキュリティパラメータインデックス値がAH及びESPに対して同じになる機会があり、従って、どちらがどちらであるか知らせるために、AH又はESPプロトコル形式を記録することが必要になる。注目すべきことに、2つのローカルクライアントが同じリモートIPアドレスと話をし、更に、その両方が同じIPSecプロトコルに対して同じリモート対ローカルセキュリティパラメータインデックスを選択した場合には、ゲートウェイ106は、両セキュリティアソシエーションに対する全てのトラフィックを、そのリモート対ローカルセキュリティパラメータインデックスを最初にネゴシエーションしたクライアントへ転送する。
SAは、IKR初期交換の後又は再キーイング交換の後に長時間アイドル状態であることが考えられ、たとえ各側で新たなセキュリティパラメータインデックスについて合意しても、それらがIPSec保護データを通信しないことがあり、従って、マッピングテーブル300内のリモート対ローカルセキュリティパラメータインデックスフィールド302を集団構成するのを許すようにIPSec保護データがゲートウェイ106に到達しないことになる。この静寂な時間中に、第三者が、ランダムに選択された(無効)セキュリティパラメータインデックスにおいて模造で偽物のパケットをシーケンス番号0x00−00−00−01で送信し得ることが考えられる。ゲートウェイ106は、到来するパケットにおける意図されたIPソースアドレスに一致する行についてのIKEが内部マシンと外部マシンとの間で実行されないことが分かった場合に(即ち、ペンディングビットフィールド303が1にセットされているが、リモート対ローカルセキュリティパラメータインデックスフィールド306にセキュリティパラメータインデックス値をもたない行がマッピングテーブル300に存在しない場合に)、このようなパケットを直ちに拒絶することができる。しかしながら、IKE交換が行なわれたが、IPSecトラフィックがゲートウェイ106を経てまだ流れていない場合には、セキュリティパラメータインデックスが有効であるかどうか確実に分かるのは、IKE接続のエンドポイントだけである。それ故、ゲートウェイ106は、新たなリモート対ローカルセキュリティパラメータインデックスをフィールド302に記録する前に、IKEピア間の完全な両方向IPSec保護トラフィック交換を監視しなければならない。
模造パケットが上述したように送信された場合には、ローカルクライアント106−Aは、このような模造パケットを破棄するか、エラーメッセージを送信するか、或いは新たなIKE交換をスタートして、既存のSAを確認し、又は新たなネゴシエーションを行なう。クライアント106−AはIPSec保護パケットで応答するが、リモートIPアドレスがその応答に異なるセキュリティパラメータインデックスを使用する場合には、ゲートウェイ106は、それが見た第1セキュリティパラメータインデックスが模造のリモート対ローカルセキュリティパラメータインデックスであったことを知る。
ゲートウェイ106は、外部マシンと内部マシンとの間に両方向のIPSec保護交換を見るまでペンディングビット303をクリアすることができない。ゲートウェイ106は、それが正しいリモート対ローカルセキュリティパラメータインデックス値を有することの付加的な証拠として初期シーケンス番号を使用することができる。偽物のパケットが受け取られ、このような偽物のパケットのセキュリティパラメータインデックスがマッピングテーブル300にない場合には、ゲートウェイ106は、既知のセキュリティパラメータインデックスをもたないリモートIPアドレスからのものとされるIPSec保護パケットを破棄することができる。但し、これは、IKE交換が行なわれず、マッピングテーブル300の既存のセキュリティパラメータインデックスを正当に無効であるとしてもよいことをゲートウェイ106が知っている場合である。ゲートウェイ106は、このようなパケットを、シーケンス番号フィールドの値に関わらず破棄することができる。簡単に述べると、不一致のセキュリティパラメータインデックスがリモートIPアドレスから到達し、そのIPアドレスに一致する行で、ペンディングビット303がセットされた行がない場合には、パケットが削除されてもよい。
本発明のある実施形態は、ゲートウェイ及び/又はクライアントコンピュータに完全に又は部分的に常駐できるプログラム製品である。メモリは、揮発性及び/又は不揮発性メモリであって、磁気的に読み取り可能なメモリ(例えば、フロッピーディスク、ハードディスク等)、光学的に読み取り可能なメモリ(例えば、CD−ROM、−RW、DVD−ROM、−RAM等)、並びに電気的に読み取り可能なメモリ(例えば、DRAM、SRAM、EEPROM、レジスタ、ラッチ等)を含むが、これらに限定されない。従って、本発明のある実施形態は、マシン読み取り可能なプログラムを含むプログラム製品である。プログラム製品のプログラム(1つ又は複数)は、これら実施形態のファンクションを定義するもので、種々の信号/保持媒体に含ませることができ、これらは、(i)書き込み不能の記憶媒体(例えば、CD−ROMドライブにより読み取り可能なCD−ROMディスクのようなコンピュータ内のリードオンリメモリ装置)に永久的に記憶された情報、(ii)書き込み可能な記憶媒体(例えば、ディスケットドライブ又はハードディスクドライブ内のフロッピーディスク)に記憶される変更可能な情報、或いは(iii)ワイヤレス通信を含むコンピュータ又は電話ネットワークのような通信媒体によりコンピュータへ搬送される情報を含むが、これらに限定されない。後者の実施形態は、特に、インターネット及び他のネットワークからダウンロードされる情報を含む。このような信号保持媒体は、本発明のファンクションを指令するコンピュータ読み取り可能な命令を搬送するときには、本発明の実施形態を表わす。
以上、本発明の好ましい実施形態を説明したが、本発明の基本的範囲から逸脱せずに本発明の他の及び更に別の実施形態を案出することもでき、それ故、本発明の範囲は、特許請求の範囲により規定される。ステップを記載した請求項は、ステップの順序が明確に指示されない限りその順序を意味するものではない。全ての商標は、各々所有者の財産である。
本発明の1つ以上の態様に基づくコンピュータシステムの実施形態を示すブロック図である。
本発明の1つ以上の態様に基づくネットワークの実施形態を示すネットワーク図である。
本発明の1つ以上の態様に基づくIPSec/NAT一体化プロセスの各部分の実施形態を示すフローチャートである。
本発明の1つ以上の態様に基づくIPSec/NAT一体化プロセスの各部分の実施形態を示すフローチャートである。
本発明の1つ以上の態様に基づくIPSec/NAT一体化プロセスの各部分の実施形態を示すフローチャートである。
本発明の1つ以上の態様に基づくIPSec関連付けマッピングテーブル(IPSAMT)の実施形態を示すテーブル図である。
本発明の1つ以上の態様に基づくIPSec関連付けマッピングテーブル(IPSAMT)の実施形態を示すテーブル図である。
符号の説明
10・・・コンピュータシステム、11・・・CPU、13・・・システムメモリ、12・・・入力/出力(I/O)インターフェイス、100・・・NIC、101・・・コンピュータシステム、102、103・・・LAN、104・・・ワイドエリアネットワーク(WAN)、106、107・・・DHCPサーバー/NATゲートウェイ(ゲートウェイ)、106−A、106−B、106−C・・・クライアントコンピュータ、107−A、107−B、107−C・・・クライアントコンピュータ、108・・・ルーター、110・・・ネットワーク、112・・・ローカルメモリ、200・・・IPSec/NAT一体化プロセス、298・・・IPSec/NATゲートウェイ側一体化サブプロセス、299・・・IPSec/NATクライアント側一体化サブプロセス、300・・・IPSec割り当てマッピングテーブル(IPSAMT)