JP2010520686A - モバイルｉｐホームエージェントのためのループ検知方法 - Google Patents

Abstract

【課題】本発明は、既存のハードウェアのいずれも修正する必要なく、ループを検知することができるループ検知方法などを提供する。
【解決手段】第１のノードがデータパケットを送信する際には、送信対象のデータパケットの少なくとも２個のヘッダフィールド内にある第１のノードの識別子をコード化し、第１のノードがデータパケットを受信する際には、データパケットの少なくとも２個のヘッダフィールドを分析し、データパケットの少なくとも２個のヘッダフィールドの分析に基づいて、データパケットが第１のノード自体によって送信されたか否かを判定することによって、ループが存在するか否かを決定する。
【選択図】図５

Description

[技術分野]
通信システムは、インターネットプロトコル（ＩＰ）ベースのネットワークへとますます進化している。通信システムは典型的には、互いに接続された多くのネットワークから成り、ネットワーク内では、音声及びデータが、一端末から別の端末へばらばらにパケットで送られる。ＩＰパケットはルータによって、接続のない態様であて先へとルーティングされる。そのため、パケットはＩＰヘッダ及びペイロード情報を含み、ヘッダはとりわけ、送信元（ソース）及びあて先のＩＰアドレスを含む。

ＩＰネットワークは、拡張性を理由に、階層的なアドレス指定スキームを用いる。それゆえ、ＩＰアドレスは対応する端末を識別するだけでなく、付加的に該端末についての位置情報を含む。ルーティングプロトコルによって提供された付加的な情報によって、ネットワーク内のルータは、特定のあて先に向かう次のルータを識別することができる。

最も一般的に用いられるトンネリング機構の一つが、ＩＰ（レイヤ３）−ｉｎ−ＩＰ（レイヤ３）カプセル化であり、これは、ＩＰデータグラムを別のＩＰヘッダでカプセル化する処理のことを言い、例えばＭｏｂｉｌｅ ＩＰ用に用いられうる。モバイルＩＰｖ６は、ＭＩＰｖ６とも表され（非特許文献を参照）、モバイルノードがサブネット間を、高位レイヤ及びアプリケーションにトランスペアレントな態様で、すなわち、高位レイヤの接続を断つことなく、移動することを可能にするＩＰベースのモビリティプロトコルである。言い換えれば、モバイルノードはＩＰｖ６インターネットネットワーク内を動き回っている間は、到達可能のままである。

通常、端末の電源が入ると、端末は、アクセスネットワークのＩＰアドレスプリフィックスに基づくＩＰアドレスを構成する。端末が移動体、いわゆるモバイルノード（ＭＮ）であり、異なるＩＰプリフィックスアドレスを持ったサブネット間を移動する場合、端末は、階層的なアドレス指定スキームを理由に、自己のＩＰアドレスを位相的に正しいアドレスへと変更しなければならない。しかしながら、ＴＣＰ接続といった高位レイヤの接続は、通信ノードのＩＰアドレス（及びポート）で定義されるので、ノードの一つが例えば移動を理由に自己のＩＰアドレスを変更する場合、アクティブＩＰセッションへの接続が切れる。前記課題に対処する一つの考えられうるプロトコルはＭＩＰｖ６プロトコルである。

ＭＩＰｖ６の主要な原理は、モバイルノードが、インターネット内の自己の位相的な位置にかかわらず、常に自己のホームアドレス（ＨｏＡ）によって識別され、一方、モバイルノードの気付アドレス（ＣｏＡ）はモバイルノードの現在の位相的な位置についての情報を提供する。

より詳細には、モバイルノードは構成された２個のＩＰアドレス、気付アドレス及びホームアドレスを有する。モバイルノードの高位レイヤは、通信パートナー（あて先端末）との通信のためにホームアドレスを用い、該通信パートナーは以降主にコレスポンデントノード（ＣＮ）と称する。このアドレスは変化せず、モバイルノードの識別という目的を担う。位相的には、ホームアドレスはモバイルノードのホームネットワーク（ＨＮ）に属する。対照的に、気付アドレスは、サブネット変化に帰着するあらゆる移動で変化して、ルーティングの下部構造のためのロケータとして用いられる。気付アドレスは位相的には、モバイルノードが現在訪問中のネットワークに属する。ホームリンク上に位置する一連のホームエージェント（ＨＡ）のうち１個のＨＡは、モバイルノードのホームアドレスに対するモバイルノードの気付アドレスのマッピングを保持するとともに、モバイルノードへのトラフィックの向きをＨＡの現在の位置へと変える。１個のホームエージェントではなく一連のホームエージェントを配備する理由は、例えば冗長性やロードバランシングのためである。

