JP5449543B2 - ネットワークにおけるパケットルーティング - Google Patents

Description

本発明は、ネットワークにおけるパケット転送に関する。具体的には、本発明は、転送情報がパケットヘッダの中に格納され、パケットがどのリンクに沿って転送されるべきかを、ネットワークノードがパケットヘッダ内の転送情報から決定することができる方法に関する。

ブルームフィルタは、よく知られた空間効率的データ構造であって、偽陽性の機会を有しながら集合メンバーシップの質問に回答を与える。次世代ネットワークが直面する多くの実現制約（例えば、Ｇｂｐｓスピード、複雑度を増加するタスク、システムの大型化、高速メモリの利用可能性など）を解決する試みの中で、国際出願ＰＣＴ／ＥＰ２００８／０６１１６７号明細書、国際出願ＰＣＴ／ＥＰ２００８／０６３６４７号明細書（今後は「［１］」と称する）、及びＰ．Ｊｏｋｅｌａ、Ａ．Ｚａｈｅｍｓｚｋｙ、Ｃ．Ｅｓｔｅｖｅ、Ｓ．Ａｒｉａｎｆａｒ、及びＰ．Ｎｉｋａｎｄｅｒ著、「ＬＩＰＳＩＮ：Ｌｉｎｅ ｓｐｅｅｄ ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ ｉｎｔｅｒ−ｎｅｔｗｏｒｋｉｎｇ」、ＡＣＭ ＳＩＧＣＯＭＭ、バルセロナ、２００９年８月（今後は「［２］」と称する）では、パケットヘッダ内の小さなブルームフィルタを、種々の目的（ルーティング、セキュリティ、アカウンタビリティなど）に使用することが提案された。これらの文書で提示された主要なアイデアは、パケットヘッダ内のリンク識別子及び小さなブルームフィルタに基づく新規な空間及び計算効率的発信元ルーティング及びパケット転送メカニズムである。

本明細書では、パケットヘッダの中に置かれて、これらのタイプの応用に使用されるブルームフィルタをパケット内ブルームフィルタ（ｉＢＦ）と呼ぶことにする。或る意味において、ｉＢＦは、文献、例えばＢｒｏｄｅｒ及びＭｉｔｚｅｎｍａｃｈｅｒ著、Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎｓ ｏｆ Ｂｌｏｏｍ Ｆｉｌｔｅｒｓ：Ａ Ｓｕｒｖｅｙ． Ｉｎｔｅｒｎｅｔ Ｍａｔｈｅｍａｔｉｃｓ（２００２） ｖｏｌ．１（４） ｐｐ．４８５−５０９の中で説明されている従来のＢＦアプローチと対比して、逆のアプローチである。

［２］で提示された１つの応用シナリオは、発信元ルーティング経路を決定できるＭＰＬＳ経路計算要素（ＰＣＥ）のようなトポロジ層を有する発行／引用ネットワークである。（発行・引用（「パブサブ」）指向ネットワーキングは、Ｍｉｋｋｏ Ｓａｅｒｅｌａｅ、Ｔｅｅｍｕ Ｒｉｎｔａ−Ａｈｏ、及びＳａｓｕ Ｔａｒｋｏｍａ著、「ＲＴＦＭ：Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅ Ｉｎｔｅｒｎｅｔｗｏｒｋｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ」、ｔｈｅ ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＩＣＴ Ｍｏｂｉｌｅ Ｓｕｍｍｉｔ、ストックホルム、２００８年６月１１〜１３日で説明されるように、一次指名エンティティとしてホスト及びエンドポイントに焦点を当てる元来のインターネットプロトコルとは反対に、データに焦点を当てる。発行・引用パラダイムの背後にある１つのアイデアは、１つのノードから他のノードへの、所望されないデータ配達を回避し得るということである。今日のネットワークがそうであるように、送信者は、世界的に唯一無二のＩＰアドレスを使用して、受信者からの明白な要求なしに、ＩＰアドレスで識別されたホストへデータパケットを配達し得る。これは多くの問題を引き起こす。というのは、所望されない、更に悪意可能性のデータをユーザが受け取ることになるからである。この問題は、受信者に基づくアドレス指定、例えばＩＰアドレススキームで使用されるアドレス指定を放棄することによって克服され得る。というのは、これは宛先ホストがデータを要求しないときに宛先ホストへデータが送信される可能性を除去するからである。他のシナリオは、（Ｇ）ＭＰＬＳ又はキャリアイーサネットの転送構造をエネルギー効率的及び安全な構造へ置換することである。

ＩＰ転送、ＭＰＬＳ、及びキャリアイーサネットを含むデータパケット転送技術の分野において、ネットワークは常にパケットヘッダ内で指名された宛先へパケットを配達しようと試みるという仮定に基づき転送が行われ、誰が宛先をパケット内に置いたか、パケットがネットワーク内のどこに存在するかということには依存しない。もっとも、ＭＰＬＳでは状況が幾分異なる。というのは、パケットヘッダ内のラベルスタックは、（通常）指定された経路でのみ働き、ラベルは他の経路上で異なる意味を有するからである。しかしＭＰＬＳにおいても、誰がパケットを送信したか、いつパケットが送信されたか、パケットが何を搬送しているかについて、ネットワークは不可知である。言い換えれば、現在のネットワークは、ネットワーク層においてどのような種類の保護も提供せず、又は提供される保護は小さくて弱い。ＭＰＬＳネットワークも同様である。

転送における他の固有のセキュリティ問題は、パケットヘッダ内の宛先フィールドが受信者へ容易に関連づけられ得ることである。これは、他のフィールドの予測可能性と共にトラフィック分析を比較的容易にする。高度安全ネットワーク、例えば軍事ネットワークでは、トラフィック分析の防止が必須である。今日、これは典型的にはリンク暗号化によって達成されるが、リンク暗号化は比較的高価な作業である。

［１−２］で説明されるようなパケット内ブルームフィルタに基づく転送の分野でも、状況はほとんど同じである。パケット内ブルームフィルタの悪用から受信者又はネットワークを保護するセキュリティ方法は存在しない。第１に、ｉＢＦの構築方法を更に考慮しないと、ｉＢＦは１つのパケットから他のパケットへ簡単にコピーされ、結果のパケットは、搬送される状態（要素）に関して、正当パケットとして認識されることになる。

第２に、同じ（又は、ほとんど同じ）ビット分布を有する（［１］で定義されるような）ｉＢＦを格納した２つの異なるパケットが与えられるとすれば、情報の漏れが存在する。というのは、同じ（又は重複する）要素の集合が２つの異なるパケットのｉＢＦ内に存在することを観察者は推論し得るからである。この脅威を拡張すると、攻撃者はｉＢＦの多量の標本を待機及び収集して、挿入された要素の幾つかの共通パターンを推測するか、更に要素アイデンティティ自体を検索するかもしれない。同様に、これは偽造ｉＢＦの構築及び詳細なトラフィック分析を可能にするかもしれない。

第３に、ｉＢＦが危険にさらされた場合、即ち、攻撃者が有効ｉＢＦの構築方法を解明した場合、犠牲者は、承認され得ないｉＢＦを検出及び廃棄することができず、危険にさらされたｉＢＦ要素に対する最初の（配布されたときの）信頼を再確立する方途を有しない。

具体的には、パケット内ブルームフィルタを有するデータパケットを転送する分野において、及び一般に、他の知られた転送方法において、このようなセキュリティ欠陥は、分散サービス妨害（ＤＤｏＳ）攻撃の危険に起因して致命的となる。ＤＤｏＳの場合、犠牲者はトラフィックの洪水を受ける。例えば、ｉＢＦ発信元ルーティングに基づく解決法、例えば［１−２］で提示される解決法では、特定の経路について生成されたｉＢＦは、同じ経路を使用する全トラフィックについて有効な転送識別子である。従って、攻撃者が有効なｉＢＦを取得したとき、攻撃者はそれを他のデータについて使用し、このデータを元来の受信者へ配達し得る。こうして、リンク識別子の簡潔表現に基づくルーティングアプローチは、ｉＢＦ複製攻撃にさらされる。更に、ＤＤｏＳ攻撃に対して、生来的な保護欠落が存在する。

他の具体的な例として、もし攻撃者が自分の近くを通過する経路について正当稼働ｉＢＦを獲得し、この経路への攻撃者の現在位置から近似的ｉＢＦを同時に形成し得るならば、攻撃者は指定経路へのトラフィック注入を可能にする新しいｉＢＦを構築し、これによって攻撃者は不所望パケットの洪水を受信者へ与え得る。

本発明の第１の態様は、パケットルーティング情報を提供するネットワークノードを提供する。ノードは、第１のノードから１つ又は複数の第２のノードへのルートのパケットルーティング情報を、集合メンバーシップの非静的な簡潔表現へ符号化する手段を備える。集合メンバーシップの簡潔表現は、第１のノードから第２のノードへ送信されるべきパケットのヘッダの中へ含められる。ノードは、少なくとも１つのパケット特定、フロー特定、又は処理コンテキスト特定パラメータを含む入力パラメータを使用して、集合メンバーシップの簡潔表現を計算するように適応される。

