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

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

Info

Publication number
JP2003535560A
JP2003535560A JP2002501144A JP2002501144A JP2003535560A JP 2003535560 A JP2003535560 A JP 2003535560A JP 2002501144 A JP2002501144 A JP 2002501144A JP 2002501144 A JP2002501144 A JP 2002501144A JP 2003535560 A JP2003535560 A JP 2003535560A
Authority
JP
Japan
Prior art keywords
domain name
packet
secure
computer
address
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.)
Granted
Application number
JP2002501144A
Other languages
English (en)
Other versions
JP5095900B2 (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 JP2003535560A publication Critical patent/JP2003535560A/ja
Application granted granted Critical
Publication of JP5095900B2 publication Critical patent/JP5095900B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

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/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
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • 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
    • 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/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Landscapes

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

Abstract

(57)【要約】 インターネットなどのコンピュータ・ネットワークに接続されたポータル、およびポータルを通してコンピュータ・ネットワークに接続されたドメイン名データベースを含む、コンピュータ・ネットワーク用の安全ドメイン名サービスを開示する。ポータルは、安全コンピュータ・ネットワーク・アドレスに関する問合せを認証し、かつドメイン名データベースは、コンピュータ・ネットワーク用の安全コンピュータ・ネットワーク・アドレスを記憶する。それぞれの安全コンピュータ・ネットワーク・アドレスは、.scom、.sorg.、.snet、.sedu、.smil、および.sintなどの、非標準トップレベル・ドメイン名に基づく。

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端末によって参照テーブル（LU
T）を使用して相関付けることができる。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端末でデータをインタリーブ解除する
ための方式またはデータ、実行すべきホップの数を示すタイム・ツー・リブ（TT
L）パラメータ、ペイロードがたとえば、TCPデータを含むか、それともUDPデー
タを含むかを示すデータ・タイプ識別子、送信側のTARPアドレス、着信先TARPア
ドレス、パケットが実際のデータを含むか、それともデコイ・データを含むかに
関するインディケータ、またはデコイ・データがTARPペイロード・データを通じ
てある方法で流布される場合にデコイ・データを除去する方式を含むべきである
。
【００１６】 本明細書ではセッション鍵に関してチェーン・ブロック暗号化を論じているが
、任意の暗号化方法を使用できることに留意されたい。好ましくは、チェーン・
ブロック暗号化と同様に、暗号化過程の結果全体が得られないかぎり許可されな
い復号が困難にする方法を使用すべきである。したがって、暗号化されたブロッ
クを複数のパケット間で分離し、侵入者がすべてのそのようなパケットにアクセ
スするのを困難にすることによって、通信のコンテンツに特別なセキュリティ・
レイヤが与えられる。
【００１７】 ピーク・ツー・アベレージ・ネットワーク負荷を低減させることによってトラ
フィック分析を無効にするための助けになるように、デコイ・データまたはダミ
ー・データをストリームに付加することができる。インターネット内のある点で
の通信バーストを他の点での通信バーストに結合して通信エンドポイントを知る
ことができなくなるように、時間またはその他の基準に応答して低トラフィック
期間中により多くのデコイ・データを生成する能力をTARP過程に付与することが
望ましい。
【００１８】 ダミー・データは、データをより多くの目立たないサイズのパケットに分割し
て、インタリーブウィンドウのサイズを大きくすることを可能にし、同時に各パ
ケットごとに合理的なサイズを維持するうえでも助けになる。（パケット・サイ
ズは、単一の標準サイズでよく、あるいは一定の範囲のサイズから選択すること
ができる。）各メッセージを複数のパケットに分割することが望ましい1つの主
要な理由は、インタリーブの前にチェーン・ブロック暗号化方式を使用して第1
の暗号化レイヤが形成される場合に明らかである。メッセージの一部または全体
に単一のブロック暗号化を適用し、次いでその部分または全体をインタリーブし
ていくつかの別々のパケットを得ることができる。パケットのアジルIPルーティ
ングと、それに伴い、パケットのシーケンス全体を再構成して、ブロック暗号化
された単一のメッセージ要素を形成するのが困難であることを考えると、デコイ
・パケットがデータ・ストリーム全体を再構成することの困難さを著しく増大さ
せることがわかる。
【００１９】 上記の方式は、データ・リンク層と、TARPシステムに参加している各サーバま
たは端末のネットワーク層との間で動作する過程によって完全に実施することが
できる。上述の暗号化システムはデータ・リンク層とネットワーク層との間に挿
入することができるので、暗号化された通信をサポートするうえで使用される過
程は、IP（ネットワーク）層以上での過程に対して完全に透過的であってよい。
TARP過程は、データ・リンク層の過程に対しても完全に透過的であってよい。し
たがって、ネットワーク層以上での動作も、データ・リンク層以下での動作も、
TARPスタックを挿入することの影響を受けない。これにより、（たとえば、ハッ
カーによる）ネットワーク層への許可されないアクセスの困難さが大幅に増大す
るので、ネットワーク層以上でのすべての過程に追加のセキュリティがもたらさ
れる。セッション層で実行される新たに開発されたサーバの場合でも、セッショ
ン層よりも下のすべての過程が侵害される可能性がある。この構造では、セキュ
リティが分散されることに留意されたい。すなわち、たとえば、移動中の管理職
によって使用されるノートブック・コンピュータは、セキュリティを損なうこと
なくインターネットを介して通信することができる。
【００２０】 TARP端末およびTARPルータによるIPアドレス変更は、一定の間隔または無作為
の間隔で行うことも、あるいは「攻撃」が検出されたときに行うこともできる。
IPアドレスを変更することにより、どのコンピュータが通信しているかを知るこ
とのできるトラフィック分析が抑制され、攻撃に対するある程度の保護ももたら
される。攻撃に対する保護の程度は、ホストのIPアドレスが変更される率にほぼ
比例する。
【００２１】 前述のように、IPアドレスは攻撃に応答して変更することができる。たとえば
、ルータがある方法で調べられていることを示す組織だった一連のメッセージに
よって、攻撃を知ることができる。攻撃が検出されると、TARP層過程は、そのIP
アドレスを変更することによってこの事象に応答することができる。また、TARP
層過程は、最初のIPアドレスを維持し、ある方法で攻撃者との対話を続けるサブ
過程を作成することができる。
【００２２】 デコイ・パケットは、アルゴリズムによって決定されるある基準に従って各TA
RP端末によって生成することができる。たとえば、アルゴリズムは、端末がアイ
ドル状態であるときに無作為にパケットを生成することを要求するランダム・ア
ルゴリズムでよい。あるいは、アルゴリズムは、時間または低トラフィックの検
出に応答して低トラフィック時により多くのデコイ・パケットを生成することが
できる。パケットが好ましくは、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プロトコル情報
パケットであってもよい。
【００３１】態様の詳細な説明 図2を参照するとわかるように、インターネットを介して通信する安全機構は
、各ルータが、1つまたは複数のIPアドレスを有しており、かつ通常のIPプロト
コルを使用して、TARPパケット140と呼ばれる、通常のパケットと同様なIPパケ
ット・メッセージを送信するという点で、正規のIPルータ128〜132と類似してい
る、TARPルータ122〜127と呼ばれるいくつかの特殊なルータまたはサーバを使用
する。TARPパケット140は、それぞれが通常のIPパケットと同様に着信先アドレ
スを含むので、正規のIPルータ128〜132によってルーティングされる通常のIPパ
ケット・メッセージと同一である。しかし、TARPパケット140 IPヘッダは、IP
ヘッダの着信先フィールドで最終着信先を示す示すのではなく、常に、一連のTA
RPルータ・ホップ内の次のホップまたは最終着信先、すなわちTARP端末110を指
し示す。TARPパケットのヘッダが次のホップ着信先のみを含むため、着信先は常
に、次のホップTARPルータおよび最終着信先、すなわちTARP端末110であるので
、傍受されたTARPパケットにはそのTARPパケットの真の着信先を明白に示すもの
がない。
【００３２】 各TARPパケットの真の着信先は、リンク鍵146を使用して生成された暗号化ア
ウタ・レイヤに隠される。リンク鍵146は、発信元TARP端末100と着信先TARP端末
110を接続するホップのチェーン内の単一のリンクのエンド・ポイント（TARP端
末またはTARPルータ）間の暗号化された通信に使用される暗号化鍵である。各TA
RPルータ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つの既知のT
ARPルータに送信し、このTARPルータは、メッセージを受信し、その妥当性を確
認した後、前述のTARPアドレスの新しいIPアドレスでルータ自体のLUTを更新す
る。TARPルータは次いで、同様なメッセージを作成し、他のTARPルータがLUTを
更新できるようにそれらのTARPルータにこのメッセージをブロードキャストする
。所与のサブネット上のTARPルータの総数は比較的小さいことが予期されるので
、この更新過程は比較的高速であるべきである。しかし、この過程は、比較的小
数のTARPルータおよび／または比較的多数のクライアントがあるときにはうまく
作用しないことがある。このため、この構造はスケーリング可能性を実現するよ
うに改良されている。この改良によって、後述の第2の態様が得られた。
【００４９】 TARP過程は、攻撃を検出したときに、最初のIPアドレスを維持し、攻撃者との
対話を続けるサブ過程を作成することもできる。この対話によって、攻撃者を追
跡するか、あるいは攻撃者の方法を研究する機会を得ることができる（金魚鉢の
ことを海と「考えている」が、実際には捕えられ観察されている金魚鉢内の小さ
な魚にたとえて「フィッシュボウリング」と呼ばれる）。攻撃者と破棄された（
フィッシュボウルされた）IPアドレスとの間の通信の履歴を、人間が分析できる
ように記録または送信するか、あるいはある方法で応答するためにさらに合成す
ることができる。
【００５０】 上述のように、TARP端末またはTARPルータによって発信データにデコイまたは
ダミー・データまたはパケットを付加することができる。このようなデコイ・パ
ケットは、より多くの別々のパケットにデータを好都合に分散するだけでなく、
トラフィック分析の試みを無効にする助けになるようにインターネットのイナク
ティブ部分上の付加を均一にすることもできる。
【００５１】 デコイ・パケットは、アルゴリズムによって決定されるある基準に従って各TA
RP端末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パラメータがゼロよりも大きい場合、ルータによって維持されているT
ARPアドレスのリストから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アドレスが、参照テーブルから判定され、TAR
Pヘッダを生成するために記憶される。初期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 インタリーブウィンドウを形成するすべてのパケットが受信されるまでT
ARPパケットがキャッシュされる。 ・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ルータ
を判定し、かつパケットの次のホップを何にすべきかを判定することである。TA
RPルータは次いで、無作為のTARPルータにパケットを転送するか、あるいは送信
先ルータがリンク・ベースのIPホッピング通信を確立させる着信先TARPルータに
パケットを転送する。
【００６５】 図8は、クライアント・コンピュータ801およびTARPルータ811が安全なセッシ
ョンを確立するにはどうすべきかを示している。クライアント801は、TARPルー
タ811とのHOPセッションを確立する際、TARPルータ811に「安全同期」要求（「S
SYN」）パケット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ルータは、そのTA
RPルータとの安全なセッションを行っているか、あるいはそのTARPルータを通し
て安全なセッションを行っている各クライアントごとに別々の送信テーブル・受
信テーブル・ペアを維持する。
【００６８】 クライアントは、それをインターネットにリンクするクライアントのホップブ
ロックを第1のサーバから受信し、それに対して、ルータはホップブロックを交
換する。ルータが他のルータとのリンク・ベースのIPホッピング通信方式を確立
すると、ペア交換の各ルータはその送信ホップブロックを交換する。各ルータの
送信ホップブロックは他方のルータの受信ホップブロックになる。ルータ間の通
信は、クライアントが第1のルータにパケットを送信する例で説明したように管
理される。
【００６９】 上記の方式はIP環境でうまく作用するが、インターネットに接続される多くの
ローカル・ネットワークはイーサネット・システムである。イーサネットでは、
既知の過程（「アドレス分解プロトコル」および「逆アドレス分解プロトコル」
）を使用して着信先装置のIPアドレスをハードウェア・アドレスに変換しなけれ
ばならず、その逆もまた同様である。しかし、リンク・ベースのIPホッピング方
式を使用する場合、相関過程が厄介なものになる。リンク・ベースのIPホッピン
グ方式の代替態様はイーサネット・ネットワーク内で使用することができる。こ
の解決策では、インターネットをイーサネットにリンクするノード（ボーダー・
ノードと呼ぶ）が、リンク・ベースのIPホッピング通信方式を使用してイーサネ
ットLANの外部のノードと通信できるようにする。イーサネットLAN内で、各TARP
ノードは、従来どおりにアドレス指定される単一のIPアドレスを有する。LAN内T
ARPノードは、｛送信側、受信側｝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はフレーム・ヘッダ1
101および埋め込まれた2つのIPパケットIP1およびIP2を備え、それに対して、第
2のイーサネット・フレーム1160は異なるフレーム・ヘッダ1104および単一のIP
パケットIP3を備えている。各フレーム・ヘッダは一般に、送信元ハードウェア
・アドレス1101Aおよび着信先ハードウェア・アドレス1101Bを含む。図11では、
図を明確にするためにフレーム・ヘッダ内の他の公知のフィールドは省略されて
いる。物理通信チャネルを介して通信する2つのハードウェア・ノードは、チャ
ネルまたはネットワーク上のどのノードがフレームを受信すべきかを示す適切な
送信元ハードウェア・アドレスおよび着信先ハードウェア・アドレスを挿入する
。
【００７６】 悪意あるリスナーが、IPパケット自体ではなく（あるいはそれに加えて）ロー
カル・ネットワーク上のフレームを調べることによって、フレームの内容および
／またはそのフレームの通信者に関する情報を得ることが可能である。このこと
は、フレームを生成したマシンのハードウェア・アドレスおよびフレームが送信
されるマシンのハードウェア・アドレスをフレーム・ヘッダに挿入する必要があ
る、イーサネットなどのブロードキャスト媒体に特に当てはまる。ネットワーク
上のすべてのノードは場合によっては、ネットワークを介して送信されるすべて
のパケットを見ることができる。これは、特に、情報交換を行っているのは誰か
を第三者が識別できることを通信者が望んでいない場合に、安全な通信に対する
問題となる恐れがある。この問題に対処する1つの方法は、アドレス・ホッピン
グ方式をハードウェア層に拡張することである。本発明の様々な態様によれば、
ハードウェア・アドレスは、IPアドレスを変更するために使用される方法と同様
な方法で「ホップされ」、したがって、リスナーは、特定のメッセージを生成し
たのはどのハードウェア・ノードであるかを判定することも、あるいは所期され
ている受信側はどのノードであるかを判定することもできない。
【００７７】 図12Aは、イーサネットなどのネットワーク上のセキュリティを向上させるた
めに媒体アクセス制御（「MAC」）ハードウェア・アドレスが「ホップされる」
システムを示している。この説明ではイーサネット環境の例示的なケースを引用
するが、本発明の原則は他の種類の通信媒体にも同様に適用することができる。
イーサネットの場合、送信側および受信側のMACアドレスは、イーサネット・フ
レームに挿入され、そのフレームのブロードキャスト範囲内にいるLAN上のあら
ゆる人によって見ることができる。安全な通信を実現する場合、特定の送信側や
受信側に帰属しないMACアドレスを持つフレームを生成することが望ましくなる
。
【００７８】 図12Aに示すように、コンピュータ・ノード1201および1202はイサーネットな
どの通信チャネルを介して通信する。各ノードは、それぞれ通信ソフトウェア12
04および1217によりパケットを送信することによって通信する1つまたは複数の
アプリケーション・プログラム1203および1218を実行する。アプリケーション・
プログラムの例にはビデオ会議、eメール、文書処理プログラムなどが含まれる
。通信ソフトウェア1204および1217は、たとえば、様々な機能レベルで実現され
る様々なサービスを標準化するOSI層化構造または「スタック」を備えることが
できる。
【００７９】 通信ソフトウェア1204および1217の最下位レベルはそれぞれ、ハードウェア構
成要素1206および1214と通信し、各構成要素は、様々な通信プロトコルに従って
ハードウェアを再構成または制御できるようにする1つまたは複数のレジスタ120
7および1215を含むことができる。ハードウェア構成要素（たとえば、イーサネ
ット・ネットワーク・インタフェース・カード）は通信媒体を介して互いに通信
する。各ハードウェア構成要素には通常、そのハードウェア構成要素をネットワ
ーク上の他のノードへに対して識別する固定ハードウェア・アドレスまたはMAC
番号が事前に割り当てられる。以下に詳しく説明するように、本発明の原則の様
々な態様は、1つまたは複数のアルゴリズムと、受信されたパケットの妥当性を
確認するためにある範囲の妥当なアドレスを追跡する1つまたは複数の移動ウィ
ンドウを使用して、様々なアドレスの「ホッピング」を可能にする。本発明の1
つまたは複数の原則に従って送信されるパケットは一般に、マシンによって相関
付けされた通常のアドレスを使用して平文で送信される通常のデータ・パケット
と区別するために「安全な」パケットまたは「安全な通信」と呼ばれる。
【００８０】 帰属不能なMACアドレスを生成する1つの簡単な方法はIPホッピング方式の拡張
態様である。この場合、同じLAN上の2つのマシンは、安全に通信して乱数発生プ
ログラムおよびシードを交換し、同期式ホッピングのための準無作為MACアドレ
スのシーケンスを作成する。この場合、インプリメンテーションおよび同期の問
題はIPホッピングの同じ問題と類似している。
【００８１】 しかし、この手法では、LAN上で現在アクティブなMACアドレスが使用される恐
れがあり、それによって、これらのマシンの通信が中断される可能性がある。イ
ーサネットMACアドレスが現在の所、長さが48ビットであるので、アクティブなM
ACアドレスが無作為に乱用される可能性は実際には極めて低い。しかし、この数
字に（広範囲のLANで見られるような）多数のノードの数、（パケット音声また
はストリーミング・ビデオの場合のような）多数のフレームの数、および多数の
並行仮想専用網（VPN）の数を乗じた場合、アドレス・ホッピングされるフレー
ムで安全でないマシンのMACアドレスが使用される可能性は無視できないものに
なる。簡単に言えば、LAN上の他のマシンの通信を中断する可能性が少しでもあ
るあらゆる方式は、先見の明のあるシステム管理者から反対を受ける。それにも
かかわらず、これは技術的に実施可能であり、マシンの数が少ないLAN上で安全
に実施することができ、あるいはLAN上のすべてのマシンがMACホップ通信を行う
場合に安全に実施することができる。
【００８２】 同期式MACアドレス・ホッピングは、セッションを確立する際、特に通信に関
与する複数のセッションまたは複数のノードがある場合、ある程度のオーバヘッ
ドを伴うことがある。MACアドレスを無作為化するより簡単な方法は、各ノード
がネットワーク上で発生したあらゆるフレームを受信し処理できるようにするこ
とである。通常、各ネットワーク・インタフェース・ドライバは、発生したあら
ゆるフレームのヘッダ内の着信先MACアドレスを検査し、そのマシンのMACアドレ
スに一致するかどうかを調べる。一致しない場合、このフレームは破棄される。
しかし、一つの態様では、これらの検査を無効化することができ、発生したあら
ゆるパケットがTARPスタックに渡され処理される。これは、発生したあらゆるフ
レームが処理されるので「プロミスキュアス」モードと呼ばれる。プロミスキュ
アス・モードでは、着信先マシンがフレームを確実に処理できるので、送信側は
、同期の取れていない完全に無作為のMACアドレスを使用することができる。パ
ケットの着信先が本当にそのマシンであるかどうかに関する決定はTARPスタック
によって処理され、TARPスタックは、送信元IPアドレスと着信先IPアドレスがTA
RPスタックのIP同期テーブルにおいて一致しているかどうかを検査する。一致が
見つからない場合、このパケットは破棄される。一致した場合、パケットが開放
され、インナヘッダが評価される。パケットの着信先がこのマシンであることを
インナヘッダが示している場合、パケットがIPスタックに転送され、そうでない
場合、パケットは破棄される。
【００８３】 純粋に無作為のMACアドレス・ホッピングの1つの欠点は、処理オーバヘッドに
対するこのホッピングの影響である。すなわち、発生したあらゆるフレームを処
理しなければならないので、ネットワーク・インタフェース・ドライバがパケッ
トを一方的に区別し拒絶する場合よりもかなり頻繁にマシンのCPUが使用される
。妥協的な手法として、メッセージの着信先である実際の受信側にかかわらず、
MACホップ通信に使用すべきアドレスとして単一の固定MACアドレスまたは少数の
MACアドレス（たとえば、イーサネット上の各仮想専用網ごとに1つのMACアドレ
ス）を選択する手法がある。このモードでは、ネットワーク・インタフェースが
、発生した各フレームを事前に確立された1つ（または少数）のMACアドレスと突
き合わせて検査することができ、それによって、CPUは物理層パケットの区別を
行わなく済む。この方式では、LAN上の侵入者に重要な情報が漏れることがない
。特に、アウタヘッダ内の固有のパケット・タイプによってあらゆる安全なパケ
ットを事前に識別しておくことができる。しかし、安全な通信を行うすべてのマ
シンが同じMACアドレスを使用するか、あるいは所定のMACアドレスの小さな集合
から選択するので、特定のマシンと特定のMACアドレスとの間の関連付けが実際
上、失われる。
【００８４】 この方式では、ネットワーク・インタフェース・ドライバが、このマシンを着
信先とする安全なパケットと他のVPNからの安全なパケットを常に一方的に区別
することはできないので、CPUは、安全でない通信（または同期式MACアドレスホ
ッピング）の場合よりも頻繁に使用される。しかし、ネットワーク・インタフェ
ースにおいて安全でないトラフィックをなくすのは容易であり、したがって、CP
Uに必要な処理の量が少なくなる。これらが当てはまらない境界条件があり、た
とえば、LAN上のすべてのトラフィックが安全なトラフィックである場合、CPUは
純粋に無作為のアドレス・ホッピングの場合と同じ程度に使用される。あるいは
、LAN上の各VPNが異なるMACアドレスを使用する場合、ネットワーク・インタフ
ェースは、ローカル・マシンを着信先とする安全なフレームを、他のVPNを構成
する安全なフレームと完全に区別することができる。これらは技術上の兼ね合せ
であり、ユーザがソフトウェアをインストールし、かつ／またはVPNを確立する
際に管理オプションを与えることによって最もうまく処理することができる。
【００８５】 しかし、この場合でも、LAN上の1つまたは複数のノードによって使用されるMA
Cアドレスが選択されるわずかな可能性が依然として残る。この問題に対する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によって使用されているMA
Cアドレスを含むフレームのストリームを作成することが可能になる。このよう
なフレームを拒絶するには過度の処理オーバヘッドが必要になる恐れがあるディ
スクリミネータ・フィールドは、擬パケットを拒絶する低オーバヘッド手段を実
現する。）
【００９２】 「ハードウェア・ホッピング」モードと呼ばれる第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）を生成することができる。次いで、R
NSを使用して、上述のように送信元／着信先IPペア（および必要に応じて、ディ
スクリミネータ・フィールドならびにハードウェア送信元アドレスおよびハード
ウェア着信先アドレス）が生成される。しかし、シーケンス全体（または最初の
N−1個の値）を生成しなくてもシーケンス内のN番目の乱数を生成することがで
きる。シーケンス・インデックスNが既知である場合、このインデックスに対応
する無作為の値を直接生成することができる（以下参照）。それぞれの異なる基
本周期を有する様々なRNG（およびシード）を使用して送信元IPシーケンスおよ
び着信先IPシーケンスを生成することができるが、この場合も基本的な概念が適
用される。話を簡単にするために、以下の議論では、単一のRNGシーケンシング
機構を使用してIP送信元・着信先アドレス・ペア（のみ）がホップされるものと
仮定する。
【００９９】 各パケット・ヘッダ内の同期フィールドは、「自己同期」機能により、IPペア
を生成するために使用されているRNSにインデックス（すなわち、シーケンス番
号）付けする。RNSを生成するために使用されているRNGにこのようにインデック
ス付けすると特定の乱数値が生成され、それによって特定のIPペアが生成される
。すなわち、RNG、シード、およびインデックス番号から直接IPペアを生成する
ことができ、この方式では、与えられたインデックス番号に関連付けされたシー
ケンス値に先行する乱数のシーケンス全体を生成することは不要である。
【０１００】 通信者がすでにRNGおよびシードを交換しているものと仮定されているので、I
Pペアを生成するために与えなければならない新しい情報はシーケンス番号だけ
である。この番号が送信側によってパケットヘッダ内に与えられる場合、受信側
は、この番号を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（「チェックポイント・オールド」）は、最後のS
YNC_REQパケットを受信側に再送するために使用されたIPペアである。受信側に
おいて、ckpt_o（「チェックポイント・オールド」）は、送信側から繰り返しSY
NC_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として記憶し、ai mod((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パラメータを導くことができる。このことはL
CGに当てはまる。この弱点は、出力を乱数生成プログラムの一部とするように構
成された暗号化プログラムを組み込むことによって軽減することができる。乱数
生成プログラムは、敵が暗号プログラムに攻撃、たとえば既知の平文攻撃を開始
するのを防止する。
【０１２１】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*3
0=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
つ先にジャンプする。
【０１２３】
【表１】
【０１２４】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で受信されたメッセージのカウント値であるM
ESS_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である。MI
N = 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）は、要求されたコンピュータまたはホストのI
Pアドレスを返す参照機能を提供する。たとえば、コンピュータのユーザがウェ
ブ名「Yahoo.com」を入力すると、ユーザのウェブブラウザがDNSに要求を送信し
、それによってこのウェブ名が、ユーザのブラウザに返されて、次に宛先ウェブ
サイトに接触するためにブラウザによって用いられる、4分割IPアドレスに変換
される。
【０１６５】 この従来の方式を図25に示す。ユーザのコンピュータ2501は、クライアント・
アプリケーション2504（たとえば、ウェブブラウザ）およびIPプロトコル・スタ
ック2505を含む。ユーザが宛先ホストの名前を入力すると、この名前に関連する
IPアドレスを参照することを求める要求DNS REQが（IPプロトコル・スタック250
5を通して）、DNS 2502に対してなされる。DNSはIPアドレスDNS RESPをクライア
ント・アプリケーション2504に返し、IPアドレスを用いてPAGE REQおよびPAGE R
ESPのような別々のトランザクションを通じて、ホスト2503と通信することがで
きる。
【０１６６】 図25に示されている従来の構造において、インターネット上の不埒なリスナー
は、DNS REQパケットおよびDNS RESPパケットを傍受し、したがってユーザがど
んなIPアドレスに接触しているかを知ることができる。たとえば、ユーザが「Ta
rget.com」という名前を有するウェブサイトと、安全な通信パスを設定すること
を望んだ場合に、ユーザのブラウザがそのウェブサイトのIPアドレスを見出すた
めにDNSに接触した場合、そのウェブサイトの真のIPアドレスはDNS問合せの一部
としてインターネット上で明らかにされる。これによってインターネット上の匿
名の通信が阻害される。
【０１６７】 インターネット上で安全な仮想専用網を提供する1つの従来の方式は、DNSサー
バがアドレスを有するマシンの公開鍵を有するDNSサーバを提供する。このため
、ホストは、ユーザに宛先ホストの公開鍵を入力させずにVPNを設定できるよう
に、通信相手のホストの公開鍵を自動的に検索することができる。この標準の実
施は現在、FreeS/WANプロジェクト（RFC2535）の一部として開発されている。
【０１６８】 この従来の方式はある欠点を有する。たとえば、任意のユーザがDNS要求を実
行することができる。さらに、DNS要求はすべてのユーザに対して同じ値になる
。
【０１６９】 本発明のある態様によれば、専用DNSサーバがDNS要求を取り込み、その要求が
特別の種類のユーザに由来する要求である場合（たとえば、安全な通信サービス
が規定されているユーザ）、サーバはターゲット・ノードの真のIPアドレスを返
さず、その代わりに、ターゲット・ノードとユーザとの間に仮想専用網を自動的
に設定する。VPNは好ましくは、上述の基本的な発明のIPアドレス「ホッピング
」機能を使用して実施され、たとえ通信中のパケットが傍受されても、2つのノ
ードの真の同一性を判定することはできないように実施される。安全なサービス
を必要としないと判定されるDNS要求に関して（たとえば、未登録のユーザ）、
要求するホストが安全でないサイトを解決する許可を得ているという条件で、DN
Sサーバは要求を透過的に「通過させ」、通常の参照機能を提供し、ターゲット
ウェブサーバのIPアドレスを返す。異なるユーザは同一のDNS要求を出す場合、
異なる結果を提供することができる。
【０１７０】 図26には、上記で要約した様々な原則を使用するシステムが示されている。ユ
ーザのコンピュータ2601は、従来のクライアント（たとえば、ウェブブラウザ）
2605、および好ましくは上記で概説したIPホッピング機能2607に従って作動する
、IPプロトコル・スタック2606を含む。修正されたDNSサーバ2602は、従来のDNS
サーバ機能2609およびDNSプロキシ2610を含む。修正されたDNSサーバと安全なタ
ーゲット・サイト2604との間にゲートキーパ・サーバ2603が挿入される。従来の
IPプロトコルを介して「安全でない」ターゲット・サイト2611もアクセス可能で
ある。
【０１７１】 一つの態様によれば、DNSプロキシ2610は、クライアント2605由来のすべてのD
NS参照機能を傍受し、安全なサイトへのアクセスが要求されたかどうかを判定す
る。安全なサイトへのアクセスが要求された場合（例えばドメイン名拡張、また
はそのようなサイトの内部テーブルの参照によって、判定されるように）、DNS
プロキシ2610は、ユーザがこのサイトにアクセスするのに十分なセキュリティ特
権を有しているかどうかを判定する。十分なセキュリティ特権を有している場合
、DNSプロキシ2610は、ユーザ・コンピュータ2601と安全なターゲット・サイト2
604との間に仮想専用網を作成することを求めるメッセージをゲートキーパ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サーバ26
09はこの要求を解決し、結果を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プロトコル42
0および421を有する。TARP VPNの場合、パケットは、定義されていないIPプロト
コルを有する。ISPのリンク・ガードである2805は、VPNパケットが暗合的に有効
であるかどうかを検証するのに用いられる、有効なVPNテーブルを維持している
。
【０１８８】 一つの態様によれば、低帯域幅リンク上のノードによって使用されるホップウ
ィンドウ内に入らないパケットは、拒絶されるか、またはより低い品質のサービ
スと共に送信される。これを行う1つの手法は、高帯域幅ノードと低帯域幅ノー
ドの両方が、ホッピングされたパケットを追跡する（たとえば、有効なパケット
が受信されたときに、高帯域幅ノードがそのホッピングウィンドウを移動させる
）ように、低帯域幅ノードによって使用されるIPホッピング・テーブルのコピー
を高帯域幅ノードに提供することである。このようなシナリオにおいて、高帯域
幅ノードは、ホッピングウィンドウに入らないパケットが低帯域幅リンクを介し
て送信される前に、このようなパケットを破棄する。したがって、たとえば、IS
P2903は、ホスト・コンピュータ2901によって使用される受信テーブルのコピー2
910を維持する。この受信テーブル内に入らない着信パケットは破棄される。異
なる態様によれば、リンク・ガード2805は、鍵をかけられたハッシュ・メッセー
ジ認証符号（HMAC）[rfc 2104]を使用して各VPNパケットを検証する。他の態様
によれば、低帯域幅ノードと高帯域幅ノードとの間の通信用に（たとえば、ホッ
プブロックを使用する）別々のVPNを確立することができる（すなわち、高帯域
幅ノードに到着するパケットは、低帯域幅ノードに送信される前に異なるパケッ
トに変換される）。
【０１８９】 図29に示されているように、たとえば、第1のホスト・コンピュータ2900がイ
ンターネット上で第2のホスト・コンピュータ2902と通信しており、かつパスがI
SP 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のホスト・コンピュータ300
0内の高速パケット拒絶機構は、これらのパケットを拒絶するうえでほとんど無
用である。というのは、これらのパケットが拒絶される前に低帯域幅リンクが実
際上渋滞してしまうからである。しかし、改良の一つの態様によれば、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が送信されてからある期間にわたって引き続き正しく
送信するので、上記のアルゴリズムは送信側の帯域幅を人為的に縮小する可能性
がある。事象により、適合した送信側がある期間（たとえば、ネットワークがSY
NC_REQまたはSYNC_ACKを破棄する期間）の間同期をとることができない場合、SY
NC_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は、受信側コンピュータ30
00にパケットを送信する際に次の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に不適切なパケットをフラッドさせることができ
ないように、すべてのクライアントとシグナリング・サーバとの間に「管理」VP
Nを確立することができる。この方式の詳細を以下に示す。
【０２０７】 シグナリング・サーバ3101は、要求3111を受信し、それを使用してクライアン
ト3103が無効に登録されたユーザであると判定する。次に、シグナリング・サー
バ3101は、クライアント3103を含むVPNを作成するために、ホッピング・テーブ
ル（もしくはホッピング・アルゴリズムまたは他の方式）を割り当てることを求
める要求をトランスポート・サーバ3102に発行する。割り当てられたホッピング
・パラメータはシグナリング・サーバ3101（パス3113）に返され、次いで、シグ
ナリング・サーバ3101はホッピング・パラメータを好ましくは暗号形式でパス31
14を介してクライアント3103に供給する。
【０２０８】 その後、クライアント3103は、上述の通常のホッピング技術を使用してトラン
スポート・サーバ3102と通信する。シグナリング・サーバ3101およびトランスポ
ート・サーバ3102は2つの別々のコンピュータとして示され、もちろん、これら
を単一のコンピュータに組み合わせ、これらの機能をこの単一のコンピュータ上
で実行してもよいことは認識されると考えられる。または、本発明の原則から逸
脱せずに、図31に示されている機能を、図示されているのとは異なるように分割
することも可能である。
【０２０９】 上述の技術の1つの利点は、シグナリング・サーバ3101が、多数の潜在的なユ
ーザに関して少量の情報を維持するだけでよく、それにもかかわらずハッカー・
コンピュータ3105のような許可されていないユーザからのパケットを即座に拒絶
する機能を保持することである。その代わり、ホッピング機能および同期機能を
実行するのに必要な比較的大きなデータ・テーブルがトランスポート・サーバ31
02内に維持され、これらのテーブルは、「アクティブ」リンクに割り当てられる
に過ぎないので比較的少数でよい。VPNがある期間（たとえば、1時間）にわたっ
て非活動状態であると、トランスポート・サーバ3102またはシグナリング・サー
バ3101によってVPNを自動的に切り離すことができる。
【０２１０】 次に、上述のシグナリング方式を実施するのにチェックポイント同期機能の特
別なケースをどのように用いればよいかに関して詳しく説明する。
【０２１１】 シグナリング・シンクロナイザは、多数（数百万）の固定・低帯域幅接続をサ
ポートする場合に必要になる。したがって、シグナリング・シンクロナイザは、
ホッピング技術によるセキュリティを実現しつつVPLメモリ使用量を最小限に抑
えなければならない。シグナリング・サーバにおけるメモリ使用量を低減させる
には、データ・ホッピング・テーブルを完全になくすか、またはデータをSYNC_R
EQメッセージの一部として搬送することができる。サーバ側（受信側）およびク
ライアント側（送信側）によって使用されるテーブルは、図31に要素3106として
概略的に示されている。
【０２１２】 CKPT_N、CKPT_O、およびCKPT_Rの意味および動作は、CKPT_Nが、データとSYNC
_REQメッセージの組合せまたはデータを含まないSYNC_REQメッセージを受信でき
ることを除いて前の説明と同じである。
【０２１３】 このプロトコルは、前述のシンクロナイザをそのまま拡張したものである。ク
ライアント送信側がオンであり、テーブルの同期がとられると仮定する。初期テ
ーブルは「同期のとれていない状態で」生成することができる。たとえば、クラ
イアントは、インターネット上にアカウントを確立するためにウェブサーバにロ
グインすることができる。クライアントは、インターネット上で、暗号化された
鍵などを受信する。その間、サーバはシグナリング・サーバ上でシグナリングVP
Nを設定する。
【０２１４】 クライアント・アプリケーションが、クライアントの固定シグナリングVPL上
でサーバにパケットを送信する必要があると仮定する。
【０２１５】 1．クライアントは、送信側のCKPT_Nアドレスを使用してインナー・ヘッダ上
のデータ・メッセージとしてマークされたメッセージを送信する。クライアント
は、送信側をオフにし、CKPT_Oを示すタイマT1を開始する。メッセージは、3つ
の種類、DATA、SYNC_REQ、およびSYNC_ACKのうちの1つであってよい。通常のア
ルゴリズムでは、各メッセージ・タイプを暗号化されたインナー・ヘッダ・フィ
ールドの一部として識別することによって、いくつかの潜在的な問題を防止する
ことができる。このアルゴリズムでは、データとSYNC_REQが同じアドレスで送信
されるので、シグナリング・シンクロナイザにおいてデータ・パケットとSYNC_R
EQを区別することが重要である。
【０２１６】 2．サーバは、そのCKPT_N上でデータ・メッセージを受信すると、このメッセ
ージを検証し、スタックに沿って転送する。メッセージは、インナー・ヘッダー
に含まれているメッセージの種類および他の情報（すなわち、ユーザの信頼）を
検査することによって検証することができる。サーバは、そのCKPT_OをCKPT_Nで
置き換え、次のCKPT_Nを生成する。サーバは、その送信側CKPT_Rをクライアント
の受信側CKPT_Rに対応するように更新し、ペイロード内にCKPT_Oを含むSYNC_ACK
を送信する。
【０２１７】 3．クライアント受信側が、送信側CKPT_Oと一致するペイロードを持つSYNC_AC
KをCKPT_R上で受信し、送信側がオフであるとき、送信側がオンにされ、受信側C
KPT_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_A
CKを送信する。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に進み、そこでコンピュータ33
01上にVPN通信ソフトウェア・モジュールがインストールされている、とハイパ
ーリンクに関連するオブジェクトが判定する。または、ユーザがコンピュータ33
01に「ゴー・セキュア」コマンドを入力することができる。
【０２２９】 段階3403で、ソフトウェア・モジュールがインストールされているとオブジェ
クトが判定した場合、流れは段階3407に進む。段階3403で、ソフトウェア・モジ
ュールがインストールされていないとオブジェクトが判定した場合、流れは段階
3404に進み、そこでコンピュータ・ネットワーク3302上のコンピュータ3301とウ
ェブサイト3308との間で、公知の方法で非VPN通信リンク3307が開始される。ウ
ェブサイト3308は、非VPN通信リンクを通してコンピュータ・ネットワーク3302
に接続されたすべてのコンピュータ端末からアクセス可能である。ウェブサイト
3308に接続された後、コンピュータ・ネットワーク3302上に安全通信リンクを確
立するソフトウェア・モジュールをダウンロードし、インストールすることがで
きる。流れは段階3405に進み、そこでコンピュータ3301がウェブサイト3308に接
続された後、通信リンクを確立するソフトウェア・モジュールがダウンロードさ
れ、公知の方法でコンピュータ端末3301上にソフトウェア・モジュール3309とし
てインストールされる。段階3405で、ユーザは、コンピュータ・ネットワーク33
02上のすべての通信リンク用の通信の安全通信モードを使用可能にするように、
ソフトウェア・モジュール用のパラメータを任意に選択することができる。次い
で、段階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）3
318のような他のネットワーク・サービスを含みうる。もちろん、安全ネットワ
ーク3311は、図33に示されていない他のリソースおよびサービスを含んでよい。
【０２３３】 ソフトウェア・モジュール3309が、サーバ3304の標準トップレベル・ドメイン
名を安全トップレベル・ドメイン名で置き換えると、ソフトウェア・モジュール
3309は、段階3408で、好ましくは管理VPN通信リンク3319を使用して、安全ポー
タル3310を通してSDNS3313に問合せを送信する。この構成では、安全ポータル33
10は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は、サーバ・コンピュータ3
304とは別のサーバ・コンピュータであっても、サーバ・コンピュータ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は公知の方法でサーバ330
4に接続する。段階3415で、ブラウザ3306は、端末3301とサーバ3304との間のVPN
通信リンクを選択するための「ゴー・セキュア」ハイパーリンク、またはアイコ
ンを表示する。この場合も「ゴー・セキュア」ハイパーリンクを表示することに
より、ユーザは現在の通信リンクが非安全非VPN通信リンクであることを知る。
【０２３８】 ソフトウェア・モジュール3309をインストールしているとき、またはユーザが
オフラインであるとき、ユーザは、コンピュータ・ネットワーク3302上で確立さ
れているすべての通信リンクが安全通信リンクであることを任意に指定すること
ができる。したがって、通信リンクが確立されているときはいつでも、リンクは
VPNリンクである。したがって、ソフトウェア・モジュール3309は、SDNS3313に
透過的にアクセスし、選択された安全ウェブサイトのURLを得る。言い換えれば
、一態様において、ユーザは安全通信を行うたびに安全オプションを「クリック
」する必要はない。
【０２３９】 さらに、コンピュータ3301のユーザは、プロキシ・コンピュータ3315を通して
、安全通信リンクを任意に選択することができる。したがってコンピュータ3301
は、プロキシ・コンピュータ3315を通して安全サーバ・コンピュータ3320とのVP
N通信リンク3323を確立することができる。または、コンピュータ3301は、非安
全サーバ・コンピュータ3304などの非安全ウェブサイトとの非VPN通信リンク332
4を確立することができる。
【０２４０】 図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通信およびHT
TP通信と比べて、サービスを要求して拒否されることの影響を最小限に抑え、そ
れによってサーバを無効な通信から保護する。
【０２４８】 図36は、コンピュータ・ネットワーク3600のシステム・ブロック図であり、本
発明による仮想専用接続は、2つのコンピュータ・ネットワーク間のファイアウ
ォールをより容易に横切るように構成することができる。図37は、既存のネット
ワーク・プロトコルを用いてカプセル化された、仮想専用接続を確立する場合の
流れ図3700である。
【０２４９】 図36では、ファイアウォール構成3603を通して、インターネットのような他の
コンピュータ・ネットワーク3602にローカル・エリア・ネットワーク（LAN）360
1が接続されている。ファイアウォール構成は、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内のア
プリケーション層で動作するため、ユーザによって都合よくインストールおよび
アンインストールされる。インストール時には、プロキシ・アプリケーション36
07は好ましくは、すべてのウェブ通信にプロキシ・アプリケーションを使用する
ようにブラウザ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上のホスト・コンピュータ36
08とクライアント・コンピュータ3604との間に仮想専用接続を形成するのに用い
られるデータを、メッセージ・パケットのペイロード部に挿入する。好ましくは
、仮想専用接続を形成するためのデータは、上記でVPNに関連して説明したよう
なフィールド・ホッピング・データを含む。サーバ・プロキシ部3610は、応答メ
ッセージ・パケットのペイロード部に仮想専用接続データを挿入するように、ホ
スト・コンピュータ内のカーネル層で動作する。好ましくは、ホスト・コンピュ
ータ3608によってクライアント・コンピュータ3604に送信される修正されたメッ
セージ・パケットは、UDPプロトコルに従う。または、修正されたメッセージ・
パケットがTCP/IPプロトコルまたはICMPプロトコルに従ってよい。
【０２５６】 段階3707で、修正されたパケットは、コンピュータ・ネットワーク3602上でホ
スト・コンピュータ3608から送信され、ファイアウォール3603を通過する。修正
されたパケットは、ファイアウォール3603を通過した後、LAN3601上でクライア
ント・コンピュータ3604に送られ、段階3708で、プロキシ・アプリケーション36
07によりクライアント・コンピュータ3604内のアプリケーション層で受信される
。プロキシ・アプリケーション3607は、修正されたメッセージ・パケットを迅速
に評価し、受信されたパケットを受け入れるべきかそれとも破棄すべきかを判定
するように動作する。受信された情報パケットに挿入された仮想専用接続データ
が、予想される仮想専用接続データと一致している場合、受信されたパケットは
受け入れられる。一致していない場合、受信されたパケットは破棄される。
【０２５７】 図示された態様に関連して本発明を説明したが、本発明の真の趣旨および範囲
から逸脱せずに修正を加えられることが認識され、理解されると考えられる。
【図面の簡単な説明】
【図１】 従来技術の態様によるインターネットを介した安全な通信の図で
ある。
【図２】 本発明の態様によるインターネットを介した安全な通信の図であ
る。
【図３Ａ】 本発明の態様によるトンネル化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つのコンピュータ・ネットワーク
間のファイアウォールをより容易に横切るように構成することのできる、コンピ
ュータ・ネットワークのシステム・ブロック図である。
【図３７】 既存のネットワーク・プロトコルを使用してカプセル化される
、仮想専用接続を確立する場合の流れ図である。
───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＯ，ＣＲ，ＣＵ，ＣＺ，ＤＥ ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ， ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，Ｉ Ｓ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ， ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，Ｐ Ｔ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ， ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 ミュンガー エドモント コルビー アメリカ合衆国 メリーランド州 クラウ ンズビル オパカ コート 1101 (72)発明者 シュミット ダグラス チャールズ アメリカ合衆国 メリーランド州 セバー ナ パーク オーク コート 230 (72)発明者 ウィリアムソン マイケル アメリカ合衆国 バージニア州 サウス ライディング オケイラ サークル 26203 Ｆターム(参考） 5J104 MA01 NA03 PA07 5K030 GA15 HC01 HC20 KA01 KA02 KA05 LC09

Claims (16)

    【特許請求の範囲】
  1. 【請求項１】 以下を含む、コンピュータ・ネットワーク用の安全ドメイン
    名サービス： コンピュータ・ネットワークに接続され、安全コンピュータ・ネットワーク・
    アドレスについて問合せを認証するポータル、および ポータルを通してコンピュータ・ネットワークに接続され、コンピュータ・ネ
    ットワーク用の安全コンピュータ・ネットワーク・アドレスを記憶する、ドメイ
    ン名データベース。
  2. 【請求項２】 各安全コンピュータ・ネットワーク・アドレスが、非標準ト
    ップレベル・ドメイン名に基づく、請求項1記載の安全ドメイン名サービス。
  3. 【請求項３】 非標準トップレベル・ドメイン名が.scom、.sorg、.snet、.
    sedu、.smil、および.sintのうちの1つである、請求項2記載の安全ドメイン名サ
    ービス。
  4. 【請求項４】 コンピュータ・ネットワークがインターネットを含む、請求
    項1記載の安全ドメイン名サービス。
  5. 【請求項５】 安全ポータルがエッジ・ルータを含む、請求項1記載の安全
    ドメイン名サービス。
  6. 【請求項６】 ポータルが、暗号化技術を使用して問合せを認証する、請求
    項1記載の安全ドメイン名サービス。
  7. 【請求項７】 ポータルが、コンピュータ・ネットワークを通して仮想専用
    ネットワークに接続可能である、請求項1記載の安全ドメイン名サービス。
  8. 【請求項８】 安全通信リンクが、安全通信リンク階層内の複数の安全通信
    リンクのうちの1つである、請求項7記載の安全ドメイン名サービス。
  9. 【請求項９】 仮想専用ネットワークが、擬似乱数シーケンスに従って変化
    する1つまたは複数のデータ値を、各データ・パケットに挿入することに基づく
    、請求項7記載の安全ドメイン名サービス。
  10. 【請求項１０】 仮想専用ネットワークが、第1のコンピュータと第2のコン
    ピュータとの間で送信されるパケット内の、コンピュータ・ネットワーク・アド
    レスを擬似乱数的に変化させるのに用いられる、コンピュータ・ネットワーク・
    アドレス・ホッピング方式に基づく、請求項7記載の安全ドメイン名サービス。
  11. 【請求項１１】 仮想専用ネットワークが、第1のコンピュータと第2のコン
    ピュータとの間で送信される各データ・パケット内の値を、妥当な値の移動ウィ
    ンドウと比較することに基づく、請求項7記載の安全ドメイン名サービス。
  12. 【請求項１２】 仮想専用ネットワークが、各データ・パケットのヘッダ内
    のディスクリミネータ・フィールドと、第1のコンピュータのために維持される
    妥当なディスクリミネータ・フィールドのテーブルとの比較に基づく、請求項7
    記載の安全ドメイン名サービス。
  13. 【請求項１３】 安全ドメイン名を登録する方法であって、 安全ドメイン名を登録することを求める要求を受信する段階、 安全ドメイン名に対応する、同等な非安全ドメイン名の所有権情報を検証する
    段階、および 同等な非安全ドメイン名の所有権情報が、安全ドメイン名の所有権情報と一致
    するときに、安全ドメイン名サービスに安全ドメイン名を登録する段階 を含む方法。
  14. 【請求項１４】 所有権情報を検証する段階が以下の段階を含む、請求項13
    記載の方法： 安全ドメイン名に対応する同等な非安全ドメイン名が、非安全ドメイン名サー
    ビスに登録されているかどうかを判定する段階、および 同等な非安全ドメイン名が非安全ドメイン名サービスに登録されていないとき
    に、同等な非安全ドメイン名を非安全ドメイン名サービスに登録すべきかどうか
    を問い合わせる段階。
  15. 【請求項１５】 記憶領域、および 安全ドメイン名を登録する方法に関するコンピュータ可読命令 を含み、該方法が以下の段階を含む、コンピュータ可読記憶媒体： 安全ドメイン名を登録することを求める要求を受信する段階、 安全ドメイン名に対応する、同等な非安全ドメイン名の所有権情報を検証する
    段階、および 同等な非安全ドメイン名の所有権情報が安全ドメイン名の所有権情報と一致す
    るときに、安全ドメイン名サービスに安全ドメイン名を登録する段階。
  16. 【請求項１６】 所有権情報を検証する段階が以下の段階を含む、請求項15
    記載のコンピュータ可読記憶媒体： 安全ドメイン名に対応する同等な非安全ドメイン名が、非安全ドメイン名サー
    ビスに登録されているかどうかを判定する段階、および 同等な非安全ドメイン名が非安全ドメイン名サービスに登録されていないとき
    に、同等な非安全ドメイン名を非安全ドメイン名サービスに登録すべきかどうか
    を問い合わせる段階。
JP2002501144A 2000-04-26 2001-04-25 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良 Expired - Lifetime JP5095900B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US55821000A 2000-04-26 2000-04-26
US09/558,210 2000-04-26
PCT/US2001/013260 WO2001092997A2 (en) 2000-04-26 2001-04-25 Secure domain name service

Related Child Applications (3)

Application Number Title Priority Date Filing Date
JP2010239197A Division JP5180274B2 (ja) 2000-04-26 2010-10-26 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2011083414A Division JP5165776B2 (ja) 2000-04-26 2011-04-05 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2011083415A Division JP5377562B2 (ja) 2000-04-26 2011-04-05 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良

Publications (2)

Publication Number Publication Date
JP2003535560A true JP2003535560A (ja) 2003-11-25
JP5095900B2 JP5095900B2 (ja) 2012-12-12

Family

ID=24228602

Family Applications (6)

Application Number Title Priority Date Filing Date
JP2002501144A Expired - Lifetime JP5095900B2 (ja) 2000-04-26 2001-04-25 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2010239197A Expired - Lifetime JP5180274B2 (ja) 2000-04-26 2010-10-26 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2011083414A Expired - Lifetime JP5165776B2 (ja) 2000-04-26 2011-04-05 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2011083415A Expired - Lifetime JP5377562B2 (ja) 2000-04-26 2011-04-05 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2012256213A Expired - Lifetime JP5478697B2 (ja) 2000-04-26 2012-11-22 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2012256228A Expired - Lifetime JP5478698B2 (ja) 2000-04-26 2012-11-22 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良

Family Applications After (5)

Application Number Title Priority Date Filing Date
JP2010239197A Expired - Lifetime JP5180274B2 (ja) 2000-04-26 2010-10-26 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2011083414A Expired - Lifetime JP5165776B2 (ja) 2000-04-26 2011-04-05 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2011083415A Expired - Lifetime JP5377562B2 (ja) 2000-04-26 2011-04-05 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2012256213A Expired - Lifetime JP5478697B2 (ja) 2000-04-26 2012-11-22 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
JP2012256228A Expired - Lifetime JP5478698B2 (ja) 2000-04-26 2012-11-22 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良

Country Status (5)

Country Link
EP (4) EP1284079B1 (ja)
JP (6) JP5095900B2 (ja)
AU (1) AU2001259140A1 (ja)
DE (1) DE60116754T2 (ja)
WO (1) WO2001092997A2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011502404A (ja) * 2007-10-31 2011-01-20 ファースト プリンシプルズ インコーポレイテッド ネットワーク・メッセージ・パケットを保護するための方法
JP2018519743A (ja) * 2015-06-22 2018-07-19 シマンテック コーポレーションＳｙｍａｎｔｅｃ Ｃｏｒｐｏｒａｔｉｏｎ ネットワーク通信のプライバシーを管理するための技術

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2368147B (en) * 2000-06-09 2004-10-20 Ali Guryel Access control system for network of servers via portal
EP1554842A4 (en) 2002-08-30 2010-01-27 Corporation Broadcom SYSTEM AND METHOD FOR TREATING FRAMES OUTSIDE THE ORDER
JP2004247908A (ja) * 2003-02-13 2004-09-02 Tech Res & Dev Inst Of Japan Def Agency 周波数ホッピング通信システム
EP1460804B1 (en) * 2003-03-20 2008-10-22 Broadcom Corporation System and method for handling out-of-order frames (fka reception of out-of-order tcp data with zero copy service)
US7643420B2 (en) 2005-03-11 2010-01-05 Broadcom Corporation Method and system for transmission control protocol (TCP) traffic smoothing
US7522905B2 (en) * 2005-06-24 2009-04-21 Visa U.S.A. Inc. Apparatus and method for preventing wireless interrogation of portable consumer devices
US7482925B2 (en) 2005-06-24 2009-01-27 Visa U.S.A. Apparatus and method to electromagnetically shield portable consumer devices
FI20065179A0 (fi) * 2006-03-20 2006-03-20 Nixu Sofware Oy Kokonaisuudeksi koottu nimipalvelin
US8604995B2 (en) 2007-06-11 2013-12-10 Visa U.S.A. Inc. Shielding of portable consumer device
US8038068B2 (en) 2007-11-28 2011-10-18 Visa U.S.A. Inc. Multifunction removable cover for portable payment device
JP5865183B2 (ja) * 2012-06-08 2016-02-17 西日本電信電話株式会社 中継装置
US9270684B2 (en) 2013-04-17 2016-02-23 Globalfoundries Inc. Providing a domain to IP address reputation service
US9634935B2 (en) 2013-04-24 2017-04-25 Secured Connectivity, Llc Method, name server, and system for directing network traffic utilizing profile records
WO2014172769A1 (en) * 2013-04-24 2014-10-30 Selectivevpn Inc. Method, server, and system for directing network traffic
US10721097B2 (en) 2018-04-24 2020-07-21 Microsoft Technology Licensing, Llc Dynamic scaling of virtual private network connections
CN114500056A (zh) * 2022-01-28 2022-05-13 杭州立思辰安科科技有限公司 一种基于ff协议的攻击检测方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09146843A (ja) * 1995-11-20 1997-06-06 Fujitsu Ltd 情報処理装置
US5898830A (en) * 1996-10-17 1999-04-27 Network Engineering Software Firewall providing enhanced network security and user transparency
JPH09266475A (ja) * 1996-03-28 1997-10-07 Hitachi Ltd アドレス情報管理装置およびネットワークシステム
JPH09270803A (ja) * 1996-04-02 1997-10-14 Furukawa Electric Co Ltd:The 仮想ネットワーク構築方法
US6101543A (en) * 1996-10-25 2000-08-08 Digital Equipment Corporation Pseudo network adapter for frame capture, encapsulation and encryption
JP3009876B2 (ja) * 1997-08-12 2000-02-14 日本電信電話株式会社 パケット転送方法および該方法に用いる基地局
JPH11288392A (ja) * 1998-04-02 1999-10-19 Matsushita Electric Ind Co Ltd 電子メールシステム
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
JP4692600B2 (ja) * 2008-09-25 2011-06-01 富士ゼロックス株式会社 情報処理装置、通信システム、及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6010023141, 高田 学也, "クラッカ対策に米国ベンダーが本腰 追跡ツール、安全の高いＤＮＳソフトが登場", 日経コミュニケーション, 19971113, 第２５７号, ｐ．８７ *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011502404A (ja) * 2007-10-31 2011-01-20 ファースト プリンシプルズ インコーポレイテッド ネットワーク・メッセージ・パケットを保護するための方法
JP2018519743A (ja) * 2015-06-22 2018-07-19 シマンテック コーポレーションＳｙｍａｎｔｅｃ Ｃｏｒｐｏｒａｔｉｏｎ ネットワーク通信のプライバシーを管理するための技術

Also Published As

Publication number Publication date
EP1542429B1 (en) 2013-06-12
JP5478698B2 (ja) 2014-04-23
JP2011124985A (ja) 2011-06-23
JP2013062862A (ja) 2013-04-04
WO2001092997A2 (en) 2001-12-06
EP2381650A1 (en) 2011-10-26
JP2011205642A (ja) 2011-10-13
JP5180274B2 (ja) 2013-04-10
EP2330801A1 (en) 2011-06-08
AU2001259140A1 (en) 2001-12-11
JP5165776B2 (ja) 2013-03-21
WO2001092997A3 (en) 2002-10-17
EP1284079A2 (en) 2003-02-19
JP5377562B2 (ja) 2013-12-25
DE60116754D1 (de) 2006-04-06
JP5095900B2 (ja) 2012-12-12
JP2013062861A (ja) 2013-04-04
EP2330801B1 (en) 2019-10-23
EP1284079B1 (en) 2006-01-18
EP1542429A1 (en) 2005-06-15
JP5478697B2 (ja) 2014-04-23
JP2011205641A (ja) 2011-10-13
DE60116754T2 (de) 2006-08-31

Similar Documents

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

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20041101

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20041101

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20050412

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050819

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080424

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091118

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20091118

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20091118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100426

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100723

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100730

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101026

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20101206

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110405

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20110412

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20110513

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120920

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

Ref document number: 5095900

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150928

Year of fee payment: 3

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

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term