モバイルＩＰｖ６は現在、２つの動作のモードを定義し、そのうち一つは双方向性トンネリングである（図１）。もう一方のモードはルート最適化モードであり（図２）、後に詳述する。双方向トンネリングを用いる際に、コレスポンデントノード１０１によって送られ、モバイルノード１０２のホームアドレスあてのデータパケットは、ホームネットワーク１１０内のホームエージェント１１１によって傍受される。傍受されるそれぞれのデータパケットはＭＮ１０２の気付アドレスへネットーク上に再送される必要があるので、ＩＰ−ｉｎ−ＩＰカプセル化が必要とされる。したがって、傍受されたそれぞれのデータパケットは、ＭＮ１０２のＣｏＡへ宛てられてＭＮ１０２へトンネリングされた新しいＩＰデータパケット内に、ペイロードとして含められており、該ＭＮ１０２は、外部ネットワーク１２０に位置している。対応するトンネルの始点は、カプセル化を行うホームエージェント１１１であり、終点はモバイルノード１０２である。外部ネットワーク１２０内のローカルエージェントが、モバイルノードに代わってメッセージを受信し、外側のＩＰヘッダを取り外し、カプセル化を解除されたデータパケットをモバイルノード（不図示）へと配信することも可能である。

モバイルノード１０２によって送られたデータパケットは、ホームエージェント１１１へとリバーストンネリングされ、該ホームエージェント１１１はパケットのカプセル化解除を行い、パケットをコレスポンデントノード１０１へと送信する。リバース トンネリングとは、パケットがモバイルノードによってホームエージェントへと「フォワード」トンネリングとは「逆の」態様でトンネリングされることを意味する。

ＭＩＰｖ６におけるこの動作に関しては、ホームエージェント１１１のみにモバイルノード１０２の気付アドレスが通知される。したがって、モバイルノードは、バインディングアップデート（ＢＵ）メッセージをホームエージェントへと送信する。これらのメッセージは、都合よく、ＩＰｓｅｃセキュリティ アソシエーション（バインディング）上を送られ、認証され、完全性が保護される。

図３は、ＣＮ１０１とＭＮ１０２のホームエージェント１１１を介したＭＮ１０２との間の例示的なデータパケット交換の図であり、通信中のパケットフォーマットが詳細に図示されている。ＣＮとＭＮの間のすべての通信はＭＮのＨＡ１１１を介して行われる、すなわち、ルート最適化はこれまで実行されていない。したがって、ＣＮからＭＮへ送られたデータパケットのＩＰヘッダは、あて先アドレスとしてＭＮのホームアドレスを、ソースアドレスとしてＣＮのＩＰアドレスを含む。パケットのあて先アドレスがＭＮのホームアドレスであることによって、データパケットはホームネットワークへ、そしてＭＮのホームエージェントへルーティングされる。

上記に説明したとおり、ＨＡは、データパケットを受け取ると、ＭＩＰｖ６手順に基づいてＩＰ−ｉｎ−ＩＰカプセル化を適用し、カプセル化されたパケットをＭＮへ送る。言い換えればＨＡは、ＩＰ−ｉｎ−ＩＰカプセル化を適用することによって、受け取ったデータパケットをＭＮへトンネリングする。より具体的にはＨＡは、ソースアドレスとして自己のアドレスと、付加的なヘッダのあて先アドレスとしてＭＮの気付アドレスとを含む別のＩＰヘッダをパケットに付加する。図３から明らかなように、これによってパケットサイズをさらに４０バイト拡張させる。

同様に、ＭＮによって戻されたデータパケットは、２個のＩＰヘッダでカプセル化される。外側のヘッダは、ＨＡへのデータパケットのトンネリングに関し、したがって、あて先アドレスとしてＨＡのアドレスと、ソースアドレスとしてＭＮの気付アドレスとを含む。内側のＩＰヘッダは、あて先としてＣＮのアドレスと、ソースアドレスとしてＭＮのホームアドレスとを含む。

