JP2009516435A

JP2009516435A - 複数鍵暗号化生成アドレスを使ったモバイルネットワークのためのセキュアな経路最適化

Info

Publication number: JP2009516435A
Application number: JP2008540351A
Authority: JP
Inventors: ジェイムズケンフ，; マンヒージョー，
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2005-11-10
Filing date: 2006-11-09
Publication date: 2009-04-16
Also published as: WO2007059419A3; WO2007059419A2; US20070113075A1

Abstract

方法は、モビリティ管理にモバイルインターネットプロトコルバージョン６(モバイルＩＰｖ６)を使用するモバイルルータが、各モバイルネットワークノードがモバイルＩＰｖ６機能を果たさない場合でさえも、各モバイルネットワークノードに代わって通信相手ノードに直接対応付け更新メッセージをセキュアに送ることによって経路制御を最適化することを可能にする。各モバイルネットワークノードごとのネットワークアドレスが、モバイルネットワークノードとモバイルルータ両方の公開鍵から生成されるため、モバイルルータに、モバイルネットワークノードに代わって生成アドレスを使用する権限が与えられる。モバイルルータは、その接続点を変更する場合、各モバイルネットワークノードの通信相手ノードに署名付きの対応付け更新メッセージを送る。通信相手ノードは、対応付け更新メッセージと正しい公開鍵を検証すると、ホームエージェントを介さずに、モバイルネットワークノードとやりとりすることができる。したがって、セキュアなプロキシ対応付け更新メッセージをモバイルルータから送ることができる。
【選択図】図１

Description

関連技術の考察

移動ネットワーク内のノードとモバイルネットワーク外のノードの間の経路を最適化するには、通信相手ノードにモバイルネットワーク内のネットワークアドレス所有者の動きについて知らせるのに、信頼性の高い、権限を有するプロキシネットワークノードを使用できることが求められる。

「AddressMechanisms in Internet Protocol」という名称の米国特許出願公開第２００２／０１３３６０７号明細書（「Ｎｉｋａｎｄｅｒ出願」）には、一方向符号化関数を使って、ホストに特有の構成要素からのインターネットプロトコル（ＩＰ）アドレスを生成することが開示されている。その場合、結果として生じるＩＰアドレスを、ホストが請求することができる。Ｎｉｋａｎｄｅｒ出願では、ホストからのメッセージの受信側が、構成要素を使ってＩＰアドレスを再構築し、チェックすることができる。請求側ホストは、認証プロトコル又は公開鍵暗号化プロトコルを使って、メッセージのデータ保全性を確立してもよく、構成要素をＩＰアドレスと結び付ける。

「Methodsand Systems for Unilateral Authentication of Messages」という名称の国特許出願公開第２００２／０１５２３８４号明細書（「Ｓｃｈｅｌｅｓｔ出願」）には、請求側ホストの公開鍵のハッシュ化によってＩＰバージョン６（ＩＰｖ６）アドレスを導出することが開示されている。Ｓｃｈｅｌｅｓｔ出願では、請求側ホストからのメッセージの受信側が、ＩＰｖ６アドレスのハッシュをチェックし、メッセージ内の暗号化署名をチェックしてそのデータ保全性を検証する。ＩＰｖ６アドレスと含まれる署名の両方が検証された場合、受信側は、そのＩＰｖ６アドレスに対するホストの所有権請求を受け入れる。

ＧａｂｒｉｅｌＭｏｎｔｅｎｅｇｒｏ及びＣｌａｕｄｅＣａｓｔｅｌｌｕｃｉａによる、「Crypto-Based Identifiers (CBIDs): Concepts and Applications」（「Ｍｏｎｔｅｎｅｇｒｏ論文」）、ACMTransactions on Information and System Security（２００４年２月）では、ホストのアドレス使用権限の請求を検証するための、暗号化生成識別子の使用が検討されている。

「AddressingMechanisms in Mobile IP」という名称の、米国特許出願公開第２００３／００８４９２９３号明細書、（「Ａｒｋｋｏ出願」）には、所有者ノードが、そのＩＰアドレスの責任を、そのアドレスが生成されるときに第２のノードに委任することが開示されている。Ａｒｋｋｏ出願では、ＩＰアドレスは、Ｎｉｋａｎｄｅｒ出願又はＳｃｈｅｌｅｓｔ出願に開示されている方法を使って暗号化して生成され得る。Ａｒｋｋｏ出願の方法によれば、所有者ノードは、第２のノードから公開／秘密鍵対の公開鍵部分を獲得し、第２のノードの公開鍵の上に所有者ノード自体の秘密鍵で署名することによって権限証明書を作成する。次いで、権限証明書が第２のノードに提供される。次いで、権限証明書は、所有者ノードのＩＰアドレスに関連する任意のメッセージに入れて配布され得る。第２のノードは、権限証明書を含むかかるメッセージに、第２のノードの秘密鍵で署名する。メッセージの受信側は、第２のノードの公開鍵を使ってメッセージを認証し、所有者ノードの公開鍵を使って権限証明書を認証する。ＩＰアドレスの暗号化ハッシュは、所有者ノードのＩＰアドレスに対する権限を検証し、第２のノードの公開鍵は権限証明書を検証し、それによって、第２のノードが、所有者ノードに代わってメッセージを送る権限を確立する。