［１］又は［２］の方法において、ｉＢＦは発信元から宛先への経路に基づいて生成される。したがって、その経路をたどる全パケットは同じｉＢＦを有し、上記で説明された欠点が存在する。しかしながら、本発明において、ｉＢＦ（又は集合メンバーシップの他の簡潔表現）はパケット依存性であるか（同じ経路に沿って送信されるパケットは、相互に異なるｉＢＦを有する）、又はフロー依存性である（異なるフローのパケットは、同じ経路に沿って送信されるときでも、相互に異なるｉＢＦを有する）。これは、例えば、ＤＤｏＳ攻撃を開始するために必要な情報を潜在的攻撃者が取得することを困難にする。

ネットワークノードは、パケットルーティング情報を複数の非静的識別子（例えば、［１−２］の単方向リンクを識別する要素）として表現し、非静的識別子を集合メンバーシップの簡潔表現へ符号化することによって、パケットルーティング情報を符号化するように適応される。

集合メンバーシップの簡潔表現を生成するための入力パラメータは、パケット識別子、フロー識別子、パケット・ペイロード・ダイジェスト、又は発行識別子の１つを含む。

ネットワークノードは、時間に依存する集合メンバーシップの簡潔表現を計算するように適応される。例えば、ｉＢＦ（又は集合メンバーシップの他の簡潔表現）は指定時間の後に失効し、攻撃者が、例えば特定のパケットフローのｉＢＦを認知しても、攻撃者はｉＢＦの失効前の短時間だけこの知識を利用し得る。

ネットワークノードは、転送ノードにおけるパケット処理コンテキストからの少なくとも１つの予測可能パラメータを含む入力パラメータを使用して、集合メンバーシップの簡潔表現を計算するように適応される。

集合メンバーシップの簡潔表現を生成するための入力パラメータは、パケットヘッダからの１つ又は複数のビットを含む。例えば、パケットヘッダは、パケットが資格を与えられたＱｏＳを表示する１つ又は複数のサービス品質（ＱｏＳ）ビットを格納している場合、これらのビットを入力として使用することができる。このことは、第１に、ヘッダ内に正しいＱｏＳビットを格納していないパケットが転送されないであろうこと（ｉＢＦが一致しないから）、第２に、ヘッダ内で定義されたＱｏＳがパケット転送で考慮されうること、の利点を有する。

本発明の第２の態様は、パケットルーティング情報を提供するネットワークノードを提供する。ノードは、パケットヘッダの中へ含めるためにパケットルーティング情報を集合メンバーシップの簡潔表現へ符号化する手段を備える。ノードは、転送ノードにおけるパケット処理コンテキストからの少なくとも１つの予測可能パラメータを含む入力パラメータを使用して、集合メンバーシップの簡潔表現を計算するように適応される。

転送ノードにおけるパケット「処理コンテキスト」は、例えばパケットが転送ノードに到着する入力ポートのポート番号（又は他の識別子）、パケットが転送ノードを出発する出力ポートのポート番号（又は他の識別子）、パケットが転送ノードに到着／出発する入力又は出力無線通信路（無線ネットワークの場合）、搬送波の波長（光ネットワークの場合）、パケットの到着時間、などのパラメータによって定義される。これらのパラメータの幾つかは、前もって予測可能であり、処理コンテキストの予測可能パラメータとして知られている。本発明の第２の態様によれば、処理コンテキストの１つ又は複数の予測可能パラメータは、ｉＢＦ（又は集合メンバーシップの他の簡潔表現）が生成されるときの入力として使用される。

第２の態様は、第１の態様と一緒に使用される。しかしながら、原理的に、そうする必要はない。というのは、本発明の第２の態様は、それ自身で攻撃に対するセキュリティの増加を提供し得るからである。

入力パラメータは、パケットの到着が予測される転送ノードのポートの識別子を含む。

本発明の第３の態様は、パケットルーティング情報を提供するネットワークノードを提供する。ノードは、パケットヘッダの中へ含めるための複数の非静的識別子としてパケットルーティング情報を表現する手段を備える。ノードは、少なくとも１つのパケット特定、フロー特定、又は処理コンテキスト特定パラメータを含む入力パラメータを使用して、識別子を計算するように適応される。

本発明の第１、第２、又は第３の態様のパケットルーティング情報は、第１のノードから１つ又は複数の第２のノードへのルートの情報であり、パケットは第１のノードから第２のノードへ送信されるように宛先を指定される。しかしながら、本発明はこれに限定されず、ルーティング情報は、追加的又は代替的に、ネットワークノードで利用可能な様々なサービスへパケットをルーティングすることに関連する。ノードは、受信されたパケットが、このノードからアクセス可能なサービスを或る一定の順序で訪問することを所望してもよい。例えば、パケットは、他のサービスを訪問する前に最初にファイアウォールサービスを訪問する。本発明は、ノード内のこの「内部ルーティング」ならびにノード間のルーティングへ応用される。

本発明の第１、第２、又は第３の態様のパケットルーティング情報は、第１のノードから第２のノードへの転送経路又は転送ツリーの表現を備える。

本発明の第４の態様は、パケットを受信する手段を備えるネットワークノードを提供する。ノードは、少なくとも１つのパケット特定、フロー特定、又は処理コンテキスト特定パラメータを使用して、１つ又は複数の非静的識別子を計算し、これらの各識別子が潜在的ルーティング判定を表すようにする手段、少なくとも１つの計算された識別子について、計算された識別子と、パケットのヘッダ内に格納されたルーティング情報とを比較し、潜在的ルーティング判定が行われるべきかどうかを決定する手段、及びこの決定に基づきパケットを操作する手段を更に有する。

本発明の第４の態様は、第１の態様に従って集合メンバーシップの簡潔表現として符号化されたルーティング情報を有するパケット又は第３の態様に従ってルーティング情報を有するパケットが受信されたときの、転送ノードにおける手順に関連する。本質的に、［１］及び［２］は、ｉＢＦを生成するためには、固定されたリンク識別子タグを使用するのに対し、本発明は、固定されないがパケット、フローなどに依存するリンク識別子タグを使用する。転送ノードは、パケットを正しく転送するためには、ｉＢＦ（又は集合メンバーシップの他の簡潔表現）の初期生成で使用されたリンク識別子タグに対応するリンク識別子タグを生成することが要求される。

計算されたリンク識別子タグは時間に依存する。更に、もし攻撃者が特定のリンクについてリンク識別子タグを認知するようなことがあれば、攻撃者はリンク識別子タグが変化する前の短時間だけこの知識を使用し得る。

パケットヘッダからの１つ又は複数のビットが、リンク識別子タグを計算するときに使用されてもよい。

第４の態様の方法は、パケットヘッダからの１つ又は複数のビットからパケット優先度を決定するステップを更に備え、パケットを操作するステップは、決定されたパケット優先度に従ってパケットを操作するステップを備える。

ネットワークノードにおけるパケット処理コンテキストからの少なくとも１つの予測可能パラメータは、リンク識別子タグを計算するときに使用される。

本発明の第５の態様は、パケットを受信する手段を備えるネットワークノードを提供する。ノードは、少なくとも１つの処理コンテキスト特定パラメータを使用して、１つ又は複数の識別子を計算し、各識別子が潜在的ルーティング判定を表すようにする手段、少なくとも１つの計算された識別子について、計算された識別子とパケットヘッダ内に格納されたルーティング情報とを比較し、潜在的ルーティング判定が行われるべきかどうかを決定する手段、及び決定に基づきパケットを操作する手段を更に有する。

本発明の第５の態様は、第２の態様に従って集合メンバーシップの簡潔表現として符号化されたルーティング情報を有するパケットが受信されたときの、転送ノードにおける手順に関連する。

パケットの到着が予測されるネットワークノードのポートの識別子が、リンク識別子タグを計算するときに使用されてもよい。

計算された識別子の少なくとも１つは、パケットがノードから送信される１つ又は複数のリンク、及び／又は、パケットが送信される１つ又は複数のノードを識別してもよく、ノードは、決定されたリンクに沿って及び／又は決定された他のノードへパケットを転送することによって、パケットを操作するように適応されてもよい。

集合メンバーシップの簡潔表現は、ブルームフィルタであってもよい。

本発明の他の態様は、相補的な方法を提供する。

本発明の更なる態様は、命令を格納したコンピュータ読み取り可能メディアを提供する。この命令は、実行されると、本発明の方法をプロセッサに実行させる。