つまり、モバイルＩＰｖ６は下記のように機能する。モバイルノード（ＭＮ）は、２個のアドレス−恒久的なホームアドレス（ＨｏＡ）と、モバイルノードが訪問しているネットワークと関連付けられた気付アドレス（ＣｏＡ）とを持ちうる。ホームエージェント（ＨＡ）は、恒久アドレスがホームエージェントのネットワーク内にあるモバイルノードについての情報を保存する。

モバイルノードと通信することを所望するノードは、モバイルノードのホームアドレスを用いて、パケットを送信する。これらパケットはホームエージェントによって傍受され、ホームエージェントはテーブルを用いて、新しいＩＰヘッダを付けてモバイルノードの気付アドレスへパケットをトンネリングし、オリジナルのＩＰヘッダを保持する。パケットは、トンネルの終点で、付加されたＩＰヘッダを取り除くべくカプセル解除され、モバイルノードへ配送される。

上記に述べたとおり、モバイルノードは、異なる理由から複数のホームエージェントに登録することができる。モバイルノードが複数のホームエージェントに登録される場合には、モバイルノードは複数のホームアドレスを持ち、ホームアドレスのそれぞれに対して気付アドレスが指定される。このことは、ループが形成されるようにバインディングを構築するよう、悪意あるホストによって用いられうる。図４に例が示されており、ここでは、３個のホームエージェントから成るループが存在する。モバイルノードに向けられたパケットは、ループ内から抜け出せなくなり、ネットワーク内に高い負荷を形成しうる。このことはサービス妨害攻撃に用いられうる。暗号化されたパケットである可能性もあるため、ループ検知は些細なものではない。

上記に説明したとおり、カプセル化は、新しいヘッダをオリジナルのパケットの先頭に追加するプロセスである。カプセル化では、トンネルヘッダのソースフィールドが、トンネルの入口点ノードのアドレスに設定され、あて先フィールドはトンネル出口点のＩＰｖ６アドレスが付いている。その後、カプセル化に起因するトンネルパケットはトンネル出口点ノードへ送信される。

上記に記載したホームエージェントによる転送は、カプセル化を利用している。

入れ子ＩＰｖ６カプセル化はトンネルパケットのカプセル化である。これは、ＩＰｖ６トンネルのホップがトンネルである場合に発生する。トンネルを含む該トンネルは、外トンネルと呼ばれる。外トンネル内に含まれるトンネルは、内トンネルと呼ばれる。内トンネル及びその外トンネルは入れ子トンネルである。

ＲＦＣ２４７３「ＩＰｖ６仕様におけるジェネリック パケット トンネリング」において、入れ子カプセル化を制限するための方法が記述されている。入れ子カプセル化は、カプセル化されたパケットのカプセル化である。

それぞれのカプセル化は０でないバイト数をパケットに付加するので、入れ子 カプセル化は必然的に最大のＩＰパケットサイズに制限される。しかしながら、この制限は非常に大きいので効果的でない。

ＲＦＣ２４７３は、「トンネルカプセル化制限」オプションを用いて過剰な入れ子カプセル化を制限する機構を提案しており、該オプションは、カプセル化ＩＰｖ６ヘッダを伴うＩＰｖ６あて先オプション拡張ヘッダの中で運ばれる。図９及び１０を参照。

ＲＦＣ２４７３より抜粋：「トンネルカプセル化制限オプションは、いくつの付加的なカプセル化レベルをパケットの先頭に追加することが許容されるか、または、言い換えれば、パケットはさらにいくつのレベルの入れ子を行うことができるかを、当該オプション自体が含まれているカプセル化の数を数えることなく、規定している。例えば、制限値０を含むトンネルカプセル化制限は、そのオプションを運ぶパケットが、現在のトンネルから出るまでは別のトンネルに入ることはできないことを意味している。

ホームエージェントどうしの間のループの場合には、いわゆる「回帰的な入れ子カプセル化」が発生し、ＲＦＣ２４７３における方法はパケットがループになることを永久的に防止するが、パケットがループに入ることは防止しない。このため、この方法はループを取り除かない。

