JP2009532919A

JP2009532919A - ネットワーク・アドレス・ポート変換器によって扱われるクライアントからの重複ソースの防止

Info

Publication number: JP2009532919A
Application number: JP2008505871A
Authority: JP
Inventors: ジャクビック、パトリシア; オーバービー、リンウッド、ヒュー、ジュニア; ポーター、ジョイス、アン; ウィアボウスキー、デイビッド、ジョン
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2005-04-11
Filing date: 2006-04-07
Publication date: 2009-09-10
Anticipated expiration: 2026-04-07
Also published as: BRPI0607515A2; CA2602778C; US20060227807A1; CA2602778A1; TWI365651B; EP1872561B1; BRPI0607515B1; CN101156420A; WO2006108805A1; JP4766574B2; CN101156420B; US7656795B2; TW200708009A; EP1872561A1

Abstract

【課題】ＮＡＰＴによって扱われるソース・アプリケーション識別するためのネットワーク・アドレス、プロトコル、およびポート番号を使用するプロトコル接続上の重複ソースを防止する。
【解決手段】到着パケットが暗号化されたパケットをカプセル化して、宛先ホストへ向かう途中でＮＡＰＴを通った場合に、カプセル化されたパケットを復号化して、復号化されたパケットから元ソース・ポート番号と元パケット・プロトコルとを取得する。ソース・ポート・マッピング・テーブル（ＳＰＭＴ）を検索して、ＮＡＰＴソース・アドレスと、元ソース・ポートと、ＮＡＰＴソース・アドレスおよびポート番号に関連した元パケット・プロトコルとの間のアソシエーションを求める。不正確なアソシエーションが見つかると、パケットは、不正な重複ソース、すなわち、同一のソース・ポートおよびプロトコルを使用しているＮＡＰＴによって扱われる異なるホストからの第２のパケットを表すものとして拒絶される。
【選択図】図１

Description

本発明は、一般的には、インターネット・ネットワーキングに関し、特定的には、ネットワーク・アドレスおよびポート変換によって生じる衝突に対する対応に関する。

本明細書において、インターネットとインターネット通信の基礎を形成するＴＣＰ／ＩＰプロトコルとの観点から、問題と解決策とを説明する。しかしながら、本技術は、プロトコルの詳細によっては、他の通信プロトコルにも同様に提供可能である。

インターネット・ネットワーク・アドレス変換を使用する理由はいくつかある。主な理由は、公開アドレスの使用を節約することである。ネットワーク・アドレス変換器（ＮＡＴ）のインターネット・プロトコル（ＩＰ）アドレスは、一般的には公開アドレスである。すなわち、ＮＡＴＩＰアドレスは、外部世界に知られているが、ＮＡＴの背後にあるサーバまたはクライアントのすべては、プライベート・アドレスであり、外部世界には知られていない。そのような場合、外部世界は、ＮＡＴと通信を行い、ＮＡＴは、その背後にある適切なサーバおよびクライアントとの通信を制御する。これは、ＮＡＴの背後にある装置のＩＰアドレスは当該ファミリー内で固有であればよいが、世界のその他におけるＩＰアドレスは重複している可能性がある。ＮＡＴは、ＩＰアドレスの変換のみに関与する。さらに、ネットワーク・アドレス・ポート変換（ＮＡＰＴ）として知られる種類の変換があり、ここでは、ＩＰアドレスおよびポート番号の両方が変換される。ネットワーク・アドレス変換（ＮＡＴ）およびネットワーク・アドレス・ポート変換（ＮＡＰＴ）のための規格は、インターネット技術標準化委員会（ＩＥＴＦ）の、「ＴｒａｄｉｔｉｏｎａｌＩＰＮｅｔｗｏｒｋＡｄｄｒｅｓｓＴｒａｎｓｌａｔｉｏｎ」という名称のＲＦＣ３０２２に記載されている。

元来のインターネットは、セキュリティを主要な要素として設計されていない。実際、インターネットは、科学的および教育的通信に対する支援として、意図的に比較的オープンに作られた。しかしながら、ウェブの出現とその商用によって、安全なインターネット通信に対する必要性が増している。一般的にはＩＰｓｅｃとして知られるインターネット・セキュリティ・プロトコルは、これらの問題に対処するために定義されていた。例えば、ＩＰｓｅｃは、ネットワーク装置の認証または送信データの暗号化もしくはその両方を提供する。ソース・アドレスと宛先アドレスとの間のＩＰｓｅｃ通信は、セキュリティ・アソシエーション（ＳＡ）に従って管理される。ＳＡは、通信に適用されるＩＰｓｅｃ処理を定義する１つ以上の規則である。ＩＰｓｅｃは、ＲＦＣ２４０１および他のＲＦＣに定義されている。パケットが拒否されるか、ＩＰｓｅｃ処理なしで許可されるか、またはＩＰｓｅｃ処理ありで許可されるかどうかは、セキュリティ・ポリシー・データベース（ＳＰＤ）内のセキュリティ規則を有するパケットの属性を照合することによって判断される。この判断を行うために、既知の技術は、送信および受信パケットの両方に関する最も特定性の高い属性から最も特定性の低い属性の順で、静的および動的規則を検索する。静的規則のセットが、実質的にはセキュリティ規則である。静的規則は、予め定義付けられており、一般的にはあまり頻繁に変化しない。動的規則は、ＩＫＥ（インターネット鍵交換）処理中に必要に応じてノード間で交渉され、必要に応じて動的にセキュリティ・ポリシー・データベースに追加される規則である。ＩＢＭ社の米国特許第６３４７３７６号は、ＳＰＤの動的規則を検索する好ましい一方法を記載する。

ネットワーク・アドレスまたはポート変換とＩＰｓｅｃ処理との間には、固有の不適合性が存在する。このような不適合性が、ＩＰｓｅｃの配置には障壁となる。ＲＦＣ３７１５は、このような不適合性のいくつかを認識し説明しているが、一般的な解決策は提供していない。例えば、ＲＦＣ３７１５の第４．１節は、ＲＦＣ３４５６「ＤｙｎａｍｉｃＨｏｓｔＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ（ＤＨＣＰｖ４，ＣｏｎｆｉｇｕｒａｔｉｏｎｏｆＩＰｓｅｃＴｕｎｎｅｌＭｏｄｅ）」に提案された限定的な解決策を示しているが、より一般的な解決策が必要とされていることを述べている。加えて、ＩＥＴＦのＩＰｓｅｃワーキング・グループからの「ＵＤＰＥｎｃａｐｓｕｌａｔｉｏｎｏｆＩＰｓｅｃパケット」という名称のＲＦＣ３９４８の第５節も、不適合性のいくつかの問題に対処している。特に、ＲＦＣ３９４８の第５．２節は、ＮＡＴによって扱われるクライアントへの接続上でどんなＩＰｓｅｃセキュリティ・アソシエーションを使用するかを判断する問題について簡単に説明している。また、この節は、ＮＡＰＴがＩＰｓｅｃトラフィックも扱う場合にＮＡＰＴの背後のクライアントへのクリア・テキスト接続を可能にする他の問題について述べている。