上記から理解され得るように、本発明は、パケットヘッダ内の転送識別子が、経路指定子、即ち、パケットの取るべき経路を定義する指定子として働き、同時に、能力、即ち、明白に承認されたパケットのみを転送するというセキュリティ方針を、経路に沿った転送ノードに効果的に実施させる能力として働く、データパケット転送方法に関連する。提示されたアプローチにおいて、転送識別子は、パケット内容、送信者、受信者、送信者及び受信者間の経路、ノードからアクセス可能な異なるサービス間の経路、例えばＱｏＳ特性を安全に合図するために使用され得るパケットヘッダ内の１つ又は複数の「安全」ビット、及び時間窓のうちの１つ又は複数へ緊密に結合され得る。

本発明は、国際出願ＰＣＴ／ＥＰ２００８／０６１１６７号明細書及び［１−２］で説明される方法の拡張である。従前に提示されたアプローチを簡単に概括すると、ｉＢＦ発行者はｉＢＦの中へ含められる或る数の要素を選択する。発行者は要素からｉＢＦを構築する。次いで、結果のｉＢＦはユーザへ渡される。このユーザは典型的にはパケット送信者である。次いで、ユーザはｉＢＦをパケットヘッダの中へ置き、パケットをネットワークへ送出する。ｉＢＦ処理エンティティ、典型的にはネットワーク内の転送ノードが、ｉＢＦを格納したパケットを受信すると、転送ノードは、ｉＢＦを、前もって構成されたリンク識別子のリストと比較する。一致が存在するときは常に、転送ノードは、関連づけられた出力リンクに沿ってパケットを転送する。既存の作業において、ｉＢＦは事前に構成されたリンク識別子の集合の簡潔表現である。

本発明の１つの特徴は、パケット処理時にｉＢＦ内の要素を計算的に構築することである。これによって、ｉＢＦは、パケット又はパケットフローの先験的に知られた部分（例えば、パケットヘッダ識別子、パケットペイロード、フロー識別子）、転送ノードとｉＢＦ発行者（例えばＭＰＬＳ ＰＣＥのようなトポロジマネージャ）との間の共有シークレット、転送ノードにおける処理コンテキストの１つ又は複数の予測可能パラメータ（例えば、転送ノードへのパケットの到着が期待される入力ポート番号及び／又は転送ノードからのパケットの出発が期待される出力ポート番号）、及び時間のうちの１つ又は複数へ結合される。データパケット転送分野で［１−２］が使用されたように、事前に構成されたリンク識別子及びリンク識別子タグを使用する代わりに、本発明は計算的に生成されたリンク識別子を使用する。

本発明の１つの特徴として、構築時にｉＢＦの中へ挿入される要素をフロー特定又はパケット特定にするｉＢＦ構築／質問方法が提供される。これによって、各具体的ｉＢＦは、特定され承認されたフロー又はパケットと一緒に使用される場合にのみ使用され得る。こうして、発明者らは、承認されていないパケット、例えば異なるフローに所属するパケットのヘッダ内にｉＢＦが置かれるｉＢＦ再生攻撃の危険を緩和する。

本発明の他の特徴として、ｉＢＦ発行者とｉＢＦ処理エンティティとの間の共有シークレットを定期的に更新するアプローチが存在してもよい。結果として、発行されたｉＢＦは或る一定の時間枠の後では再使用され得ず（自動失効特性）、又は、明白な再キーイング要求があったときには再使用され得ない。これは、承認されたノードによる再生攻撃からｉＢＦネットワーキングアプリケーションを保護する効果的対策を提供する。

発信元ルーティングに基づくアプリケーションでｉＢＦを使用する具体的な場合、［１−２］の方法は、転送ノードとトポロジシステムとの間に共有シークレットが存在する方法によって拡張される。ここで、シークレットは時間ベース疑似ランダム関数の出力である。提案される共有シークレットリンク識別メカニズムは、ＤＤｏＳ攻撃からネットワークを徐々に保護する新規なネットワーク能力を構成する。

本発明の更なる特徴として、ｉＢＦは先行業績よりも緊密に所望のネットワーク経路（又は複数の経路）へ結合される。具体的には、ｉＢＦは、転送ノードにおける処理コンテキストの１つ又は複数のパラメータ、例えば転送ノードの入力ポート及び出力ポートの双方に強く依存する。（複数の転送ノードを通過するパケットを含む典型的なパケットフローでは、ｉＢＦは、幾つか又は全ての転送ノードにおける処理コンテキストの１つ又は複数のパラメータに依存する。）本発明のこの特徴は、増加されたセキュリティを提供するのと同様に、仮想的転送ノード内部サービスの導入を可能にする。即ち、ノード内で内部的にパッカをサービスへ渡すことができ、一度、そのサービスが依然として同一不変のｉＢＦを有するパケットを出力すると、ノードは転送ループを引き起こすことなくパケットを更に転送し得る。［１−２］で提示された構築の場合には、転送ループが引き起こされた。

本発明の更なる利点は、ネットワーク内の転送ノードのそれぞれで、非常に小さな転送表、例えば数十又は２百〜３百ビットの転送表が必要とされるだけで、依然としてフローごとに転送判定が行われ得ることである。

本発明の更なる特徴は、ｉＢＦがパケットヘッダ内の少数の「安全」ビットへ結合される方法を定義する。この方法は、ｉＢＦを特定のパケット又はパケットフローへ結合することとは反対に、ｉＢＦ発行者がｉＢＦ構築時に定義した値をパケットヘッダ内の特定ビットが正確に有するかどうかを転送ノードが安全にチェックすることを可能にする。例えば、パケット内の「安全」ビットは、特定のＱｏＳパラメータを指定するために使用され得る。或る一定のビットパターンは「即時転送」を指定し、他のパターンは「キャッシュ・アンド・転送」を指定する。提示される方法は、パケット送信者がこれらのビットを自由に設定することを不可能にし、パケット送信者はパケット又はフローについて特定値を使用するように拘束される。

本発明の更なる利点は、少なくとも同じフローに所属するパケットを検出することを超える、トラフィック分析が事実上不可能になる範囲まで、異なるパケット又は異なるパケットフローのｉＢＦが相互に異なることである。即ち、相異なるフローに所属する２つのパケットが与えられたと仮定すると、攻撃者は、それらのパケットが同じ当事者によって送信されたのか、又はそれらのパケットが同じ当事者又は複数の当事者へ宛てられているのかを判別し得ない。

注目に値することとして、この態様は更にｉＢＦ間の相関の計算を不可能にし、これによって事実上、多数の稼働ｉＢＦを分析することによって新しいｉＢＦを構築することを不可能にする。

本発明の好ましい実施形態は、添付の図面を参照し、例を挙げて説明される。

図１は、本発明の実施形態による識別子の計算を示す。 図２は、ネットワークの略図である。 図３は、フィルタを形成する略図である。 図４は、他のフィルタを形成する略図である。 図５は、本発明の実施形態による方法の主なステップを示す。 図６は、本発明の実施形態による方法の主なステップを示す。

パケットルーティング情報がパケットヘッダ内のブルームフィルタ（「ｉＢＦ」と称する）の中に格納された本発明の好ましい実施形態が説明される。しかしながら、本発明は、これに限定されず、ルーティング情報を集合メンバーシップの任意の簡潔表現へ符号化してもよい。もっとも、好ましくは、ブルームフィルタ又はブルームフィルタ等価物が使用される。実際、本発明の幾つかの実施形態では、集合メンバーシップの簡潔表現を使用することなく、パケットルーティング情報がパケットヘッダの中に格納されてもよい。

一般に、パケット内ブルームフィルタ（ｉＢＦ）は、各パケットに要素リストを含める必要があってもリスト全体の空間要求が多すぎるネットワークアプリケーションに適している。セキュリティの観点から、個々の要素の値は開示されないままであることが望ましい。

一般化するために、ｉＢＦの中で搬送され、本発明に従ってネットワーク処理エンティティから質問されるオブジェクトを単に要素と呼ぶことにする。これらの要素は、本発明が応用される特定のネットワークアプリケーションに依存して種々の形態を取る。要素は、例えばインタフェース名、ＩＰアドレス、証明書、リンクＩＤなどに関連してもよい。ｉＢＦの要素は「識別子」とも呼ばれてもよい。というのは、要素は、例えばインタフェース、ＩＰアドレス、証明書、ネットワークリンクなどを識別するからである。

ｉＢＦパラメータの基本的表記法は、標準のブルームフィルタの用語と同じである。ｉＢＦは長さｍのビットベクトルである。構築時に、ｉＢＦの中へ含められるべきｎ個の要素の全てについて、発行者はｋ個のビット位置を選択し、それらを「１」へ設定して他の全ビットを「０」のままに残す。同様に、要素がｉＢＦ内に存在するかどうかをチェックするために、処理エンティティは対応するｋ個のビット位置をチェックする。もし選択された位置のいずれかが「０」に等しければ、構築時に要素がｉＢＦの中へ挿入されなかったことを処理エンティティは確認し得る（ゼロ偽陰性の特性）。もしｋビット位置の全ビットが「１」へ設定されていれば、構築時に要素がｉＢＦの中へ実際に挿入されたことを確信せる確率的論拠が存在する。しかしながら、他の要素の挿入に起因して「１」へ設定されたビットが、非挿入要素を真へ転じさせる場合がある。これは偽陽性と呼ばれる。
動的名前を有するパケット転送