トンネルカプセル化制限値は、入口点ノードが、当該ノードで発生したトンネルパケットのカプセル化の数を制限するよう構成されているか否かを示すことができる。ＩＰｖ６トンネルカプセル化制限は、当該入口点ノードにおいてカプセル化を行うパケットに対して許容される追加的なカプセル化の最大数である。推奨されるデフォルト値は４である。入れ子カプセル化の数を制限するよう構成される入口点ノードは、カプセル化を行うオリジナルのパケットの先頭に、トンネルカプセル化制限オプションを含むあて先オプション拡張ヘッダを追加する。上記を参照。

トンネルカプセル化制限オプションがトンネルに入るパケット内に見出され、その制限値が０でない場合、追加的なトンネルカプセル化制限オプションが、この入口点で付加されているカプセル化ヘッダの一部として含まれなければならない。カプセル化オプションにおける制限値は、カプセル化されているパケット内に見出される制限値よりも低い値に設定される。

モバイルＩＰにおいて、ホームと離れているモバイルノードは、ホームエージェントに、モバイルのノードホームアドレスをその現在の気付アドレスとバインディングさせるバインディングを有している。複数のホームエージェントに登録されているモバイルノードは、ループが存在するよう、バインディングを設定することが可能である。こうして、モバイルノードへ向けられたパケットは、決してモバイルノードに到達しないであろうし、ホームエージェントどうしの間に重いトラフィック負荷を形成しうる。これは、サービス妨害攻撃に用いられうる。暗号化されたパケットである可能性もあるため、ループ検知は些細なことではない。

目標は、ループを遮断するために必要な措置がホームエージェントによって取ることができるように、カプセル化ループを検知することである。困難なのは、ループ内のそれぞれのホームエージェントにおいて、パケットが新しいパケットヘッダを得て、（カプセル化の一部として）暗号化される可能性があることである。したがって、受信側のホームエージェントは、他に何も手段がなければ、自らの場所でこのパケットが発生したことを判別できない。

記述したとおり、ホームエージェントは、ループの間に、パケットを暗号化してもよい。ＭＮに向けられたパケットがあるので、ＭＮのみがコンテンツを復号することができる。しかしループの場合には、パケットは決してＭＮに到達せず、したがって、パケットを復号することは（一般的に）不可能である。

ループ内のすべてのホームエージェントの実装に対する変更を可能にするループ検知の解決法は、些細であろうことに留意するべきである。ホームエージェントは、ループの存在について互いに通信することができる。

目的は、ループ内の未変更のホームエージェントと一体となって、解決法が動作することである。本発明を用いるには、ループ内の少なくとも１個のホームエージェントが必要とされる。

Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、"Mobility Support in IPv6"、ＩＥＴＦ ＲＦＣ ３７７５、２００４年６月

本発明は上記の状況に鑑みて行われ、既存のハードウェアのいずれも修正する必要なく、ループを検知することをその目的とする。

本目的は、独立請求項中に請求された発明によって解決される。本発明の好適な実施の形態は従属請求項によって定義される。

本目的を達成するために、本発明は、複数のノードを備えるネットワーク内のトンネルを活用するデータパケット通信におけるループ検知のための方法及びコンピュータ可読媒体を提供する。前記方法は、第１のノードがデータパケットを送信する際には、送信対象のデータパケットの少なくとも２個のヘッダフィールド内にある第１のノードの識別子をコード化するとともに、第１のノードがデータパケットを受信する際には、データパケットの少なくとも前記２個のヘッダフィールドを分析するステップと、データパケットの少なくとも前記２個のヘッダフィールドの分析に基づいて、前記データパケットが第１のノード自体によって送信されたか否かを判定することによって、ループが存在するか否かを決定するステップとを含む。

有利な実施の形態によると、第１のノードはホームエージェント又はルータである。

本発明の別の実施の形態によると、少なくとも前記２個のヘッダフィールドは、拡張ＩＰｖ６ヘッダのトンネルカプセル化制限フィールドである。

本発明のさらなる実施の形態では、前記分析するステップが、データパケットの少なくとも前記２個のヘッダフィールドを第１のノードの前記コード化された識別子と比較することを含む。少なくとも前記２個のヘッダフィールドが第１のノードから発生している場合は、ループが存在すると決定され、そうでない場合は、ループが存在しないと決定される。

本発明の別の実施の形態は、データパケットをさらにカプセル化するネットワーク内のそれぞれのノード内において、トンネルカプセル化制限フィールド内の各バイトの値を１ずつ減少させるステップを含む。