ＴｕｏｍａｓＡｕｒａによるＩＥＴＦＲＦＣ（Request for Comment）３９７２（２００５年３月）には、近隣探索プロトコル（ＲＦＣ２４６１及びＲＦＣ２４６２）を使って、ＩＰｖ６アドレスを暗号化して生成し、ＩＰｖ６アドレスの権限の請求を保護することが開示されている。ＩＰｖ６アドレスは、所有者ノードの公開鍵の暗号化ハッシュと追加情報の両方を使って生成される。暗号化ハッシュの６４ビットが、ＩＰｖ６アドレスのインターフェース識別子として使用される。

「Methodsand Systems for Unilateral Authentication of Messages」という名称の、米国特許出願公開第２００２／０１５２３８０号明細書（「Ｏ'Ｓｈｅａ出願」）には、ホストの公開鍵（Ｓｃｈｅｌｅｓｔ出願に記載されている方法など）を使って、モバイルＩＰｖ６ホームアドレスと気付アドレスを暗号化して生成することが開示されている。モバイルノードがホームサブネットの外部にあるとき、ホームネットワーク内のモバイルＩＰｖ６ホームエージェントは、ホームアドレス向けのデータパケットを気付アドレスに転送する。モバイルノードは、通信相手ノードが、パケットを、ホームアドレス経由ではなく、気付アドレスに直接アドレス指定して、経路制御性能を改善するよう要求してもよく、このプロセスを「経路最適化のための対応付け更新」という。このように経路制御を最適化するシグナリングは、モバイルノードに新しい気付アドレスを請求する権限が与えられているという証拠を必要とする。この証拠は、ネットワークアドレスとシグナリングパケット上の公開鍵署名の暗号化特性を使って提供され得る。モバイルノードは、対応付け更新シグナリングパケットに、ネットワークアドレスを生成するのに使用される公開鍵に対応する秘密鍵で署名する。シグナリングパケットは、送信元アドレスを、新しい、暗号化して生成された気付アドレスに設定して送られる。また、シグナリングパケットには、暗号化して生成されたホームアドレスとモバイルノードの公開鍵も含まれる。シグナリングパケットを受け取ると、通信相手ノードは、送信元アドレスとホームアドレスが、パケットに含まれる公開鍵から生成され得ることをチェックし、次いで、署名をチェックする。送信元アドレスと公開鍵の両方が検証される場合、通信相手ノードは、そのシグナリングパケットを受け入れる。

ＪａｒｉＡｒｋｋｏ、ＪａｍｅｓＫｅｍｐｆ、ＢｒｉａｎＺｉｌｌ、及びＰｅｋｋａＮｉｋａｎｄｅｒによるＲＦＣ３９７１（２００５年３月）には、（ＲＦＣ２４６１と２４６２に記載されている）ＩＰｖ６近隣探索プロトコルを、ネットワークアドレスのセキュアな広告及び防御と、最後のホップＩＰルータのセキュアな探索のために拡張することが開示されている。ノードは、ＲＦＣ３９７２に記載されているアルゴリズムに従って暗号化生成アドレスを生成し、近隣広告パケットにＲＳＡ署名で署名する。近隣広告パケットは、アドレスの所有権を請求する。この請求は、アドレスの暗号特性によって証明され、パケット上の署名は、パケットに対するデータ起点認証を確立する。よって、受信側ノードは、そのパケットが請求された送信元アドレスから発せられていると信頼することができ、メッセージは、請求側ノードがそのネットワークアドレスを請求する権限を確立する。ＳＥＮＤプロトコルは、さらに、最後のホップルータのセキュアな探索も可能にする。ＲＦＣ３９７２では、最後のホップルータに関する証明書のフォーマットが指定されている。かかる証明書を処理するルータは、ルータ広告メッセージに、それの認証された公開鍵の秘密鍵対応部分で署名する。最後のホップルータを求めるノードは、ルータの証明書と、そのルータから共用のＴｒｕｓｔＲｏｏｔ（信頼されるルート）まで戻る証明書チェーンを獲得する。このノードは、ルータの認証鍵を使って、ルータ広告メッセージ上の署名を検証し、それによって、認証された最後のホップルータを獲得する。