本発明の１つの特徴は、構築時に発行者がｉＢＦの中に要素を挿入し、処理時に処理要素がメンバーシップをチェックする新しい方途を定義することである。１つの重要な点は、入力パラメータの集合及び一方向性関数を使用し、構築時及び検証時に各要素のブルームフィルタに分かりやすい名前を構築することである。

一般に、普通に使用されるパケット転送アプローチは、宛先ノードを指名すること、発信元ルーティングの場合にはパケットが通過する中間ノードを指名することに基づく。［１−２］で与えられるアプローチは、ノードではなくリンクを指名することで、この従来のアプローチから逸脱している。［１−２］において、ノードは本質的に匿名又は無名に維持される。

本発明の１つの実施形態において、発明者らは、例えばリンクへ非静的識別子を原則的に与えることによって、先行アプローチから更に逸脱する。［１−２］では、リンクは静的な「リンク識別子タグ」を与えられる。「リンク識別子タグ」は、一度生成されると変化しない。このリンク識別子タグは、そのリンク上での送信を要求される全てのパケットについて使用され、パケットの発信元、宛先、フロー、又はタイプに関係しない。本発明では対照的に、リンクは非静的識別子を与えられる。この非静的識別子は、パケット特定パラメータ、フロー特定パラメータ、又は処理コンテキスト特定パラメータのうちの１つ又は複数に依存してもよい。即ち、各リンクの事前に定義された名前の集合に頼る代わりに、本発明はリンクへ「動的な」コンテキスト依存の名前を提供する。この名前は、例えばパケット内容、パケットが取る経路、又は他のパラメータに依存する。

こうして、提示されるアプローチにおいて、転送判定は完全に動的な計算アプローチに基づく。この場合、ｉＢＦ、パケット内容、及び随意的に、処理コンテキストが使用され、転送されるとすればどこへパケットが転送されるかを計算的に決定する。パケットは、その発信元又は宛先を指名する識別子を格納する必要はない。更に、個別のフローに所属するパケット内のｉＢＦフィールドは完全に異なる。というのは、動的リンク識別子は、フロー間で完全に異なるからである。実際、リンクがパケット依存識別子を与えられる実施形態において、リンク識別子は同一フローのパケット間で異なる。これは、潜在的攻撃者がＤＤｏＳ攻撃のために悪意パケットを導入することを非常に困難にする。
安全なｉＢＦ運用

発明者らのアプローチにおいて、構築時に「１」へ設定され、処理時に、例えば転送ノードで値「１」を有するかどうかをチェックされるｋ個のビット位置は、ｉＢＦ構築時及びｉＢＦ処理時の双方で、アルゴリズム的に選択される。このアプローチの１つの新規な態様は、パケット処理時に、ｋ個の非ゼロビット位置を選択するアルゴリズムへの入力パラメータが、少なくとも１つの非静的入力パラメータを含むことである。パラメータは、処理されつつあるパケットからの時間不変要素（例えば、パケット依存又はフロー依存要素）、転送ノードへ構成された半静的要素、及びパケットがどこから来てどこへ転送されるかのコンテキストによって決定される動的要素を含んでもよい。

ｉＢＦを生成するために使用される入力パラメータがパケット処理時に取る値をｉＢＦ発行者が予測し得る限り、ｉＢＦ発行者は、パケットが処理されるときに生成されるｋ個の非ゼロビット位置と同じ非ゼロビット位置をｉＢＦ発行時に計算し得る。即ち、ｉＢＦ発行者は、パケット内で搬送される時間不変値、即ちｉＢＦをパケット又はフローへ結合するために使用されるパケット又はフロー識別子、転送ノードへ構成された半静的な値（例えば、共有秘密鍵Ｋ）、及びパケットが取ることを想定されパケット処理時の動的入力値を決定する経路を知っているので、ｉＢＦ発行者は、処理要素が処理時に取得するｋ個の非ゼロビット位置と同じ非ゼロビット位置を構築時に計算し得る。従って、ｉＢＦは、これらのｋ個のビット位置をｉＢＦ内で「１」へ設定し、処理時にパケットが転送規準と一致することを引き起こし得る。

図２は、ノードＡ〜Ｌを示すネットワークの略図である。パケットはノードＡから経路Ａ−Ｂ−Ｃ−Ｋ、Ａ−Ｂ−Ｃ−Ｄ−Ｅ、Ａ−Ｂ−Ｃ−Ｄ−Ｈ−Ｉに沿って送信される。従って、ノードＤは転送ノードとして行為する１つのノードである。というのは、それはノードＣからパケットを受信し、ノードＥ及びＨへパケットを転送するからである（ノードＢ、Ｃ、及びＨも転送ノードである）。［１−２］で概略的に説明されるように、パケットルーティング情報はパケットヘッダ内のｉＢＦの中に格納される。ｉＢＦは、ノードＡから送信されるパケットのヘッダ内に挿入されるようにｉＢＦ発行者（図示されず）によって生成される。本発明を応用するためには、ｉＢＦ発行者は、例えばノードＤでパケットが処理されるときに、ｉＢＦを生成するために使用される入力パラメータの値を予測し得ることが必要である。これは、パケットがノードＤで正しく処理されることを保証するためである。

本発明によれば、ノードＡから送信されるパケット内に含められるｉＢＦは、少なくとも１つのパケット特定、フロー特定、又は処理コンテキスト特定のパラメータを含む入力パラメータを使用して生成される。したがって、ｉＢＦは、［１−２］におけるように不変ではなく、異なるフローのパケット間（この場合、入力パラメータはフローを特定する特定のパラメータを含む）、異なるパケット間（この場合、入力パラメータはパケットを特定する特定のパラメータを含む）、又は転送ノード、例えばノードＤで異なるように処理されるパケット間（この場合、入力パラメータは処理コンテキストを特定するパラメータを含む）で変動する。

図５は、本発明の実施形態に従ってｉＢＦを生成するための主なステップを示す流れ図である。

最初に、ステップ１において、１つ又は複数のパケットを送信する必要がある発信元ノード６（例えば、図２のノードＡ）は、パケットフローについてルーティング情報を要求する。要求は、ルーティング機能を遂行する他のネットワークノード７（図２では示さず）へ行われる。

ステップ２において、ネットワークノード７は、パケットフローについてネットワーク経路情報を決定又は検索する。図２の例では、ネットワーク経路情報は経路Ａ−Ｂ−Ｃ−Ｋ、Ａ−Ｂ−Ｃ−Ｄ−Ｅ、Ａ−Ｂ−Ｃ−Ｄ−Ｈ−Ｉに関連することになる。

ステップ３において、ネットワークノード７は、ネットワーク経路に沿ったノードの処理コンテキストパラメータを決定する。例えば、図２のノードＤの場合、処理コンテキストは、パケットがノードＣからの受信を期待される入力ポート、パケットがノードＥ及びＨへの転送を期待される出力ポート、（もし予測可能であれば）パケットがノードＤに到着する時間、光送信の場合の搬送波の波長、無線送信の場合の無線通信路などのうちの１つ又は複数を含む。これは、各経路、経路内の各転送ノードについて反復される。

ステップ４において、ネットワークノード７はｉＢＦを決定する。ｉＢＦを計算するためにネットワークノードによって使用される入力パラメータは、少なくとも１つのパケット特定、フロー特定、又は処理コンテキスト特定のパラメータを含む。可能なパケット特定又はフロー特定パラメータの例は、パケット識別子、フロー識別子、パケット・ペイロード・ダイジェスト、又は発行識別子を含む。ｉＢＦは、ステップ２で決定された所望のネットワーク経路を入力として更に取る。ｉＢＦがパケットフローへ結合されるとき、フロー識別子がノードＡによってノード７へ送信されるか、又はノード７によって生成されて、Ａへ送信されてもよい。ｉＢＦが単一のパケットへ結合されるとき、ノードＡが幾つかのパケット識別子をグループとしてノード７へ送信するか、又はノード７が識別子のグループを生成し、それをｉＢＦと一緒にノードＡへ送信するか、又はノードＡ及びノード７がパケット識別子を生成するアルゴリズムに合意してもよい。例えば、パブ／サブ・システムでは、トピックＩＤ（これに加えて、メタデータ）が存在してもよく、これから一連のパケット識別子が引き出され得る。

次いでステップ５において、ネットワークノード７はｉＢＦを発信元ノードＡへ戻す。発信元ノードは、ステップ６でｉＢＦをパケットの中へ組み立て、ステップ７でパケットを送信する。