別の実施の形態によると、前記比較するステップが、第１のノードの前記コード化された識別子の個々のバイトから、トンネルカプセル化制限の個々のバイトを減算し、結果として生じるバイトが同一である場合、ループが存在すると決定することを含む。

本発明の別の実施の形態では、データパケットがバインディングリフレッシュ通知パケットである。

本発明の別の有利な実施の形態は、ループが存在する旨の決定後、バインディングリフレッシュ通知パケットの送信から所定時間以内に、バインディングアップデートを受信し、ループが存在しないと決定するステップをさらに含む。

さらなる特徴及び利点が、下記、そして添付される図面に示されるような本発明の様々な実施の形態のより特別な説明によって明らかになる。
トンネルを含むＭＩＰｖ６ネットワークのモデルを例示する図。 ＣＮとＭＮとの間のルーティングを示す図。 ＭＩＰｖ６において用いられるヘッダを示す図。 複数のホームエージェントに登録されているモバイルのために、ループが形成できることを示す図。 ループ検知パケットがホームエージェントで発生し、最終的にはこのホームエージェントによって受信される主要概念を示す図。 受信装置が検知されうる時に、ループ検知パケットが別のホームエージェントでどのように発生するかの例を示す図。 ループが存在していないにもかかわらず、ループを模倣しようと試みる攻撃者を示す図。 ループ検知を無効化しようと試みる攻撃者を示す図。 拡張されたモバイルＩＰｖ６ヘッダを例示する図。 トンネルカプセル化制限フィールドのフォーマットを示す図。

下記の段落は、本発明の様々な実施の形態を説明し、さらに代替的な構成を明らかにする。

例示的な目的のみのために、大部分の実施の形態は、ＩＰｖ６システムと関連して概略が説明され、後続において用いられる用語は、主としてＩＰｖ６用語に関連している。しかしながら、ＩＰｖ６アーキテクチャに関して用いられる用語及び実施の形態の説明は、本発明の原理及び概念をこのようなシステムに制限することを意図していない。

また、上記背景技術にて提供される詳細な説明は、単に、下記に記載されるほとんどＩＰｖ６に特有の例示的な実施の形態をより良く理解するよう意図されており、本発明を特定の実施を説明するように制限するものであると理解されるべきではない。

本発明はホームエージェント間のループ検知を対象としているものの、その主要概念は他のループを検知するのにも同様に用いられうる。

主要概念は、ＲＦＣ２４７３に定義される既存の技術を活用することである。当該文書は、当該パケットに対して許容されるカプセル化の数を制限するのに用いられうる「トンネルカプセル化制限」フィールドを定義している。制限（８ビットを含むフィールド）は、トンネルのそれぞれの入口で１ずつ減少する。本発明の主要概念は、１個のパケット内でこれらのフィールドのうち複数を用いることである。送信者のＩＤをこれらのフィールドへコード化することによって、元の送信者は、当該特定のパケットが実際に自らによって送信されたことを検知することができ、このことは、ループを示唆する。

「トンネルカプセル化制限」はＩＰｖ６拡張ヘッダの一部であり、標準的なＩＰｖ６適合ルータ（又はホームエージェント）は、パケット内のそれぞれの拡張ヘッダに対して、当該制限を１ずつ減少させる。したがって、元の送信者のＩＤが４バイトを含む場合、それぞれ１バイトのカプセル化制限が付いた４個の拡張ヘッダは、ループ検知パケットヘッダ内に含まれる。

こうして、すべてのコード化された送信者ＩＤのバイトは、元の送信者によって受信された後、ループの長さに対応する値だけ減少する。送信者ＩＤとして１バイトのみを用いることは、ループを検知するには十分でないことに留意されたい。その理由は、送信者は、自己のＩＤと、他の可能なホームエージェントのＩＤとの間の区別ができないからである。したがって、送信者ＩＤには少なくとも２バイトが必要であり、付加的なバイトは他のホームエージェントのＩＤとのコリジョン（衝突）の可能性を低下させる。

図４では、３個のホームエージェント４０２、４０４、４０６に登録されているＭＮ１０２が示されている。それぞれのホームエージェントにおいて、ＭＮ１０２は、ＭＮのホームアドレスからその気付アドレスへのバインディングを、当該バインディングがループを形成するように設定した。ＭＮ１０２に向けられた任意のパケットはループ内で捕捉される。この状況は、ホームエージェント間のリンクに対してトラフィックの集中を生成する目的で、悪意あるホストによって形成されうる。