ＪａｒｉＡｒｋｋｏ、ＣｈｒｉｓｔｉａｎＶｏｇｔ、及びＷａｓｓｉｍＨａｄｄａｄによるＩＥＴＦ草案「draft-arkko-mipshop-cga-cba-04」（「Ａｒｋｋｏ草案」）（２００６年６月）には、モバイルＩＰｖ６ノードのセキュアな経路最適化のためにモバイルＩＰｖ６を拡張することが開示されている。Ａｒｋｋｏ草案では、モバイルノードはその通信相手ノードに、伝搬経路を最適化するための対応付け更新メッセージを直接送る。通信相手ノードは、ＲＦＣ３９７２に開示されているように、モバイルノードの公開鍵を使って、モバイルノードの請求アドレス所有権を検証する。加えて、対応付け更新シグナリング負荷を低減することにより、ハンドオフ遅延を低減しようとする試みも行われる。アドレス所有権検証時の宛先変更ベースのフラッド攻撃は、両ノードでパケットの量を制限することによって防止される。

ＶｉｊａｙＤｅｖａｒａｐａｌｌｉ、ＲｙｕｊｉＷａｋｉｋａｗａ、ＡｌｅｘａｎｄｒｕＰｅｔｒｅｓｃｕ、及びＰａｓｃａｌＴｈｕｂｅｒｔによるＲＦＣ３９６３（２００５年１月）には、モバイルネットワークにインターネットへの接続を提供するプロトコルが開示されている。モバイルネットワーク内の各ノード（「モバイルネットワークノード」）に代わって、そのノードがモビリティ機能を備えているか否かを問わず、モバイルＩＰｖ６機能を有するルータ（「モバイルルータ」）が、モバイルネットワークノードとインターネットの間の連続した接続を提供するモビリティサポート機能を実行する。モバイルルータは、モバイルルータとそのホームエージェントの間の双方向トンネルを確立する。モバイルルータは、その接続点を変更するたびに、この双方向トンネルを再確立する。この構成の下では、各モバイルネットワークノードに向けられ、各モバイルネットワークから送られるすべてのパケットが、この双方向トンネルを介してモバイルルータのホームエージェントによって処理される。

上記から分かるように、Ｎｉｋａｎｄｅｒ出願及びＳｃｈｅｌｅｓｔ出願、Ｍｏｎｔｅｎｅｇｒｏ論文、ＲＦＣ３９７２、Ｓｈｅａ出願、並びにＲＦＣ３９７１は、ネットワークアドレスを使用する権限が、単一のホストによって請求される場合のみに関連するものである。加えて、Ａｒｋｋｏ草案は、モバイルＩＰｖ６ノードの経路最適化のみに関連するものである。しかしながら、しばしば、１つ又は複数のホストにアドレスを使用する権限を与えることが、各ノードがモビリティ機能をサポートしているか否かを問わず、必要になり得る。かかる必要の例は、モバイルネットワーク用途や、モバイルネットワークの経路制御最適化で見ることができる。

上記から分かるように、ＲＦＣ３９６３は、すべてのパケットが、モバイルルータとそのホームエージェントの間の双方向トンネルを介して伝搬されるものと規定している。この次善の経路制御方式は、モバイルネットワークノードに代わって通信相手ノードに直接対応付け更新メッセージを送ることのできる、信頼性の高い、権限を有するプロキシモバイルルータが存在する場合には不要である。その場合、通信相手ノードは、新しく獲得されたアドレスを含む対応付け更新メッセージが権限を有するノードから送られていることを検証することができる。しかしながら、モバイルネットワークノードが、その公開鍵だけに結び付けられた暗号化識別子を使ってアドレスを生成する場合には、そのモバイルネットワークノードだけしか、セキュアな対応付け更新メッセージを送ることができない。モバイルルータによるプロキシ対応付け更新メッセージは、セキュリティなしで行われなければならない。

Ａｒｋｋｏ出願には、所有者ノードが、そのアドレスの広告と防御を別の当事者に委任することが開示されているが、Ａｒｋｋｏ出願の解決法は、煩雑である。Ａｒｋｋｏ出願では、所有者ノードの公開鍵と委任先ノードの公開鍵の両方を使用することに加えて、属性証明書も必要とされる。アドレスを生成した後、属性証明書が、所有者ノードによって、委任先ノードに送られる。Ａｒｋｋｏ出願に記載されているように、Ａｒｋｋｏ出願の解決法は、請求側が所有者ノードであるか、それとも委任先ノードであるか識別する。この情報は、攻撃者によって、所有者ホストに関する場所その他の情報を推論するのに使用され得る。

概要