よって、クライアントがＮＡＰＴで扱われる場合には、重複ソースを回避するという問題に対処する必要性がある。この問題に対しては、どの関連のＩＥＴＦＲＦＣ文献も解決策を提供していない。本明細書の目的のために、重複ソースは、同一のソース・アドレス（例えば、ＩＰｓｅｃカプセル化された元のパケットに割り当てられたＮＡＰＴのＩＰアドレス）、同一のトランスポート・プロトコル、および同一の元ソース・ポート番号（すなわち、ＩＰｓｅｃカプセル化されたパケットのトランスポート・ヘッダにおけるポート番号）を有するパケットとして定義される。

重複ソースは、ネットワークの整合性を破る重複接続という結果をもたらす。例えば、パケットが誤った宛先に送られる可能性がある。

「ＮｅｇｏｔｉａｔｉｏｎｏｆＮＡＴ‐ＴｒａｖｅｒｓａｌｉｎｔｈｅＩＫＥ」という名称のＲＦＣ３９４７は、ＮＡＴトラバーサル・サポートためのＩＫＥ（インターネット鍵交換）のフェーズ１およびフェーズ２において必要とされるものを記述している。これには、パケット通信における両端がＮＡＴトラバーサルをサポートしているかどうかを検出することと、ホストからホストへのパスに沿って１つ以上のＮＡＴがあるかどうかを検出することを含まれる。また、ＩＫＥクイック・モードにおけるユーザ・データグラム・プロトコル（ＵＤＰ）のカプセル化されたＩＰｓｅｃパケットの使用を交渉するやり方も含まれており、元ソースＩＰアドレスを他端に必要に応じて送信するやり方を記載している。ＵＤＰは、ＲＦＣ７６８に定義されている。ＲＦＣ３９４８である「ＵＤＰＥｎｃａｐｓｕｌａｔｉｏｎｏｆＩＰｓｅｃＥＳＰＰａｃｋｅｔｓ」は、ＮＡＴをトラバースするために、ＵＤＰパケット内部のＥＳＰ（カプセル化セキュリティ・ペイロード）パケットをカプセル化およびカプセル開放するための方法を定義している。ＥＳＰは、ＲＦＣ２４０６に定義されている。ＥＳＰは、ＩＰｖ４およびＩＰｖ６における混合セキュリティ・サービスを提供するように設計されている。

本発明は、ＮＡＰＴによって扱われるソース・アプリケーションを識別するためのソース・アドレス、プロトコル、およびソース・ポート番号を使用する接続におけるパケットの複製ソースを防止することに向けられている。パケットがサーバで受信されると、当該パケットが、ネットワーク・アドレス・ポート変換器（ＮＡＰＴ）を含む送信路のＥＳＰパケットをカプセル化するＵＤＰパケットかどうかについて判断する。この判断が合致すると、元パケットはカプセル開放されて、元ソース・ポート番号と、元トランスポート・プロトコルとを取得する。ソース・ポート・マッピング・テーブル（ＳＰＭＴ）を検索して、ＮＡＰＴソースＩＰアドレスと、元ソース・ポート番号と、ＮＡＰＴソースＩＰアドレスおよび変換されたソース・ポート番号に関連した元トランスポート・プロトコルとの間のアソシエーションを求める。不正確なアソシエーションが見つかると、パケットは、不正な重複ソース、すなわち、同一のソースＩＰアドレス、ソース・ポート番号およびプロトコルを使用しているＮＡＰＴによって扱われる異なるホストからの第２のパケットを表すものとして拒絶される。

好ましい実施形態において、サーバにおけるＳＰＭＴ内のネットワーク・アドレス・ポート変換器（ＮＡＰＴ）ホスト・エントリが、インターネット・ホストからのインターネット鍵交換（ＩＫＥ）メッセージに応答して動的に構築される。各ＮＡＰＴホスト・エントリは、ＮＡＰＴのソースＩＰアドレスと、ＮＡＰＴによって割り当てられたソース・ポートとを含む。ＳＰＭＴ内のソース・ポート・エントリは、暗号化されたパケットが到着して復号化されるにつれて動的に構築され、ソース・ポート・エントリとＳＰＭＴのＮＡＰＴホスト・エントリとの間でアソシエーションが確立される。各ソース・ポート・エントリは、ＮＡＰＴのソースＩＰアドレスと、元ソース・ポート番号と、元プロトコルとを含む。

本発明の好ましい一実施形態を、以下の図面を参照して一例として説明する。

本発明の実施形態によって対処される問題は、インターネット送信におけるトランスポート・モードおよびトンネル・モードの両方について存在するが、開示された実施形態は、トランスポート・モードに向けられている。説明する軽微な変形によって、トランスポート・モードに関する開示をトンネル・モードにおける動作のために適合させる。

本発明の実施形態は、ソフトウェア、ハードウェア、またはハードウェアおよびソフトウェアの組み合わせにおいて実施することができる。さらに、本発明の実施形態は、コンピュータまたは任意の命令実行システムによってまたはそれに関連して使用される媒体で実施されるプログラム・コード手段を有する、コンピュータ使用可能またはコンピュータ読み取り可能な記憶媒体上のコンピュータ・プログラム製品の形態を取ることができる。本明細書の場合、コンピュータ使用可能またはコンピュータ読み取り可能な媒体は、命令実行システム、装置、または機器によってまたはそれに関連して使用される、プログラムを包含、記憶、通信、伝播、または搬送することができる任意の手段でありうる。

しかしながら、媒体は、例えば、電子的、磁気的、光学的、電磁的、赤外線、または半導体のシステム、装置、機器、または伝播媒体であることが可能であるが、これらに限定されない。コンピュータ読み取り可能な媒体のより特定的な例（網羅したリストではない）には、１つ以上の線を有する電気接続、着脱可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、携帯型コンパクト・ディスク読み出し専用メモリ（ＣＤ‐ＲＯＭ）が含まれるだろう。注意すべきは、コンピュータ使用可能またはコンピュータ読み取り可能な媒体は、プログラムを印刷可能な用紙または他の適した媒体であってさえよく、なぜならば、プログラムを例えば用紙または他の媒体の光走査を介して電子的に取り込んでから、コンパイル、解釈、または、そうでない場合には必要があれば適切なやり方での処理の後、コンピュータ・メモリに記憶することができるからである。

本説明において、同様の番号は、全体に渡って同様の構成要素を示す。

ＩＰｓｅｃ処理を使用して、パケットの内容をセキュリティ目的のために認証または暗号化することができる。認証および暗号化は、共にパケットに適用できるか、または、別個に適用できる。この説明を簡略化すると、ＩＰｓｅｃ処理の説明は、暗号化および復号化の観点でのパケットのカプセル化およびカプセル開放について述べている。説明の処理は、認証が単独に適用されていても、暗号化と共に適用されていても、等しく有効である。