この状況は明らかに所望されておらず、措置を取ることができるよう検知されるべきである。本発明の主要概念が図５に図示されている。

この図において、ＭＮ１０２に向けられたパケットに対して、ホームエージェントにループが存在する。図において、ＨＡ１ ４０２はループを疑い、ループ検知手順を開始すると仮定する。この場合にはＨＡ１ ４０２は、４個のトンネルカプセル化制限オプションを備えた「ループ検知パケット」を生成することによって、ループ検知手順を行う。ＨＡ１ ４０２は、自己のＩＤ（１３、５４、３０、８）をパケットへ記述し、ＨＡ１ ４０２に登録されたＭＮ１０２の気付アドレスへ送信する。

ＨＡ２ ４０４は、標準的な適合ＩＰｖ６ホームエージェントであってもよく、ＭＮ１０２に対する他の任意のパケットと同様、このパケットを処理する。ＭＮ１０２は、ＨＡ２ ４０４に現在いないので、パケットをカプセル化し、それをＨＡ２ ４０４に登録された気付アドレスへと送信する。これを行うことによって、ＭＮ１０２はオリジナルのパケットのトンネルカプセル化制限フィールドを減少させる。トンネルカプセル化制限のヘッダ・オプションは、オリジナルのパケットからコピーされ、当該制限は減らされ、新しいパケット内にオプションヘッダとして入れられる。

この結果、ＨＡ１ ４０２の元のＩＤは、依然としてパケット内部にあり、暗号化されない。個々のバイトは１ずつのみ減少する。ＨＡ３ ４０６はＨＡ２ ４０４と全く同じことを行い、その結果、パケットがＨＡ１ ４０２に到達する。受信後、ＨＡ１ ４０２は受信した値を自己のＩＤと比較し、すべての数が等しい場合は、ループが示唆される。ループ検知の主要概念は、受信した数をホームエージェントの自己のＩＤと比較することである。これは、両方の数字のそれぞれ一部（バイト）を減算することによって行われる。同一の効果に到達するには、他の演算も可能である。

減算の次には、ループを検知するのに他の数学的な手順が可能である。下記には、このような方法の一つを記述する。ホームエージェントＩＤが、４個の数字ａ１〜ａ４から成り、パケット内における受信した数がｒ１〜ｒ４であると仮定する。

最初のステップは、ホームエージェントＩＤのそれぞれの数字の差を計算することである。すなわち、ｍ１＝ａ２−ａ１、ｍ２＝ａ３−ａ２、ｍ３＝ａ４−ａ３である。

次に、受信した数とＩＤとが合計される。ｓ１＝ａ１＋ｒ１、ｓ２＝ａ２＋ｒ２、ｓ３＝ａ３＋ｒ３、ｓ４＝ａ４＋ｒ４である。

再び、Ｓのそれぞれの数の差が計算される。ｎ１＝ｓ２−ｓ１、ｎ２＝ｓ３−ｓ２、ｎ３＝ｓ４−ｓ３。

ここで、下記の場合にはループが存在するとともに、ループが存在するのは下記の場合のみである：
ｎ１／ｍ１＝２
ｎ２／ｍ２＝２
ｎ３／ｍ３＝２

こうして、３つの除算すべてにおいて除算の結果がちょうど２である場合は、ループが存在し、そうでない場合は、ループは存在しない。

ひとたびループが検知されると、ＨＡは、当該ＭＮに対するバインディングを単に削除してループを遮断することができる。ＭＮに向けられたパケットは廃棄される。標準的なモバイルＩＰタイムアウト機構は、他のホームエージェントにあるバインディングを最終的には削除する。

当該ループ検知方法には、複数の方法を用いてホームエージェントにＩＤを割り当てることができる。簡単な方法は、ＩＤを手入力で割り当てるか、又は無作為に生成することである。別の可能性は、当該数字を、ホームエージェント ＩＰアドレスのようなＨＡを固有に定義する他の数字に基づいて形成することである。

ホームエージェントは、他のホームエージェントがループと関与しうるかを事前にわかっていないことに留意されたい。

したがって、ループ内の別のホームエージェントが全く同じＩＤを用いる可能性がある。しかしながら、「ＩＤコリジョン」の場合の確率は、ＩＤのビット数を増加させることによって、適宜小さくすることができる。