本発明の一態様によれば、一方法は、ルータがモバイルネットワーク内でセキュアなプロキシ経路最適化を実行することを可能にする。一実施形態では、モバイルネットワーク内のモバイルノードが、モバイルルータから、モバイルネットワークプレフィックスとそのモバイルルータの公開鍵を含むルータ広告メッセージを受け取る。モバイルノードは、モバイルネットワークプレフィックス、及びモバイルノード自体の公開鍵とモバイルルータの公開鍵の両方を使って、複数鍵暗号化生成アドレス（ＭＣＧＡ）を生成する。次いで、このＭＣＧＡが、モバイルルータに知らされる。一実施形態では、モバイルルータは、ＭＣＧＡとモバイルノードの公開鍵をキャッシュに入れる。次いで、モバイルルータに、セキュアなプロキシ経路最適化を実行する権限が与えられる。

また、本発明は、モバイルルータが、経路最適化を可能にするために、モバイルノードに代わって通信相手ノードに対応付け更新メッセージを送ることを可能にする方法も提供する。一実施形態では、モバイルネットワークノードに代わって、モバイルルータが、モバイルネットワークノードの通信相手ノードに保護された対応付け更新メッセージを送る。その場合、モバイルネットワークノードには、場所の変更又は気付アドレスの変更が生じたときに、モビリティ機能を果たす必要がなくなる。

本発明の別の態様によれば、セキュアなプロトコルは、通信相手ノードが、アドレスを請求するモバイルノードの権限を検証することを可能にする。通信相手ノードは、モバイルノードのネットワークアドレスとメッセージ上の署名を、そのネットワークアドレスを生成するのに使用される公開鍵を使ってチェックする。加えて、アドレスを請求するモバイルノードは、その要求に、そのネットワークアドレスを作成するのに使用される１つ又は複数の公開鍵に対応する秘密鍵を使って署名される署名を含む。この署名は、ネットワークアドレスを形成するすべての公開鍵を使って形成されたリング署名とすることができる。

本発明の一態様によれば、ネットワークアドレスが、モバイルネットワークノードによって自動的に構成され得る。モバイルネットワークノードは、適切なプロトコルを使用し、モバイルルータの公開鍵とネットワークプレフィックスを使ってネットワークアドレスを作成する。適切なプロトコルの例には、ＳＥＮＤプロトコル、すなわち、モバイルノード鍵のＩＰｖ６ルータ探索の拡張が含まれる。ルータは、モバイルノードに、モバイルノードの公開鍵を標準ＳＥＮＤ近隣探索メッセージに含ませることによって、モバイルノードの公開鍵を獲得し得る。

また、本発明は、モバイルノードが、ネットワークアドレスをセキュアに請求し、防御する方法も提供する。一実施形態では、この方法は、少なくとも、モバイルネットワークノードの公開鍵とモバイルルータの公開鍵とから生成されるネットワークアドレスを求めるアドレス解決要求を受け取るステップを含む。この方法では、アドレス解決要求に応答して、送信側に公開鍵を含めたメッセージを送る。アドレス解決要求の送信側は、受け取った公開鍵を使ってネットワークアドレスをチェックし、モバイルネットワークノード又はモバイルルータにより秘密鍵を使って署名されているメッセージ上の署名を検証する。

よって、本発明は、モバイルルータが、経路最適化のためにＩＰｖ６モバイルネットワークノードに代わって通信相手ノードに直接対応付け更新を送ることを可能にし、通信相手ノードがモバイルルータの権限を検証することを可能にする。

本発明は、本発明と添付の図面を考察すればよりよく理解されるものである。

好ましい実施形態の詳細な説明

本発明は、モビリティ管理にモバイルＩＰｖ６を使用するモバイルルータが、ＩＰｖ６モバイルネットワークノードに代わって通信相手ノードに直接対応付け更新メッセージを送ることにより、経路制御をセキュアに最適化することを可能にする。例えば、一実施形態によれば、ＩＰｖ６モバイルネットワークノードは、ネットワークプレフィックスと、モバイルルータから広告される公開鍵と、モバイルネットワークノード自体の公開鍵の組み合わせを使って、複数鍵暗号化生成ＩＰｖ６アドレス(ＭＣＧＡ)を生成する。モバイルネットワークノードもモバイルルータも、ネットワークアドレスを請求するメッセージに署名し、これを検証することができる。モバイルネットワークがその接続点を変更すると、モバイルルータは、モバイルネットワークノードに代わって、通信相手ノードに直接セキュアな対応付け更新メッセージを送る。このＭＣＧＡが通信相手ノードにセキュアに提供されれば、後続のデータパケットを最適化された経路を介して送ることができる。