ＩＰｓｅｃ処理がソース・クライアントからの送信パケットに適用されると、当該処理は、元ソースおよび宛先ポートならびにプロトコル・フィールドを暗号化し、この暗号化されたものをＵＤＰパケットにカプセル化する。元クライアント・ソースＩＰアドレスがＵＤＰパケットに保持されるが、ソース・ポート番号は、ＲＦＣ３９４８「ＵＤＰＥｎｃａｐｓｕｌａｔｉｏｎｏｆＩＰｓｅｃＥＳＰＰａｃｋｅｔｓ」に規定されているような４５００に設定される。ＵＤＰパケットはその後ＮＡＰＴへ送られ、ＮＡＰＴは、さらなる変換を行う。これらの変換は、図１および図２に対して以下に詳細に説明する。特に、ＮＡＰＴは、その自身のＩＰアドレスをクライアント・ソースＩＰアドレスの代わりに使用し、ＵＤＰヘッダに対する新規の固有のポート番号を割り当て、戻りパケットが元ソースに対してマッピングされるようにこれらの変換を追跡する。ＲＦＣ３９４８が説明する手法では、ＴＣＰまたはＵＤＰパケット内の元ソース・ポート番号は、ＮＡＰＴ装置によって変更されない。なぜならば、これは、ＩＰｓｅｃＥＳＰペイロードの一部として暗号化されている元トランスポート・ヘッダの一部だからである。その代わりに、上述のように、ＵＤＰカプセル化のために追加されたＵＤＰヘッダ内のポート番号が変更される。そのようなＩＰｓｅｃパケットがサーバによって受信されて暗号化されると、元ソースおよびパケットの宛先ポートを明らかにする。ＩＰｓｅｃを通じて処理されなかったパケットについては、ＮＡＰＴ装置は、元ソースＩＰアドレスおよびソース・ポートを変換する。暗号化されないパケットについては、ＮＡＰＴは、重複接続（重複ソース）がないことを保証する。

図１は、クライアント１０．１．１．１からＮＡＰＴ２１０．１．１．１とＮＡＰＴ２１１．１．１．１を通って宛先ホスト１１．１．１．１へのパケット進行と、パケット進行に伴うパケット・ヘッダおよび内容の変化とを示す。図２は、サーバからクライアントへの逆方向の戻りパケットの進行を示す。図１を参照して、ＩＰアドレス１０．１．１．１．のクライアントは、ＩＰアドレス１１．１．１．１のサーバ宛の暗号化されたパケットを送出する。ＩＰｓｅｃによる処理以前のパケットの元の内容を１００に示す。１００の左欄はパケットのフィールド型を記述し、右欄はフィールド内容を示す。注意すべきなのは、１００の宛先ＩＰアドレスは、２１１．１．１．１であり、実際の宛先サーバ１１．１．１．１の前のＮＡＴの公開アドレスである。ＮＡＴ２１１．１．１．１の役割は、パケットを１１．１．１．１のようなバックエンド・サーバにマッピングすることである。１００において、ソースおよび宛先ポートは、例示的にそれぞれ４０９６および２１に設定されている。ＩＰｓｅｃ処理後のパケットの内容を１０２に示す。パケット１０２の底部にある薄く網掛けされた部分は、ＩＰｓｅｃによって暗号化された部分を示す。１０２の濃く網掛けされた部分（および送信路の他の点におけるパケット内容）は、送信の当該点において変化または追加されたフィールドである。１０２において、実際のソースおよび宛先ポートは、ＩＰｓｅｃによる４０９６および２１という暗号化された値であり、この時点では読み出し可能ではない。ＩＰｓｅｃ処理は、ＵＤＰヘッダを追加して、これが元クライアント・パケットのポートおよびプロトコルをカプセル化するＩＰｓｅｃパケットである旨を示す。ＩＰｓｅｃによって追加されたクリア・テキストＵＤＰヘッダ内のソースおよび宛先ポートは、ＲＦＣ３９４８によって特定されるように４５００に設定されている。ＳＰＩ（セキュリティ・パラメータ・インデックス）フィールドは、例示的に２５６に設定されている。ＳＰＩフィールドは、セキュリティ・プロトコルおよび宛先アドレスと共に、暗号化アルゴリズムおよびこれらのエンティティ間の他のセキュリティ・パラメータを司るクライアント１０．１．１．１とサーバ１１．１．１．１との間のセキュリティ・アソシエーションをポイントする。

１０２のパケットは、ＩＰアドレス２１０．１．１．１におけるＮＡＰＴによって変換されて、１０４に示すパケットとなる。この時点で、ＮＡＰＴ２１０．１．１．１は、ソースＩＰアドレスを変更して、２１０．１．１．１という自身のアドレスを反映させている。また、ＮＡＰＴは、新規の固有のソース・ポート番号を設定する。図１において、選択されたソース・ポート番号は、４５００から４５０１へ例示的に変更される。ＮＡＰＴ２１０．１．１．１は、サーバ１１．１．１．１からの戻りパケットと、クライアントＩＰ１０．１．１．１およびソース・ポート４５００からの今後の送信パケットとについて、この変換を追跡する。

１０４のパケットは、ＮＡＴ２１１．１．１．１によって、サーバ１１．１．１．１に対する入力パケットへ再変換する。この入力パケットを１０６に示す。実質的には、パケットの宛先ＩＰアドレスが、ＮＡＴ２１１．１．１．１によって、宛先サーバの実際の宛先アドレス１１．１．１．１にマッピングされる。パケットのＩＰｓｅｃ処理は、ソース１０．１．１．１．におけるＩＰｓｅｃ処理によって追加されたＵＤＰヘッダを除去して、実際のソースおよび宛先ポート番号を復旧させる。その後、１０８に示すような復旧されたパケットは、宛先ポート（本例では２１）へ送られて、アプリケーション処理に供される。

完全性のために、図２は、サーバ２１１．１．１．１から元クライアント１０．１．１．１への戻りパケット・フローを示す。このパケット・フローの詳細を説明する必要がないのは、対処される重複ソースの問題は、戻りパケットには生じないからである。

図１を再び参照すると、１０８のパケットは、ソース・アドレスとして、ＮＡＰＴ２１０．１．１．１のアドレスと、ソース・ポート・アドレス４０９６を含む。しかしながら、ＮＡＰＴ２１０１．１．１の背後にある例えば、１０．１．１．２という他のクライアントが、ソース・ポート４０９６からホスト１１．１．１．１へパケットを送っている可能性もある。したがって、クライアント１０．１．１．１およびホスト１１．１．１．１間のパスにおけるＮＡＰＴがあるゆえに、衝突を生じさせる不正な重複ソースの可能性がある。