好ましい実施形態は、一方向性関数Ｆを使用してｉＢＦを生成する。一方向性関数Ｆは３つの入力を取る。即ち、ｉＢＦ発行者と処理要素（例えばノードＤ）との間で共有される秘密鍵Ｋ、パケット内に置かれるパケット又はフロー識別子Ｉ、及びノードＤにおけるパケットの処理コンテキストからの１つ又は複数の予測可能値によって定義されるコンテキストＣである。ノードにおける処理コンテキストは、値、例えば、パケットが到着するノードの入力リンク（又は入力ポート）、パケットが送信されるノードの出力リンク（又は出力ポート）、パケットがノードに到着する時間、光送信の場合の搬送波の波長、無線送信の場合の無線通信路、及び他の値を含む。これらの値の幾つかは、前もって予測可能であってもよく、従って「予測可能」パラメータであり、幾つかは前もって予測可能でなくてもよい。図２のノードＤの例では、期待される到着リンクはノードＣからのリンクになり、一致する出発リンクはノードＥ及びノードＨへ進むリンクである。ノードＩ、ノードＬへ進むリンク、及びノードＣへ戻るリンクも潜在的な出発リンクちなるが、それらはパケット内のルーティング情報と一致しない（偽陽性が存在しない限り）。従って、ノードＤは、＜Ｃ，Ｅ＞、＜Ｃ，Ｈ＞、＜Ｃ，Ｉ＞、＜Ｃ，Ｌ＞の全ペアを（おそらく並列に）考察することになる。

従って、発明者らは次の一方向性関数を仮定し、
Ｏ＝Ｆ（Ｋ，Ｉ，Ｃ） （１）
ｉＢＦの構築時に「１」へ設定され、（例えばノードＤで）パケットが処理されるときに「１」であることがチェックされるｋ個のビットを選択する。入力値は次のとおりである。即ち、Ｋは、ｉＢＦ発行者とｉＢＦ処理要素との間で共有されるシークレットである。（図２の例において、シークレットＫは、ｉＢＦ発行者と、パケットが処理されるノードＢ、Ｃ、Ｋ、Ｄ、Ｅ、Ｈとの間で共有される（ノードＡは、送信ホストであるときシークレットを知っている必要はない。もしノードＡが送信ホストのプロキシであれば、ノードＡは最初の転送判定を既に知っており、この場合、再びノードＡはシークレットを知っている必要はない）。（ｉＢＦ発行者とノードＢ、Ｃ、Ｋ、Ｄ、Ｅ、Ｈとの間で共有される単一のシークレットではなく、別々のシークレット、例えばｉＢＦ発行者とノードＢとの間で共有される第１のシークレットＫ＿Ｂ、ｉＢＦ発行者とノードＣとの間で共有される第２のシークレットＫ＿Ｃなどが存在するかもしれないことに留意されたい。） Ｉはパケット内で搬送されるパケット又はフロー識別子である。Ｃは、処理要素におけるパケット処理コンテキストによって決定され、典型的には、入力ポート及び出力ポート識別子の１つ又は双方、即ち、パケットが処理要素に到着する入力ポートの索引、及びパケットが処理要素から転送されてもよい出力ポートの索引を含む。図１は、一方向性関数Ｏの略図である。出力Ｏは、ｉＢＦが生成されるとき「１」へ設定されるビットのｋ個の位置を与える。これらのビットは、（例えばノードＤで）パケットが処理されるときにチェックされる。

値Ｉは、パケット内で識別子として搬送され得る。図２は、ｉＢＦ、値Ｉ、及びペイロードを含むパケット１を略図的に示す。代替として、値Ｉはパケット内容それ自体から引き出される。例えば、それはペイロードダイジェスト、ＩＰフロー識別子、例えば＜ＩＰ＿ｓｒｃ、ＩＰ＿ｄｓｔ、ｐｏｒｔ＿ｓｒｃ、ｐｏｒｔ＿ｄｓｔ、ｐｒｏｔｏｃｏｌ＿ｉｄ＞のハッシュ（ここで、ＩＰ＿ｓｒｃ／ｄｓｔは発信元及び宛先ＩＰアドレスであり、ｐｏｒｔ＿ｓｒｃ／ｄｓｔは発信元及び宛先ポート識別子であり、ｐｒｏｔｏｃｏｌ＿ｉｄは使用されるプロトコルの識別子である）、又は純粋な発行／引用ネットワークにおける発行ＩＤである。

関数Ｆは十分に高速及び簡単であることが望ましく、パケット処理時に、パケット処理要素によってチェックされるコンテキストの集合について並列に計算され得ることが望ましい。例えば、対称暗号法、例えばＡＥＳを使用する場合、鍵Ｋを暗号化鍵として使用し、コンテキストＣを初期ベクトルとして使用して、値Ｉを暗号化すると、出力は数クロックサイクルで与えられる。しかしながら、本発明は特定の関数Ｆに限定されないことに留意されたい。一般に、関数Ｆの選択は、セキュリティと処理時間／コストとの妥協である。例えば、関数Ｆとしてフルハッシュ関数を使用することは、非常に良好なセキュリティを提供することになるが、比較的長い処理時間を費やす。逆に、Ｆとして簡単な一次関数を使用することは、非常に短い処理時間でよいが安全度は小さくなる。

図６は、転送ノード、例えば図２のノードＤで実行される主要なパケット操作ステップを示す。

図６のステップ１（図５のステップ１に対応する）で示されるように、パケットが発信元ノード６（例えば、図２のノードＡ）から送信された後、それは転送ノード８（例えば図２のノードＤ）で受信される。これは図６のステップ２として示される。

ステップ３において、転送ノード８は、パケットについて１つ又は複数の処理コンテキストパラメータを決定する。処理コンテキストパラメータは、パケットが転送ノード８で受信された入力ポート、パケットが転送ノード８へ到着した時間、光送信の場合の搬送波の波長、無線送信の場合の無線通信路などのうちの１つ又は複数を含む。

ステップ４において、転送ノード８はｉＢＦについて識別子の集合を決定する。これらの識別子は、図５のステップ４においてｉＢＦが発信元ノード６で決定された方途と同じ方途で決定される。即ち、発信元ノードで使用された入力パラメータと同じ入力パラメータが使用され、識別子は発信元ノードと同じ方途で入力パラメータから決定される。転送ノードの各利用可能出力ポート（又はノード内部ポート）は、「この出力ポートに沿ってパケットを転送すべきか？」の形態をした潜在的「ルーティング判定」として考察され得る。従って、ノードは、好ましくは、それぞれの潜在的な次のホップ処理ユニットについて、明確な識別子、即ち、「１」へ設定されたｋ個のビットの明確な集合を計算する。ここで「次のホップ処理ユニット」は、物理的ネットワークインタフェースに限定されず、内部ノードプロセスも含んでもよい。（ノード内部プロセスへ本発明を応用する例は、この後で図４に関して与えられる。）

ステップ５において、転送ノードは、ステップ４で決定された識別子を、受信されたパケット内のｉＢＦに対してチェックする。各識別子は、ｋ個のビットが「１」へ設定され、他の全ビットが「０」へ設定されたｍビットワードの形態を有する。ステップ５は、それぞれの決定された識別子について、受信されたパケット内のｉＢＦの対応するｋ個のビットが全て「１」へ設定されているかどうかのチェックから構成される。

ステップ６において、転送ノード８は、ステップ５の結果に基づき転送判定を行う。もしステップ５の結果が、識別子について、受信されたパケット内のｉＢＦの対応するｋ個のビットが全て「１」へ設定されていることであれば、その識別子に対応するリンクに沿って転送ノードからパケットを転送する判定が行われる。しかしながら、もしステップ５の結果が、識別子について、受信されたパケット内のｉＢＦの対応するｋ個のビットが全て「１」へ設定されているのはないことであれば、その識別子に対応するリンクに沿ってパケットを転送しない判定が行われる。図２の例において、ノードＤはノードＥ及びＨへパケットを転送する判定を行うが、（パケットをノードＬ及びＩの１つ又は双方へ転送することを引き起こす偽陽性が存在しない限り）ノードＬ及びＩへは行わない。

ステップ７において、転送ノード８は、ステップ６で識別されたリンクに沿ってパケットを転送する。

パケットは、続いて更なるノード９で受信される。図６の方法は、更なるノード９で反復される。もっとも、もしノード９が終局的な宛先ノード、例えば図２のノードＥであれば、図６の方法は、パケットがノードＥから送信されるリンクを識別せず、また偽陽性が存在しない限り、パケットがノード９から更に送信されることはない（もっとも、パケットは、この後の「経路上ルーティング」を参照して説明されるように、ノードＥにおける１つ又は複数のサービスへルーティングされてもよい）。代替として、ノードＥは自分が終端ノードであることを知ることができ、常に全ての到着パケットが自分に宛てられているものと仮定してもよい。

