"下記の段階を含む、第1のコンピュータと第2のコンピュータとの間の情報を送信する方法:1連続するデータパケット間で周期的に変化する各ディスクリミネータ値が、各データパケット内の他のデータの値のみに基づく値ではない、複数のデータパケットのそれぞれにディスクリミネータ値を埋め込む段階、2第1のコンピュータと第2のコンピュータとの間で複数のデータパケットを送信する段階、3送信されたデータパケットを第2のコンピュータで受信する段階、および4受信された各データパケットについて、該ディスクリミネータ値を1組の有効なディスクリミネータ値と比較し、一致を検出したことに応答して、受信されたデータパケットを受け付けてさらに処理し、そうでない場合には、受信されたデータパケットを拒否する段階。段階1が、インタネットプロトコルヘッダ内のインタネットプロトコルアドレスをディスクリミネータ値として使用する段階を含み、該インタネットプロトコルアドレスが、インタネットを介してデータパケットをルーティングするために使用される、請求項1記載の方法。連続するパケット間でインタネットプロトコルアドレスの一部のみの値を変化させる段階をさらに含む、請求項2記載の方法。各データパケットのインタネットプロトコルヘッダの外部のデータフィールドをディスクリミネータ値として使用する段階をさらに含む、請求項1記載の方法。段階1および4がISO標準通信プロトコルのデータリンク層で実行される、請求項1記載の方法。段階1が、ディスクリミネータ値として媒体アクセス制御MACハードウェアアドレスを使用する段階を含み、MACハードウェアアドレスがローカルエリアネットワーク上でデータパケットをルーティングするために使用される、請求項1記載の方法。段階1が、連続する各パケットごとに異なるディスクリミネータ値を使用する段階を含む、請求項1記載の方法。段階4が、各ディスクリミネータ値を有効なディスクリミネータ値のウインドウと比較する段階を含み、該ウインドウが、有効である可能性のある少数のディスクリミネータ値のみとの比較を可能にするのに十分な幅を有し、段階4が、連続するデータパケットが受信されたときにウインドウを移動させる段階をさらに含む、請求項1記載の方法。1組の有効なディスクリミネータ値を生成するのに十分な情報を第1のコンピュータと第2のコンピュータとの間で共用する段階をさらに含む、請求項1記載の方法。連続的に有効なディスクリミネータ値を選択するアルゴリズムを第1のコンピュータから第2のコンピュータに送信する段階をさらに含む、請求項1記載の方法。段階4が、存在ベクトルを使用して、各データパケットを受け付けるかどうかを判定する段階を含む、請求項1記載の方法。段階4が、ハッシュ関数を使用して、ディスクリミネータ値が有効であるかどうかを判定する段階を含む、請求項1記載の方法。第1のコンピュータと第2のコンピュータとの間で同期要求を送信する段階をさらに含み、第2のコンピュータが、該同期要求を使用して有効なディスクリミネータ値の同期を維持する、請求項1記載の方法。第2のコンピュータからの同期肯定応答の受信に失敗したことに応答して、第2のコンピュータへのデータパケットの送信を遮断する段階をさらに含む、請求項13記載の方法。第2のコンピュータが、有効である可能性のある1組のディスクリミネータ値において同期を再確立できるようにする同期値を、各データパケットに埋め込む段階をさらに含む、請求項13記載の方法。第1のコンピュータから同期要求を受信したことに応答して、第2のコンピュータ内の有効なディスクリミネータ値のウインドウを移動させる段階をさらに含む、請求項13記載の方法。段階1が、インタネットプロトコルヘッダ内のインタネットプロトコル送信元アドレスをディスクリミネータ値の第1の部分として使用し、インタネットプロトコルヘッダ内のインタネットプロトコル着信先アドレスをディスクリミネータ値の第2の部分として使用する段階を含み、該送信元アドレスおよび着信先アドレスが、インタネットを介して各データパケットをルーティングするために使用される、請求項1記載の方法。複数のデータパケットをフレームに埋め込む段階と、準無作為的に生成されフレームをネットワーク上でルーティングするために使用される送信元および着信先ハードウェアアドレスをフレームに埋め込む段階とをさらに含む、請求項17記載の方法。第1の送信テーブルおよび第1の受信テーブルを第1のコンピュータ内に維持し、且つ第2の送信テーブルおよび第2の受信テーブルを第2のコンピュータ内に維持する段階をさらに含み、各送信テーブルが、発信データパケットに挿入すべき有効なディスクリミネータ値のリストを含み、各受信テーブルが、着信データパケットと比較すべき有効なディスクリミネータ値のリストを含み、第1のコンピュータ内の第1の送信テーブルが第2のコンピュータ内の第2の受信テーブルに一致し、第1のコンピュータ内の第1の受信テーブルが第2のコンピュータ内の第2の送信テーブルに一致する、請求項1記載の方法。下記の段階を含む、複数の物理送信パスを通して互いに接続された複数のコンピュータを備えるネットワークを介してデータパケットを送信する方法:1複数のデータパケットのそれぞれについて、複数のコンピュータを通る複数の物理送信パスのうちの1つを無作為に選択する段階、および2無作為に選択された物理送信パスを介して各データパケットを送信する段階。段階1が下記の段階を含む、請求項20記載の方法:aネットワーク内の一対のコンピュータによって規定されるパスを選択する段階、b選択されたパスに関連する有効な送信元アドレスおよび着信先アドレスを選択する段階、ならびにc有効な送信元アドレスおよび着信先アドレスを、選択されたパスを介して送信する前にデータパケットに挿入する段階。連続するデータパケット間で周期的に変化する各ディスクリミネータ値が、各データパケット内の他のデータの値のみに基づく値ではない、複数のデータパケットのそれぞれにディスクリミネータ値を埋め込む第1のコンピュータと、ネットワークを通して第1のコンピュータに結合された第2のコンピュータとを備えるシステムであって、該第1のコンピュータが該第2のコンピュータに複数のデータパケットを送信し、該第2のコンピュータが、送信されたデータパケットを受信し、受信された各データパケット内のディスクリミネータ値を1組の有効なディスクリミネータ値と比較し、一致を検出したことに応答して、受信されたデータパケットを受け付けてさらに処理し、そうでない場合には、受信されたデータパケットを拒否するシステム。第1のコンピュータが、ディスクリミネータ値としてのインタネットプロトコルヘッダ内のインタネットプロトコルアドレスを複数のデータパケットのそれぞれに埋め込み、インタネットプロトコルアドレスが、インタネットを介してデータパケットをルーティングするために使用される、請求項22記載のシステム。第1のコンピュータが、連続するパケット間でインタネットプロトコルアドレスの一部のみの値を変化させる、請求項22記載のシステム。第1のコンピュータが、各データパケットのインタネットプロトコルヘッダの外部のデータフィールドにディスクリミネータ値を埋め込む、請求項22記載のシステム。第1のコンピュータが、ISO標準通信プロトコルの第1のデータリンク層に各ディスクリミネータ値を埋め込み、第2のコンピュータが、ISO標準通信プロトコルの第2のデータリンク層内の各ディスクリミネータ値を比較する、請求項22記載のシステム。第1のコンピュータが、ディスクリミネータ値として媒体アクセス制御MACハードウェアアドレスを使用し、MACハードウェアアドレスがローカルエリアネットワーク上でデータパケットをルーティングするために使用される、請求項22記載のシステム。第1のコンピュータが、連続する各パケットごとに異なるディスクリミネータ値を埋め込む、請求項22記載のシステム。第2のコンピュータが、各ディスクリミネータ値を有効なディスクリミネータ値のウインドウと比較し、該ウインドウが、有効である可能性のある少数のディスクリミネータ値のみとの比較を可能にするのに十分な幅を有し、該ウインドウが、連続するデータパケットが受信されたときに移動させられる、請求項22記載のシステム。第1のコンピュータと第2のコンピュータが、1組の有効なディスクリミネータ値を生成するのに十分な情報を共用する、請求項22記載のシステム。第1のコンピュータが、連続的に有効なディスクリミネータ値を選択するアルゴリズムを第2のコンピュータに送信する、請求項22記載のシステム。第2のコンピュータが、存在ベクトルを使用して、各データパケットを受け付けるかどうかを判定する、請求項22記載のシステム。第2のコンピュータが、ハッシュ関数を使用して、ディスクリミネータ値が有効であるかどうかを判定する、請求項22記載のシステム。第1のコンピュータが第2のコンピュータに同期要求を送信し、該第2のコンピュータが、該同期要求を使用して有効なディスクリミネータ値の同期を維持する、請求項22記載のシステム。第1のコンピュータが、第2のコンピュータからの同期肯定応答の受信に失敗したことに応答して、第2のコンピュータへのデータパケットの送信を遮断する、請求項34記載のシステム。第1のコンピュータが、第2のコンピュータが有効である可能性のある1組のディスクリミネータ値において同期を再確立できるようにする同期値を、各データパケットに埋め込む、請求項34記載のシステム。第2のコンピュータが、第1のコンピュータから同期要求を受信したことに応答して、有効なディスクリミネータ値のウインドウを移動させる、請求項34記載のシステム。第1のコンピュータが、インタネットプロトコル送信元アドレスをインタネットプロトコルヘッダにディスクリミネータ値の第1の部分として埋め込み、インタネットプロトコル着信先アドレスをインタネットプロトコルヘッダにディスクリミネータ値の第2の部分として埋め込み、該送信元アドレスおよび着信先アドレスが、インタネットを介して各データパケットをルーティングするために使用される、請求項22記載のシステム。第1のコンピュータが、複数のデータパケットをフレームに埋め込み、送信元および着信先ハードウェアアドレスをフレームに埋め込み、該送信元および着信先ハードウェアアドレスが、準無作為的に生成され、フレームをネットワーク上でルーティングするために使用される、請求項38記載のシステム。第1のコンピュータが、第1の送信テーブルおよび第1の受信テーブルを備え、第2のコンピュータが、第2の送信テーブルおよび第2の受信テーブルを備え、各送信テーブルが、発信データパケットに挿入すべき有効なディスクリミネータ値のリストを含み、各受信テーブルが、着信データパケットと比較すべき有効なディスクリミネータ値のリストを含み、第1のコンピュータ内の第1の送信テーブルが第2のコンピュータ内の第2の受信テーブルに一致し、第1のコンピュータ内の第1の受信テーブルが第2のコンピュータ内の第2の送信テーブルに一致する、請求項22記載のシステム。偽無作為ディスクリミネータ値を生成し、送信されるデータパケットに偽無作為ディスクリミネータ値を埋め込む送信側ノードと、送信側ノードによって送信されたデータパケットを受信し、受信された各パケットごとに、偽無作為的に生成されたディスクリミネータ値を抽出し、該ディスクリミネータ値を、送信側ノードと受信側ノードとの間で共用される有効である可能性のある1組のディスクリミネータ値と比較し、一致を検出したことに応答して、データパケットを受け付け、そうでない場合はパケットを破棄する受信側ノードとの組合せを備えるシステム。受信側ノードが、有効なディスクリミネータ値のウインドウを維持し、該ウインドウが、一致を検出したことに応答して移動させられる、請求項41記載のシステム。偽無作為的に生成された各ディスクリミネータ値が、受信側ノードに割り当てられた有効なインタネットプロトコルアドレスを含む、請求項41記載のシステム。偽無作為的に生成された各ディスクリミネータ値が、受信側ノードに割り当てられた有効な媒体アクセス制御MACハードウェアアドレスを含む、請求項41記載のシステム。送信側ノードが、連続する各データパケットごとに、それぞれの異なる、偽無作為的に生成されたディスクリミネータ値を生成する、請求項41記載のシステム。送信側コンピュータからデータパケットを受信する受信側コンピュータであって、1受信された各データパケットごとに、送信側コンピュータによって挿入されたディスクリミネータ値を抽出する段階と、2抽出されたディスクリミネータ値を、すでに送信側コンピュータと共用されている情報に基づいて、1組の有効なディスクリミネータ値と比較する段階と、3段階2で一致を検出したことに応答して、受信されたデータパケットを受け付けてさらに処理し、そうでない場合はデータパケットを拒否する段階とを実行するコンピュータ命令を備える、受信側コンピュータ。ディスクリミネータ値として各データパケットのヘッダ部分からインタネットプロトコルアドレスを抽出するコンピュータ命令をさらに備える、請求項46記載の受信側コンピュータ。受信側コンピュータが、有効なディスクリミネータ値のウインドウを維持し、該ウインドウが、一致を検出したことに応答して移動させられる、請求項46記載の受信側コンピュータ。1組の有効なディスクリミネータ値を確立するのに十分な情報を送信側コンピュータから受信する、請求項46記載の受信側コンピュータ。下記の段階を含む、特定の順序に配置された複数のデータバイトを含むデータを第1のコンピュータから第2のコンピュータに送信する方法:1複数のデータパケットにデータを無作為に分配するにはどうすべきかを決定する共通のアルゴリズムを第1のコンピュータおよび第2のコンピュータにおいて確立する段階、2第1のコンピュータにおいて、共通のアルゴリズムに従って複数のデータパケットに複数のデータバイトを無作為に分配する段階、3複数のデータパケットを第1のコンピュータから第2のコンピュータに送信する段階、および4第2のコンピュータにおいて、無作為に分配された複数のデータバイトを、複数のデータパケットから抽出し、共通のアルゴリズムに従って特定の順序に並べ直す段階。段階3が、複数のデータパケットのそれぞれをコンピュータネットワーク内の異なるパスを介して送信する段階を含む、請求項50記載の方法。複数のデータパケットにデータを割り付けるための無作為分配パターンを確立するアルゴリズムを含み、データ供給源からのデータバイトを無作為分配パターンに従って複数のデータパケットに無作為に分配し、複数のデータパケットをネットワークを介して送信する第1のコンピュータと、ネットワークを介して第1のコンピュータに結合されており、第1のコンピュータから複数のデータパケットを受信し、無作為に分配されたデータバイトを抽出し、該データバイトをアルゴリズムに従って最初の順序に並べ直す第2のコンピュータとを備えるシステム。第1のコンピュータが、複数のデータパケットのそれぞれをネットワーク内のそれぞれの異なるパスを介して送信する、請求項52記載のシステム。下記の段階を含む、送信側コンピュータと受信側コンピュータとの間でデータパケットを安全に送信する方法:1送信側コンピュータおよび受信側コンピュータに知られているが、送信側コンピュータと受信側コンピュータとの間の中間コンピュータには知られていないセッション鍵を使用してデータパケットを暗号化する段階、2段階1で暗号化されたデータパケットに、該データパケットを識別するパケットヘッダを付加する段階、3段階2で作成された組み合わされたパケットヘッダと暗号化データパケットを、第1のコンピュータと第2のコンピュータとの間に配置された複数の各中間コンピュータに知られているリンク鍵を使用して暗号化する段階、4段階3で暗号化されたパケットをルーティングするために平文パケットヘッダを付加する段階、および5段階4で作成されたパケットを送信する段階。5各中間コンピュータにおいて、前のコンピュータから受信されたパケットを復号し、かつリンク鍵を使用して復号する段階と、6ネットワーク内の次の中間ネットワークに知られている異なるリンク鍵を使用してパケットを再暗号化する段階と、7段階6で再暗号化されたパケットをルーティングするために平文パケットヘッダを付加する段階と、8段階7で作成されたパケットを次の中間コンピュータに送信する段階とをさらに含む、請求項54記載の方法。受信側コンピュータにおいて、セッション鍵を使用してパケットを復号する段階をさらに含む、請求項55記載の方法。下記の段階を含む、コンピュータネットワークを介してデータを送信する方法:コンピュータネットワークに接続された発信側端末において、データストリームを受信し、該データストリームから第1レベルデータパケットペイロードを形成する段階、データストリーム用のネットワーク着信先アドレスを識別し、ネットワーク着信先アドレスを表すデータを含む第1レベルヘッダを各データパケットに付加して第1レベルパケットを形成する段階、各第1レベルパケットを暗号化して第2レベルパケットペイロードを形成する段階、発信側端末を着信先に接続する少なくとも1つの中間ルータのアドレスを着信先アドレスとして含むペイロードヘッダを第2のレベルパケットに付加して第2レベルパケットを形成する段階、第2レベルパケットを該少なくとも1つの中間ルータに送信する段階、および該少なくとも1つの中間ルータにおいて、少なくとも1つの第2レベルペイロードを復号し、第1レベルヘッダから着信先アドレスを判定し、少なくとも第1レベルパケットペイロードを含む新しいパケットを形成し、着信先アドレスを含むヘッダを新しいパケットに付加し、それによって、データストリームの真の着信先が、ネットワークを介して送信される少なくとも一部の時間の間、暗号化層に隠される段階。付加段階が、一群の中間ルータから無作為に選択することによって少なくとも1つの中間ルータを決定することを含む、請求項57記載の方法。第1レベルヘッダから着信先アドレスを判定する段階が、中間ルータ上に記憶されている相関データによって、ネットワーク着信先アドレスを表すデータをネットワーク着信先アドレスに変換することを含む、請求項57記載の方法。第1レベルパケットがネットワーク着信先に到着する前に行うホップの数のインディケータを第1層ヘッダと第2層ヘッダの一方に含める段階をさらに含み、少なくとも1つの中間ルータが、ホップの数のインディケータを減分させ、ホップの数のインディケータの値に応じてそれぞれ別の中間ルータに第1レベルパケットを送信する、請求項57記載の方法。下記の段階を含む、パケットネットワーク上でパケットをルーティングする方法:セッション鍵を用いてメッセージデータをブロック暗号化してペイロードを形成する段階、ブロック暗号化によって暗号化されたブロックを、ブロック暗号化段階によるデータのインタリーブ部分が少なくとも2つのデータペイロードの間に入るように少なくとも2つのデータペイロードに分割する段階、少なくとも2つのデータペイロードのそれぞれを、パケットの最終的な着信先を識別する着信先データと共に、リンク鍵を用いて暗号化する段階、第1の中間着信先アドレスを示す第1のホップアドレスを最後の暗号化段階の結果として得られた第1のペイロードと組み合わせ、結果として得られた第1のパケットを第1の中間着信先アドレスに送信する段階、および第2の中間着信先アドレスを示す第2のホップアドレスを最後の暗号化段階の結果として得られた第2のペイロードと組み合わせ、結果として得られた第2のパケットを第2の中間着信先アドレスに送信する段階。第1のパケットに第1のホップカウンタを組み合わせる段階と、第1の中間着信先アドレスに一致する端末において、第1のホップカウンタに応じて、第1のパケットを最終的な着信先アドレスに送信するよう判定する段階と、第1の中間着信先アドレスに一致する端末において、リンク鍵を用いて第1のペイロードを復号して最終的な着信先アドレスを明らかにし、判定段階に応じて第1のパケットを最終的な着信先アドレスに送信する段階とをさらに含む、請求項61記載の方法。第2のパケットに第2のホップカウンタを組み合わせる段階と、第2の中間着信先アドレスに一致する端末において、第2のホップカウンタに応じて、第1のパケットを最終的な着信先アドレスに送信するよう判定する段階と、第2の中間着信先アドレスに一致する端末において、リンク鍵を用いて第2のペイロードを復号して最終的な着信先アドレスを明らかにし、最後の判定段階に応じて第2のパケットを最終的な着信先アドレスに送信する段階とをさらに含む、請求項61記載の方法。態様の詳細な説明図2を参照するとわかるように、インタネットを介して通信する安全機構は、各ルータが、1つまたは複数のIPアドレスを有しており、かつ通常のIPプロトコルを使用して、TARPパケット140と呼ばれる、通常のパケットと同様なIPパケットメッセージを送信するという点で、正規のIPルータ128~132と類似している、TARPルータ122~127と呼ばれるいくつかの特殊なルータまたはサーバを使用する。TARPパケット140は、それぞれが通常のIPパケットと同様に着信先アドレスを含むので、正規のIPルータ128~132によってルーティングされる通常のIPパケットメッセージと同一である。しかし、TARPパケット140IPヘッダは、IPヘッダの着信先フィールドで最終着信先を示す示すのではなく、常に、一連のTARPルータホップ内の次のホップまたは最終着信先、すなわちTARP端末110を指し示す。TARPパケットのヘッダが次のホップ着信先のみを含むため、着信先は常に、次のホップTARPルータおよび最終着信先、すなわちTARP端末110であるので、傍受されたTARPパケットにはそのTARPパケットの真の着信先を明白に示すものがない。各TARPパケットの真の着信先は、リンク鍵146を使用して生成された暗号化アウタレイヤに隠される。リンク鍵146は、発信元TARP端末100と着信先TARP端末110を接続するホップのチェーン内の単一のリンクのエンドポイントTARP端末またはTARPルータ間の暗号化された通信に使用される暗号化鍵である。各TARPルータ122~127は、チェーン内の前のホップとに通信に使用するリンク鍵146を使用してTARPパケットの真の着信先を知ることができる。受信側TARPまたはルーティング端末は、TARPパケットの暗号化アウタレイヤを復号するのに必要なリンク鍵を識別するために、平文IPヘッダの送信側フィールドによって使用されるリンク鍵を示すことのできる送信側端末を識別することができる。あるいは、平文IPヘッダ内の利用可能なビット内の他の暗号化レイヤにこのIDを隠すことができる。各TARPルータは、TARPメッセージを受信すると、TARPパケット内の認証データを使用することによって、そのメッセージがTARPメッセージであるかどうかを判定する。これは、TARPパケットのIPヘッダ内の利用可能なバイトに記録することができる。あるいは、リンク鍵146を使用して復号を試み、結果が予期されていた結果であるかどうかを判定することによって、TARPパケットを認証することができる。この方法は復号プロセスを伴わないので計算面の利点を有する。TARPルータ122~127によって復号アウタレイヤが完成した後、TARPルータは最終着信先を判定する。システムは好ましくは、トラフィック分析を無効にする助けになるように各TARPパケット140に最小数のホップを受けさせるように構成される。TARPメッセージのIPヘッダ内のタイムツーリブカウンタを使用して、完了すべき残りのTARPルータホップの数を示すことができる。各TARPルータは次いで、このカウンタを減分し、それにより、TARPパケット140を他のTARPルータ122~127に転送すべきか、それとも着信先TARP端末110に転送すべきかを判定する。タイムツーリブカウンタが減分後にゼロ以下になった場合、使用例として、TARPパケット140を受信したTARPルータは、このTARPパケット140を着信先TARP端末110に転送することができる。タイムツーリブカウンタが減分後にゼロを超えた場合、使用例として、TARPパケット140を受信したTARPルータは、この現在のTARP端末によって無作為に選択されたTARP端末122~127にこのTARPパケット140を転送することができる。その結果、各TARPパケット140は、無作為に選択されたTARPルータ122~127の最小数のホップを通してルーティングされる。したがって、各TARPパケットは、インタネット内のトラフィックを判定する従来の因子とは無関係に、着信先に到着する前に地理的に異なるいくつかのルータの間を無作為に移動し、各移動は、上述のように独立に無作為に決定されるので、所与のメッセージを構成する各パケットごとに異なる可能性が非常に高くなる。この機能をアジルルーティングと呼ぶ。まもなく明らかになる理由により、様々なパケットがそれぞれの異なる経路をとるため、侵入者が、マルチパケットメッセージ全体を形成するすべてのパケットを得ることは困難になる。アジルルーティングは、この目的を促進する他の機能、すなわち、あらゆるメッセージが複数のパケットに分割されるようにする機能と組み合される。TARPルータは、TARPルータによって使用されているIPアドレスがTARPパケットのIPヘッダIPC内のIPアドレスと一致するときにTARPパケットを受信する。しかし、TARPルータのIPアドレスは一定でなくてよい。侵入を回避し管理するために、各TARPルータは、独立して、あるいは他のTARP端末またはTARPルータからの指示の下で、IPアドレスを変更することができる。変更可能な別の識別子またはアドレスも定義される。このアドレスは、TARPアドレスと呼ばれ、TARPルータおよびTARP端末のみに知られ、いつでもTARPルータまたはTARP端末によって参照テーブルLUTを使用して相関付けることができる。TARPルータまたはTARP端末は、IPアドレスを変更したときに、他のTARPルータまたはTARP端末を更新し、これらのTARPルータまたはTARP端末はそれぞれのLUTを更新する。実際、TARPルータは、暗号化されたヘッダ内の着信先のアドレスを参照するときは常に、ルータ自体のLUTを使用してTARPアドレスを実際のIPアドレスに変換しなければならない。TARPパケットを受信したあらゆるTARPルータは、パケットの最終着信先を判定することができるが、メッセージペイロードは、セッション鍵を使用しないかぎりロック解除できないTARPパケット内の暗号化インナレイヤに埋め込まれる。発信元TARP端末100と着信先TARP端末110との間に介在するTARPルータ122~127はセッション鍵を利用することができない。セッション鍵を使用してTARPパケット140のペイロードを復号し、メッセージ全体を再構成することができる。一態様では、リンク鍵およびセッション鍵を使用して通信を公開されないようにすることができ、任意の所望の方法に従ってリンク鍵およびセッション鍵を共用し使用することができる。たとえば、公開鍵法を使用して、リンクエンドポイントまたはセッションエンドポイント間で公開鍵または対称鍵を伝達することができる。許可されたコンピュータのみがTARPパケット140内のプライベート情報にアクセスできるようにデータのセキュリティを確保する他の様々な機構のいずれかを必要に応じて使用することができる。図3Aを参照するとわかるように、一連のTARPパケットを構成する場合、IPパケット207a、207b、207cなどのデータストリーム300、すなわち、ネットワークIP層プロセスによって形成された一連のパケットが、一連の小さなセグメントに分割される。この例では、等しいサイズのセグメント1~9が定義され、これらを使用して、1組のインタリーブされたデータパケットA、B、およびCが構成される。この場合、形成されるインタリーブされたパケットA、B、およびCの数を3つと仮定し、インタリーブされた3つのパケットA、B、およびCを形成するために使用されるIPパケット207a~207cの数も3つと仮定する。もちろん、インタリーブされたパケットのグループに展開されるIPパケットの数は、着信データストリームが展開されたインタリーブされたパケットの数と同様に任意の好都合な数でよい。データストリームが展開されたインタリーブされたパケットの数をインタリーブウインドウと呼ぶ。送信側ソフトウェアは、パケットを作成する場合、通常のIPパケット207aおよび後続のパケットをインタリーブして、新しい1組のインタリーブされたペイロードデータ320を形成する。このペイロードデータ320は次いで、各データA、B、およびCがTARPパケットのペイロードを形成する、セッション鍵で暗号化された1組のペイロードデータ330を、セッション鍵を使用して形成することによって暗号化される。最初のパケット207a~207cのIPヘッダデータを使用して、新しいTARPパケットIPTが形成される。TARPパケットIPTは、通常のIPヘッダと同一でよく、あるいは何らかの方法でカスタマイズすることができる。好ましい態様では、TARPパケットIPTは、メッセージのルーティングおよび再構成に必要な以下の情報を提供する追加のデータを含むIPヘッダである。このデータのいくつかは通常、通常のIPヘッダに含まれており、あるいは通常のIPヘッダに含めることができる。1.ウインドウシーケンス番号-最初のメッセージシーケンス内でパケットがどこに属するかを示す識別子。2.インタリーブシーケンス番号-パケットをインタリーブウインドウ内の他のパケットと共にインタリーブ解除できるようにパケットを形成するために使用されるインタリーブシーケンスを示す識別子。3.タイムツーリブTTLデータ-パケットがその着信先に到着する前に実行すべきTARPルータホップの数を示す。TTLパラメータが、パケットを着信先にルーティングすべきか、それとも他のホップにルーティングすべきかを判定するための確率公式で使用すべきデータを提供できることに留意されたい。4.データタイプ識別子-ペイロードが、たとえばTCPデータを含むべきか、それともUDPデータを含むべきかを示す。5.送信側のアドレス-TARPネットワーク内の送信側のアドレスを示す。6.着信先アドレス-TARPネットワーク内の着信先端末のアドレスを示す。7.デコイ/実-パケットが実際のメッセージデータを含むか、それともダミーデコイデータを含むか、それとも組合せを含むかのインディケータ。自明のことながら、単一のインタリーブウインドウに入るパケットは、共通の着信先を有するパケットのみを含まなければならない。したがって、図の例では、IPパケット207a~207cのIPヘッダはすべて、同じ着信先アドレスを含むか、あるいはインタリーブ解除できるように少なくとも同じ端末によって受信されるものと仮定されている。他の場合に所与のメッセージのサイズによって必要とされるよりも大きなインタリーブウインドウを形成するようにダミーまたはデコイデータまたはパケットを追加できることに留意されたい。デコイデータまたはダミーデータをストリームに付加してネットワーク上の負荷を一様にすることにより、トラフィック分析を無効にする助けにすることができる。したがって、インタネット内のある点での通信バーストを他の点での通信バーストに結合して通信エンドポイントを知ることができなくなるように、時間またはその他の基準に応答して低トラフィック期間中により多くのデコイデータを生成する能力をTARPプロセスに付与することが望ましい。ダミーデータは、データをより多くの目立たないサイズのパケットに分割して、インタリーブウインドウのサイズを大きくすることを可能にし、同時に各パケットごとに合理的なサイズを維持するうえでも助けになる。パケットサイズは、単一の標準サイズでよく、あるいは一定の範囲のサイズから選択することができる。各メッセージを複数のパケットに分割することが望ましい1つの主要な理由は、インタリーブの前にチェーンブロック暗号化方式を使用して第1の暗号化レイヤが形成される場合に明らかである。メッセージの一部または全体に単一のブロック暗号化を適用し、次いでその部分または全体をインタリーブしていくつかの別々のパケットを得ることができる。図3Bを参照するとわかるように、TARPパケット構成の代替態様では、一連のIPパケットが蓄積され所定のインタリーブウインドウが形成される。パケットのペイロードを使用し、セッション鍵を使用して、チェーンブロック暗号化用の単一のブロック520が構成される。ブロックを形成するために使用されるペイロードは、同じ端末を着信先とするものと仮定する。ブロックサイズは、図3Bの態様例に示されたインタリーブウインドウと一致することができる。暗号化の後で、暗号化されたブロックは別々のペイロードおよびセグメントに分割され、これらのペイロードおよびセグメントが図3Aの態様のようにインタリーブされる。結果として得られるインタリーブされたパケットA、B、およびCは次いで、図3Aの例のようにTARPヘッダを有するTARPパケットとしてパッケージングされる。残りのプロセスは、図3Aに示され、図3Aを参照して論じられるとおりである。TARPパケット340が形成された後、TARPヘッダIPTを含む各TARPパケット340全体が、第1のホップTARPルータと通信するためのリンク鍵を使用して暗号化される。第1のホップTARPルータは無作為に選択される。暗号化された各TARPパケット240に最後の未暗号化IPヘッダIPCが付加され、TARPルータに送信できる通常のIPパケット360が形成される。TARPパケット360を構成するプロセスを前述のように段階的に行う必要がないことに留意されたい。上記の説明は、最終プロダクト、すなわち、TARPパケットを説明するための有用なヒューリスティックに過ぎない。TARPパケットIPTを、上記で識別された情報を含むことを除いて、通常のIPヘッダとはまったく異なる完全なカスタムヘッダ構成にすることができることに留意されたい。これは、このヘッダがTARPルータによってのみ解釈されるからである。上記の方式は、TARPシステムに参加している各サーバまたは端末のデータリンク層とネットワーク層との間で動作するプロセスによって完全に実施することができる。図4を参照するとわかるように、TARPトランシーバ405は発信元端末100、着信先端末110、またはTARPルータ122~127でよい。各TARPトランシーバ405において、ネットワークIP層から通常のパケットを受信し、ネットワークを介して伝達できるTARPパケットを生成する送信側プロセスが生成される。TARPパケットを含む通常のIPパケットを受信し、このIPパケットから、ネットワークIP層に渡される通常のIPパケットを生成する受信側プロセスが生成される。TARPトランシーバ405がルータである場合、受信されたTARPパケット140は、適切なTARPパケットとして認証され、次いで他のTARPルータまたはTARP着信先端末110に渡されるだけでよいので、IPパケット415のストリームとして処理されないことに留意されたい。介入するプロセス、すなわちTARP層420をデータリンク層430またはネットワーク層410と組み合わせることができる。いずれの場合も、このプロセスは、埋め込まれたTARPパケットを含む正規のIPパケットを受信し、一連の組立て直されたIPパケットをネットワーク層410に渡すようにデータリンク層430に介入する。TARP層420をデータリンク層430と組み合わせる例として、プログラムによって、通信カード、たとえばイーサネット登録商標カードを実行する通常のプロセスを拡張することができる。あるいは、TARP層プロセスは、動的にロード可能なモジュールの、ロードされネットワーク層とデータリンク層の間の通信をサポートするように実行される部分を形成することができる。上述の暗号化システムはデータリンク層とネットワーク層との間に挿入することができるので、暗号化された通信をサポートするうえで使用されるプロセスは、IPネットワーク層以上でのプロセスに対して完全に透過的であってよい。TARPプロセスは、データリンク層に対しても完全に透過的であってよい。したがって、ネットワーク層以上での動作も、データリンク層以下での動作も、TARPスタックを挿入することの影響を受けない。これにより、たとえば、ハッカーによるネットワーク層への許可されないアクセスの困難さが大幅に増大するので、ネットワーク層以上でのすべてのプロセスに追加のセキュリティがもたらされる。セッション層で実行される新たに開発されたサーバの場合でも、セッション層よりも下のすべてのプロセスが侵害される可能性がある。このアーキテクチャでは、セキュリティが分散されることに留意されたい。すなわち、たとえば、移動中の管理職によって使用されるノートブックコンピュータは、セキュリティを損なうことなくインタネットを介して通信することができる。TARP端末およびTARPルータによるIPアドレス変更は、一定の間隔または無作為の間隔で行うことも、あるいは侵入が検出されたときに行うこともできる。IPアドレスを変更することにより、どのコンピュータが通信しているかを知ることのできるトラフィック分析が抑制され、侵入に対するある程度の保護ももたらされる。侵入に対する保護の程度は、ホストのIPアドレスが変更される率にほぼ比例する。前述のように、IPアドレスは侵入に応答して変更することができる。たとえば、ルータがある方法で調べられていることを示す組織だった一連のメッセージによって、侵入を知ることができる。侵入が検出されると、TARP層プロセスは、そのIPアドレスを変更することによってこのイベントに応答することができる。TARPプロセスは、これを行うために、一例としてインタネット制御メッセージプロトコルICMPデータグラムの形式で、TARPフォーマットのメッセージを構成する。このメッセージは、マシンのTARPアドレス、マシンの前のIPアドレス、およびマシンの新しいIPアドレスを含む。TARP層は、このパケットを少なくとも1つの既知のTARPルータに送信し、このTARPルータは、メッセージを受信し、その妥当性を確認した後、前述のTARPアドレスの新しいIPアドレスでルータ自体のLUTを更新する。TARPルータは次いで、同様なメッセージを作成し、他のTARPルータがLUTを更新できるようにそれらのTARPルータにこのメッセージをブロードキャストする。所与のサブネット上のTARPルータの総数は比較的小さいことが予期されるので、この更新プロセスは比較的高速であるべきである。しかし、このプロセスは、比較的小数のTARPルータおよび/または比較的多数のクライアントがあるときにはうまく作用しないことがある。このため、このアーキテクチャはスケーリング可能性を実現するように改良されている。この改良によって、後述の第2の態様が得られた。TARPプロセスは、侵入を検出したときに、最初のIPアドレスを維持し、侵入者との対話を続けるサブプロセスを作成することもできる。この対話によって、侵入者を追跡するか、あるいは侵入者の方法を研究する機会を得ることができる金魚鉢のことを海と考えているが、実際には捕えられ観察されている金魚鉢内の小さな魚にたとえてフィッシュボウリングと呼ばれる。侵入者と破棄されたフィッシュボウルされたIPアドレスとの間の通信の履歴を、人間が分析できるように記録または送信するか、あるいはある方法で応答するためにさらに合成することができる。上述のように、TARP端末またはTARPルータによって発信データにデコイまたはダミーデータまたはパケットを付加することができる。このようなデコイパケットは、より多くの別々のパケットにデータを好都合に分散するだけでなく、トラフィック分析の試みを無効にする助けになるようにインタネットのイナクティブ部分上の付加を均一にすることもできる。デコイパケットは、アルゴリズムによって決定されるある基準に従って各TARP端末100、110または各ルータ122~127によって生成することができる。たとえば、アルゴリズムは、端末がアイドル状態であるときに無作為にパケットを生成することを要求するランダムアルゴリズムでよい。あるいは、アルゴリズムは、時間または低トラフィックの検出に応答して低トラフィック時により多くのデコイパケットを生成することができる。パケットが好ましくは、1つずつ生成されるのではなく、実際のメッセージをシミュレートするようなサイズのグループとして生成されることに留意されたい。また、デコイパケットを通常のTARPメッセージストリームに挿入できるように、バックグラウンドループは、メッセージストリームが受信されているときにデコイパケットを挿入する可能性を高くするラッチを有することができる。すなわち、一連のメッセージが受信されるときに、デコイパケット生成率を高めることができる。あるいは、多数のデコイパケットが正規のTARPパケットと共に受信される場合、アルゴリズムは、これらのデコイパケットを転送するのではなくそれらを除去する率を高くすることができる。このようにデコイパケットを除去し生成すると、見掛けの着信メッセージサイズが見掛けの発信メッセージサイズと異なるものになり、トラフィック分析を無効にすることができる。デコイパケットであるか、それとも他のパケットであるかにかかわらず、パケットの受信率を、ペリッシャブルデコイ正規パケットカウンタを通してデコイパケット除去プロセスおよびデコイパケット生成プロセスに示すことができる。ぺリッシャブルカウンタは、急速に連続して増分されたときに大きな値を含み、低速で増分されるかあるいは少ない回数だけ急速に連続して増分されたときには小さな値を含むように時間に応答して値をリセットまたは減分するカウンタである。着信先TARP端末110が、単にパケットをルーティングしており、したがって、着信先端末でないように見えるように、受信されたTARPパケットと数およびサイズの等しいデコイパケットを生成できることに留意されたい。図5を参照するとわかるように、TARPパケットをルーティングする上述の方法で以下の特定のステップを使用することができる。S0デコイIPパケットの生成を決定するアルゴリズムを適用するバックグラウンドループ動作が実行される。このループは、暗号化されたTARPパケットが受信されたときに割り込まれる。S2TARPパケットを、リンク鍵を使用して復号することを試みる前に、何らかの方法で調べて認証することができる。すなわち、ルータは、ペイロードに含まれる暗号化されたTARPパケットに付加された平文IPヘッダと共に含まれるあるデータに対して選択された動作を実行することによって、パケットが真正なTARPパケットであることを判定することができる。これによって、真正なTARPパケットではないパケットに復号を実行することを避けることが可能になる。S3TARPパケットが復号され、着信先TARPアドレスと、このパケットがデコイパケットであるか、それとも実際のメッセージの一部であるかが明らかになる。S4このパケットがデコイパケットである場合、ペリッシャブルデコイカウンタが増分される。S5ルータは、デコイ生成/除去アルゴリズムおよびペリッシャブルデコイカウンタ値に基づいて、パケットがデコイパケットである場合には、それを破棄することを選択することができる。受信されたパケットがデコイパケットであり、これを破棄すべきであると判定された場合S6、制御はステップS0に戻る。S7TARPヘッダのTTLパラメータが減分され、TTLパラメータがゼロより大きいかどうかが判定される。S8TTLパラメータがゼロよりも大きい場合、ルータによって維持されているTARPアドレスのリストからTARPアドレスが無作為に選択され、このTARPアドレスに対応するリンク鍵およびIPアドレスが、このTARPパケットを含む新しいIPパケットを作成する際に使用できるように記憶される。S9TTLパラメータがゼロ以下である場合、着信先のTARPアドレスに対応するリンク鍵およびIPアドレスが、このTARPパケットを含む新しいIPパケットを作成する際に使用できるように記憶される。S10TARPパケットが、記憶されたリンク鍵を使用して暗号化される。S11記憶されたIPアドレスを含むパケットにIPヘッダが付加され、暗号化されたTARPパケットがIPヘッダで覆われ、完成したパケットが次のホップまたは着信先に送信される。図6を参照するとわかるように、TARPパケットを生成する上述の方法では以下の特定のステップを使用することができる。S20バックグラウンドループ動作が、デコイIPパケットの生成を決定するアルゴリズムを適用する。このループは、IPパケットを含むデータストリームが、後で送信できるように受信されたときに割り込まれる。S21受信されたIPパケットが、一定のIP着信先アドレスを有するメッセージから成る集合としてグループ化される。この集合はさらに、インタリーブウインドウの最大サイズに一致するように分割される。集合が暗号化されインタリーブされ、TARPパケットになる予定の1組のペイロードが得られる。S22IPアドレスに対応するTARPアドレスが、参照テーブルから判定され、TARPヘッダを生成するために記憶される。初期TTLカウントが生成され、ヘッダに格納される。TTLカウントは、最小値および最大値を有する無作為の値でも、あるいは一定の値でもよく、あるいは他の何らかのパラメータによって決定することができる。S23ウインドウシーケンス番号およびインタリーブシーケンスが各パケットのTARPヘッダに記録される。S24各TARPパケットごとに1つのTARPルータアドレスが無作為に選択され、このアドレスに対応するIPアドレスが、平文IPヘッダで使用できるように記憶される。このルータに対応するリンク鍵が識別され、インタリーブされ暗号化されたデータおよびTARPヘッダを含むTARPパケットが、このリンク鍵を使用して暗号化される。S25第1のホップルータの実際のIPアドレスを有する平文IPヘッダが生成され、暗号化されたTARPパケットおよび結果として得られるパケットのそれぞれに付加される。図7を参照するとわかるように、TARPパケットを受信する上述の方法で以下の特定のステップを使用することができる。S40デコイIPパケットの生成を決定するアルゴリズムを適用するバックグラウンドループ動作が実行される。このループは、暗号化されたTARPパケットが受信されたときに割り込まれる。S42TARPパケットが、リンク鍵を使用して復号される前に、調べられ認証される。S43TARPパケットが適切なリンク鍵を用いて復号され、着信先TARPアドレスと、このパケットがデコイパケットであるか、それとも実際のメッセージの一部であるかが明らかになる。S44このパケットがデコイパケットである場合、ペリッシャブルデコイカウンタが増分される。S45受信側は、デコイ生成/除去アルゴリズムおよびペリッシャブルデコイカウンタ値に基づいて、パケットがデコイパケットである場合には、それを破棄することを選択することができる。S46インタリーブウインドウを形成するすべてのパケットが受信されるまでTARPパケットがキャッシュされる。S47インタリーブウインドウのすべてのパケットが受信された後、パケットがインタリーブ解除される。S48次いで、インタリーブウインドウを形成する組み合わされた各パケットのパケットブロックが、セッション鍵を使用して復号される。S49次いで、復号されたブロックが、ウインドウシーケンスデータを使用して分割され、IPrヘッダが通常のIPCヘッダに変化される。ウインドウシーケンス番号がIPCヘッダに組み込まれる。S50次いで、パケットがIPレイヤプロセスに渡される。スケーリング可能性の向上上述のIPアジリティ機能は、IPアドレスの変更をすべてのTARPルータに送信する能力に依存する。この機能を含む各態様は、インタネットなど大規模なネットワーク向けにこのような機能をスケーリングする際の潜在的な制限のためにブティック態様と呼ばれる。しかし、ブティック態様は、たとえば、小規模な仮想専用網など小規模なネットワークで使用する場合にはロバストである。ブティック態様の1つの問題は、IPアドレスの変更が頻繁に行われる場合、すべてのルータを十分に高速に更新するのに必要なメッセージトラフィックのために、TARPルータおよび/またはクライアントの数が非常に多くなるとインタネットに大きな負荷が掛かる。すべてのTARPルータを更新するために使用される帯域幅負荷であって、たとえばICMPパケットにおいてネットワークに加わる帯域幅負荷は、インタネットのスケールに近い大規模なインプリメンテーションの場合にインタネットの能力を超える可能性がある。言い換えれば、ブティックシステムのスケーリング可能性は限られている。追加的なメッセージ負荷なしにIPアジリティの利益をもたらすように上記の態様の特徴のうちのいくつかの兼合いを取るシステムを構成することができる。これは、TARPノードなどのノード間の通信セッションに参加しているリンク間で使用されるIPアドレスを管理する共用アルゴリズムに従ってIPアドレスホッピングによって行われる。IPホッピング技法をブティック態様に適用することもできることに留意されたい。ブティックシステムに関して論じたIPアジリティ機能は、スケーリング可能なこの方式の下で分散され、かつ上述の共用アルゴリズムによって管理されるように修正することができる。ブティックシステムの他の機能をこの新しい種類のIPアジリティrと組み合わせることができる。この新しい態様は、通信する各ノードペアによって交換されるローカルアルゴリズムおよび1組のIPアドレスによって管理されるIPアジリティをもたらすという利点を有する。このローカル管理は、直接通信するノードペア間で転送されるセッションまたはエンドポイントにかかわらず、ノードペア間の通信を管理できるという点でセッションに依存しない。スケーリング可能なこの態様では、ネットワーク内の各ノードにIPアドレスのブロックが割り付けられる。このスケーリング可能性は、将来において、インタネットプロトコルアドレスが128ビットフィールドに増加し、明確にアドレス可能なノードの数が大幅に増加したときに高くなる。したがって、各ノードは、そのノードに割り当てられたIPアドレスのいずれかを使用してネットワーク内の他のノードと通信することができる。実際には、通信する各ノードペアは複数の送信元IPアドレスおよび着信先IPアドレスを使用して互いに通信することができる。任意のセッションに参加しているチェーン内の通信する各ノードペアは、ネットブロックと呼ばれる2つのIPアドレスブロックと、アルゴリズムと、次のメッセージを送信するために使用される次の送信元/着信先IPアドレスペアを各ネットブロックごとに選択するための無作為化シードとを記憶する。言い換えれば、このアルゴリズムは、各ネットブロックからのIPアドレスペア、1つの送信側IPアドレス、および1つの受信側IPアドレスの順次選択を管理する。アルゴリズムと、シードと、ネットブロックIPアドレスブロックの組合せをホップブロックと呼ぶ。ルータは別々の送信ホップブロックおよび受信ホップブロックをルータのクライアントに発行する。クライアントによって送信される各発信パケットのIPヘッダの送信アドレスおよび受信アドレスには、アルゴリズムによって管理される送信IPアドレスおよび受信IPアドレスが充填される。アルゴリズムは、ペアが使用されるたびに、アルゴリズムが次に送信すべきパケット用の新しい送信ペアを作成するように、カウンタによってクロッキングインデックス付けされる。ルータの受信ホップブロックはクライアントの送信ホップブロックと同一である。ルータは、このクライアントからの次に予期されるパケット用の送信IPアドレス受信IPアドレスペアが何であるかを、受信ホップブロックを使用して予想する。各パケットは順序正しく受信されないことがあるので、ルータが、次の順次パケット上にどんなIPアドレスが来るかを確実に予想することは不可能である。ルータは、この問題を考慮して、次に受信されるパケットの後に続く可能性のある送信パケット送信/受信アドレスの数を包含するある範囲の予想を生成する。したがって、所与のパケットが、その前にクライアントによって送信された5つのパケットよりも前にルータに到着する可能性が非常に低い場合、ルータは、次に受信されるパケットと比較すべき一連の6つの送信/受信IPアドレスペアまたはホップウインドウを生成することができる。パケットが受信されると、このパケットは、受信されたものとしてホップウインドウ内にマーク付けされ、したがって、同じIPアドレスペアを有する第2のパケットは破棄される。シーケンスからずれたパケットが所定のタイムアウト期間内に到着しない場合、その通信セッションに使用されているプロトコルに応じ、あるいは場合によっては規約によって、そのパケットを再送信することを要求するか、あるいは単に受信テーブルから破棄することができる。ルータは、クライアントのパケットを受信すると、パケットの送信IPアドレスおよび受信IPアドレスを、予想される次のN個の送信IPアドレス受信アドレスペアと比較し、パケットがこの集合のメンバーではない場合、パケットを拒絶する。ウインドウに収まった予想される送信元/着信先IPアドレスを有さない受信パケットは拒絶され、したがって、可能なハッカーは妨害される。可能な組合せの数を用いた場合、かなり大きなウインドウであっても無作為にこの中に収めることは困難である。パケットがこの集合のメンバーである場合、ルータはパケットを受け入れ、さらに処理する。リンクベースのこのIPホッピング方式は、IHOPと呼ばれ、独立しており、必ずしも上述のブティックシステムの要素を伴わないネットワーク要素である。ブティック態様に関して説明したルーティングアジリティ機能をこのリンクベースIPホッピング方式と組み合わせた場合、ルータの次のステップは、TARPヘッダを復号して、パケットの着信先TARPルータを判定し、かつパケットの次のホップを何にすべきかを判定することである。TARPルータは次いで、無作為のTARPルータにパケットを転送するか、あるいは送信先ルータがリンクベースのIPホッピング通信を確立させる着信先TARPルータにパケットを転送する。図8は、クライアントコンピュータ801およびTARPルータ811が安全なセッションを確立するにはどうすべきかを示している。クライアント801は、TARPルータ811とのHOPセッションを確立する際、TARPルータ811に安全同期要求SSYNパケット821を送信する。このSYNパケット821は、クライアント811の認証トークンを含み、暗号化フォーマットでルータ811に送信することができる。パケット821上の送信先IP番号および着信先IP番号は、クライアント801の現在の固定IPアドレスおよびルータ811の既知の固定IPアドレスである。セキュリティのために、着信先がルータの既知の固定IPアドレスである、ローカルネットワークの外部からのあらゆるパケットを拒絶することが望ましい。ルータ811は、クライアント801のSSYNパケット821を受信し、妥当性を確認した後、暗号化された安全同期確認応答SSYNACK822をクライアント801に送信することによって応答する。このSSYNACK822は、クライアント801がTARPルータ811と通信するときに使用する送信ホップブロックおよび受信ホップブロックを含む。クライアント801は、その固定IPアドレスからTARPルータ811の既知の固定IPアドレスに送信される暗号化されたSSYNACKACKパケット823を生成することによって、TARPルータ811の応答パケット822で確認応答する。クライアント801は、SSYNACKACKパケットを同時に生成する。このSSYNACKパケットは、安全セッション初期設定SSIパケット824と呼ばれ、TARPルータ811によってSSYNACKパケット822内に与えられる送信ホップブロックに指定される、クライアントの送信テーブル921図9内の第1の{送信側、受信側}IPペアと共に送信される。TARPルータ811は、TARPルータの送信テーブル923内の第1の{送信側、受信側}IPペアと共に送信されるSSIACKパケット825を用いてSSIパケット824に応答する。これらのパケットが首尾良く交換された後、安全な通信セッションが確立され、クライアント801とTARPルータ811との間の他のすべての安全な通信は、同期が維持されるかぎり、この安全なセッションを介して行われる。同期が失われた場合、クライアント801およびTARPルータ802は、図8に概略的に示し上記で説明した手順によって安全なセッションを再確立することができる。安全なセッションがアクティブであるとき、クライアント901とTARPルータ911図9は共に、セッション同期822中にTARPルータから与えられるそれぞれの送信テーブル921、923および受信テーブル922、924を維持する。クライアントの送信テーブル921内のIPペアのシーケンスがTARPルータの受信テーブル924内のIPペアのシーケンスと同一であることが重要である。同様に、クライアントの受信テーブル922内のIPペアのシーケンスはルータの送信テーブル923内のIPペアのシーケンスと同一でなければならない。このことはセッション同期を維持するうえで必要である。クライアント701は、安全なセッションの間1つの送信テーブル921および1つの受信テーブル922のみを維持する必要がある。クライアント901によって送信される各順次パケットは、TCPセッションであるか、それともUDPセッションであるかにかかわらず、送信テーブル内の次の{送信側、受信側}IPアドレスペアを使用する。TARPルータ911は、クライアント911から到着する各パケットが受信テーブル内に示された次のIPアドレスを保持していることを予期する。しかし、パケットは順序正しく到着しないことがあるので、ルータは受信テーブル内にルックアヘッドバッファを維持することができ、すでに受信されているIPペアを未来のパケットに対して無効なIPペアとしてマーク付けする。IPルックアヘッドバッファ内に存在するが、受信済みIPペアとしてマーク付けされているIPペアを含む未来のパケットは破棄される。TARPルータ911からクライアント901への通信も同様に維持される。特に、ルータ911は、クライアント901に送信すべきパケットを構成する際にルータ911の送信テーブル923から次のIPアドレスペアを選択し、クライアント901は、それが受信するパケット上の予期されるIPペアのルックアヘッドバッファを維持する。各TARPルータは、そのTARPルータとの安全なセッションを行っているか、あるいはそのTARPルータを通して安全なセッションを行っている各クライアントごとに別々の送信テーブル受信テーブルペアを維持する。クライアントは、それをインタネットにリンクするクライアントのホップブロックを第1のサーバから受信し、それに対して、ルータはホップブロックを交換する。ルータが他のルータとのリンクベースのIPホッピング通信方式を確立すると、ペア交換の各ルータはその送信ホップブロックを交換する。各ルータの送信ホップブロックは他方のルータの受信ホップブロックになる。ルータ間の通信は、クライアントが第1のルータにパケットを送信する例で説明したように管理される。上記の方式はIP環境でうまく作用するが、インタネットに接続される多くのローカルネットワークはイーサネット登録商標システムである。イーサネット登録商標では、既知のプロセスアドレス分解プロトコルおよび逆アドレス分解プロトコルを使用して着信先装置のIPアドレスをハードウェアアドレスに変換しなければならず、その逆もまた同様である。しかし、リンクベースのIPホッピング方式を使用する場合、相関プロセスが厄介なものになる。リンクベースのIPホッピング方式の代替態様はイーサネット登録商標ネットワーク内で使用することができる。この解決策では、インタネットをイーサネット登録商標にリンクするノードボーダーノードと呼ぶが、リンクベースのIPホッピング通信方式を使用してイーサネット登録商標LANの外部のノードと通信できるようにする。イーサネット登録商標LAN内で、各TARPノードは、従来どおりにアドレス指定される単一のIPアドレスを有する。LAN内TARPノードは、{送信側、受信側}IPアドレスペアを比較してパケットを認証するのではなく、1つのIPヘッダ拡張フィールドを使用してパケットを認証する。したがって、ボーダーノードは、LAN内TARPノードによって共用されるアルゴリズムを使用して、IPヘッダ内の空きフィールドに格納される記号を生成し、LAN内TARPノードは、この特定の送信元IPアドレスから次に受信されることが予期されるパケットについてのノード自体の予想に基づいてある範囲の記号を生成する。パケットは、予想される記号たとえば、数値の集合内に収まらない場合には拒絶され、収まった場合には受け入れられる。LAN内TARPノードからボーダーノードへの通信も同様に行われる。ただし、セキュリティ上の理由で、アルゴリズムは必然的に異なる。したがって、各通信ノードは、図9と同様に送信テーブルおよび受信テーブルを生成する。すなわち、LAN内TARPノードの送信テーブルはボーダーノードの受信テーブルと同一であり、LAN内TARPノードの受信テーブルはボーダーノードの送信テーブルと同一である。IPアドレスホッピングに使用されるアルゴリズムは任意の所望のアルゴリズムでよい。たとえば、アルゴリズムは、所与のシードを有する許可されたIPアドレスをカバーする範囲の番号を生成する擬似乱数生成プログラムでよい。あるいは、セッション参加者が、ある種のアルゴリズムを仮定し、単にそのアルゴリズムを適用するためのパラメータを指定することができる。たとえば、仮定されるアルゴリズムは特定の擬似乱数生成プログラムでよく、セッション参加者は単にシード値を交換することができる。発信元端末ノードと着信先端末ノードとの間に永久的な物理的な違いはないことに留意されたい。いずれのエンドポイントのいずれの装置もペアの同期を開始することができる。別々のメッセージ交換が必要にならないように認証/同期要求および確認応答およびホップブロック交換がすべて単一のメッセージによって実行できることにも留意されたい。前述のアーキテクチャの他の拡張態様として、リンク冗長性を実現し、さらに、サービスを拒否する試みおよびトラフィック監視を妨げるために、クライアントによって複数の物理パスを使用することができる。図10に示すように、たとえば、クライアント1001は、それぞれの異なるISP1011、1012、1013から与えられる3つのTARPルータのそれぞれとの3つの同時セッションを確立することができる。一例として、クライアント1001は3つの異なる電話回線1021、1022、1023や2つの電話回線およびケーブルモデムなどを使用してISPに接続することができる。この方式では、送信されるパケットが様々な物理パスの間で無作為に送信される。このアーキテクチャは高度の通信冗長性を実現し、サービス拒否アタックおよびトラフィック監視に対する保護を向上させる。他の拡張態様以下に、上述の技法、システム、および方法の様々な拡張態様について説明する。上述のように、コンピュータネットワークインタネット、イーサネット登録商標など内のコンピュータ間で行われる通信のセキュリティは、ネットワークを介して送信されるデータパケットの、見掛け上無作為の送信元インタネットプロトコルIPアドレスおよび着信先IPアドレスを使用することによって向上させることができる。この機能は、盗聴者が、ネットワーク内のどのコンピュータが通信しているかを判定するのを妨げ、同時に、通信している2つのコンピュータが、受信された所与のデータパケットが正当なパケットであるか否かを容易に認識できるようにする。上述のシステムの一態様では、IPヘッダ拡張フィールドを使用してイーサネット登録商標上の着信パケットが認証される。本明細書で説明する前述の技法の様々な拡張態様には、1ホップされるハードウェアまたはMACアドレスをブロードキャスト型ネットワークで使用すること、2コンピュータが送信側との同期を自動的に回復できるようにする自己同期技法、3送信側コンピュータおよび受信側コンピュータがパケット喪失イベントまたはその他のイベントの場合に同期を迅速に再確立できるようにする同期アルゴリズム、および4無効なパケットを拒絶する高速パケット拒絶機構が含まれる。これらの拡張態様のいずれかまたはすべてを様々な方法のいずれかで上述の機能と組み合わせることができる。A.ハードウェアアドレスホッピングLAN上のインタネットプロトコルベース通信技法または任意の専用物理媒体を介したインタネットプロトコルベース通信技法では通常、フレームと呼ばれることの多い下位パケット内にIPパケットが埋め込まれる。図11に示すように、たとえば、第1のイーサネット登録商標フレーム1150はフレームヘッダ1101および埋め込まれた2つのIPパケットIP1およびIP2を備え、それに対して、第2のイーサネット登録商標フレーム1160は異なるフレームヘッダ1104および単一のIPパケットIP3を備えている。各フレームヘッダは一般に、送信元ハードウェアアドレス1101Aおよび着信先ハードウェアアドレス1101Bを含む。図11では、図を明確にするためにフレームヘッダ内の他の公知のフィールドは省略されている。物理通信チャネルを介して通信する2つのハードウェアノードは、チャネルまたはネットワーク上のどのノードがフレームを受信すべきかを示す適切な送信元ハードウェアアドレスおよび着信先ハードウェアアドレスを挿入する。悪意ある盗聴者が、IPパケット自体ではなくあるいはそれに加えてローカルネットワーク上のフレームを調べることによって、フレームの内容および/またはそのフレームの通信者に関する情報を得ることが可能である。このことは、フレームを生成したマシンのハードウェアアドレスおよびフレームが送信されるマシンのハードウェアアドレスをフレームヘッダに挿入する必要がある、イーサネット登録商標などのブロードキャスト媒体に特に当てはまる。ネットワーク上のすべてのノードは場合によっては、ネットワークを介して送信されるすべてのパケットを見ることができる。これは、特に、情報交換を行っているのは誰かを第三者が識別できることを通信者が望んでいない場合に、安全な通信に対する問題となる恐れがある。この問題に対処する1つの方法は、アドレスホッピング方式をハードウェア層に拡張することである。本発明の様々な態様によれば、ハードウェアアドレスは、IPアドレスを変更するために使用される方法と同様な方法でホップされ、したがって、盗聴者は、特定のメッセージを生成したのはどのハードウェアノードであるかを判定することも、あるいは所期されている受信側はどのノードであるかを判定することもできない。図12Aは、イーサネット登録商標などのネットワーク上のセキュリティを向上させるために媒体アクセス制御MACハードウェアアドレスがホップされるシステムを示している。この説明ではイーサネット登録商標環境の例示的なケースを引用するが、本発明の原則は他の種類の通信媒体にも同様に適用することができる。イーサネット登録商標の場合、送信側および受信側のMACアドレスは、イーサネット登録商標フレームに挿入され、そのフレームのブロードキャスト範囲内にいるLAN上のあらゆる人によって見ることができる。安全な通信を実現する場合、特定の送信側や受信側に帰属しないMACアドレスを持つフレームを生成することが望ましくなる。図12Aに示すように、コンピュータノード1201および1202はイサーネットなどの通信チャネルを介して通信する。各ノードは、それぞれ通信ソフトウェア1204および1217によりパケットを送信することによって通信する1つまたは複数のアプリケーションプログラム1203および1218を実行する。アプリケーションプログラムの例にはビデオ会議、eメール、文書処理プログラムなどが含まれる。通信ソフトウェア1204および1217は、たとえば、様々な機能レベルで実現される様々なサービスを標準化するOSI層化アーキテクチャまたはスタックを備えることができる。通信ソフトウェア1204および1217の最下位レベルはそれぞれ、ハードウェア構成要素1206および1214と通信し、各構成要素は、様々な通信プロトコルに従ってハードウェアを再構成または制御できるようにする1つまたは複数のレジスタ1207および1215を含むことができる。ハードウェア構成要素たとえば、イーサネット登録商標ネットワークインタフェースカードは通信媒体を介して互いに通信する。各ハードウェア構成要素には通常、そのハードウェア構成要素をネットワーク上の他のノードへに対して識別する固定ハードウェアアドレスまたはMAC番号が事前に割り当てられる。以下に詳しく説明するように、本発明の原則の様々な態様は、1つまたは複数のアルゴリズムと、受信されたパケットの妥当性を確認するためにある範囲の妥当なアドレスを追跡する1つまたは複数の移動ウインドウを使用して、様々なアドレスのホッピングを可能にする。本発明の1つまたは複数の原則に従って送信されるパケットは一般に、マシンによって相関付けされた通常のアドレスを使用して平文で送信される通常のデータパケットと区別するために安全なパケットまたは安全な通信と呼ばれる。帰属不能なMACアドレスを生成する1つの簡単な方法はIPホッピング方式の拡張態様である。この場合、同じLAN上の2つのマシンは、安全に通信して乱数発生プログラムおよびシードを交換し、同期式ホッピングのための準無作為MACアドレスのシーケンスを作成する。この場合、インプリメンテーションおよび同期の問題はIPホッピングの同じ問題と類似している。しかし、この手法では、LAN上で現在アクティブなMACアドレスが使用される恐れがあり、それによって、これらのマシンの通信が中断される可能性がある。イーサネット登録商標MACアドレスが現在の所、長さが48ビットであるので、アクティブなMACアドレスが無作為に乱用される可能性は実際には極めて低い。しかし、この数字に広範囲のLANで見られるような多数のノードの数、パケット音声またはストリーミングビデオの場合のような多数のフレームの数、および多数の並行仮想専用網VPNの数を乗じた場合、アドレスホッピングされるフレームで安全でないマシンのMACアドレスが使用される可能性は無視できないものになる。簡単に言えば、LAN上の他のマシンの通信を中断する可能性が少しでもあるあらゆる方式は、先見の明のあるシステム管理者から反対を受ける。それにもかかわらず、これは技術的に実施可能であり、マシンの数が少ないLAN上で安全に実施することができ、あるいはLAN上のすべてのマシンがMACホップ通信を行う場合に安全に実施することができる。同期式MACアドレスホッピングは、セッションを確立する際、特に通信に関与する複数のセッションまたは複数のノードがある場合、ある程度のオーバヘッドを伴うことがある。MACアドレスを無作為化するより簡単な方法は、各ノードがネットワーク上で発生したあらゆるフレームを受信し処理できるようにすることである。通常、各ネットワークインタフェースドライバは、発生したあらゆるフレームのヘッダ内の着信先MACアドレスを検査し、そのマシンのMACアドレスに一致するかどうかを調べる。一致しない場合、このフレームは破棄される。しかし、一態様では、これらの検査を無効化することができ、発生したあらゆるパケットがTARPスタックに渡され処理される。これは、発生したあらゆるフレームが処理されるのでプロミスキュアスモードと呼ばれる。プロミスキュアスモードでは、着信先マシンがフレームを確実に処理できるので、送信側は、同期の取れていない完全に無作為のMACアドレスを使用することができる。パケットの着信先が本当にそのマシンであるかどうかに関する決定はTARPスタックによって処理され、TARPスタックは、送信元IPアドレスと着信先IPアドレスがTARPスタックのIP同期テーブルにおいて一致しているかどうかを検査する。一致が見つからない場合、このパケットは破棄される。一致した場合、パケットが開放され、インナヘッダが評価される。パケットの着信先がこのマシンであることをインナヘッダが示している場合、パケットがIPスタックに転送され、そうでない場合、パケットは破棄される。純粋に無作為のMACアドレスホッピングの1つの欠点は、処理オーバヘッドに対するこのホッピングの影響である。すなわち、発生したあらゆるフレームを処理しなければならないので、ネットワークインタフェースドライバがパケットを一方的に区別し拒絶する場合よりもかなり頻繁にマシンのCPUが使用される。妥協的な手法として、メッセージの着信先である実際の受信側にかかわらず、MACホップ通信に使用すべきアドレスとして単一の固定MACアドレスまたは少数のMACアドレスたとえば、イーサネット登録商標上の各仮想専用網ごとに1つのMACアドレスを選択する手法がある。このモードでは、ネットワークインタフェースが、発生した各フレームを事前に確立された1つまたは少数のMACアドレスと突き合わせて検査することができ、それによって、CPUは物理層パケットの区別を行わなく済む。この方式では、LAN上の侵入者に重要な情報が漏れることがない。特に、アウタヘッダ内の固有のパケットタイプによってあらゆる安全なパケットを事前に識別しておくことができる。しかし、安全な通信を行うすべてのマシンが同じMACアドレスを使用するか、あるいは所定のMACアドレスの小さな集合から選択するので、特定のマシンと特定のMACアドレスとの間の関連付けが実際上、失われる。この方式では、ネットワークインタフェースドライバが、このマシンを着信先とする安全なパケットと他のVPNからの安全なパケットを常に一方的に区別することはできないので、CPUは、安全でない通信または同期式MACアドレスホッピングの場合よりも頻繁に使用される。しかし、ネットワークインタフェースにおいて安全でないトラフィックをなくすのは容易であり、したがって、CPUに必要な処理の量が少なくなる。これらが当てはまらない境界条件があり、たとえば、LAN上のすべてのトラフィックが安全なトラフィックである場合、CPUは純粋に無作為のアドレスホッピングの場合と同じ程度に使用される。あるいは、LAN上の各VPNが異なるMACアドレスを使用する場合、ネットワークインタフェースは、ローカルマシンを着信先とする安全なフレームを、他のVPNを構成する安全なフレームと完全に区別することができる。これらは技術上の兼ね合せであり、ユーザがソフトウェアをインストールし、かつ/またはVPNを確立する際に管理オプションを与えることによって最もうまく処理することができる。しかし、この場合でも、LAN上の1つまたは複数のノードによって使用されるMACアドレスが選択されるわずかな可能性が依然として残る。この問題に対する1つの解決策として、MACホップ通信で使用される1つのアドレスまたはある範囲のアドレスが公式に割り当てられる。これは通常、割当て番号登録権限を介して行われ、たとえば、イーサネット登録商標の場合、電気電子技術者協会IEEEによってベンダにMACアドレス範囲が割り当てられている。公式に割り当てられるアドレス範囲によって、安全なフレームはLAN上の適切に構成され適切に機能するマシンに確実に適合する。次に、本発明の原則に従った多数の組合せおよび特徴について説明するために図12Aおよび図12Bを参照する。上述のように、2つのコンピュータノード1201および1202がイーサネット登録商標などのネットワークまたは通信媒体を介して通信しているものと仮定する。各ノードの通信プロトコルそれぞれ、1204および1217は、標準通信プロトコルから導かれるある機能を実行する修正された要素1205および1216を含む。特に、コンピュータノード1201は、各パケットを他方のコンピュータノードに送信するために見掛け上無作為の送信元IPアドレスおよび着信先IPアドレスおよび一態様では、見掛け上無作為のIPヘッダディスクリミネータフィールドを選択する第1のホップアルゴリズム1208Xを実施する。たとえば、ノード1201は、送信先S、着信先D,および発信IPパケットヘッダに挿入されるディスクリミネータフィールドDSの3つ組を含む送信テーブル1208を維持する。このテーブルは、受信側ノード1202に知られている適切なアルゴリズムたとえば、適切なシードを用いてシードされる乱数生成プログラムを使用することによって生成される。新しい各IPパケットが形成される際、送信側の送信テーブル1208の順次エントリを使用してIP送信元、IP着信先、およびIPヘッダ拡張フィールドたとえば、ディスクリミネータフィールドが埋められる。送信テーブルを事前に作成しておく必要がなく、その代わり、動作時に、各パケットを形成する際にアルゴリズムを実行することによって作成できることが理解されよう。受信側ノード1202では、同じIPホップアルゴリズム1222Xが維持され、送信元IPアドレス、着信先IPアドレス、およびディスクリミネータフィールドの妥当な3つ組をリストした受信テーブル1222を、上記のアルゴリズムを使用して生成するために使用される。これは、送信テーブル1208の第1の5つのエントリが、受信テーブル1222の第2の5つのエントリに一致することによって示されている。各テーブルは、パケットの喪失、パケットの順序のずれ、または送信遅延のために任意の特定の時間にわずかにずれる可能性がある。また、ノード1202は、着信IPパケットの一部として受信されたときに受け入れられる妥当なIP送信元、IP着信先、およびディスクリミネータフィールドのリストを表す受信ウインドウW3を維持する。パケットが受信されると、ウインドウW3は妥当なエントリのリストを下にスライドさせ、したがって、可能な妥当なエントリは時間の経過と共に変化する。誤った順序で到着したが、それにもかかわらずウインドウW3内のエントリと一致している2つのパケットは受け入れられる。ウインドウW3に収まらないパケットは無効なパケットとして拒絶される。ウインドウW3の長さは、ネットワーク遅延またはその他の因子を反映する必要に応じて調整することができる。ノード1202は、場合によっては異なるホッピングアルゴリズム1221Xを使用して着信先がノード1201であるIPパケットおよびフレームを作成するために同様な送信テーブル1221を維持し、ノード1201は、同じアルゴリズム1209Xを使用して一致する受信テーブル1209を維持する。ノード1202が見掛け上無作為のIP送信先、IP着信先、および/またはディスクリミネータフィールドを使用してノード1201にパケットを送信すると、ノード1201は着信パケット値を、ノード1201の受信テーブルに維持されているウインドウW1内に収まる値と突き合わせる。実際には、ノード1201の送信テーブル1208と受信側ノード1202の受信テーブル1222との同期が取られるすなわち、同じ順序でエントリが選択される。同様に、ノード1202の送信テーブル1221とノード1201の受信テーブル1209との同期が取られる。図12Aでは送信元、着信先、およびディスクリミネータフィールドについて共通のアルゴリズムが示されているたとえば、3つのフィールドのそれぞれに異なるシードを使用するが、実際には、まったく異なるアルゴリズムを使用してこれらのフィールドのそれぞれの値を確立できることが理解されよう。図のように3つのフィールドすべてではなく1つまたは2つのフィールドをホップできることも理解されよう。本発明の他の態様によれば、ローカルエリアネットワークまたはブロードキャスト型ネットワーク内のセキュリティを向上させるために、IPアドレスおよび/またはディスクリミネータフィールドの代わりにあるいはそれらと共にハードウェアアドレスまたはMACアドレスがホップされる。この目的のために、ノード1201は、ノード1202にある対応する受信テーブル1224との同期が取られるフレームヘッダたとえば、図11のフィールド1101Aおよび1101Bに挿入される送信元ハードウェアアドレスおよび着信先ハードウェアアドレスを、送信アルゴリズム1210Xを使用して生成する、送信テーブル1210をさらに維持する。同様に、ノード1202は、ノード1201にある対応する受信テーブル1211との同期が取られる送信元ハードウェアアドレスおよび着信先ハードウェアアドレスを含む異なる送信テーブル1223を維持する。このように、発信ハードウェアフレームは、各受信側が、所与のパケットの着信先が該受信側であるかどうかを判定できるにもかかわらず、ネットワーク上の完全に無作為のノードから発信され、かつこのようなノードに送信されるように見える。ハードウェアホッピング機能をIPホッピング機能とは異なる通信プロトコルレベルでたとえば、性能を向上させるためにカードドライバまたはハードウェアカード自体で実施できることが理解されよう。図12Bは、前述の原則を用いて使用することのできる3つの異なる態様またはモードを示している。プロミスキュアスモードと呼ばれる第1のモードでは、ネットワーク上のすべてのノードによって共通のハードウェアアドレスたとえば、送信元用の固定アドレスおよび着信先用の別の固定アドレスまたは完全に無作為のハードウェアアドレスが使用され、したがって、特定のパケットを1つのノードに帰属させることはできなくなる。各ノードは最初、共通または無作為のハードウェアアドレスを含むすべてのパケットを受け入れ、IPアドレスまたはディスクリミネータフィールドを調べて、パケットの着信先がそのノードであるかどうかを判定しなければならない。なお、IPアドレスまたはディスクリミネータフィールド、あるいはその両方を上述のアルゴリズムに従って変更することができる。前述のように、この場合、所与のパケットが妥当な送信元ハードウェアアドレスおよび着信先ハードウェアアドレスを有するかどうかを判定する追加の処理が必要になるので、各ノードのオーバヘッドが増大する可能性がある。VPN当たりプロミスキュアスモードと呼ばれる第2のモードでは、少数の1組の固定ハードウェアアドレスが使用され、仮想専用網上で通信するすべてのノードに固定送信元/着信先ハードウェアアドレスが使用される。たとえば、イーサネット登録商標上に6つのノードがあり、1つのVPN上の各ノードがそのVPN上の他の2つのノードのみと通信できるようにネットワークが2つの専用仮想網に分割される場合、第1のVPN用の1組と第2のVPN用の第2の組の、2組のハードウェアアドレスを使用することができる。これにより、指定されたVPNから到着するパケットのみを検査すればよいので、妥当なフレームについての検査に必要なオーバヘッドの量が少なくなる。この場合も、VPN内で安全な通信を行えるように、前述のようにIPアドレスおよび1つまたは複数のディスクリミネータフィールドをホップすることができる。もちろん、この解決策では、VPNの匿名性は無効になるすなわち、トラフィックがどのVPNに属するものであるかを部外者が容易に知ることができる。ただし、部外者がそれを特定のマシン/人と相関付けることはできない。また、ディスクリミネータフィールドを使用してある種のDoSアタックを受ける可能性を低減させる必要もある。たとえば、ディスクリミネータフィールドがない場合、LAN上のアタッカーが、VPNによって使用されているMACアドレスを含むフレームのストリームを作成することが可能になる。このようなフレームを拒絶するには過度の処理オーバヘッドが必要になる恐れがあるディスクリミネータフィールドは、擬パケットを拒絶する低オーバヘッド手段を実現する。ハードウェアホッピングモードと呼ばれる第3のモードでは、図12Aに示すようにハードウェアアドレスが変更され、それによって、ハードウェア送信元アドレスおよびハードウェア着信先アドレスが常に変更され、アドレスは帰属不能になる。もちろん、これらの態様の変形態様が可能であり、本発明は、いかなる点においてもこれらの例によって制限されることはない。B.アドレス空間の拡張アドレスホッピングによってセキュリティおよびプライバシーが確保される。しかし、保護のレベルは、ホップされるブロック内のアドレスの数によって制限される。ホップブロックは、VPNを実現するためにパケットごとに調整されるフィールドを示す。たとえば、各ブロックが4つのアドレス2ビットから成るホップブロックを使用するIPアドレスホッピングを用いて2つのノードが通信する場合、16個の可能なアドレスペア組合せがある。サイズ16のウインドウの場合、大部分の時間において大部分のアドレスペアが妥当なペアとして受け入れられる。この制限は、ホップアドレスフィールドに加えてあるいはその代わりにディスクリミネータフィールドを使用することによって解消することができる。ディスクリミネータフィールドは、アドレスフィールドとまったく同じようにホップされ、パケットを受信側によって処理すべきかどうかを判定するために使用される。それぞれが4ビットホップブロックを使用する2つのクライアントが、2つのAブロック間のIPホッピングを介して通信するクライアントに与えられるのと同じ保護レベルを望んでいるものと仮定するホッピングに有効な24ビット。20ビットのディスクリミネータフィールドを、IPアドレスフィールドにおけるホッピングに有効な4アドレスビットと共に使用すると、この保護レベルが達成される。24ビットディスクリミネータフィールドは、アドレスフィールドがホップされず、また無視されない場合に同様な保護レベルを達成する。ディスクリミネータフィールドを使用すると、1任意に高い保護レベルを達成することができ、2アドレスホッピングなしで保護が実現されるという2つの利点が与えられる。これは、アドレスホッピングによってルーティングの問題が起こる環境で重要である。C.同期技法送信側ノードと受信側ノードがアルゴリズムおよびシードまたは準無作為送信元テーブルおよび準無作為着信先テーブルを生成するのに十分な同様な情報を交換した後、2つのノード間のその後の通信は円滑に進行するものと一般に仮定される。しかし、現実的には、2つのノードは、ネットワークの遅延または障害、あるいはその他の問題のために同期を失う可能性がある。したがって、ネットワーク内の、同期を失ったノード間に同期を再確立する手段を提供することが望ましい。ある可能な技法では、各ノードに、各パケットが首尾良く受信されたときに確認応答を供給させ、ある期間内に確認応答が受信されなかった場合に、非確認応答パケットを再送する。しかし、この手法は、オーバヘッドコストを増大させ、たとえば、ストリーミングビデオやストリーミングオーディオなどの高スループット環境では使用不能になる恐れがある。別の手法では、本明細書で自己同期と呼ぶ自動同期技法が使用される。この手法では、各パケットに同期情報が埋め込まれ、それによって、受信側は、送信側との同期を失ったと判定した場合、単一のパケットが受信されたときにそれ自体の同期を取り戻すことができる。すでに通信が進行中であり、受信側が、まだ送信側と同期していると判定した場合、再同期の必要はない。受信側は、たとえば、ある期間が経過した時点で満了し、それぞれの妥当なパケットによってリセットされるデッドマンタイマを使用することによって、同期していないことを検出することができる。パケット再試行アタックを防止するために、ハッシングによってパブリック同期フィールド以下参照にタイムスタンプを付加することができる。一態様では、送信側によって送信される各パケットのヘッダに同期フィールドが付加される。この同期フィールドは、平文であっても、あるいはパケットの暗号化された部分の一部であってもよい。送信側および受信側が乱数生成プログラムRNGおよびシード値を選択しているものと仮定すると、RNGとシードのこの組合せを使用して乱数配列RNSを生成することができる。次いで、RNSを使用して、上述のように送信元/着信先IPペアおよび必要に応じて、ディスクリミネータフィールドならびにハードウェア送信元アドレスおよびハードウェア着信先アドレスが生成される。しかし、シーケンス全体または最初のN1個の値を生成しなくてもシーケンス内のN番目の乱数を生成することができる。シーケンスインデックスNが既知である場合、このインデックスに対応する無作為の値を直接生成することができる以下参照。それぞれの異なる基本周期を有する様々なRNGおよびシードを使用して送信元IPシーケンスおよび着信先IPシーケンスを生成することができるが、この場合も基本的な概念が適用される。話を簡単にするために、以下の議論では、単一のRNGシーケンシング機構を使用してIP送信元着信先アドレスペアのみがホップされるものと仮定する。各パケットヘッダ内の同期フィールドは、自己同期機能により、IPペアを生成するために使用されているRNSにインデックスすなわち、シーケンス番号付けする。RNSを生成するために使用されているRNGにこのようにインデックス付けすると特定の乱数値が生成され、それによって特定のIPペアが生成される。すなわち、RNG、シード、およびインデックス番号から直接IPペアを生成することができ、この方式では、与えられたインデックス番号に関連付けされたシーケンス値に先行する乱数のシーケンス全体を生成することは不要である。通信者がすでにRNGおよびシードを交換しているものと仮定されているので、IPペアを生成するために与えなければならない新しい情報はシーケンス番号だけである。この番号が送信側によってパケットヘッダ内に与えられる場合、受信側は、この番号をRNGに入力するだけでIPペアを生成することができ、したがって、パケットのヘッダに示されたIPペアが妥当であることを検証することができる。この方式では、送信側と受信側が同期を失った場合、受信側は、パケットヘッダ内のIPペアを、インデックス番号から生成されるIPペアと比較することにより、単一のパケットを受信した時点でただちに同期を取り戻すことができる。したがって、単一のパケットを受信したときに、同期の取れた通信を再開することができ、この方式はマルチキャスト通信にとって理想的な方式になる。極端な場合には、同期テーブルが完全に不要になる。すなわち、送信側と受信側は、同期フィールド内のインデックス番号を使用するだけで各パケット上のIPペアの妥当性を確認することができ、それによってテーブルを完全になくすことができる。前述の方式は、それに関連する、セキュリティ上のある固有の問題を有する。すなわち、同期フィールドの配置の問題である。このフィールドをアウタヘッダに配置した場合、侵入者はこのフィールドの値および該値とIPストリームとの関係を見ることができる。これにより、場合によっては、IPアドレスシーケンスを生成するために使用されているアルゴリズムが影響を受け、したがって、通信のセキュリティが影響を受ける。しかし、この値をインナヘッダに配置した場合、送信側はインナヘッダを復号しないかぎり、同期値を抽出してIPペアの妥当性を確認することができなくなる。この場合、受信側は、パケット再生などある種のサービス拒否DoSアタックにさらされる。すなわち、受信側がパケットを復号しないかぎりIPペアの妥当性を確認することができない場合、アタッカーが単に、前に妥当であったパケットを再送する場合には、復号に関して著しい量の処理を実行しなければならなくなる恐れがある。アルゴリズムのセキュリティと処理速度との可能な兼ね合せとして、インナヘッダ暗号化済みとアウタヘッダ未暗号化との間で同期値が分割される。すなわち、同期値が十分に長い場合、は、平文で表示することのできる急速に変化する部分と、保護されなければならない固定または非常にゆっくりと変化する部分とに分割することができる。平文で表示することのできる部分をパブリック同期部と呼び、保護されなければならない部分をプライベート同期部と呼ぶ。完全な同期値を生成するにはパブリック同期部とプライベート同期部の両方が必要である。しかし、プライベート部は、固定されるか、あるいはときどきにのみ変化するように選択することができる。したがって、プライベート同期値を受信側によって記憶することができ、したがって、ヘッダを復号しなくても検索することができるようになる。送信側と受信側が、同期のプライベート部分が変化する頻度に関してすでに合意している場合、受信側は、同期を失う原因となった通信ギャップが前のプライベート同期の有効期間を超えた場合に、選択的に単一のヘッダを復号して新しいプライベート同期を抽出することができる。この場合、復号の量が厄介な量になることはなく、したがって、受信側が、単に単一のヘッダをときどき復号する必要があることに基づいてサービス拒否アタックにさらされることはない。この1つのインプリメンテーションでは、ハッシュ関数を1対1マッピングと共に使用して同期値からプライベート同期部およびパブリック同期部が生成される。このインプリメンテーションは図13に示されており、この場合、たとえば第1のISP1302が送信側であり、第2のISP1303が受信側である。図13では他の代替態様が可能である。送信されるパケットは、暗号化されていないパブリックヘッダまたはアウタヘッダ1305と、たとえばリンク鍵を使用して暗号化されたプライベートヘッダまたはインナヘッダ1306とを備える。アウタヘッダ1305はパブリック同期部を含み、それに対して、インナヘッダ1306はプライベート同期部を含む。受信側ノードは、復号関数1307を使用してインナヘッダを復号し、プライベート同期部を抽出する。このステップが必要になるのは、現在バッファされているプライベート同期の有効期間が満了した場合だけである。現在バッファされているプライベート同期がまだ有効である場合、このプライベート同期は単にメモリから抽出され、ステップ1308に示すようにパブリック同期に付加逆ハッシュでよいされる。パブリック同期部と復号されたプライベート同期部は関数1308で組み合わされ、組合せ同期1309が生成される。組合せ同期1309は次いで、RNG1310に送られ、IPアドレスペア1311と比較され、パケットの妥当性が確認されるか、あるいはパケットが拒絶される。このアーキテクチャの重要な点は、パブリック同期値が関与する未来と過去の概念である。スプーフィングアタックを防止するには同期値自体が無作為の値であるべきであるが、すでに送信された同期値を含むパケットが実際には受信側によって受信されていない場合でも、受信側がこの同期値を高速に識別できることが重要である。1つの解決策として、ハッシングによってタイムスタンプまたはシーケンス番号がパブリック同期部に付加され、したがって、このパブリック同期部を高速に抽出し、検査し、破棄し、それによってパブリック同期部自体の妥当性を確認することができる。一態様では、同期フィールドによって生成された送信元/着信先IPペアを、パケットヘッダに示されたペアと比較することによってパケットを検査することができる。1ペアが一致し、2タイムスタンプが妥当であり、3デッドマンタイマが満了している場合、同期が取り直される。そうでない場合、パケットは拒絶される、十分な処理能力が利用できる場合、デッドマンタイマおよび同期テーブルを回避することができ、受信側は単にあらゆるパケットに関して同期を取り直すたとえば、妥当性を確認する。前述の方式では、そのインプリメンテーションに影響を与える大整数たとえば、160ビット計算が必要になることがある。このような大整数レジスタがない場合、スループットに影響が及び、したがって、場合によってはサービス拒否の点でセキュリティに影響が及ぶ。それにもかかわらず、大整数計算処理機能が普及すると、このような機能を実施するコストが削減される。D.他の同期方式上述のように、VPN内の通信側と受信側の間で、連続するW個以上のパケットが失われた場合Wはウインドウサイズ、受信側のウインドウは更新されておらず、送信側は、受信側のウインドウに入っていないパケットは送信しない。送信側と受信側は、おそらくウインドウ内の無作為のペアが偶然に繰り返されるまで同期を回復しない。したがって、可能なときにはいつでも送信側と受信側を同期させ、同期が失われたときは常にそれを再確立する必要がある。同期を失った送信側と受信側の間の同期を、チェックポイント方式を使用して回復することができる。この方式では、無作為のIPアドレスペアを備えたチェックポイントメッセージを使用して同期情報が伝達される。一態様では、2つのメッセージを使用して送信側と受信側の間で以下の同期情報が伝達される。1.SYNCREQは、送信側が同期を取る必要があることを示すために送信側によって使用されるメッセージであり、2.SYNCACKは、受信側の同期が取れたことを送信側に知らせるために受信側によって使用されるメッセージである。この手法の一変形態様によれば、送信側と受信側は共に以下の3つのチェックポイントを維持する図14参照。1.送信側において、ckptoチェックポイントオールドは、最後のSYNCREQパケットを受信側に再送するために使用されたIPペアである。受信側において、ckptoチェックポイントオールドは、送信側から繰り返しSYNCREQパケットを受信するIPペアである。2.送信側において、ckptnチェックポイントニューは、次のSYNCREQパケットを受信側に送信するために使用されるIPペアである。受信側において、ckptnチェックポイントニューは、新しいSYNCREQパケットを送信側から受信し、受信側のウインドウを再整列させ、ckptoをckptnに設定させ、新しいckptnを生成させ、新しいckptrを生成させるIPペアである。3.送信側において、ckptrは、次のSYNCACKパケットを受信側に送信するために使用されるIPペアである。受信側において、ckptrは、新しいSYNCACKパケットを送信側から受信し、新しいckptnを生成させるIPペアである。SYNCACKは受信側ISPから送信側ISPに送信されるので、送信側ckptrは受信側のckptrをを指し、受信側ckptrは送信側のckptrを指す図14参照。送信側が同期を開始すると、送信側が次のデータパケットを送信するために用いるIPペアが所定の値に設定され、受信側がまずSYNCREQを受信すると、受信側ウインドウが、送信側の次のIPペアが中心になるように更新される。同期はパケットカウンタによって開始することもたとえば、N個のパケットが送信されるたびに同期を開始する、あるいはタイマによって開始することもS秒おきに同期を開始する、あるいはそれらの組合せによって開始することもできる。図15を参照されたい。送信側から見ると、この技法は以下のように作用する。1各送信側は、受信側が同期していることを確認するために定期的に同期要求メッセージを受信側に送信する。2受信側は、まだ同期している場合、同期確認メッセージを送り返す。これがうまくいった場合、さらなる処置は必要とされない。3ある期間内に同期確認が受信されなかった場合、送信側は同期要求を再び送信する。送信側が同期確認応答を受信せずに次のチェックポイントに到達した場合、同期が失われ、送信側は送信を停止する必要がある。送信側はsyncackを受信するまでsyncreqsを送信し続け、受信した時点で送信が再確立される。受信側から見ると、この方式は以下のように作用する。1受信側は、送信側から同期要求要求を受信すると、ウインドウを次のチェックポイント位置へ進め場合によっては必要に応じてペアをスキップする、同期応答メッセージを送信側に送信する。同期が失われていない場合、ジャンプアヘッドによって、テーブル内の次の利用可能なアドレスペアに進むすなわち、通常の前進。侵入者が同期要求メッセージを捕捉し、新しい同期要求メッセージを送信することによって通信の干渉を試みた場合、同期が確立されているか、あるいはこのメッセージが実際に同期を再確立する助けになる場合、このメッセージは無視される。ウインドウは、再同期が行われたときは常に再整列させられる。この再整列に伴い、SYNCREQパケットが送信された直後に送信されたパケットによって使用されたアドレスペアにまたがるように受信側のウインドウが更新される。通常、送信側と受信側は互いに同期させられる。しかし、ネットワークイベントが起こった場合、再同期中に受信側のウインドウを多数のステップ分進めなければならないことがある。この場合、介在する乱数間を順次進む必要なしにウインドウを進めることが望ましい。この機能は、上述の自動同期手法にも望ましい。E.ジャンプアヘッド機能を有する乱数生成プログラム無作為にホップされるアドレスを生成するための魅力的な方法は、送信側と受信側で同一の乱数生成プログラムを使用し、パケットが送信され受信されたときにこのプログラムを進める方法である。使用できる多数の乱数生成アルゴリズムがある。各アルゴリズムは、アドレスホッピング応用例に対する利点と欠点を有する。線形乱数生成プログラムLCRは、明確な特徴を有する高速で簡単な乱数生成プログラムであり、効率的にnステップ先にジャンプさせることができる。LCRは、以下の反復を使用してシードX0から始まる乱数X1、X2、X3、、XKを生成する。Ximodc上式で、a、b、およびcは特定のLCRを定義する符号である。Xiに関する別の数式、すなわち、Xibmodcによって、ジャンプアヘッド機能が有効になる。係数aiは、拘束されない場合、iが小さい場合もで非常に大きなることができる。したがって、モジュロ演算のいくつかの特殊な特性を使用して、2を計算するのに必要なサイズおよび処理時間を調節することができる。2は次式のように書くことができる。Xibbmodc以下のことを示すことができる。bbmodccbbmodcbをbmodcとして記憶し、bをbmodcとして記憶し、aimodcを計算することができるこれには0回のステップが必要である。このアルゴリズムの実際的なインプリメンテーションは、各同期間で一定距離nだけジャンプする。これは、nパケットおきの同期に相当する。ウインドウは、前のウインドウが開始してからnIPペア後に開始する。ノードは、Xjw、すなわち、J番目のチェックポイントでの乱数をX0として使用し、nをiとして使用して、LCR当たり1度anmodcを記憶し、Xj1wXncbbmodcを、j1番目の同期用の乱数を生成するように設定することができる。ノードは、この構成を使用して、nとは無関係の一定の時間内に、各同期間で任意のしかし、一定の距離だけ先にジャンプすることができる。したがって、一般に擬似乱数生成プログラム、特にLCRはそのサイクルを繰り返す。この繰返しは、IPホッピング方式の弱点となる可能性がある。すなわち、繰侵入者は、繰返しを待つだけで未来のシーケンスを予想することができる。この弱点に対処する1つの方法は、既知の長いサイクルを有する乱数生成プログラムを作成することである。無作為のシーケンスが繰り返される前に、このシーケンスを新しい乱数生成プログラムで置き換えることができる。既知の長いサイクルを有するLCRを構成することができる。このことは、現在の所、多くの乱数生成プログラムには当てはまらない。乱数生成プログラムは、暗号に関して安全でない点がある。侵入者は、出力またはその一部を調べることによってRNGパラメータを導くことができる。このことはLCGに当てはまる。この弱点は、出力を乱数生成プログラムの一部とするように構成された暗号化プログラムを組み込むことによって軽減することができる。乱数生成プログラムは、侵入者が暗号プログラムにアタック、たとえば既知の平文アタックを開始するのを防止する。F.乱数生成プログラムの例a31、b4、およびc15であるRNGについて考える。この場合、数式1はXimod15になる。X01を設定した場合、数式6はシーケンス1、5、9、13、2、6、10、14、3、7、11、0、4、8、12を生成する。このシーケンスは無限に繰り返される。このシーケンスで3つの数だけ先にジャンプする場合、an31329791、c1530450、およびanmodc313mod29791mod91である。数式5は430mod15表1は、7のジャンプアヘッド計算を示している。この計算は、5から始まり3つ先にジャンプする。G.高速パケットフィルタアドレスホッピングVPNは、パケットが妥当なヘッドを有し、したがって、さらなる処理を必要とするか、それとも不当なヘッダを有し有害なパケット、ただちに拒絶すべきであるかどうかを高速に判定しなければならない。このような高速の判定を高速パケットフィルタリングと呼ぶ。この機能は、受信側のプロセッサを飽和させるために受信側で有害なパケットのストリームを高速に作成する侵入者によるアタックいわゆるサービス拒否アタックからVPNを保護する。高速パケットフィルタリングは、イーサネット登録商標などの共用媒体上でVPNを実施するための重要な機能である。VPNのすべての参加者が、割り当てられていないAアドレスブロックを共用すると仮定した場合、1つの可能性として、共用媒体上でアドレスホッピングされないマシンに割り当てられることのない実験的なAブロックが使用される。Aブロックは、Cブロック内の8ビットとは逆にホップできる24ビットのアドレスを有する。この場合、ホップブロックはAブロックになる。イーサネット登録商標上では以下の理由で、実験的なAブロックが使用される可能性が高い。1.アドレスが、イーサネット登録商標の外部で無効であり、ゲートウェイによって妥当な外部の着信先にルーティングされることがない。2.各Aブロック内でホップできる224~1600万個のアドレスがある。このため、>280兆個の可能なアドレスペアが生成され、侵入者が妥当なアドレスを推測できる可能性は非常に低くなる。また、別々のVPN同士が衝突する可能性が許容される程度に低くなる共用される媒体上のすべてのVPNが独立に、Aブロックから無作為のアドレスペアを生成する。3.マシンがプロミスキュアスモードでないかぎりパケットが、イーサネット登録商標上のユーザであり、かつVPN上には存在しないユーザに受信されることがなく、非VPNコンピュータに対する影響が最小限に抑えられる。このイーサネット登録商標の例を、高速パケットフィルタリングの1インプリメンテーションを説明するために使用する。理想的なアルゴリズムは、パケットヘッダを高速に調べ、パケットが有害であるかどうかを判定し、あらゆる有害なパケットを拒絶するか、あるいはパケットヘッダが一致するのはどのアクティブIPペアかを判定する。この場合の問題は、従来のアソシエーティブメモリの問題である。この問題を解決するために様々な技法が開発されているハッシング、Bツリーなど。これらの手法はそれぞれ、利点と欠点を有する。たとえば、ハッシュテーブルは、統計的な意味で極めて高速に動作させることができるが、場合によってはずっと低速のアルゴリズムに退化することがある。この低速はある期間にわたって持続することがある。有害なパケットは常に高速に破棄する必要があるので、ハッシングは受け入れられない。H.存在ベクトルアルゴリズム存在ベクトルとは、nビット番号それぞれ0から2n1までの範囲によってインデックス付けすることのできる長さ2nのビットベクトルである。各番号によってインデックス付けされた存在ベクトル内のビットを1に設定することにより、k個のnビット番号必ずしも一意ではないの存在を示すことができる。nビット番号xがk個の番号のうちの1つであるのは、存在ベクトルのx番目のビットが1である場合だけである。存在ベクトルにインデックス付けし、1を探すことによって高速パケットフィルタを実施することができる。この方法をテストと呼ぶ。たとえば、存在ベクトルを使用して番号135を表す必要があるものと仮定する。ベクトルの135番目のビットが設定される。したがって、1つのビット、すなわち135番目のビットを検査することによって、アドレス135が妥当であるかどうかを迅速に判定することができる。存在ベクトルは、IPアドレスのテーブルエントリに対応するように事前に作成することができる。実際には、着信アドレスを長いベクトルのインデックスとして使用して、比較を非常に高速に行うことができる。各RNGが新しいアドレスを生成すると、存在ベクトルはこの情報を反映するように更新される。ウインドウが移動すると、存在ベクトルは、もはや妥当ではないアドレスをゼロにするように更新される。テストの効率と、存在ベクトルを記憶するのに必要なメモリの量との兼ね合せがある。たとえば、48ビットのホッピングアドレスをインデックスとして使用する必要がある場合、存在ベクトルは35テラバイトを有する必要がある。これが実際上大き過ぎることは明らかである。この代わりに、48ビットをいくつかのより小さなフィールドに分割することができる。たとえば、48ビットを4つの12ビットフィールドに細分することができる。これによって、記憶要件は2048バイトに削減され、その代わりに、ときどき有害なパケットを処理しなければならなくなる。実際には、1つの長い存在ベクトルではなく、分解された各アドレス部分が、4つの短い存在ベクトルのすべてに一致しないかぎり、さらなる処理が許可されなくなる。アドレス部分の第1の部分が第1の存在ベクトルに一致しない場合、残りの3つの存在ベクトルを検査する必要はない。存在ベクトルのy番目のビットが1であるのは、対応するフィールドがyである1つまたは複数のアドレスがアクティブである場合だけである。アドレスがアクティブであるのは、そのアドレスの適切なサブフィールドによってインデックス付けされた各存在ベクトルが1である場合だけである。32個のアクティブアドレスおよび3個のチェックポイントから成るウインドウについて考える。有害なパケットは、1つの存在ベクトルに99よりも長い時間にわたってインデックス付けすることによって拒絶される。有害なパケットは、4つの存在ベクトルのすべてに999999995よりも長い時間にわたってインデックス付けすることによって拒絶される。平均すると、有害なパケットは102回未満の存在ベクトルインデックス動作で拒絶される。高速パケットフィルタを通過した少数の有害パケットは、一致するペアが、アクティブウインドウ内に見つからないか、あるいはアクティブチェックポイントであるときに拒絶される。思いがけずヘッダに一致した有害なパケットは、VPNソフトウェアがこのヘッダの復号を試みたときに拒絶される。しかし、これらのケースは極めてまれである。空間と速度の兼合いを図るようにこの方法を構成する手段として、他に多くの方法がある。"