宛先ホストにおけるソース・ポート・マッピング・テーブル（ＳＰＭＴ）を使用して、ＮＡＰＴによって扱われるクライアントまたはサーバからパケットが受信される重複ソースを検出する。ＳＰＭＴの例示を図３の３００に示す。このテーブルは、ＩＰｓｅｃセキュリティ・アソシエーションが確立される場合にインターネット鍵交換（ＩＫＥ）パケットがサーバで受信されるときに動的に構築される。図３を参照して、ＩＫＥがＮＡＰＴを
トラバースするＩＰｓｅｃセキュリティ・アソシエーションを交渉する場合、ＴＣＰ／ＩＰスタックは、３０２などのＮＡＰＴホスト・エントリを作成して、ＮＡＰＴによって表される遠隔クライアントを表すように通知される。このエントリは、ＮＡＰＴのソースＩＰアドレス（本例においては、２１０．１．１．１）と、ＮＡＰＴによってこのクライアントに対して割り当てられたソース・ポート（本例においては、４５０１）とを含む。図３は、同一のＮＡＰＴＩＰソース・アドレス２１０．１．１．１と、ＮＡＰＴによって割り当てられた異なるソース・ポート４５０２とを有する、第２の例示的なＮＡＰＴクライアント３０４を示す。ＳＰＭＴ３００の右側は、ソース・ポート・エントリである。これらのエントリは、既存のエントリのないＩＰｓｅｃの暗号化されたパケットが到着するにつれて作成される。ソース・ポートエントリを追加する処理は、ＩＰｓｅｃ復号化が生じた後に生じる。ソース・ポート・エントリをＮＡＰＴホスト・エントリにマッピングするアソシエーション３０６は、ソース・ポート・エントリが作成されるにつれて作成される。ＮＡＰＴホスト・エントリは、当該エントリに関する最終セキュリティ・アソシエーションが削除されると除去される。パケットが到着して復号化されると、ソースＮＡＰＴアドレスと、元パケットのソース・ポートと、元パケットのプロトコルとが利用可能である。これらの属性の合致を見つけるために、ＳＰＭＴのソース・ポート・エントリが検索される。合致が見つかると、ＮＡＰＴソース・アドレスと、ＮＡＰＴによって割り当てられたソース・ポートとの合致を見つけるために、関連したＮＡＰＴホスト・エントリがチェックされる。これらの後者の属性が不一致の場合、ソースＮＡＰＴの背後の２つのクライアントは同一のソース・ポート番号を使用しようとしているということを意味する。これは、重複ソースを表し、第２のパケットは拒絶される。これらの後者の属性が一致すると、パケットは許可される。

図４から図７は、上述の説明を例示する助けとなる。図４は、ソースＮＡＰＴから来るパケットを示す。例示のため、クライアント・アドレスおよびポートは、１０．１．１．１および４０９６であると仮定する。４００は、ＮＡＰＴによって更新されたＩＰヘッダである。これは、ＮＡＰＴアドレス２１０．１．１．１と、ホスト宛先アドレス１１．１．１．１とを含む。４０２は、ＩＰｓｅｃ処理によって追加されてＮＡＰＴによって更新されたカプセル化ＵＤＰヘッダである。ソース・ポート４５００は、ＮＡＰＴによって４５０１へ変更されている。４０４は、ＩＰｓｅｃ処理によって追加されたカプセル化されたセキュリティ制御（ＥＳＰ）ヘッダを含む。ＴＣＰトランスポート・ヘッダ４０６は、元クライアント・ソースと、宛先ポートとを含み、それぞれ４０９６および２１である。４０８は、ＥＳＰトレーラが続くペイロード・データを含む。トランスポート・ヘッダ４０６およびペイロード４０８は、ＩＰｓｅｃ処理に従って暗号化される。図５は、宛先ホストにおける復号化後の図４のパケットを表す。注意すべきなのは、（パケット・フィールド５００からの）ソースＮＡＰＴアドレス２１０．１．１．１と、クライアント・ソース・ポート４０９６と、プロトコル（ＴＣＰ）とが、フィールド５０６から利用可能である。これらの属性を使用して、ＳＰＭＴ３００のソース・ポート・エントリが検索される。この例において、３０８において合致が見つかる。対応のアソシエーション３０６は、ＮＡＰＴホスト・エントリ３０２をポイントする。ソースＮＡＰＴアドレス２１０．１．１．１およびＮＡＰＴソース・ポート４５０１は、このパケットと合致する（ＮＡＰＴソース・ポート４５０１は、受信パケットのフィールド４０２からクリアで利用可能である）。よって、このパケットは、正確な接続に関連付けられて、受け付けられる。

図６および図７は、２番目に到着する「重複」ソース・パケットを表し、これは拒絶されることになる。なぜならば、フィールド７００からのＮＡＰＴソース・アドレス２１０．１．１．１と、７０６からのプロトコルと、ソース・クライアント・ポート４０９６は、ＳＰＭＴ３００のソース・ポート・エントリである３０８と合致するが、関連ＮＡＰＴエントリ３０２は、受信パケットのフィールド６０２からの４５０２のＮＡＰＴ割り当てポート番号と合致しないからである。

適切なフローチャートに関連して、この処理をより詳細に以下に説明する。

図８は、ＩＫＥ交渉中のＳＰＭＴ３００のＮＡＰＴホスト・エントリの初期化を示す。ＩＫＥ交渉は、ステップ８０２で表されている。交渉中に、ステップ８０４は、ＳＰＭＴ３００における関連ＮＡＰＴホスト・エントリを作成するためにＴＣＰ／ＩＰスタックへ通知を送信する。この通知は、ＩＫＥフローから取り出されたＮＡＰＴソース・アドレスとポート番号とを含む。

図９は、データ・パケットが宛先ホストに到着する場合の重複ソースを検出する処理を開始する。ステップ９０２は、受信パケットがＵＤＰヘッダ内にカプセル化されたＥＳＰパケットを含み、かつＵＤＰヘッダ内のソース・ポートが予め規定されたＵＤＰカプセル化ポート４５００ではないかどうかを判断する。上記が真であれば、パケットは、暗号化または認証のいずれかのためにＩＰｓｅｃを使用しており、ＮＡＰＴは送信路に含まれる。パケットが４５００の宛先ポートを伴うＵＤＰプロトコルを使用しており、最初の４バイトが非ゼロ・データを含む場合には、パケットは、ＵＤＰカプセル化されたＥＳＰパケットとして識別される。ステップ９０２におけるこれらの質問に対する答えがいいえの場合は、９０４におけるオプション１と９０６におけるオプション２という２つの代替処理オプションがある。これらを共に以下で説明する。９０２における答えがハイであると仮定すると、９０８は図１０のＡと続く。図１０において、ステップ１００２は、パケットを復号化するために必要なＩＰｓｅｃ処理を行う。その結果、ＮＡＰＴソース・アドレスと、元クライアント・ソース・ポート番号と、プロトコルとが、上述のようにクリアで取得される。ステップ１００４は、これらの属性についてＳＰＭＴ３００のソース・ポート・エントリを検索する。１００６において、合致が見つからない場合には、ステップ１００８においてソース・ポート・エントリが作成され、パケットの受信処理は通常通り継続する。ステップ１００６において合致が見つかると、ステップ１０１０は、対応のアソシエーション３０６を使用して、ＮＡＰＴ割り当てソース・アドレスと、復号化されたパケットからの同一の属性への対応ＮＡＰＴホスト・エントリからのポート番号とを比較する。この比較が失敗すると、パケットは１０１１において拒絶される。合致が取得されると、パケット処理は、通常通り１０１２において継続する。