転送ノードにおける静的処理コンテキストへｉＢＦを結合し、パケット又はパケットフローへ結合しないことによって、利点が提供されうることに留意されたい。このｉＢＦは、その処理コンテキストを有する転送ノードで受信された全パケットへ適用されるので静的と見なされ得る（もっとも、ｉＢＦは有限寿命を有するようにされてもよい）。例えば、もしｉＢＦが転送ノード７で特定の入力ポートへ結び付けられたならば、転送ノード７のその入力ポートで受信された全てのパケットは、異なるフローに所属するパケットでも、そのｉＢＦに従って処理されるはずである。この実施形態を実現するため、ｉＢＦは図５のステップ４で決定され、識別子は図６のステップ４で決定されることになる。この場合、処理コンテキスト特定パラメータが使用されるが、パケット依存又はフロー依存パラメータは使用されない。

［１−２］は、複数の候補ｉＢＦが計算され、候補ｉＢＦの１つ、例えば偽陽性の最低確率を有する候補ｉＢＦが選択されて、パケットの中へ含められる方法を開示する。この方法は、複数の候補ｉＢＦを決定し、パケット内に含めるために候補ｉＢＦの１つを選択し、どの候補ｉＢＦが選択されたかの表示をパケット内に置くように図５のステップ４を修正することによって、本発明へ応用されてもよい。従って、図６の方法において、どの候補ｉＢＦが選択されたかの表示を転送ノード８が受信パケットから読み取り、ステップ４で識別子を決定するときに前記表示を使用するという追加の特徴が必要となる。

図５及び図６の方法は、コンピュータ制御のもとで実施されてもよい。例えば、適切なプログラムがコンピュータ読み取り可能メディアの中に記憶され、プロセッサを制御して本発明の方法を実行させるように使用されてもよい。
セキュリティを向上した発信元ルーティング

述べたように、本発明は、［１、２］で説明された発信元ルーティングベースのデータパケット転送に関連して応用されてもよい。上記で説明されたように、［１、２］の発信元ルーティング転送アプローチは、基本的に、出発転送ノードインタフェースごとにリンクＩＤタグ（ＬＩＴ）の集合を定義し、ネットワーク経路上でＬＩＴをＯＲ結合することによって転送識別子（ＦｉＤ）を構築する。ＬＩＴ値はブルームフィルタ準備形態であるから（各ＬＩＴはｍビットを格納し、そのｋ個のビットだけが１へ設定される）、結果の値はパケットヘッダ内に置かれ得るブルームフィルタである。本発明がこれに応用されるとき、［１−２］の不変ＬＩＴ（従って不変ＩＢＦ）は、非静的リンク識別子、従って非静的ｉＢＦによって置換される。

述べたように、本発明は、インタフェースごとに多数のＬＩＴを単一のシークレットＫで置換することによって実現される。このシークレットＫは、ノードごと又はインタフェースごとに唯一無二であってもよい。この更なる利点は、転送表のサイズを数十又は数百ビットへ縮小できることである。というのは、［１，２］で説明される多数のリンクＩＤタグの代わりに単一の値Ｋだけで足りるからである。

本発明の更なる実施形態において、式（１）で使用されるシークレットＫは、疑似ランダム関数Ｋ＝Ｆ（ｓｅｅｄ，ｔ）を用いて生成される。ｓｅｅｄ値は、転送ノード（ｉＢＦ処理要素）及びトポロジシステム（ｉＢＦ発行者）によって知られていなければならない。それらの双方は、緩いクロック同期を維持する。アプローチの利点は、ｓｅｅｄが配布された後、転送ノードとトポロジノードとの間で要求されるシグナリングが非常に小さいことである。この実施形態では、ｉＢＦが有限寿命を有する点でｉＢＦも時間依存性である。これはセキュリティを更に改善する。というのは、ｉＢＦを認知するようになった攻撃者は短時間だけこの情報を使用でき、この時間の後にｉＢＦは「失効」し、このｉＢＦを格納するパケットはネットワークを介して転送されないからである。
セキュリティを向上された転送判定

本発明の更なる実施形態において、パケットの中で搬送されるＲＩＤ（ランデブＩＤ）［１，２］又はＩＰフロー指定子の５つ組が、パケット又はフロー識別子Ｉとして使用される（図３を参照）。これによって、攻撃者は、ｉＢＦを計算するため最初に使用されたＲＩＤ又はＩＰアドレス又はＴＣＰ／ＵＤＰポートとは異なるものを有するｉＢＦを使用することができない。更に、公開鍵に基づくＲＩＤの有効性は、ディジタル署名アルゴリズムを用いて検証される。代替として、ＲＩＤは、一方向性アルゴリズムを使用してペイロードのダイジェストを計算することにより形成されてもよい。

図３の左側にあるトポロジ：Ｚ形成の図は、転送ホップ（Ｓ−１、１−２などで表される）ごとに関数（Ｆｋ）を適用することによってｉＢＦを計算することを示す。フロー特定情報に加えて、各Ｆｋは出力インタフェースの転送コンテキスト特定パラメータを使用する。結果のビットストリングはｉＢＦパケットヘッダの中へ組み立てられる。このｉＢＦパケットヘッダは、今後はｚフィルタと呼ばれる。パケットは簡単に１で示される。図３の右側部分は、パケットが受信されたとき、それら自身のＦｋの結果と、受信されたｚフィルタ名パケットとの一致に基づき、転送判定を行う転送ノードでの動作を示す。

本発明の更なる実施形態において、発明者らは、式（１）のコンテキストＣが、ノードについてペア＜＃ｉｎ，＃ｏｕｔ＞から構成されるものと定義する。ここで、＃ｉｎはノードにおける到着インタフェースの索引であり、＃ｏｕｔはノードにおける出発インタフェースの索引である。パケットごとの入力Ｉは、この場合、ペア＜ＲＩＤ，ｄ＞から構成される。ここで、ＲＩＤはパケット又はフローごとの識別子であり、ｄはパケット内で搬送される小さい整数である。この整数は、ｉＢＦの充填レートを最適化するため複数の候補表現を有するように使用される。Ｐ．Ｊｏｋｅｌａ、Ａ．Ｚａｈｅｍｓｚｋｙ、Ｃ．Ｅｓｔｅｖｅ、Ｓ．Ａｒｉａｎｆａｒ、及びＰ．Ｎｉｋａｎｄｅｒ著、「ＬＩＰＳＩＮ：Ｌｉｎｅ ｓｐｅｅｄ ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ ｉｎｔｅｒ−ｎｅｔｗｏｒｋｉｎｇ」、ＡＣＭ ＳＩＧＯＭＭ、バルセロナ、２００年８月を参照されたい。（簡単に述べれば、候補ｉＢＦの集合が生成され、使用するために１つの候補ｉＢＦ、例えば、偽陽性の最低確率を有する１つの候補ｉＢＦが選択される。整数ｄは、選択された候補ｉＢＦを識別するために使用される）。

ｉＢＦ処理時に、入力インタフェース＃ｉｎを介して、値＜ｄ，ＲＩＤ＞及びｉＢＦ値を格納したパケットを受信した転送ノードは、各出力リンク＃ｏｕｔ及び出力リンクで現在有効な全てのＫについて関数Ｆ（Ｋ，＜ＲＩＤ，ｄ＞、＜＃ｉｎ，＃ｏｕｔ＞）を評価する（Ｋは、上記で言及されたように時間依存であることを念頭に置かれたい）。Ｆ（）の出力は、常にｋ個のビット位置の集合であり、これらのｋ個のビット位置はｉＢＦ値のＦＩＤに対してチェックされ、全てが１へ設定されているかどうかを調べられる。全てのｋ個のビットが１へ設定されている場合、一致するインタフェース＃ｏｕｔに沿ってパケットが転送される。もしｋ個のビットのうちの１つ又は複数のビットが１へ設定されていなければ、そのインタフェースに沿ってパケットは転送されない。

このアプローチは、問題とする経路へｉＢＦを緊密に結合する。もし第３者が特定のｉＢＦ値を有するパケットを送信しようと試み、それらが他の入力インタフェースを介して経路のいずれかの転送ノードに到着したならば、生成されるｋ個のビット位置が異なるであろう。結果として、パケットは偽陽性の一致が存在するときにのみ転送されることになる。

経路上のサービス
これまで、本発明は、１つのノードから他のノードへネットワークを介してパケットをルーティングすることに関して説明されてきた。しかしながら、本発明は、これに限定されず、追加的又は代替的に、ノードからアクセス可能な経路上のサービスへ内部ルーティングすることへ応用され得る。データセンタ及び他の企業ネットワークにおいて、パケットが所定の順序で或る一定の経路上のサービスを訪問することが度々必要となる。他の必要性は、訪問されるサービスの順序を容易に変更し得ることである。Ｊｏｓｅｐｈ，Ｄ．Ａ．、Ｔａｖａｋｏｌｉ，Ａ．、 Ｓｔｏｉｃａ，Ｉ著、「Ａ Ｐｏｌｉｃｙ−ａｗａｒｅ Ｓｗｉｔｃｈｉｎｇ Ｌａｙｅｒ ｆｏｒ Ｄａｔａ Ｃｅｎｔｅｒｓ」、ＳＩＧＣＭＭ、２００８年において、ｐスイッチと呼ばれる新しい転送ノード設計が提示された。ｐスイッチは、到着ＭＡＣアドレス及びインタフェース索引を使用して、到着パケットを処理するためにネクスト・ホップ・サービスを決定する。したがって、その設計では、単一ノードの内部で或る所定順序の転送を実施でき、経路上のサービスについて物理的又は論理的に別個のノードを必要としない。