２個のホームエージェントのＩＤが異なる場合であっても、コリジョンは発生しうる。ＩＤ１＝５、５、５、ＩＤ２＝８、８、８である場合を考慮されたい。ループ検知パケットが例えば２、２、２に到達する場合、ＨＡ１は、このパケットは自らの場所で発生したと考える可能性があり、一方、ＨＡ２は全く同じことを考える。

図６は、ＨＡ１ ４０２の代わりにＨＡ２ ４０４がループ検知手順を開始する場合を図示する。ＨＡ２ ４０４が開始したので、ＨＡ２ ４０４は、自己のＩＤが内部にコード化されている（１３、５４、２０、６）ループ検知パケットを生成した。このパケットがＨＡ１ ４０２に到達すると、元の数字はすべて１ずつ減少する。ここで、ＨＡ１ ４０２は、すべての番号をそれぞれ減算することによって、受信した数字を自己のＩＤと比較する。図中に示すように、この減算によって数字１、１、１１、３を生成し、これらは、すべてが等しくなく、したがって、ＨＡ１ ４０２は、このループ検知パケットがＨＡ１ ４０２では発生しなかったことがわかる。

ホームエージェントループは、ホームエージェントに対するサービス妨害攻撃を形成するために、悪意あるホストによって用いられうるので、ループを検知するためのソルーションもまた安全であるべきである。前の段落において説明されたループ検知の主要概念は依然として有効であるが、それを安全にするためには何らかの付加が必要である。

これまで、出願人らはループ検知パケットを厳密に定義しなかった。主要概念としては、どの種類のパケットが実際に用いられるかということも重要でない。しかしながら、攻撃者の可能性を鑑みると、このことは重要になった。これは、攻撃者がループ検知プロセスと介入しうるという事実と関係している。基本的には、解決が必要な２つの問題がある。

ループはないが、攻撃者が、ホームエージェントに対し、ループが１個あると思い込ませる。

ループがあるが、攻撃者が検知を無効にする。

図７は第１の場合のシナリオを示し、ここでは、ＨＡ１ ４０２が、ループ検知パケットをＭＮ １０２へと送信することによってループ検知手順を開始する。しかしながら、ＭＮ１０２に送信されたパケットを聞くことができる攻撃者７０２がいる。この攻撃者７０２が、ＨＡへと戻るループ検知パケットを複製する場合、ＨＡはループを誤って検知しうる。

上記に記載された問題に対するソルーションは、複数の要素から成る。まず最初に、ループ検知に用いられるパケットは、ＲＦＣ ３５５７による「バインディングリフレッシュ通知」である（実際のところこれは、随意的なバインディングリフレッシュ通知を備えたバインディング確認パケットである）。バインディングリフレッシュ通知によって、ホームエージェントは、当該バインディングの寿命が正常に終了するよりも前に、ＭＮに対して強制的にそのバインディングをリフレッシュさせることができる。このメッセージを用いる要点は二つある。第１に、未変更のＭＮがこのメッセージに応答することができ、第２に、当該ＭＮはこの要求に対して安全に応答することができる。

したがって、ホームエージェントの視点から見た完全に安全なループ検知手順は下記のとおりである。

ホームエージェントが、ある特定のＭＮに対するループを疑う場合は、このＭＮに対するバインディングリフレッシュ要求を生成する。ホームエージェントは、自己のＩＤをトンネルカプセル化制限オプションヘッダの形式で含む。

ループ検知パケットが受信され、パケット内の数字がホームエージェントＩＤと合致する場合、これは、ループ又は攻撃者を示唆しうる。これを見出すために、ホームエージェントはタイマーを開始する。この時間内でれば、認証されたバインディングアップデートがＭＮから受信され、この場合、ループはない。そうでない場合はループがある。攻撃者がＭＮへ行くパケットもあるいはＭＮから来るパケットも捨てることはできないと仮定することに留意されたい。

第２のセキュリティの問題は、攻撃者がループを設定しうるが、検知を無効にすることである。この原理が図８に示される。攻撃者７０２がＭＮ１０２になりすまし、ＢＵをホームエージェントへと送信する場合、ホームエージェントはループはないと考えうる。