図９からのオプション１およびオプション２は、パケットがクリア内に送られる（ＩＰｓｅｃ処理がない）か、パス内にアドレス変換（ＮＡＰＴ）がないかのいずれかの状況を表す。しかしながら、重複ソースの可能性がまだある。代替オプション１および２は両方とも、そのような重複パケットを回避する。オプション１の処理は、図１１のＢで開始する。このオプションは、ＳＰＭＴテーブル３００を通じてすべてのデータ・パケットを処理する。これは、「ＮＯＩＰＳＥＣ／ＮＡＰＴ」として指定された他の単一のＮＡＰＴホスト・エントリを追加することによって行われる。ＳＰＭＴ３００のパケットが到着すると、ソース・ポート・エントリを上述のように検索する。合致が見つからない場合には、ソース・ポート・エントリが１１０６において作成されて、「ＮＯＩＰＳＥＣ／ＮＡＰＴ」ＮＡＰＴホスト・エントリに関連付けられる。合致するソース・ポート・エントリが１１０４で見つかると、ステップ１１１０は、対応アソシエーション３０６が「ＮＯＩＰＳＥＣ／ＮＡＰＴ」ＮＡＰＴホスト・エントリをポイントしているかどうかを判断する。ポイントしている場合には、パケットは１１０８で許可される。そうでなければ、パケットは１１１２で拒絶される。このオプション１の利点は、簡略性である。その利点は、すべてのデータ・トラフィックがＳＰＭＴテーブル３００を通じて処理されるということである。

オプション２は、受信ＩＰｓｅｃパケット・フィルタリングを使用して、重複ソース・パケットを拒絶する。ＩＰｓｅｃがいったんホストに設定されると、すべてのパケットは、パケットが暗号化されているかどうかに関わらず、ＩＰｓｅｃ規則テーブル（ＳＰＤ）を介して処理される。これは、所定の接続上のクリア・パケットがＩＰｓｅｃ規則によって実際に許可されたことを検証するためのものである。オプション２の処理は、図１２のＣで開始する。ステップ１２０２において、受信パケットは、ＩＰｓｅｃ規則テーブル（図示せず）を介して処理される。好ましい一実施形態においてこれがどのように行われるかについては、上記の米国特許第６３４７３７６号から判断できる。この特許を、その全体を参照により援用するものとする。パケットが暗号化されると（ステップ１２０４）、ステップ１２０６は、支配的なＩＰｓｅｃ規則が暗号化を要求しているかどうかを判断する。要求していると仮定すると、パケットは１２０６において許可される。そうでない場合には、１２１０において拒絶される。ステップ１２０４においてパケットが暗号化されていない場合には、１２１２において、支配的なＩＰｓｅｃ規則は暗号化されていないパケットを許可するかどうかについての判断がなされ、それに従ってパケットが許可または拒絶される。トンネル・モードにおいて、ＩＰｓｅｃＳＡは、必ずしもエンド・ツー・エンドではない。例えば、ＳＡは、ホストと、複数のクライアントおよびサーバを扱うゲートウェイとの間を交渉してもよい。トンネル・モードにおいて、単一のＮＡＰＴアドレス（ＵＤＰカプセル化ヘッダにおけるソースＩＰアドレス）は、複数のホストを表す場合がある。トンネル・モードにおいて、パケットのカプセル化されかつ暗号化された部分は、ソースの元のＩＰアドレスとＴＣＰトランスポート・ヘッダとの両方を含む。本明細書の目的のために、トンネル・モードにおけるソースの元のＩＰアドレスを、内部ソースＩＰアドレスと称する。内部ソースＩＰアドレスは、全体的に固有ではないので、パケット・ルーティングまたは接続のソースを表すためには使用できない。ＳＰＭＴ３００のソース・ポート・エントリ内に含まれるような元のソース・ポートと、トランスポート・モードについて上述したようなＵＤＰポートだけを伴うカプセル化ソースＩＰアドレスとは、固有でない場合もあろう。これに対処するために、内部ソースＩＰアドレスを含む追加のフィールドが、図３のＳＰＭＴ３００のソース・ポート・エントリ（例えば、３０８）に追加される。（トランスポート・モードにおいては利用可能ではない）内部ソースＩＰアドレスは、ソース・ポート・エントリの他の値と組み合わせると、トンネル・モードのＩＰｓｅｃＳＡによって保護されたホストについての固有の識別子を生じさせる。内部ソースＩＰアドレスは、ステップ１００８の一部として、ソース・ポート・エントリに追加される。トンネル・モード・パケットが到着すると、ステップ１００４において上述したようなＳＰＭＴのソース・ポート・エントリを検索して、ＮＡＰＴホスト・エントリに対するアソシエーションを見つけ、ステップ１０１０において、上記説明に加えて、復号化されたパケットから取得した内部ソース・クライアントＩＰアドレスがソース・ポート・エントリ内のクライアントＩＰアドレスと同一であることを検証する。この検証が失敗すると、当該パケットは拒絶される。

好ましい実施形態が数多くの軽微の変形を有しうることは、当業者にとって明らかだろう。例えば、ＩＣＭＰプロトコルは、ポート番号を使用せず、むしろクエリ識別子を使用する。開示され請求された本発明に関して、クエリ識別子は、ポート番号と等価である。

クライアントからＮＡＰＴを介して宛先ホストへのパケットの進行と、パケットの進行に伴うパケット・ヘッダおよび内容に対する変更とを示す。図１のパケットに応答する戻りパケットを示す。ソース・ポート・マッピング・テーブル（ＳＰＭＴ）の一実施形態を例示する。暗号化された元パケットをカプセル化するＮＡＰＴ変換パケットを示す。復号化後の図４のパケットを示す。図４に対応する、送信路内のＮＡＰＴを含ませることによって生じる違法な重複ソースを表す先のパケットと同一のパス上の第２のパケットを示す。図５に対応する、送信路内のＮＡＰＴを含ませることによって生じる違法な重複接続を表す先のパケットと同一のパス上の第２のパケットを示す。ＳＰＭＴ内のＮＡＰＴホスト・エントリの作成のフローチャートである。受信パケットが最初に宛先ホストに到着した場合に利用可能なオプションを示すフローチャートである。暗号化された元パケットをカプセル化しかつＮＡＰＴを通った受信パケットの処理を示すフローチャートである。カプセル化およびＮＡＰＴ通過という両条件を満足しない受信パケットを処理する一代替方法を示すフローチャートである。カプセル化およびＮＡＰＴ通過という両条件を満足しない受信パケットを処理する一代替方法を示すフローチャートである。