図１に、ＩＰｖ６モバイルネットワークノード（「モバイルネットワークノードＡ」など）におけるＩＰｖ６ＭＣＧＡの構成を示す。図１に示すように、ステップ１０１で、モバイルルータ（「モバイルルータＢ」など）は、ＲＦＣ２４６２の要件によるＩＰｖ６マルチキャストアドレス（すなわち、「Ａｌｌ＿Ｎｏｄｅｓ＿Ｍｕｌｔｉｃａｓｔ＿Ａｄｄｒｅｓｓ」）にルータ広告メッセージをマルチキャストする。ルータ広告メッセージは、例えば、モバイルネットワークプレフィックスと、ＲＦＣ３９７１の要件などによるＣＧＡオプションの公開鍵（すなわち、モバイルルータＢ自体の公開鍵）を含む。次いで、ステップ１０２で、モバイルネットワークノードＡは、モバイルルータＢの公開鍵を使ってモバイルルータＢのアドレスを検証する。正常に検証された場合、ステップ１０３で、モバイルネットワークノードＡは、モバイルネットワークプレフィックス、及びモバイルルータＢの公開鍵とモバイルネットワークノードＡ自体の公開鍵の両方を使って、ＭＣＧＡ（「アドレスＡＢ」）を生成する。ステップ１０４で、モバイルネットワークノードＡは、重複アドレス検出プロトコルを実行して、アドレスＡＢに近隣要請を送り、ＣＧＡオプションでモバイルネットワークノードＡの公開鍵を提供する。また、モバイルネットワークノードＡは、近隣要請に、その公開鍵と、モバイルルータＢの公開鍵と、（モバイルネットワークノードＡの公開鍵を補完する）モバイルネットワークノードＡの秘密鍵を使った署名を含めてもよい。（ステップ１０５で）所定の期間後に近隣要請への応答が受け取られないとき、ステップ１０６で、モバイルルータＢは、モバイルネットワークノードＡの公開鍵とモバイルルータＢ自体の公開鍵を使って、アドレスＡＢと近隣要請の署名を検証する。ステップ１０７で、モバイルルータＢは、後で参照するために、アドレスＡＢとモバイルネットワークノードＡの公開鍵の間の対応付けを記録する。同時に（ステップ１０８）、アドレスＡＢは、今や、重複アドレスでないとみなされているため、モバイルネットワークノードＡは、アドレスＡＢを、そのＩＰトラフィックの送信元アドレスとして使用することができる。攻撃者がアドレスＡＢを詐称するのを防ぐために、モバイルネットワークノードＡとモバイルルータＢは、例えば、ＲＦＣ３９７１に記載されている証明書パス要請／広告技術を実施してもよい。

図２に、モバイルネットワークの接続点が変わるときに、モバイルルータＢが、そのホームエージェントに対応付け更新メッセージを送る手順を示す。この実施形態では、モバイルルータＢは、モビリティ管理にモバイルＩＰｖ６機能を使用する。したがって、モバイルルータＢは、モバイルルータＢが接続点を変更するときに、インターネットへの接続を確実にするためにそれ自体のホームエージェント（「ホームエージェントＤ」）に対応付け更新メッセージを送る。（図２には、新しい接続点が「アクセスルータＣ」に示されている）。この構成の下では、モバイルルータＢのモバイルネットワーク内のモバイルネットワークノード（モバイルネットワークノードＡなど）は、それ自体の対応付け更新メッセージをそれぞれのホームエージェントに送る必要がない。ＲＦＣ３９７１に従って、ステップ２０１で、モバイルルータＢとアクセスルータＣは、ＳＥＮＤプロトコルを実行して、モバイルルータＢの新しいアドレス（「気付アドレスＢ」又は「アドレスＣｏＢ」）を生成する。ステップ２０２で、モバイルルータＢは、後続のデータパケットにおいてアドレスＣｏＢを使用する。ステップ２０３で、モバイルルータＢは、モバイルルータＢのモバイルネットワークプレフィックス（「モバイルネットワークプレフィックスＢ」）とアドレスＣｏＢを使って、ホームエージェントＤに対応付け更新メッセージを送る。また、対応付け更新メッセージは、ＲＦＣ３９６３に記載されているルータフラグを含んでいてもよい。ステップ２０４で、ホームエージェントＤは、後で参照するために、モバイルネットワークプレフィックスＢとアドレスＣｏＢを表に記録する。次いで、ステップ２０５で、ホームエージェント２０５は、モバイルルータＢに対応付け確認応答メッセージを送る。