本発明を使用して経路上のサービスを実現するため、ｉＢＦに基づく単一転送ノードの内部で、経路上のサービスを或る一定の順序で訪問するｉＢＦを構築することが可能である。［１，２］で提示される最初のｉＢＦ設計では、パケットがどこから来たかに基づきパケットを選択的に転送することは不可能であった。というのは、パケットは、全ての一致する出発インタフェースへ常に転送されたからである。しかしながら、本発明では、ｉＢＦ作成時及び処理時の双方で、入力インタフェース索引を関数Ｆへの入力値として使用することによって、単一ノードの内部でサービスの訪問順序を決定することが可能になる。

例えば、図４で示される構造を考える。図４は、スイッチング構造２、及びスイッチング構造２からアクセス可能な多数のサービスを表示する。サービスは、全て転送ノードの内部にあるか、転送ノードからアクセスされる別個のノードとして実現される。パケットが物理インタフェース＃１、例えばエッジルータ５を介して到着するとき、パケットは最初に第１のサービス（この例ではファイアウォールサービス３）へ向かって横断することを強制され、パケットが第１のサービスから到着するときにのみ、第２のサービス（この例では負荷平衡サービス４）へ通過することを強制される。以下同様である。即ち、パケットがインタフェース＃１を介してスイッチング構造２に到着するとき、出発インタフェース＃３及び＃４について計算されたｋ個のビット位置は、（偽陽性が存在しない限り）到着パケットヘッダ内のｉＢＦと一致しない。その代わりに、出発インタフェース＃２のみが一致を与え、ノードでパケットをファイアウォールサービス３へ通過させる。（ファイアウォールサービス３が転送ノードの内部に存在するとき、出発インタフェース＃２は「仮想インタフェース」と考えられ得ることに留意されたい。というのは、インタフェース＃２は、転送ノードから他のノードへパケットを送信するためには使用され得ないからである。）他方、一度、パケットがインタフェース＃２を介してファイアウォールサービスから到着すると、今度は、Ｆ（Ｋ，＜ＲＩＤ，ｄ＞，＜＃２，＃３＞）によって与えられるｋ個のビット位置は一致を与えるが、他の出発インタフェースについては与えない（偽陽性の可能性を無視する）。従って、パケットはインタフェース＃３を介して負荷平衡サービス４へ転送される。

この実施形態の解決法の利点は、パケットがスイッチング構造２を横断する間にパケットヘッダ内のｉＢＦを変更して、所望の順序でサービス訪問を保証する必要がないことである。更に、ｉＢＦ発行者ノードで経路上のサービスの訪問順序を再定義することが非常に容易である。

パケットヘッダ内の制御情報を使用する
本発明の更なる実施形態において、転送ノードでの様々な動作についてパケットヘッダ内の多数の「制御ビット」を使用するセキュリティ方法が説明される。パケットヘッダ内の制御ビットの設定を強制することによって、ｉＢＦ発行者は、動作の集合の中の特定の動作が通過パケットで実施される必要があること、又はパケットが或る一定のやり方で操作される（例えば、特定の優先度に従って操作される）必要があることを転送ノードへ安全に「合図」し得る。

制御ビットは、パケットヘッダ内に存在する少数のビットであり、式（１）の関数Ｆの入力パラメータとして使用される。即ち、制御ビットはパケット依存入力パラメータＩの一部分である。したがって、制御ビットは改ざんに対して保護される。即ち、制御ビットの修正は、関数Ｆからの出力を変更し、ｋ個の非ゼロビットの位置を変更し、これによって転送ノードは、（偶然に、偽陽性が存在しない限り）パケットを脱落させる。

これらの制御ビットの１つの実用的な使用例は、転送ノードでフロー優先度を定義することである。即ち、この制御情報を使用して、或る一定のトラフィックについて差別化された送信品質を安全に提供し得る。パケットが到着したとき、或る一定の優先度を指定するように設定された制御ビットを有するならば、かつ、関数Ｆからの結果の出力が１つ又は複数の出発インタフェースと一致するならば、パケットは差別化された処置を受けてもよい。例えば、パケットは、同じ出発インタフェースについて待ち行列となっている他の潜在的パケットよりも先に、転送ノードから送信されてもよい。提示されたメカニズムを用いると、経路上の転送ノードは、トラフィックを優先づけるように事前に構成される必要がなく、パケットそれ自身が、改ざんに抵抗するやり方で優先度情報を格納してもよい。

制御ビットの他の応用は、キャッシングのサポートを良好にするために制御ビットを使用することである。或る一定のデータは、他のデータよりも可能性としてキャッシングから取得され、この情報は制御ビットとして配達され得る。

これまでの説明から分かるように、本発明は様々な態様を介して次のような利点を提供することができる。

本発明の１つの態様は、パケット・データ・ネットワーク内のパケットのｉＢＦをパケット特定、フロー特定、又は処理コンテキスト特定パラメータに依存させ、これによって、ｉＢＦの依存パラメータがパケット間で同一に維持されない限り、１つのパケットから他のパケットへｉＢＦをコピーすることを不可能にする。本発明の相補的態様は、パケット・データ・ネットワーク内のパケットの転送識別子をパケット特定、フロー特定、又は処理コンテキスト特定のパラメータに依存させ、これによって、識別子の依存パラメータがパケット間で同一に維持されない限り、１つのパケットから他のパケットへ転送識別子をコピーすることを不可能にする。ｉＢＦ又は転送識別子は、［１−２］のように固定されていない。これらの態様は、現在のパケット・データ・ネットワーク内に存在する多種のセキュリティ脅威、例えば、発信元アドレスのなりすまし、制御情報の改ざんなどを防止する利点を有する。

更に、本発明は、パケット・データ・ネットワーク内のパケットのｉＢＦ又は転送識別子を時間依存にし、これによって、失効した転送識別子の使用を不可能にする。この態様は、攻撃者が特定の転送識別子を悪用することから生じる攻撃の延長を防止し、（攻撃者が最初に転送識別子を獲得したどんな手段によっても）新しい転送識別子を定期的に獲得することを潜在的攻撃者に強制する利点を有する。これは潜在的攻撃者のコストを上昇させ、問題の攻撃シナリオを、儲けを少なくするものにする。

本発明の更なる態様は、パケット・データ・ネットワーク内のパケットのｉＢＦ又は転送識別子を、転送ノードにおけるパケットの処理コンテキストの１つ又は複数の予測可能パラメータ、例えば、パケットが送信者から１人又は複数の受信者へネットワークを通過するために取る必要がある特定経路（又は複数の経路）に依存させる。この態様は、いわゆるトラフィックインジェクション攻撃を不可能にする利点を有する。即ち、この態様は、現在の知られた攻撃が事実上不可能になるようなレベルまで、パケット経路上の攻撃者のコストを上昇させる。従って、この態様は、オフパス攻撃をほとんど不可能にする利点を有する。

別の利点として、転送識別子をパケット処理コンテキストの詳細に依存させる態様は、経路上のサービスを容易に実現させる利点を有する。処理状態を把握しない単一のスイッチング構造の内部で、パケットは、どこから来たかに依存して異なるように自動転送される。このことは、パケットがサービスへ通過することを可能にし、ループ又は他の悪影響を生じることなく、同じスイッチを何回も通過することを可能にする。

本発明は、数十又は数百ビットの非常に小さい転送表を有するとともに、パケット、時間、及び経路に依存した転送判定を安全な方途で行い得るパケット転送ノードの構築を可能にする。パケット内の転送情報の量は合理的に小さく、パケットの処理判定は比較的に単純であり、対称暗号関数を用いるときの単一ラウンドと同程度である。１）非常に小さい転送表、２）パケットごとに転送判定を差別化し得ること、３）合理的に小さい制御情報量をパケット内で搬送するだけであること、４）合理的に簡単な転送判定を有すること、及び５）改ざんから安全であることの利点を同時に有する転送方法は、発明者らが知る限り、この提示が最初である。

本発明は、パケットが、少数の制御ビットをパケットヘッダ内で安全に搬送することを可能にする。これらの制御ビットは、転送ノードでの優先的な処置をパケットに与える。安全であることは、送信者が自分の意思でビットを制御し得ないことを意味する。というのは、ビットの変更は、パケット内に置かれる転送識別子の変更を必要とするからである。