認証された「バインディングリフレッシュ通知」及び対応する「バインディングアップデート」を使用しているので、この問題はすでに解決されている。攻撃者７０２は、ＭＮのキーを持っている場合のみこのバインディングアップデートを送信でき、したがって、この第２のセキュリティの件は問題であると考えられない。

ループ検知の主要概念は、検知手順に任意のパケット種類を用いうる。すなわち、ループがある場合は、当該パケットはホームエージェントへ戻り、ホームエージェントを点検することができる。しかしながら、上記より明らかなように、セキュリティのため、バインディングリフレッシュ要求の使用は、攻撃者が存在する場合には利点がある。しかし、他のメッセージでもこの目的を達成しうる。重要なのは、ホームエージェントが、ＭＮからの回答が本当にＭＮから来たのであって、何か別の実体から来たのではないことを検証できることである。

さらに、本発明の様々な実施の形態は、処理装置によって又はハードウェア中で直接実行されるソフトウェアモジュールの手段によっても実施されるべきである。また、ソフトウェアモジュールとハードウェア実装の組み合わせも可能でありうる。ソフトウェアモジュールは、任意の種類のコンピュータで読み取り可能な記憶媒体、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに記憶されてもよい。

Claims (10)

1. 複数のノードを備えるネットワーク内のトンネルを活用するデータパケット通信におけるループ検知のための方法であって、
   第１のノードがデータパケットを送信する際には、
   送信対象の前記データパケットの少なくとも２個のヘッダフィールド内にある前記第１のノードの識別子をコード化するステップと、
   前記第１のノードがデータパケットを受信する際には、
   前記データパケットの前記少なくとも２個のヘッダフィールドを分析し、
   前記データパケットの前記少なくとも２個のヘッダフィールドの分析に基づいて、前記データパケットが前記第１のノード自体によって送信されたか否かを判定することによって、ループが存在するか否かを決定するステップとを、
   含むループ検知方法。
2. 前記第１のノードがホームエージェント又はルータである請求項１に記載のループ検知方法。
3. 前記少なくとも２個のヘッダフィールドが、拡張ＩＰｖ６ヘッダのトンネルカプセル化制限フィールドである請求項１又は２に記載のループ検知方法。
4. 前記分析するステップは、
   前記データパケットの前記少なくとも２個のヘッダフィールドを前記第１のノードの前記コード化された識別子と比較し、
   前記少なくとも２個のヘッダフィールドが前記第１のノードから発生している場合は、ループが存在すると決定され、
   そうでない場合は、ループが存在しないと決定される請求項１から３のいずれか１つに記載のループ検知方法。
5. 前記データパケットをさらにカプセル化するネットワーク内のそれぞれのノード内において、前記トンネルカプセル化制限フィールド内の各バイトの値を１ずつ減少させるステップをさらに含む請求項３又は４に記載のループ検知方法。
6. 前記比較するステップは、
   前記第１のノードの前記コード化された識別子の個々のバイトから、前記トンネルカプセル化制限の個々のバイトを減算し、
   結果として生じるバイトが同一である場合、ループが存在すると決定する請求項４又は５に記載のループ検知方法。
7. 前記データパケットがバインディングリフレッシュ通知パケットである請求項１から６のいずれか１つに記載のループ検知方法。
8. ループが存在する旨の決定後、
   前記バインディングリフレッシュ通知パケットの送信から所定時間以内に、バインディングアップデートを受信し、
   ループが存在しないと決定する請求項７に記載のループ検知方法。
9. 複数のノードを備えるネットワーク内のトンネルを活用するデータパケット通信において、ループを検知するノードの処理装置によって実行される際の指示を格納するコンピュータ可読媒体であって、
   第１のノードがデータパケットを送信する際には、
   送信対象の前記データパケットの少なくとも２個のヘッダフィールド内にある前記第１のノードの識別子をコード化し、
   前記第１のノードがデータパケットを受信する際には、
   前記データパケットの前記少なくとも２個のヘッダフィールドを分析し、
   前記データパケットの前記少なくとも２個のヘッダフィールドの分析に基づいて、前記データパケットが前記第１のノード自体によって送信されたか否かを判定することによって、ループが存在するか否かを決定するコンピュータ可読媒体。
10. 請求項２から８のいずれか１つに記載の方法のステップを実行することによって、ノードにループを検知させる指示を格納する請求項９に記載のコンピュータ可読媒体。

Images