図３に、ＩＰｖ６基本サポート（すなわち、経路最適化なし）を使って、モバイルネットワークノードとその通信相手ノードの間でパケット経路制御を確立する手順を示す。ＩＰｖ６基本サポートの下では、ＲＦＣ３９６３に記載されているように、すべてのデータパケットが、モバイルルータＢ）とそのホームエージェントＤの間の双方向トンネルを介して伝搬される。ステップ３０１で、モバイルネットワークノードＡは、通信相手ノード（「ネットワークノードＥ」）にデータパケット（「パケットＸ」）を送る。ステップ３０２で、モバイルルータＢは、パケットＸを、ホームエージェントＤに向けたＩＰｖ６パケットとしてカプセル化する。ステップ３０３で、パケットＸを受け取ると、ホームエージェントＤは、パケットＸをカプセル開放し、ネットワークノードＥのアドレスを使って、その目的の宛先に転送する。ネットワークノードＥからモバイルネットワークノードＡにデータパケット（「パケットＹ」）を送るのに、ネットワークノードＥは、アドレスＡＢを宛先アドレスとして使用する。ホームエージェントＤは、ステップ３０４でパケットＹを受け取ると、モバイルネットワークプレフィックスＢを使って、以前にモバイルネットワークプレフィックスＢとアドレスＣｏＢを記録した表からアドレスＣｏＢを検索する（ステップ３０５）。次いで、ステップ３０６で、ホームエージェントＤは、パケットＹをＩＰｖ６データパケット（「パケットＹ’」）にカプセル化し、パケットＹ’を、アドレスＣｏＢを宛先アドレスに指定してモバイルルータＢに送る。パケットＹ’を受け取ると、モバイルルータＢは、パケットＹ’をカプセル開放してパケットＹを回復し、アドレスＡＢを求めて経路制御表を検索する（ステップ３０７）。ステップ３０で、モバイルルータは、パケットＹをモバイルネットワークノードＡに送る。したがって、すべてのパケットが、モバイルルータＢとホームエージェントＤの間の双方向トンネルを介して転送される場合には、パケットは、最適化された経路を介して伝搬しない可能性があることに留意されたい。経路最適化をセキュアなやり方でサポートするために、本発明の一方法では、モバイルルータＢは、モバイルネットワークノードＡがモバイルＩＰｖ６機能を果たすことができない場合でさえも、モバイルネットワークノードＡに代わってネットワークノードＥに対応付け更新メッセージを送ることができる。

図４に、対応付け更新メッセージが、モバイルネットワークノード（モバイルネットワークノードＡなど）に代わって、モバイルルータＢからネットワークノードＥに送られる初期のセキュアな対応付け更新プロトコルを示す。モバイルルータＢがネットワークノードＥにセキュアな対応付け更新メッセージを送る前に、モバイルルータＢとネットワークノードＥは、例えば、ＲＦＣ３７７５などによる往復経路確認（Return Routability）プロトコルを実行して到達性を確実にする（ステップ４０１から４０６）。ステップ４０１と４０２で、モバイルルータＢは、ＨｏｍｅＩｎｉｔＣｏｏｋｉｅ（ホーム開始クッキー）を含むＨｏｍｅＴｅｓｔＩｎｉｔＲｅｑｕｅｓｔ（ホーム試験開始要求）を、ホームエージェントＤ経由でネットワークノードＥに送る。ＨｏｍｅＴｅｓｔＩｎｉｔＲｅｑｕｅｓｔは、アドレスＡＢを送信元アドレスに指定する。同時に、モバイルルータＢは、Ｃａｒｅ−ｏｆＴｅｓｔＣｏｏｋｉｅ（気付試験クッキー）を含むＣａｒｅ−ｏｆＴｅｓｔＩｎｉｔＲｅｑｕｅｓｔ（気付試験開始要求）を、アドレスＣｏＢを送信元アドレスに指定してネットワークノードＥに直接送る（ステップ４０３）。ステップ４０４と４０５で、ネットワークノードＥは、ＨｏｍｅＩｎｉｔＣｏｏｋｉｅに基づいてＨｏｍｅＫｅｙｇｅｎ（すなわち、鍵生成）Ｔｏｋｅｎを算出し、そのＨｏｍｅＫｅｙｇｅｎＴｏｋｅｎをＨｏｍｅＩｎｉｔＣｏｏｋｉｅと共にＨｏｍｅＴｅｓｔＲｅｓｐｏｎｓｅ（ホーム試験応答）に入れて、ホームエージェントＤ経由でモバイルルータＢに送る。ステップ４０６で、ネットワークノードＥは、Ｃａｒｅ−ｏｆＩｎｉｔＣｏｏｋｉｅに基づいてＣａｒｅ−ｏｆＫｅｙｇｅｎＴｏｋｅｎ（気付鍵生成トークン）を算出し、そのＣａｒｅ−ｏｆＫｅｙｇｅｎＴｏｋｅｎをＣａｒｅ−ｏｆＩｎｉｔＣｏｏｋｉｅと共にＣａｒｅ−ｏｆＴｅｓｔＲｅｓｐｏｎｓｅ（気付試験応答）に入れて、モバイルルータＢに直接送る。次いで、ステップ４０７で、モバイルルータＢは、ＨｏｍｅＫｅｙｇｅｎＴｏｋｅｎとＣａｒｅ−ｏｆＫｅｙｇｅｎＴｏｋｅｎからＫｂｍ（対応付け管理のための鍵）を構築する。Ｋｂｍは、「半永久的」期間にわたって、セキュリティアソシエーション鍵として使用される。ステップ４０８で、Ｋｂｍを使って、モバイルルータＢは、ＲＦＣ３７７５による対応付け更新メッセージのメッセージ認証コード（ＭＡＣ）を算出する。加えて、ステップ４０９で、モバイルルータＢは、モバイルルータＢの秘密鍵を使って、対応付け更新メッセージの署名も計算する。この署名は、例えば、リング署名などとすることができる。ステップ４１０で、モバイルルータＢは、この署名を、ネットワークノードＥに送られる対応付け更新メッセージの署名オプションに含む。加えて、対応付け更新メッセージは、（ａ）対応付け権限データオプションのＭＡＣと、（ｂ）送信元アドレスフィールドのアドレスＣｏＢと、（ｃ）複数鍵ＣＧＡオプションのモバイルネットワークノードＡの公開鍵とモバイルルータＢの公開鍵も含む。ステップ４１１で、ネットワークノードＥは、モバイルネットワークノードＡの公開鍵とモバイルルータＢの公開鍵を使って、署名とＭＡＣとモバイルネットワークノードＡのＭＣＧＡ（すなわちアドレスＡＢ）を検証する。ステップ４１２で、アドレスＡＢが正常にチェックされ、署名が正常に検証されると、ネットワークノードＥは、ネットワークノードＥのアドレスを送信元アドレスに、アドレスＣｏＢを宛先アドレスに指定して、モバイルルータＢに対応付け確認応答メッセージを返送する。また、対応付け確認応答メッセージは、（ａ）対応付け権限データオプションに確認応答メッセージに対して算出されたＭＡＣを含み、（ｂ）モバイルルータＢが、後続のデータパケットの宛先アドレスを、アドレスＣｏＢからアドレスＡＢに変更できるように、例えばホームアドレスなどにアドレスＡＢを含んでいてもよい。ステップ４１３で、ネットワークノードＥは、後で参照するために、アドレスＡＢとアドレスＣｏＡを表に記録する。この時点から、ネットワークノードＥは、アドレスＣｏＢを、モバイルネットワークノードＡへの到達可能アドレスとして使用することができる。

