JP5374536B2 - 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良 - Google Patents

保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良 Download PDF

Info

Publication number
JP5374536B2
JP5374536B2 JP2011085052A JP2011085052A JP5374536B2 JP 5374536 B2 JP5374536 B2 JP 5374536B2 JP 2011085052 A JP2011085052 A JP 2011085052A JP 2011085052 A JP2011085052 A JP 2011085052A JP 5374536 B2 JP5374536 B2 JP 5374536B2
Authority
JP
Japan
Prior art keywords
client
packet
address
secure
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2011085052A
Other languages
English (en)
Other versions
JP2011182427A5 (ja
JP2011182427A (ja
Inventor
ビクター ラーソン
ロバート ダンハム ザ サード ショート
エドモント コルビー ミュンガー
マイケル ウィリアムソン
Original Assignee
バーネットエックス インコーポレーティッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by バーネットエックス インコーポレーティッド filed Critical バーネットエックス インコーポレーティッド
Publication of JP2011182427A publication Critical patent/JP2011182427A/ja
Publication of JP2011182427A5 publication Critical patent/JP2011182427A5/ja
Application granted granted Critical
Publication of JP5374536B2 publication Critical patent/JP5374536B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5076—Update or notification mechanisms, e.g. DynDNS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5092—Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1491—Countermeasures against malicious traffic using deception as countermeasure, e.g. honeypots, honeynets, decoys or entrapment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/604—Address structures or formats
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

関連出願の相互参照
本出願は、2000年2月15日に出願された出願済みの米国特許出願第09/504,783号の一部継続特許出願であり、米国特許出願第09/504,783号は、1999年10月29日に出願された出願済みの米国特許出願第09/429,643号の優先権を主張し、かつこの出願の一部継続特許出願である。本明細書に全体的に組み入れられる米国特許出願第09/429,643号の主題は、米国特許仮出願第60/106,261号（1998年10月30日出願）および第60/137,704号（1999年6月7日出願）に由来する。本出願は、2000年4月26日に出願され、かつ参照として本明細書に組み入れられる、米国特許出願第09/558,210号（弁理士事件登録番号479.86839）にも関する。
発明の背景
インターネットを介した通信のセキュリティおよび匿名性を実現するために、極めて様々な方法が提案され実施されている。このように種類が多いのは、1つには様々なインターネット・ユーザのニーズがそれぞれ異なるためである。これらの様々なセキュリティ技法を論じるうえで助けになる基本的なヒューリスティック構造を図1に示す。2つの端末、すなわち、発信元端末100と着信先端末110はインターネットを介して通信する。通信を安全なものし、すなわち、通信が盗聴されないものであることが望ましい。たとえば、端末100がインターネット107を介して端末110に秘密情報を送信することがある。また、端末100が端末110と通信していることをリスナーが気付かないようにすることが望ましい場合もある。たとえば、端末100がユーザであり、端末110がウェブ・サイトを運営している場合、端末100のユーザは、どのウェブ・サイトに「アクセスしている」かを介在するネットワーク内の誰にも知られたくない場合がある。したがって、たとえば、自分たちの市場研究の対象を公開しないことを望み、したがってウェブ・サイトまたはその他のインターネットリソースのうちのどれに「アクセスしている」かを部外者が知るのを防止することを望む会社には匿名性が重要である。セキュリティに関するこの2つの問題はそれぞれ、データ・セキュリティおよび匿名性と呼ぶことができる。
データ・セキュリティは通常、ある形式のデータ暗号化を使用して対処される。発信元端末100と110の両方で暗号化鍵48が知られている。この鍵は、発信元端末100および着信先端末110のそれぞれでの専用鍵および公開鍵でも、あるいは対称鍵（同じ鍵が、両当事者によって暗号化および復号のために使用される）でもよい。多くの暗号化方法が知られており、この場合に使用可能である。
トラフィックをローカル管理者またはISPから隠すために、ユーザは、このローカル管理者またはISPが暗号化されたトラフィックのみを見るように、暗号化されたチャネルを通して外部エポキシと通信する際にローカル・エポキシ・サーバを使用することができる。プロキシ・サーバは、着信先サーバが発信元クライアントのIDを判定するのを妨げる。このシステムはクライアントと着信先サーバとの間に介在する中間サーバを使用する。着信先サーバは、プロキシ・サーバのインターネット・プロトコル（IP）アドレスのみを見て、発信元クライアントは見ない。ターゲット・サーバは外部プロキシのアドレスのみを見る。この方式は、信用できる外部プロキシ・サーバに依存する。また、プロキシ方式は、送信側および受信側のIDを判定するトラフィック分析方法の影響を受けやすい。プロキシ・サーバの他の重要な制限は、サーバが呼出し側と被呼出し側の両方のIDを知ることである。多くの例では、端末Aなどの発信元端末は、インターネット・サービス・プロバイダ（ISP）によってプロキシ・サーバが設けられている場合、端末のIDをプロキシから隠しておくことを望む。
トラフィック分析を無効にするために、Chaumのミックスと呼ばれる方式では、ダミー・メッセージを含む固定長メッセージを送受信するプロキシ・サーバが使用される。複数の発信元端末がミックス（サーバ）を通して複数のターゲット・サーバに接続される。どの発信元端末が、接続されているターゲット・サーバのうちのどれと通信しているかを判定するのは困難であり、ダミー・メッセージによって、リスナーがトラフィックを分析することによって通信ペアを検出することは困難になる。この方法の欠点は、ミックス・サーバが打破される恐れがあることである。この危険に対処する1つの方法は、複数のミックス間で責任を分散することである。すなわち、1つのミックスが打破された場合でも、発信元端末およびターゲット端末のIDを隠されたままにすることができる。この方式では、複数のミックスをコンプロマイズしないかぎり、発信元端末とターゲット端末との間に介在する中間サーバを判定できないように、いくつかの代替ミックスが必要である。この方式では、メッセージが複数の暗号化アドレスレイヤで覆われる。シーケンス中の第1のミックスはメッセージのアウタ・レイヤのみを復号して、シーケンス中の次の着信先ミックスを知ることができる。第2のミックスはこのメッセージを復号して次のミックスを知り、以下同様な手順が繰り返される。ターゲット・サーバは、メッセージを受信し、任意選択で、データを同様に送り返すためのリターン情報を含むマルチレイヤ暗号化ペイロードを受信する。このようなミックス方式を無効にするには、ミックスを共謀させるしかない。パケットがすべて固定長であり、パケットにダミー・パケットが混合されている場合、どんな種類のトラフィック分析も不可能である。
「クラウド」と呼ばれる他の匿名性技法は、発信元端末をクラウドと呼ばれるプロキシ・グループに属させることによって発信元端末のIDを中間プロキシから保護する技法である。クラウド・プロキシは、発信元端末とターゲット端末との間に介在する。メッセージが通過する各プロキシは、上流側プロキシによって無作為に選択される。各中間プロキシは、「クラウド」内の無作為に選択された他のプロキシまたは着信先にメッセージを送信することができる。したがって、クラウド・メンバーでも、メッセージの発信側が前のプロキシであるかどうかや、メッセージが他のプロキシから転送されたものに過ぎないのかどうかを判定することができない。
ZKS（ゼロ・ノリッジ・システム）匿名IPプロトコルは、ユーザが5つの異なる匿名のいずれかを選択できるようにし、同時に、デスクトップ・ソフトウェアが発信トラフィックを暗号化し、ユーザ・データグラム・プロトコル（UDP）パケット内に隠される。2＋−ホップ・システム内の第1のサーバは、UDPパケットを得て、1つの暗号化レイヤを除去して別の暗号化レイヤを付加し、次いでこのトラフィックを次のサーバに送信する。このサーバはさらに別の暗号化レイヤを除去して新しい暗号化レイヤを付加する。ユーザはホップの数を制御することができる。最後のサーバで、トラフィックは、追跡不能なIPアドレスを用いて復号される。この技法はオニオン・ルーティングと呼ばれている。この方法は、トラフィック分析を使用して無効にすることができる。簡単な例では、低デューティ期間中のユーザからのパケットのバーストによって送信側および受信側のIDが知られることがある。
ファイアウォールは、許可されていないアクセスや、LANに接続されたコンピュータの悪意ある使用またはそのようなコンピュータに対する損害からLANを保護することを試みる。ファイアウォールは、管理オーバヘッドを維持することを必要とする中央化システムである。ファイアウォールは、仮想マシン・アプリケーション（「アプレット」）によって打破することができる。このようなアプリケーションは、たとえば、ユーザがファイアウォールの外部のサーバに機密情報を送信したり、モデムを使用してファイアウォール・セキュリティを回避することを勧めたりすることによってセキュリティ違反を引き起こすセキュリティの誤った意味を浸透させる。ファイアウォールは、出張旅行者、エクストラネット、小規模なチームなどの分散システムには有用ではない。
発明の概要
トンネル・アジル・ルーティング・プロトコル（TARP）と呼ばれるプロトコルを含む、インターネットを介して通信する安全機構は、固有の2レイヤ暗号化フォーマットおよび特殊なTARPルータを使用する。TARPルータは、機能が正規のIPルータと類似している。各TARPルータは、1つまたは複数のアドレスを有し、通常のIPプロトコルを使用してIPパケット・メッセージ（「パケット」または「データグラム」）を送信する。TARPルータを介してTARP端末間で交換されるIPパケットは、TARPルータおよびサーバ以外には真の着信先アドレスが隠される実際に暗号化されたパケットである。TARP IPパケットに付加された通常のIPヘッダまたは「平文」IPヘッダまたは「外部」IPヘッダは、次のホップ・ルータまたは着信先サーバのアドレスのみを含む。すなわち、TARPパケットのIPヘッダは、IPヘッダの着信先フィールドで最終着信先を示すのではなく、常に、一連のTARPルータ・ホップ内の次のホップまたは最終着信先を指し示す。このことは、着信先は常に次のホップTARPルータおよび最終着信先であるので、傍受されたTARPパケットにはそのTARPパケットの真の着信先を明白に示すものがないことを意味する。
各TARPパケットの真の着信先は、リンク鍵を使用して生成された暗号化層に隠される。リンク鍵は、発信元TARP端末と着信先TARP端末との間に介在するホップ間の暗号化された通信に使用される暗号化鍵である。各TARPルータは、暗号化アウタ・レイヤを除去して各TARPパケットの着信先ルータを知ることができる。受信側TARPまたはルーティング端末は、TARPパケットの暗号化アウタ・レイヤを復号するのに必要なリンク鍵を識別するために、平文IPヘッダ内の送信側／受信側IP番号によって送信側端末を識別することができる。
暗号化アウタ・レイヤが除去された後、TARPルータは最終着信先を判定する。各TARPパケット140は、トラフィック分析を無効にする助けとなるように最小数のホップを受ける。ホップは、無作為に選択することができ、あるいは一定の値でもよい。その結果、各TARPパケットは、着信先に到着する前に地理的に異なるいくつかのルータの間を無作為に移動することができる。各移動は、独立に無作為に決定されるので、所与のメッセージを構成する各パケットごとに異なる可能性が非常に高くなる。この機能をアジル・ルーティングと呼ぶ。様々なパケットがそれぞれの異なる経路をとるため、侵入者が、マルチパケット・メッセージ全体を形成するすべてのパケットを得ることは困難になる。これに伴う利点は、後述の暗号化インナレイヤに関する利点である。アジル・ルーティングは、この目的を促進する他の機能、すなわち、あらゆるメッセージが複数のパケットに分割されるようにする機能と組み合される。
TARPルータのIPアドレスは変更することができ、この機能をIPアジリティと呼ぶ。各TARPルータは、独立して、あるいは他のTARP端末またはTARPルータからの指示の下で、IPアドレスを変更しうる。変更可能な別の識別子またはアドレスも定義される。このアドレスは、TARPアドレスと呼ばれ、TARPルータおよびTARP端末のみに知られ、いつでもTARPルータまたはTARP端末によって参照テーブル（LUT）を使用して相関付けることができる。TARPルータまたはTARP端末は、IPアドレスを変更したときに、他のTARPルータまたはTARP端末を更新し、これらのTARPルータまたはTARP端末はそれぞれのLUTを更新する。
メッセージ・ペイロードは、セッション鍵を使用しないかぎりロック解除できない、TARPパケット内の暗号化インナレイヤに隠される。セッション鍵は、介入するTARPルータがいずれも利用できない鍵である。セッション鍵は、TARPパケットのペイロードを復号し、データ・ストリームを再構成できるようにするために使用される。
リンク鍵およびセッション鍵を使用して通信を公開されないようにすることができ、任意の所望の方法に従ってリンク鍵およびセッション鍵を共用し使用することができる。たとえば、公開／専用鍵または対称鍵を使用することができる。
TARP発信元端末は、データ・ストリームを送信する場合、ネットワーク（IP）層過程によって生成された一連のIPパケットから一連のTARPパケットを構成する。（本明細書で使用される「ネットワーク層」、「データ・リンク層」「アプリケーション層」などが開放形システム間相互接続（OSI）ネットワーク用語に対応することに留意されたい。）これらのパケットのペイロードは、セッション鍵を使用して暗号化されたブロックおよびチェーン・ブロックとして組み立てられる。もちろん、この場合、すべてのIPパケットが同じTARP端末を着信先としているものと仮定する。このブロックは次いでインタリーブされ、インタリーブされた暗号化済みブロックは、生成すべき各TARPパケットごとに1つの一連のペイロードに分割される。次いで、データ・ストリーム・パケットから得たIPヘッダを使用して、各ペイロードに特殊なTARPヘッダIPrが付加される。TARPヘッダは、通常のIPヘッダと同一であってよく、あるいは何らかの方法でカスタマイズすることができる。TARPヘッダは、着信先TARP端末でデータをインタリーブ解除するための方式またはデータ、実行すべきホップの数を示すタイム・ツー・リブ（TTL）パラメータ、ペイロードがたとえば、TCPデータを含むか、それともUDPデータを含むかを示すデータ・タイプ識別子、送信側のTARPアドレス、着信先TARPアドレス、パケットが実際のデータを含むか、それともデコイ・データを含むかに関するインディケータ、またはデコイ・データがTARPペイロード・データを通じてある方法で流布される場合にデコイ・データを除去する方式を含むべきである。
本明細書ではセッション鍵に関してチェーン・ブロック暗号化を論じているが、任意の暗号化方法を使用できることに留意されたい。好ましくは、チェーン・ブロック暗号化と同様に、暗号化過程の結果全体が得られないかぎり許可されない復号が困難にする方法を使用すべきである。したがって、暗号化されたブロックを複数のパケット間で分離し、侵入者がすべてのそのようなパケットにアクセスするのを困難にすることによって、通信のコンテンツに特別なセキュリティ・レイヤが与えられる。
ピーク・ツー・アベレージ・ネットワーク負荷を低減させることによってトラフィック分析を無効にするための助けになるように、デコイ・データまたはダミー・データをストリームに付加することができる。インターネット内のある点での通信バーストを他の点での通信バーストに結合して通信エンドポイントを知ることができなくなるように、時間またはその他の基準に応答して低トラフィック期間中により多くのデコイ・データを生成する能力をTARP過程に付与することが望ましい。
ダミー・データは、データをより多くの目立たないサイズのパケットに分割して、インタリーブウィンドウのサイズを大きくすることを可能にし、同時に各パケットごとに合理的なサイズを維持するうえでも助けになる。（パケット・サイズは、単一の標準サイズでよく、あるいは一定の範囲のサイズから選択することができる。）各メッセージを複数のパケットに分割することが望ましい1つの主要な理由は、インタリーブの前にチェーン・ブロック暗号化方式を使用して第1の暗号化レイヤが形成される場合に明らかである。メッセージの一部または全体に単一のブロック暗号化を適用し、次いでその部分または全体をインタリーブしていくつかの別々のパケットを得ることができる。パケットのアジルIPルーティングと、それに伴い、パケットのシーケンス全体を再構成して、ブロック暗号化された単一のメッセージ要素を形成するのが困難であることを考えると、デコイ・パケットがデータ・ストリーム全体を再構成することの困難さを著しく増大させることがわかる。
上記の方式は、データ・リンク層と、TARPシステムに参加している各サーバまたは端末のネットワーク層との間で動作する過程によって完全に実施することができる。上述の暗号化システムはデータ・リンク層とネットワーク層との間に挿入することができるので、暗号化された通信をサポートするうえで使用される過程は、IP（ネットワーク）層以上での過程に対して完全に透過的であってよい。TARP過程は、データ・リンク層の過程に対しても完全に透過的であってよい。したがって、ネットワーク層以上での動作も、データ・リンク層以下での動作も、TARPスタックを挿入することの影響を受けない。これにより、（たとえば、ハッカーによる）ネットワーク層への許可されないアクセスの困難さが大幅に増大するので、ネットワーク層以上でのすべての過程に追加のセキュリティがもたらされる。セッション層で実行される新たに開発されたサーバの場合でも、セッション層よりも下のすべての過程が侵害される可能性がある。この構造では、セキュリティが分散されることに留意されたい。すなわち、たとえば、移動中の管理職によって使用されるノートブック・コンピュータは、セキュリティを損なうことなくインターネットを介して通信することができる。
TARP端末およびTARPルータによるIPアドレス変更は、一定の間隔または無作為の間隔で行うことも、あるいは「攻撃」が検出されたときに行うこともできる。IPアドレスを変更することにより、どのコンピュータが通信しているかを知ることのできるトラフィック分析が抑制され、攻撃に対するある程度の保護ももたらされる。攻撃に対する保護の程度は、ホストのIPアドレスが変更される率にほぼ比例する。
前述のように、IPアドレスは攻撃に応答して変更することができる。たとえば、ルータがある方法で調べられていることを示す組織だった一連のメッセージによって、攻撃を知ることができる。攻撃が検出されると、TARP層過程は、そのIPアドレスを変更することによってこの事象に応答することができる。また、TARP層過程は、最初のIPアドレスを維持し、ある方法で攻撃者との対話を続けるサブ過程を作成することができる。
デコイ・パケットは、アルゴリズムによって決定されるある基準に従って各TARP端末によって生成することができる。たとえば、アルゴリズムは、端末がアイドル状態であるときに無作為にパケットを生成することを要求するランダム・アルゴリズムでよい。あるいは、アルゴリズムは、時間または低トラフィックの検出に応答して低トラフィック時により多くのデコイ・パケットを生成することができる。パケットが好ましくは、1つずつ生成されるのではなく、実際のメッセージをシミュレートするようなサイズのグループとして生成されることに留意されたい。また、デコイ・パケットを通常のTARPメッセージ・ストリームに挿入できるように、バックグラウンド・ループは、メッセージ・ストリームが受信されているときにデコイ・パケットを挿入する可能性を高くするラッチを有することができる。あるいは、多数のデコイ・パケットが正規のTARPパケットと共に受信される場合、アルゴリズムは、これらのデコイ・パケットを転送するのではなくそれらを除去する率を高くすることができる。このようにデコイ・パケットを除去し生成すると、見掛けの着信メッセージ・サイズが見掛けの発信メッセージ・サイズと異なるものになり、トラフィック分析を無効にすることができる。
本発明の他の様々な態様では、ネットワーク内の各通信ノード・ペアに複数のIPアドレスが事前に割り当てられるシステムのスケーリング可能なバージョンを構成することができる。各ノード・ペアは、IPアドレス（送信側と受信側の両方）間の「ホッピング」に関するアルゴリズムに合意し、したがって、リスナーは、通信ノード・ペアの間で送信されるパケットにおいて見掛け上連続する無作為のIPアドレスを見る。各ノードは、合意されたアルゴリズムによる妥当な送信元／着信先ペアを含むことを検証するに過ぎないので、同じサブネット上の数人の異なるユーザに重複するIPアドレスまたは「再使用可能な」IPアドレスを割り付けることができる。好ましくは、IPブロック・サイズが限られているか、あるいはセッションが長いために必要とされないかぎり、所与のエンド・ツー・エンド・セッション中に2つのノード間で送信元／着信先ペアを再使用することはない。
この一部継続出願に記載されたさらなる改良には、（1）伝送パスの品質に応じて異なる伝送パスを超えてパケットを分配するロード・バランサ、（2）ドメイン名の問合せに応答して仮想専用網を透過的に形成するDNSプロキシ・サーバ、（3）システム・チェックポイントでのサービス拒否攻撃(attack)を防止する大小リンク帯域幅管理機能、（4）送信側と受信側の同期をとることができる速度を制限することによって着信パケットを規制するトラフィック・リミッタ、および（5）通信機能を2つの別々のエンティティ間で分割することによって、多数のノードが中央ノードと通信できるようにするシグナリング・シンクロナイザが含まれる。
本発明は、既存のインターネット・プロトコル（IP）上に構築された、新しいアジル・ネットワーク・プロトコルを用いることによって、安全仮想インターネットを実施する基本技術を提供する。この安全仮想インターネットは、既存のインターネット構造基盤上で働き、既存のインターネットと同様にクライアント・アプリケーションとのインタフェースをとる。この安全仮想インターネットを支える本発明によって提供される基本技術は、安全仮想インターネットの一部となる「ワン・クリック」・「ノー・クリック」技術、安全仮想インターネット用の安全ドメイン名サービス（SDNS）、および特定のクライアント・アプリケーションと安全仮想インターネットを相互接続する新しい手法を含む。本発明によれば、安全ドメイン名サービスは、ドメイン名およびアドレスを登録し、それに対してサービスを提供する方法を実現するだけでなく、既存のアプリケーションとのインタフェースをとる。
本発明の一局面によれば、ユーザは好都合なことに、ユーザ識別情報、パスワード、および／またはVPNを確立するための暗号化鍵を入力する必要なしに、「ワン・クリック」・「ノー・クリック」技術を使用してVPNを確立することができる。本発明の利点は、インターネットなどのコンピュータ・ネットワーク上の第1のコンピュータと第2のコンピュータとの間に、安全通信リンクを確立する方法によってもたらされる。一態様において、安全通信モードは、ユーザが通信の安全通信モードを確立するための暗号化情報を入力せずに、好ましくは、第1のコンピュータ上に表示されるアイコンを単に選択することによって、第1のコンピュータで使用可能にされる。または、第1のコンピュータにコマンドを入力することによって、通信の安全通信モードを使用可能にすることができる。次いで、使用可能にされた通信の安全通信モードに基づいて、コンピュータ・ネットワーク上の第1のコンピュータと第2のコンピュータとの間に安全通信リンクが確立される。本発明によれば、通信の安全通信モードを確立する段階に応答して第1のコンピュータに安全通信のソフトウェア・モジュールが記憶されているかどうかが判定される。次いで、このソフトウェア・モジュールが第1のコンピュータ上に記憶されていないときは、所定のコンピュータ・ネットワーク・アドレスがアクセスされ、安全通信のソフトウェア・モジュールがロードされる。その後、第1のコンピュータにプロキシ・ソフトウェア・モジュールが記憶される。安全通信リンクとは、コンピュータ・ネットワーク上の仮想専用ネットワーク通信リンクである。好ましくは、仮想専用ネットワークは、擬似乱数シーケンスに応じて変化する1つまたは複数のデータ値を、各データ・パケットに挿入することに基づいてよい。または、仮想専用ネットワークは、第2のコンピュータが、第1のコンピュータと第2のコンピュータとの間で送信される、各データ・パケット内のデータ値と妥当な値の移動ウィンドウを比較するように、第1のコンピュータと第2のコンピュータとの間で送信されるパケット内のコンピュータ・ネットワーク・アドレスまたは他のデータ値を、擬似乱数的に変化させるのに用いられる、コンピュータ・ネットワーク・アドレス・ホッピング方式に基づいてよい。さらに別の選択肢により、各データ・パケット内のディスクリミネータ・フィールドと、第1のコンピュータのために維持される妥当なディスクリミネータ・フィールドのテーブルとの比較に基づく、仮想専用ネットワークが提供される。
本発明の他の態様によれば、通信の安全通信リンク・モードに関連するセットアップ・パラメータを定義するコマンドが入力される。したがって、安全通信モードは、コンピュータ・ネットワーク上で通信リンクが確立されるときに自動的に確立される。
本発明は、コンピュータ・ネットワークとの通信リンク、およびコンピュータ・ネットワークを通して仮想専用ネットワークを確立するハイパーリンクを示すディスプレイを有する、コンピュータ・システムも提供する。仮想専用ネットワークを確立するハイパーリンクを選択すると、コンピュータ・ネットワーク上に仮想専用ネットワークが確立される。次いで、仮想専用ネットワーク通信上で、安全ドメイン名サービス（SDNS）用のコンピュータ・ネットワーク・アドレスのような、所定のコンピュータ・ネットワーク・アドレスに、非標準トップレベル・ドメイン名が送信される。
本発明は、安全非標準トップレベル・ドメイン名の安全コンピュータ・ネットワーク・アドレスを提供する、ドメイン名サービスを提供する。本発明の利点は、インターネットなどのコンピュータ・ネットワークに接続されたポータル、およびポータルを通してコンピュータ・ネットワークに接続されたドメイン名データベースを含むコンピュータ・ネットワーク用の安全ドメイン名サービスによって提供される。本発明によれば、ポータルは安全コンピュータ・ネットワーク・アドレスに関する問合せを認証し、かつドメイン名データベースはコンピュータ・ネットワーク用の安全コンピュータ・ネットワーク・アドレスを記憶する。各安全コンピュータ・ネットワーク・アドレスは、.scom、.sorg、.snet、.snet、.sedu、.smil、および.sintなどの非標準トップレベル・ドメイン名に基づくアドレスである。
本発明は、クライアント・アプリケーションがアジル・ネットワーク・プロトコルによって保護されたサーバと安全に通信することができるように、クライアント・コンピュータのアプリケーション層で既存のアプリケーション・ネットワーク・トラフィックをカプセル化する方法を提供する。本発明の利点は、インターネットなどのコンピュータ・ネットワーク上で、クライアント・コンピュータとサーバ・コンピュータとの間の専用通信リンクを使用して通信する方法によって提供される。本発明によれば、コンピュータ・ネットワーク上でクライアント・コンピュータからサーバ・コンピュータに情報パケットが送信される。情報パケットは、クライアント・コンピュータのアプリケーション層でパケットのペイロード部に挿入され、クライアント・コンピュータとサーバ・コンピュータとの間の仮想専用接続を形成するのに用いられるデータを含む。修正された情報パケットは、コンピュータ・ネットワーク上でサーバ・コンピュータに送信される前にファイアウォールを通して送信することができ、本発明は、既存のプロトコル（すなわち、UDP、ICMP、およびTCP）に作用することによって、より容易にファイアウォールを貫通する。情報パケットは、サーバ側のオペレーティング・システムのカーネル層で受信される。次いで、ホスト・コンピュータ上のオペレーティング・システムのカーネル層で、仮想専用接続を形成するのに用いられるデータを情報パケットが含むかどうかが判定される。サーバ側は、応答情報パケットのペイロード部に仮想専用接続情報を含むように、カーネル層で修正された情報パケットをクライアント・コンピュータに送信することによって応答する。好ましくは、クライアント・コンピュータからの情報パケット、およびサーバ側からの応答情報パケットはそれぞれ、UDPプロトコル情報パケットである。または、2つの情報パケットは共に、TCP/IP情報パケットであっても、ICMPプロトコル情報パケットであってもよい。
従来技術の態様によるインターネットを介した安全な通信の図である。 本発明の態様によるインターネットを介した安全な通信の図である。 本発明の態様によるトンネル化IPパケットを形成する過程の図である。 本発明の他の態様によるトンネル化IPパケットを形成する過程の図である。 本発明を実施するために使用できる過程のOSI層位置の図である。 本発明によるトンネル化パケットをルーティングする過程を示すフローチャートである。 本発明の態様による、トンネル化パケットを形成する過程を示すフローチャートである。 本発明の態様による、トンネル化パケットを受信する過程を示すフローチャートである。 クライアントとTARPルータとの間で安全なセッションを確立し同期させるにはどうすべきかを示す図である。 各コンピュータ内の送信テーブルおよび受信テーブルを使用したクライアント・コンピュータとTARPルータとの間のIPアドレス・ホッピング方式を示す。 3つのインターネット・サービス・プロバイダ（ISP）およびクライアント・コンピュータの間の物理リンク冗長性を示す。 イーサネット（登録商標）・フレームなど単一の「フレーム」に複数のIPパケットを埋め込むにはどうすべきかを示し、ディスクリミネータ・フィールドを使用して真のパケット受信側を隠すにはどうすべきかをさらに示す。 ホップされるハードウェアのアドレス、ホップされるIPアドレス、およびホップされるディスクリミネータ・フィールドを使用するシステムを示す。 ハードウェア・アドレス、IPアドレス、ディスクリミネータ・フィールドの組合せをホップするためのいくつかの異なる手法を示す。 部分的に公開される同期値を使用することによって送信側と受信側との間の同期を自動的に再確立する技法を示す。 送信側と受信側との間の同期を回復する「チェックポイント」方式を示す。 図14のチェックポイント方式の詳細を示す。 2つのアドレスを複数のセグメントに分解して存在ベクトルと比較するにはどうすべきかを示す。 受信側のアクティブ・アドレスの格納アレイを示す。 同期要求を受信した後の、受信側の格納アレイを示す。 新しいアドレスが生成された後の、受信側の格納アレイを示す。 分散送信パスを使用するシステムを示す。 図20のシステム内でパケットをルーティングするために使用できる複数のリンク送信テーブルを示す。 複数の伝送リンクに関連する重み値分布を調整するためのフローチャートを示す。 送信側がオフにされた場合に重み値をゼロに設定するためのフローチャートを示す。 各パスに関して調整された重み値分布を有する分散伝送パスを使用するシステムを示す。 図23のシステムを使用する例を示す。 従来のドメイン名参照サービスを示す。 透過的なVPN作成が可能なDNSプロキシ・サーバを使用するシステムを示す。 DNS参照機能に基づく透過的なVPN作成を実現するために実施できる段階を示す。 パケットが低帯域幅リンクLOW BWにオーバーロードされるのを防止する、リンク・ガード機能を含むシステムを示す。 図28の原則を使用するシステムの一つの態様を示す。 同期が行われる速度を落とすことによってパケット送信速度を規制するシステムを示す。 クライアント・コンピュータを有するVPNを確立するのに用いられる、シグナリング・サーバ3101および透過サーバ3102を示す。 図31の同期プロトコルに関するメッセージの流れを示す。 本発明の「ワン・クリック」通信リンクを使用するのに適した、コンピュータ・ネットワークのシステム・ブロック図である。 本発明によるコンピュータ・ネットワーク上で「ワン・クリック」安全通信リンクをインストールし、確立する場合の流れ図である。 本発明による安全ドメイン名を登録する場合の流れ図である。 本発明による専用接続を、2つのコンピュータ・ネットワーク間のファイアウォールをより容易に横切るように構成することのできる、コンピュータ・ネットワークのシステム・ブロック図である。 既存のネットワーク・プロトコルを使用してカプセル化される、仮想専用接続を確立する場合の流れ図である。
態様の詳細な説明
図2を参照するとわかるように、インターネットを介して通信する安全機構は、各ルータが、1つまたは複数のIPアドレスを有しており、かつ通常のIPプロトコルを使用して、TARPパケット140と呼ばれる、通常のパケットと同様なIPパケット・メッセージを送信するという点で、正規のIPルータ128〜132と類似している、TARPルータ122〜127と呼ばれるいくつかの特殊なルータまたはサーバを使用する。TARPパケット140は、それぞれが通常のIPパケットと同様に着信先アドレスを含むので、正規のIPルータ128〜132によってルーティングされる通常のIPパケット・メッセージと同一である。しかし、TARPパケット140 IPヘッダは、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パケットが受信されたときに割り込まれる。
・S2 TARPパケットを、リンク鍵を使用して復号することを試みる前に、何らかの方法で調べて認証することができる。すなわち、ルータは、ペイロードに含まれる暗号化されたTARPパケットに付加された平文IPヘッダと共に含まれるあるデータに対して選択された動作を実行することによって、パケットが真正なTARPパケットであることを判定することができる。これによって、真正なTARPパケットではないパケットに復号を実行することを避けることが可能になる。
・S3 TARPパケットが復号され、着信先TARPアドレスと、このパケットがデコイ・パケットであるか、それとも実際のメッセージの一部であるかが明らかになる。
・S4 このパケットがデコイ・パケットである場合、ペリッシャブル・デコイ・カウンタが増分される。
・S5 ルータは、デコイ生成／除去アルゴリズムおよびペリッシャブル・デコイ・カウンタ値に基づいて、パケットがデコイ・パケットである場合には、それを破棄することを選択することができる。受信されたパケットがデコイ・パケットであり、これを破棄すべきであると判定された場合（S6）、制御は段階S0に戻る。
・S7 TARPヘッダのTTLパラメータが減分され、TTLパラメータがゼロより大きいかどうかが判定される。
・S8 TTLパラメータがゼロよりも大きい場合、ルータによって維持されているTARPアドレスのリストからTARPアドレスが無作為に選択され、このTARPアドレスに対応するリンク鍵およびIPアドレスが、このTARPパケットを含む新しいIPパケットを作成する際に使用できるように記憶される。
・S9 TTLパラメータがゼロ以下である場合、着信先のTARPアドレスに対応するリンク鍵およびIPアドレスが、このTARPパケットを含む新しいIPパケットを作成する際に使用できるように記憶される。
・S10 TARPパケットが、記憶されたリンク鍵を使用して暗号化される。
・S11 記憶されたIPアドレスを含むパケットにIPヘッダが付加され、暗号化されたTARPパケットがIPヘッダで覆われ、完成したパケットが次のホップまたは着信先に送信される。
図6を参照するとわかるように、TARPパケットを生成する上述の方法では以下の特定の段階を使用することができる。
・S20 バックグラウンド・ループ動作が、デコイIPパケットの生成を決定するアルゴリズムを適用する。このループは、IPパケットを含むデータ・ストリームが、後で送信できるように受信されたときに割り込まれる。
・S21 受信されたIPパケットが、一定のIP着信先アドレスを有するメッセージから成る集合としてグループ化される。この集合はさらに、インタリーブウィンドウの最大サイズに一致するように分割される。集合が暗号化されインタリーブされ、TARPパケットになる予定の1組のペイロードが得られる。
・S22 IPアドレスに対応するTARPアドレスが、参照テーブルから判定され、TARPヘッダを生成するために記憶される。初期TTLカウントが生成され、ヘッダに格納される。TTLカウントは、最小値および最大値を有する無作為の値でも、あるいは一定の値でもよく、あるいは他の何らかのパラメータによって決定することができる。
・S23 ウィンドウシーケンス番号およびインタリーブ・シーケンスが各パケットのTARPヘッダに記録される。
・S24 各TARPパケットごとに1つのTARPルータ・アドレスが無作為に選択され、このアドレスに対応するIPアドレスが、平文IPヘッダで使用できるように記憶される。このルータに対応するリンク鍵が識別され、インタリーブされ暗号化されたデータおよびTARPヘッダを含むTARPパケットが、このリンク鍵を使用して暗号化される。
・S25 第1のホップ・ルータの実際のIPアドレスを有する平文IPヘッダが生成され、暗号化されたTARPパケットおよび結果として得られるパケットのそれぞれに付加される。
図7を参照するとわかるように、TARPパケットを受信する上述の方法で以下の特定の段階を使用することができる。
・S40 デコイIPパケットの生成を決定するアルゴリズムを適用するバックグラウンド・ループ動作が実行される。このループは、暗号化されたTARPパケットが受信されたときに割り込まれる。
・S42 TARPパケットが、リンク鍵を使用して復号される前に、調べられ認証される。
・S43 TARPパケットが適切なリンク鍵を用いて復号され、着信先TARPアドレスと、このパケットがデコイ・パケットであるか、それとも実際のメッセージの一部であるかが明らかになる。
・S44 このパケットがデコイ・パケットである場合、ペリッシャブル・デコイ・カウンタが増分される。
・S45 受信側は、デコイ生成／除去アルゴリズムおよびペリッシャブル・デコイ・カウンタ値に基づいて、パケットがデコイ・パケットである場合には、それを破棄することを選択することができる。
・S46 インタリーブウィンドウを形成するすべてのパケットが受信されるまでTARPパケットがキャッシュされる。
・S47 インタリーブウィンドウのすべてのパケットが受信された後、パケットがインタリーブ解除される。
・S48 次いで、インタリーブウィンドウを形成する組み合わされた各パケットのパケット・ブロックが、セッション鍵を使用して復号される。
・S49 次いで、復号されたブロックが、ウィンドウシーケンス・データを使用して分割され、IPrヘッダが通常のIPCヘッダに変化される。ウィンドウシーケンス番号がIPCヘッダに組み込まれる。
・S50 次いで、パケットがIPレイヤ・過程に渡される。
1．スケーリング可能性の向上
上述の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を受信し、妥当性を確認した後、暗号化された「安全同期確認応答」（「SSYN ACK」）822をクライアント801に送信することによって応答する。このSSYN ACK822は、クライアント801がTARPルータ811と通信するときに使用する送信ホップブロックおよび受信ホップブロックを含む。クライアント801は、その固定IPアドレスからTARPルータ811の既知の固定IPアドレスに送信される暗号化されたSSYN ACK ACKパケット823を生成することによって、TARPルータ811の応答パケット822で確認応答する。クライアント801は、SSYN ACK ACKパケットを同時に生成する。このSSYN ACKパケットは、安全セッション初期設定（SSI）パケット824と呼ばれ、TARPルータ811によってSSYN ACKパケット822内に与えられる送信ホップブロックに指定される、クライアントの送信テーブル921（図9）内の第1の｛送信側、受信側｝IPペアと共に送信される。TARPルータ811は、TARPルータの送信テーブル923内の第1の｛送信側、受信側｝IPペアと共に送信されるSSI ACKパケット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に接続することができる。この方式では、送信されるパケットが様々な物理パスの間で無作為に送信される。この構造は高度の通信冗長性を実現し、サービス拒否攻撃およびトラフィック監視に対する保護を向上させる。
2.他の拡張態様
以下に、上述の技法、システム、および方法の様々な拡張態様について説明する。上述のように、コンピュータ・ネットワーク（インターネット、イーサネット（登録商標）など）内のコンピュータ間で行われる通信のセキュリティは、ネットワークを介して送信されるデータ・パケットの、見掛け上無作為の送信元インターネット・プロトコル（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ペア（および必要に応じて、ディスクリミネータ・フィールドならびにハードウェア送信元アドレスおよびハードウェア着信先アドレス）が生成される。しかし、シーケンス全体（または最初のN−1個の値）を生成しなくてもシーケンス内の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）は次いで、RNG（1310）に送られ、IPアドレス・ペア（1311）と比較され、パケットの妥当性が確認されるか、あるいはパケットが拒絶される。
この構造の重要な点は、パブリック同期値が関与する「未来」と「過去」の概念である。スプーフィング攻撃を防止するには同期値自体が無作為の値であるべきであるが、すでに送信された同期値を含むパケットが実際には受信側によって受信されていない場合でも、受信側がこの同期値を即座に識別できることが重要である。1つの解決策として、ハッシングによってタイム・スタンプまたはシーケンス番号がパブリック同期部に付加され、したがって、このパブリック同期部を即座に抽出し、検査し、破棄し、それによってパブリック同期部自体の妥当性を確認することができる。
一つの態様では、同期フィールドによって生成された送信元／着信先IPペアを、パケット・ヘッダに示されたペアと比較することによってパケットを検査することができる。（1）ペアが一致し、（2）タイム・スタンプが妥当であり、（3）デッドマン・タイマが満了している場合、同期が取り直される。そうでない場合、パケットは拒絶される、十分な処理能力が利用できる場合、デッドマン・タイマおよび同期テーブルを回避することができ、受信側は単にあらゆるパケットに関して同期を取り直す（たとえば、妥当性を確認する）。
前述の方式では、そのインプリメンテーションに影響を与える大整数（たとえば、160ビット）計算が必要になることがある。このような大整数レジスタがない場合、スループットに影響が及び、したがって、場合によってはサービス拒否の点でセキュリティに影響が及ぶ。それにもかかわらず、大整数計算処理機能が普及すると、このような機能を実施するコストが削減される。
D．他の同期方式
上述のように、VPN内の通信側と受信側の間で、連続するW個以上のパケットが失われた場合（Wはウィンドウサイズ）、受信側のウィンドウは更新されておらず、送信側は、受信側のウィンドウに入っていないパケットは送信しない。送信側と受信側は、おそらくウィンドウ内の無作為のペアが偶然に繰り返されるまで同期を回復しない。したがって、可能なときにはいつでも送信側と受信側を同期させ、同期が失われたときは常にそれを再確立する必要がある。
同期を失った送信側と受信側の間の同期を、「チェックポイント」方式を使用して回復することができる。この方式では、無作為のIPアドレス・ペアを備えたチェックポイント・メッセージを使用して同期情報が伝達される。一つの態様では、2つのメッセージを使用して送信側と受信側の間で以下の同期情報が伝達される。
1．SYNC_REQは、送信側が同期を取る必要があることを示すために送信側によって使用されるメッセージであり、
2．SYNC_ACKは、受信側の同期が取れたことを送信側に知らせるために受信側によって使用されるメッセージである。
この手法の一変形態様によれば、送信側と受信側は共に以下の3つのチェックポイントを維持する（図14参照）。
1．送信側において、ckpt_o（「チェックポイント・オールド」）は、最後のSYNC_REQパケットを受信側に再送するために使用されたIPペアである。受信側において、ckpt_o（「チェックポイント・オールド」）は、送信側から繰り返しSYNC_REQパケットを受信するIPペアである。
2．送信側において、ckpt_n（「チェックポイント・ニュー」）は、次のSYNC_REQパケットを受信側に送信するために使用されるIPペアである。受信側において、ckpt_n（「チェックポイント・ニュー」）は、新しいSYNC_REQパケットを送信側から受信し、受信側のウィンドウを再整列させ、ckpt_oをckpt_nに設定させ、新しいckpt_nを生成させ、新しいckpt_rを生成させるIPペアである。
3．送信側において、ckpt_rは、次のSYNC_ACKパケットを受信側に送信するために使用されるIPペアである。受信側において、ckpt_rは、新しいSYNC_ACKパケットを送信側から受信し、新しいckpt_nを生成させるIPペアである。SYNC_ACKは受信側ISPから送信側ISPに送信されるので、送信側ckpt_rは受信側のckpt_rをを指し、受信側ckpt_rは送信側のckpt_rを指す（図14参照）。
送信側が同期を開始すると、送信側が次のデータ・パケットを送信するために用いるIPペアが所定の値に設定され、受信側がまずSYNC_REQを受信すると、受信側ウィンドウが、送信側の次のIPペアが中心になるように更新される。
同期はパケット・カウンタによって開始することも（たとえば、N個のパケットが送信されるたびに同期を開始する）、あるいはタイマによって開始することも（S秒おきに同期を開始する）、あるいはそれらの組合せによって開始することもできる。図15を参照されたい。送信側から見ると、この技法は以下のように作用する。（1）各送信側は、受信側が同期していることを確認するために定期的に「同期要求」メッセージを受信側に送信する。（2）受信側は、まだ同期している場合、「同期確認」メッセージを送り返す。（これがうまくいった場合、さらなる処置は必要とされない）。（3）ある期間内に「同期確認」が受信されなかった場合、送信側は同期要求を再び送信する。送信側が「同期確認」応答を受信せずに次のチェックポイントに到達した場合、同期が失われ、送信側は送信を停止する必要がある。送信側はsync_ackを受信するまでsync_reqsを送信し続け、受信した時点で送信が再確立される。
受信側から見ると、この方式は以下のように作用する。（1）受信側は、送信側から「同期要求」要求を受信すると、ウィンドウを次のチェックポイント位置へ進め（場合によっては必要に応じてペアをスキップする）、「同期応答」メッセージを送信側に送信する。同期が失われていない場合、「ジャンプ・アヘッド」によって、テーブル内の次の利用可能なアドレス・ペアに進む（すなわち、通常の前進）。
侵入者が「同期要求」メッセージを捕捉し、新しい「同期要求」メッセージを送信することによって通信の干渉を試みた場合、同期が確立されているか、あるいはこのメッセージが実際に同期を再確立する助けになる場合、このメッセージは無視される。
ウィンドウは、再同期が行われたときは常に再整列させられる。この再整列に伴い、SYNC_REQパケットが送信された直後に送信されたパケットによって使用されたアドレス・ペアにまたがるように受信側のウィンドウが更新される。通常、送信側と受信側は互いに同期させられる。しかし、ネットワーク・事象が起こった場合、再同期中に受信側のウィンドウを多数の段階分進めなければならないことがある。この場合、介在する乱数間を順次進む必要なしにウィンドウを進めることが望ましい。（この機能は、上述の自動同期手法にも望ましい）。
E．ジャンプアヘッド機能を有する乱数生成プログラム
無作為にホップされるアドレスを生成するための魅力的な方法は、送信側と受信側で同一の乱数生成プログラムを使用し、パケットが送信され受信されたときにこのプログラムを進める方法である。使用できる多数の乱数生成アルゴリズムがある。各アルゴリズムは、アドレス・ホッピング応用例に対する利点と欠点を有する。
線形乱数生成プログラム（LCR）は、明確な特徴を有する高速で簡単な乱数生成プログラムであり、効率的にn段階先にジャンプさせることができる。LCRは、以下の反復を使用してシードX0から始まる乱数X1、X2、X3、・・・、XKを生成する。
（数１）
Xi=(aXi-1＋b)mod c (1)
式中、a、b、およびcは特定のLCRを定義する符号である。Xiに関する別の数式、すなわち、
（数２）
Xi=((ai(X0＋b)−b)/(a−1))mod c (2)
によって、ジャンプアヘッド機能が有効になる。係数aiは、拘束されない場合、iが小さい場合もで非常に大きなることができる。したがって、モジュロ演算のいくつかの特殊な特性を使用して、（2）を計算するのに必要なサイズおよび処理時間を調節することができる。（2）は次式のように書くことができる。
（数３）
Xi=(ai(X0(a−1)＋b)−b/(a−1)mod c (3)
以下のことを示すことができる。
（数４）
(ai(X0(a−1)＋b)−b)/(a−1)mod c=
((aimod((a−1)c)(X0(a−1)＋b)−b)/(a−1))mod c (4)
(X0(a−1)＋b)を(X0(a−1)＋b)mod cとして記憶し、bをb mod cとして記憶し、aimod((a−1)c)を計算することができる（これには0(log(i)）回の段階が必要である）。
このアルゴリズムの実際的なインプリメンテーションは、各同期間で一定距離nだけジャンプする。これは、nパケットおきの同期に相当する。ウィンドウは、前のウィンドウが開始してからn IPペア後に開始する。ノードは、Xj w、すなわち、J番目のチェックポイントでの乱数をX0として使用し、nをiとして使用して、LCR当たり1度anmod((a−1)c)を記憶し、
（数５）
Xj+1 w=Xn(j+1)=((anmod((a−1)c)(Xj w(a−1)＋b)−b)/(a−1))mod c (5)
を、j＋1番目の同期用の乱数を生成するように設定することができる。ノードは、この構成を使用して、（nとは無関係の）一定の時間内に、各同期間で任意の（しかし、一定の）距離だけ先にジャンプすることができる。
したがって、一般に擬似乱数生成プログラム、特にLCRはそのサイクルを繰り返す。この繰返しは、IPホッピング方式の弱点となる可能性がある。すなわち、敵は、繰返しを待つだけで未来のシーケンスを予想することができる。この弱点に対処する1つの方法は、既知の長いサイクルを有する乱数生成プログラムを作成することである。無作為のシーケンスが繰り返される前に、このシーケンスを新しい乱数生成プログラムで置き換えることができる。既知の長いサイクルを有するLCRを構成することができる。このことは、現在の所、多くの乱数生成プログラムには当てはまらない。
乱数生成プログラムは、暗号に関して安全でない点がある。敵は、出力またはその一部を調べることによってRNGパラメータを導くことができる。このことはLCGに当てはまる。この弱点は、出力を乱数生成プログラムの一部とするように構成された暗号化プログラムを組み込むことによって軽減することができる。乱数生成プログラムは、敵が暗号プログラムに攻撃、たとえば既知の平文攻撃を開始するのを防止する。
F．乱数生成プログラムの例
a=31、b=4、およびc=15であるRNGについて考える。この場合、数式（1）は
（数６）
Xi=(31Xi-1＋4)mod 15 (6)
になる。
X0=1を設定した場合、数式（6）はシーケンス1、5、9、13、2、6、10、14、3、7、11、0、4、8、12を生成する。このシーケンスは無限に繰り返される。このシーケンスで3つの数だけ先にジャンプする場合、an=313=29791、c*(a−1)=15*30=450、およびan mod((a−1)c)=313mod(15*30)=29791mod(450)=91である。数式（5）は
（数７）
((91(Xi30＋4)−4)/30)mod 15 (7)
表1は、（7）のジャンプアヘッド計算を示している。この計算は、5から始まり3つ先にジャンプする。
Figure 0005374536
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から2n−1までの範囲）によってインデックス付けすることのできる長さ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つの存在ベクトルのすべてに99.9999995％よりも長い時間にわたってインデックス付けすることによって拒絶される。平均すると、有害なパケットは1.02回未満の存在ベクトル・インデックス動作で拒絶される。
高速パケット・フィルタを通過した少数の有害パケットは、一致するペアが、アクティブウィンドウ内に見つからないか、あるいはアクティブ・チェックポイントであるときに拒絶される。思いがけずヘッダに一致した有害なパケットは、VPNソフトウェアがこのヘッダの復号を試みたときに拒絶される。しかし、これらのケースは極めてまれである。空間と速度の兼合いを図るようにこの方法を構成する手段として、他に多くの方法がある。
I．他の同期拡張態様
上述の同期技法のわずかに修正された形態を使用することができる。前述のチェックポイント同期方式の基本原則は同じである。しかし、チェックポイントを受信したことによる処置はわずかに異なる。この変形態様では、受信側は、OoO（「誤った順序」）ないし2xWINDOW_SIZE＋OoO個のアクティブ・アドレスを維持する。（1≦OoO≦WINDOW_SIZEおよびWINDOW_SIZE≧1）。OoOおよびWINDOW_SIZEは、調整可能なパラメータであり、OoOは、ネットワーク内の事象または順序のずれた到着による失われたパケットに対処するのに必要なアドレスの最小数であり、WINDOW_SIZEは、SYNC_REQが発行される前に送信されたパケットの数である。図17は、受信側のアクティブ・アドレスの格納アレイを示している。
受信側は、ロードされておりアクティブである（データを受信する準備が整った）最初の2xWINDOW_SIZE個のアドレスから始まる。パケットが受信されると、対応するエントリが「使用済み」とマーク付けされ、もはやパケットを受信することはできなくなる。送信側は、最初は0に設定されるパケット・カウンタであって、SYNC_ACKが受信されたSYNC_REQの最後の初期送信以来送信されたデータ・パケットの数を含む、パケット・カウンタを維持する。送信側のパケット・カウンタがWINDOW_SIZEに等しくなると、送信側は、SYNC_REQを生成し、その初期送信を行う。受信側は、その現在のCKPT_Nに対応するSYNC_REQを受信すると、次のWINDOW_S個のアドレスを生成し、最後のアクティブ・アドレスの後の最初の位置から始まり、アレイの終了部分に到達した後でアレイの開始部分に戻る順序での、これらのアドレスのロードを開始する。受信側のアレイは、SYNC_REQが受信されたときには図18のようになる。この場合、SYNC_REQが受信されるときに、2、3のパケットが失われているか、あるいは誤った順序で受信される。
図19は、新しいアドレスが生成された後の受信側のアレイを示している。送信側は、SYNC_ACKを受信しない場合、SYNC_REQを一定の間隔で再発行する。送信側がSYNC_ACKを受信すると、パケット・カウンタがWINDOW_SIZEだけ減分される。パケット・カウンタが2xWINDOW_SIZE−OoOに到達した場合、送信側は、最終的に適切なSYNC_ACKが受信されるまでデータ・パケットの送信を停止する。送信側は次いで、データ・パケットの送信を再開する。未来の動作は主として、この初期サイクルの繰返しである。この手法の利点は以下のとおりである。
1．乱数生成プログラムにおいて効率的なジュンプアヘッドが必要とされない。
2．受信側に対応するエントリを有さないパケットが送信されることがない。
3．タイマ・ベースの再同期が不要である。これは2の結果である。
4．受信側は、最後に送信されたメッセージからOoO個以内の送信されたデータ・メッセージを受け入れる能力を常に有する。
J．分散送信パス変形態様
本発明の様々な原則を組み込んだ他の態様が図20に示されている。この態様において、メッセージ送信システムは、中間コンピュータのネットワーク2011を介して第2のコンピュータ2002と通信する第1のコンピュータ2001を含む。この態様の一変形態様では、ネットワークは、それぞれが、複数のインターネット・サービス・プロバイダ（ISP）2005から2010にリンクされた、2つのエッジ・ルータを含む。各ISPは、代表的な構成に過ぎず、制限的なものではない、図20に示す構成で他の複数のISPに結合されている。ISP間の各接続は、図20において、特定の物理的送信パスを示すように符号が付けられている（たとえば、ADは、ISP A（要素2005）をISP D（要素2008）にリンクする物理的パスである）。各エッジ・ルータに到着したパケットは、無作為選択基準または準無作為選択基準に基づいてルータが接続されているISPのうち1つに選択的に送信される。
図21に示すように、コンピュータ2001またはエッジ・ルータ2003は、パケットを送信するために使用できるIPアドレスの妥当な集合を、ネットワーク内の潜在的な各送信パスごとに識別する、複数のリンク送信テーブル2100を組み込んでいる。たとえば、ADテーブル2101は、無作為または準無作為に生成された複数のIP送信元／着信先ペアを含む。第1のコンピュータ2001から第2のコンピュータ2002へパケットを送信する際、1つのリンク・テーブルが無作為（または準無作為）に選択され、このテーブル内の次の妥当な送信先／着信先アドレス・ペアを使用して、パケットがネットワークを介して送信される。たとえば、パスADを無作為に選択した場合、（ISP A（要素2005）とISP B（要素）との間で送信することが事前に決定されている）次の送信元／着信先IPアドレス・ペアを使用してパケットが送信される。送信パスのうちの1つが劣化するか、あるいは動作不能になった場合、そのリンク・テーブルを、テーブル2105に示されているように「ダウン」状態に設定し、したがって、このテーブルからアドレスが選択されるのを防止することができる。他の送信パスが、破壊されたこのリンクの影響を受けることはない。
3．一部継続改良点
以下では、上述の態様に適用できる様々な改良および特徴について説明する。これらの改良には、（1）伝送パスの品質に応じて異なる伝送パスを超えてパケットを分配するロード・バランサと、（2）ドメイン名の問合せに応答して仮想専用網を透過的に形成するDNSプロキシ・サーバと、（3）システム・チェックポイントでのサービス拒否攻撃を防止する大小リンク帯域幅管理機能と、（4）送信側と受信側の同期をとることができる速度を制限することによって着信パケットを規制するトラフィック・リミッタと、（5）多数のノードが通信機能を2つの別々のエンティティ間で分割することによって中央ノードと通信できるようにするシグナリング・シンクロナイザとが含まれる。各改良について以下に別々に考察する。
A．ロード・バランサ
上述の様々な態様には、送信ノードと受信ノードが複数の伝送パスを通して結合されており、かつ連続するパケットが複数のパス上で準無作為的に分配されるシステムが含まれる。たとえば、図20および図21とそれに伴う説明を参照されたい。本発明の改良により、この基本概念は拡大されて、伝送リンクの品質に応じてパスに対する負荷が概ね釣り合うように、異なるパスを超えてパケットを分配する段階を包含する。
一つの態様において、システムは、場合によっては変動する送信品質を有する複数の伝送パスを介して連結された、送信ノードおよび受信ノードを含む。連続するパケットが、各パスに関する重み値分配機能に基づいて、パス上で送信される。パケットが所与のパス上で送信される速度は、各パスごとに異なる可能性がある。劣化したパスを識別するために各伝送パスの相対的な「正常性（health）」が監視される。一つの態様において、各パスの正常性は、送信されたパケットの数を、受信されたパケット肯定応答の数と比較することによって送信側において監視される。各伝送パスは、物理的に分離されたパス（たとえば、ダイヤルアップ電話回線、コンピュータ・ネットワーク、ルータ、ブリッジなど）を含んでいても、広帯域通信媒体内に含まれる論理的に分離されたパス（たとえば、FDM、TDM、CDMA、または他の種類の変調伝送リンクまたは非変調伝送リンク）を含んでいてもよい。
パスの送信品質があらかじめ決められたしきい値よりも低くなり、パケットを送信できる他のパスがあるとき、送信側はそのパスに使用されている重み値を変更し、そのパスを介して所与のパケットが送信される可能性を低くする。重みは好ましくは、パス上に公称トラフィックを維持する最小値以上に設定されると考えられる。他の利用可能なパスの重みは、影響を受けるパスの変更を補償するように改変される。送信側が同期機能によってオフにされるまでパスの品質が劣化し（すなわち、パケットが全く宛先に到着しないとき）、重みはゼロに設定される。すべての送信側がオフにされる場合、パケットは全く送信されない。
従来のTCP/IPプロトコルは、送信中に遅延またはエラーが起こっていると判定されるときにパケットの送信速度を低下させる、「スロットリング」機能を含む。この点で、場合によっては、パケットが受信されたかどうかを判定するのにタイマが用いられることがある。しかし、パケットの送信を制限するこれらの従来の技術は、他のパスに対して特定のパスを超える送信がリンクの品質に基づいて変更される、2つのノード間の複数の伝送パスを伴わない。
ある態様によれば、重みの分配が（たとえば、階段関数に従って）大幅に変更された場合に、別の方法で起こりうる発振を減衰させるために、線形減衰公式または指数減衰公式を適用して、劣化しているパスが使用されると考えられる時間にわたって重み値を減少させることができる。同様に、劣化したパスの正常性が改善される場合、そのパスの重み値は徐々に増大される。
伝送リンクの正常性は、送信ウィンドウ（上述の態様を参照）内で肯定応答されるパケットの数を、そのウィンドウ内で送信されたパケットの数と比較することによって評価することができ、かつ送信側の状態（すなわち、オンまたはオフ）によって評価することができる。言い換えれば、ある特定の実施では、パスに関してある時間にわたって総体的な送信統計を蓄積するのではなく、上述の「ウィンドウ」概念を使用して伝送パスの正常性を評価する。
「異常な」パスから「正常な」パスに仮想回線パスを移動し、新しい仮想回線用のパスを選択するのに、同じ方式を使用することができる。
図22Aには、複数の伝送リンクに関連する重み値を調整するためのフローチャートを示す。1つまたは複数のコンピュータ・ノードで実行されるソフトウェアが、図22Aに示されている各段階を実行すると仮定する。また、磁気ディスクや光ディスクなどのコンピュータ可読媒体上に、コンピュータによって実行するためのソフトウェアを記憶できると仮定する。
まず段階2201で、所与の伝送パスの送信品質が測定される。上述のように、この測定は、特定のリンク上で送信されたパケットの数とこのリンク上で受信されたパケット肯定応答信号の数との比較（たとえば、単位時間当たりや絶対項において）に基づくことができる。または、送信ウィンドウ内で肯定応答されたパケットの数を、このウィンドウ内で送信されたパケットの数と比較することによって、品質を評価することができる。別の変形態様では、受信されなかった同期メッセージの数を用いて、リンク品質を示すことができる。もちろん、他の多くの変形態様が可能である。
段階2202で、複数の送信側（たとえば、伝送パス）がオンになっているかどうかを判定する検査が行われる。複数の送信側がオンになっていない場合、この過程は終了し、段階2201から再開する。
段階2203で、リンク品質が所与のしきい値（たとえば、50％または任意の不定数）と比較される。品質がしきい値よりも低くなる場合、段階2207で、重みが最小レベル（たとえば、1％）を超えているかどうかを判定する検査が行われる。超えていない場合、段階2209で、重みが最小レベルに設定され、かつ処理が段階2201で再開する。重みが最小レベルを超えている場合、段階2208で、このパスに関して重みが徐々に減少し、次いで段階2206で、補償するように残りのパスの重みが調整される（たとえば、重みが増大する）。
段階2203でパスの品質がしきい値以上である場合、段階2204で、重みがそのパスの定常状態値より小さいかどうかを判定する検査が行われる。その場合は、段階2205で重みは定常状態値に近くなるように増大され、段階2206で、補償するように残りのパスの重みが調整される（たとえば、重みを減少させる）。段階2204で、重みが定常状態値以上である場合、処理は重みを調整せずに段階2201で再開する。
重みは、好ましくは値を徐々に変更することにより、様々な関数に従って増分的に調整することができる。一つの態様では、線形減少関数を使用して重みが調整され、別の態様によれば、指数減衰関数が使用される。重みを徐々に変更することにより、さもなければ確率が急激に変化した場合に起こりうる振動子を減衰させるのを促進することができる。
図22Aには明示的に示されていないが、過程は（たとえば、タイム・スケジュールに従って）周期的にのみ行うことができるか、またはバックグラウンド操作モードなどで連続的に動作することもできる。一つの態様では、すべての潜在的なパスの組み合わされた重みは合計で1（unity）になるべきである（たとえば、あるパスの重みを減少させると、他のパスが選択される対応する重みは増大すると考えられる）。
他のパスの重み値の調整は比例配分することができる。たとえば、あるパスの重み値を10％減少させると、残りのパスの重みに均等に増分が分配される。または、所望の加重公式（weighted formula）に応じて（たとえば、正常なパスを正常性の劣るパスよりも支持する）重みづけを調整してもよい。別の変形態様では、トラフィック重みづけに比例するように、残りのリンク上で重み値の差を償却することができる。
図22Bには、送信側がオフになる伝送リンクを遮断するために実行できる段階が示されている。段階2210で、送信側遮断事象が起こる。段階2211で、少なくとも1つの送信側が依然としてオンになるかどうかを判定する試験が行われる。オンになる送信側がない場合、段階2215で、送信側がオンになるまですべてのパケットが破棄される。段階2211で、少なくとも1つの送信側がオンになる場合、段階2212で、パスの重みがゼロに設定され、かつそれに応じて残りのパスの重みが調整される。
図23には、上述の態様の様々な原則を利用するコンピュータ・ノード2301が示されている。図23に示されている種類の2つのコンピュータ・ノードが複数の別々の物理的伝送パスを介して通信すると仮定する。図23に示されているように、4つの伝送パスX1からX4は、2つのノード間の通信に関して定義されている。各ノードは、上述の送信テーブル2308に従って作動するパケット送信側2302を含む。（パケット送信側は、上述のIPホッピング機能を使用せずに作動することもできるが、以下の説明では、パス選択機構と共に何らかの形のホッピングが使用されると仮定する）。コンピュータ・ノードは、有効なパケットが受信されたときに移動する移動ウィンドウWを含む、受信テーブル2309に従って作動するパケット受信側2303も含む。ウィンドウWに入らない送信元アドレスおよび宛先アドレスを有する無効なパケットは拒絶される。
各パケットを送信する準備が整えられると、上述の様々なアルゴリズムのうちの任意のものに従って、送信元IPアドレスおよび宛先IPアドレス（または他のディスクリミネータ値）が送信テーブル2308から選択され、4つの伝送パスが連結されているノードに対応する、これらの送信元／宛先アドレスペアを含むパケットが、伝送パス・スイッチ2307に対して生成される。ソフトウェア機能を含みうるスイッチ2307は、重み分配テーブル2306に従って利用可能な伝送パスのうちの1つを選択する。たとえば、パスX1の重みが0.2である場合、パケットはパスX1上で5つおきに送信される。図示されている他のパスに関しても同様な方式が適用される。最初は、各リンクの重み値は、帯域幅に比例するように設定することができ、これを重み値の「定常状態」値と呼ぶ。
パケット受信側2303は、上述のように作動して各伝送パスの品質を判定するリンク品質測定機能2304への出力を生成する（着信パケットを受信するパケット受信側2303への入力は、図を明確にするために省略される）。リンク品質測定機能2304は、リンク品質を各伝送リンクのしきい値と比較し、かつ必要な場合は、重み調整機能2305への出力を生成する。重み調整が必要である場合、テーブル2306内の重みがそれに応じて、好ましくは漸減（たとえば、線形減衰または指数減衰）関数に従って調整される。一つの態様では、すべての利用可能なパスの重み値は最初は、同じ値に設定され、かつパスの品質が劣化するときにのみ、重みが差を反映するように変更される。
リンク品質測定機能2304は、上述のシンクロナイザ機能の一部として作動させることができる。すなわち、再同期が行われて、同期が失われた（たとえば、結果として、順序が乱れて同期ウィンドウWが進んだ）ことを受信側が検出する場合、この事実を使用してリンク品質測定機能2304を駆動することができる。一つの態様によれば、通常の同期中に得られ、リンクの正常性を受信側から送信側に伝えるためにわずかに増大される情報を使用して、ロード・バランシングが行われる。受信側は、同期ウィンドウWで受信されたメッセージのカウント値であるMESS_R(W)を維持する。ウィンドウWの終了点に対応する同期要求（SYNC_REQ）を受信すると、受信側は送信側に送り返される、結果として得られる同期肯定応答（SYNC_ACK）にカウンタMESS_Rを含める。これによって、送信側は、送信されたメッセージを受信されたメッセージと比較して、リンクの正常性を評価することができる。
同期が完全に失われている場合、重み調整機能2305は、影響を受けるパス上の重み値をゼロに減少させる。同期が回復すると、影響を受けるパスの重み値が徐々に増大され、最初の値になる。または、受信側が同期要求に肯定応答するのに必要な時間の長さを評価することによって、リンクの品質を測定することができる。一つの態様では、各送信パスごとに別々の送信テーブルおよび受信テーブルが使用される。
送信側がSYNC_ACKを受信すると、MESS_Rが、ウィンドウ（MESS_T）内で送信されたメッセージの数と比較される。送信側がSYNC_ACKを受信すると、トラフィック確率が調べられ、必要な場合は調整されると考えられる。MESS_Rはウィンドウ（MESS_T）内で送信されたメッセージの数と比較される。以下の2つの可能性がある。
1．MESS_Rがしきい値THRESHよりも小さい場合、リンクは異常であると考えられる。送信側がオフになった場合、送信側はオンにされ、そのリンクの重みPは最小値MINに設定される。これにより、それが回復するまで、監視のためにリンク上に少量のトラフィックが維持されると考えられる。送信側がオンになった場合、そのリンクの重みPは次式のように設定されると考えられる。
（数８）
P=α×MIN＋(1−α)×P (1)
式（1）は、サービスが劣化している期間中にトラフィック重み値を指数関数的にMINまで減少させる。
2．リンクのMESS_RがTHRESH以上である場合、リンクは正常であると考えられる。そのリンクの重みPがそのリンクの定常状態値S以上である場合、Pは不変である。そのリンクの重みPがTHRESHよりも小さい場合、Pは次式のように設定されると考えられる。
（数９）
P=β×S＋(1−β)×P (2)
式中、βはPの減衰率を決定する0<=β<=1であるようなパラメータである。式（2）は、受け入れられるサービスの持続期間中に、トラフィック重みを減衰指数関数的にSまで増大させると考えられる。
次に、図24を参照して詳細な例について説明する。図24に示されているように、第1のコンピュータ2401は、2つのルータ2403および2404を通して第2のコンピュータ2402と通信する。各ルータは、3つの伝送リンクを通して他のルータに結合されている。上述のように、これらは、物理的に離散したリンクまたは（仮想専用網を含む）論理リンクでもよい。
第1のリンクL1が100Mb/sの送信帯域幅を維持することができ、かつウィンドウサイズが32であり、リンクL2が75Mb/sを維持することができ、かつウィンドウサイズが24であり、さらにリンクL3が25Mb/sを維持することができ、かつウィンドウサイズが8であると仮定する。したがって、組み合わされたリンクは200Mb/sを維持することができ、定常状態のトラフィック重みは、リンクL1に関しては0.5であり、リンクL2に関しては0.375であり、リンクL3に関しては0.125である。MIN = 1Mb/sであり、各リンクに関してTHRESH = 0.8MESS_Tであり、α=0.75およびβ=0.5である。これらのトラフィック重みは、リンクが同期をとるために停止するか、またはTHRESHよりも少ない数のパケットが受信されたことを報告するまで安定なままであると考えられる。以下の事象シーケンスを考慮されたい。
1．リンクL1は、最後のウィンドウで送信されたMESS_T(32)のメッセージの75％のみが、首尾良く受信されたことを示す、24のMESS_Rを含むSYNC_ACKを受信する。リンクL1は、THRESH(0.8)よりも低くなる。リンクL1のトラフィック重み値は0.12825まで減少する一方、リンクL2のトラフィック重み値は0.65812まで増大し、リンクL3のトラフィック重み値は0.217938まで増大すると考えられる。
2．リンクL2およびL3は正常なままであり、リンクL1は同期をとるために停止する。次いで、リンクL1のトラフィック重み値が0に設定され、リンクL2のトラフィック重み値が0.75に設定され、リンクL3のトラフィック重み値が0.25に設定されると考えられる。
3．リンクL1は、最後のウィンドウで送信されたMESS_T(32)のメッセージのうちの1つも首尾良く受信されなかったことを示す、0のMESS_Rを含むSYNC_ACKを受信する。リンクL1は、THRESHよりも低くなると考えられる。リンクL1のトラフィック重み値は0.005まで増大し、リンクL2のトラフィック重み値は0.74625まで減少し、リンクL3のトラフィック重み値は0.24875まで減少すると考えられる。
4．リンクL1は、最後のウィンドウで送信されたMESS_T(32)のメッセージのうちの100％が首尾良く受信されたことを示す、32のMESS_Rを含むSYNC_ACKを受信する。リンクL1は、THRESHを超えると考えられる。リンクL1のトラフィック重み値は0.2525まで増大する一方、リンクL2のトラフィック重み値は0.560625まで減少し、リンクL3のトラフィック重み値は0.186875まで減少すると考えられる。
5．リンクL1は、最後のウィンドウで送信されたMESS_T(32)のメッセージのうちの100％が首尾良く受信されたことを示す、32のMESS_Rを含むSYNC_ACKを受信する。リンクL1は、THRESHを超える。リンクL1のトラフィック重み値は0.37625まで増大し、リンクL2のトラフィック重み値は0.4678125まで減少し、リンクL3のトラフィック重み値は0.1559375まで減少すると考えられる。
6．リンクL1は正常なままであり、トラフィック確率はその定常状態のトラフィック確率に近づく。
B．DNSプロキシを用いて仮想専用網を透過的に作成する
第2の改良は、ドメイン名サーバ参照機能に応答して仮想専用網（VPN）を自動的に作成することに関する。
従来のドメイン名サーバ（DNS）は、要求されたコンピュータまたはホストのIPアドレスを返す参照機能を提供する。たとえば、コンピュータのユーザがウェブ名「Yahoo.com」を入力すると、ユーザのウェブブラウザがDNSに要求を送信し、それによってこのウェブ名が、ユーザのブラウザに返されて、次に宛先ウェブサイトに接触するためにブラウザによって用いられる、4分割IPアドレスに変換される。
この従来の方式を図25に示す。ユーザのコンピュータ2501は、クライアント・アプリケーション2504（たとえば、ウェブブラウザ）およびIPプロトコル・スタック2505を含む。ユーザが宛先ホストの名前を入力すると、この名前に関連するIPアドレスを参照することを求める要求DNS REQが（IPプロトコル・スタック2505を通して）、DNS 2502に対してなされる。DNSはIPアドレスDNS RESPをクライアント・アプリケーション2504に返し、IPアドレスを用いてPAGE REQおよびPAGE RESPのような別々のトランザクションを通じて、ホスト2503と通信することができる。
図25に示されている従来の構造において、インターネット上の不埒なリスナーは、DNS REQパケットおよびDNS RESPパケットを傍受し、したがってユーザがどんなIPアドレスに接触しているかを知ることができる。たとえば、ユーザが「Target.com」という名前を有するウェブサイトと、安全な通信パスを設定することを望んだ場合に、ユーザのブラウザがそのウェブサイトのIPアドレスを見出すためにDNSに接触した場合、そのウェブサイトの真のIPアドレスはDNS問合せの一部としてインターネット上で明らかにされる。これによってインターネット上の匿名の通信が阻害される。
インターネット上で安全な仮想専用網を提供する1つの従来の方式は、DNSサーバがアドレスを有するマシンの公開鍵を有するDNSサーバを提供する。このため、ホストは、ユーザに宛先ホストの公開鍵を入力させずにVPNを設定できるように、通信相手のホストの公開鍵を自動的に検索することができる。この標準の実施は現在、FreeS/WANプロジェクト（RFC2535）の一部として開発されている。
この従来の方式はある欠点を有する。たとえば、任意のユーザがDNS要求を実行することができる。さらに、DNS要求はすべてのユーザに対して同じ値になる。
本発明のある態様によれば、専用DNSサーバがDNS要求を取り込み、その要求が特別の種類のユーザに由来する要求である場合（たとえば、安全な通信サービスが規定されているユーザ）、サーバはターゲット・ノードの真のIPアドレスを返さず、その代わりに、ターゲット・ノードとユーザとの間に仮想専用網を自動的に設定する。VPNは好ましくは、上述の基本的な発明のIPアドレス「ホッピング」機能を使用して実施され、たとえ通信中のパケットが傍受されても、2つのノードの真の同一性を判定することはできないように実施される。安全なサービスを必要としないと判定されるDNS要求に関して（たとえば、未登録のユーザ）、要求するホストが安全でないサイトを解決する許可を得ているという条件で、DNSサーバは要求を透過的に「通過させ」、通常の参照機能を提供し、ターゲットウェブサーバのIPアドレスを返す。異なるユーザは同一のDNS要求を出す場合、異なる結果を提供することができる。
図26には、上記で要約した様々な原則を使用するシステムが示されている。ユーザのコンピュータ2601は、従来のクライアント（たとえば、ウェブブラウザ）2605、および好ましくは上記で概説したIPホッピング機能2607に従って作動する、IPプロトコル・スタック2606を含む。修正されたDNSサーバ2602は、従来のDNSサーバ機能2609およびDNSプロキシ2610を含む。修正されたDNSサーバと安全なターゲット・サイト2604との間にゲートキーパ・サーバ2603が挿入される。従来のIPプロトコルを介して「安全でない」ターゲット・サイト2611もアクセス可能である。
一つの態様によれば、DNSプロキシ2610は、クライアント2605由来のすべてのDNS参照機能を傍受し、安全なサイトへのアクセスが要求されたかどうかを判定する。安全なサイトへのアクセスが要求された場合（例えばドメイン名拡張、またはそのようなサイトの内部テーブルの参照によって、判定されるように）、DNSプロキシ2610は、ユーザがこのサイトにアクセスするのに十分なセキュリティ特権を有しているかどうかを判定する。十分なセキュリティ特権を有している場合、DNSプロキシ2610は、ユーザ・コンピュータ2601と安全なターゲット・サイト2604との間に仮想専用網を作成することを求めるメッセージをゲートキーパ2603に送信する。一つの態様において、ゲートキーパ2603は、安全な通信を行うためにコンピュータ2601および安全なターゲット・サイト2604によって使用される「ホップブロック」を作成する。次いで、ゲートキーパ2603はこれらをユーザ・コンピュータ2601に伝える。その後、DNSプロキシ2610は、DNSプロキシ2610に転送されて解決されたアドレス（このアドレスは実際のターゲット・コンピュータとは異なってもよい）を、ゲートキーパ2604によって好ましくは安全な管理VPNを使用してユーザ・コンピュータ2601に返す。返されたアドレスは宛先コンピュータの実際のアドレスでなくてもよい。
ユーザがサイト2611のような安全でないウェブサイトの参照を要求した場合、DNSプロキシは単に参照要求を通過させて、従来のDNSサーバ2609に送り、この要求が従来どおりに処理され、安全でないウェブサイト2611のIPアドレスを返すと考えられる。ユーザが安全なウェブサイトの参照を要求したが、そのような接続を作成するための信頼性に欠ける場合、DNSプロキシ2610は「未知のホスト」エラーをユーザに返す。このように、同じDNS名へのアクセスを要求する異なるユーザには、異なる参照結果が提供される。
ゲートキーパ2603は、（図26に示されているように）別個のコンピュータ上で実施されても、修正されたDNSサーバ2602内の機能として実施されてもよい。一般に、ゲートキーパ2703は、「ホッピングされた」IPアドレスを使用することなどにより、安全に通信するのに必要な情報の配分および交換を容易にすることが予想される。サイト2604のような安全なホストは、IPホッピング機能2608のような安全な通信機能を備えていると仮定される。
便宜上、DNSプロキシ2610およびDNSサーバ2609の機能を組み合わせて単一のサーバとすることができることが認識されると考えられる。さらに、要素2602は2つのサーバの機能を組み合わせたものとして示されているが、2つのサーバを独立に作動させることができる。
図27には、安全なホストに関するDNS参照を求める要求を処理するために、DNSプロキシ・サーバ2610によって実行できる段階が示されている。段階2701で、ターゲット・ホストに関してDNS参照要求が受信される。段階2702で、安全なホストへのアクセスが要求されたかどうかを判定する検査が行われる。安全なホストへのアクセスが要求されなかった場合、段階2703で、このDNS要求は従来のDNSサーバ2609に送られ、DNSサーバ2609はターゲット・サイトのIPアドレスを参照し、さらに処理するためにユーザのアプリケーションに返す。
段階2702で、安全なホストへのアクセスが要求された場合、段階2704で、ユーザがその安全なホストに接続することを許可されているかどうかを判定するさらなる検査が行われる。このような検査は、許可されているIPアドレスの内部に記憶されているリストを参照して行うことができるか、またはゲートキーパ2603と通信することによって行うことができる（たとえば、安全な「管理」VPN上で）。ホストの異なる範疇に対して、異なるレベルのセキュリティが提供されることは認識されると考えられる。たとえば、いくつかのサイトがあるセキュリティ・レベルを有するサイトとして指定されてもよく、かつアクセスを要求するユーザのセキュリティ・レベルはそのセキュリティ・レベルに一致しなければならない。十分な特権を有していることを証明することを求める要求メッセージを、ユーザのコンピュータに送り返すことによって、ユーザのセキュリティ・レベルを判定することもできる。
ユーザが安全なサイトにアクセスする許可を得ていない場合、「未知のホスト」メッセージが返される（段階2705）。ユーザが十分なセキュリティ特権を有する場合、段階2706で、ユーザのコンピュータと安全なターゲット・サイトとの間に安全なVPNが確立される。上述のように、これは好ましくは、ユーザのコンピュータと安全なターゲット・サイトとの間で実施されるホッピング式を配分することによって行われ、好ましくはユーザに対して透過的に実行される（すなわち、ユーザが安全なリンクを作成することに関与する必要はない）。本出願の様々な態様で説明するように、安全に通信するために様々なフィールドの任意のものが「ホッピング」されうる（たとえば、IP送信元／宛先アドレス、ヘッダ内のフィールドなど）。
ゲートキーパ2603は安全なサイトへの接続を求めるすべての要求を処理するように、いくつかまたはすべてのセキュリティ機能をゲートキーパ2603に埋め込むことができる。この態様において、DNSプロキシ2610は、ゲートキーパ2603と通信し、ユーザが特定のウェブサイトにアクセスできるかどうかを（好ましくは安全な管理VPNを介して）判定する。これらの機能を実施するための様々なシナリオを以下の例によって説明する。
シナリオ#1：
クライアントはターゲット・コンピュータにアクセスする許可を得ており、ゲートキーパはクライアント用のVPNを作るという規則を有する。このシナリオでは、クライアントのDNS要求はDNSプロキシ・サーバ2610によって受信され、DNSプロキシ・サーバ2610はこの要求をゲートキーパ2603に転送する。ゲートキーパはクライアントと要求されたターゲットとの間にVPNを確立する。ゲートキーパはDNSプロキシに宛先のアドレスを提供し、次いでDNSプロキシは結果として解決された名前を返す。解決されたアドレスは、安全な管理VPNにおいてクライアントに送り返すことができる。
シナリオ#2：
クライアントはターゲット・コンピュータにアクセスする許可を得ていない。このシナリオでは、クライアントのDNS要求はDNSプロキシ・サーバ2610によって受信され、DNSプロキシ・サーバ2610はこの要求をゲートキーパ2603に転送する。ゲートキーパはこの要求を拒絶し、ターゲット・コンピュータを見出すことができなかったことをDNSプロキシ・サーバ2610に知らせる。次いで、DNSプロキシ2610は「未知のホスト」エラー・メッセージをクライアントに返す。
シナリオ#3：
クライアントは、通常の非VPNリンクを使用して接続する許可を得ており、ゲートキーパは、ターゲット・サイトに対するクライアント用のVPNを設定するという規則を有していない。このシナリオでは、クライアントのDNS要求はDNSプロキシ・サーバ2610によって受信され、DNSプロキシ・サーバ2610はこの規則を検査し、VPNは無用であると判定する。ゲートキーパ2603は、次にDNSプロキシ・サーバに、この要求を従来のDNSサーバ2609に転送することを知らせ、DNSサーバ2609はこの要求を解決し、結果をDNSプロキシ・サーバに返して、クライアントに返す。
シナリオ#4：
クライアントは、通常／非VPNリンクを確立する許可を得ておらず、ゲートキーパは、ターゲット・サイトに対するクライアント用のVPNを作るという規則を有していない。このシナリオでは、DNSプロキシ・サーバは、クライアントのDNS要求を受信してゲートキーパ2603に転送する。ゲートキーパ2603は、特別のVPNは無用であるが、クライアントは非VPNメンバーと通信する許可を得ていないと判定する。ゲートキーパはこの要求を拒絶し、DNSプロキシ・サーバ2610にクライアントへエラー・メッセージを返させる。
C．大リンクから小リンクへの帯域幅管理
基本的な構造の1つの特徴は、コンピュータ・ハッカーが既知のインターネット・ノードにパケットをフラッドさせる場合に起こりうる、いわゆる「サービスの拒否」攻撃を防止し、したがってノードが他のノードと通信することを防止する能力である。IPアドレスまたは他のフィールドは「ホッピング」され、無効なアドレスと共に到着するパケットはただちに破棄されるので、インターネット・ノードは、単一のIPアドレスを標的としたフラッドに対して保護される。
コンピュータが、限られた帯域幅を有するリンク（たとえば、エッジ・ルータ）を通して、はるかに高い帯域幅を有するリンクをサポートできるノード（たとえば、インターネット・サービス・プロバイダ）に結合されているシステムでは、確信的なハッカーが潜在的な弱点を利用することができる。図28を参照し、第1のホスト・コンピュータ2801が、上述のIPアドレス・ホッピング原則を使用して第2のホスト・コンピュータ2804と通信すると仮定する。第1のホスト・コンピュータは、エッジ・ルータ2802を通じて低帯域幅リンク（LOW BW）を介してインターネット・サービス・プロバイダ（ISP）2803に結合されており、次にインターネットの一部を通じ高帯域幅リンク（HIGH BW）を介して第2のホスト・コンピュータ2804に結合されている。この構造において、ISPはインターネットに対して高帯域幅をサポートすることができるが、エッジ・ルータ2802に対してサポートできる帯域幅ははるかに低い。
コンピュータ・ハッカーが、第1のホスト・コンピュータ2801にアドレス指定された大量のダミー・パケットを高帯域幅リンクHIGH BWを超えて送信することができると仮定する。通常、ホスト・コンピュータは、これらのパケットがIPアドレス・ホッピング方式で許可される受入れウィンドウ内に入らないため、これらのパケットを即座に拒絶することができる。しかし、パケットは、低帯域幅リンクLOW BWを横切らなければならないため、ホスト・コンピュータ2801によって受信される前にこのより低い帯域幅リンクを占有する。したがって、ホスト・コンピュータ2801へのリンクは、パケットが破棄されうる前に事実上フラッドされる。
本発明の一つの改良によれば、低帯域幅のターゲット・ノードを宛先とするパケットが有効なパケットでない場合に、それを即座に破棄する「リンク・ガード」機能2805が、高帯域幅ノード（たとえば、ISP2803）に挿入される。低帯域幅ノードを宛先とする各パケットは、VPNに属するかどうかを判定するために暗号によって認証される。有効なVPNパケットでない場合、高帯域幅ノードで破棄される。パケットは、VPNに属すると認証された場合、高い優先順位で送られる。パケットは、有効な非VPNパケットである場合、より低い品質のサービス（たとえば、より低い優先順位））と共に送られる。
一つの態様において、ISPは、パケットのプロトコルを使用してVPNパケットと非VPNパケットを区別する。IPSEC[rfc 2401]の場合、パケットはIPプロトコル420および421を有する。TARP VPNの場合、パケットは、定義されていないIPプロトコルを有する。ISPのリンク・ガードである2805は、VPNパケットが暗合的に有効であるかどうかを検証するのに用いられる、有効なVPNテーブルを維持している。
一つの態様によれば、低帯域幅リンク上のノードによって使用されるホップウィンドウ内に入らないパケットは、拒絶されるか、またはより低い品質のサービスと共に送信される。これを行う1つの手法は、高帯域幅ノードと低帯域幅ノードの両方が、ホッピングされたパケットを追跡する（たとえば、有効なパケットが受信されたときに、高帯域幅ノードがそのホッピングウィンドウを移動させる）ように、低帯域幅ノードによって使用されるIPホッピング・テーブルのコピーを高帯域幅ノードに提供することである。このようなシナリオにおいて、高帯域幅ノードは、ホッピングウィンドウに入らないパケットが低帯域幅リンクを介して送信される前に、このようなパケットを破棄する。したがって、たとえば、ISP2903は、ホスト・コンピュータ2901によって使用される受信テーブルのコピー2910を維持する。この受信テーブル内に入らない着信パケットは破棄される。異なる態様によれば、リンク・ガード2805は、鍵をかけられたハッシュ・メッセージ認証符号（HMAC）[rfc 2104]を使用して各VPNパケットを検証する。他の態様によれば、低帯域幅ノードと高帯域幅ノードとの間の通信用に（たとえば、ホップブロックを使用する）別々のVPNを確立することができる（すなわち、高帯域幅ノードに到着するパケットは、低帯域幅ノードに送信される前に異なるパケットに変換される）。
図29に示されているように、たとえば、第1のホスト・コンピュータ2900がインターネット上で第2のホスト・コンピュータ2902と通信しており、かつパスがISP 2901への高帯域幅リンクHIGH BWおよびエッジ・ルータ2904を介する低帯域幅リンクLOW BWを含むと仮定する。上述の基本的な構造によれば、第1のホスト・コンピュータ2900および第2のホスト・コンピュータ2902はホップ・ブロック（またはホップブロック・アルゴリズム）を交換し、かつ一致する送信テーブルならびに受信テーブル2905、2906、2912、および2913を作成することができる。次に、基本的な構造によれば、2つのコンピュータは、直示的に無作為なIP送信元アドレスおよびIP宛先アドレスを有するパケットを送信し、各コンピュータは、有効なパケットが受信されたときにその受信テーブル内の対応するホッピングウィンドウを移動させる。
ある範囲のIPアドレス（たとえば、簡単にするためにアドレス100からアドレス200）を有するパケットがISP 2901に送信されており、これらのパケットが低帯域幅リンク上で転送されていることを不埒なコンピュータ・ハッカー2903が推論することができると仮定する。したがって、ハッカーのコンピュータ2903は、100から200の範囲内のアドレスを有するパケットが低帯域幅リンクLOW BWに沿って転送され、したがって低帯域幅リンクが占有されるることを予想して、それらのパケットを「フラッドさせる」ことができる。第1のホスト・コンピュータ3000内の高速パケット拒絶機構は、これらのパケットを拒絶するうえでほとんど無用である。というのは、これらのパケットが拒絶される前に低帯域幅リンクが実際上渋滞してしまうからである。しかし、改良の一つの態様によれば、VPNリンク・ガード2911は、この攻撃がVPNトラフィックの性能に影響を与えるのを防止する。なぜなら、これらのパケットは無効なVPNパケットとして拒絶されるか、または比較的狭い帯域幅を有するリンクを介してVPNトラフィックよりも低い品質のサービスが与えられるからである。しかし、サービス拒否フラッド攻撃は依然として非VPNトラフィックを妨害する。
改良の一つの態様によれば、ISP 2901は、第1のホスト・コンピュータ2900と別個のVPNを維持し、したがって、ISPに到着したパケットを、ホスト・コンピュータ2900に送信される前に異なるIPヘッダを有するパケットに変換する。リンク・ガード2911でVPNパケットを認証するのに用いられる暗号鍵と、ホスト2902およびホスト2901でVPNパケットを暗号化し復号するのに用いられる暗号鍵は、異なるものでよく、したがって、リンク・ガード2911は、専用ホスト・データにアクセスすることができず、これらのパケットを認証できるに過ぎない。
第3の態様によれば、低帯域幅ノードは、ホッピングされたパケットのみが低帯域幅ノードに転送されるように特定のIPアドレスに対するすべての送信を遮断するよう高帯域幅ノードに指示する特別のメッセージを、高帯域幅ノードに送信することができる。この態様は、ハッカーが、単一のIPアドレスを使用するパケットをフラッドさせるのを防止する。第4の態様によれば、高帯域幅ノードは、送信速度が任意の所与のIPアドレスの、あるあらかじめ決められたしきい値を超えている場合に、低帯域幅ノードに送信されたパケットを破棄するように構成することができる。これにより、ホッピングされたパケットを通過させることができる。この場合、所与のIPアドレスに対するパケットの率がしきい値率を超えていることを、リンク・ガード2911を用いて検出することができる。同じIPアドレスにアドレス指定された他のパケットは、破棄されるか、または比較的低い優先順位で送信される（たとえば、遅延される）。
D．トラフィック・リミッタ
複数のノードを「ホッピング」技術を使用して通信するシステムでは、背信的なインサイダーが内部でシステムにパケットをフラッドさせる可能性がある。この可能性を防止するために、本発明の一つの改良は、受信側が各パケット送信側に帯域幅の制限を課すことができるように、システム内のノード間に「契約」を設定する段階を伴う。これを行う1つの技術は、送信側からのチェックポイント同期要求の受入れを、ある期間が経過するまで（たとえば、1分）遅延させることである。各受信側は、「SYNC_REQ」メッセージに対する「SYNC ACK」応答を遅延させることによってホッピングウィンドウが移動する速度を実際上調節することができる。
チェックポイント・シンクロナイザを簡単に修正することにより、内部の背信的なクライアントによる、偶然または故意の過負荷から受信側を保護することができる。この修正は、ホッピングされたアドレスCKPT_Nに対するSYNC_REQが受信されるまで、受信側がテーブルを更新しないことに基づいて行われる。これは、前のチェックポイントから適切な間隔が経過するまで、新しいCKPT_Nの生成を遅延させることによって簡単に行うことができる。
受信側が送信側からの受信を毎秒100パケットに制限することを望んでおり、チェックポイント同期メッセージが50パケットごとにトリガされると仮定する。適切な送信側が新しいSYNC_REQメッセージを発行する頻度は、0.5秒おき以下である。受信側は、最後のSYNC_REQが受けいれられてから0.5秒間CKPT_Nの発行を遅延させることにより、不適切な送信側が同期をとるのを遅延させることができる。
一般に、M個の受信側が、W個のメッセージを受信するたびに新しいSYNC_REQメッセージを発行するN個の送信側を、全体として毎秒R個のメッセージの送信に制限する必要がある場合、各受信側は、最後のSYNC_REQが受信され受け入れられてからM×N×W/R秒が経過するまで、新しいCKPT_Nの発行を遅延させることができる。送信側は、一ペアのチェックポイント間でこの率を超えている場合、受信側が新しいチェックポイントを受信する準備ができる前にこのチェックポイントを発行し、SYNC_REQが受信側によって破棄される。この後、送信側はSYNC_ACKを受信するまでT1秒おきにSYNC_REQを再発行する。受信側は最終的にCKPT_Nを更新し、SYNC_REQが肯定応答される。送信速度が許容速度を大幅に超えている場合、送信側は、送信速度が適切な速度になるまで停止する。送信側が許容速度を少しだけ超えている場合、送信速度が適切な速度になるまで数回同期を遅延させられた後、最終的に停止する。遮断を行わない送信側の符号をハッキングしても、送信側に受入れウィンドウを失わせることしかできない。この場合、送信側は、送信速度が再び適切な速度になった後にのみウィンドウを回復して動作を進めることができる。
上記の方式を実施する際には、2つの実際的な問題を考慮しなければならない。
1．トラフィック到着時間の統計的な変動、およびロード・バランシングの非一様性を考慮するため、受信側の速度は許容速度よりもわずかに速くなければならない。
2．送信側は、SYNC_REQが送信されてからある期間にわたって引き続き正しく送信するので、上記のアルゴリズムは送信側の帯域幅を人為的に縮小する可能性がある。事象により、適合した送信側がある期間（たとえば、ネットワークがSYNC_REQまたはSYNC_ACKを破棄する期間）の間同期をとることができない場合、SYNC_REQが受け入れられる時間は予期されるよりも遅くなる。この後、送信側は、次のチェックポイントに出会う前に、予想されるよりも少ない数のメッセージを送信する。新しいチェックポイントは活動化されておらず、送信側はSYNC_REQを再送する必要がある。このことは、受信側からは、送信側の送信速度が不適切であるかのように見える。したがって、送信側からは、次のチェックポイントが受け入れられるのが遅くなったように見える。これは、送信側がある期間にわたって、合意されている速度よりも遅いパケット速度で送信を行うまで、送信側の許容パケット速度を低下させる効果を有する。
これを防止するために、受信側は、最後のC SYNC_REQが受信され受け入れられた回数を追跡し、CKPT_Nを活動化する時間として、最後のSYNC_REQが受信され受け入れられてからM×N×W/R秒後、最後のSYNC_REQの次のSYNC_REQが受信され受け入れられてから2×M×N×W/R秒後、最後のSYNC_REQから(C−1)番目のSYNC_REQが受信されてからC×M×N×W/R秒後の最小値を使用しなければならない。これにより、最初の試みで最後のC個のSYNC_REQのうちの少なくとも1つが処理された場合に、受信側が送信側のパケット速度を不適切に制限するのが防止される。
図30には、上述の原則を使用するシステムが示されている。図30において、2つのコンピュータ3000および3001は、上述の「ホッピング」原則（たとえば、ホッピングされたIPアドレス、ディスクリミネータ値など）に従ってネットワークNを介して通信すると仮定されている。簡単にするために、コンピュータ3000を受信側コンピュータと呼び、コンピュータ3001を送信側コンピュータと呼ぶ。ただし、もちろん全二重動作を想定する。さらに、単一の送信側しか示されていないが、複数の送信側が受信側3000に送信を行ってよい。
上述のように、受信側コンピュータ3000は、着信データ・パケットに現われたときに受け入れられる有効なIPアドレスペアを定義するウィンドウWを含む、受信テーブル3002を維持する。送信側コンピュータ3001は、受信側コンピュータ3000にパケットを送信する際に次のIPアドレスペアを選択するための送信テーブル3003を維持する。（図示のため、ウィンドウWも送信テーブル3003を基準として示されている）。送信側コンピュータは、テーブル内を移動する際、最終的に機能3010に示されているようにSYNC_REQメッセージを生成する。このメッセージは、送信側3001が（SYNC_ACKメッセージの一部として含まれる）CKPT_Nの形の応答を予期している受信テーブル3002の同期をとることを、受信側3000に求める要求である。送信側コンピュータ3001は、割り当てられているよりも多くのメッセージを送信する場合、通常よりも早くSYNC_REQメッセージを生成する。（送信側がSYNC_REQメッセージを生成しないように変更されている場合、受信側3000がウィンドウWに入らないパケットを即座に拒絶するため、送信側が同期をとることはできず、送信側3001によって生成された余分なパケットは破棄される）。
上述の改良によれば、受信側コンピュータ3000は、図30に示されているようにSYNC_REQメッセージが受信されたときにある段階を実行する。段階3004で受信側コンピュータ3000はSYNC_REQメッセージを受信する。段階3005で、要求が重複していないかどうかを判定する検査が行われる。重複している場合、段階3006で要求は破棄される。段階3007で送信側3001から受信されたSYNC_REQが、許容速度R（すなわち、最後のSYNC_REQメッセージの時間の周期）を超えた速度で受信されたかどうかを判定する検査が行われる。値Rは一定であっても、必要に応じて変動させてもよい。速度がRを超えている場合、段階3008で、次のCKPT_Nホッピング・テーブル・エントリの次の活動化が、最後のSYNC_REQが受け入れられてからW/R秒遅延される。
要求が重複していない場合、段階3109で、送信側3101からの次のSYNC_REQの前に、次のCKPT_N値が算出され受信側のホッピング・テーブルに挿入される。次いで、送信側3101はSYNC_REQを通常どおり処理する。
E．シグナリング・シンクロナイザ
多数のユーザが安全なホッピング技術を使用して中央ノードと通信するシステムでは、ホッピング・テーブルおよびそれがサポートするデータ構造用に多量のメモリを確保する必要がある。たとえば、あるウェブサイトの百万人の加入者がそのウェブサイトと時折通信する場合、そのサイトは百万個のホッピング・テーブルを維持しなければならず、したがって、任意の一時点でシステムを実際に使用するユーザが全加入者のわずかな割合に過ぎないにもかかわらず、貴重なコンピュータ資源が使い尽くされてしまう。望ましい解決策は、ある最大数の同時リンクを維持できるようにするが、数百万人の登録されたユーザを任意の一時点で「認識」するシステムである。言い換えれば、百万人の登録されたユーザのうち、1度に数千人のユーザが、適切なサイズの百万個のホッピング・テーブルをサーバに維持させる必要なしに、同時に中央サーバと通信することができる。
1つの解決策は、中央ノードを2つのノード、すなわち、ユーザのログオンおよびログオフのためのセッション開始を行う（最小限のサイズのテーブルしか必要としない）シグナリング・サーバと、ユーザ用の比較的大きなホッピング・テーブルを含むトランスポート・サーバとに分割することである。シグナリング・サーバは、数百万人の既知のユーザをリスンし、他の（不適切な）パケットの高速パケット拒絶を行う。既知のユーザからパケットが受信されると、シグナリング・サーバは、ユーザと、ホッピング・テーブルが割り当てられ維持されるトランスポート・サーバとの間の仮想専用リンク（VPL）を活動化する。ユーザがシグナリング・サーバにログオンされると、トランスポート・サーバと通信し、したがってVPLを活動化するためのホッピング・テーブルがユーザのコンピュータに与えられる。VPLは、ある期間にわたって非活動状態であったときに切り離すか、またはユーザ・ログアウト時に切り離してよい。ユーザのログオンおよびログオフを可能にするシグナリング・サーバとの通信は、上述のチェックポイント方式の専用バージョンを使用して行うことができる。
図31には、上述の原則のうちのある原則を使用するシステムが示されている。図31において、シグナリング・サーバ3101とトランスポート・サーバ3102はリンクを介して通信する。シグナリング・サーバ3101は、1つまたは複数のクライアント3103および3104に対する通信要求を認証するのに十分な情報を含む、多数の小さなテーブル3106および3107を含む。以下に詳しく説明するように、これらの小さなテーブルは、前述の同期チェックポイント・テーブルの特別な場合として構築できるので有利である。トランスポート・サーバ3102は、好ましくはシグナリング・サーバ3101と通信する独立のコンピュータであり、1つのクライアント・コンピュータを持つVPNを作成するように割り当てることができる比較的少数の比較的大きなホッピング・テーブル3108、3109、および3110を含む。
一つの態様によれば、（たとえば、システム管理機能、ユーザ登録手順、または他の何らかの方法を介して）すでにシステムに登録しているクライアントは、コンピュータ（たとえば、ウェブサイト）に情報を求める要求を送信する。一変形態様では、この要求が「ホッピングされた」パケットを使用して行われ、それによって、シグナリング・サーバ3101はハッカー・コンピュータ3105のような許可されていないコンピュータからの、無効なパケットを即座に拒絶する。ハッカーがシグナリング・サーバ3101に不適切なパケットをフラッドさせることができないように、すべてのクライアントとシグナリング・サーバとの間に「管理」VPNを確立することができる。この方式の詳細を以下に示す。
シグナリング・サーバ3101は、要求3111を受信し、それを使用してクライアント3103が無効に登録されたユーザであると判定する。次に、シグナリング・サーバ3101は、クライアント3103を含むVPNを作成するために、ホッピング・テーブル（もしくはホッピング・アルゴリズムまたは他の方式）を割り当てることを求める要求をトランスポート・サーバ3102に発行する。割り当てられたホッピング・パラメータはシグナリング・サーバ3101（パス3113）に返され、次いで、シグナリング・サーバ3101はホッピング・パラメータを好ましくは暗号形式でパス3114を介してクライアント3103に供給する。
その後、クライアント3103は、上述の通常のホッピング技術を使用してトランスポート・サーバ3102と通信する。シグナリング・サーバ3101およびトランスポート・サーバ3102は2つの別々のコンピュータとして示され、もちろん、これらを単一のコンピュータに組み合わせ、これらの機能をこの単一のコンピュータ上で実行してもよいことは認識されると考えられる。または、本発明の原則から逸脱せずに、図31に示されている機能を、図示されているのとは異なるように分割することも可能である。
上述の技術の1つの利点は、シグナリング・サーバ3101が、多数の潜在的なユーザに関して少量の情報を維持するだけでよく、それにもかかわらずハッカー・コンピュータ3105のような許可されていないユーザからのパケットを即座に拒絶する機能を保持することである。その代わり、ホッピング機能および同期機能を実行するのに必要な比較的大きなデータ・テーブルがトランスポート・サーバ3102内に維持され、これらのテーブルは、「アクティブ」リンクに割り当てられるに過ぎないので比較的少数でよい。VPNがある期間（たとえば、1時間）にわたって非活動状態であると、トランスポート・サーバ3102またはシグナリング・サーバ3101によってVPNを自動的に切り離すことができる。
次に、上述のシグナリング方式を実施するのにチェックポイント同期機能の特別なケースをどのように用いればよいかに関して詳しく説明する。
シグナリング・シンクロナイザは、多数（数百万）の固定・低帯域幅接続をサポートする場合に必要になる。したがって、シグナリング・シンクロナイザは、ホッピング技術によるセキュリティを実現しつつVPLメモリ使用量を最小限に抑えなければならない。シグナリング・サーバにおけるメモリ使用量を低減させるには、データ・ホッピング・テーブルを完全になくすか、またはデータをSYNC_REQメッセージの一部として搬送することができる。サーバ側（受信側）およびクライアント側（送信側）によって使用されるテーブルは、図31に要素3106として概略的に示されている。
CKPT_N、CKPT_O、およびCKPT_Rの意味および動作は、CKPT_Nが、データとSYNC_REQメッセージの組合せまたはデータを含まないSYNC_REQメッセージを受信できることを除いて前の説明と同じである。
このプロトコルは、前述のシンクロナイザをそのまま拡張したものである。クライアント送信側がオンであり、テーブルの同期がとられると仮定する。初期テーブルは「同期のとれていない状態で」生成することができる。たとえば、クライアントは、インターネット上にアカウントを確立するためにウェブサーバにログインすることができる。クライアントは、インターネット上で、暗号化された鍵などを受信する。その間、サーバはシグナリング・サーバ上でシグナリングVPNを設定する。
クライアント・アプリケーションが、クライアントの固定シグナリングVPL上でサーバにパケットを送信する必要があると仮定する。
1．クライアントは、送信側のCKPT_Nアドレスを使用してインナー・ヘッダ上のデータ・メッセージとしてマークされたメッセージを送信する。クライアントは、送信側をオフにし、CKPT_Oを示すタイマT1を開始する。メッセージは、3つの種類、DATA、SYNC_REQ、およびSYNC_ACKのうちの1つであってよい。通常のアルゴリズムでは、各メッセージ・タイプを暗号化されたインナー・ヘッダ・フィールドの一部として識別することによって、いくつかの潜在的な問題を防止することができる。このアルゴリズムでは、データとSYNC_REQが同じアドレスで送信されるので、シグナリング・シンクロナイザにおいてデータ・パケットとSYNC_REQを区別することが重要である。
2．サーバは、そのCKPT_N上でデータ・メッセージを受信すると、このメッセージを検証し、スタックに沿って転送する。メッセージは、インナー・ヘッダーに含まれているメッセージの種類および他の情報（すなわち、ユーザの信頼）を検査することによって検証することができる。サーバは、そのCKPT_OをCKPT_Nで置き換え、次のCKPT_Nを生成する。サーバは、その送信側CKPT_Rをクライアントの受信側CKPT_Rに対応するように更新し、ペイロード内にCKPT_Oを含むSYNC_ACKを送信する。
3．クライアント受信側が、送信側CKPT_Oと一致するペイロードを持つSYNC_ACKをCKPT_R上で受信し、送信側がオフであるとき、送信側がオンにされ、受信側CKPT_Rが更新される。SYNC_ACKのペイロードが送信側CKPT_Oと一致しないか、または送信側がオンである場合、SYNC_ACKは単に破棄される。
4．T1が満了する： 送信側がオフであり、クライアントの送信側CKPT_Oがタイマに関連するCKPT_Oに一致する場合、送信側はCKPT_Oを示すタイマT1を再開し、送信側のCKPT_Oアドレスを使用してSYNC_REQが送信される。これ以外の場合、何ら措置はとれらない。
5．サーバは、そのCKPT_N上でSYNC_REQを受信すると、そのCKPT_OをCKPT_Nで置き換え、次のCKPT_Nを生成する。サーバは、その送信側CKPT_Rをクライアントの受信側CKPT_Rに対応するように更新し、ペイロード内にCKPT_Oを含むSYNC_ACKを送信する。
6．サーバは、そのCKPT_O上でSYNC_REQを受信すると、その送信側CKPT_Rをクライアントの受信側CKPT_Rに対応するように更新し、ペイロード内にCKPT_Oを含むSYNC_ACKを送信する。
図32には、このプロトコルを強調するメッセージ・フローが示されている。上から下へ読むと分かるように、クライアントはその送信側CKPT_Nを使用してサーバにデータを送信する。クライアント送信側がオフにされ、再試行タイマがオフにされる。次いで、クライアント送信側は、CKPT_NをCKPT_Oにロードし、CKPT_Nを更新する。このメッセージは首尾良く受信され、スタックに沿って転送される。このメッセージはまた受信側を同期させ、すなわち、サーバは、CKPT_NをCKPT_Oにロードし、新しいCKPT_Nを生成し、サーバ送信側で新しいCKPT_Rを生成し、サーバ側受信側のCKPT_Oを含むSYNC_ACKを送信する。SYNC_ACKはクライアントで首尾良く受信される。クライアント受信側のCKPT_Rが更新され、送信側がオンにされ、再試行タイマが停止される。クライアント送信側は、新しいデータ・メッセージを送信する準備を整える。
次に、クライアントは、その送信側CKPT_Nを使用してサーバにデータを送信する。クライアント送信側がオフにされ、再試行タイマがオフにされる。送信側は、オフになっているかぎりメッセージを送信しない。次いで、クライアント送信側はCKPT_NをCKPT_Oにロードし、CKPT_Nを更新する。このメッセージは失われる。クライアント側タイマが満了し、その結果、クライアント送信側のCKPT_O上でSYNC_REQが送信される（これは、クライアントでSYNC_ACKが受信されるまで行われる）。SYNC_REQはクライアントで首尾良く受信される。SYNC_REQは受信側を同期させ、すなわちサーバは、CKPT_NをCKPT_Oにロードし、新しいCKPT_Nを生成し、サーバ送信側で新しいCKPT_Rを生成し、サーバ側受信側のCKPT_Oを含むSYNC_ACKを送信する。SYNC_ACKはクライアントで首尾良く受信される。クライアント受信側のCKPT_Rが更新され、送信側がオンにされ、再試行タイマが停止される。クライアント送信側は、新しいデータ・メッセージを送信する準備を整える。
このフローの後に続く他の多数のシナリオがある。たとえば、SYNC_ACKが失われる可能性がある。送信側は、受信側が同期し応答するまでSYNC_REQを再送し続ける。
上述の手順では、シグナリング・サーバ3201が、ハッカー・コンピュータ3205によって生成されるような、無効なパケットを即座に拒絶する能力を維持しつつ、シグナリング・サーバでクライアントを認証することができる。様々な態様において、シグナリング・シンクロナイザはシンクロナイザを模倣したものである。シグナリング・シンクロナイザは、ホッピング・プロトコルと同じ保護を提供し、多数の低帯域幅接続に対してこれを行う。
F．ワン・クリック安全オンライン通信および安全ドメイン名サービス
本発明は、コンピュータ・ネットワーク上の第1のコンピュータと第2のコンピュータとの間で、安全通信リンクを確立する技術を提供する。好ましくは、ユーザは、マウスの1回のクリック、またはキーボード上で入力されるキーストロークやトラックボールを通じて入力されるクリックのような、他の入力装置からの対応する最小入力を用いて、安全通信リンクを使用可能にする。または、安全リンクは、コンピュータの立ち上げ時にデフォルト設定として自動的に確立される（すなわち、クリックなし）。図33は、本発明のワン・クリック安全通信方法が適切である、コンピュータ・ネットワークのシステム・ブロック図3300である。図33において、パーソナル・コンピュータ（PC）などのコンピュータ端末またはクライアント・コンピュータ3301は、ISP3303を通じてインターネットなどのコンピュータ・ネットワーク3302に接続されている。または、コンピュータ3301は、エッジ・ルータを通してコンピュータ・ネットワーク3302に接続することができる。コンピュータ3301は、キーボードおよび／またはマウスなどの入力装置、およびモニタなどの表示装置を含む。インストールされて、公知の方法でコンピュータ3301上で動作するブラウザ3306を使用して、コンピュータ3301は従来どおり、通信リンク3305を介してコンピュータ・ネットワーク3302に接続された、他のコンピュータ3304と通信することができる。
コンピュータ3304はたとえば、電子商取引を行うのに用いられるサーバ・コンピュータであってよい。コンピュータ・ネットワーク3302がインターネットである状況では、コンピュータ3304は通常、.com、.net、.org、.edu、.mil、または.govなどの標準トップレベル・ドメイン名を有する。
図34は、本発明によるコンピュータ・ネットワーク上に「ワン・クリック」安全通信リンクをインストールし、かつ確立する場合の、流れ図3400である。段階3401で、コンピュータ3301は非VPN通信リンク3305を介して、サーバ・コンピュータ3304に接続される。ウェブブラウザ3306は、公知の方法でサーバ3304に関連付けされたウェブページを表示する。本発明の一つの変形によれば、コンピュータ3301のディスプレイは、コンピュータ・ネットワーク3302を通して端末3301とサーバ3304との間で仮想専用ネットワーク（VPN）通信リンク（「ゴー・セキュア(go secure)」ハイパーリンク）を選択するためのハイパーリンク、またはハイパーリンクを表すアイコンを含む。好ましくは、「ゴー・セキュア」ハイパーリンクは、サーバ・コンピュータ3304からダウンロードされるウェブページの一部として表示され、それによって、エンティティ提供サーバ3304がVPN機能も実現することを示す。
コンピュータ3301のユーザは、「ゴー・セキュア」ハイパーリンクを表示することによって、コンピュータ3301とサーバ・コンピュータ3304との間の現在の通信リンクが、非安全非VPN通信リンクであることを知る。段階3402で、コンピュータ3301のユーザが「ゴー・セキュア」ハイパーリンクを選択したかどうかが判定される。選択していない場合、非安全（従来型の）通信方法（図示せず）を使用して処理が再開する。段階3402で、ユーザが「ゴー・セキュア」ハイパーリンクを選択したと判定された場合、流れは段階3403に進み、そこでコンピュータ3301上にVPN通信ソフトウェア・モジュールがインストールされている、とハイパーリンクに関連するオブジェクトが判定する。または、ユーザがコンピュータ3301に「ゴー・セキュア」コマンドを入力することができる。
段階3403で、ソフトウェア・モジュールがインストールされているとオブジェクトが判定した場合、流れは段階3407に進む。段階3403で、ソフトウェア・モジュールがインストールされていないとオブジェクトが判定した場合、流れは段階3404に進み、そこでコンピュータ・ネットワーク3302上のコンピュータ3301とウェブサイト3308との間で、公知の方法で非VPN通信リンク3307が開始される。ウェブサイト3308は、非VPN通信リンクを通してコンピュータ・ネットワーク3302に接続されたすべてのコンピュータ端末からアクセス可能である。ウェブサイト3308に接続された後、コンピュータ・ネットワーク3302上に安全通信リンクを確立するソフトウェア・モジュールをダウンロードし、インストールすることができる。流れは段階3405に進み、そこでコンピュータ3301がウェブサイト3308に接続された後、通信リンクを確立するソフトウェア・モジュールがダウンロードされ、公知の方法でコンピュータ端末3301上にソフトウェア・モジュール3309としてインストールされる。段階3405で、ユーザは、コンピュータ・ネットワーク3302上のすべての通信リンク用の通信の安全通信モードを使用可能にするように、ソフトウェア・モジュール用のパラメータを任意に選択することができる。次いで、段階3406で、コンピュータ3301とウェブサイト3308との間の通信リンクが公知の方法で終了する。
コンピュータ3301のユーザは、「ゴー・セキュア」ハイパーリンクをクリックすることによって、コンピュータ3301とサーバ・コンピュータ3304との間で、通信の安全通信モードを使用可能にした。本発明の一変形態様によれば、ユーザは、「ゴー・セキュア」ハイパーリンクをクリックするだけでよい。ユーザが、ユーザ識別情報、パスワード、または安全通信リンクを確立する暗号化鍵を入力する必要はない。コンピュータ3301とサーバ・コンピュータ3304との間に安全通信リンクを確立するのに必要なすべての手順は、コンピュータ3301のユーザに対して透過的に実行される。
段階3407で、安全VPN通信動作モードが使用可能にされており、ソフトウェア・モジュール3309はVPN通信リンクの確立を開始する。一態様において、ソフトウェア・モジュール3309は、ブラウザ3406内のサーバ3304のトップレベル・ドメイン名を、サーバ・コンピュータの安全トップレベル・ドメイン名で自動的に置き換える。たとえば、サーバ3304のトップレベル・ドメイン名が.comである場合、ソフトウェア・モジュール3309は.comトップレベル・ドメイン名を.scomトップレベル・ドメイン名で置き換える。この場合、「s」は安全（secure）を表す。または、ソフトウェア・モジュール3409は、サーバ3304のトップレベル・ドメイン名を他の非標準トップレベル・ドメイン名で置き換えることができる。
安全トップレベル・ドメイン名が非標準ドメイン名であるため、標準ドメイン名サービス（DNS）に対する問合せは、URLが不明であることを示すメッセージを返す。本発明によれば、ソフトウェア・モジュール3409は、安全トップレベル・ドメイン名のURLを得るために、安全ドメイン名サービス（SDNS）に問い合わせるためのURLを含む。この点において、ソフトウェア・モジュール3309は、安全ネットワーク3311をコンピュータ・ネットワーク3302に接続する、安全ポータル3310にアクセスする。安全ネットワーク3311は、内部ルータ3312、安全ドメイン名サービス（SDNS）3313、VPNゲートキーパ3314、および安全プロキシ3315を含む。安全ネットワークは、eメール3316、複数のチャットルーム（1つのチャットルーム3317しか示されていない）、および標準ドメイン名サービス（STD DNS）3318のような他のネットワーク・サービスを含みうる。もちろん、安全ネットワーク3311は、図33に示されていない他のリソースおよびサービスを含んでよい。
ソフトウェア・モジュール3309が、サーバ3304の標準トップレベル・ドメイン名を安全トップレベル・ドメイン名で置き換えると、ソフトウェア・モジュール3309は、段階3408で、好ましくは管理VPN通信リンク3319を使用して、安全ポータル3310を通してSDNS3313に問合せを送信する。この構成では、安全ポータル3310はVPN通信リンクを用いた場合にのみアクセスすることができる。好ましくは、このようなVPN通信リンクは、擬似乱数シーケンス；クライアント・コンピュータと安全ターゲット・コンピュータとの間で送信されるパケット内のIPアドレスを擬似乱数的に変更する、IPアドレス・ホッピング方式；既知のシーケンスに従った一連のデータ・パケット内の少なくとも1つのフィールドの周期的な変更；第2のコンピュータのテーブルに維持されている妥当なIPアドレスのテーブルと比較される各データ・パケットのヘッダ内のインターネット・プロトコル（IP）アドレス、および／または各データ・パケットのヘッド内のアドレスと妥当なIPアドレスの移動ウィンドウとの比較に従って選択される各データ・パケットに、送信元・宛先IPアドレス対を挿入し、かつおよび移動ウィンドウに入らないIPアドレスを有するデータ・パケットを拒絶する技術に基づくリンクであってよい。他の種類のVPNを使用することもできる。安全ポータル3310は、VPN通信リンク3319に用いられる特定の情報ホッピング技術に基づいて、ソフトウェア・モジュール3309からの問合せを認証する。
SDNS3313は、安全ドメイン名および対応する安全ネットワーク・アドレスの相互参照データベースを含む。すなわちSDNS3313は、各安全ドメイン名ごとに、安全ドメイン名に対応するコンピュータ・ネットワーク・アドレスを記憶する。エンティティは、エンティティのウェブサイトとの安全通信リンクを望むユーザが、この安全ウェブサイトの安全コンピュータ・ネットワーク・アドレスを自動的に得ることができるように、SDNS3313に安全ドメイン名を登録することができる。さらにエンティティは、各々がアクセス・レベル階層における安全ウェブサイトへのアクセスの異なる優先順位レベルを表す、複数の安全ドメイン名を登録することができる。たとえば、証券取引ウェブサイトは、ウェブサイトにサービスを求めたことに対する拒否が、安全ウェブサイト・サービスに加入しているユーザに対して無効になるように、ユーザ安全アクセスを提供することができる。たとえば、手数料に基づいて様々な加入レベルを設けることができ、したがって、ユーザは安全証券取引ウェブサイトに接続するための所望の保証レベルを選択することができる。ユーザが証券取引ウェブサイトの安全コンピュータ・ネットワーク・アドレスについてSDNS3313に問い合わせると、SDNS3313は、ユーザのIDおよびユーザの加入レベルに基づいて特定の安全コンピュータ・ネットワーク・アドレスを判定する。
段階3409で、SDNS3313は、ソフトウェア・モジュール3309と安全サーバ3320との間にVPN通信リンクを確立する場合、VPNゲートキーパ3314にアクセスする。サーバ3320にはVPN通信リンクによってのみアクセスすることができる。VPNゲートキーパ3314は、コンピュータ3301および安全ウェブサーバ・コンピュータ3320、または安全コンピュータ3320の安全エッジ・ルータに関する準備をし、それによってVPNを作成する。安全サーバ・コンピュータ3320は、サーバ・コンピュータ3304とは別のサーバ・コンピュータであっても、サーバ・コンピュータ3322によって示されるような、非VPN通信リンク機能とVPN通信リンク機能の両方を有する、同じサーバ・コンピュータであってもよい。図34に戻ると分かるように、段階3410で、SDNS3313は、サーバ3304に対応する安全サーバ3320の.scomサーバ・アドレスを求める安全URLを、ソフトウェア・モジュール3309に返す。
または、安全ポータル3310を通して「平文で（in the clear）」、すなわち、管理VPN通信リンクを使用せずに、SDNS3313にアクセスすることができる。この状況では、安全ポータル3310は好ましくは、問合せをSDNS3319に送信できるようにする前に、暗号化技術のような公知の技術を使用して問合せを認証する。この状況での初期通信リンクはVPN通信リンクではないので、問合せに対する応答は「平文」であってよい。問合せ側コンピュータは、平文の問合せを用いて所望のドメイン名とのVPNリンクを確立することができる。または、SDNS3313に対する問合せは平文であってよく、SDNS3313およびゲートキーパ3314は、応答を送信するために問合せ側コンピュータとのVPN通信リンクを確立するよう動作することができる。
段階3411で、ソフトウェア・モジュール3309は、VPNゲートキーパ3314に割り当てられたVPNリソースに基づくVPN通信リンク3321を通して、安全サーバ3320にアクセスする。段階3412で、ウェブブラウザ3306は、サーバ3320との現在の通信リンクが安全VPN通信リンクであることを示す、安全アイコンを表示する。サーバ3301とコンピュータ3320との間のさらなる通信は、たとえば上記で論じた「ホッピング」方式を使用して、VPNを介して行われる。段階3413でVPNリンク3321が終了すると、流れは段階3414に進み、そこでソフトウェア・モジュール3309が安全トップレベル・ドメイン名を、サーバ3304の対応する非安全トップレベル・ドメイン名で自動的に置き換える。ブラウザ3306は、標準DNS3325にアクセスしてサーバ3304の非安全URLを得る。次いで、ブラウザ3306は公知の方法でサーバ3304に接続する。段階3415で、ブラウザ3306は、端末3301とサーバ3304との間のVPN通信リンクを選択するための「ゴー・セキュア」ハイパーリンク、またはアイコンを表示する。この場合も「ゴー・セキュア」ハイパーリンクを表示することにより、ユーザは現在の通信リンクが非安全非VPN通信リンクであることを知る。
ソフトウェア・モジュール3309をインストールしているとき、またはユーザがオフラインであるとき、ユーザは、コンピュータ・ネットワーク3302上で確立されているすべての通信リンクが安全通信リンクであることを任意に指定することができる。したがって、通信リンクが確立されているときはいつでも、リンクはVPNリンクである。したがって、ソフトウェア・モジュール3309は、SDNS3313に透過的にアクセスし、選択された安全ウェブサイトのURLを得る。言い換えれば、一態様において、ユーザは安全通信を行うたびに安全オプションを「クリック」する必要はない。
さらに、コンピュータ3301のユーザは、プロキシ・コンピュータ3315を通して、安全通信リンクを任意に選択することができる。したがってコンピュータ3301は、プロキシ・コンピュータ3315を通して安全サーバ・コンピュータ3320とのVPN通信リンク3323を確立することができる。または、コンピュータ3301は、非安全サーバ・コンピュータ3304などの非安全ウェブサイトとの非VPN通信リンク3324を確立することができる。
図35は、本発明による安全ドメイン名を登録する場合の流れ図3500を示している。段階3501で、要求側はウェブサイト3308にアクセスし、ウェブサイト3308を通して利用可能な安全ドメイン名登録サービスにログインする。段階3502で要求側は、.com、.net、.org、.edu、.mil、または.govなどのトップレベル・ドメイン名を有する安全ドメイン名を登録するための、オンライン登録フォームを完成する。もちろん、他の安全トップレベル・ドメイン名を使用してもよい。好ましくは要求側は、要求されている同等な安全ドメイン名に対応する非安全ドメイン名をすでに登録している必要がある。たとえば、安全ドメイン名「website.scom」の登録を試みる要求側は、対応する非安全ドメイン名「website.com」をすでに登録している必要がある。
段階3503で、ウェブサイト3308での安全ドメイン名登録サービスは、たとえば、要求された安全ドメイン名に対応する非安全ドメイン名に関する所有権情報を判定するためのwhois問合せを使用して、標準DNS3322などの非安全ドメイン名サーバ・データベースに問い合わせる。段階3504で、ウェブサイト3308での安全ドメイン名登録サービスは、標準DNS3322から応答を受信し、段階3505で、対応する非安全ドメイン名の矛盾する所有権情報があるかどうかを判定する。矛盾する所有権情報がない場合、流れは段階3507に進み、矛盾する所有権情報がある場合は、段階3506に進み、そこで矛盾する所有権情報が要求側に提供される。流れは段階3502に戻る。
段階3505で矛盾する所有権情報がないとき、安全ドメイン名登録サービス（ウェブサイト3308）は、矛盾する所有権情報がないことを要求側に知らせ、オンライン・フォームに入力された情報を検証し、承認されている支払いフォームを選択するよう要求側に促す。入力された情報および適切な支払い情報を確認した後、流れは段階3508に進み、そこで新たに登録された安全ドメイン名が通信リンク3326を介してSDNS3313に送信される。
段階3505で、要求された安全ドメイン名が対応する同等な非安全ドメイン名を有さない場合、本発明は要求側にこの状況を知らせ、かつ料金の増加に関して、対応する同等な非安全ドメイン名を得るよう要求側に促す。この申し出を受け入れることによって、本発明は、対応する同等な非安全ドメイン名を標準DNS3325に公知の方法で自動的に登録する。次いで、流れは段階3508に進む。
G．ウェブプロキシを使用した既存のプロトコルによるトネリング安全アドレス・ホッピング・プロトコル
本発明は、2つのコンピュータ・ネットワーク間のファイアウォールのクライアント側のアプリケーション・プログラム、およびファイアウォールのサーバ側のネットワーク・スタックにおいて、上述のフィールド・ホッピング方式を実施する技術も提供する。本発明は、サービス拒絶機能を適切に拒否する新しい安全無接続プロトコルを、ICMPプロトコル、UDPプロトコル、TCPプロトコルのような既存のIPプロトコル上に、このプロトコル層を形成することによって使用する。
本発明によれば、ローカル・ブラウザ・アプリケーションからの、暗号化されておらず保護されていない通信パケットを受け入れるクライアント側プロキシ・アプリケーション・プログラムによって、通信が保護される。クライアント側プロキシ・アプリケーション・プログラムは、暗号化されておらず保護されていない通信パケットを、新しいプロトコルによってトネリングし、それによってサーバ側でのサービスの拒否から通信を保護する。もちろん、暗号化されておらず保護されていない通信パケットを、トネリングの前に暗号化しておいてもよい。
クライアント側プロキシ・アプリケーション・プログラムは、オペレーティング・システムの拡張機能ではなく、オペレーティング・システムのネットワーク・スタックおよびドライバの修正を必要としない。したがって、クライアントは、VPNと比べてインストール、除去、および維持が容易である。さらに、クライアント側プロキシ・アプリケーションは、ファイアウォールのずっと小さな「穴」を用いて共同ファイアウォールを通過することができ、プロトコル層VPNを共同ファイアウォールを通過させる場合と比べて、セキュリティ・リスクの可能性が低い。
本発明のサーバ側インプリメンテーションは、標準仮想専用ネットワークと同様に、サーバ・パケット処理の非常に早いうちに、フィールド・ホッピングされた妥当なパケットを妥当または無効であると認証し、通常のTCP/IP通信およびHTTP通信と比べて、サービスを要求して拒否されることの影響を最小限に抑え、それによってサーバを無効な通信から保護する。
図36は、コンピュータ・ネットワーク3600のシステム・ブロック図であり、本発明による仮想専用接続は、2つのコンピュータ・ネットワーク間のファイアウォールをより容易に横切るように構成することができる。図37は、既存のネットワーク・プロトコルを用いてカプセル化された、仮想専用接続を確立する場合の流れ図3700である。
図36では、ファイアウォール構成3603を通して、インターネットのような他のコンピュータ・ネットワーク3602にローカル・エリア・ネットワーク（LAN）3601が接続されている。ファイアウォール構成は、LAN3601とコンピュータ・ネットワーク3602を相互接続し、LAN3601の外側で開始された攻撃からLAN3601を保護するように公知の方法で動作する。
LAN3601にはクライアント3604が公知の方法で接続されている。クライアント・コンピュータ3604は、オペレーティング・システム3605とおよびウェブブラウザ3606を含む。オペレーティング・システム3605は、クライアント・コンピュータ3604を動作させるカーネル・モード機能を実現する。ブラウザ3606は、公知の方法でLAN3601およびコンピュータ・ネットワーク3602に接続された、コンピュータ・ネットワーク・リソースにアクセスするアプリケーション・プログラムである。本発明によれば、クライアント・コンピュータ3604上にプロキシ・アプリケーション3607も記憶されており、このアプリケーションは、アプリケーション層でブラウザ3606と共に動作する。プロキシ・アプリケーション3607は、クライアント・コンピュータ3604内のアプリケーション層で動作し、使用可能にされると、LAN3601またはコンピュータ・ネットワーク3602に接続されたクライアント・コンピュータ3604とサーバ・コンピュータとの仮想専用接続を形成するのに用いられるメッセージ・パケットにデータを挿入することにより、ブラウザ3606によって生成された保護されておらず暗号化されていないメッセージ・パケットを修正する。本発明によれば、仮想専用接続が、仮想専用ネットワークと同じセキュリティ・レベルをクライアント・コンピュータに対して実現することはない。仮想専用接続は好都合なことに、たとえば、サービス攻撃に対する拒否を迅速に拒絶できるように認証することができ、それによってユーザが加入できる様々なレベルのサービスを提供する。
プロキシ・アプリケーション3607は、クライアント・コンピュータ3604内のアプリケーション層で動作するため、ユーザによって都合よくインストールおよびアンインストールされる。インストール時には、プロキシ・アプリケーション3607は好ましくは、すべてのウェブ通信にプロキシ・アプリケーションを使用するようにブラウザ3606を構成する。すなわち、すべてのメッセージ・パケットのペイロード部が、クライアント・コンピュータ3604とサーバ・コンピュータとの間の仮想専用接続を形成するためのデータを用いて修正される。好ましくは、仮想専用接続を形成するためのデータは、上記でVPNに関連して説明したフィールド・ホッピング・データを含む。または、修正されたメッセージ・パケットはTCP/IPプロトコルまたはICMPプロトコルと一致することができる。または、たとえばブラウザ3606から提供されるオプションによって、プロキシ・アプリケーション3606を選択し使用可能にすることができる。さらに、クライアント・コンピュータ3604と、指定されたホスト・コンピュータとの間に仮想専用接続を形成するためのデータにより、特別に指定されたメッセージ・パケットのペイロード部のみが修正されるように、プロキシ・アプリケーション3607を使用可能にすることができる。特別に指定されるメッセージ・パケットはたとえば、選択された所定のドメイン名であってよい。
図37を参照すると分かるように、段階3701で、保護されておらず暗号化されていないメッセージ・パケットがブラウザ3606によって生成される。段階3702で、プロキシ・アプリケーション3607は、クライアント・コンピュータ3604と宛先サーバ・コンピュータとの間に仮想専用接続を形成するためのデータをペイロード部にトネリングすることによって、すべてのメッセージ・パケットのペイロード部を修正する。段階3703で、修正されたメッセージ・パケットが、コンピュータ・ネットワーク3602上でクライアント・コンピュータ3604から、たとえばウェブサイト（サーバ・コンピュータ）3608に送信される。
ウェブサイト3608は、VPNガード部3609、サーバ・プロキシ部3610、およびウェブサーバ部3611を含む。VPNガード部3609は、ウェブサイト3608に対する大きな帯域幅の攻撃が迅速に拒絶されるように、ウェブサイト3608のオペレーティング・システムのカーネル層内に埋め込まれている。クライアント・コンピュータ3604が、ウェブサイト3608との認証された接続を開始すると、VPNガード部3609が、クライアント・コンピュータ3604からのメッセージ・パケットに含まれるホッピング・シーケンスによって調節され、それにより、段階3704でウェブサイト3608に入るクライアント・パケット・ストリームの強力な認証を実行する。VPNガード部3609は、加入しているサービス・レベルに応じて様々なレベルの認証を行い、したがって様々なレベルの品質を提供するように構成することができる。すなわち、VPNガード部3609は、サービス攻撃の拒否が検出されるまですべてのメッセージ・パケットを通過させ、拒否された場合、本発明の調節されたホッピング・シーケンスのようなホッピング・シーケンスに一致する、クライアント・パケット・ストリームのみを許可するように、構成することができる。
サーバ・プロキシ部3610もウェブサイト3608内のカーネル層で動作し、VPNレベルでクライアント・コンピュータ3604からの着信メッセージ・パケットを取り込む。段階3705で、サーバ・プロキシ部3610は、IPアドレス、UDPポート、およびディスクリミネータ・フィールドを用いてホスト・コンピュータ3604内のカーネル・レベルでメッセージ・パケットを認証する。次いで、認証されたメッセージ・パケットは、通常のTCP ウェブトランザクションとしてウェブサーバ部3611に転送される。
段階3705で、ウェブサーバ部3611は、メッセージ・パケットの特定の性質に従って、クライアント・コンピュータ3604から受信されたメッセージ・パケットに、応答メッセージ・パケットを生成することによって応答する。たとえば、クライアント・コンピュータがウェブページを要求すると、ウェブサーバ部3611は、要求されたウェブページに対応するメッセージ・パケットを生成する。段階3706で、応答メッセージ・パケットはサーバ・プロキシ部3610を通過し、サーバ・プロキシ部3610は、コンピュータ・ネットワーク3602上のホスト・コンピュータ3608とクライアント・コンピュータ3604との間に仮想専用接続を形成するのに用いられるデータを、メッセージ・パケットのペイロード部に挿入する。好ましくは、仮想専用接続を形成するためのデータは、上記でVPNに関連して説明したようなフィールド・ホッピング・データを含む。サーバ・プロキシ部3610は、応答メッセージ・パケットのペイロード部に仮想専用接続データを挿入するように、ホスト・コンピュータ内のカーネル層で動作する。好ましくは、ホスト・コンピュータ3608によってクライアント・コンピュータ3604に送信される修正されたメッセージ・パケットは、UDPプロトコルに従う。または、修正されたメッセージ・パケットがTCP/IPプロトコルまたはICMPプロトコルに従ってよい。
段階3707で、修正されたパケットは、コンピュータ・ネットワーク3602上でホスト・コンピュータ3608から送信され、ファイアウォール3603を通過する。修正されたパケットは、ファイアウォール3603を通過した後、LAN3601上でクライアント・コンピュータ3604に送られ、段階3708で、プロキシ・アプリケーション3607によりクライアント・コンピュータ3604内のアプリケーション層で受信される。プロキシ・アプリケーション3607は、修正されたメッセージ・パケットを迅速に評価し、受信されたパケットを受け入れるべきかそれとも破棄すべきかを判定するように動作する。受信された情報パケットに挿入された仮想専用接続データが、予想される仮想専用接続データと一致している場合、受信されたパケットは受け入れられる。一致していない場合、受信されたパケットは破棄される。
図示された態様に関連して本発明を説明したが、本発明の真の趣旨および範囲から逸脱せずに修正を加えられることが認識され、理解されると考えられる。

Claims (16)

  1. クライアントによって送信されたドメイン名サーバ（DNS）要求を傍受しかつ傍受されたDNS要求それぞれに対して以下の段階を実施するDNSプロキシ・モジュールを記憶しているメモリを含む、データ処理装置：
    （i）傍受されたDNS要求が安全サーバに対応しているかどうかを判定する段階；
    （ii）傍受されたDNS要求が安全サーバに対応していない場合、該DNS要求を、安全でないコンピュータのIPアドレスを返すDNS機能に転送する段階；および
    （iii）傍受されたDNS要求が安全サーバに対応している場合、クライアントと安全サーバとの間の安全通信リンクを自動的に開始する段階。
  2. 段階（iii）が以下の段階を含む、請求項1記載のデータ処理装置：
    （a）クライアントが安全サーバへのアクセスを許可されているかどうかを判定する段階；および
    （b）クライアントが安全サーバへのアクセスを許可されている場合、安全サーバとクライアントとの間の安全通信リンクを確立することを求める要求を送信する段階。
  3. 段階（iii）が以下の段階をさらに含む、請求項2記載のデータ処理装置：
    （c）クライアントが安全サーバへのアクセスを許可されていない場合、クライアントに「未知のホスト」エラー・メッセージを返す段階。
  4. ユーザがURLを入力した結果前記DNS要求が生じるウェブブラウザを、クライアントが含む、請求項3記載のデータ処理装置。
  5. クライアントと安全サーバとの間の安全通信リンクを自動的に開始する段階が、クライアントと安全サーバとの間のIPアドレス・ホッピング方式を確立する段階を含む、請求項1記載のデータ処理装置。
  6. クライアントと安全サーバとの間の安全通信リンクを自動的に開始する段階が、安全サーバの真のIPアドレスをクライアントに送信することを回避する、請求項1記載のデータ処理装置。
  7. 実行されるとデータ処理装置に以下の段階を実施させるコンピュータ可読命令で構成されたドメイン名サーバ（DNS）プロキシ・モジュールを記憶している、コンピュータ可読媒体：
    （i）クライアントにより送信されたDNS要求を傍受する段階；
    （ii）傍受されたDNS要求が安全サーバに対応しているかどうかを判定する段階；
    （iii）傍受されたDNS要求が安全サーバに対応していない場合、該DNS要求を、安全でないコンピュータのIPアドレスを返すDNS機能に転送する段階；および
    （iv）傍受されたDNS要求が安全サーバに対応している場合、クライアントと安全サーバとの間の安全通信リンクを自動的に開始する段階。
  8. 段階（iv）が以下の段階を含む、請求項7記載のコンピュータ可読媒体：
    （a）クライアントが安全サーバへのアクセスを許可されているかどうかを判定する段階；および
    （b）クライアントが安全サーバへのアクセスを許可されている場合、安全サーバとクライアントとの間の安全通信リンクを確立することを求める要求を送信する段階。
  9. 段階（iv）が以下の段階をさらに含む、請求項8記載のコンピュータ可読媒体：
    （c）クライアントが安全サーバへのアクセスを許可されていない場合、クライアントに「未知のホスト」エラー・メッセージを返す段階。
  10. ユーザがURLを入力した結果前記DNS要求が生じるウェブブラウザを、クライアントが含む、請求項9記載のコンピュータ可読媒体。
  11. クライアントと安全サーバとの間の安全通信リンクを自動的に開始する段階が、クライアントと安全サーバとの間のIPアドレス・ホッピング方式を確立する段階を含む、請求項7記載のコンピュータ可読媒体。
  12. クライアントと安全サーバとの間の安全通信リンクを自動的に開始する段階が、安全サーバの真のIPアドレスをクライアントに送信することを回避する、請求項7記載のコンピュータ可読媒体。
  13. 実行されるとデータ処理装置に以下の段階を実施させるコンピュータ可読命令で構成されたドメイン名サーバ（DNS）モジュールを記憶している、コンピュータ可読媒体：
    （i）クライアントにより送信されたDNS要求が安全サーバに対応しているかどうかを判定する段階；
    （ii）該DNS要求が安全サーバに対応していない場合、該DNS要求を、安全でないコンピュータのIPアドレスを返すDNS機能に転送する段階；および
    （iii）該DNS要求が安全サーバに対応している場合、クライアントと安全サーバとの間の安全チャネルを自動的に作成する段階。
  14. 段階（iii）が以下の段階を含む、請求項13記載のコンピュータ可読媒体：
    （a）クライアントが安全サーバへのアクセスを許可されているかどうかを判定する段階；および
    （b）クライアントが安全サーバへのアクセスを許可されている場合、安全サーバとクライアントとの間の安全チャネルを確立することを求める要求を送信する段階。
  15. 段階（iii）が以下の段階をさらに含む、請求項14記載のコンピュータ可読媒体：
    （c）クライアントが安全サーバへのアクセスを許可されていない場合、クライアントに「未知のホスト」エラー・メッセージを返す段階。
  16. ユーザがURLを入力した結果前記DNS要求が生じるウェブブラウザを、クライアントが含む、請求項15記載のコンピュータ可読媒体。
JP2011085052A 2000-04-26 2011-04-07 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良 Expired - Lifetime JP5374536B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US55820900A 2000-04-26 2000-04-26
US09/558,209 2000-04-26

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2001583006A Division JP4756811B2 (ja) 2000-04-26 2001-04-25 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良

Publications (3)

Publication Number Publication Date
JP2011182427A JP2011182427A (ja) 2011-09-15
JP2011182427A5 JP2011182427A5 (ja) 2013-01-10
JP5374536B2 true JP5374536B2 (ja) 2013-12-25

Family

ID=24228599

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2001583006A Expired - Lifetime JP4756811B2 (ja) 2000-04-26 2001-04-25 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2010239225A Expired - Lifetime JP5377455B2 (ja) 2000-04-26 2010-10-26 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2011085051A Expired - Lifetime JP5374535B2 (ja) 2000-04-26 2011-04-07 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2011085052A Expired - Lifetime JP5374536B2 (ja) 2000-04-26 2011-04-07 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良

Family Applications Before (3)

Application Number Title Priority Date Filing Date
JP2001583006A Expired - Lifetime JP4756811B2 (ja) 2000-04-26 2001-04-25 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2010239225A Expired - Lifetime JP5377455B2 (ja) 2000-04-26 2010-10-26 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2011085051A Expired - Lifetime JP5374535B2 (ja) 2000-04-26 2011-04-07 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良

Country Status (4)

Country Link
EP (10) EP2421220A1 (ja)
JP (4) JP4756811B2 (ja)
AU (1) AU2001259141A1 (ja)
WO (1) WO2001086911A2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100023620A1 (en) * 2004-12-22 2010-01-28 Matsushita Electric Industrial Co., Ltd. Access controller
GB2423220B (en) * 2005-02-11 2009-10-07 Ericsson Telefon Ab L M Method and apparatus for ensuring privacy in communications between parties
US9059884B2 (en) * 2011-01-20 2015-06-16 Openwave Mobility, Inc. Routing of IP traffic directed at domain names using DNS redirection
US9270684B2 (en) 2013-04-17 2016-02-23 Globalfoundries Inc. Providing a domain to IP address reputation service
SE542300C2 (en) * 2015-03-09 2020-04-07 Saab Ab Secure data transfer
CN109428916B (zh) * 2017-08-25 2022-02-22 中兴通讯股份有限公司 数据传输方法和装置、终端及服务器

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05152587A (ja) * 1991-11-26 1993-06-18 Seikosha Co Ltd Ｍｉｓダイオード
US5588060A (en) * 1994-06-10 1996-12-24 Sun Microsystems, Inc. Method and apparatus for a key-management scheme for internet protocols
US5689566A (en) * 1995-10-24 1997-11-18 Nguyen; Minhtam C. Network with secure communications sessions
US6058250A (en) * 1996-06-19 2000-05-02 At&T Corp Bifurcated transaction system in which nonsensitive information is exchanged using a public network connection and sensitive information is exchanged after automatically configuring a private network connection
US5870610A (en) * 1996-06-28 1999-02-09 Siemens Business Communication Systems, Inc. Autoconfigurable method and system having automated downloading
US5805820A (en) * 1996-07-15 1998-09-08 At&T Corp. Method and apparatus for restricting access to private information in domain name systems by redirecting query requests
GB2317792B (en) * 1996-09-18 2001-03-28 Secure Computing Corp Virtual private network on application gateway
US6101543A (en) * 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
US6032118A (en) * 1996-12-19 2000-02-29 Northern Telecom Limited Virtual private network service provider for asynchronous transfer mode network
TW338865B (en) * 1997-06-03 1998-08-21 Philips Eloctronics N V Authentication system
SE9702385L (sv) * 1997-06-23 1998-12-24 Ericsson Telefon Ab L M Förfarande och anordning i ett datanät
US6061796A (en) * 1997-08-26 2000-05-09 V-One Corporation Multi-access virtual private network
US6023764A (en) * 1997-10-20 2000-02-08 International Business Machines Corporation Method and apparatus for providing security certificate management for Java Applets
GB2334181B (en) * 1998-02-06 2003-02-19 Nec Technologies Over-the-air re-programming of radio transceivers
JPH11266240A (ja) * 1998-03-16 1999-09-28 Mitsubishi Electric Corp 暗号通信処理装置
US6557037B1 (en) * 1998-05-29 2003-04-29 Sun Microsystems System and method for easing communications between devices connected respectively to public networks such as the internet and to private networks by facilitating resolution of human-readable addresses
US6502135B1 (en) * 1998-10-30 2002-12-31 Science Applications International Corporation Agile network protocol for secure communications with assured system availability

Also Published As

Publication number Publication date
EP1755315A3 (en) 2010-07-07
EP2323335A3 (en) 2011-12-28
EP2421220A1 (en) 2012-02-22
EP2421219A1 (en) 2012-02-22
EP1755315A2 (en) 2007-02-21
JP5377455B2 (ja) 2013-12-25
EP1302047B1 (en) 2012-08-01
EP2424187A3 (en) 2012-04-25
EP1755307B1 (en) 2019-06-05
JP2011205644A (ja) 2011-10-13
EP2512093B1 (en) 2019-12-04
WO2001086911A2 (en) 2001-11-15
EP1755307A2 (en) 2007-02-21
EP2323335B1 (en) 2020-04-08
EP1302047A2 (en) 2003-04-16
EP1755307A3 (en) 2010-07-21
EP2323335A2 (en) 2011-05-18
EP2424187A2 (en) 2012-02-29
JP4756811B2 (ja) 2011-08-24
JP2011109651A (ja) 2011-06-02
AU2001259141A1 (en) 2001-11-20
JP2004507909A (ja) 2004-03-11
WO2001086911A3 (en) 2003-02-06
EP2312808A1 (en) 2011-04-20
EP2512093A1 (en) 2012-10-17
EP2375672A1 (en) 2011-10-12
JP2011182427A (ja) 2011-09-15
JP5374535B2 (ja) 2013-12-25

Similar Documents

Publication Publication Date Title
JP5478698B2 (ja) 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP3923312B2 (ja) システム可用性が保証された安全な通信を可能にするアジル・ネットワーク・プロトコルの改良
JP5685326B2 (ja) 保証されたシステム可用性を有する安全な通信のためのアジル・ネットワーク・プロトコル
US10187387B2 (en) Method for establishing connection between devices
US10511573B2 (en) Agile network protocol for secure communications using secure domain names
US9967240B2 (en) Agile network protocol for secure communications using secure domain names
JP5374536B2 (ja) 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120502

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120525

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121119

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121212

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130311

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130314

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130611

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130822

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130920

R150 Certificate of patent or registration of utility model

Ref document number: 5374536

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term