Claims

アプリケーションを識別するためのネットワーク・アドレス、プロトコル、およびポート番号を使用するネットワーク・プロトコルにおける重複ソースを防止する方法であって、ａ）サーバでパケットを受信するステップと、ｂ）前記パケットがネットワーク・アドレス・ポート変換器によって変換されかつＩＰｓｅｃカプセル化されたパケットを含むかどうかを判断するステップと、ｃ）前記パケットが変換されかつＩＰｓｅｃカプセル化されたパケットを含む場合、前記パケットを処理して、元の接続情報を取得して、ソース・ポート・マッピング・テーブル（ＳＰＭＴ）を検索して、ＮＡＰＴ変換接続情報と前記元の接続情報との間のアソシエーションを見つけるステップと、ｄ）ステップｃ）の結果が重複ソースであることを表す場合には、前記パケットを拒絶するステップとを含む、方法。
前記ソース・ポート・マッピング・テーブルは、クライアントとサーバとの間のセキュリティ・アソシエーションが交渉される場合に作成されるＮＡＰＴホスト・エントリと、重複ソースを検出するために使用される前記ソース・ポート・エントリと前記ＮＡＰＴホスト・エントリとの間のマッピングを伴う、既存のエントリのない非重複ソース・パケットが到着すると作成されるソース・ポート・エントリとを含む、請求項１に記載の方法。
前記ソース・ポート・マッピング・テーブル内にＮＯＩＰＳＥＣ／ＮＡＰＴホスト・エントリを確立して、請求項１のステップｂ）を失敗したすべての受信パケットを示して、ソース・ポート・エントリを有しないすべての受信パケットを表して、ソース・ポート・エントリを有しないすべての受信パケットについてのソース・ポート・エントリを作成し、前記ソース・ポート・エントリをＮＯＩＰＳＥＣ／ＮＡＰＴホスト・エントリにマッピングし、前記ＮＯＩＰＳＥＣ／ＮＡＰＴホスト・エントリにマッピングされていない前記ソース・ポート・マッピング・テーブル内にソース・ポート・エントリを既に有する受信パケットのいずれかを拒絶するステップをさらに含む、請求項２に記載の方法。
アプリケーションを識別するためのネットワーク・アドレス、プロトコル、およびポート番号を使用するネットワーク・プロトコルにおける重複ソースを防止する方法であって、ａ）サーバでパケットを受信するステップと、ｂ）前記パケットがＩＰｓｅｃカプセル化されたパケットかどうかを判断するステップと、ｃ）前記パケットがＩＰｓｅｃカプセル化されたパケットである場合、前記パケットの前記送信パスがネットワーク・アドレス・ポート変換器（ＮＡＰＴ）を含むかどうかを判断するステップと、ｄ）前記パケットの前記送信パスがＮＡＰＴを含む場合、前記ＩＰｓｅｃカプセル化されたパケットをカプセル化して、元のソースポート番号と、元のパケット・プロトコルを取得するステップと、ｅ）ソース・ポート・マッピング・テーブル（ＳＰＭＴ）を検索して、前記ＮＡＰＴソース・アドレスと、前記元のソース・ポートと、前記ＮＡＰＴソース・アドレスおよびポート番号に対する前記元のパケット・プロトコルとの間のアソシエーションを見つけるステップと、ｆ）前記パケット内に含まれるのとは異なる元のポート番号に対するアソシエーションがステップｅ）で見つかると、前記パケットを拒絶するステップとを含む、方法。
ステップｂ）は、ユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダによってカプセル化されたカプセル化セキュリティ・ペイロード（ＥＳＰ）を含むかどうかを判断するステップをさらに含む、請求項４に記載の方法。
前記カプセル化されたＵＤＰヘッダは、４５００以外のソース・ポート・番号と、４５０に等しい宛先ポート番号を含むかどうかを判断するステップをさらに含む、請求項４に記載の方法。
インターネット・ホストからのインターネット鍵交換（ＩＫＥ）メッセージに応答して、前記サーバにおける前記ＳＰＭＴ内に、前記ＮＡＰＴの前記ソースＩＰアドレスと、前記ＮＡＰＴによって割り当てられたソース・ポート番号とをそれぞれ含むネットワーク・アドレス変換器（ＮＡＰＴ）ホスト・エントリを動的に構築するステップをさらに含む、請求項４に記載の方法。
ＩＰｓｅｃパケットが到着して処理されると、前記ＳＰＭＴ内に、ＮＡＰＴのソース・アドレスと、元のソース・ポート番号と、元のプロトコルとをそれぞれ含むソース・ポート・エントリを動的に構築するステップと、前記ソース・ポート・エントリと前記ＳＰＭＴの前記ＮＡＰＴホスト・エントリとの間のアソシエーションを確立するステップとをさらに含む、請求項７に記載の方法。
アソシエーションを確立する前記ステップは、アソシエーションがないＩＰｓｅｃパケットが到着する場合に、各アソシエーションを動的に確立するステップをさらに含む、請求項８に記載の方法。
単一のホスト「ＮＯＩＰＳＥＣ／ＮＡＰＴ」エントリを前記ＳＰＭＴに追加して、ＥＳＰヘッダを含まないかまたはＮＡＰＴを通過していないすべてのパケットを関連付けるステップと、ＥＳＰヘッダを含まないかまたはＮＡＰＴを通過しておらず、かつアソシエーションを有しないパケットが到着する場合に、前記ＳＰＭＴのソース・ポート・エントリと、前記「ＮＯＩＰＳＥＣ／ＮＡＰＴ」エントリとの間のアソシエーションを形成するステップと、前記「ＮＯＩＰＳＥＣ／ＮＡＰＴ」エントリをポイントしない前記合致ソース・ポート・エントリについて確立されたアソシエーションが既にある場合に、ＥＳＰヘッダを含まないかまたはＮＡＰＴを通過していないパケットを拒絶するステップとをさらに含む、請求項９に記載の装置。
到着パケットの前記送信路がＮＡＰＴを含まないか、前記到着パケットがＩＰｓｅｃパケットでない場合に、規則のセキュリティ・テーブルを検索して、前記パケットの拒絶または受け入れを司る規則合致を見つけるステップと、前記パケットがＩＰｓｅｃパケットであって前記合致規則がＩＰｓｅｃ処理を必要としない場合に、前記パケットを拒絶するステップと、前記パケットがＩＰｓｅｃパケットでなく前記合致規則がＩＰｓｅｃ処理を必要とする場合に、前記パケットを拒絶するステップとをさらに含む、請求項４に記載の装置。
コンピュータにロードおよび実行されると、アプリケーションを識別するためのネットワーク・アドレス、プロトコル、およびポート番号を使用するネットワーク・プロトコルにおける重複ソースを防止するための以下のステップを前記コンピュータに行わせるプログラム・コードを含む記憶媒体を備えるコンピュータ・プログラム製品であって、ａ）サーバでパケットを受信するステップと、ｂ）前記パケットがネットワーク・アドレス・ポート変換器によって変換されかつＩＰｓｅｃカプセル化されたパケットを含むかどうかを判断するステップと、ｃ）前記パケットが変換されかつＩＰｓｅｃカプセル化されたパケットを含む場合、前記カプセル化されたパケットを復号化して、元の接続情報を取得して、ソース・ポート・マッピング・テーブル（ＳＰＭＴ）を検索して、ＮＡＰＴ変換接続情報と前記元の接続情報との間のアソシエーションを見つけるステップと、ｄ）ステップｃ）の結果が重複ソースであることを表す場合には、前記パケットを拒絶するステップとを含む、コンピュータ・プログラム製品。
前記ソース・ポート・マッピング・テーブルは、クライアントとサーバとの間のセキュリティ・アソシエーションが交渉される場合に作成されるＮＡＰＴホスト・エントリと、重複ソースを検出するために使用される前記ソース・ポート・エントリと前記ＮＡＰＴホスト・エントリとの間のマッピングを伴う、既存のエントリのない非重複ソース・パケットが到着すると作成されるソース・ポート・エントリとを含む、請求項１２に記載のコンピュータ・プログラム製品。
前記ソース・ポート・マッピング・テーブル内にＮＯＩＰＳＥＣ／ＮＡＰＴホスト・エントリを確立して、請求項１のステップｂ）を失敗したすべての受信パケットを示して、ソース・ポート・エントリを有しないすべての受信パケットを表して、ソース・ポート・エントリを有しないすべての受信パケットについてのソース・ポート・エントリを作成し、前記ソース・ポート・エントリをＮＯＩＰＳＥＣ／ＮＡＰＴホスト・エントリにマッピングし、前記ＮＯＩＰＳＥＣ／ＮＡＰＴホスト・エントリにマッピングされていない前記ソース・ポート・マッピング・テーブル内のソース・ポート・エントリを既に有する受信パケットのいずれかを拒絶するためのプログラム・コードをさらに含む、請求項１３に記載のコンピュータ・プログラム製品。
コンピュータにロードおよび実行されると、アプリケーションを識別するためのネットワーク・アドレス、プロトコル、およびポート番号を使用するネットワーク・プロトコルにおける重複ソースを防止するための以下のステップを前記コンピュータに行わせるプログラム・コードを含む記憶媒体を備えるコンピュータ・プログラム製品であって、ａ）サーバでパケットを受信するステップと、ｂ）前記パケットの送信路がネットワーク・アドレス変換器（ＮＡＰＴ）を含むかどうかを判断するステップと、ｃ）前記パケットの前記送信路がＮＡＰＴを含む場合、前記パケットが元のカプセル化されたパケットを含むかどうかを判断するステップと、ｄ）前記パケットが元のカプセル化されたパケットを含む場合、前記元のカプセル化されたパケットを復号化して、元のソース・ポート番号と元のパケット・プロトコルとを取得するステップと、ｅ）ソース・ポート・マッピング・テーブル（ＳＰＭＴ）を検索して、前記ＮＡＰＴソース・アドレスと、前記元のソース・ポートと、前記ＮＡＰＴソース・アドレスおよび元のポート番号に対する前記元のパケット・プロトコルとの間のアソシエーションを求めるステップと、ｆ）ステップｅ）において前記パケットに含まれるのとは異なる元のポート番号であるアソシエーションが見つかる場合に、前記パケットを拒絶するステップとを含む、コンピュータ・プログラム製品。
ステップｂ）は、前記パケットがユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダを含むかどうかを判断するステップをさらに含む、請求項１５に記載のコンピュータ・プログラム製品。
ステップｃ）は、前記パケットがカプセル化されたセキュリティ・ペイロード（ＥＳＰ）ヘッダを含むかどうかを判断するステップをさらに含む、請求項１５に記載のコンピュータ・プログラム製品。
インターネット・ホストからのインターネット鍵交換（ＩＫＥ）メッセージに応答して、前記サーバにおける前記ＳＰＭＴ内に、前記ＮＡＰＴの前記ソースＩＰアドレスと、前記ＮＡＰＴによって割り当てられたソース・ポート番号とをそれぞれ含むネットワーク・アドレス変換器（ＮＡＰＴ）ホスト・エントリを動的に構築するステップをさらに含む、請求項１５に記載のコンピュータ・プログラム製品。
ＩＰｓｅｃパケットが到着して処理されると、前記ＳＰＭＴ内に、ＮＡＰＴのソース・アドレスと、元のソース・ポート番号と、元のプロトコルとをそれぞれ含むソース・ポート・エントリを動的に構築するためのコードと、前記ソース・ポート・エントリと前記ＳＰＭＴの前記ＮＡＰＴホスト・エントリと間のアソシエーションを確立するためのコードとをさらに含む、請求項１８に記載のコンピュータ・プログラム製品。
アソシエーションを確立する前記ステップは、アソシエーションがないカプセル化されたパケットが到着する場合に、各アソシエーションを動的に確立するためのコードをさらに含む、請求項１９に記載のコンピュータ・プログラム製品。
単一のホスト「ＮｏＩＰＳＥＣ／ＮＡＰＴ」エントリを前記ＳＰＭＴに追加して、ＥＳＰヘッダを含まないすべてのパケットを関連付け、アソシエーションを有しない非ＩＰｓｅｃパケットが到着する場合に、前記ＳＰＭＴのソース・ポート・エントリと、前記「ＮｏＩＰＳＥＣ／ＮＡＰＴ」エントリとの間のアソシエーションを形成し、前記ＮＡＰＴ「ＮｏＩＰＳＥＣ／ＮＡＰＴ」エントリをポイントしない前記合致ソース・ポート・エントリについて確立されたアソシエーションが既にある場合に、非ＩＰｓｅｃパケットを拒絶するためのコードをさらに含む、請求項２０に記載のコンピュータ・プログラム製品。
到着パケットの前記送信路がＮＡＰＴを含まないか、前記到着パケットがＩＰｓｅｃパケットでない場合に、規則のセキュリティ・テーブルを検索して、前記パケットの拒絶または受け入れを司る規則合致を見つけるためのコードと、前記パケットがＩＰｓｅｃパケットであって前記合致規則がＩＰｓｅｃ処理を必要としない場合に、前記パケットを拒絶するためのコードと、前記パケットがＩＰｓｅｃパケットでなく前記合致規則がＩＰｓｅｃ処理を必要とする場合に、前記パケットを拒絶するためのコードとをさらに含む、請求項１５または１６に記載の装置。
アプリケーションを識別するためのネットワーク・アドレス、プロトコル、およびポート番号を使用するネットワーク・プロトコルにおける重複ソースを防止するための装置であって、ａ）サーバでパケットを受信するための手段と、ｂ）前記パケットがネットワーク・アドレス・ポート変換器によって変換されかつＩＰｓｅｃカプセル化されたパケットを含むかどうかを判断するための手段と、ｃ）ＮＡＰＴからのＩＰｓｅｃカプセル化されたパケットを処理して、元の接続情報を取得するための手段と、ソース・ポート・マッピング・テーブル（ＳＰＭＴ）を検索して、ＮＡＰＴ変換接続情報と前記元の接続情報との間のアソシエーションを見つけるための手段と、ｄ）前記ＳＰＭＴが重複ソースであることを表す場合には、ＮＡＰＴからのＩＰｓｅｃカプセル化されたパケットを拒絶するための手段とを備える、装置。
クライアントとサーバとの間のセキュリティ・アソシエーションが交渉される場合に、ＮＡＰＴホスト・エントリを前記ソース・ポート・マッピング・テーブル内に作成するための手段と、既存のエントリのない非重複ソース・パケットが到着するとソース・ポート・エントリを作成するための手段とをさらに備える、請求項２３に記載の装置。
前記ソース・ポート・マッピング・テーブル内にＮＯＩＰＳＥＣ／ＮＡＰＴホスト・エントリを確立して、ＮＡＰＴによってＩＰｓｅｃカプセル化も変換もされていないすべての受信パケットを示すための手段と、ＮＡＰＴによってＩＰｓｅｃカプセル化も変換もされていないすべての受信パケットについてのソース・ポート・エントリを作成するための手段と、ソース・ポート・エントリを前記ＮＯＩＰＳＥＣ／ＮＡＰＴホスト・エントリにマッピングするための手段と、ＮＡＰＴによってＩＰｓｅｃカプセル化も変換もされておらず、かつ前記ＮＯＩＰＳＥＣ／ＮＡＰＴホスト・エントリにマッピングされていない前記ソース・ポート・マッピング・テーブル内のソース・ポート・エントリを既に有する受信パケットを拒絶するための手段をさらに備える、請求項２４に記載の装置。
アプリケーションを識別するためのネットワーク・アドレス、プロトコル、およびポート番号を使用するネットワーク・プロトコルにおける重複ソースを防止するための装置であって、ａ）サーバでパケットを受信するための手段と、ｂ）前記パケットの送信路がネットワーク・アドレス変換器（ＮＡＰＴ）を含むかどうかを判断するための手段と、ｃ）前記パケットの前記送信路がＮＡＰＴを含むという判断に応答して、前記パケットがＩＰｓｅｃカプセル化されたパケットを含むかどうかを判断するための手段と、ｄ）前記パケットがＩＰｓｅｃカプセル化されたパケットを含むという判断に応答して、前記パケットを処理して、元のソース・ポート番号と元のパケット・プロトコルとを取得するための手段と、ｅ）ソース・ポート・マッピング・テーブル（ＳＰＭＴ）を検索して、前記ＮＡＰＴソース・アドレスと、前記元のソース・ポートと、前記ＮＡＰＴソース・アドレスおよび元のポート番号に対する前記元のパケット・プロトコルとの間のアソシエーションを求めるための手段と、ｆ）前記パケットに含まれるのとは異なる元のポート番号であるアソシエーションに応答して、前記パケットを拒絶するための手段とを備える、装置。
前記パケットの前記送信路がネットワーク・アドレス変換器（ＮＡＰＴ）を含むかどうかを判断するための前記手段は、前記パケットがユーザ・データグラム・プロトコル（ＵＤＰ）ヘッダを含むかどうかを判断することをさらに含む、請求項２６に記載の装置。
前記パケットがＩＰｓｅｃカプセル化されたパケットを含むかどうかを判断するための前記手段は、前記パケットがカプセル化されたセキュリティ・ペイロード（ＥＳＰ）ヘッダを含むかどうかを判断することをさらに含む、請求項２６に記載の装置。
インターネット・ホストからのインターネット鍵交換（ＩＫＥ）メッセージに応答して、前記サーバにおける前記ＳＰＭＴ内に、前記ＮＡＰＴの前記ソースＩＰアドレスと、前記ＮＡＰＴによって割り当てられたソース・ポート番号とをそれぞれ含むネットワーク・アドレス変換器（ＮＡＰＴ）ホスト・エントリを動的に構築するための手段をさらに備える、請求項２６に記載の装置。
ＩＰｓｅｃパケットが到着して処理されると、前記ＳＰＭＴ内に、ＮＡＰＴのソース・アドレスと、元のソース・ポート番号と、元のプロトコルとをそれぞれ含むソース・ポート・エントリを動的に構築するための手段と、前記ソース・ポート・エントリと前記ＳＰＭＴの前記ＮＡＰＴホスト・エントリと間のアソシエーションを確立するための手段とをさらに備える、請求項２９に記載の装置。
アソシエーションを確立するための前記手段は、アソシエーションがないカプセル化されたパケットが到着する場合に、各アソシエーションを動的に確立するための手段をさらに備える、請求項３０に記載の装置。
単一のホスト「ＮｏＩＰＳＥＣ／ＮＡＰＴ」エントリを前記ＳＰＭＴに追加して、ＥＳＰヘッダを含まないすべてのパケットを関連付けるための手段と、アソシエーションを有しない非ＩＰｓｅｃパケットが到着する場合に、前記ＳＰＭＴのソース・ポート・エントリと、前記「ＮｏＩＰＳＥＣ／ＮＡＰＴ」エントリとの間のアソシエーションを形成するための手段と、前記ＮＡＰＴ「ＮｏＩＰＳＥＣ／ＮＡＰＴ」エントリをポイントしない前記合致ソース・ポート・エントリについて確立されたアソシエーションが既にある場合に、非ＩＰｓｅｃパケットを拒絶するための手段とをさらに備える、請求項３１に記載の装置。
到着パケットの前記送信路がＮＡＰＴを含まないか、前記到着パケットがＩＰｓｅｃパケットでないという判断に応答して、規則のセキュリティ・テーブルを検索して、前記パケットの拒絶または受け入れを司る規則合致を見つけるための手段、前記パケットがＩＰｓｅｃパケットであって前記合致規則がＩＰｓｅｃ処理を必要としない場合に、前記パケットを拒絶するための手段と、前記パケットが非ＩＰｓｅｃパケットであって前記合致規則がＩＰｓｅｃ処理を必要とする場合に、前記パケットを拒絶するための手段とをさらに備える、請求項２６または２７に記載の装置。