Ａｒｋｋｏ草案で指摘されているように、シグナリング負荷は、モバイルＩＰｖ６ノードが移動するときに長い遅延をもたらす。図５に、図４の初期の対応付け更新プロトコルの後でネットワーク接続に生じる後続の変更のためのずっと簡単な対応付け更新プロトコルを示す。モバイルルータＢの接続点が新しいアクセスルータ（すなわちアクセスルータＣ）に変わる場合、モバイルルータＢとアクセスルータＣは、ステップ５０１に示すようにＳＥＮＤプロトコルを実行する。次いで、ステップ５０２で、モバイルルータＢは、その新しい気付アドレス（「アドレスＣｏＢ’」）を確立する。ステップ５０３で、モバイルルータＢは、ネットワークノードＥに、送信元アドレスとして新しいアドレスＣｏＢ’を含む仮の対応付け更新メッセージ（とＣａｒｅ−ｏｆＴｅｓｔＲｅｑｕｅｓｔも）送る。また、モバイルルータＢは、このメッセージに、以前に獲得したＫｂｍを使って、対応付け権限データオプションの仮の対応付け更新メッセージに対して算出されたＭＡＣを含む。また、ステップ５０４で、ネットワークノードＥは、仮の対応付け確認応答メッセージのＭＡＣも算出し、モバイルルータＢに、仮の対応付け確認応答メッセージを、アドレスＣｏＢ’を使って生成された、新しいＣａｒｅ−ｏｆＫｅｙｇｅｎＴｏｋｅｎと共に返す。ステップ５０５で、ネットワークノードＥは、アドレスＡＢに向けられたすべてのパケットを、アドレスＣｏＢ’に宛先変更する。これらのステップの間、モバイルネットワークノードＡとネットワークノードＥは、モバイルルータＢを介してペイロードパケットを送ってもよい。それらのパケットは、Ａｒｋｋｏ草案によれば、十分な信用が残されている限り許容される。ステップ５０６で、新しく受け取ったＣａｒｅ−ｏｆＫｅｙｇｅｎＴｏｋｅｎとＫｂｍを使って、モバイルルータＢは、次に送られる実際の対応付け更新メッセージで使用される新しい対応付け管理鍵Ｋｂｍ’を生成する。ステップ５０７で、モバイルルータＢは、Ｋｂｍ’を使って、実際の対応付け更新メッセージに対するＭＡＣを算出する。ステップ５０８で、モバイルルータＢは、Ｂの秘密鍵を使って、実際の対応付け更新メッセージに対する署名を計算する。この署名もやはりリング署名とすることができる。ステップ５０９で、モバイルルータＢは、実際の対応付け更新メッセージを、（ａ）複数鍵ＣＧＡオプションのモバイルネットワークノードＡの公開鍵及びモバイルルータＢの公開鍵と、（ｂ）署名オプションの署名と、（ｃ）対応付け権限データオプションのＭＡＣと共に送る。ステップ５１０で署名、ＭＡＣ、及びアドレスＡＢを検証した後、ネットワークノードＥは、モバイルルータＢに、ステップ５１１で算出した、新しく計算されたＭＡＣを含む対応付け確認応答メッセージを送る。ステップ５１２で、ネットワークノードＥは、アドレスＡＢとアドレスＣｏＢ'を記録する。後続のデータパケットでは、ネットワークノードＥは、アドレスＣｏＢ'を、モバイルネットワークノードＡの到達可能アドレスとして使用する。