本発明は、これまで識別子がネットワークのリンクに関連する実施形態を参照して説明されている。しかしながら、本発明はこれに限定されない。例えば、識別子は、ネットワークリンクではなくネットワークノードを識別してもよい。代替として、識別子は、ネットワークノードのペアを識別してもよく（例えば、リンクが多数のノード間で共有されるネットワークの場合）、ノードの内部で実施されるサービス、例えばキャッシングを識別してもよく（実施後、パケットは、あたかもノードに到着したばかりのように、ルーティング判定に再び服従しても、服従しなくてもよい）、パケットを転送する他の手段、例えばネットワーク・アドレス・プレフィックス若しくは管理定義域を識別してもよく、又はネットワークリンクの集合を識別してもよい。更なる代替として、識別子は、集団及び指名形態の種々のレベル、例えばネットワーク定義域名又はネットワーク・アドレス・プレフィックスに関連してもよい（及び、それらから導き出されてもよい）。他の適切な識別子は、サービス、例えば中間ボックスサービス（ファイアウォール、プロキシ）、又は一層高いレベルのアプリケーションアイデンティティ（ＳＩＰアプリケーションサーバ、コンテンツ配布ノードなど）を参照し得る。

これまで、本発明は、ルーティング情報がｉＢＦ又は集合メンバーシップの他の簡潔表現としてパケットヘッダ内へ符号化される実施形態を参照して説明された。しかしながら、本発明はこれに限定されず、本発明によって取得された識別子は、原理的にパケットヘッダ内に直接含められてもよい。

略語
ｉＢＦ パケット内ブルームフィルタ
ＢＦ ブルームフィルタ
ＩＤ 識別子
リンクＩＤ リンク識別子
ＲＩＤ ランデブＩＤ
定義
ｓｅｅｄ ｉＢＦ発行者と処理エンティティとの間の共有シークレット
Ｋ 鍵Ｋ、例えば、Ｋ＝ｆ（ｓｅｅｄ，ｔ）
Ｉ 処理されるパケットの予測可能部分、例えば、
（ＩＰ＿ｓｒｃ，ＩＰ＿ｄｓｔ，ｐｏｒｔ＿ｓｒｃ，ｐｏｒｔ＿ｄｓｔ，ｐｒｏｔｏｃｏｌ＿ｉｄ）
Ｃ パケット処理コンテキストの予測可能特性の集合、
例えば、パケットが取ろうとしている経路に沿った入力及び出力ポート索引
Ｆ 入力として値Ｋ、Ｉ、及びＣを取り、出力Ｏとしてｋ個のビット位置を与える一方向性関数。ｋ個のビット位置は、一致を与えるためには、ｉＢＦ内で１でなければならない。
Ｏ 関数Ｆからの出力。この出力は、ｉＢＦ内で１であることをチェックされるｋ個のビットを提供する。

Claims (16)

1. パケットルーティング情報を提供するネットワークノードであって、
   パケットルーティング情報を集合メンバーシップの簡潔表現へ符号化する手段を備え、
   前記集合メンバーシップの簡潔表現は、パケットヘッダの中へ含められ、
   前記ノードは、少なくとも１つのパケット特定、フロー特定、又は処理コンテキスト特定パラメータを含む入力パラメータを使用して、集合メンバーシップの非静的簡潔表現として、前記集合メンバーシップの簡潔表現を計算し、よって集合メンバーシップのパケット特定、フロー特定、又は処理コンテキスト特定簡潔表現を計算するように適応されるか、又は
   前記ノードは、転送ノードにおける前記パケットの前記処理コンテキストからの少なくとも１つの予測可能パラメータを含む入力パラメータを使用して、前記集合メンバーシップの簡潔表現を計算し、よって少なくとも１つの予測可能パラメータに依存する集合メンバーシップの簡潔表現を計算するように適応されているネットワークノード。
2. 前記パケットルーティング情報を複数の非静的識別子として表現し、前記非静的識別子を前記集合メンバーシップの簡潔表現へ符号化することによって、前記パケットルーティング情報を符号化するように適応された、請求項１に記載のネットワークノード。
3. 時間依存性である集合メンバーシップの簡潔表現を計算するように適応された、請求項１又は２に記載のネットワークノード。
4. 転送ノードにおけるパケット処理コンテキストからの少なくとも１つの予測可能パラメータを含む入力パラメータを使用して、前記集合メンバーシップの簡潔表現を計算するように適応された、請求項１乃至３のいずれか一項に記載のネットワークノード。
5. パケットを受信する手段と、
   少なくとも１つのパケット特定、フロー特定、又は処理コンテキスト特定パラメータを使用して、１つ又は複数の非静的識別子を計算し、よって１つ又は複数のパケット特定、フロー特定、又は処理コンテキスト特定識別子を計算し、各識別子が潜在的ルーティング判定を表すようにする手段と、
   少なくとも１つの計算された識別子について、前記計算された識別子と、集合メンバーシップのパケット特定、フロー特定、又は処理コンテキスト特定簡潔表現として前記パケットのヘッダの中に格納されたルーティング情報とを比較し、前記潜在的ルーティング判定が行われるべきかどうかを決定する手段と、
   前記決定に基づき前記パケットを操作する手段と
   を備えるネットワークノード。
6. 前記識別子を時間依存識別子として計算するように適応された、請求項５に記載のネットワークノード。
7. 前記識別子を計算するとき前記パケットの前記ヘッダからの１つ又は複数のビットを使用するように適応された、請求項５又は請求項６に記載のネットワークノード。
8. 前記パケットの前記ヘッダからの前記１つ又は複数のビットからパケット優先度を決定し、前記決定されたパケット優先度に従って前記パケットを操作するように更に適応された、請求項５乃至７のいずれか一項に記載のネットワークノード。
9. 前記識別子を計算するとき前記ネットワークノードにおける前記パケットの前記処理コンテキストからの少なくとも１つの予測可能パラメータを使用するように適応された、請求項５乃至８のいずれか一項に記載のネットワークノード。
10. 前記計算された識別子の少なくとも１つは、前記パケットが前記ノードから送信される１つ又は複数のリンク、及び／又は前記パケットが送信される１つ又は複数のノードを識別し、
    前記ノードは、前記決定されたリンクに沿って及び／又は前記決定された他のノードへ前記パケットを転送することによって前記パケットを操作するように適応された、請求項５乃至９のいずれか一項に記載のネットワークノード。
11. 前記集合メンバーシップの簡潔表現はブルームフィルタである、請求項１乃至１０のいずれか一項に記載のネットワークノード。
12. パケットルーティング情報を提供する方法であって、
    パケットルーティング情報を集合メンバーシップの非静的簡潔表現へ符号化するステップと、
    集合メンバーシップの前記簡潔表現をパケットのヘッダの中に置くステップと
    を含み、
    集合メンバーシップの前記簡潔表現を計算するための前記入力パラメータが、少なくとも１つのパケット特定、フロー特定、又は処理コンテキスト特定のパラメータを含み、それによって前記方法が、集合メンバーシップのパケット特定、フロー特定、又は処理コンテキスト特定簡潔表現を計算することを含む、方法。
13. 前記パケットルーティング情報を符号化するステップは、前記パケットルーティング情報を複数の非静的識別子として表現するステップと、
    該非静的識別子を前記集合メンバーシップの前記簡潔表現へ符号化するステップとを含み、及び／又は、前記集合メンバーシップの簡潔表現を生成するための前記入力パラメータは、パケット識別子、フロー識別子、パケット・ペイロード・ダイジェスト、又は発行識別子のうちの１つを含む、請求項１２に記載の方法。
14. ネットワークを介してパケットをルーティングする方法であって、
    ネットワークノードでパケットを受信するステップと、
    少なくとも１つのパケット特定、フロー特定、又は処理コンテキスト特定のパラメータを使用して、１つ又は複数の非静的識別子を計算し、よって１つ又は複数のパケット特定、フロー特定、又は処理コンテキスト特定識別子を計算するステップであって、各識別子が潜在的ルーティング判定を表す、ステップと、
    少なくとも１つの計算された識別子について、前記潜在的ルーティング判定が行われるべきかどうかを決定するために、前記計算された識別子と、集合メンバーシップのパケット特定、フロー特定、又は処理コンテキスト特定識別子として前記パケットの前記ヘッダの中に格納されたルーティング情報とを比較するステップと、
    前記決定に基づき前記パケットを操作するステップとを含む方法。
15. 前記１つ又は複数の識別子を計算するステップは、前記パケットが前記ノードから送信される１つ又は複数のリンク、及び／又は前記パケットが送信される１つ又は複数のノードを識別する少なくとも１つの識別子を計算するステップを含み、
    前記パケットを操作するステップは、前記決定されたリンクに沿って及び／又は前記決定された他のノードへ前記パケットを転送するステップを含む、請求項１４に記載の方法。
16. 実行されたときに、請求項１２乃至１５のいずれか一項に記載の方法をプロセッサに実行させるコンピュータプログラム。

Images