図６に、経路最適化の観点から見たパケット経路の比較を示す。事例６０１に、セキュアな経路最適化が使用されない場合を示す。ステップ６０２で、モバイルルータＢは、そのホームエージェントＤに、その新しいアドレスを知らせる対応付け更新メッセージを送る。ホームエージェントＤがモバイルルータＢに対応付け確認応答メッセージを返送（ステップ６０３）した後、モバイルネットワークノード（モバイルネットワークノードＡなど）とその通信相手ノード（ネットワークノードＥなど）の間のすべてのパケットは、ホームエージェントＤ経由の最適化されない経路を介して伝搬される。これに対して、事例６０２では、セキュアな経路最適化の使用を可能にする。事例６０２で、モバイルルータＢは、経路最適化のために、セキュアな対応付け更新メッセージを、適切なパラメータと共にネットワークノードＥに直接送る（ステップ６０６）。これらのパラメータには、（ａ）複数鍵ＣＧＡオプションの公開鍵と、（ｂ）署名オプションのリング署名が含まれる。次いで、ネットワークノードＥは、モバイルルータＢに、適切なセキュリティパラメータを含むセキュアな対応付け確認応答メッセージ６０７を返送する。その後、モバイルネットワークノードＡとネットワークノードＥの間のすべてのデータパケットは、参照番号６０８を付した、最適化された経路を介して送信され得る。モバイルルータＢには、モバイルネットワークノードＡのアドレス（すなわちアドレスＡＢ）を使用する権限が与えられているため、モバイルルータＢは、モバイルネットワークノードＡに代わってネットワークノードＥに対応付け更新メッセージを送るプロキシとなることができる。ネットワークノードＥは、モバイルルータＢからの対応付け更新メッセージを検証し、認証することができるため、信頼性の高い、最適化された経路を、ホームエージェントＤを介したトンネリングなしで使用することができる。

以上の詳細な説明は、本発明の具体的実施形態を説明するために示すものであり、限定するためのものではない。本発明の適用範囲内で多数の改変及び変形が可能である。本発明を、添付の図面に示す。

ＩＰｖ６モバイルネットワークノードＡが、それ自体の公開鍵とモバイルルータＢの公開鍵を使ってＭＣＧＡを構成する手順を示す図である。モバイルルータＢが、それ自体のホームエージェントに対応付け更新メッセージを送る手順を示す図である。ＩＰｖ６基本サポートの下で（すなわち経路最適化なしで）、モバイルネットワークノードとその通信相手ノードの間のパケット経路制御を確立する手順を示す図である。モバイルルータＢが、経路最適化を可能にするために、モバイルネットワークノードに代わって、最初にモバイルネットワークノードの通信相手ノードに対応付け更新メッセージを送り、後続のデータパケットが、最適化された経路を介して送られるようにするセキュアな対応付け更新プロトコルを示す図である。図４の初期対応付け更新プロトコルの後でネットワーク接続に生じる後続の変更のためのずっと簡単な対応付け更新プロトコルを示す図である。セキュアな経路最適化なしとセキュアな経路最適化ありで行われ得る経路制御最適化を比較する図である。

Claims

モバイルルータがモバイルネットワークノードのためにセキュアなプロキシ対応付け更新を実行することを可能にする方法であって、
ネットワークプレフィックス、及び前記モバイルルータと関連付けられた公開鍵を受け取るステップと、
前記ネットワークプレフィックス、前記モバイルネットワークノードと関連付けられた公開鍵、及び前記モバイルルータからの前記公開鍵を使って、ネットワークアドレスを作成するステップと
を含む方法。