(57)【要約】本発明の第１の態様は、モバイル・ノードのモビリティを管理するために、ネットワーク・ベース及びホスト・ベースの両方のモビリティ管理を実施するローカル・モビリティ・アンカーでのセキュリティを向上させるための方法に関する。モバイル・ノード（ＭＮ）からネットワーク内のネットワーク要素への接続を検証するための方法を提案する。本発明の第２の態様は、登録メッセージ間に競合状態が発生しているか否かを検出し、モバイル・ノードの最も新しい位置を解決する、モビリティ・アンカー・ノードで実施されることになる方法に関する。本発明の第３の態様は、通信相手ノードでモバイルに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための方法、及び通信相手ノードでモバイル・ノードの気付けアドレスを登録するための方法に関する。【選択図】図１
2010507301.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク内のネットワーク要素へのモバイル・ノード（ＭＮ）の接続を検証するための方法であって、前記ネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、
第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージを受信するステップであって、前記第１のメッセージは第１のＩＰアドレスを有するステップと、
第２のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージを受信するステップであって、前記第２のメッセージは、第２のＩＰアドレスを有するステップと、
前記第１及び第２の両方のＩＰアドレスに確認メッセージを送信するステップと、
前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第１のメッセージと前記確認メッセージを比較するステップと、
前記比較の結果に基づいて、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージが改ざんされているか否かを検出するステップとを、
有する方法。
【請求項２】
前記第１のネットワークが、前記モバイル・ノード（ＭＮ）の前記モビリティを管理するためにモバイル・ノード（ＭＮ）ベースのモビリティ管理スキームを使用し、前記第２のネットワークが、前記モバイル・ノード（ＭＮ）の前記モビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、
前記第１のメッセージ（ＢＵ）が、ローカル・モビリティ・アンカー（ＬＭＡ）によって前記モバイル・ノード（ＭＮ）から受信され、前記第１のメッセージが前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受け入れられ、前記第２のメッセージ（ＰＢＵ）が、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって前記第２のネットワーク内のネットワーク要素から受信され、
前記確認メッセージが、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって前記モバイル・ノード（ＭＮ）及び前記第２のネットワーク内の前記ネットワーク要素にそれぞれ送信されるバインディング確認メッセージ（ＰＢＡ、ＢＡ’）であり、
前記比較するステップ及び検出するステップが、前記モバイル・ノード（ＭＮ）によって実行される請求項１に記載の方法。
【請求項３】
前記第１及び第２のメッセージがそれぞれ第１及び第２のシーケンス番号を更に有し、前記確認メッセージ（ＰＢＡ、ＢＡ’）が、前記第２のシーケンス番号と共に送信され、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の前記位置に関する前記第１のメッセージの前記第１のシーケンス番号と、前記確認メッセージ（ＰＢＡ、ＢＡ’）の前記第２のシーケンス番号とが互いに比較される請求項１又は２に記載の方法。
【請求項４】
前記受信した確認メッセージ（ＢＡ’）の前記第２のシーケンス番号が、前記第１のメッセージ（ＢＵ）の前記第１のシーケンス番号とは異なり、かつ、アクセス・ルータによって前記モバイル・ノード（ＭＮ）に通知されたプレフィックスが、前記モバイル・ノード（ＭＮ）のホーム・プレフィックスとは異なる場合、又は
前記受信した確認メッセージ（ＢＡ’）の前記第２のシーケンス番号が、前記第１のメッセージ（ＢＵ）の前記第１のシーケンス番号と等しい場合には、前記受信した確認メッセージ（ＢＡ’）が、前記第２のシーケンス番号を有する受信した前記第１の確認メッセージ（ＢＡ’）ではなく、かつ、アクセス・ルータによって前記モバイル・ノード（ＭＮ）に通知された前記プレフィックスが、前記モバイル・ノードのホーム・プレフィックスとは異なる場合、
前記モバイル・ノード（ＭＮ）によって、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ネットワーク要素からの前記第２のメッセージ（ＰＢＵ）が改ざんされている旨を決定するステップを更に有する請求項３に記載の方法。
【請求項５】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ネットワーク要素からの前記第２のメッセージ（ＰＢＵ）が改ざんされているものと決定された場合、前記モバイル・ノード（ＭＮ）によって、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第３のメッセージ（ＢＵ’）を、前記ローカル・モビリティ・アンカー（ＬＭＡ）に送信するステップを更に有する請求項２から４のいずれか１つに記載の方法。
【請求項６】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ネットワーク要素からの前記第２のメッセージ（ＰＢＵ）が改ざんされていると決定された旨を、前記第３のメッセージ（ＢＵ’）内にフラグを設定することにより、前記モバイル・ノード（ＭＮ）によって、前記ローカル・モビリティ・アンカー（ＬＭＡ）に優先的に通知するステップを更に有する請求項５に記載の方法。
【請求項７】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ネットワーク要素からの前記第２のメッセージ（ＰＢＵ、ＰＢＵ’）を前記ローカル・モビリティ・アンカー（ＬＭＡ）によって破棄するステップと、
前記ローカル・モビリティ・アンカー（ＬＭＡ）によって、信頼されるネットワーク要素のリストから前記ネットワーク要素を削除するステップとを、
更に有する請求項６に記載の方法。
【請求項８】
前記モバイル・ノード（ＭＮ）からの前記通知を受信した場合に、前記ローカル・モビリティ・アンカー（ＬＭＡ）により、前記モバイル・ノード（ＭＮ）のネットワーク認証に関する情報を認証サーバから取得するステップと、
前記ネットワーク要素と前記モバイル・ノード（ＭＮ）のネットワーク認証が存在しないことに気付いた場合には、信頼されるネットワーク要素のリストから前記ネットワーク要素を削除するステップとを、
更に有する請求項６に記載の方法。
【請求項９】
前記第１及び第２のネットワークが、前記モバイル・ノード（ＭＮ）の前記モビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、
前記第１のメッセージ（ＰＢＵ１）が、ローカル・モビリティ・アンカー（ＬＭＡ）によって前記第１のネットワーク内の第１のネットワーク要素から受信され、前記第１のメッセージが、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受け入れられ、前記第２のメッセージ（ＰＢＵ２）が、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって前記第２のネットワーク内の第２のネットワーク要素から受信され、
前記確認メッセージが、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって、前記第１及び前記第２の両方のネットワーク要素に送信されるバインディング確認メッセージ（ＰＢＡ２、ＰＢＡ’２）であり、
前記比較するステップ及び検出するステップが、前記第１のネットワーク要素によって実行される請求項１に記載の方法。
【請求項１０】
前記第１のネットワーク要素によって、前記モバイル・ノード（ＭＮ）が、依然として前記第１のネットワーク要素に接続されているか否かを決定するステップを更に有し、前記第１のネットワーク要素が、前記比較結果及び前記決定結果のうちの少なくとも１つに基づいて、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージが改ざんされているか否かを検出する請求項９に記載の方法。
【請求項１１】
前記第１及び第２のメッセージが、それぞれ第１及び第２のシーケンス番号を更に有し、前記確認メッセージ（ＰＢＡ２、ＰＢＡ’２）が、前記第２のシーケンス番号と共に送信され、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の前記位置に関する前記第１のメッセージの前記第１のシーケンス番号と、前記確認メッセージ（ＰＢＡ’２）の前記第２のシーケンス番号とが互いに比較される請求項１０に記載の方法。
【請求項１２】
前記受信した確認メッセージ（ＰＢＡ’２）の第２のシーケンス番号が、前記第１のメッセージ（ＰＢＵ１）の前記第１のシーケンス番号とは異なり、かつ、前記モバイル・ノード（ＭＮ）が依然として前記第１のネットワーク要素に接続されている場合、又は
前記受信した確認メッセージ（ＰＢＡ’２）の第２のシーケンス番号が、前記第１のメッセージ（ＰＢＵ１）の前記第１のシーケンス番号と等しい場合には、前記受信した確認メッセージ（ＰＢＡ’２）が、前記第２のシーケンス番号を有する受信した前記第１の確認メッセージ（ＰＢＡ’２）ではなく、かつ、前記モバイル・ノード（ＭＮ）が依然として前記第１のネットワーク要素に接続されている場合、
前記第１のネットワーク要素によって、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のネットワーク要素からの前記第２のメッセージ（ＰＢＵ２）が改ざんされている旨を決定するステップを更に有する請求項１１に記載の方法。
【請求項１３】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のネットワーク要素からの前記第２のメッセージ（ＰＢＵ２）が改ざんされていると決定された場合、前記第１のネットワーク要素によって、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第３のメッセージ（ＰＢＵ’）を前記ローカル・モビリティ・アンカー（ＬＭＡ）に送信するステップを更に有する請求項９から１２のいずれか１つに記載の方法。
【請求項１４】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のネットワーク要素からの前記第２のメッセージ（ＰＢＵ２）が改ざんされていると決定された旨を、前記第３のメッセージ（ＰＢＵ’）内にフラグを設定することにより、前記第１のネットワーク要素によって、前記ローカル・モビリティ・アンカー（ＬＭＡ）に優先的に通知するステップを更に有する請求項１３に記載の方法。
【請求項１５】
前記第１のネットワーク要素からの前記通知を受信した場合に、前記ローカル・モビリティ・アンカー（ＬＭＡ）により、前記モバイル・ノード（ＭＮ）のネットワーク認証に関する情報を認証サーバから取得するステップと、
前記第２のネットワーク要素と前記モバイル・ノード（ＭＮ）のネットワーク認証が存在しないことに気付いた場合には、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって、信頼されるネットワーク要素のリストから前記第２のネットワーク要素を削除するステップとを、
更に有する請求項１４に記載の方法。
【請求項１６】
ネットワーク内のネットワーク要素へのモバイル・ノード（ＭＮ）の接続を検証するための方法であり、前記ネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、ローカル・モビリティ・アンカー（ＬＭＡ）によって実行される方法であって、
第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージを受信するステップであって、前記第１のメッセージは第１のＩＰアドレスを有するステップと、
第２のネットワークは前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージを受信するステップであって、前記第２のメッセージは第２のＩＰアドレスを有するステップと、
前記第１及び第２の両方のＩＰアドレスに確認メッセージを送信するステップであって、前記確認メッセージが、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージと前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージとの再送をそれぞれ要求するステップと、
前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受信された前記モバイル・ノード（ＭＮ）の位置に関する再送されたメッセージに基づいて、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージが改ざんされているか否かを検出するステップとを、
更に有する方法。
【請求項１７】
前記第１のネットワークが、前記モバイル・ノード（ＭＮ）の前記モビリティを管理するためにモバイル・ノード（ＭＮ）ベースのモビリティ管理スキームを使用し、前記第２のネットワークが、前記モバイル・ノード（ＭＮ）の前記モビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、
前記第１のメッセージ（ＢＵ）が、前記モバイル・ノード（ＭＮ）から受信され、前記第１のメッセージが、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受け入れられ、前記第２のメッセージ（ＰＢＵ）が、前記第２のネットワーク内のネットワーク要素から受信され、
前記確認メッセージが、バインディング確認メッセージ（ＰＢＡ、ＢＡ’）又はモビリティ・ヘッダ信号要求メッセージであり、前記確認メッセージが、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージ（ＢＵ’）と、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージ（ＰＢＵ’）との再送をそれぞれ、前記モバイル・ノード（ＭＮ）及び前記第２のネットワーク内の前記ネットワーク要素に要求する請求項１６に記載の方法。
【請求項１８】
前記確認メッセージが、バインディング・リフレッシュ・アドバイス・オプションを備えたバインディング確認メッセージ（ＰＢＡ、ＢＡ’）であって、前記バインディング・リフレッシュ・アドバイス・オプション内のリフレッシュ間隔フィールドの値を実質的にゼロに設定するステップを更に有する請求項１６又は１７に記載の方法。
【請求項１９】
前記バインディング確認メッセージ内の存続期間フィールドの値が実質的にゼロに設定される請求項１８に記載の方法。
【請求項２０】
前記確認メッセージが、バインディング・リフレッシュ・アドバイス・オプションを備えていないバインディング確認メッセージ（ＰＢＡ、ＢＡ’）であって、前記バインディング確認メッセージ内の存続期間フィールドの値を実質的にゼロに設定するステップを更に有する請求項１６又は１７に記載の方法。
【請求項２１】
アクセス・ルータによって前記モバイル・ノード（ＭＮ）に通知されたプレフィックスが、前記モバイル・ノード（ＭＮ）のホーム・プレフィックスとは異なる場合にのみ、前記モバイル・ノード（ＭＮ）が、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージ（ＢＵ’）を再送する請求項１６から２０のいずれか１つに記載の方法。
【請求項２２】
前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージ（ＢＵ’）と、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージ（ＰＢＵ’）との両方が、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受信された場合、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ネットワーク要素からの前記第２のメッセージ（ＰＢＵ、ＰＢＵ’）が改ざんされていることを決定するステップを更に有する請求項１６から２１のいずれか１つに記載の方法。
【請求項２３】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ネットワーク要素からの前記第２のメッセージ（ＰＢＵ、ＰＢＵ’）を破棄するステップと、
信頼されるネットワーク要素のリストから前記ネットワーク要素を削除するステップとを、
更に有する請求項２２に記載の方法。
【請求項２４】
前記モバイル・ノード（ＭＮ）のネットワーク認証に関する情報を認証サーバから取得するステップと、
前記ネットワーク要素と前記モバイル・ノード（ＭＮ）のネットワーク認証が存在しないことに気付いた場合には、信頼されるネットワーク要素のリストから前記ネットワーク要素を削除するステップとを、
更に有する請求項２２に記載の方法。
【請求項２５】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージ（ＰＢＵ’）のみが前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受信された場合、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ネットワーク要素からの前記第２のメッセージ（ＰＢＵ、ＢＵ’）が真正であることを決定するステップを更に有する請求項１６から２１のいずれか１つに記載の方法。
【請求項２６】
前記第１及び第２のネットワークが、前記モバイル・ノード（ＭＮ）の前記モビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、
前記第１のメッセージ（ＰＢＵ１）が、第１のネットワーク内の第１のネットワーク要素から受信され、前記第１のメッセージが、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受け入れられ、前記第２のメッセージ（ＰＢＵ２）が、前記第２のネットワーク内の第２のネットワーク要素から受信され、
前記確認メッセージが、バインディング確認メッセージ（ＰＢＡ２、ＰＢＡ’２）又はモビリティ・ヘッダ信号要求メッセージであって、前記確認メッセージが、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージ（ＰＢＵ’１）と、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージ（ＰＢＵ’２）との再送をそれぞれ、前記第１のネットワーク要素及び前記第２のネットワーク要素に要求する請求項１６に記載の方法。
【請求項２７】
前記確認メッセージが、バインディング・リフレッシュ・アドバイス・オプションを備えたバインディング確認メッセージ（ＰＢＡ２、ＰＢＡ’２）であって、前記バインディング・リフレッシュ・アドバイス・オプション内のリフレッシュ間隔フィールドの値を実質的にゼロに設定するステップを更に有する請求項２６に記載の方法。
【請求項２８】
前記バインディング確認メッセージ内の存続期間フィールドの値が、実質的にゼロに設定される請求項２７に記載の方法。
【請求項２９】
前記確認メッセージが、バインディング・リフレッシュ・アドバイス・オプションを備えていないバインディング確認メッセージ（ＰＢＡ、ＢＡ’）であって、前記バインディング確認メッセージ内の存続期間フィールドの値を実質的にゼロに設定するステップを更に有する請求項２６に記載の方法。
【請求項３０】
前記それぞれの確認メッセージ（ＰＢＡ２、ＰＢＡ’２）を受信した場合に、前記第１及び第２のネットワーク要素によって、前記モバイル・ノード（ＭＮ）が依然として接続されているか否かをチェックするステップと、
前記モバイル・ノード（ＭＮ）が接続されている場合にのみ、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージ（ＰＢＵ’１）と、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージ（ＰＢＵ’２）とを再送するステップとを、
更に有する請求項２６から２９のいずれか１つに記載の方法。
【請求項３１】
前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージ（ＰＢＵ’１）と、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージ（ＰＢＵ’２）との両方が、前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受信された場合、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のネットワーク要素からの前記第２のメッセージ（ＰＢＵ２、ＰＢＵ’２）が改ざんされていることを決定するステップを更に有する請求項２６から３０のいずれか１つに記載の方法。
【請求項３２】
前記モバイル・ノード（ＭＮ）のネットワーク認証に関する情報を認証サーバから取得するステップと、
前記第２のネットワーク要素と前記モバイル・ノード（ＭＮ）のネットワーク認証が存在しないことに気付いた場合には、信頼されるネットワーク要素のリストから前記第２のネットワーク要素を削除するステップとを、
更に有する請求項３１に記載の方法。
【請求項３３】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージ（ＰＢＵ’２）のみが前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受信された場合、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のネットワーク要素からの前記第２のメッセージ（ＰＢＵ２、ＰＢＵ’２）が真正であることを決定するステップを更に有する請求項２６から３０のいずれか１つに記載の方法。
【請求項３４】
ネットワーク内のネットワーク要素へのモバイル・ノード（ＭＮ）の接続を検証するように構成されたローカル・モビリティ・アンカーであって、前記ネットワークは、モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、
第１のネットワーク内のモバイル・ノード（ＭＮ）の位置に関する第１のメッセージであって、前記第１のメッセージは第１のＩＰアドレスを有する第１のメッセージと、第２のネットワーク内のモバイル・ノード（ＭＮ）の位置に関する第２のメッセージであって、前記第２のメッセージは第２のＩＰアドレスを有する第２のメッセージとを受信するための受信手段であって、前記第２のネットワークは前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用する受信手段と、
前記第１及び第２の両方のＩＰアドレスに確認メッセージを送信するための送信手段とを、
有するローカル・モビリティ・アンカー。
【請求項３５】
前記第１及び第２のメッセージが、それぞれ第１及び第２のシーケンス番号を更に有し、前記ローカル・モビリティ・アンカー（ＬＭＡ）が、前記第２のシーケンス番号と共に前記確認メッセージを送信するように構成された請求項３４に記載のローカル・モビリティ・アンカー。
【請求項３６】
前記ローカル・モビリティ・アンカー（ＬＭＡ）が、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージ（ＰＢＵ、ＰＢＵ’）を破棄するように構成され、前記ローカル・モビリティ・アンカー（ＬＭＡ）が、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第３のメッセージ（ＢＵ’）を前記モバイル・ノード（ＭＮ）から受信した場合、信頼されるネットワーク要素のリストから、前記第２のメッセージ（ＰＢＵ、ＰＢＵ’）の発信元であるネットワーク要素を削除するように構成された請求項３４又は３５に記載のローカル・モビリティ・アンカー。
【請求項３７】
前記ローカル・モビリティ・アンカー（ＬＭＡ）が、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージが改ざんされていると決定された旨の通知を受信した場合に、前記モバイル・ノード（ＭＮ）のネットワーク認証に関する情報を認証サーバから取得するように構成され、前記ネットワーク要素と前記モバイル・ノード（ＭＮ）のネットワーク認証が存在しないことに気付いた場合には、信頼されるネットワーク要素のリストから、前記第２のメッセージの発信元であるネットワーク要素を削除する請求項３４又は３５に記載のローカル・モビリティ・アンカー。
【請求項３８】
第１のネットワークは、モバイル・ノード（ＭＮ）のモビリティを管理するためにモバイル・ノード（ＭＮ）ベースのモビリティ管理スキームを使用し、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージ（ＢＵ）を送信するための送信手段と、
ローカル・モビリティ・アンカー（ＬＭＡ）から確認メッセージ（ＢＡ’）を受信するための受信手段と、
前記第１のネットワーク内のモバイル・ノード（ＭＮ）の位置に関する前記第１のメッセージ（ＢＵ）と、前記受信した確認メッセージ（ＢＡ’）とを比較するための比較手段と、
第２のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記比較結果に基づいて、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ローカル・モビリティ・アンカー（ＬＭＡ）で受信した第２のメッセージ（ＰＢＵ）が、改ざんされているか否かを検出するための検出手段とを、
有するモバイル・ノード。
【請求項３９】
前記第１のメッセージ（ＢＵ）が、第１のシーケンス番号を更に有し、前記受信した確認メッセージ（ＢＡ’）が、第２のシーケンス番号を備え、前記モバイル・ノード（ＭＮ）が、前記第１のメッセージ（ＢＵ）の前記第１のシーケンス番号と、前記確認メッセージ（ＢＡ’）の前記第２のシーケンス番号とを互いに比較するように構成された請求項３８に記載のモバイル・ノード。
【請求項４０】
前記受信した確認メッセージ（ＢＡ’）の第２のシーケンス番号が、前記第１のメッセージ（ＢＵ）の前記第１のシーケンス番号とは異なり、かつ、アクセス・ルータによって前記モバイル・ノード（ＭＮ）に通知されたプレフィックスが、前記モバイル・ノード（ＭＮ）のホーム・プレフィックスとは異なる場合、又は
前記受信した確認メッセージ（ＢＡ’）の前記第２のシーケンス番号が、前記第１のメッセージ（ＢＵ）の前記第１のシーケンス番号と等しい場合には、前記受信した確認メッセージ（ＢＡ’）が、前記第２のシーケンス番号を含む受信した前記第１の確認メッセージ（ＢＡ’）ではなく、かつ、アクセス・ルータによって前記モバイル・ノード（ＭＮ）に通知された前記プレフィックスが、前記モバイル・ノード（ＭＮ）のホーム・プレフィックスとは異なる場合、
前記モバイル・ノード（ＭＮ）が、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージ（ＰＢＵ）が改ざんされている旨を決定するように構成された請求項３９に記載のモバイル・ノード。
【請求項４１】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ネットワーク要素からの前記第２のメッセージ（ＰＢＵ）が改ざんされていると決定された場合、前記モバイル・ノード（ＭＮ）が、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第３のメッセージ（ＢＵ’）を前記ローカル・モビリティ・アンカー（ＬＭＡ）に送信するように構成された請求項４０に記載のモバイル・ノード。
【請求項４２】
前記モバイル・ノード（ＭＮ）が、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージ（ＰＢＵ）が改ざんされていると決定された旨を、前記第３のメッセージ（ＢＵ’）内にフラグを設定することにより、前記ローカル・モビリティ・アンカー（ＬＭＡ）に優先的に通知するように構成された請求項４１に記載のモバイル・ノード。
【請求項４３】
第１のネットワークは、モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージ（ＰＢＵ１）を送信するための送信手段と、
ローカル・モビリティ・アンカー（ＬＭＡ）から確認メッセージ（ＰＢＡ’２）を受信するための受信手段と、
前記第１のネットワーク内のモバイル・ノード（ＭＮ）の位置に関する前記第１のメッセージ（ＰＢＵ１）と、前記受信した確認メッセージ（ＰＢＡ’２）とを比較するための比較手段と、
第２のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記比較結果に基づいて、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記ローカル・モビリティ・アンカー（ＬＭＡ）で受信した第２のメッセージ（ＰＢＵ２）が、改ざんされているか否かを検出するための検出手段とを、
有するネットワーク要素。
【請求項４４】
前記ネットワーク要素が、前記モバイル・ノード（ＭＮ）が依然として前記ネットワーク要素に接続されているか否かを決定するように構成され、前記比較結果及び前記決定結果のうちの少なくとも１つに基づいて、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージ（ＰＢＵ２）が改ざんされているか否かを検出するように構成された請求項４３に記載のネットワーク要素。
【請求項４５】
それぞれ、前記第１のメッセージ（ＰＢＵ１）が、第１のシーケンス番号を更に有するとともに、前記受信した確認メッセージが、第２のシーケンス番号を有し、前記ネットワーク要素が、前記第１のメッセージ（ＰＢＵ１）の前記第１のシーケンス番号と、前記確認メッセージの前記第２のシーケンス番号とを互いに比較するように構成された請求項４３又は４４に記載のネットワーク要素。
【請求項４６】
前記受信した確認メッセージ（ＰＢＡ’２）の前記第２のシーケンス番号が、前記第１のメッセージ（ＰＢＵ１）の前記第１のシーケンス番号とは異なり、かつ、前記モバイル・ノード（ＭＮ）が依然として前記ネットワーク要素に接続されている場合、又は
前記受信した確認メッセージ（ＰＢＡ’２）の前記第２のシーケンス番号が、前記第１のメッセージ（ＰＢＵ１）の前記第１のシーケンス番号と等しい場合には、前記受信した確認メッセージ（ＰＢＡ’２）が、前記第２のシーケンス番号を含む受信した前記第１の確認メッセージ（ＰＢＡ’２）ではなく、かつ、前記モバイル・ノード（ＭＮ）が依然として前記ネットワーク要素に接続されている場合、
前記ネットワーク要素が、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージ（ＰＢＵ２）が改ざんされている旨を決定するように構成された請求項４５に記載のネットワーク要素。
【請求項４７】
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のネットワーク要素からの前記第２のメッセージ（ＰＢＵ２）が改ざんされていると決定された場合、前記ネットワーク要素が、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第３のメッセージ（ＰＢＵ’）を前記ローカル・モビリティ・アンカー（ＬＭＡ）に送信するように構成された、請求項４３から４６のいずれか１項に記載のネットワーク要素。
【請求項４８】
前記ネットワーク要素が、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージ（ＰＢＵ２）が改ざんされていると決定された旨を、前記第３のメッセージ（ＰＢＵ’）内にフラグを設定することにより、前記ローカル・モビリティ・アンカー（ＬＭＡ）に優先的に通知するように構成された、請求項４７に記載のネットワーク要素。
【請求項４９】
ネットワーク内のネットワーク要素へのモバイル・ノード（ＭＮ）の接続を検証するように構成されたローカル・モビリティ・アンカーであって、前記ネットワークは、モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、
第１のネットワーク内のモバイル・ノード（ＭＮ）の位置に関する第１のメッセージであって、前記第１のメッセージは第１のＩＰアドレスを有する第１のメッセージと、第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージであって、前記第２のメッセージは第２のＩＰアドレスを有する第２のメッセージとを受信するための受信手段であって、前記第２のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用する受信手段と、
前記第１及び第２の両方のＩＰアドレスに確認メッセージを送信するための送信手段であって、前記確認メッセージは、第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第１のメッセージと、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する第２のメッセージとの再送をそれぞれ要求する送信手段と、
前記ローカル・モビリティ・アンカー（ＬＭＡ）によって受信された前記モバイル・ノード（ＭＮ）の位置に関する再送されたメッセージに基づいて、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関する前記第２のメッセージが改ざんされているか否かを検出するための検出手段とを、
有するローカル・モビリティ・アンカー。
【請求項５０】
前記ローカル・モビリティ・アンカーが、請求項１７から２０のいずれか１つに記載の方法、又は請求項２２から２９のいずれか１つに記載の方法、又は請求項３１から３３のいずれか１つに記載の方法のステップを実行するように構成された請求項４９に記載のローカル・モビリティ・アンカー。
【請求項５１】
モバイル・アンカー・ポイントでモバイル・ノード（ＭＮ）のモビリティを管理するための方法であって、前記モバイル・ノード（ＭＮ）は、第１のネットワークと第２のネットワークとの間を移動し、前記第１のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにモバイル・ノード（ＭＮ）ベースのモビリティ管理スキームを使用し、前記第２のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・アンカー・ポイントは、前記モバイル・ノード（ＭＮ）ベースのモビリティ管理スキーム及び前記ネットワーク・ベースのモビリティ管理スキームの両方を実施し、前記モバイル・アンカー・ポイントによって実行される下記のステップ：
前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の第１の位置に関する前記モバイル・ノード（ＭＮ）から第１のメッセージを受信するステップであって、前記モバイル・ノード（ＭＮ）は第１のＩＰアドレスを有するステップと、
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の第２の位置に関する前記第２のネットワーク内のネットワーク要素から第２のメッセージを受信するステップであって、前記モバイル・ノード（ＭＮ）が第２のＩＰアドレスを有するステップと、
前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するステップと、
前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する応答メッセージを受信するステップと、
前記受信した応答メッセージに基づいて、前記第１及び第２のＩＰアドレスのうちのどちらが前記モバイル・ノード（ＭＮ）の現行ＩＰアドレスであるかを決定するステップとを、
有する方法。
【請求項５２】
モバイル・アンカー・ポイントでモバイル・ノード（ＭＮ）のモビリティを管理するための方法であって、前記モバイル・ノード（ＭＮ）は、第１のネットワークと第２のネットワークとの間を移動し、前記第１及び第２のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・アンカー・ポイントは、前記ネットワーク・ベースのモビリティ管理スキームを実施し、前記モバイル・アンカー・ポイントによって実行される下記のステップ：
前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の第１の位置に関する第１のメッセージを前記第１のネットワーク内の第１のネットワーク要素から受信するステップであって、前記モバイル・ノード（ＭＮ）が第１のＩＰアドレスを有するステップと、
前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の第２の位置に関する第２のメッセージを前記第２のネットワーク内の第２のネットワーク要素から受信するステップであって、前記モバイル・ノード（ＭＮ）が第２のＩＰアドレスを有するステップと、
前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するステップと、
前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する応答メッセージを受信するステップと、
前記受信した応答メッセージに基づいて、前記第１及び第２のＩＰアドレスのうちのどちらが前記モバイル・ノード（ＭＮ）の現行ＩＰアドレスであるかを決定するステップとを、
有する方法。
【請求項５３】
前記受信した応答メッセージが、前記第１及び第２のＩＰアドレスのうちの少なくとも１つに対する肯定応答メッセージである場合、前記第１及び第２のＩＰアドレスのうちの少なくとも１つが、前記モバイル・ノード（ＭＮ）の前記現行ＩＰアドレスとして決定される請求項５１又は５２に記載の方法。
【請求項５４】
前記肯定応答メッセージが、非ゼロの存続期間を有するバインディング更新メッセージである請求項５３に記載の方法。
【請求項５５】
前記受信した応答メッセージが、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する否定応答メッセージである場合、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する他方が、前記モバイル・ノード（ＭＮ）の前記現行ＩＰアドレスとして決定される請求項５１又は５２に記載の方法。
【請求項５６】
前記第１及び第２のメッセージの受信間の時間間隔を測定するステップを更に有し、前記測定された時間間隔が所定の期間よりも短い場合、前記バインディング要求メッセージが、前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの少なくとも１つに送信される請求項５１から５５のいずれか１つに記載の方法。
【請求項５７】
前記所定の期間が、前記第１と第２のネットワーク間での前記モバイル・ノード（ＭＮ）のハンドオーバで必要な最低期間よりも長いか又は等しい請求項５６に記載の方法。
【請求項５８】
前記第１のＩＰアドレスが、前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）に対して構成された第１の気付けアドレスであり、前記第２のＩＰアドレスが、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）に対して構成された第２の気付けアドレスである請求項５１から５７のいずれか１つに記載の方法。
【請求項５９】
前記モバイル・アンカー・ポイントでの前記第１のメッセージの第１の到達時間と、前記モバイル・アンカー・ポイントでの前記第２のメッセージの第２の到達時間との時間差を計算するステップを更に有する請求項５１から５８のいずれか１つに記載の方法。
【請求項６０】
前記モバイル・アンカー・ポイントが前記モバイル・ノード（ＭＮ）に対するホーム・エージェントであり、
前記第１及び第２のメッセージのうちで最も早く受信されたメッセージのＩＰアドレスを、優先的に前記ホーム・エージェントのバインディング・キャッシュ・エントリ内に格納するステップと、
前記第１及び第２のメッセージのうちで最も遅く受信されたメッセージのＩＰアドレスを前記バインディング更新メッセージの受信まで格納するステップとを、
更に有する請求項５１から５９のいずれか１つに記載の方法。
【請求項６１】
前記バインディング要求メッセージが、前記第１及び第２のメッセージのうちで最も早く受信されたメッセージに関する前記格納されたＩＰアドレス、及び前記第１及び第２のメッセージのうちで最も遅く受信されたメッセージに関する前記格納されたＩＰアドレスに送信される請求項６０に記載の方法。
【請求項６２】
前記バインディング更新メッセージを受信した場合に、前記第１及び第２のメッセージのうちで最も遅く受信されたメッセージに関する前記格納されたＩＰアドレスを削除するステップと、
前記受信されたバインディング更新メッセージに含まれる前記第１及び第２のＩＰアドレスのうちの前記１つによって、前記第１及び第２のメッセージのうちで最も早く受信されたメッセージに関する前記格納されたＩＰアドレスを更新するステップとを、
更に有する請求項６０又は６１に記載の方法。
【請求項６３】
前記受信されたバインディング更新メッセージに含まれる前記第１及び第２のＩＰアドレスのうちの前記１つが、前記第１及び第２のメッセージのうちで最も早く受信されたメッセージに関する前記格納されたＩＰアドレスに対応する場合、前記バインディング・キャッシュ・エントリのタイマ存続期間を更新するステップを更に有する請求項６２に記載の方法。
【請求項６４】
前記バインディング要求メッセージが、バインディング確認メッセージ、気付けアドレス・テスト開始メッセージ、又はインターネット制御メッセージ・プロトコル・メッセージのうちの少なくとも１つである請求項５１から６３のいずれか１つに記載の方法。
【請求項６５】
前記バインディング要求メッセージが、バインディング確認メッセージであり、前記方法が、前記バインディング確認メッセージを送信する前に、前記バインディング確認メッセージのリフレッシュ・アドバイス・オプションをゼロに設定するステップを更に有する請求項５１から６４のいずれか１つに記載の方法。
【請求項６６】
リフレッシュ・アドバイス・オプションがゼロに設定されたバインディング要求メッセージを受信した場合に、前記モバイル・ノード（ＭＮ）又は前記ネットワーク要素によって、バインディング更新を前記モバイル・アンカー・ポイントに送信するステップを更に有する請求項６５に記載の方法。
【請求項６７】
前記ネットワーク要素によって、前記モバイル・アンカー・ポイントから前記バインディング要求メッセージを受信するステップと、
前記ネットワーク要素によって、前記ネットワーク要素への前記モバイル・ノード（ＭＮ）の接続をチェックするステップと、
前記モバイル・ノード（ＭＮ）が前記ネットワーク要素に接続されている場合、前記ネットワーク要素によって、バインディング更新を前記モバイル・アンカー・ポイントに送信するか、又は前記モバイル・ノード（ＭＮ）が前記ネットワーク要素に接続されていない場合、前記ネットワーク要素によって、前記バインディング要求メッセージを破棄するステップとを、
更に有する請求項５１から６６のいずれか１つに記載の方法。
【請求項６８】
前記ネットワーク要素によって、前記モバイル・アンカー・ポイントから前記バインディング要求メッセージを受信するステップと、
前記ネットワーク要素によって、前記モバイル・ノード（ＭＮ）の前記ネットワーク要素への接続をチェックするステップと、
前記モバイル・ノード（ＭＮ）が前記ネットワーク要素に接続されている場合、ゼロよりも長い存続期間を有するバインディング更新を、又は前記モバイル・ノード（ＭＮ）が前記ネットワーク要素に接続されていない場合、ゼロに等しい存続期間を有するバインディング更新を、前記ネットワーク要素によって送信するステップとを、
更に有する請求項１から１６のいずれか１つに記載の方法。
【請求項６９】
前記チェックするステップが、前記ネットワーク要素によって、レイヤ２ポーリング・メッセージ又は近隣要請メッセージのうちの少なくとも１つを前記モバイル・ノード（ＭＮ）に送信するステップを有する請求項６７又は６８に記載の方法。
【請求項７０】
前記モバイル・アンカー・ポイントによって、前記モバイル・ノード（ＭＮ）から、又は前記ネットワーク要素から、前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの１つに関するバインディング登録解除メッセージを受信するステップと、
前記バインディング登録解除メッセージを受信した場合に、前記モバイル・アンカー・ポイントによって、前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの他の１つが前記モバイル・ノード（ＭＮ）の前記現行ＩＰアドレスである旨を決定するステップとを、
更に有する請求項５１から６９のいずれか１つに記載の方法。
【請求項７１】
前記バインディング登録解除メッセージを受信した場合に、前記バインディング要求メッセージの送信を停止するステップを更に有する請求項７０に記載の方法。
【請求項７２】
前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの１つに対する前記バインディング登録解除メッセージが、前記バインディング要求メッセージの送信後、及び応答メッセージの受信前に受信された場合、前記方法が、前記応答メッセージの受信を待つことなく、前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの他の１つが前記モバイル・ノード（ＭＮ）の前記現行ＩＰアドレスである旨を決定するステップを更に有する請求項７０に記載の方法。
【請求項７３】
モバイル・ノード（ＭＮ）のモビリティを管理するためのモバイル・アンカー・ポイントであって、
前記モバイル・ノード（ＭＮ）は第１のネットワークと第２のネットワークとの間を移動し、前記第１のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにモバイル・ノード（ＭＮ）ベースのモビリティ管理スキームを使用し、前記第２のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・アンカー・ポイントは、前記モバイル・ノード（ＭＮ）ベースのモビリティ管理スキーム及び前記ネットワーク・ベースのモビリティ管理スキームの両方を実施し、
前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の第１の位置に関する第１のメッセージを前記モバイル・ノード（ＭＮ）から受信するための受信手段であって、前記モバイル・ノード（ＭＮ）は第１のＩＰアドレスを有し、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の第２の位置に関する第２のメッセージを前記第２のネットワーク内のネットワーク要素から受信するための受信手段であって、前記モバイル・ノード（ＭＮ）は第２のＩＰアドレスを有する受信手段と、
前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するための送信手段とを有し、
前記受信手段は、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する応答メッセージを受信するように構成されており、
前記モバイル・アンカー・ポイントは、前記受信した応答メッセージに基づいて、前記第１及び第２のＩＰアドレスのうちのどちらが前記モバイル・ノード（ＭＮ）の現行ＩＰアドレスであるかを決定するための決定手段を更に有するモバイル・アンカー・ポイント。
【請求項７４】
モバイル・ノード（ＭＮ）のモビリティを管理するためのモバイル・アンカー・ポイントであって、前記モバイル・ノード（ＭＮ）は第１のネットワークと第２のネットワークとの間を移動し、前記第１及び第２のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・アンカー・ポイントは、前記ネットワーク・ベースのモビリティ管理スキームを実施し、
前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の第１の位置に関する第１のメッセージを前記第１のネットワーク内の第１のネットワーク要素から受信するための受信手段であって、前記モバイル・ノード（ＭＮ）は第１のＩＰアドレスを有し、前記第２のネットワーク内の前記モバイル・ノード（ＭＮ）の第２の位置に関する第２のメッセージを前記第２のネットワーク内の第２のネットワーク要素から受信するための受信手段であって、前記モバイル・ノード（ＭＮ）は第２のＩＰアドレスを有する受信手段と、
前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するための送信手段とを有し、
前記受信手段は、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する応答メッセージを受信するように構成されており、
前記モバイル・アンカー・ポイントは、前記受信した応答メッセージに基づいて、前記第１及び第２のＩＰアドレスのうちのどちらが前記モバイル・ノード（ＭＮ）の現行ＩＰアドレスであるかを決定するための決定手段を更に有するモバイル・アンカー・ポイント。
【請求項７５】
前記決定手段が、前記受信した応答メッセージが前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する肯定応答メッセージである場合、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つを前記モバイル・ノード（ＭＮ）の前記現行ＩＰアドレスとして決定するように構成された請求項７３又は７４に記載のモバイル・アンカー・ポイント。
【請求項７６】
前記肯定応答メッセージが、非ゼロの存続期間を有するバインディング更新メッセージである請求項７５に記載のモバイル・アンカー・ポイント。
【請求項７７】
前記決定手段が、前記受信した応答メッセージが前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する否定応答メッセージである場合、前記第１及び第２のＩＰアドレスのうちの前記少なくとも他の１つを前記モバイル・ノード（ＭＮ）の前記現行ＩＰアドレスとして決定するように構成された請求項７３又は７４に記載のモバイル・アンカー・ポイント。
【請求項７８】
前記第１及び第２のメッセージの受信間の時間間隔を測定するための測定手段を更に有し、
前記送信手段が、前記測定された時間間隔が所定の期間よりも短い場合、前記バインディング要求メッセージを、前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの少なくとも１つに送信するように構成された請求項７３から７７のいずれか１つに記載のモバイル・アンカー・ポイント。
【請求項７９】
前記受信手段が、前記モバイル・ノード（ＭＮ）、又は前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの１つに対する前記ネットワーク要素からバインディング登録解除メッセージを受信するように構成され、
前記決定手段が、前記バインディング登録解除メッセージを受信した場合に、前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの前記他の１つが、前記モバイル・ノード（ＭＮ）の前記現行ＩＰアドレスである旨を決定するように構成された請求項７３から７８のいずれか１つに記載のモバイル・アンカー・ポイント。
【請求項８０】
前記モバイル・アンカー・ポイントが、前記バインディング登録解除メッセージを受信した場合に、前記バインディング要求メッセージの送信を停止するように構成された請求項７９に記載のモバイル・アンカー・ポイント。
【請求項８１】
前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの１つに対する前記バインディング登録解除メッセージが、前記バインディング要求メッセージの送信後、及び応答メッセージの受信前に受信された場合、前記決定手段が、前記応答メッセージの受信を待つことなく、前記モバイル・ノード（ＭＮ）の前記第１及び第２のＩＰアドレスのうちの前記他の１つが前記モバイル・ノード（ＭＮ）の前記現行ＩＰアドレスである旨を決定するように構成された請求項７９に記載のモバイル・アンカー・ポイント。
【請求項８２】
前記モバイル・アンカー・ポイントが、請求項５７から６５のいずれか１つに記載の方法ステップを実行するように構成された、請求項７３から８１のいずれか１つに記載のモバイル・アンカー・ポイント。
【請求項８３】
第１のネットワークと第２のネットワークとの間を移動するモバイル・ノードであって、
前記第１のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにモバイル・ノード（ＭＮ）ベースのモビリティ管理スキームを使用し、前記第２のネットワークは、前記モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・ノード（ＭＮ）は、
前記第１のネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関するメッセージを前記モバイル・ノード（ＭＮ）に対するモバイル・アンカー・ポイントに送信するための送信手段であって、前記モバイル・ノード（ＭＮ）が第１のＩＰアドレスを有する送信手段と、
前記モバイル・ノード（ＭＮ）の前記第１のＩＰアドレスに対するバインディング要求メッセージを前記モバイル・アンカー・ポイントから受信するための受信手段とを有し、
前記送信手段は、前記受信したバインディング要求メッセージへの応答メッセージを前記モバイル・アンカー・ポイントに送信するように構成されたモバイル・ノード。
【請求項８４】
前記送信手段が、リフレッシュ・アドバイス・オプションがゼロに設定されたバインディング要求メッセージを受信した場合に、バインディング更新を前記モバイル・アンカー・ポイントに送信するように構成された請求項８３に記載のモバイル・ノード。
【請求項８５】
モバイル・ノード（ＭＮ）のモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用するネットワーク内のネットワーク要素であって、
前記ネットワーク内の前記モバイル・ノード（ＭＮ）の位置に関するメッセージを前記モバイル・ノード（ＭＮ）に対するモバイル・アンカー・ポイントに送信するための送信手段であって、前記モバイル・ノード（ＭＮ）はＩＰアドレスを有する送信手段と、
前記モバイル・ノード（ＭＮ）の前記ＩＰアドレスに対するバインディング要求メッセージを前記モバイル・アンカー・ポイントから受信するための受信手段とを有し、
前記送信手段は、前記受信したバインディング要求メッセージへの応答メッセージを前記モバイル・アンカー・ポイントに送信するように構成されたネットワーク要素。
【請求項８６】
前記送信手段が、リフレッシュ・アドバイス・オプションがゼロに設定されたバインディング要求メッセージを受信した場合に、バインディング更新を前記モバイル・アンカー・ポイントに送信するように構成された請求項８５に記載のネットワーク要素。
【請求項８７】
前記ネットワーク要素への前記モバイル・ノード（ＭＮ）の接続をチェックするためのチェック手段を更に有し、
前記ネットワーク要素が、前記モバイル・ノード（ＭＮ）が前記ネットワーク要素に接続されている場合、前記モバイル・アンカー・ポイントにバインディング更新を送信し、前記モバイル・ノード（ＭＮ）が前記ネットワーク要素に接続されていない場合、前記バインディング要求メッセージを破棄するように構成された請求項８５又は８６に記載のネットワーク要素。
【請求項８８】
前記ネットワーク要素への前記モバイル・ノード（ＭＮ）の接続をチェックするためのチェック手段を更に有し、
前記ネットワーク要素が、前記モバイル・ノード（ＭＮ）が前記ネットワーク要素に接続されている場合、ゼロよりも長い存続期間を有するバインディング更新を、又は前記モバイル・ノード（ＭＮ）が前記ネットワーク要素に接続されていない場合、ゼロに等しい存続期間を有するバインディング更新を送信するように構成された請求項８５又は８６に記載のネットワーク要素。
【請求項８９】
前記チェック手段が、レイヤ２ポーリング・メッセージ又は近隣要請メッセージのうちの少なくとも１つを前記モバイル・ノード（ＭＮ）に送信するように構成された請求項８７又は８８に記載のネットワーク要素。
【請求項９０】
通信相手ノードでのモバイルに対するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための方法であって、前記モバイル・ノードが、そのホーム・ネットワーク内に少なくとも１つのホーム・アドレス、及びフォーリン・ネットワーク内に少なくとも１つの気付けアドレスを有し、
前記通信相手ノードから、承認されたバインディング更新の受信に応答して、少なくとも１つのバインディング確認を前記モバイル・ノードに送信するステップであって、１つのバインディング確認が、そのホーム・ネットワーク内の前記モバイル・ノードのホーム・アドレスに向けて送られ、及び／又は１つのバインディング確認が、前記承認されたバインディング更新によって登録解除されたモバイル・ノードの気付けアドレスに向けて送られるステップと、
前記モバイル・ノードで、前記少なくとも１つのバインディング確認を受信するステップと、
前記モバイルに関する前記通信相手ノードにあるバインディング・キャッシュ・エントリがスプーフィングされているか否かを、前記少なくとも１つの受信されたバインディング確認に基づいて検出するステップとを、
有する方法。
【請求項９１】
１つの更なるバインディング確認が、前記承認されたバインディング更新内に示された前記モバイル・ノードの気付けアドレスに向けて送られる請求項９０に記載の方法。
【請求項９２】
前記通信相手ノードにおける前記モバイル・ノードに関する前記バインディング・キャッシュ・エントリがスプーフィングされているか否かを決定するステップが、前記モバイル・ノードによって送信された承認されたバインディング更新に関する前記少なくとも１つのバインディング確認が受信されるか否かを前記モバイル・ノードにおいて判断するステップを有する請求項９０又は９１に記載の方法。
【請求項９３】
前記通信相手ノードにおける前記モバイル・ノードに関する前記バインディング・キャッシュ・エントリがスプーフィングされているか否かを決定するステップが、前記少なくとも１つの受信したバインディング確認内のシーケンス番号が、確認されていない承認されたバインディング更新のシーケンス番号と一致するか否かを前記モバイル・ノードにおいて判断するステップを有する請求項９０から９２のいずれか１つに記載の方法。
【請求項９４】
前記モバイル・ノードが前記ホーム・アドレスを登録した前記ホーム・エージェントがダウンした場合、バインディング確認が、前記承認されたバインディング更新によって登録解除された前記モバイル・ノードの気付けアドレスに向けて送られる請求項９０から９３のいずれか１つに記載の方法。
【請求項９５】
前記モバイル・ノードが登録された前記ホーム・エージェントがダウンしたことを検出するステップと、前記ホーム・エージェントがダウンしていることを前記モバイル・ノードによって前記通信相手ノードに通知するステップとを更に有する請求項９０から９４のいずれか１つに記載の方法。
【請求項９６】
通信相手ノードでのモバイルに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための方法であって、前記モバイル・ノードはフォーリン・ネットワーク内に少なくとも１つの気付けアドレスを有し、
前記モバイル・ノードの気付けアドレスを使用して、前記通信相手ノードによって前記モバイル・ノードにバインディング・テスト・メッセージを送信することによって、バインディング・テストを実行するステップと、
前記バインディング・テストに基づいて、前記通信相手ノードにおいてスプーフィングされたバインディング・キャッシュ・エントリを検出するステップとを、
有する方法。
【請求項９７】
前記モバイル・ノードが、しきい値期間中に前記通信相手ノードからバインディング・テスト・メッセージを受信しない場合、前記モバイル・ノードは、前記通信相手ノードにおける前記モバイル・ノードに関するバインディング・キャッシュ・エントリがスプーフィングされていることを検出する請求項９６に記載の方法。
【請求項９８】
前記バインディング・テスト・メッセージが、前記通信相手ノードによって送信された送信要請されていないメッセージである請求項９６又は９７に記載の方法。
【請求項９９】
前記バインディング・テスト・メッセージが定期的に送信される請求項９６から９８のいずれか１つに記載の方法。
【請求項１００】
前記通信相手ノードが前記モバイル・ノードに一時的にデータ・パケットを送信しない場合、前記バインディング・テスト・メッセージが送信される請求項９６から９９のいずれか１つに記載の方法。
【請求項１０１】
前記バインディング・テストが、前記通信相手ノードに前記バインディング・テスト・メッセージの送信を要求するために、少なくとも１つのバインディング・テスト要求メッセージを前記モバイル・ノードから前記通信相手ノードに送信するステップを更に有する請求項９６に記載の方法。
【請求項１０２】
１つ又は複数のプローブ・メッセージに対する応答が前記モバイル・ノードによって前記通信相手ノードから受信されない場合、前記通信相手ノードにおいてスプーフィングされたバインディング・キャッシュ・エントリが前記モバイル・ノードによって検出される請求項１０１に記載の方法。
【請求項１０３】
前記バインディング・テストがＩＣＭＰプロトコルのメッセージを使用する請求項１０１又は１０２に記載の方法。
【請求項１０４】
前記バインディング・テスト・メッセージがバインディング確認メッセージである請求項９６から１０３のいずれか１つに記載の方法。
【請求項１０５】
前記通信相手ノードにおいてスプーフィングされたバインディング・キャッシュ・エントリの検出に応じて、
・前記モバイル・ノードに暗号情報を提供するリターン・ルータビリティ手順を前記通信相手ノードとの間で実行し、その後、前記スプーフィングされたバインディング・キャッシュ・エントリを修正するために、前記リターン・ルータビリティ手順の実行によって取得された前記暗号情報を使用することによって承認されたバインディング更新を、前記通信相手ノードに送信する対応策
・前記スプーフィングされたバインディング・キャッシュ・エントリに関して前記通信相手ノードに通知する対応策
・モバイル・ノードと通信相手ノードとの間でデータを交換する際に、ルート最適化を使用しない対応策
のうちの少なくとも１つを前記モバイル・ノードによって実行するステップを更に有する請求項９０から１０４のいずれか１つに記載の方法。
【請求項１０６】
前記リターン・ルータビリティ手順が、永続キー生成トークンを決定するステップを有する請求項１０５に記載の方法。
【請求項１０７】
前記スプーフィングされたバインディング・キャッシュ・エントリに関して前記通信相手ノードに通知する場合、前記通信相手ノードは、前記スプーフィングされたバインディング・キャッシュ・エントリ内の前記気付けアドレスを登録するための更なるバインディング更新をブロックする、及び／又は前記スプーフィングされたバインディング・キャッシュ・エントリ内の前記気付けアドレスと類似のプレフィックスを有する気付けアドレスを登録するための更なるバインディング更新をブロックする請求項１０５又は１０６に記載の方法。
【請求項１０８】
前記スプーフィングされたバインディング・キャッシュ・エントリについて前記通信相手ノードに通知するために、前記モバイル・ノードのホーム・エージェントによって、前記モバイル・ノードから前記ホーム・エージェントを介して前記通信相手ノードに送信されたメッセージを認証するステップを更に有する請求項１０５から１０７のいずれか１つに記載の方法。
【請求項１０９】
前記モバイル・ノードによって、前記モバイル・ノード及び前記通信相手ノードに知られた少なくとも１つの永続キー生成トークンに基づいて、メッセージ認証コードを決定するステップを更に有する請求項９０から１０８のいずれか１つに記載の方法。
【請求項１１０】
前記通信相手ノードに送信された承認されたバインディング更新に対して前記メッセージ認証コードを含めるステップを更に有し、
前記承認されたバインディング更新がフラグを更に有し、前記フラグが設定された場合には、前記永続キー生成トークンに基づいて前記メッセージ認証コードの妥当性を検査することを前記通信相手ノードに指示する請求項１０９に記載の方法。
【請求項１１１】
前記通信相手ノードから、気付けキー生成トークンを含むメッセージを前記モバイル・ノードに送信するステップを更に有し、前記メッセージが、現在前記通信相手ノードに登録されている前記モバイル・ノードの気付けアドレスに向けて送られ、
少なくとも前記永続キー生成トークンに基づいて決定される前記メッセージ認証コードが、前記モバイル・ノードにより、前記気付けキー生成トークンを使用して決定される請求項１０９又は１１０のいずれか１つに記載の方法。
【請求項１１２】
前記通信相手ノードにおいて前記モバイル・ノードに関する気付けアドレスを登録するために、承認されたバインディング更新を前記モバイル・ノードから前記通信相手ノードに送信するステップを更に有し、
前記承認されたバインディング更新が、メッセージ認証コードと、設定された場合には、永続キー生成トークンを決定することを前記通信相手ノードに指示するフラグとを有する請求項９０から１０８のいずれか１つに記載の方法。
【請求項１１３】
前記永続キー生成トークンの有効性が有限である請求項１０９から１１２のいずれか１つに記載の方法。
【請求項１１４】
前記通信相手ノードによって決定される前記永続キー生成トークンが、前記モバイル・ノードによって決定される永続キー生成トークンと同一である請求項１０９から１１２のいずれか１つに記載の方法。
【請求項１１５】
前記永続キー生成トークンの決定が、前記モバイル・ノードのホーム・アドレスに向かって送られる前記通信相手ノードからのメッセージで前記モバイル・ノードに提供されるキー生成トークンであるホーム・キー生成トークン、及び／又は前記モバイル・ノードの気付けアドレスに向かって送られる前記通信相手ノードからのメッセージで前記モバイル・ノードに提供されるキー生成トークンである気付けキー生成トークンのうちの少なくとも１つに基づく請求項１０９から１１２のいずれか１つに記載の方法。
【請求項１１６】
前記永続キー生成トークンの決定が、リターン・ルータビリティ手順のホーム・アドレス・テスト及び／又は気付けアドレス・テストにおいて、前記通信相手ノードによって提供される少なくとも１つのキー生成トークンに基づく請求項９０から１１５のいずれか１つに記載の方法。
【請求項１１７】
前記モバイル・ノードのホーム・アドレスに向けて送られる前記通信相手ノードからのメッセージで前記モバイル・ノードに提供されるキー生成トークンであるホーム・キー生成トークン、及び、前記モバイル・ノードの気付けアドレスに向けて送られる前記通信相手ノードからのメッセージで前記モバイル・ノードに提供されるキー生成トークンである気付けキー生成トークンのうちの少なくとも１つに基づいて、前記モバイル・ノードで前記メッセージ認証コードを決定するステップを更に有する請求項９０から１１６のいずれか１つに記載の方法。
【請求項１１８】
前記モバイル・ノード及び／又は前記通信相手ノードで永続キー生成トークンを決定するステップを更に有する請求項９０から１１７のいずれか１つに記載の方法。
【請求項１１９】
前記永続キー生成トークンが、前記モバイル・ノードからの承認されたバインディング更新に対する少なくとも１つのバインディング確認の受信に応じて、前記モバイル・ノードで決定される請求項１１８に記載の方法。
【請求項１２０】
前記永続キー生成トークンが、前記モバイル・ノードからの承認されたバインディング更新の受信に応じて、前記通信相手ノードで決定され、前記承認されたバインディング更新が、設定された場合に、永続キー生成トークンを決定することを前記通信相手ノードに指示するフラグを有する請求項１１８又は１１９に記載の方法。
【請求項１２１】
通信相手ノードでモバイル・ノードの気付けアドレスを登録するための方法であって、
前記モバイル・ノード及び前記通信相手ノードによって気付けアドレス・テストを実行するステップであって、これにより、前記モバイル・ノードに気付けキー生成トークンを提供するステップと、
承認されたバインディング更新を前記モバイル・ノードから前記通信相手ノードに送信するステップであって、前記承認されたバインディング更新が、前記気付けキー生成トークンと、前記モバイル・ノード及び前記通信相手ノードに知られた永続キー生成トークンとに基づいて、前記モバイル端末によって決定されたメッセージ認証コードを含むステップとを、
有する方法。
【請求項１２２】
前記永続キー生成トークンが、前記ホーム・エージェントがダウンする前の、最新の成功したホーム・アドレス・テストの前記ホーム・キー生成トークンである請求項１２１に記載の方法。
【請求項１２３】
前記通信相手ノードによって、前記承認されたバインディング更新に関する少なくとも１つのバインディング確認を前記モバイル・ノードに送信するステップを更に有し、少なくとも１つのバインディング確認が、前記承認されたバインディング更新によって登録解除された前記気付けアドレスに向けて送られる請求項１２１又は１２２に記載の方法。
【請求項１２４】
前記ホーム・エージェントがダウンしたことを前記通信相手ノードが検出するか、又は前記モバイル・ノードによって通知された場合、通信相手ノードが、少なくとも１つのバインディング確認を、前記承認されたバインディング更新によって登録解除された前記気付けアドレスに向けて送る請求項１２３に記載の方法。
【請求項１２５】
・前記モバイル・ノードによって前記ホーム・エージェントに送信された承認されたバインディング更新に関して、前記モバイル・ノードでバインディング確認が受信されないことを検出するメカニズム
・ＩＰｓｅｃデッド・ピア検出手順を使用するメカニズム
・前記ホーム・エージェントに、又はこのホーム・エージェントに登録されたホーム・アドレスに送信された１つ又は複数のプローブ・メッセージへの応答が受信されないことを、前記モバイル・ノード又は前記通信相手ノードによって検出するメカニズム
のうちの１つ、又はこれらの組合せによって、前記モバイル・ノードが登録されたホーム・エージェントがダウンしたことを検出するステップを更に有する請求項１２１から１２４のいずれか１つに記載の方法。
【請求項１２６】
前記通信相手ノードに通知メッセージを送信することによって、前記モバイル・ノードが登録されている前記ホーム・エージェントがダウンしたことを、前記モバイル・ノードから前記通信相手ノードに通知するステップを更に有する請求項１２１から１２５のいずれか１つに記載の方法。
【請求項１２７】
前記通知メッセージが、ホーム・アドレス・テスト及び気付けアドレス・テストを含むリターン・ルータビリティ手順で以前に決定されたバインディング管理キーを使用して、前記モバイル・ノードによって承認される請求項１２６に記載の方法。
【請求項１２８】
前記通知メッセージが、前記モバイル・ノードによって前記通信相手ノードに送信される承認されたバインディング更新である請求項１２６又は１２７に記載の方法。
【請求項１２９】
請求項９０から１２０のいずれか１つに記載の方法のステップを更に有する請求項１２１から１２８のいずれか１つに記載の方法。
【請求項１３０】
通信相手ノードでのモバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するためのモバイル・ノードであって、前記モバイル・ノードには、そのホーム・ネットワーク内の少なくとも１つのホーム・アドレス、及びフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられ、
前記通信相手ノードによって送信された少なくとも１つのバインディング確認を受信するための受信機であって、１つのバインディング確認がそのホーム・ネットワーク内の前記モバイル・ノードのホーム・アドレスに向けて送られ、及び／又は１つのバインディング確認が前記承認されたバインディング更新によって登録解除されたモバイル・ノードの気付けアドレスに向けて送られる受信機と、
少なくとも１つの受信されたバインディング確認に基づいて、前記モバイルに関する前記通信相手ノードでのバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための処理ユニットとを、
有するモバイル・ノード。
【請求項１３１】
請求項９０から１２０のいずれか１つに記載の方法のステップを実行するか又はこれらに関与するように構成された手段を更に有する請求項１３０に記載のモバイル・ノード。
【請求項１３２】
モバイル・ノードに対するバインディング・キャッシュ・エントリを維持するための通信相手ノードであって、前記モバイル・ノードには、そのホーム・ネットワーク内の少なくとも１つのホーム・アドレス及びフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられ、
承認されたバインディング更新の受信に応じて、少なくとも１つのバインディング確認を前記モバイル・ノードに送信するための通信ユニットであって、１つのバインディング確認がそのホーム・ネットワーク内の前記モバイル・ノードのホーム・アドレスに向けて送られ、及び／又は１つのバインディング確認が前記承認されたバインディング更新によって登録解除されたモバイル・ノードの気付けアドレスに向けて送られる通信ユニットを有する通信相手ノード。
【請求項１３３】
請求項９０から１２０のいずれか１つに記載の方法のステップを実行するか又はこれらに関与するように構成された手段を更に有する請求項１３２に記載の通信相手ノード。
【請求項１３４】
通信相手ノードでのモバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するためのモバイル・ノードであって、前記モバイル・ノードには、フォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられ、
前記モバイル・ノードの気付けアドレスに向けて送られたバインディング・テスト・メッセージを前記通信相手ノードから受信することを含むバインディング・テストを実行するための通信手段と、
前記バインディング・テストに基づいて前記通信相手ノードでスプーフィングされたバインディング・キャッシュ・エントリを検出するための処理ユニットとを、
有するモバイル・ノード。
【請求項１３５】
請求項９６から１２０のいずれか１つに記載の方法のステップを実行するか又はこれらに関与するように構成された手段を更に有する請求項１３４に記載のモバイル・ノード。
【請求項１３６】
モバイル・ノードに対するバインディング・キャッシュ・エントリを維持するための通信相手ノードであって、前記モバイル・ノードには、フォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられ、
バインディング・テストの一部として前記モバイル・ノードから少なくとも１つのバインディング・テスト要求メッセージを受信するための受信機と、
前記バインディング・テストの一部として、少なくとも１つのバインディング・テスト要求メッセージに応答して、前記モバイル・ノードの気付けアドレスに向けて送られたバインディング・テスト・メッセージを送信するための送信機とを、
有する通信相手ノード。
【請求項１３７】
請求項９６から１２０のいずれか１つに記載の方法のステップを実行するか又はこれらに関与するように構成された手段を更に有する請求項１３６に記載の通信相手ノード。
【請求項１３８】
通信相手ノードで気付けアドレスを登録するためのモバイル・ノードであって、
前記モバイル・ノード及び前記通信相手ノードによって気付けアドレス・テストを実行し、それによって前記モバイル・ノードに気付けキー生成トークンを提供するための通信ユニットを有し、
前記通信ユニットが、承認されたバインディング更新を前記モバイル・ノードから前記モバイル・ノードへ送信するように動作可能であり、前記承認されたバインディング更新が、前記気付けキー生成トークンと、前記モバイル・ノード及び前記通信相手ノードに知られた永続キー生成トークンとに基づいて、前記モバイル端末によって決定されたメッセージ認証コードを有するモバイル・ノード。
【請求項１３９】
請求項１２１から１２９のいずれか１つに記載の方法のステップを実行するか又はこれらに関与するように構成された手段を更に有する請求項１３８に記載のモバイル・ノード。
【請求項１４０】
モバイル・ノードに対する気付けアドレスを登録するための通信相手ノードであって、
前記モバイル・ノード及び前記通信相手ノードによって気付けアドレス・テストを実行し、それによって前記モバイル・ノードに気付けキー生成トークンを提供する通信ユニットを有し、
前記通信ユニットは、承認されたバインディング更新を前記モバイル・ノードから前記モバイル・ノードへ受信するように動作可能であり、前記承認されたバインディング更新は、前記気付けキー生成トークンと、前記モバイル・ノード及び前記通信相手ノードに知られた永続キー生成トークンとに基づいて、前記モバイル端末によって決定されたメッセージ認証コードを有する通信相手ノード。
【請求項１４１】
請求項１２１から１２９のいずれか１つに記載の方法のステップを実行するか又はこれらに関与するように構成された手段を更に有する請求項１４０に記載の通信相手ノード。
【請求項１４２】
請求項１３０、１３１、１３４、１３５、１３８、又は１３９に記載のモバイル・ノードと、請求項１３２、１３３、１３６、１３７、１４０、又は１４１に記載の通信相手ノードとを有するモバイル通信システム。
【請求項１４３】
モバイル・ノードには、そのホーム・ネットワーク内の少なくとも１つのホーム・アドレス、及びフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられる場合に、通信相手ノードにおける前記モバイル・ノードに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かを前記モバイル・ノードに検出させる命令を格納するコンピュータ読み取り可能媒体であって、
前記モバイル・ノードのプロセッサによって実行された場合、
前記通信相手ノードによって送信された少なくとも１つのバインディング確認のうちの少なくとも１つを受信するステップであって、１つのバインディング確認が、そのホーム・ネットワーク内のモバイル・ノードのホーム・アドレスに向けて送られ、及び／又は１つのバインディング確認が、承認されたバインディング更新によって登録解除された気付けアドレスに向けて送られるステップと、
少なくとも１つの受信されたバインディング確認に基づいて、前記通信相手ノードでの前記モバイルに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するステップと、
によって、通信相手ノードでの前記モバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされているか否かを前記モバイル・ノードに検出させる命令を格納するコンピュータ読み取り可能媒体。
【請求項１４４】
前記モバイル・ノードの前記プロセッサによって実行された場合、請求項９０から１２０のいずれか１つに記載の方法のステップを実行するか又はこれらに関与するように、前記モバイル・ノードに実行させる命令を更に格納する請求項１４３に記載のコンピュータ読み取り可能媒体。
【請求項１４５】
モバイル・ノードには、そのホーム・ネットワーク内の少なくとも１つのホーム・アドレス、及びフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられる場合に、通信相手ノードに前記モバイル・ノードに対するバインディング・キャッシュ・エントリを維持させる命令を格納するコンピュータ読み取り可能媒体であって、
通信相手ノードのプロセッサによって実行された場合、
承認されたバインディング更新の受信に応じて、少なくとも１つのバインディング確認を前記モバイル・ノードに送信するステップであって、１つのバインディング確認が、そのホーム・ネットワーク内の前記モバイル・ノードのホーム・アドレスに向けて送られ、及び／又は１つのバインディング確認が、前記承認されたバインディング更新によって登録解除されたモバイル・ノードの気付けアドレスに向けて送られるステップ、
によって、前記通信相手ノードに前記モバイル・ノードに対するバインディング・キャッシュ・エントリを維持させる命令を格納するコンピュータ読み取り可能媒体。
【請求項１４６】
前記通信相手ノードの前記プロセッサによって実行された場合、請求項９０から１２０のいずれか１つに記載の方法のステップを実行するか又はこれらに関与するように、前記通信相手ノードに実行させる命令を更に格納する請求項１４５に記載のコンピュータ読み取り可能媒体。
【請求項１４７】
モバイル・ノードのプロセッサによって実行された場合、
前記モバイル・ノードの気付けアドレスに向けて送られたバインディング・テスト・メッセージを前記通信相手ノードから受信することを含むバインディング・テストを実行するステップと、
前記バインディング・テストに基づいて、前記通信相手ノードでスプーフィングされたバインディング・キャッシュ・エントリを検出するステップと、
によって、通信相手ノードでの前記モバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされているか否かを前記モバイル・ノードに検出させる命令を格納するコンピュータ読み取り可能媒体であって、前記モバイル・ノードには、フォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられるコンピュータ読み取り可能媒体。
【請求項１４８】
前記モバイル・ノードの前記プロセッサによって実行された場合、請求項９６から１２０のいずれか１項に記載の方法のステップを実行するか又はこれらに関与するように、前記モバイル・ノードに実行させる命令をさらに格納する、請求項１４７に記載のコンピュータ読み取り可能媒体。
【請求項１４９】
通信相手ノードのプロセッサによって実行された場合、
少なくとも１つのバインディング・テスト要求メッセージをバインディング・テストの一部として前記モバイル・ノードから受信するステップと、
前記少なくとも１つのバインディング・テスト要求メッセージに応答して、バインディング・テスト・メッセージを、前記モバイル・ノードの気付けアドレスに向けて、前記バインディング・テストの一部として送信するステップと、
によって、前記通信相手ノードにモバイル・ノードに対するバインディング・キャッシュ・エントリを維持させる命令を格納するコンピュータ読み取り可能媒体であって、前記モバイル・ノードには、フォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられるコンピュータ読み取り可能媒体。
【請求項１５０】
前記通信相手ノードの前記プロセッサによって実行された場合、請求項９６から１２０のいずれか１項に記載の方法のステップを実行するか又はこれらに関与するように、前記通信相手ノードに実行させる命令をさらに格納する、請求項１４９に記載のコンピュータ読み取り可能媒体。
【請求項１５１】
モバイル・ノードのプロセッサによって実行された場合、
モバイル・ノード及び通信相手ノードによって気付けアドレス・テストを実行し、それによって、気付けキー生成トークンをモバイル・ノードに提供するステップと、
前記モバイル・ノードから前記モバイル・ノードへと承認されたバインディング更新を送信するステップであって、前記承認されたバインディング更新は、前記気付けキー生成トークンと、前記モバイル・ノード及び前記通信相手ノードに知られた永続キー生成トークンとに基づいて、前記モバイル端末によって決定されたメッセージ認証コードを含むステップと、
によって、通信相手ノードでの気付けアドレスをモバイル・ノードに登録させる命令を格納するコンピュータ読み取り可能媒体。
【請求項１５２】
前記モバイル・ノードの前記プロセッサによって実行された場合、請求項１２１から１２９のいずれか１項に記載の方法のステップを実行するか又はこれらに関与するように、前記モバイル・ノードに実行させる命令をさらに格納する、請求項１５１に記載のコンピュータ読み取り可能媒体。
【請求項１５３】
通信相手ノードのプロセッサによって実行された場合、
モバイル・ノード及び通信相手ノードによって気付けアドレス・テストを実行し、それによって、気付けキー生成トークンを前記モバイル・ノードに提供するステップと、
前記モバイル・ノードから前記モバイル・ノードへの承認されたバインディング更新を受信するステップであって、前記承認されたバインディング更新は、前記気付けキー生成トークンと、前記モバイル・ノード及び前記通信相手ノードに知られた永続キー生成トークンとに基づいて、前記モバイル端末によって決定されたメッセージ認証コードを含むステップと、
によって、モバイル・ノードに対する気付けアドレスを通信相手ノードに登録させる命令を格納するコンピュータ読み取り可能媒体。
【請求項１５４】
前記通信相手ノードの前記プロセッサによって実行された場合、請求項１２１から１２９のいずれか１項に記載の方法のステップを実行するか又はこれらに関与するように、前記通信相手ノードに実行させる命令をさらに格納する、請求項１５３に記載のコンピュータ読み取り可能媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、第１の態様によれば、パケット・ベースの通信ネットワークにおけるモバイル・ノードのモビリティ管理に関し、より詳細には、モバイル・ノードのモビリティを管理するためにネットワーク・ベース及びホスト・ベースのモビリティ管理スキームを実施するローカル・モビリティ・アンカーで、セキュリティを向上させるための方法に関する。本発明は、危険にさらされたネットワーク要素（compromised network element）がモバイル・ノードを宛先とするトラフィックを宛先変更しようとすることを検出するための方法に関する。本発明は、ネットワーク内のネットワーク要素へのモバイル・ノードの接続を検証するための方法を提案する。また、本発明は、この方法に関与するローカル・モビリティ・アンカー、モバイル・ノード、及びネットワーク要素も提供する。
【０００２】
本発明は、第２の態様によれば、パケット・ベースの通信ネットワークにおけるネットワーク・ベース及びホスト・ベースのモビリティ管理の相互動作に関する。本発明は、ネットワーク・ベース及びホスト・ベースの混合モビリティ管理においてモビリティ・アンカー・ポイントでの競合状態を解決するため、並びにモビリティ・アンカー・ポイントが２つのバインディング更新を受信した際に、常に最も新しいバインディング更新を受け入れることを確実にするための方法を提供する。
【０００３】
本発明は、第３の態様によれば、通信相手ノードでモバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされていたか否かを検出するための方法に関する。さらに、本発明の第３の態様は、通信相手ノードでモバイル・ノードの気付けアドレスを登録するための方法にも関する。本発明の第３の態様は、これらの方法に関与するモバイル・ノード及び通信相手ノード、並びにモバイル・ノード及び通信相手ノードを備えるモバイル通信システムも提供する。
【背景技術】
【０００４】
モバイル通信システムは、インターネット・プロトコル（ＩＰ）ベースのネットワークの方向へさらに進化している。インターネットは多くの相互接続されたネットワークからなり、ここでは音声及びデータが、部片単位、いわゆるパケット単位で、１つの端末から他の端末へと伝送される。それらのパケットは、コネクションレス式で、ルータによって宛先にルーティングされる。従って、パケットはＩＰヘッダ及びペイロード情報からなり、ヘッダはとりわけソース及び宛先ＩＰアドレスを備える。スケーラビリティのために、大規模ＩＰネットワークは通常サブネットに分割され、階層アドレッシングスキームを使用する。従って、ＩＰアドレスは対応する端末を識別するだけでなく、さらにこの端末に関するロケーション情報（現在のサブネット）を含む。ルーティング・プロトコルによって提供される追加の情報を使用して、ネットワーク内のルータは、特定の宛先に向かって次のルータを識別することができる。
【０００５】
端末が、以下でモバイル・ノード（ＭＮ）と呼ばれるモバイルであり、サブネット間を移動する場合、階層アドレッシングスキームにより、そのＩＰアドレスをトポロジー的に正しいアドレスに変更しなければならない。しかし、ＴＣＰ接続などの上位層における接続が、通信ノードのＩＰアドレス（及びポート）で定義されるため、ノードのうちの１つが、例えば移動によってそのＩＰアドレスを変更した場合、接続は切断される。
【０００６】
Ｍｏｂｉｌｅ  ＩＰｖ６（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで入手可能であり、参照により本明細書に組み込むものとする、Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏの、「Ｍｏｂｉｌｉｔｙ  Ｓｕｐｐｏｒｔ  ｉｎ  ＩＰｖ６」ＩＥＴＦ  ＲＦＣ  ３７７５、２００４年６月を参照のこと）は、上位層及びアプリケーションに関してトランスペアレントに、すなわち上位層接続を切断することなく、モバイル・ノードがサブネット間を移動できるようにするＩＰベースのモビリティ・プロトコルである。従って、モバイル・ノードは、気付けアドレス（ＣｏＡ）及びホーム・アドレス（ＨｏＡ）という２つの構成されたＩＰアドレスを有する。モバイル・ノードの上位層は、宛先端末に関連付けられた、以下、通信相手ノード（ＣＮ）と呼ぶ通信パートナーと通信するために、ホーム・アドレスを使用する。このアドレスは変更されることなく、モバイル・ノードを識別する働きをする。トポロジー的に言えば、これはモバイル・ノードのホーム・ネットワーク（ＨＮ）に属する。これに対して、気付けアドレスは、結果としてサブネットが変更されることになるあらゆる動きで変更され、ルーティング・インフラストラクチャのロケータとして使用される。トポロジー的に言えば、これはモバイル・ノードが現在接続されているネットワークに属する。ホーム・リンク上に位置するホーム・エージェント（ＨＡ）のセットのうちの１つが、モバイル・ノードの気付けアドレスのモバイル・ノードのホーム・アドレスへのマッピングを維持し、モバイル・ノードに対する着信トラフィックをその現在の位置へと宛先変更する。単一のホーム・エージェントの代わりにＨＡのセットを有する理由は、冗長性及びロード・バランシングである。
【０００７】
Ｍｏｂｉｌｅ  ＩＰｖ６は、現在、双方向トンネリング及びルート最適化という２つの動作モードを定義している。図１は、双方向トンネリングの使用を例証している。通信相手ノードによって送信され、モバイル・ノードのホーム・アドレスにアドレス指定されたデータ・パケットは、ホーム・ネットワーク内のホーム・エージェントによってインターセプトされ、モバイル・ノードの気付けアドレスにトンネリングされる。モバイル・ノードによって送信されたデータ・パケットは、ホーム・エージェントに逆トンネリングされ、ここでパケットをカプセル化解除し、それらを通信相手ノードに送信する（逆トンネリングとは、モバイル・ノードの気付けアドレスから始まりホーム・エージェントで終わるトンネルを介して、パケットがモバイル・ノードによって送信されることを意味する）。
【０００８】
この動作では、モバイル・ノードの気付けアドレスがホーム・エージェントのみに通知される。従って、モバイル・ノードはバインディング更新（ＢＵ）メッセージをホーム・エージェントに送信する。バインディング更新メッセージは、ＩＰｓｅｃセキュリティアソシエーションを介して送信されることから、データ源の認証及び整合性保護を提供するために暗号によって保護される。これには、モバイル・ノード及びホーム・エージェントが秘密鍵を共有している必要がある。従ってホーム・エージェントは、対応する共有鍵で暗号によって保護されたモバイル・ノードのホーム・アドレスに対するバインディング更新メッセージのみを受け入れる。
【０００９】
モバイル・ノードがホーム・ネットワークから遠く、通信相手ノードがモバイル・ノードに近い場合、通信パスが不必要に長くなり、結果として非効率なルーティング及び大きなパケット遅延が生じることが欠点である。ルート最適化モードは、通信相手ノードとモバイル・ノードとの間の直接パスを使用することによって、双方向トンネリング・モードの非効率性を防ぐことができる。モバイル・ノードは、バインディング更新メッセージを通信相手ノードに送信し、ここでデータ・パケットをモバイル・ノードに直接送信することができる（直接パス上でパケットを送信するために、タイプ２のルーティング・ヘッダが使用される）。もちろん、通信相手ノードはＭｏｂｉｌｅ  ＩＰｖ６のルート最適化サポートを実施しなければならない。
【００１０】
通信相手ノードへのバインディング更新メッセージを認証するために、モバイル・ノード及び通信相手ノードはいわゆるリターン・ルータビリティ手順を実行し、この手順は、それぞれホーム・アドレス・テスト及び気付けアドレス・テストを使用してホーム・アドレス及び気付けアドレスでモバイル・ノードの到達可能性をテストし、共有セッション鍵を生成する。その後、モバイル・ノードは、通信相手ノードに送信されたそのバインディング更新を認証するためのセッション鍵を使用して、その気付けアドレスを通信相手ノードに登録することができる。
【００１１】
モビリティ管理信号がホスト／クライアントとホーム・エージェントとの間で送信されるため、モバイルＩＰはホスト・ベース又はクライアント・ベースのプロトコルである。従って、モバイルＩＰは、時折クライアント・モバイルＩＰ（ＣＭＩＰ）とも呼ばれる。普及しつつある他の手法は、ＩＰモビリティ管理に関するネットワーク・ベースの手法であり、すなわち、訪問先のアクセス・ネットワーク内のエンティティがモバイル・ノードのモビリティを管理し、位置更新をホーム・エージェントに信号送信する。ネットワーク・ベースのモビリティ管理には、無線での信号オーバヘッドが少ないこと、及び単純なＩＰノード（すなわち、非ＣＭＩＰ可能ノード）に関するモビリティ・サポートなどの幾つかの利点がある。欠点は、訪問先のアクセス・ネットワークからのサポートが必要なことである。
【００１２】
ＩＥＴＦは、モバイルＩＰプロトコルに基づいて局所的モビリティ管理に関するこうした手法に取り組んでいる。ネットワーク・エンティティはモバイル・ノードに代わってプロキシとして動作しているため、プロトコルはプロキシ・モバイルＩＰ（ＰＭＩＰ）と呼ばれる。ＰＭＩＰｖ６と呼ばれるＩＰｖ６の変形（例えば、Ｓ．Ｇｕｎｄａｖｅｌｌｉ、Ｋ．Ｌｅｕｎｇ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、Ｋ．Ｃｈｏｗｄｈｕｒｙ、Ｂ．Ｐａｔｉｌによる、Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６、ｄｒａｆｔ−ｓｇｕｎｄａｖｅ−ｍｉｐ６−ｐｒｏｘｙｍｉｐ６−０２、２００７年３月を参照のこと）、及びＰＭＩＰｖ４と呼ばれるＩＰｖ４の変形（例えば、Ｋ．Ｌｅｕｎｇ、Ｇ．Ｄｏｍｍｅｔｙ、Ｐ．Ｙｅｇａｎｉ、Ｋ．Ｃｈｏｗｄｈｕｒｙの、「Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  ｕｓｉｎｇ  Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ４」、ｄｒａｆｔ−ｌｅｕｎｇ−ｍｉｐ４−ｐｒｏｘｙ−ｍｏｄｅ−０２．ｔｘｔ、２００７年１月を参照のこと）がある。
【００１３】
ＰＭＩＰｖ６は、モバイル・ノードが現在接続されており、モバイル・ノードに代わってバインディング更新（ＢＵ）メッセージを送信する、通常はアクセス・ルータ（ＡＲ）と同じ場所に配置されるプロキシ・モバイル・エージェント（ＰＭＡ）又はモバイル・アクセス・ゲートウェイ（ＭＡＧ）と呼ばれる新しい論理エンティティを導入する。ＰＭＩＰホーム・エージェントは、拡張ＣＭＩＰホーム・エージェントであり、ローカル・モビリティ・アンカー（ＬＭＡ）と呼ばれる。モバイル・アクセス・ゲートウェイによって送信されるバインディング更新メッセージはフラグでマーク付けされるため、ローカル・モビリティ・アンカーによってプロキシ・バインディング更新（ＰＢＵ）メッセージとして識別可能であり、モバイル・ノードによって送信されるバインディング更新メッセージ（すなわち、ＣＭＩＰ信号メッセージ）と区別可能である。
【００１４】
さらに、ＰＢＵメッセージはネットワーク・アクセス識別子（ＮＡＩ）オプション、ホーム・プレフィックス・オプション、及びタイムスタンプ・オプションを含む。ＮＡＩオプションは、「ユーザ名＠範囲」などの形を有し、モバイル・ノードを識別するために使用されるモバイル・ノードのネットワーク・アクセス識別子［ＲＦＣ４２８２］を含む。ホーム・プレフィックス・オプションは、ホーム・アドレス又はモバイル・ノードのホーム・プレフィックスを含む。ＰＭＩＰｖ６によって、２つのアドレッシングモデルがサポートされる。いわゆるｐｅｒ−ＭＮ−ｐｒｅｆｉｘモデルでは、あらゆるモバイル・ノードが固有のホーム・プレフィックスを有し、これをホーム・アドレスの代わりにＰＢＵメッセージで使用することができる。共有プレフィックス・モデルでは、モバイル・ノードは、複数のモバイル・ノード間で共有されるプレフィックスからのホーム・アドレスを使用する。タイムスタンプ・オプションは、ＰＢＵが送信された時間を含み、ＰＢＵの「新しさ」を識別してＰＢＵメッセージの順序を修正するために、ローカル・モビリティ・アンカーによって使用される。ＰＢＵメッセージ中のシーケンス番号値はＰＭＩＰｖ６によって使用されず、ローカル・モビリティ・アンカーには無視される。ＰＭＡはＰＢＵに使用するシーケンス番号を同期化しないため、ＰＢＵメッセージのシーケンス番号値は、ＰＢＵのシーケンスを決定するためにホーム・エージェントによって考慮されない。
【００１５】
モバイル・ノードは、ハンドオーバ後、又は電源投入後、新しいモバイル・アクセス・ゲートウェイに接続した場合、例えば、リンク層特有の方法、ＥＡＰフレームワーク（ＲＦＣ３７４８を参照のこと）、及びＥＡＰ−ＡＫＡ（ＲＦＣ４１８７を参照のこと）などのＥＡＰ方法を使用して、ネットワークを認証する。モバイル・アクセス・ゲートウェイは、通常、パススルー認証として働き、例えば、Ｄｉａｍｅｔｅｒ（ＲＦＣ３５８８、ＲＦＣ４０７２を参照のこと）又はＲａｄｉｕｓ（ＲＦＣ２８６５、ＲＦＣ３５７９を参照のこと）などのＡＡＡプロトコルを使用して、ＥＡＰパケットを、ＡＡＡサーバ又はインフラストラクチャなどのバックエンドの認証サーバへ転送する。モバイル・ノードは、ネットワーク認証時に、例えば、ネットワーク・アクセス識別子を識別子として使用する。ネットワーク認証が正常に終了すると、モバイル・アクセス・ゲートウェイは、モバイル・ノードのホーム・プレフィックスを含むＡＡＡサーバからモバイル・ノードのプロファイルを取得し、このプロファイルをネットワーク・アクセス識別子と共に格納する。次にモバイル・アクセス・ゲートウェイは、ＰＢＵをローカル・モビリティ・アンカーに送信し、モバイル・ノードの新しい位置を登録する。ＰＢＵ送信プロセスは、例えば、ネットワーク認証の成功によって、ＤＨＣＰ（動的ホスト構成プロトコル）メッセージによって、又はその他によって、トリガ可能である。さらに、モバイル・アクセス・ゲートウェイは、モバイル・ノードにモバイル・ノードのホーム・プレフィックスを通知する。従って、モバイル・ノードは、モバイル・ノードのホーム・プレフィックスを通知し、モバイル・ノードのモビリティ（以後、ＰＭＩＰｖ６又はＰＭＩＰドメインと呼ぶ）を管理するモバイル・アクセス・ゲートウェイのセット内を移動する限り、ホームにいるものと考え、サブネットの変更は通知しない。ローカル・モバイル・アンカーとモバイル・アクセス・ゲートウェイとの間のトンネルが確立され、モバイル・ノードとの間のすべてのトラフィックは、このトンネルを介して転送される。
【００１６】
プロキシ・バインディング更新メッセージは、ＩＰｓｅｃセキュリティアソシエーションを介して送信されることから、データ源の認証及び整合性保護を提供するために暗号によって保護される。これには、通常、モバイル・アクセス・ゲートウェイ及びホーム・エージェントが秘密鍵を共有している必要がある。従ってホーム・エージェントは、対応する共有鍵で暗号によって保護されたモバイル・アクセス・ゲートウェイのアドレスに対するプロキシ・バインディング更新メッセージＰＢＵのみを受け入れる。ローカル・モビリティ・アンカーは基本的に、正しい共有鍵を所有する信頼されるモバイル・アクセス・ゲートウェイによって送信された任意のＰＢＵメッセージを受け入れるため、モバイル・アクセス・ゲートウェイが危険にさらされた場合、すなわち、攻撃者が信頼されるモバイル・アクセス・ゲートウェイの制御を入手できる場合、問題が発生する。この場合、このモバイル・アクセス・ゲートウェイは、偽のＰＢＵをローカル・モバイル・アンカーに送信することによってパス外攻撃を実施し、ＰＭＩＰドメイン内の任意のモバイル・ノードに対するトラフィックをそれ自体に宛先変更することができる。この問題は、ローカル・モビリティ・アンカーがモバイル・ノードのＣＭＩＰアンカーでもあり、ＰＭＩＰホーム・アドレスがＣＭＩＰホーム・アドレスに等しい場合、さらに深刻である。この場合、攻撃はＭＩＰｖ６にまで拡大され、攻撃者はＰＭＩＰドメイン外に配置されたモバイル・ノードに対するトラフィックを宛先変更することができる。
【００１７】
この状況が図１に示されている。通信相手ノード（ＣＮ）とデータを交換しているモバイル・ノード（ＭＮ）は、そのホームＰＭＩＰドメイン外に配置され、ローカル・モビリティ・アンカー（ＬＭＡ）をＭＩＰｖ６のホーム・エージェントとして使用する。モバイル・ノードはＰＭＩＰドメイン内にある場合、モバイル・アクセス・ゲートウェイＭＡＧ１によるサービスを受けることができる。しかし、危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２は、モバイル・ノードのホーム・アドレスに対する偽のＰＢＵを送信することができる。ローカル・モバイル・アンカーは、モバイル・ノードがモバイル・アクセス・ゲートウェイＭＡＧ２に移動したものと考えて、この偽のＰＢＵを受け入れる。それ故、ローカル・モバイル・アンカーは、モバイル・ノードに対するすべての着信トラフィックをモバイル・アクセス・ゲートウェイＭＡＧ２に転送する。
【００１８】
従って、モバイル・ノードの位置に応じて、２種類の宛先変更攻撃を区別することができる。第１に、宛先変更攻撃は、危険にさらされたモバイル・アクセス・ゲートウェイと同じＰＭＩＰｖ６ドメイン内に位置するモバイル・ノードに対して向けられる可能性がある（シナリオ１）。第２に、宛先変更攻撃は、危険にさらされたモバイル・アクセス・ゲートウェイのＰＭＩＰｖ６の外部に位置し、Ｍｏｂｉｌｅ  ＩＰｖ６を使用しているモバイル・ノードに対して向けられる可能性がある（シナリオ２）。
【００１９】
シナリオ１に関して、ローカル・モバイル・アンカーは、モバイル・アクセス・ゲートウェイが、モバイル・ノードに対するバインディング・キャッシュを作成する権限が与えられているか否かをチェックすることができる（Ｓ．Ｇｕｎｄａｖｅｌｌｉ、Ｋ．Ｌｅｕｎｇ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、Ｋ．Ｃｈｏｗｄｈｕｒｙ、Ｂ．Ｐａｔｉｌによる、Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６、ｄｒａｆｔ−ｓｇｕｎｄａｖｅ−ｍｉｐ６−ｐｒｏｘｙｍｉｐ６−０２、２００７年３月を参照のこと）。このチェックの詳細は説明しないが、ＡＡＡインフラストラクチャなどのポリシー・ストアが照会可能であることが示唆される。しかし、ＰＢＵメッセージの受け取りごとにポリシー・ストア又はＡＡＡサーバを調べることは、ハンドオーバ遅延を大幅に増大させる。
【００２０】
シナリオ２に関して、モバイル・ノードがＰＭＩＰドメインの外部に位置することを現在のバインディング・キャッシュ・エントリが示す場合、ローカル・モビリティ・アンカーは、ＰＢＵメッセージの受け取り時に、ＢＵメッセージの登録解除がモバイル・ノードから受け取られるまでは、バインディング・キャッシュ・エントリを変更しないというメカニズムが、Ｓ．Ｇｕｎｄａｖｅｌｌｉ、Ｋ．Ｌｅｕｎｇ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、Ｋ．Ｃｈｏｗｄｈｕｒｙ、Ｂ．Ｐａｔｉｌによる、Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６、ｄｒａｆｔ−ｓｇｕｎｄａｖｅ−ｍｉｐ６−ｐｒｏｘｙｍｉｐ６−０２、２００７年３月に記載されている。攻撃者は登録解除ＢＵメッセージをスプーフィングできないため、このメカニズムは問題を解決することになる。しかし、このメカニズムも、モバイル・ノードがＰＭＩＰドメインに入った場合にハンドオーバ遅延を大幅に増大させ、シナリオ１の問題を解決しない。
【００２１】
モバイル・ノード（ＭＮ）は、新しいＰＭＡに接続されると、ＥＡＰフレームワーク［ＲＦＣ３７４８］及びＥＡＰ−ＡＫＡ［ＲＦＣ４１８７］などのＥＡＰ方法を使用して、ネットワークを認証する。ＰＭＡは、通常、パススルー認証として働き、ＥＡＰパケットをＭＮに関するＡＡＡサーバ／インフラストラクチャに転送する。ＭＮはＮＡＩを識別子として使用する。ネットワーク認証が正常に終了すると、ＰＭＡはＭＮのホーム・プレフィックスを含むＡＡＡサーバからＭＮのプロファイルを取得する。次にＰＭＡは、ＰＢＵをＨＡに送信し、ホーム・プレフィックスをＭＮに通知する。ＭＮはＡＲを認証した後、ＩＰ構成を開始し、すなわちリンク・ローカル（ＬＬ）ＩＰアドレスを構成し、近隣要請（ＮＳ）メッセージを、チェックされる予定のＬＬアドレスの送信要請（solicited）型ノード・マルチキャスト・アドレスに送信するＬＬアドレスに対する重複アドレス検出（ＤＡＤ）を実行する。この手順が正常に完了すると、ＭＮはルータ要請（ＲＳ）メッセージをすべてのルータのマルチキャスト・アドレスに送信し、ルータ広告（ＲＡ）の受け取りを待機する。ＡＲ／ＰＭＡはＭＮのホーム・プレフィックスを含むユニキャストＲＡに応答する。本発明では、ＭＮがステートフル・アドレス構成スキームを適用する、すなわち動的ホスト構成プロトコル（ＤＨＣＰ）が使用されることが想定される。ＭＮは、「Ｍ」フラグが設定された、受け取ったユニキャストＲＡメッセージから、ＤＨＣＰが使用される予定であることを習得する。従って、ＭＮはＤＨＣＰ送信要請メッセージを送信し、これが、ＤＨＣＰリレー・エージェントとして働くＡＲ／ＰＭＡによってキャプチャされる。ＤＨＣＰリレーは、このメッセージをＤＨＣＰサーバに転送し、ＤＨＣＰサーバは、ＭＮのホーム・アドレス（ＨｏＡ）を含むＤＨＣＰリレー又は広告メッセージで応答する。ＭＮがＤＨＣＰ広告メッセージを受け取った後、ＭＮは、そのグローバルＩＰアドレスとして広告されたＨｏＡを構成する。従って、ＭＮは到達可能であり、ＰＭＩＰドメイン内を移動する限り、ホームにいるものと考える。本パラグラフで説明したような初期接続手順時のＰＭＩＰｖ６に関する例示的信号フローは、図６に示されている。
【００２２】
図７は、同じＰＭＩＰドメイン内のＰＭＡ間でのハンドオーバの場合の信号フローを示す。ＭＮはＡＲ／ＰＭＡ２領域に移動した場合、図６に示したような認証手順を開始する。ＰＭＡ２はＥＡＰキートランスポート・メッセージを受け取った後、ＰＢＵ［ＮＡＩ，ｈｏｍｅ  ｐｒｅｆｉｘ，ｔｉｍｅｓｔａｍｐ］を送信するＨＡの登録プロセスを開始することができる。ＭＮはＰＭＡ２を正常に認証した後、現在のＩＰ構成が依然として有効であるか否かのチェックを開始し、すなわちＭＮはＲＳメッセージを送信する。ＡＲ／ＰＭＡ２は、アドレス構成にＤＨＣＰを使用するために「Ｍ」フラグを設定したＲＡで応答する。次に、ＭＮはＤＨＣＰ確認メッセージを送信し、これは、ＤＨＣＰリレー・エンティティとして動作するＡＰ／ＰＭＡ２によってインターセプトされる。ＤＨＣＰサーバによって送信されるＤＨＣＰ応答メッセージは、以前に構成されたＨｏＡが依然として使用可能であることを確認する。ＤＨＣＰ手順が完了した後、ＭＮは再度ＩＰ接続され、データ・パケットを送受信することができる。
【００２３】
ＲＦＣ３７７５に定義されたＭＩＰｖ６に関するＨＡの機能は、大部分が再使用されるが、ＰＭＩＰｖ６をサポートするためには幾つかの変更が必要である。以下、ＲＦＣ３７７５で定義されたＨＡはＣＭＩＰ−ＨＡと呼ばれ、（Ｓ．Ｇｕｎｄａｖｅｌｌｉ、Ｋ．Ｌｅｕｎｇ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、Ｋ．Ｃｈｏｗｄｈｕｒｙによる、「Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６」ｄｒａｆｔ．ａｇｕｎｄａｖｅ−ｍｉｐ６−ｐｒｏｘｙｍｉｐ６−０１、２００７年１月）に定義されたＨＡはＰＭＩＰ−ＨＡと呼ばれる。例えば、大きな違いは、ＢＵ／ＰＢＵメッセージの新しさがＨＡによってどのように決定されるかである。ＣＭＩＰ−ＨＡはＢＵメッセージの新しさをＢＵ内のシーケンス番号に基づいて識別するが、ＰＭＩＰ−ＨＡは、ＰＢＵメッセージの新しさを、ＰＢＵ内のタイムスタンプ・オプションのタイムスタンプに基づいて識別する。ＰＭＩＰ−ＨＡはＰＢＵメッセージ内のシーケンス番号値を考慮しない。
【００２４】
同じ位置に配置されたＰＭＩＰ−ＨＡ及びＣＭＩＰ−ＨＡ（さらに本発明では、こうしたＣＭＩＰ／ＰＭＩＰ−ＨＡは単にＨＡと呼ばれる）を含む可能なシナリオが、図８に示されている。図では、ＰＭＩＰｖ６がホーム・オペレータ・ネットワーク内の局所的モビリティ管理に使用され、ＣＭＩＰｖ６は、ＭＮが他のネットワーク内をローミングする場合、グローバル・モビリティ管理に使用される。ＨＡはＭＮのＣｏＡが登録されたデータベースを維持する。これらの登録は、ＭＮ又はＰＭＡによって対応的に送信されたＢＵ及びＰＢＵメッセージに基づく。このデータベースは、さらに、バインディング・キャッシュ・エントリ（ＢＣＥ）と呼ばれる。
【００２５】
ＢＵ及びＰＢＵメッセージは異なるＣｏＡを含むが、どちらも同じＨｏＡに結び付けられる。ＨＡが、様々なＣｏＡの中で同じＨｏＡに向けて送られた異なるＩＰフローを分離するためのメカニズム（こうしたメカニズムはマルチホーミングとして知られている）を実施しない場合、ＨＡにはＨｏＡとＣｏＡのアクティブ・バインディングが１つだけあればよいため、ＨＡは、どのＣｏＡにデータ・パケットが転送されるかが明瞭にわかる。ＢＵ及びＰＢＵメッセージは、異なるＣｏＡを含むため、ＨＡは、どのメッセージが現行であるか、同様に、どのＣｏＡが現行であるかを決める必要がある。
【００２６】
前述のように、モバイル・ノードによって送信されるバインディング更新（クライアント・ベースのモビリティであり、ｃｌｉｅｎｔ−ＢＵに対する簡易ＣＢＵが求められる場合）及びプロキシ・モバイル・エージェント（ネットワーク・ベースのモビリティであり、ｐｒｏｘｙ−ＢＵに対する簡易ＰＢＵが求められる場合）について、異なる条件に基づいて新しさが比較される。クライアント・バインディング更新は、新しいバインディング更新が送信されるごとに増加するシーケンス番号を含む。プロキシ・バインディング更新は、受信機内に送信時間を示すタイムスタンプを含む。こうすることで、ホーム・エージェントは両方のバインディング更新のうちのいずれが、より最近に送信されたかを比較することができない。さらに本発明では、この状況はバインディング更新競合状態と呼ばれる。バインディング更新が異なるルートを介して伝搬されるため、ホーム・エージェントは、バインディング更新の結果の到着に基づいてバインディング更新の新しさを結論付けることはできない。
【００２７】
バインディング更新の順序変更が実行され、ホーム・エージェントが誤って古いバインディング更新を受け入れた場合、モバイル・ノードへのデータ・パケットは古いモバイル・ノードの位置へとルーティングされることになり、すなわちパケットは失われることになる。ＢＵ及びＰＢＵがＨＡ内で順序変更されて到達するシナリオが、図９及び図１０に示されている。図９は、ＭＮがＣＭＩＰベース・モビリティからＰＭＩＰベース・モビリティ・メカニズムへと移動し、ＭＮによって送信されたＢＵが、ＰＭＡによって送信されたＰＢＵよりもＨＡ内で後に到着するケースを示す。類推によれば、図１０は、ＰＭＩＰベース・モビリティからＣＭＩＰベース・モビリティ・メカニズムへの遷移を示し、ＰＭＡによって送信されたＰＢＵは、ＭＮによって送信されたＢＵよりもＨＡ内で後に到着する。
【００２８】
Ｍｏｂｉｌｅ  ＩＰｖ６は、現在、双方向トンネリング及びルート最適化という２つの動作モードを定義している。図１５は、双方向トンネリングの使用を例証している。通信相手ノードによって送信され、モバイル・ノードのホーム・アドレスにアドレス指定されたデータ・パケットが、ホーム・ネットワーク内のホーム・エージェントによってインターセプトされ、モバイル・ノードの気付けアドレスへとトンネリングされる。モバイル・ノードによって送信されたデータ・パケットは、ホーム・エージェントへと逆トンネリングされ、ホーム・エージェントはパケットをカプセル化解除し、それらを通信相手ノードへ送信する（逆トンネリングとは、モバイル・ノードの気付けアドレスから始まりホーム・エージェントで終わるトンネルを介して、パケットがモバイル・ノードによって伝送されることを意味する）。
【００２９】
この動作の場合、ホーム・エージェントのみにモバイル・ノードの気付けアドレスが通知される。従ってモバイル・ノードは、バインディング更新（ＢＵ）メッセージをホーム・エージェントに送信する。これらのメッセージは、ＩＰｓｅｃセキュリティアソシエーションを介して送信されるため、認証され、整合性が保護される。欠点は、モバイル・ノードがホーム・ネットワークから遠く、通信相手ノードがモバイル・ノードに近い場合、通信パスが不必要に長くなり、結果として非効率なルーティング及び大きなパケット遅延が生じることである。
【００３０】
ルート最適化モードは、通信相手ノードとモバイル・ノードとの間の直接パスを使用して、双方向トンネリング・モードの非効率を防ぐことができる。ルート最適化の使用が図１６に例証されている。モバイル・ノードはバインディング更新メッセージを通信相手ノードに送信し、次にこれがデータ・パケットを直接モバイル・ノードに送信することができる（タイプ２のルーティング・ヘッダを使用して、直接パス上でパケットを送信する）。もちろん、通信相手ノードはＭｏｂｉｌｅ  ＩＰｖ６のルート最適化サポートを実施しなければならない。
【００３１】
バインディング更新メッセージを認証するために、モバイル・ノード及び通信相手ノードは、いわゆるリターン・ルータビリティ手順を実行し（図１７を参照のこと）、これが、ホーム・アドレス・テスト及び気付けアドレス・テストを使用して、それぞれ、ホーム・アドレス及び気付けアドレスでのモバイル・ノードの到達可能性をテストし、共有セッション鍵を生成する。その後、モバイル・ノードは、通信相手ノードに送信されたそのバインディング更新を認証するために、セッション鍵を使用して、その気付けアドレスを通信相手ノードに登録することができる。
【００３２】
図１８に示されるように、モバイル・ノードは、ホーム・エージェントを介して逆トンネリングされるホーム・テスト開始メッセージを送信することによって、リターン・ルータビリティ手順を開始する。ホーム・テスト開始メッセージは、要求に対して回答をマッピングできるようにするためのクッキーを含む。通信相手ノードは、ホーム・クッキー、ホーム・ノンス・インデックス、及びホーム・キー生成トークンを含む、いわゆるホーム・テスト・メッセージで回答する。ホーム・キー生成トークンは、ホーム・アドレス及びホーム・ノンスからのキー付きハッシュ関数で計算される。この交換と並行して、又はこれに続いて、モバイル・ノードは、通信相手ノードに対して直接パス上で気付けテスト開始メッセージを送信する。気付けテスト開始は気付けクッキーを含み、通信相手ノードは、気付けクッキー、気付けノンス・インデックス、並びに、気付けアドレス及び気付けノンスからのキー付きハッシュ関数で計算される気付けキー生成トークンを含む気付けテスト・メッセージで回答する。ハッシュ関数に対するキー及びノンスを知っているのは、通信相手ノードのみである。モバイル・ノードは、ホーム・テスト及び気付けテストの両方のメッセージを受信した後、ホーム・テスト・メッセージ及び気付けテスト・メッセージ内でのキー生成トークンの連結のハッシュ値であるバインディング・キー「ｋｂｍ」を計算する。次にモバイル・ノードは、バインディング・キーでキー付けされたハッシュ関数を使用して、認証を計算する。認証は、バインディング更新メッセージ、ホーム・アドレス、及び気付けアドレスを介して計算され、バインディング更新メッセージに付加される。この承認された（authorized：正当性が認められた、オーソライズされた）バインディング更新メッセージは、最終的に通信相手ノードに送信される。検証が正常に終了した場合、通信相手ノードは、そのバインディング・キャッシュ内にホーム・アドレスと気付けアドレスとのバインディングを作成し、モバイル・ノードの気付けアドレスにパケットを直接送信することができる。
【００３３】
セキュリティに関連して、設計の目標は、ＩＰｖ６に対して適合可能なレベルを達成すること、すなわち、攻撃者がパス上にいる場合、トラフィックの宛先変更のみを可能にすることであった。
【００３４】
リターン・ルータビリティ手順及びルート最適化モードに対して、複数タイプの攻撃が可能である（例えば、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで入手可能であり、参照により本明細書に組み込むものとする、Ｐ．Ｎｉｋａｎｄｅｒ、Ｊ．Ａｒｋｋｏ他による、「Ｍｏｂｉｌｅ  ＩＰ  Ｖｅｒｓｉｏｎ  ６  Ｒｏｕｔｅ  Ｏｐｔｉｍｉｚａｔｉｏｎ  Ｓｅｃｕｒｉｔｙ  Ｄｅｓｉｇｎ  Ｂａｃｋｇｒｏｕｎｄ」、ＩＥＴＦ  ＲＦＣ４２２５、２００５年１２月を参照のこと）。偽のバインディング更新メッセージが通信相手ノードによって誤って受け入れられた場合に可能な最も重要な２つの攻撃は、以下の通りである。
−アドレス・スティーリング又は偽装攻撃。攻撃者は、トラフィックを傍受又は不正変更するため、あるいはサービス妨害のためにそれらを中断させるため、犠牲者に向けて送られたトラフィックを自分自身に宛先変更しようと試みる。犠牲者は、モバイル・ノード又は、グローバルにルーティング可能なアドレスを備えた任意の定常ノードとすることができる。
−フラッディング攻撃。攻撃者は高帯域サービスに加入し、サービス妨害のために着信トラフィックを犠牲者向けに宛先変更する。
【００３５】
以下のテーブルは、攻撃者がバインディング更新メッセージに挿入可能なアドレスの可能な組合せと、バインディング更新が通信相手ノードによって受け入れられた場合の結果と、可能な対応策との概要を示す。
１）ホーム・アドレス＝犠牲者のホーム・アドレス／アドレス、気付けアドレス＝攻撃者の気付けアドレス
−目的：傍受／不正変更のためのアドレス・スティーリング／偽装攻撃
−対応策：暗号化生成アドレス、ホーム・アドレス・テスト
２）ホーム・アドレス＝犠牲者のホーム・アドレス／アドレス、気付けアドレス＝非既存気付けアドレス
−目的：サービス妨害のためのアドレス・スティーリング／偽装攻撃
−対応策：暗号化生成アドレス、ホーム・アドレス・テスト
３）ホーム・アドレス＝攻撃者のホーム・アドレス、気付けアドレス＝犠牲者の気付けアドレス
−目的：フラッディング攻撃
−対応策：信用ベースのバインディング確認、気付けアドレス・テスト
４）ホーム・アドレス＝犠牲者のプレフィックスを備えた攻撃者のホーム・アドレス、気付けアドレス＝攻撃者の気付けアドレス
−目的：ホーム復帰（ｒｅｔｕｒｎ−ｔｏ−ｈｏｍｅ）フラッディング：攻撃者はホーム・アドレスを高帯域サービスに加入し、サービス妨害のためにストリームを犠牲者のネットワークへ宛先変更するようにバインディングを期限切れにさせる
−対応策：ホーム・アドレス・テスト
【００３６】
ホーム・アドレス・テスト（ホーム・テスト／ホーム・テスト開始交換）により、攻撃者は請求したホーム・アドレスに到達可能でなければならない。従って、ホーム・エージェントと通信相手ノードの間のパス上にいる攻撃者、及びモバイル・ノードとホーム・エージェントの間の攻撃者のみが、１、２、及び４番のアドレス組合せで攻撃を首尾よく完了することができる。ＩＰｓｅｃが使用される場合、モバイル・ノードとホーム・エージェントとの間のトンネル内でのホーム・テストは暗号化しなければならない（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで入手可能であり、参照により本明細書に組み込むものとする、Ｊ．Ａｒｋｋｏ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、Ｆ．Ｄｕｐｏｎｔの、「Ｕｓｉｎｇ  ＩＰｓｅｃ  ｔｏ  Ｐｒｏｔｅｃｔ  Ｍｏｂｉｌｅ  ＩＰｖ６  Ｓｉｇｎａｌｉｎｇ  Ｂｅｔｗｅｅｎ  Ｍｏｂｉｌｅ  Ｎｏｄｅｓ  ａｎｄ  Ｈｏｍｅ  Ａｇｅｎｔｓ」、ＩＥＴＦ  ＲＦＣ  ３７７６、２００４年６月を参照のこと）。この場合、攻撃者は、１、２、及び４番のアドレス組合せで攻撃を首尾よく完了するために、ホーム・エージェントと通信相手ノードとの間のパス上にいなければならない。気付けアドレス・テスト（気付けテスト／気付けテスト開始交換）により、攻撃者は、３番のアドレス組合せでフラッディング攻撃を首尾よく完了するために、請求した気付けアドレスに到達可能でなければならない。
【００３７】
要約すると、攻撃者は、偽の通信相手ノード登録を使用してトラフィックを宛先変更できるようにするために、パス上にいなければならない。しかし、ＩＰｖ６とは異なり、攻撃者は一時的にパスにアクセスし、パス外攻撃を続行できるだけである。例えば、攻撃者はホーム・テストをインターセプトし、その後、ホーム・エージェントと通信相手ノードの間のパスを離れて、１番のアドレス組合せで偽装攻撃を実施することができる。これは時間移動攻撃と呼ばれ（例えば、ＲＦＣ  ４２２５を参照のこと）、７分という短時間のバインディングによって軽減されるものであり、すなわち攻撃者は、偽の宛先変更をアクティブ状態で維持するために、少なくとも７分ごとに再度パス上に移動しなければならない。
【００３８】
リターン・ルータビリティ手順及びルート最適化モードの欠点は、待ち時間及び信号オーバヘッドが大幅に増加することであり、あらゆるハンドオーバ時に、少なくとも５つのメッセージ（バインディング更新メッセージを含む）を交換しなければならず、たとえモバイル・ノードが移動していない場合であっても、バインディング期間が期限切れになるごと（すなわち７分後）に、手順を反復しなければならない。他の欠点は、手順が完全にはセキュアでないことであり、最新の７分間に請求したホーム・アドレス及び気付けアドレスに到着可能であったノードは攻撃者ではないという仮定に基づいている。リターン・ルータビリティ手順の他の欠点は、ホーム・エージェントに依存することであり、ホーム・エージェントがダウンした場合、ホーム・エージェントはルート最適化トラフィック向けのデータ・パス上にはいないことになるが、ルート最適化通信は不可能であることを意味する。
【００３９】
Ｊ．Ａｒｋｋｏ、Ｃ．Ｖｏｇｔ、Ｗ．Ｈａｄｄａｄの、「Ａｐｐｌｙｉｎｇ  Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ  Ｇｅｎｅｒａｔｅｄ  Ａｄｄｒｅｓｓｅｓ（ＣＧＡ）  ａｎｄ  Ｃｒｅｄｉｔ−ｂａｓｅｄ  Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＣＢＵ）  ｔｏ  Ｍｏｂｉｌｅ  ＩＰｖ６」、ｄｒａｆｔ−ａｒｋｋｏ−ｍｉｐｓｈｏｐ−ｃｇａ−ｃｂａ−０４．ｔｘｔ、２００６年６月（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで入手可能であり、参照により本明細書に組み込むものとする）では、ルート最適化モードに関する２つの最適化を提案している。第１は、モバイル・ノードが、ハンドオーバ遅延を改善するために、初期のバインディング更新を新しい未検証の気付けアドレスと共に送信すること、すなわち、バインディング更新が送信された後に気付けアドレス・テストが実行されること、並びに、並行して新しい気付けアドレスにデータを送信することを可能にする。しかし、通信相手ノードは信用カウンタを維持し、以前の気付けアドレスに送信したものと同じ数のパケットのみをこの未検証の気付けアドレスに送信することが許可される。この「信用ベース承認」により、宛先変更ベースのフラッディング攻撃を防止する。第２の最適化は、モバイル・ノード及び通信相手ノードが、初期ホーム・アドレス・テストを除くほぼすべてのホーム・アドレス・テストをスキップできるようにする。これにより、例えば、Ｔ．Ａｕｒａの、「Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ  Ｇｅｎｅｒａｔｅｄ  Ａｄｄｒｅｓｓｅｓ（ＣＧＡ）」、ＲＦＣ  ３９７２、２００５年３月（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで入手可能であり、参照により本明細書に組み込むものとする）で提案されるように、信号オーバヘッド及びハンドオーバ遅延は低減されるが、ホーム・アドレスが暗号化生成アドレス（ＣＧＡ）であることが必要である。暗号化生成アドレスは、公開鍵をＩＰｖ６アドレス（又は、より詳細には、そのインターフェイス識別子）にバインディングし、これは、対応する秘密鍵で署名されたメッセージに関する強力な暗号化アドレス所有の証明であり、偽装攻撃を実質上不可能にする。初期ホーム・アドレス・テストは、ホーム暗号化生成アドレスのプレフィックスを検証するため、及びホーム復帰フラッディング攻撃を防止するためにのみ必要である（Ｊ．Ａｒｋｋｏ、Ｃ．Ｖｏｇｔ、Ｗ．Ｈａｄｄａｄの、「Ａｐｐｌｙｉｎｇ  Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ  Ｇｅｎｅｒａｔｅｄ  Ａｄｄｒｅｓｓｅｓ（ＣＧＡ）  ａｎｄ  Ｃｒｅｄｉｔ−ｂａｓｅｄ  Ａｕｔｈｏｒｉｚａｔｉｏｎ（ＣＢＵ）  ｔｏ  Ｍｏｂｉｌｅ  ＩＰｖ６」を参照のこと）。これらのメカニズムにより、通信相手ノードでのバインディング期間を７分より長くすることが可能である。すなわち、リターン・ルータビリティ手順を７分ごとに反復する必要がない。
【００４０】
しかし、この提案には欠点がある。第１に、暗号化生成アドレスは、公開鍵暗号に基づいているため、公開／秘密鍵及びある程度の計算及びメモリ（メッセージの署名及び検証のため、並びに暗号化生成アドレスの生成のため）を必要とし、これは、すべてのモバイル・ノード又は通信相手ノードで使用可能ではない場合がある。さらに暗号化生成アドレスは、様々な理由で大規模に実施されない。
【００４１】
Ｍｏｂｉｌｅ  ＩＰｖ６ルート最適化モードの欠点は、双方向トンネリング・モードに比べて制限されたセキュリティ並びに大幅な信号及びハンドオーバ遅延である。後者は、遅延に影響を受けやすいアプリケーションにマイナスの影響を与える。本発明の第３の態様は、ルート最適化モード及びその変形のセキュリティを向上させるため、又はほぼ同じセキュリティ特性を維持しながら、信号オーバヘッド及びハンドオーバ遅延を削減するために使用可能なメカニズムを提案する。
【００４２】
他の欠点は、ホーム・エージェントへの依存度、及びホーム・エージェントがダウンした場合にデータ・セッションをアクティブに維持できないことである。本発明の第３の態様は、ホーム・エージェントへの依存度を低下させ、ホーム・エージェントのクラッシュに対する許容範囲を拡大することが可能である。
【発明の概要】
【発明が解決しようとする課題】
【００４３】
本発明の第１の目的は、危険にさらされたネットワーク要素が、モバイル・ノードに向けて送られたトラフィックを宛先変更しようとすることを検出するための改善された方法であって、ハンドオーバ遅延に影響を与えない方法を提供することである。
【００４４】
本発明の第２の目的は、ネットワーク・ベース及びホスト・ベースの混合モビリティ管理においてモビリティ・アンカー・ポイントでの競合状態を解決するため、並びに、モビリティ・アンカー・ポイントが２つのバインディング更新を受信した際に、常に最も新しいバインディング更新を受け入れることを確実にするための方法を提供することである。
【００４５】
本発明の第３の目的は、モバイル・ノード及び／又は通信相手ノードが、通信相手ノードでスプーフィングされたバインディング・キャッシュ・エントリを検出できるようにすること、並びにたとえモバイル・ノードのホーム・エージェントが到達不可能な場合であっても、通信相手ノードへの気付けアドレスの承認された登録を可能にするメカニズムを提案することである。
【００４６】
さらに他の目的は、暗号化生成アドレスを使用する必要なしに、これらの目的のうちの少なくとも１つを達成することである。
【課題を解決するための手段】
【００４７】
本発明の第１の態様による実施の形態では、受信したばかりの有効ＰＢＵメッセージに含まれるＩＰアドレスだけでなく、以前に受信した有効ＰＢＵメッセージに含まれるＩＰアドレスへも確認メッセージを送信することによって、モバイル・ノードが、ＰＢＵメッセージをローカル・モビリティ・アンカーに送信したモバイル・アクセス・ゲートウェイに、実際に接続されているか否かを検証することが行われる。こうしたメカニズムは、あらゆるハンドオーバ時に、ポリシー・ストア又はＡＡＡサーバを照会する必要なしに、攻撃の検出が可能であり、これによって、ハンドオーバ遅延の増加を防止する。
【００４８】
本発明の第１の態様による実施の形態によれば、ローカル・モビリティ・アンカーが、信頼されるモバイル・アクセス・ゲートウェイから有効ＰＢＵを受信した直後に、バインディング・キャッシュ・エントリを更新し、モバイル・ノードが、その後ＰＢＵを送信するモバイル・アクセス・ゲートウェイに実際に位置するか否かを検証するための手順を開始する場合、ハンドオーバ遅延はさらに削減することが可能であり、すなわち、データ・トラフィックは新しい位置へと即時に流れることが可能であり、攻撃の検出が同時に実行される。この楽観的な手法は、宛先変更攻撃の検出が依然として可能でありながら、ハンドオーバ遅延が通常のＰＭＩＰハンドオーバに比べて増加しないことを確保する。
【００４９】
本発明の第１の態様による一実施の形態は、ネットワーク内のネットワーク要素へのモバイル・ノードの接続を検証するための方法を提供し、上記ネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、上記方法は、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージを受信するステップであって、上記第１のメッセージは、第１のＩＰアドレスを有するステップと、第２のネットワーク内のモバイル・ノードの位置に関する第２のメッセージを受信するステップであって、上記第２のメッセージは第２のＩＰアドレスを有し、上記第２のネットワークはモバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用するステップと、第１及び第２の両方のＩＰアドレスに確認メッセージを送信するステップと、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージと確認メッセージを比較するステップと、比較結果に基づいて、第２のネットワーク内のモバイル・ノードの位置に関する第２のメッセージが改ざんされているか否かを検出するステップとを有する。
【００５０】
本発明の第１の態様による他の実施の形態は、ネットワーク内のネットワーク要素へのモバイル・ノードの接続を検証するための方法を提供し、上記ネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、上記方法は、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージを受信するステップであって、上記第１のメッセージは第１のＩＰアドレスを有するステップと、第２のネットワーク内のモバイル・ノードの位置に関する第２のメッセージを受信するステップであって、上記第２のメッセージは第２のＩＰアドレスを有し、上記第２のネットワークはモバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用するステップと、第１及び第２の両方のＩＰアドレスに確認メッセージを送信するステップであって、上記確認メッセージは、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージと第２のネットワーク内のモバイル・ノードの位置に関する第２のメッセージとの再送をそれぞれ要求するステップと、ローカル・モビリティ・アンカーによって受信されたモバイル・ノードの位置に関する再送されたメッセージに基づいて、第２のネットワーク内のモバイル・ノードの位置に関する第２のメッセージが改ざんされているか否かを検出するステップがローカル・モビリティ・アンカーによって実行されるステップを有する。
【００５１】
本発明の第１の態様による他の実施の形態は、ネットワーク内のネットワーク要素へのモバイル・ノードの接続を検証するように構成されたローカル・モビリティ・アンカーを提供し、上記ネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、上記ローカル・モビリティ・アンカーは、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージであって、上記第１のメッセージは第１のＩＰアドレスを有する第１のメッセージと、第２のネットワーク内のモバイル・ノードの位置に関する第２のメッセージであって、上記第２のメッセージは第２のＩＰアドレスを有する第２のメッセージとを受信するための受信手段であって、上記第２のネットワークはモバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用する受信手段と、第１及び第２の両方のＩＰアドレスに確認メッセージを送信するための送信手段とを有する。
【００５２】
本発明の第１の態様による他の実施の形態は、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージを送信するための送信手段であって、前記第１のネットワークは、モバイル・ノードのモビリティを管理するためにモバイル・ノード・ベースのモビリティ管理スキームを使用する送信手段と、ローカル・モビリティ・アンカーから確認メッセージを受信するための受信手段と、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージと受信した確認メッセージとを比較するための比較手段と、比較結果に基づいて、第２のネットワーク内のモバイル・ノードの位置に関するローカル・モビリティ・アンカーで受信した第２のメッセージが、改ざんされているか否かを検出するための検出手段であって、上記第２のネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用する検出手段とを有するモバイル・ノードを提供する。
【００５３】
本発明の第１の態様による他の実施の形態は、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージを送信するための送信手段であって、前記第１のネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用する送信手段と、ローカル・モビリティ・アンカーから確認メッセージを受信するための受信手段と、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージと受信した確認メッセージとを比較するための比較手段と、比較結果に基づいて、第２のネットワーク内のモバイル・ノードの位置に関するローカル・モビリティ・アンカーで受信した第２のメッセージが、改ざんされているか否かを検出するための検出手段であって、上記第２のネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用する検出手段とを有するネットワーク要素を提供する。
【００５４】
本発明の第１の態様による他の実施の形態は、ネットワーク内のネットワーク要素へのモバイル・ノードの接続を検証するように構成されたローカル・モビリティ・アンカーを提供し、上記ネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、上記ローカル・モビリティ・アンカーは、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージであって、上記第１のメッセージは第１のＩＰアドレスを有する第１のメッセージと、第２のネットワーク内のモバイル・ノードの位置に関する第２のメッセージであって、上記第２のメッセージは第２のＩＰアドレスを有する第２のメッセージとを受信するための受信手段であって、上記第２のネットワークはモバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用する受信手段と、第１及び第２の両方のＩＰアドレスに確認メッセージを送信するための送信手段であって、上記確認メッセージは、第１のネットワーク内のモバイル・ノードの位置に関する第１のメッセージと第２のネットワーク内のモバイル・ノードの位置に関する第２のメッセージとの再送をそれぞれ要求する送信手段と、ローカル・モビリティ・アンカーによって受信されたモバイル・ノードの位置に関する再送されたメッセージに基づいて、第２のネットワーク内のモバイル・ノードの位置に関する第２のメッセージが改ざんされているか否かを検出するための検出手段とを有する。
【００５５】
本発明の第２の態様による実施の形態は、ＣＭＩＰ−ＨＡ及びＰＭＩＰ−ＨＡが単一のＨＡ内に共同配置された場合、ネットワーク・ベース及びクライアント・ベースのモビリティ・メカニズムによって送信されたバインディング更新の競合状態を検出及び解決するために、ホーム・エージェント内にアルゴリズムを導入することにある。ＨＡは第１に、所与のＭＮに関するモビリティ・メカニズムの変更を検出する必要がある。このモビリティ・メカニズム変更（すなわち、ＣＭＩＰからＰＭＩＰ又はＰＭＩＰからＣＭＩＰ）の検出は、異なるタイプのバインディング更新を連続して受信すること、すなわちＨＡが、ＰＢＵの後にＣＢＵを、又はＣＢＵの後にＰＢＵを受信する場合に基づく。これは、バインディング更新の競合状態が発生する可能性があるという第１のサインである。
【００５６】
さらにＨＡは、ＢＵ競合状態の検出を改良するために追加のメカニズムを実施することができる。本発明の第２の態様による実施の形態によれば、ＨＡは、異なるタイプのバインディング更新のそれぞれの到達時間の時間差を測定することができる。この時間が所与の時間制限よりも短い場合、すなわち、バインディング更新が互いの後に疑わしく接近して到達する場合、ＨＡは、バインディング更新間に競合状態が発生したものと結論付けることができる。ＨＡが競合状態に関して疑う場合、ＨＡは最終のＢＵを拒否し、結果として、例えば、バインディング・キャッシュ・エントリ内のＣｏＡ及び最終ＢＵ内のＣｏＡという両方のＣｏＡに対して、ＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］が示される、リフレッシュ・アドバイス・オプションを０に設定したバインディング確認であるＢＵ解決照会メッセージ（BU resolution query message）を送信する。その後、ＨＡは、現在のＭＮの位置からＢＵ解決回答メッセージ（BU resolution reply message）（ＣＢＵ又はＰＢＵ）を１つだけ受信し、このＢＵを通常の方法で処理する。
【００５７】
本発明の第２の態様による実施の形態は、モバイル・アンカー・ポイントでモバイル・ノードのモビリティを管理するための方法を提供し、上記モバイル・ノードは第１のネットワークと第２のネットワークとの間を移動し、上記第１のネットワークは、モバイル・ノードのモビリティを管理するためにモバイル・ノード・ベースのモビリティ管理スキームを使用し、上記第２のネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、上記モバイル・アンカー・ポイントは、モバイル・ノード・ベースのモビリティ管理スキーム及びネットワーク・ベースのモビリティ管理スキームの両方を実施し、上記方法は、第１のネットワーク内のモバイル・ノードの第１の位置に関する第１のメッセージをモバイル・ノードから受信するステップであって、モバイル・ノードは第１のＩＰアドレスを有するステップと、第２のネットワーク内のモバイル・ノードの第２の位置に関する第２のメッセージを第２のネットワーク内のネットワーク要素から受信するステップであって、モバイル・ノードは第２のＩＰアドレスを有するステップと、モバイル・ノードの第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するステップと、第１及び第２のＩＰアドレスのうちの少なくとも１つに対する応答メッセージを受信するステップと、受信した応答メッセージに基づいて、第１及び第２のＩＰアドレスのうちのどちらがモバイル・ノードの現行ＩＰアドレスであるかを決定するステップがモバイル・アンカー・ポイントによって実行されるステップを有する。
【００５８】
本発明の第２の態様による他の実施の形態は、モバイル・アンカー・ポイントでモバイル・ノードのモビリティを管理するための方法を提供し、上記モバイル・ノードは第１のネットワークと第２のネットワークとの間を移動し、上記第１及び第２のネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、上記モバイル・アンカー・ポイントは、ネットワーク・ベースのモビリティ管理スキームを実施し、上記方法は、第１のネットワーク内のモバイル・ノードの第１の位置に関する第１のメッセージを第１のネットワーク内の第１のネットワーク要素から受信するステップであって、モバイル・ノードは第１のＩＰアドレスを有するステップと、第２のネットワーク内のモバイル・ノードの第２の位置に関する第２のメッセージを第２のネットワーク内の第２のネットワーク要素から受信するステップであって、モバイル・ノードは第２のＩＰアドレスを有するステップと、モバイル・ノードの第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するステップと、第１及び第２のＩＰアドレスのうちの少なくとも１つに対する応答メッセージを受信するステップと、受信した応答メッセージに基づいて、第１及び第２のＩＰアドレスのうちのどちらがモバイル・ノードの現行ＩＰアドレスであるかを決定するステップがモバイル・アンカー・ポイントによって実行されるステップを有する。
【００５９】
本発明の第２の態様による他の実施の形態は、モバイル・ノードのモビリティを管理するためのモバイル・アンカー・ポイントを提供し、上記モバイル・ノードは第１のネットワークと第２のネットワークとの間を移動し、上記第１のネットワークは、モバイル・ノードのモビリティを管理するためにモバイル・ノード・ベースのモビリティ管理スキームを使用し、上記第２のネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、上記モバイル・アンカー・ポイントは、モバイル・ノード・ベースのモビリティ管理スキーム及びネットワーク・ベースのモビリティ管理スキームの両方を実施し、上記モバイル・アンカー・ポイントは、第１のネットワーク内のモバイル・ノードの第１の位置に関する第１のメッセージをモバイル・ノードから受信するための受信手段であって、モバイル・ノードは第１のＩＰアドレスを有し、第２のネットワーク内のモバイル・ノードの第２の位置に関する第２のメッセージを第２のネットワーク内のネットワーク要素から受信するための受信手段であって、モバイル・ノードは第２のＩＰアドレスを有する受信手段と、モバイル・ノードの第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するための送信手段とを備え、上記受信手段は、第１及び第２のＩＰアドレスのうちの少なくとも１つに対する応答メッセージを受信するように構成され、上記モバイル・アンカー・ポイントは、受信した応答メッセージに基づいて、第１及び第２のＩＰアドレスのうちのどちらがモバイル・ノードの現行ＩＰアドレスであるかを決定するための決定手段を更に有する。
【００６０】
本発明の第２の態様によるさらに他の実施の形態は、モバイル・ノードのモビリティを管理するためのモバイル・アンカー・ポイントを提供し、上記モバイル・ノードは第１のネットワークと第２のネットワークとの間を移動し、上記第１及び第２のネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、上記モバイル・アンカー・ポイントは、ネットワーク・ベースのモビリティ管理スキームを実施し、上記モバイル・アンカー・ポイントは、第１のネットワーク内のモバイル・ノードの第１の位置に関する第１のメッセージを第１のネットワーク内の第１のネットワーク要素から受信するための受信手段であって、モバイル・ノードは第１のＩＰアドレスを有し、第２のネットワーク内のモバイル・ノードの第２の位置に関する第２のメッセージを第２のネットワーク内の第２のネットワーク要素から受信するための受信手段であって、モバイル・ノードは第２のＩＰアドレスを有する受信手段と、モバイル・ノードの第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するための送信手段とを有し、上記受信手段は、第１及び第２のＩＰアドレスのうちの少なくとも１つに対する応答メッセージを受信するように構成され、上記モバイル・アンカー・ポイントは、受信した応答メッセージに基づいて、第１及び第２のＩＰアドレスのうちのどちらがモバイル・ノードの現行ＩＰアドレスであるかを決定するための決定手段を更に有する。
【００６１】
本発明の第２の態様による他の実施の形態は、第１のネットワークと第２のネットワークとの間を移動するモバイル・ノードを提供し、上記第１のネットワークは、モバイル・ノードのモビリティを管理するためにモバイル・ノード・ベースのモビリティ管理スキームを使用し、上記第２のネットワークは、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、上記モバイル・ノードは、第１のネットワーク内のモバイル・ノードの位置に関するメッセージをモバイル・ノードに対するモバイル・アンカー・ポイントに送信するための送信手段であって、モバイル・ノードは、第１のＩＰアドレスを有する送信手段と、モバイル・ノードの第１のＩＰアドレスに対するバインディング要求メッセージをモバイル・アンカー・ポイントから受信するための受信手段とを有し、上記送信手段は、受信したバインディング要求メッセージへの応答メッセージをモバイル・アンカー・ポイントに送信するように構成される。
【００６２】
本発明の第２の態様による他の実施の形態は、モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用するネットワーク内のネットワーク要素を提供し、上記ネットワーク要素は、ネットワーク内のモバイル・ノードの位置に関するメッセージをモバイル・ノードに対するモバイル・アンカー・ポイントに送信するための送信手段であって、モバイル・ノードは、ＩＰアドレスを有する送信手段と、モバイル・ノードのＩＰアドレスに対するバインディング要求メッセージをモバイル・アンカー・ポイントから受信するための受信手段とを有し、上記送信手段は、受信したバインディング要求メッセージへの応答メッセージをモバイル・アンカー・ポイントに送信するように構成される。
【００６３】
本発明の第３の態様の目的の１つは、通信相手ノードでモバイル・ノードに対するスプーフィングされたバインディング・キャッシュ・エントリの検出が可能なメカニズムを提案することである。以下で概説するように、１つの解決策は、モバイル・ノードのホーム・アドレス及び／又はその以前に登録された気付けアドレスに、バインディング更新に関するバインディング確認を送信することである可能性がある。さらに、通信相手ノードは、オプションで、他のバインディング確認を新しく登録された気付けアドレスに送信することができる。後者の例では、通信相手ノードが、新しい（スプーフィングされた可能性のある）気付けアドレスのみではなく、モバイル・ノードの以前に登録された気付けアドレス及び／又はそのホーム・アドレスにもバインディング確認を送信する場合、モバイル端末は、モバイル端末によって送信されていないバインディング更新に関するバインディング確認が受け取られたことを認識することによって、そのバインディング上での攻撃を検出することができる。
【００６４】
モバイル・ノードのスプーフィングされたバインディング・キャッシュ・エントリを検出するための他のオプションは、通信相手ノードが１つ又は複数の要求／送信要請されたか又は送信要請されていない（solicited or unsolicited）プローブ・メッセージをモバイル・ノードに送信するバインディング・テストとすることができる。これらのプローブ・メッセージは、通信相手ノードにあるそのバインディング・キャッシュ・エントリが（依然として）正しいかどうかを、モバイル・ノードがチェック／検出可能にすることができる。
【００６５】
本発明の第３の態様の他の目的は、たとえモバイル・ノードのホーム・エージェントがダウンした場合であっても、信号オーバヘッドを削減できる、及び／又は通信相手ノードへ気付けアドレスの承認された登録も可能にする、承認された気付けアドレス登録メカニズムを提案することである。本発明の第３の態様に従って提案されたメカニズムは、モバイル・ノード及び通信相手ノードによって暗号化生成アドレスが使用される必要がないという点で、有利な可能性がある。この態様により、いわゆる永続（permanent）トークン（又は永続キー生成トークン）が、バインディング更新の認証に使用される。様々な実施の形態では、こうした永続トークンがモバイル・ノード及び通信相手ノードでどのように生成可能であるか、並びに例えば、通信相手ノードでモバイル・ノードのバインディングへの攻撃の検出に応答した場合など、永続トークンをいつどのように更新するかについても考察する。
【００６６】
本発明の第３の態様による一実施の形態によれば、通信相手ノードでのモバイルに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための方法が提供される。この実施の形態では、モバイル・ノードが、そのホーム・ネットワーク内に少なくとも１つのホーム・アドレス、及びフォーリン・ネットワーク内に少なくとも１つの気付けアドレスを有するものと仮定される。この実施の形態では、通信相手ノードは、承認されたバインディング更新の受信に応答して、少なくとも１つのバインディング確認をモバイル・ノードに送信する。それによって、１つのバインディング確認が、そのホーム・ネットワーク内のモバイル・ノードのホーム・アドレスに向けて送られる。別の方法としては（又は、バインディング更新をモバイル・ノードのホーム・アドレスに送信することに加えて）、通信相手ノードは、承認されたバインディング更新によって登録解除された気付けアドレスに向けて１つのバインディング確認を送ることもできる。モバイル・ノードは、少なくとも１つのバインディング確認を受信し、モバイルに関する通信相手ノードにあるバインディング・キャッシュ・エントリがスプーフィングされているか否かを、少なくとも１つの受信されたバインディング確認に基づいて検出することができる。
【００６７】
本発明の第３の態様による他の実施の形態によれば、通信相手ノードは、更なるバインディング確認を、承認されたバインディング更新で提供された新しい気付けアドレスに向けて送ることができる。
【００６８】
本発明の第３の態様による一実施の形態では、モバイル・ノードによって送信された承認されたバインディング更新に関する少なくとも１つのバインディング確認が受信されたか否かをモバイル・ノードで判別することによって、モバイル・ノードに対するバインディング・キャッシュ・エントリが通信相手ノードでスプーフィングされたか否かが判別される。
【００６９】
本発明の第３の態様による他の実施の形態では、少なくとも１つの受信されたバインディング確認におけるシーケンス番号が、未確認の承認されたバインディング更新のシーケンス番号と一致するか否かをモバイル・ノードで判別することによって、モバイル・ノードに対するバインディング・キャッシュ・エントリが通信相手ノードでスプーフィングされたか否かが判別される。
【００７０】
本発明の第３の態様による他の実施の形態では、さらに、モバイル・ノードが登録されたホーム・エージェントがダウンしたことがモバイル・ノードで検出される。その場合、モバイル・ノードは、ホーム・エージェントがダウンしていることを通信相手ノードに通知することができる。
【００７１】
本発明の第３の態様による他の実施の形態は、通信相手ノードでモバイルに関するバインディング・キャッシュ・エントリがスプーフィングされたか否かを検出するための方法に関する。この実施の形態では、モバイル・ノードはフォーリン・ネットワーク内に少なくとも１つの気付けアドレスを有する。モバイル・ノード及び通信相手ノードは、バインディング・テストを実行する。このバインディング・テストは、送信側の通信相手ノードからモバイル・ノードへ、モバイル・ノードの気付けアドレスを使用してバインディング・テスト・メッセージを送信することを含んでいてもよい。通信相手ノードでスプーフィングされたバインディング・キャッシュ・エントリは、バインディング・テストに基づいて検出することができる。
【００７２】
この実施の形態の変形では、モバイル・ノードが、しきい値の期間内に通信相手ノードからバインディング・テスト・メッセージを受信しない場合、モバイル・ノードは、通信相手ノードで、モバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされたことを検出することが可能である。
【００７３】
実施の形態の他の変形では、バインディング・テスト・メッセージは、通信相手ノードによって送信された非送信要請メッセージとすることができる。さらに、バインディング・テスト・メッセージが定期的に送信されることがあらかじめ分かっていてもよい。
【００７４】
本発明の第３の態様による他の実施の形態では、通信相手ノードが、モバイル・ノードに送信するデータ・パケットを、例えば一時的に有していない場合、通信相手ノードによってバインディング・テスト・メッセージが送信される。
【００７５】
本発明の第３の態様による他の実施の形態では、バインディング・テストは、バインディング・テスト・メッセージを送信するように通信相手ノードに要求するために、モバイル・ノードから通信相手ノードへ少なくとも１つのバインディング・テスト要求メッセージを送信することを更に有する。この実施の形態の変形では、通信相手ノードからの１つ又は複数のプローブ・メッセージに対する応答が、モバイル・ノードによって受信されない場合、通信相手ノードでスプーフィングされたバインディング・キャッシュ・エントリをモバイル・ノードによって検出することができる。この実施の形態の他の変形では、バインディング・テストは、例えば、ＩＣＭＰエコー要求及び／又はＩＣＭＰエコー応答メッセージなどのＩＣＭＰプロトコルのメッセージを使用する。
【００７６】
本発明の第３の態様による他の実施の形態では、バインディング・テスト・メッセージはバインディング確認メッセージである。
【００７７】
本発明の第３の態様による他の実施の形態は、モバイル端末のバインディングで検出された攻撃に対する対応策を実行することに関する。例えば、モバイル・ノードは、通信相手ノードでスプーフィングされたバインディング・キャッシュ・エントリの検出に応答して、以下の対応策のうちの少なくとも１つを実行することができる。
【００７８】
１つの可能な対応策は、通信相手ノードでリターン・ルータビリティ手順を実行することである。この手順は、モバイル・ノードに暗号情報を提供することができる。リターン・ルータビリティ手順に続いて、モバイル端末は、スプーフィングされたバインディング・キャッシュ・エントリを修正するために、オーソライズされたバインディング更新を通信相手ノードに送信することができる。それにより、承認されたバインディング更新は、リターン・ルータビリティ手順を実行することによって取得された暗号情報を使用して認証される。オプションで、永続キー生成トークンは、リターン・ルータビリティ手順の一部として、モバイル・ノード及び通信相手ノードによって決定することができる。
【００７９】
他の可能な対応策として、モバイル・ノードが、スプーフィングされたバインディング・キャッシュ・エントリに関して通信相手ノードに通知してもよい。
【００８０】
他の対応策は、モバイル・ノードと通信相手ノードとの間でデータを交換する際に、ルート最適化を使用しない／もはや使用しないことである。本発明の第３の態様による例示的実施の形態によれば、これは、モバイル・ノードのバインディング上で攻撃が検出されると、モバイル・ノードと通信相手ノードとの間で交換されたすべてのデータが、モバイル・ノードのホーム・ネットワークを介して送信されることを含んでいてもよい。従って、通信相手は、もはやモバイル・ノードに対するバインディング・キャッシュ・エントリを有さないことになり、最終的に、攻撃ノードの可能性がある通信相手ノードでモバイル・ノードのバインディング・キャッシュ・エントリをスプーフィングするのを防止することになる。
【００８１】
通信相手ノードがスプーフィングされたバインディング・キャッシュ・エントリについて通知された場合、本発明の第３の態様による他の実施の形態によれば、通信相手ノードが、スプーフィングされたバインディング・キャッシュ・エントリ内の気付けアドレスを登録するための更なるバインディング更新をブロックすること、及び／又はスプーフィングされたバインディング・キャッシュ・エントリ内の気付けアドレスと同じか又は類似のプレフィックスを有する気付けアドレスを登録するための更なるバインディング更新をブロックすることが示唆される。これは、その現在の位置からの攻撃ノードが、通信相手ノードでのバインディング・キャッシュ・エントリ上でさらに攻撃を開始することが防止できるという利点を有するかもしれない。
【００８２】
本発明の第３の態様による他の実施の形態では、スプーフィングされたバインディング・キャッシュ・エントリについて通信相手ノードに通知するために、モバイル・ノードのホーム・エージェントは、モバイル・ノードからホーム・エージェントを介して通信相手ノードに送信されたメッセージを認証することができる。
【００８３】
本発明の第３の態様による他の実施の形態では、モバイル・ノードは、モバイル・ノード及び通信相手ノードに知られた少なくとも１つの永続キー生成トークンに基づいて、メッセージ認証コードを決定する。さらに、モバイル・ノードは、通信相手ノードに送信されることになる、承認されたバインディング更新に対するこのメッセージ認証コードを含むことができる。この承認されたバインディング更新は更にフラグを有し、このフラグが設定された場合、永続キー生成トークンに基づいてメッセージ認証コードの妥当性を検査することを通信相手ノードに指示することができる。永続キー生成トークンの使用によって、例えば、リターン・ルータビリティ手順においてホーム・アドレス・テストをスキップできる可能性があり、これは、モバイル・ノードのホーム・アドレスに関連付けられたそのホーム・ネットワーク内でモバイル・ノードにサービスを提供しているホーム・エージェントが、応答していないか又はダウンした場合、とりわけ有利な可能性がある。
【００８４】
メッセージ認証コードの生成は、例えば以下のように実施することができる。通信相手ノードは、気付けキー生成トークンを含むメッセージをモバイル・ノードに送信することができる。このメッセージを、現在通信相手ノードに登録されているモバイル・ノードの気付けアドレスに向けて送ることができる。このメッセージを受信すると、モバイル・ノードは、少なくとも永続キー生成トークンに基づいて、及び気付けキー生成トークンを使用して、メッセージ認証コードを決定することができる。
【００８５】
本発明の第３の態様による他の実施の形態では、モバイル・ノードは、通信相手ノードでモバイル・ノードに対する気付けアドレスを登録するために、承認されたバインディング更新を通信相手ノードに送信する。この承認されたバインディング更新は、メッセージ認証コードと、設定された場合に、永続キー生成トークンを決定することを通信相手ノードに指示するフラグとを備えることができる。
【００８６】
一般に、永続キー生成トークンは、有効性が有限であるか、場合によっては無限であるものとすることができる。
【００８７】
本発明の第３の態様による一実施の形態では、通信相手ノードによって決定される永続キー生成トークンは、モバイル・ノードによって決定される永続キー生成トークンと同一である。
【００８８】
本発明の第３の態様による他の実施の形態は、永続キー生成トークンの決定に関する。その決定は、例えば、モバイル・ノードのホーム・アドレスに向かって送られる通信相手ノードからのメッセージ内でモバイル・ノードに提供されるキー生成トークンであるホーム・キー生成トークン、及び／又はモバイル・ノードの気付けアドレスに向かって送られる通信相手ノードからのメッセージ内でモバイル・ノードに提供されるキー生成トークンである気付けキー生成トークンのうちの少なくとも１つに基づくものとすることができる。
【００８９】
本発明の第３の態様による１つの例示的実施の形態では、永続キー生成トークンの決定は、リターン・ルータビリティ手順のホーム・アドレス・テスト及び／又は気付けアドレス・テストにおいて、通信相手ノードによって提供される少なくとも１つのキー生成トークンに基づくものである。
【００９０】
前述のように、モバイル端末は、メッセージ認証コードを生成することができる。本発明の第３の態様による１つの例示的実施の形態によれば、モバイル・ノードは、モバイル・ノードのホーム・アドレスに向けて送られる通信相手ノードからのメッセージ内でモバイル・ノードに提供されるキー生成トークンであるホーム・キー生成トークン、及び、モバイル・ノードの気付けアドレスに向けて送られる通信相手ノードからのメッセージ内でモバイル・ノードに提供されるキー生成トークンである気付けキー生成トークンのうちの少なくとも１つに基づいて、メッセージ認証コードを決定する。
【００９１】
それ故、本発明の第３の態様による様々な実施の形態では、永続キー生成トークンがモバイル・ノード及び／又は通信相手ノードによって決定されることが予見される。
【００９２】
本発明の第３の態様による他の例示的実施の形態では、モバイル・ノードは、モバイル・ノードからの承認されたバインディング更新に関する少なくとも１つのバインディング確認の受信に応答して、永続キー生成トークンを決定することができる。
【００９３】
本発明の第３の態様による他の例示的実施の形態では、永続キー生成トークンは、モバイル・ノードからの承認されたバインディング更新の受信に応答して、通信相手ノードで決定される。承認されたバインディング更新は、それに応答してこの実施の形態により、永続キー生成トークンが決定されるものであり、例えば、設定された場合には、永続キー生成トークンを決定することを通信相手ノードに指示するフラグを備える。
【００９４】
本発明の第３の態様による他の実施の形態は、通信相手ノードでモバイル・ノードの気付けアドレスを登録するための方法に関する。この方法によれば、モバイル・ノード及び通信相手ノードは気付けアドレス・テストを実行可能であり、これによって、モバイル・ノードに気付けキー生成トークンが提供される。さらに、モバイル・ノードは、承認されたバインディング更新を通信相手ノードとの間で伝送可能であり、承認されたバインディング更新は、気付けキー生成トークンと、モバイル・ノード及び通信相手ノードに知られた永続キー生成トークンとに基づいてモバイル端末によって決定されたメッセージ認証コードを有する。
【００９５】
例えば、永続キー生成トークンは、ホーム・エージェントがダウンするのに先立って、最新の成功したホーム・アドレス・テストにおいてモバイル端末に提供されたホーム・キー生成トークンとすることができる（又はこれに基づいて生成することができる）。
【００９６】
本発明の第３の態様による他の実施の形態では、通信相手ノードは、承認されたバインディング更新に関する少なくとも１つのバインディング確認をモバイル・ノードに送信する。通信相手ノードは、宛先に向けて送られるこの少なくとも１つのバインディング確認を、承認されたバインディング更新によって登録解除された気付けアドレスに向けて送ることができる。
【００９７】
変形では、通信相手ノードは、通信相手ノードが、ホーム・エージェントがダウンしたことを検出するか、又はモバイル・ノードによって通知された場合（にのみ）、少なくとも１つのバインディング確認を、承認されたバインディング更新によって登録解除された気付けアドレスに向けて送ることができる。
【００９８】
本発明の第３の態様による他の実施の形態では、到達不可能なホーム・エージェントを検出するための幾つかのメカニズムが提案される。ホーム・エージェントは、以下のメカニズムのうちのいずれか１つ又は組合せによって、ダウンした（又は到達不可能である）ものとみなされるか、又は検出される。１つのオプションは、モバイル・ノードによってホーム・エージェントに送信された承認されたバインディング更新に関して、モバイル・ノードでバインディング確認が受信されないことをモバイル・ノードで検出することであろう。他のオプションは、このためにＩＰｓｅｃデッド・ピア検出手順を使用することである。本明細書で提案される他のオプションは、ホーム・エージェントに、又はこのホーム・エージェントに登録されたモバイル端末のホーム・アドレスに送信された１つ又は複数のプローブ・メッセージへの応答が受信されないことを、モバイル・ノード又は通信相手ノードによって検出することである。
【００９９】
本発明の第３の態様による他の実施の形態では、モバイル・ノードから通信相手ノードに通知メッセージを送信することによって、モバイル・ノードが登録されているホーム・エージェントがダウンしたことを、モバイル・ノードが通信相手ノードに通知することができる。
【０１００】
この通知メッセージがモバイル・ノードによって認証されることが有利な可能性がある。通知の認証には、ホーム・アドレス・テスト及び気付けアドレス・テストを含むリターン・ルータビリティ手順で以前に決定されたバインディング管理キーを使用することができる。
【０１０１】
さらに、モバイル・ノードによって通信相手ノードに送信される承認されたバインディング更新の一部として通知が送信されることを他のオプションとすることができる。
【０１０２】
さらに、本発明の第３の態様による他の実施の形態では、前述の本発明の第３の態様による様々な実施の形態に従って、通信相手ノードでモバイル・ノードの気付けアドレスを登録するための方法は、本明細書で説明された本発明の第３の態様による様々な実施の形態に従って、通信相手ノードでのモバイルに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための方法ステップを更に有してもよい。
【０１０３】
本発明の第３の態様による他の実施の形態は、通信相手ノードでのモバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するためのモバイル・ノードに関する。モバイル・ノードには、そのホーム・ネットワーク内の少なくとも１つのホーム・アドレス、及びフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられる。この例示的実施の形態によれば、モバイル・ノードは、通信相手ノードによって送信された少なくとも１つの確認を受信するための受信機を備える。通信相手ノードは、そのホーム・ネットワーク内のモバイル・ノードのホーム・アドレスに向けて１つのバインディング確認を、及び／又は承認されたバインディング更新によって登録解除された気付けアドレスに向けて１つのバインディング確認を送っている。さらにモバイル・ノードは、少なくとも１つの受信されたバインディング確認に基づいて、モバイルに関する通信相手ノードでのバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための処理ユニットを有していてもよい。
【０１０４】
本発明の第３の態様による他の実施の形態では、モバイル・ノードは、通信相手ノードでのモバイルに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための任意の方法、及び／又は本明細書に記載された様々な実施の形態のうちの１つに従って、通信相手ノードでモバイル・ノードの気付けアドレスを登録するための方法に関する方法ステップを実行するか又はこれらに関与するように構成された手段を備えることができる。
【０１０５】
本発明の第３の態様による他の実施の形態は、モバイル・ノードに対するバインディング・キャッシュ・エントリを維持するための通信相手ノードに関する。他の実施の形態と同様に、モバイル・ノードには、そのホーム・ネットワーク内の少なくとも１つのホーム・アドレス及びフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられるものと仮定することができる。通信相手ノードは、承認されたバインディング更新の受信に応答して、少なくとも１つのバインディング確認をモバイル・ノードに送信するための通信ユニット（例えば、送信機を含む）を有することができる。それにより、通信相手ノードは、そのホーム・ネットワーク内のモバイル・ノードのホーム・アドレス、及び／又は承認されたバインディング更新によって通信相手ノードのバインディング・キャッシュから登録解除された気付けアドレスに向けて、１つのバインディング確認を送る。
【０１０６】
本発明の第３の態様による他の実施の形態では、通信相手ノードは、通信相手ノードでのモバイルに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための方法、及び／又は本明細書に記載された様々な実施の形態のうちの１つに従って、通信相手ノードでモバイル・ノードの気付けアドレスを登録するための方法に関する方法ステップを実行するか、又はこれらに関与するように構成された手段を有する。
【０１０７】
本発明の第３の態様による他の実施の形態は、通信相手ノードでのモバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための他のモバイル・ノードに関する。ここで、モバイル・ノードには、フォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられる。この実施の形態によるモバイル・ノードは、モバイル・ノードの気付けアドレスに向けて送られたバインディング・テスト・メッセージを通信相手ノードから受信することを含むバインディング・テストを実行するための通信手段を有することができる。さらに端末は、バインディング・テストに基づいて通信相手ノードでスプーフィングされたバインディング・キャッシュ・エントリを検出するための処理ユニットを含んでいてもよい。
【０１０８】
本発明の第３の態様による他の実施の形態は、モバイル・ノードに対するバインディング・キャッシュ・エントリを維持するための他の通信相手ノードを提供する。ここでも、モバイル・ノードには、フォーリン・ネットワーク内の少なくとも１つの気付けアドレスを割り当てることが可能である。この例示的実施の形態による通信相手ノードは、バインディング・テストの一部としてモバイル・ノードから少なくとも１つのバインディング・テスト要求メッセージを受信するための受信機と、バインディング・テストの一部として、少なくとも１つのバインディング・テスト要求メッセージに応答して、モバイル・ノードの気付けアドレスに向けて送られるバインディング・テスト・メッセージを送信するための送信機とを含んでいてもよい。
【０１０９】
本発明の第３の態様による他の実施の形態は、モバイル・ノード及び通信相手ノードによって気付けアドレス・テストを実行し、それによってモバイル・ノードに気付けキー生成トークンを提供するための通信ユニットを備えた通信相手ノードで気付けアドレスを登録するためのモバイル・ノードに関する。さらに、この通信ユニットは、モバイル・ノードからモバイル・ノードへと承認されたバインディング更新を送信するように動作可能とすることができる。この承認されたバインディング更新は、気付けキー生成トークンと、モバイル・ノード及び通信相手ノードに知られた永続キー生成トークンとに基づいて、モバイル端末によって決定されたメッセージ認証コードを含んでいてもよい。
【０１１０】
本発明の第３の態様による他の実施の形態による他の通信相手ノードは、モバイル・ノードに対する気付けアドレスを登録する際に使用することができる。この通信相手ノードは、モバイル・ノード及び通信相手ノードによって気付けアドレス・テストを実行し、それによってモバイル・ノードに気付けキー生成トークンを提供するための通信ユニットを有することができる。この通信ユニットは、例えば、モバイル・ノードからモバイル・ノードへと承認されたバインディング更新を受信するように動作可能とすることが可能であり、承認されたバインディング更新は、気付けキー生成トークンと、モバイル・ノード及び通信相手ノードに知られた永続キー生成トークンとに基づいて、モバイル端末によって決定されたメッセージ認証コードを含む。
【０１１１】
さらに、本発明の第３の態様による他の実施の形態は、本明細書で説明された本発明の様々な実施の形態のうちの１つに従ったモバイル・ノード及び／又は通信相手ノードを有するモバイル通信システムに関する。
【０１１２】
本発明の第３の態様による他の実施の形態は、モバイル・ノードのプロセッサによって実行された場合、通信相手ノードでのモバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされているか否かをモバイル・ノードに検出させる命令を格納するコンピュータ読み取り可能媒体を提供する。１つの例示的実施の形態によれば、モバイル・ノードには、そのホーム・ネットワーク内の少なくとも１つのホーム・アドレス、及びフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられる。本発明のこの実施の形態に従ってコンピュータ読み取り可能媒体上に格納された命令は、モバイル・ノードの処理ユニットによって実行された場合、通信相手ノードによって送信された少なくとも１つのバインディング確認のうちの少なくとも１つをモバイル・ノードに受信させる。１つのバインディング確認が、そのホーム・ネットワーク内のモバイル・ノードのホーム・アドレスに向けて送られ、及び／又は１つのバインディング確認が、承認されたバインディング更新によって登録解除された気付けアドレスに向けて送られている。さらにこの命令は、少なくとも１つの受信されたバインディング更新に基づいて、通信相手ノードでのモバイルに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かをモバイル・ノードに検出させることができる。
【０１１３】
本発明の第３の態様による他の実施の形態は、通信相手ノードのプロセッサによって実行された場合、通信相手ノードにモバイル・ノードに対するバインディング・キャッシュ・エントリを維持させる命令を格納するコンピュータ読み取り可能媒体を提供し、ここで、モバイル・ノードには、そのホーム・ネットワーク内の少なくとも１つのホーム・アドレス、及びフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられる。これは、承認されたバインディング更新の受信に応答して、少なくとも１つのバインディング確認をモバイル・ノードに送信するよう通信相手ノードに実行させることによって実現可能であり、ここでは、１つのバインディング確認が、そのホーム・ネットワーク内のモバイル・ノードのホーム・アドレスに向けて送られ、及び／又は１つのバインディング確認が、承認されたバインディング更新によって登録解除されたモバイル・ノードの気付けアドレスに向けて送られる。
【０１１４】
本発明の第３の態様による他の実施の形態による他のコンピュータ読み取り可能媒体は、モバイル・ノードのプロセッサによって実行された場合、通信相手ノードでのモバイル・ノードに対するバインディング・キャッシュ・エントリがスプーフィングされているか否かをモバイル・ノードに検出させる命令を格納し、ここで、モバイル・ノードの気付けアドレスに向けて送られたバインディング・テスト・メッセージを通信相手ノードから受信することを含むバインディング・テストを実行すること、及び、バインディング・テストに基づいて、通信相手ノードでスプーフィングされたバインディング・キャッシュ・エントリを検出することによって、モバイル・ノードにフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられる。
【０１１５】
本発明の第３の態様による他の実施の形態による他のコンピュータ読み取り可能媒体は、通信相手ノードのプロセッサによって実行された場合、通信相手ノードにモバイル・ノードに対するバインディング・キャッシュ・エントリを維持させる命令を格納し、ここで、少なくとも１つのバインディング・テスト要求メッセージをバインディング・テストの一部としてモバイル・ノードから受信すること、及び、少なくとも１つのバインディング・テスト要求メッセージに応答して、バインディング・テスト・メッセージを、モバイル・ノードの気付けアドレスに向けて、バインディング・テストの一部として送信することによって、モバイル・ノードにフォーリン・ネットワーク内の少なくとも１つの気付けアドレスが割り当てられる。
【０１１６】
本発明の第３の態様による他の実施の形態は、モバイル・ノード及び通信相手ノードによって気付けアドレス・テストを実行し、それによって、気付けキー生成トークンをモバイル・ノードに提供し、モバイル・ノードからモバイル・ノードへと承認されたバインディング更新を送信することによって、モバイル・ノードのプロセッサによって実行された場合、通信相手ノードでの気付けアドレスをモバイル・ノードに登録させる命令を格納するコンピュータ読み取り可能媒体を提供し、ここで、承認されたバインディング更新は、気付けキー生成トークンとモバイル・ノード及び通信相手ノードに知られた永続キー生成トークンとに基づいてモバイル端末によって決定されたメッセージ認証コードを含む。
【０１１７】
本発明の第３の態様による他の実施の形態は、モバイル・ノード及び通信相手ノードによって気付けアドレス・テストを実行し、それによって、気付けキー生成トークンをモバイル・ノードに提供し、モバイル・ノードからモバイル・ノードへと承認されたバインディング更新を受信することによって、通信相手ノードのプロセッサによって実行された場合、モバイル・ノードに対する気付けアドレスを通信相手ノードに登録させる命令を格納するコンピュータ読み取り可能媒体に関し、ここで、承認されたバインディング更新は、気付けキー生成トークンとモバイル・ノード及び通信相手ノードに知られた永続キー生成トークンとに基づいてモバイル端末によって決定されたメッセージ認証コードを含む。
【０１１８】
本発明の第３の態様による他の実施の形態は、モバイル・ノード又は通信相手ノードのプロセッサによって実行された場合、モバイル・ノード又は通信相手ノード、それぞれに、通信相手ノードでのモバイルに関するバインディング・キャッシュ・エントリがスプーフィングされているか否かを検出するための方法、及び／又は本明細書に記載された様々な実施の形態のうちの１つに従って、通信相手ノードでモバイル・ノードの気付けアドレスを登録するための方法に関する方法ステップを実行させるか又はこれらに関与させる命令を格納するコンピュータ読み取り可能媒体を提供する。
【図面の簡単な説明】
【０１１９】
以下で、添付の図面を参照しながら本発明についてより詳細に説明する。図面内の類似の又は対応する細部は、同じ参照番号でマーク付けされている。
【０１２０】
【図１】接続されていないモバイル・ノードに向けて送られたトラフィックを宛先変更する、危険にさらされたモバイル・アクセス・ゲートウェイの例を示す図である。
【図２】第１の態様に従って、本発明の第１の実施の形態による信号フローの例を示す図であり、ＰＭＩＰドメイン内の危険にさらされたモバイル・アクセス・ゲートウェイは、ＰＭＩＰドメイン外部に位置するモバイル・ノードに向けて送られたトラフィックを宛先変更するように試行する。
【図３】第１の態様に従って、本発明の第１の実施の形態による信号フローの例を示す図であり、ＰＭＩＰドメイン内の危険にさらされたモバイル・アクセス・ゲートウェイは、ＰＭＩＰドメイン内部に位置するモバイル・ノードに向けて送られたトラフィックを宛先変更するように試行する。
【図４】第１の態様に従って、本発明の第２の実施の形態による信号フローの例を示す図であり、ＰＭＩＰドメイン内の危険にさらされたモバイル・アクセス・ゲートウェイは、ＰＭＩＰドメイン外部に位置するモバイル・ノードに向けて送られたトラフィックを宛先変更するように試行する。
【図５】第１の態様に従って、本発明の第２の実施の形態による信号フローの例を示す図であり、ＰＭＩＰドメイン内の危険にさらされたモバイル・アクセス・ゲートウェイは、ＰＭＩＰドメイン内部に位置するモバイル・ノードに向けて送られたトラフィックを宛先変更するように試行する。
【図６】初期接続中のＰＭＩＰｖ６に関する例示的信号フローを示す図である。
【図７】ＣＭＩＰベースのネットワーク・ドメインからＰＭＩＰベースのネットワーク・ドメインへのハンドオーバ（ＣＭＩＰからＰＭＩＰへのモビリティ遷移）中の、ＰＭＩＰｖ６に関する例示的信号フローを示す図である。
【図８】同じ位置に配置されたＰＭＩＰ／ＣＭＩＰ−ＨＡシナリオを示す図である。
【図９】ＣＭＩＰからＰＭＩＰへのモビリティ遷移におけるＢＵ競合状態の例を示す図である。
【図１０】ＰＭＩＰからＣＭＩＰへのモビリティ遷移におけるＢＵ競合状態の例を示す図である。
【図１１】本発明の第２の態様による、ＣＭＩＰからＰＭＩＰへのモビリティ遷移におけるＢＵ競合状態シナリオの解決策を示す図である。
【図１２】本発明の第２の態様による、ＰＭＩＰからＣＭＩＰへの遷移におけるＢＵ競合状態シナリオの解決策を示す図である。
【図１３】ＢＵの到達は適切（順序）であるが、本発明の第２の態様によるＢＵ競合状態の検出例を示す図である。
【図１４】本発明の第２の態様による、最新ＢＵの解決手順をサポートするために必要なプロセス（オプションも）を示す、ＰＭＡにおける例示的フローチャートである。
【図１５】ＭＩＰｖ６による、モバイル・ノードと通信相手ノードとの間の通信に関する双方向トンネリングの使用を例証する図である。
【図１６】ＭＩＰｖ６による、モバイル・ノードと通信相手ノードとの間の通信に関するルート最適化の使用を例証する図である。
【図１７】ＭＩＰｖ６による、フォーリン・ネットワークにおける新しい気付けアドレスの取得時にモバイル・ノードによって実行されるアクションを示す図である。
【図１８】ＭＩＰｖ６による、モバイル・ノードと通信相手によって実行されるリターン・ルータビリティ手順及び気付けアドレス登録を示す図である。
【図１９】本発明の第３の態様による例示的実施の形態に従い、モバイル・ノードのホーム・ネットワークを介して送信されたバインディング確認に基づいて、通信相手ノードでそのバインディング上の攻撃をモバイル・ノードが検出できるようにする攻撃者、モバイル・ノード、通信相手ノード、及びホーム・エージェントの間で交換されるメッセージの例示的シーケンスを示す図である。
【図２０】本発明の第３の態様による例示的実施の形態に従い、バインディング・テストに基づいて、通信相手ノードでそのバインディング上の攻撃をモバイル・ノードが検出できるようにする攻撃者、モバイル・ノード、通信相手ノード、及びホーム・エージェントの間で交換されるメッセージの例示的シーケンスを示す図である。
【図２１】本発明の第３の態様による例示的実施の形態に従い、改良されたリターン・ルータビリティ手順及び後続の気付けアドレス登録に従って、モバイル・ノード、通信相手ノード、及びホーム・エージェントの間で交換されるメッセージの例示的シーケンスを示す図である。
【図２２】永続トークンが認証に使用される、本発明の第３の態様による例示的実施の形態に従い、通信相手ノードの気付けアドレスを登録するために、モバイル・ノードと通信相手ノードとの間で交換されるステップ及びメッセージのシーケンスを示す図である。
【図２３】永続トークンが認証に使用される、本発明の第３の態様による例示的実施の形態に従い、通信相手ノードの気付けアドレスを登録するために、モバイル・ノード、ホーム・エージェント、及び通信相手ノードの間で交換されるステップ及びメッセージの他のシーケンスを示す図である。
【図２４】永続トークンが認証に使用され、モバイル・ノードが、攻撃者が通信相手ノードに対するそのバインディング・キャッシュ・エントリをスプーフィングしたことを検出する、本発明の第３の態様による例示的実施の形態に従い、モバイル・ノード、攻撃者、ホーム・エージェント、及び通信相手ノードの間で交換されるステップ及びメッセージの他のシーケンスを示す図である。
【発明を実施するための形態】
【０１２１】
以下の段落で、本発明の様々な態様について説明する。さらに、幾つかの実施の形態について説明する。単なる例示の目的で、ほとんどの実施の形態は、前述の背景分野のセクションで考察したように、ＭＩＰｖ６を使用する通信ネットワークとの関係で概説するが、本発明は、この特定の例示的通信ネットワークの使用に限定されるものではない。
【０１２２】
従って、本明細書で使用される用語も、主に、Ｍｏｂｉｌｅ  ＩＰｖ６の標準化でＩＥＴＦによって使用された用語に基づいている。しかし、Ｍｏｂｉｌｅ  ＩＰｖ６に関連したこの用語及び実施の形態の説明は、本発明の原理及び観念を、こうしたシステム及びこのプロトコルのみの使用に限定することを意図するものではない。
【０１２３】
前述の技術的背景のセクションで与えられた説明は、本明細書で説明される特定の例示的実施の形態をより良く理解することを意図するものであり、本発明を、モバイル通信ネットワークにおける説明された特定のプロセス及び機能の実施態様に限定するものであると解釈されるべきではない。それにもかかわらず、本明細書で提案された改良点は、技術的背景のセクションで説明されたプロトコル／システムで容易に適用可能であり、本発明の幾つかの実施の形態では、これらのプロトコル／システムの標準的及び改良された手順も使用可能である。
【０１２４】
次に、本明細書で頻繁に使用される幾つかの用語の定義について説明する。
【０１２５】
通信相手ノード又はモバイル・ノードとは、通信ネットワークにおける物理エンティティである。１つのノードが幾つかの機能エンティティを有することができる。機能エンティティとは、ノード又はネットワークの他の機能エンティティに所定の機能セットを実施及び／又は提供するソフトウェア又はハードウェア・モジュールを意味する。ノードは、ノードが通信の際に介することが可能な通信設備又は媒体にノードを接続する１つ又は複数のインターフェイスを有することができる。同様に、ネットワーク・エンティティは、他の機能エンティティ又はノードとの通信の際に介することが可能な通信設備又は媒体に機能エンティティを接続する論理インターフェイスを有することができる。
【０１２６】
ノード又は機能エンティティのアドレスは、永続的であるか又は有効性が一時的に制限されたノード又は機能エンティティのグローバル又はサイトローカル識別子である。通常、本明細書の幾つかの実施の形態では、アドレスはネットワーク層アドレスであり、すなわち、ＯＳＩ基準モデルのネットワーク層上にあるノード及びネットワーク・エンティティの識別に使用される（例えば、参照により本明細書に組み込むものとする、Ａｎｄｒｅｗ  Ｓ．Ｔａｎｅｎｂａｕｍによるテキストブック「Ｃｏｍｐｕｔｅｒ  Ｎｅｔｗｏｒｋｓ」第４版、２００３、Ｐｒｅｎｔｉｃｅ  Ｈａｌｌ  ＰＴＲ、１．４章を参照のこと）。ネットワーク層又はレイヤ３は、通常、１つ又は複数のネットワークを介してソースから宛先へと可変長パケットを転送するための機能及び手順手段を提供する。
【０１２７】
通常、ノードのインターフェイスには１つのアドレスが割り当てられる。しかし、複数のアドレスを１つのインターフェイスに割り当てることも可能である。さらに、複数の機能エンティティを備えるノードの場合、それぞれの機能エンティティの論理インターフェイスに１つ又は複数のアドレスを関連付けることができる。
【０１２８】
一般に、各ネットワークは、少なくとも１つの番号、例えば、いわゆるプレフィックスによって識別される。この番号は、ネットワーク内でのノードへのパケットのルーティングを可能にする。さらに、この番号は、ネットワーク内でノードによって使用可能な識別子のプールを言い表す。ネットワーク内のアドレスは、識別子のプールからの識別子である。例えばＩＰｖ６では、ネットワークの番号はＩＰｖ６プレフィックスであり、ネットワーク内のアドレスは、ＩＰｖ６プレフィックス及びＩＰｖ６ホスト部分からなるＩＰｖ６アドレスである。異なるネットワークでは、例えばホーム・ネットワーク及びフォーリン・ネットワークにおいて、異なるアドレスが使用される。
【０１２９】
モバイル・ノードのホーム・ネットワークは、通常、モバイル・ノードが、モバイル・ノードの所与のホーム・アドレスに対するその気付けアドレスを登録するホーム・エージェントの位置によって識別される。
【０１３０】
ホーム・アドレスは、モバイル・ノードの永続アドレスとして使用される、モバイル・ノードに割り当てられたアドレスである。このアドレスは、モバイル・ノードのホーム・ネットワーク内で定義される。モバイル・ノードは、例えば、複数のホーム・ネットワークが存在するか、又はモバイル・ノードが単一のホーム・ネットワーク内に複数のホーム・アドレスを有することができる場合、複数のホーム・アドレスを有することができる。
【０１３１】
気付けアドレスは、フォーリン・ネットワークを訪問中に、モバイル・ノードに関連付けられるアドレスである。モバイル・ノードは、１つ又は複数の気付けアドレスを同時に有することができる。
【０１３２】
バインディングは、モバイル・ノードのホーム・アドレスとそのモバイル・ノードに対する気付けアドレスとの関連付けである。本発明の幾つかの実施の形態では、その関連付けの残りの存続期間をバインディングの一部とすることも可能である。バインディングは登録によって生成され、この登録は、その間にモバイル・ノード又はプロキシがモバイル・ノードのホーム・エージェント又は通信相手ノードにバインディング更新を送信し、モバイル・ノードに対するバインディングが登録されることになるプロセスを表す。バインディングは、例えば、それぞれ、モバイル・ノードのホーム・エージェント又は通信相手ノードのバインディング・キャッシュに格納することができる。承認されたバインディング更新は、バインディングを登録するためのメッセージである。バインディングの登録は、例えば、メッセージ認証コード（ＭＡＣ）又は他の認証メカニズム（例えば、公開／秘密鍵のペアによるバインディング更新の署名）によって、承認されたバインディング更新の送信者を認証することによって承認される。
【０１３３】
本発明の幾つかの実施の形態では、ＩＰｖ６プロトコルがネットワーク層上で使用される。この場合、アドレスはノードの単一の（論理）インターフェイスに関する識別子であるため、結果として他のＩＰｖ６サブネットからそこへ送信されるパケットは、そのアドレスによって識別された（論理）インターフェイスへの低位層リンクを介して送達される。
【０１３４】
ホーム・エージェントは、モバイル・ノードがその現在の気付けアドレスを登録する際に使用するモバイル・ノードのホーム・ネットワーク上にルーティング機能を提供するルータ又は機能エンティティである。モバイル・ノードがホームから遠い間、ホーム・エージェントは、モバイル・ノードのホーム・アドレスに向けて送られたホーム・リンク上のパケットをインターセプトし、それらをカプセル化して、それらをモバイル・ノードの登録済み気付けアドレスのうちの１つ又は幾つかにトンネリングすることができる。
【０１３５】
ルート最適化が使用される場合、モバイル・ノード及び通信相手ノードは、モバイル・ノードのホーム・ネットワークを同じように通過することなく、データ・パケットを直接交換する。その代わりに通信相手ノードは、通信相手ノードのバインディング・キャッシュ内に登録されたモバイル・ノードの気付けアドレスに、データ・パケットを送信する。同様にモバイル・ノードも、そのホーム・ネットワークを介して（すなわち、ホーム・エージェントを介して）通信相手ノードへデータ・パケットを送信することはないが、データ・パケットを通信相手ノードのアドレスに向けて直接送信する。
【０１３６】
以下で、本発明の第１の態様について説明する。
【０１３７】
第１の態様については、ローカル・モビリティ・アンカー及びホーム・エージェントの機能が同じ物理エンティティ内で同じ位置に配置された状況に関して説明される。従って「ローカル・モビリティ・アンカー」及び「ホーム・エージェント」という用語は、相互に交換可能に使用されることになる。さらに、この第１の態様による本発明については、モバイル・ノードがアプリケーション・セッション中にネットワーク・ベースのモビリティ管理スキームとホスト・ベースのモビリティ管理スキームとの間で交換可能な状況に関して説明される。使用可能なネットワーク・ベースのモビリティ管理スキームの例は、Ｓ．Ｇｕｎｄａｖｅｌｌｉ、Ｋ．Ｌｅｕｎｇ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、Ｋ．Ｃｈｏｗｄｈｕｒｙ、Ｂ．Ｐａｔｉｌによる、Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６、ｄｒａｆｔ−ｓｇｕｎｄａｖｅ−ｍｉｐ６−ｐｒｏｘｙｍｉｐ６−０２、２００７年３月に定義されたような、ＰＭＩＰｖ６プロトコルである。しかし、この第１の態様による本発明は、このプロトコルに限定されるものではなく、ＰＭＩＰｖ４又はＰＭＩＰの他の変形などの他のネットワーク・ベースのモビリティ管理スキームが使用可能である。
【０１３８】
以下で、第１の態様による本発明の２つの実施の形態について説明する。第１の実施の形態は図２及び図３に関して説明され、第２の実施の形態は図４及び図５に関して説明される。
【０１３９】
第１の態様による第１の実施の形態の第１の変形について、図２に関して説明する。モバイル・ノードは、クライアント・ベースのモビリティ管理スキームを実施するドメイン内に位置する。それ故、モバイル・ノードは、バインディング更新メッセージＢＵをローカル・モビリティ・アンカーＬＭＡに送信することによって、その位置を通信する。ローカル・モビリティ・アンカーＬＭＡは、第１に、バインディング更新メッセージＢＵに含まれる認証情報をチェックして、このバインディング更新ＢＵが信用できることを識別する。バインディング更新が受け入れられた後、ローカル・モビリティ・アンカーＬＭＡは、気付けアドレスがローカル・モビリティ・アンカーＬＭＡのバインディング・キャッシュ・エントリ内に保存されたことを確認するために、バインディング更新ＢＵに含まれるモバイル・ノードの気付けアドレスにバインディング確認メッセージＢＡを送信する。
【０１４０】
図２は、ネットワーク・ベースのモビリティ管理スキームを実施するドメイン内の危険にさらされたモバイル・アクセス・ゲートウェイによる、モバイル・ノードに向けて送られたトラフィックを宛先変更する試行を示す。モバイル・アクセス・ゲートウェイは、偽のプロキシ・バインディング更新メッセージＰＢＵをローカル・モビリティ・アンカーＬＭＡに送信する。ローカル・モビリティ・アンカーは、モバイル・ノードの古い気付けアドレスを、偽のプロキシ・バインディング更新ＰＢＵに含まれたモバイル・アクセス・ゲートウェイの新しい気付けアドレスに置き換えることによって、そのバインディング・キャッシュ・エントリを対応的に更新する。その後、ローカル・モビリティ・アンカーＬＭＡは、プロキシ・バインディング確認メッセージＰＢＡを、危険にさらされたモバイル・アクセス・ゲートウェイの気付けアドレスに送信する。さらに、ローカル・モビリティ・アンカーＬＭＡは、危険にさらされたモバイル・アクセス・ゲートウェイの新しく保存された気付けアドレスに送信されたプロキシ・バインディング確認メッセージＰＢＡに加えて、バインディング確認ＢＡ’を、バインディング・キャッシュ・エントリに以前に保存されたモバイル・ノードの気付けアドレスに送信する。
【０１４１】
モバイル・ノードは、受信したバインディング確認メッセージＢＡ’と、モバイル・ノードがローカル・モビリティ・アンカーＬＭＡに以前に送信したバインディング更新メッセージとを比較することによって、危険にさらされたモバイル・アクセス・ゲートウェイによってトラフィックを宛先変更する試行を検出することができる。モバイル・ノードが、ローカル・モビリティ・アンカーＬＭＡに送信したいかなるバインディング更新にも対応しないバインディング確認メッセージに気付いた場合、モバイル・ノードは、危険にさらされたモバイル・アクセス・ゲートウェイによるトラフィックの宛先変更の試行の可能性を検出する。
【０１４２】
モバイル・ノードは、以前に送信されたバインディング更新メッセージに関する情報を含むバインディング更新リストを調べることによって、バインディング確認メッセージがバインディング更新メッセージに対応するか否かをチェックすることができる。
【０１４３】
第１の態様による本発明の実施の形態によれば、バインディング更新メッセージ及びバインディング確認メッセージのそれぞれのシーケンス番号が互いに等しく、この特定のバインディング更新に関するバインディング確認メッセージがこれまで受信されていない場合、すなわち、このバインディング確認メッセージが最初に受信されたものである場合、バインディング確認メッセージは、特定のバインディング更新メッセージに対応するものとして定義される。しかし、バインディング更新メッセージをバインディング確認メッセージにマッピングする他の方法が使用可能である。
【０１４４】
図２に示された例では、モバイル・ノードは第１に、その位置を示すためのバインディング更新メッセージＢＵをローカル・モビリティ・アンカーＬＭＡに送信する。このバインディング更新メッセージＢＵは、１に等しいシーケンス番号ＳＮを含む。ローカル・モビリティ・アンカーＬＭＡによって送信されたバインディング確認メッセージＢＡは、値１を有するシーケンス番号を含むため、モバイル・ノードによって送信されたバインディング更新メッセージＢＵに対応する。
【０１４５】
しかし、危険にさらされたモバイル・アクセス・ゲートウェイは、モバイル・ノードからのバインディング更新メッセージ内のシーケンス番号の値を取得できない。従って、危険にさらされたモバイル・アクセス・ゲートウェイによってローカル・モビリティ・アンカーＬＭＡに送信されたプロキシ・バインディング更新メッセージＰＢＵは、モバイル・ノードからのバインディング更新メッセージのシーケンス番号値とは異なるシーケンス番号値を有する。図２の例では、プロキシ・バインディング更新メッセージＰＢＵは、シーケンス番号値２を有する。ローカル・モビリティ・アンカーＬＭＡは、シーケンス番号値２を有するプロキシ・バインディング更新メッセージＰＢＵへの応答として、プロキシ・バインディング確認ＰＢＡを、モバイル・アクセス・ゲートウェイの気付けアドレスに送信する。さらに、ローカル・モビリティ・アンカーＬＭＡは、他のバインディング確認メッセージＢＡ’を、以前にバインディング・キャッシュ・エントリ内に保存されたモバイル・ノードの気付けアドレスに送信する。この他のバインディング確認メッセージＢＡ’は、シーケンス番号２を有する。
【０１４６】
モバイル・ノードは、ローカル・モビリティ・アンカーＬＭＡからバインディング確認メッセージＢＡ’を受け取ると、バインディング確認メッセージＢＡ’と以前に送信されたバインディング更新メッセージＢＵとを比較する。モバイル・ノードは、バインディング更新メッセージＢＵのシーケンス番号が値１を有し、バインディング確認メッセージＢＡ’の番号は２であるため、それぞれのメッセージのシーケンス番号が対応しないことに気付く。従って、モバイル・ノードは攻撃を検出する。
【０１４７】
さらに、モバイル・アクセス・ゲートウェイが、モバイル・ノードとローカル・モビリティ・アンカーとの間で交換されたシーケンス番号の現行値を取り出すことができた場合、モバイル・アクセス・ゲートウェイは、モバイル・ノードによって送信されたバインディング更新メッセージの番号値に対応するシーケンス番号値、すなわち値１を有するバインディング確認メッセージＢＡ’を送信することが可能であった。しかし、モバイル・ノードは、バインディング更新リストを調べることによって、シーケンス番号値１を有する、従ってバインディング更新メッセージＢＵに対応するバインディング確認ＢＡが、すでに受信されていることに気付くことになった。従って、モバイル・ノードは、バインディング確認メッセージＢＡ’が、シーケンス番号値１を有するモバイル・ノードによって受信された第２のバインディング確認メッセージであることに気付くことになった。
【０１４８】
従って、モバイル・ノードは、バインディング確認メッセージを受信すると、モバイル・ノードが、受信したバインディング確認メッセージに対応するバインディング更新メッセージを送信していなかった場合、すなわち、モバイル・ノードが、これまでにバインディング確認が受信されていない、受信したバインディング確認メッセージと同じシーケンス番号を備えるいかなるバインディング更新も見つけられない場合、トラフィック宛先変更の試行を検出する。
【０１４９】
モバイル・ノードがプロキシ・モバイルＩＰホーム・ドメインに入るケースでは、モバイル・ノードは、トラフィック宛先変更の試行を検出した場合、他の条件を考慮すべきである。受信したバインディング確認メッセージが以前に送信されたいかなるバインディング更新メッセージにも対応しない場合、及びモバイル・ノードがホームにいない場合、すなわち、モバイル・ノードが接続されているアクセス・ルータによって通知されたプレフィックスが、モバイル・ノードのホーム・プレフィックスでない場合にのみ、攻撃を検出するべきである。第２の条件は、モバイル・ノードがＰＭＩＰホーム・ドメインに入った場合、攻撃の誤った検出を防ぐことができる。
【０１５０】
モバイル・ノードは攻撃を検出すると、モバイル・ノードの気付けアドレスを含む新しいバインディング更新メッセージＢＵ’をローカル・モビリティ・アンカーＬＭＡに送信し、バインディング・キャッシュ・エントリを、危険にさらされたモバイル・アクセス・ゲートウェイの保存済み気付けアドレスから、モバイル・ノードの気付けアドレスに訂正する。
【０１５１】
第１の態様による本発明の他の実施の形態によれば、モバイル・ノードは、例えばバインディング更新メッセージＢＵ’内に「攻撃フラグ」を設定する事によって、予想される攻撃に関してローカル・モビリティ・アンカーに通知することができる。バインディング更新メッセージＢＵ’を受信すると、ローカル・モビリティ・アンカーは、攻撃が実際に存在するか否かを検証するための手段、及び、危険にさらされたモバイル・アンカー・ゲートウェイを識別するための手段を講じることができる。これは、例えばＡＡＡインフラストラクチャに照会して、モバイル・ノードが最近どの位置からネットワークに対して認証されていたかを決定することによって、実行可能である。この決定された位置が、プロキシ・バインディング更新ＰＢＵを送信したモバイル・アンカー・ゲートウェイの位置と異なる場合、ローカル・モビリティ・アンカーは、モバイル・アンカー・ゲートウェイが危険にさらされているものとみなす。危険にさらされているモバイル・アンカー・ゲートウェイを識別した後、ローカル・モビリティ・アンカーは、信頼されるモバイル・アンカー・ゲートウェイのリストからこのモバイル・アクセス・ゲートウェイを削除することができる。
【０１５２】
次に、第１の態様による第１の実施の形態の第２の変形について、図３に関して説明する。ここでは、モバイル・ノードが、ネットワーク・ベースのモビリティ管理スキームを実施するドメイン内にあるという状況について説明する。モバイル・ノードは第１のモバイル・アクセス・ゲートウェイＭＡＧ１に接続され、このＭＡＧ１が、モバイル・ノードの接続を示すために、プロキシ・バインディング更新メッセージＰＢＵ１をローカル・モビリティ・アンカーＬＭＡに送信する。プロキシ・バインディング更新メッセージＰＢＵ１が受け入れられた後、ローカル・モビリティ・アンカーＬＭＡは、気付けアドレスがローカル・モビリティ・アンカーＬＭＡのバインディング・キャッシュ・エントリに保存されたことを確認するために、プロキシ・バインディング確認メッセージＰＢＡ１を、プロキシ・バインディング更新ＰＢＵ１に含まれる第１のモバイル・アクセス・ゲートウェイＭＡＧ１である気付けアドレスに送信する。
【０１５３】
図３は、第２の危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２による、モバイル・ノードに向けて送られたトラフィックを宛先変更する試行を示す。第２のモバイル・アクセス・ゲートウェイＭＡＧ２は、偽のプロキシ・バインディング更新メッセージＰＢＵ２をローカル・モビリティ・アンカーＬＭＡに送信する。ローカル・モビリティ・アンカーは、第１のモバイル・アクセス・ゲートウェイＭＡＧ１に対応する古い気付けアドレスを、偽のプロキシ・バインディング更新ＰＢＵ２に含まれる第２のモバイル・アクセス・ゲートウェイＭＡＧ２に対応する新しい気付けアドレスに置き換えることによって、そのバインディング・キャッシュ・エントリを対応的に更新する。ローカル・モビリティ・アンカーＬＭＡは、次に、プロキシ・バインディング確認メッセージＰＢＡ２を、危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２に対応する気付けアドレスに送信する。さらに、ローカル・モビリティ・アンカーＬＭＡは、危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２に対応する新しく保存された気付けアドレスに送信されたプロキシ・バインディング確認メッセージＰＢＡ２に加えて、プロキシ・バインディング確認メッセージＰＢＡ’２を、バインディング・キャッシュ・エントリに以前に保存された第１のモバイル・アクセス・ゲートウェイＭＡＧ１に対応する気付けアドレスに送信する。
【０１５４】
第１のモバイル・アクセス・ゲートウェイＭＡＧ１は、受信したプロキシ・バインディング確認メッセージＰＢＡ’２と、第１のモバイル・アクセス・ゲートウェイＭＡＧ１がローカル・モビリティ・アンカーＬＭＡに以前に送信したプロキシ・バインディング更新メッセージとを比較することによって、危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２によるトラフィックを宛先変更する試行を検出することができる。第１のモバイル・アクセス・ゲートウェイＭＡＧ１が、ローカル・モビリティ・アンカーＬＭＡに送信したいかなるプロキシ・バインディング更新メッセージにも対応しないプロキシ・バインディング確認メッセージに気付いた場合、第１のモバイル・アクセス・ゲートウェイＭＡＧ１は、モバイル・ノードが依然として第１のモバイル・アクセス・ゲートウェイＭＡＧ１に接続されているか否かをチェックする。接続されている場合、危険にさらされたモバイル・アクセス・ゲートウェイによるトラフィックの宛先変更の試行の可能性を検出する。
【０１５５】
図３に示されるように、プロキシ・バインディング確認メッセージＰＢＡ’２を受信すると、第１のモバイル・アクセス・ゲートウェイＭＡＧ１は、以前に送信されたプロキシ・バインディング更新ＰＢＵ１に関するプロキシ・バインディング確認ＰＢＡ１を既に受け取っているため、及びプロキシ・バインディング確認メッセージＰＢＡ’２内のシーケンス番号が、プロキシ・バインディング更新ＰＢＵ１内のものと異なるため、対応するプロキシ・バインディング更新メッセージを送信していないことに気付く。第１のモバイル・アクセス・ゲートウェイＭＡＧ１は、次に、図３の「レイヤ２接続をテスト」信号で示されるように、モバイル・ノードが依然として第１のモバイル・アクセス・ゲートウェイＭＡＧ１に接続されているか否かをチェックする。モバイル・ノードは、依然として第１のモバイル・アクセス・ゲートウェイＭＡＧ１に接続されている場合、第２のモバイル・アクセス・ゲートウェイＭＡＧ２から攻撃を検出する。
【０１５６】
第１のモバイル・アクセス・ゲートウェイＭＡＧ１は、攻撃を検出すると、新しいプロキシ・バインディング更新メッセージＰＢＵ’をローカル・モビリティ・アンカーに送信して、ローカル・モビリティ・アンカーでのバインディング・キャッシュ・エントリを修正する。さらに、第１のモバイル・アクセス・ゲートウェイＭＡＧ１は、例えば、プロキシ・バインディング更新メッセージ内に新しい「攻撃フラグ」を設定することによって、推測される攻撃に関してローカル・モビリティ・アンカーに通知することができる。ローカル・モビリティ・アンカーは、次に、攻撃が実際に存在するか否かを検証するための手段、及び危険にさらされたモバイル・アクセス・ゲートウェイを識別するための手段を講じることができる。これは、どの位置からモバイル・ノードがネットワークに対して認証されていたかを決定するために、ＡＡＡインフラストラクチャに照会することによって実行可能である。危険にさらされているモバイル・アクセス・ゲートウェイを識別した後、ローカル・モビリティ・アンカーは、信頼されるモバイル・アクセス・ゲートウェイのリストからこのモバイル・アクセス・ゲートウェイを削除することができる。
【０１５７】
図２及び図３の各々に関して示された方法では、気付けアドレスに対するバインディング確認メッセージＢＡ’及びプロキシ・バインディング確認メッセージＰＢＡ’２の各々、又はモバイル・ノード及び第１のモバイル・アクセス・ゲートウェイＭＡＧ１の各々が失われた場合、攻撃を適時に検出することはできない。こうしたケースでは、モバイル・ノード及び危険にさらされていないモバイル・アクセス・ゲートウェイの各々からの次のバインディング更新メッセージに続いて、危険にさらされたモバイル・アクセス・ゲートウェイからのバインディング更新が発生した後にのみ、攻撃が検出可能であり、これには、バインディング・キャッシュ・エントリの存続期間に応じてある程度の時間を要する可能性がある。パケット損失の場合、検出速度を上げる可能な方法の１つは、バインディング・キャッシュ・エントリの存続期間を減少させることになる。他のオプションは、バインディング確認メッセージＢＡ’及びプロキシ・バインディング確認メッセージＰＢＡ’２の各々の受信を確認するために、モバイル・ノード及びモバイル・アクセス・ゲートウェイの各々から、確認メッセージを導入することにあり、結果として、バインディング確認メッセージＢＡ’及びプロキシ・バインディング確認メッセージＰＢＡ’２の各々は、ある時間枠内に何の確認も受信されない場合、ローカル・モビリティ・アンカーによって再送することができる。
【０１５８】
第１の態様による本発明の実施の形態によれば、ローカル・モビリティ・アンカーは、ハンドオーバ遅延の速度を上げるために、プロキシ・バインディング更新を受信した直後に、バインディング・キャッシュ・エントリを更新する。しかし、偽のプロキシ・バインディング更新の場合、これは、トラフィックの一時的な宛先変更を可能にすることになる。従って、ローカル・モビリティ・アンカーは、一時的なバインディング・キャッシュ・エントリを作成し、バインディング確認メッセージＢＡ’及びプロキシ・バインディング確認メッセージＰＢＡ’２の各々を、モバイル・ノード及び第１のモバイル・アクセス・ゲートウェイＭＡＧ１の各々の古い気付けアドレスに送信した後に、タイマを設定することができる。タイマが期限切れとなり、攻撃フラグを伴うバインディング更新及びプロキシ・バインディング更新メッセージが受信されていない場合、ローカル・モビリティ・アンカーは、バインディング・キャッシュ・エントリを、一時的なバインディング・キャッシュ・エントリからの情報で更新することができる。これにより、トラフィックの一時的な宛先変更は防止されるが、ハンドオーバ遅延は増加することになる。
【０１５９】
次に、第１の態様による本発明の第２の実施の形態について、図４及び図５に関して説明する。
【０１６０】
第１の態様による第２の実施の形態の第１の変形について、図４に関して説明する。モバイル・ノードは、クライアント・ベースのモビリティ管理スキームを実施するドメイン内に位置する。それ故、モバイル・ノードは、バインディング更新メッセージＢＵをローカル・モビリティ・アンカーＬＭＡに送信することによってその位置を送る。ローカル・モビリティ・アンカーＬＭＡは、第１に、バインディング更新メッセージＢＵに含まれる認証情報をチェックして、このバインディング更新ＢＵが、ＢＵに含まれるホーム・アドレスに対応するモバイル・ノードによって実際に送信されていることを識別する。バインディング更新を受け入れた後、ローカル・モビリティ・アンカーＬＭＡは、気付けアドレスがローカル・モビリティ・アンカーＬＭＡのバインディング・キャッシュ・エントリ内に保存されたことを確認するために、バインディング確認メッセージＢＡを、バインディング更新メッセージＢＵに含まれるモバイル・ノードの気付けアドレスに送信する。
【０１６１】
図４は、ネットワーク・ベースのモビリティ管理スキームを実施するドメイン内の危険にさらされたモバイル・アクセス・ゲートウェイによる、モバイル・ノードに向けて送られたトラフィックを宛先変更する試行を示す。モバイル・アクセス・ゲートウェイは、偽のプロキシ・バインディング更新メッセージＰＢＵをローカル・モビリティ・アンカーＬＭＡに送信する。ローカル・モビリティ・アンカーは、モバイル・ノードの古い気付けアドレスを、偽のプロキシ・バインディング更新ＰＢＵに含まれたモバイル・アクセス・ゲートウェイの新しい気付けアドレスに置き換えることによって、そのバインディング・キャッシュ・エントリを対応的に更新する。ローカル・モビリティ・アンカーＬＭＡは、次に、プロキシ・バインディング確認メッセージＰＢＡを、危険にさらされたモバイル・アクセス・ゲートウェイの気付けアドレスに送信する。さらに、ローカル・モビリティ・アンカーＬＭＡは、危険にさらされたモバイル・アクセス・ゲートウェイの新しく保存された気付けアドレスに送信されたプロキシ・バインディング確認メッセージＰＢＡに加えて、バインディング確認ＢＡ’を、バインディング・キャッシュ・エントリに以前に保存されたモバイル・ノードの気付けアドレスに送信する。
【０１６２】
第１の態様による本発明の第２の実施の形態のこの変形では、ローカル・モビリティ・アンカーは、バインディング・キャッシュ・エントリに現在保存されている気付けアドレスと、受信したＰＢＵ又はＢＵメッセージ内の気付けアドレスとの両方から、新しいバインディング更新メッセージを要求する。この要求は、例えば、プロキシ・バインディング確認メッセージＰＢＡ及びバインディング確認メッセージＢＡ’、又は別の方法としては、Ｂ．Ｈａｌｅｙ、Ｓｒｉ  Ｇｕｎｄａｖｅｌｌｉの、「Ｍｏｂｉｌｉｔｙ  Ｈｅａｄｅｒ  Ｓｉｇｎａｌｉｎｇ  Ｍｅｓｓａｇｅ」、ｄｒａｆｔ−ｈａｌｅｙ−ｍｉｐ６−ｍｈ−ｓｉｇｎａｌｉｎｇ−０２．ｔｘｔ、２００７年３月に記載されたような、モビリティ・ヘッダ信号要求メッセージ（ＭＨＳＲ）などの異なるタイプのメッセージを送信することによって実現可能である。さらに、バインディング・リフレッシュ・アドバイス・オプション（ＢＲＡ、ＲＦＣ３７７５のセクション６．２．４を参照のこと）を含めることが可能である。バインディング・リフレッシュ・アドバイス・オプションにおけるリフレッシュ間隔フィールドについて、又はバインディング確認メッセージにおける存続期間フィールドについて、ゼロに等しいか又はこれに近い値、好ましくは５秒未満を設定することで、プロキシ・バインディング確認メッセージＰＢＡ、危険にさらされたモバイル・アクセス・ゲートウェイ、及びそのバインディング確認メッセージＢＡ’、モバイル・ノードのそれぞれの受信側に、ローカル・モビリティ・アンカー内のバインディング・キャッシュ・エントリを更新するために、それぞれプロキシ・バインディング更新ＰＢＵ’及びバインディング更新ＢＵ’で即時に回答するように要求する。
【０１６３】
図４に示されるように、バインディング・リフレッシュ・アドバイス・オプションを伴うか又は伴わないバインディング確認メッセージＢＡ’を受信すると、モバイル・ノードは、新しいバインディング更新ＢＵ’でローカル・モビリティ・アンカーに応答する。図４にはバインディング確認メッセージの特定の例が記載されているが、前述のように、バインディング確認メッセージＢＡ’は、モビリティ・ヘッダ信号要求メッセージに置き換えることが可能である。プロキシ・バインディング確認メッセージＰＢＡ、又はバインディング・リフレッシュ・アドバイスを伴うか又は伴わないモビリティ・ヘッダ信号要求を受信したモバイル・アクセス・ゲートウェイは、モバイル・ノードが依然として接続されているか否かをチェックし、接続されている場合は、新しいプロキシ・バインディング更新をローカル・モビリティ・アンカーに送信する。モバイル・ノードがもはや接続されていない場合は、新しいプロキシ・バインディング更新は送信しない。しかし、モバイル・アクセス・ゲートウェイＭＡＧが危険にさらされているため、モバイル・ノードはそれに接続されていないが、宛先変更攻撃をアクティブ状態で維持するために、プロキシ・バインディング更新ＰＢＵ’で応答する。
【０１６４】
従って、ローカル・モビリティ・アンカーＬＭＡは、プロキシ・バインディング更新ＰＢＵ’及びバインディング更新メッセージＢＵ’の両方を、その再送要求に対する応答として受信する。このようにしてローカル・モビリティ・アンカーは、危険にさらされたモバイル・アクセス・ゲートウェイが存在する事を検出する。
【０１６５】
第１のオプションによれば、モバイル・ノードとローカル・モビリティ・アンカーＬＭＡとの間に２地点間セキュリティアソシエーションが存在し、モバイル・ノード自体がバインディング更新メッセージＢＵ’のソースであるため、ローカル・モビリティ・アンカーＬＭＡは、モビリティ・アンカー・ゲートウェイではなくモバイル・ノードを信頼する。結果として、ローカル・モビリティ・アンカーはプロキシ・バインディング更新ＰＢＵ’を破棄し、モバイル・アクセス・ゲートウェイを危険にさらされているものとみなすが、これは、このモバイル・アクセス・ゲートウェイからのプロキシ・バインディング更新をこれ以上受け入れないことを意味する。
【０１６６】
第２のオプションによれば、ローカル・モビリティ・アンカーＬＭＡは、モバイル・ノードがアクセス・リソースの使用をどこで認証及び承認されたかを検証するために、ＡＡＡインフラストラクチャからのポリシー・ストアを調べる。モバイル・ノードがＰＭＩＰドメイン内にないことをローカル・モビリティ・アンカーＬＭＡが検証した後、ローカル・モビリティ・アンカーＬＭＡは、モバイル・アクセス・ゲートウェイが危険にさらされることになるものとみなす。
【０１６７】
次に、第１の態様による第２の実施の形態の第２の変形について、図５に関して説明する。
【０１６８】
説明される状況は、モバイル・ノードが現時点で、ネットワーク・ベースのモビリティ管理スキームを実施するドメイン内部にあるというものである。モバイル・ノードは第１のモバイル・アクセス・ゲートウェイＭＡＧ１に接続され、これが、モバイル・ノードの接続を示すために、プロキシ・バインディング更新メッセージＰＢＵ１をローカル・モビリティ・アンカーＬＭＡに送信する。プロキシ・バインディング更新メッセージＰＢＵ１を受け入れた後、ローカル・モビリティ・アンカーＬＭＡは、気付けアドレスがローカル・モビリティ・アンカーＬＭＡのバインディング・キャッシュ・エントリに保存されたことを確認するために、プロキシ・バインディング確認メッセージＰＢＡ１を、プロキシ・バインディング更新ＰＢＵ１に含まれた第１のモバイル・アクセス・ゲートウェイＭＡＧ１に対応する気付けアドレスに送信する。
【０１６９】
図５は、第２の危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２による、モバイル・ノードに向けて送られたトラフィックを宛先変更する試行を示す。第２のモバイル・アクセス・ゲートウェイＭＡＧ２は、偽のプロキシ・バインディング更新メッセージＰＢＵ２をローカル・モビリティ・アンカーＬＭＡに送信する。ローカル・モビリティ・アンカーは、第１のモバイル・アクセス・ゲートウェイＭＡＧ１に対応する古い気付けアドレスを、偽のプロキシ・バインディング更新ＰＢＵ２に含まれる第２のモバイル・アクセス・ゲートウェイＭＡＧ２に対応する新しい気付けアドレスに置き換えることによって、そのバインディング・キャッシュ・エントリを対応的に更新する。次にローカル・モビリティ・アンカーＬＭＡは、プロキシ・バインディング確認メッセージＰＢＡ２を、危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２に対応する気付けアドレスに送信する。さらに、ローカル・モビリティ・アンカーＬＭＡは、危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２に対応する新しく保存された気付けアドレスに送信されたプロキシ・バインディング確認メッセージＰＢＡ２に加えて、プロキシ・バインディング確認メッセージＰＢＡ’２を、バインディング・キャッシュ・エントリに以前に保存された第１のモバイル・アクセス・ゲートウェイＭＡＧ１に対応する気付けアドレスに送信する。
【０１７０】
第１の態様による本発明の第２の実施の形態のこの変形では、ローカル・モビリティ・アンカーは、モビリティ・ヘッダ信号要求か、又は図５に示されるように、プロキシ・バインディング確認メッセージＰＢＡ２を危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２に対応する気付けアドレスへ、及びプロキシ・バインディング確認メッセージＰＢＡ’２を第１のモバイル・アクセス・ゲートウェイＭＡＧ１に対応する気付けアドレスへ、バインディング・リフレッシュ・アドバイス・オプション（ＢＲＡ、ＲＦＣ３７７５のセクション６．２．４を参照のこと）を伴うか又は伴わずに送信する。
【０１７１】
モバイル・アクセス・ゲートウェイが再送の要求を受信すると、モバイル・アクセス・ゲートウェイは、モバイル・ノードが依然としてそれに接続されているか否かを判別するためのチェックを実行する。モバイル・ノードが依然として接続されている場合、モバイル・アクセス・ゲートウェイはプロキシ・バインディング更新をローカル・モビリティ・アンカーに送信する。危険にさらされたモバイル・アクセス・ゲートウェイＭＡＧ２は、宛先変更攻撃をアクティブに維持するために、プロキシ・バインディング更新ＰＢＵ’２をローカル・モビリティ・アンカーに送信し、モバイル・ノードが接続されている場合、第１のモバイル・アクセス・ゲートウェイＭＡＧ１は、ローカル・モビリティ・アンカー内のバインディング・キャッシュ・エントリを更新するために、プロキシ・バインディング更新ＰＢＵ’１で回答する。
【０１７２】
前述のように、ローカル・モビリティ・アンカーは２つのプロキシ・バインディング更新を受信し、同時に、ローカル・モビリティ・アンカーＬＭＡは、モバイル・アクセス・ゲートウェイのうちの１つが危険にさらされていることを決定する。次に、ローカル・モビリティ・アンカーＬＭＡは、危険にさらされたモバイル・アクセス・ゲートウェイを識別するために、前述のようにＡＡＡインフラストラクチャのポリシー・ストアを調べることができる。
【０１７３】
第１の態様による第１の実施の形態に関して前述したように、ローカル・モビリティ・アンカーＬＭＡは、ハンドオーバ遅延の速度を上げるためにプロキシ・バインディング更新の受信直後にバインディング・キャッシュ・エントリを更新することができる。しかし、これは、危険にさらされたモバイル・アクセス・ゲートウェイによるトラフィックの一時的宛先変更を可能にすることになる。従って、ローカル・モビリティ・アンカーは、新しい気付けアドレスを伴う一時的なバインディング・キャッシュ・エントリを作成し、バインディング確認及びプロキシ・バインディング確認メッセージの各々を、バインディング・キャッシュ・エントリ内の現在の気付けアドレスに送信した後、タイマを設定することができる。タイマが期限切れとなり、バインディング更新及びプロキシ・バインディング更新メッセージの各々が現在の気付けアドレスが受信されなかった場合、ローカル・モビリティ・アンカーは、バインディング・キャッシュ・エントリを、一時的なバインディング・キャッシュ・エントリからの情報で更新する。このようにしてローカル・モビリティ・アンカーは、新しい気付けアドレスが危険にさらされていないモバイル・アクセス・ゲートウェイからのものであると想定する。この代替は、トラフィックの一時的な宛先変更を防止するが、ハンドオーバ遅延は増加させることになる。
【０１７４】
本発明の第１の態様について、特に、ローカル・モビリティ・アンカーがバインディング確認メッセージをモバイル・ノード又はモバイル・アクセス・ゲートウェイのいずれかに送信する状況を使用して説明してきたが、説明したタイプの中から、本発明の範囲を逸脱することなしに、攻撃を検出するための他のタイプのメッセージを使用することができる。
【０１７５】
以下では、本発明の第２の態様について説明する。以下の用語は、以下の定義を有するものとして解釈されよう。
【０１７６】
バインディング更新（ＢＵ）は、本明細書では、ＭＮの新しいアドレス（すなわちトポロジー的位置）に関してモビリティ・アンカー・ポイントに通知するために、モバイル・ノード又はプロキシ・モビリティ・エージェント（ＰＭＡ）によって送信される登録メッセージとして定義される。本発明のこの第２の態様では、以下ではクライアントＢＵに対してＣＢＵと呼ばれるホスト・ベースのモビリティ・メカニズムによって送信されるＢＵと、以下ではプロキシＢＵに対してＰＢＵと呼ばれるネットワーク・ベースのモビリティ・メカニズムとが区別される。また同じように、ホストによって送信されるバインディング更新確認メッセージは、ＣＢＡｃｋ（クライアントＢＡｃｋ）として示され、ＰＭＡによって送信されたバインディング更新確認メッセージはＰＢＡｃｋ（プロキシＢＡｃｋ）として示される。
【０１７７】
本明細書では、ＢＵ競合状態を、ＣＢＵ又はＰＢＵメッセージが遅延し、従って、古い（Ｐ）ＢＵが新しい（Ｐ）ＢＵの後でＨＡに到達する状況を言い表す。
【０１７８】
ＣＭＩＰ（クライアント・モバイルＩＰ）は、ホスト・ベースのモビリティ・メカニズムを言い表す。クライアント（ホスト又はモバイル・ノード、ＭＮ）は、その新しい位置を登録するために、登録メッセージをモビリティ・アンカー・ノード（ホーム・エージェント、ＨＡ）に送信する。
【０１７９】
ＰＭＩＰ（プロキシ・モバイルＩＰ）は、モバイルＩＰプロトコル上に基礎を置いたネットワーク・ベースのモビリティ・メカニズムを言い表す（Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏの、「Ｍｏｂｉｌｉｔｙ  Ｓｕｐｐｏｒｔ  ｉｎ  ＩＰｖ６」、ＲＦＣ３７７５、２００４年６月）。プロキシ・モバイル・エージェント（ＰＭＡ）は、ＭＮの新しい位置を登録するために、ＭＮの代わりにモビリティ・アンカー・ノード（ＨＡ）に登録メッセージを送信する。ＰＭＩＰメカニズムでは、ＭＮはモビリティ関係手順に関係しない。
【０１８０】
第２の態様による本発明の実施の形態による解決策は、２段階に分けることができる。第１段階では、ＨＡがＢＵ競合状態の可能性を検出する。この段階は、以下ではＢＵ競合状態検出手順と呼ばれる。第２段階では、ＨＡがＢＵ競合状態の可能性を検出した後、ＨＡは、両方のＢＵのうちどちらが新しいかを解決する必要がある。これは、以下では最新ＢＵの解決手順と呼ばれる。
【０１８１】
第２の態様による本発明の説明では、以下の用語が使用され、その定義を以下に示す。
【０１８２】
ＢＵ解決照会メッセージは、ＢＵ競合状態が発生した場合、最新の（すなわち最も新しい）ＢＵを解決するために、ＨＡによって送信されるメッセージを指す。このメッセージは、リフレッシュ・アドバイス・オプションを備えたバインディング更新確認、又はインターネット制御メッセージ・プロトコル（ＩＣＭＰ）エコー・メッセージ、又は気付けテスト開始（ＣｏＴＩ）メッセージ、又は何らかの他のメッセージとすることができる。
【０１８３】
ＢＵ解決回答メッセージは、ＭＮによって、又はＰＭＡによって、ＢＵ解決照会メッセージへの回答として送信されるメッセージを指す。このメッセージは、バインディング更新又はプロキシ・バインディング更新メッセージ、又はＩＣＭＰエコー回答メッセージ又は気付けテスト（ＣｏＴ）メッセージ又は何らかの他のメッセージとすることができる。
【０１８４】
ＢＵ競合状態検出手順は、主に、使用されるモビリティ・メカニズムの変更、すなわち、クライアント・ベース（ＣＭＩＰ）からネットワーク・ベース（ＰＭＩＰ）のモビリティへの移行、又はその逆の検出に基づくものである。ＨＡはこの移行を、例えば、ＰＢＵを受信した後のＣＢＵの受信又はＣＢＵを受信した後のＰＢＵの受信など、異なるタイプのＢＵの連続する受信によって検出することができる。ＨＡが、モビリティ・メカニズムの移行が検出されるごとに、最新ＢＵの解決手順を開始する場合、結果として、ネットワーク内に不必要な信号を発生させ、ＨＡ内のバインディング更新の処理に不必要な遅延を発生させることになる。従って、第２の態様による本発明の好ましい実施の形態により、ＢＵ競合状態検出手順が調整され、異なるタイプのＢＵが到達した時間をＨＡに監視及び格納させることによって、ＢＵ競合状態検出のための追加のより精密な条件が導入される。異なるタイプの連続するＢＵの到達が、事前に構成された期間（以下、この期間は「Ｔ」で表される）内である場合、これは、異なるタイプのＢＵが互いに非常に短い間隔で送信されることを意味し、ＢＵの再順序付けの可能性がかなり高い。この場合、ＨＡは最新ＢＵの解決手順をトリガする。図１２で測定された時間差を想定してみる。次に、Δｔが事前に構成された期間よりも小さい／短い（すなわち、Δｔ＜Ｔ）という条件が満たされた場合、ＨＡは最新ＢＵの解決手順を開始する。
【０１８５】
期間Ｔの構成は、ネットワーク・オペレータによって手動で実行するか、又は動的に決定することができる。例えば、オペレータは、フォーリン・ネットワークとホーム・ネットワーク（又は、ＣＭＩＰベースからＰＭＩＰベースのメカニズム）との間のハンドオーバ手順がどのくらいの長さであるかを知ることができるか、又は異なるネットワーク・ドメイン間のハンドオーバに必要な最低時間を知っている。従って、異なるタイプの連続するＢＵの到達が、最低ハンドオーバ遅延よりも短いことはあり得ない。この時間が短い場合、何らかの推測が生じ、ＨＡはＢＵの正しい連続した到達に疑いを持つ。この場合、パラメータＴは、ＣＭＩＰからＰＭＩＰ（又はその逆）へのモビリティ移行に関する最低ハンドオーバ遅延に、何らかの保護時間をプラス又はマイナスしたものに基づいて構成される。しかし、ＭＮが事前認証及び事前承認を実行する（すなわち、ＭＮがＬ２ハンドオーバ以前に新しいネットワーク・ドメインでＥＡＰ手順を実行する）場合、パラメータＴを適切にセットアップする必要があり、すなわち、異なるタイプのＢＵが互いに短い間隔で送信できることを考える必要がある。パラメータＴは、ＢＵ競合状態検出手順に関する追加の条件であり、その構成は実施特有であることに留意されたい。ＨＡがＢＵ競合状態を検出した場合、次のステップは、最新ＢＵの解決手順を実行することである。この手順中に、ＨＡは最後に受信したＢＵ（ＣＢＵ又はＰＢＵ、以下ではＣ／ＰＢＵと呼ぶ）を拒否し、ＢＵ解決照会メッセージ（例えば、リフレッシュ・アドバイス・オプションが０に設定されたバインディング確認、ＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］）を両方のＣｏＡに送信する。第１のＣｏＡは、これが以前のＣ／ＰＢＵによって既に登録されているアドレスである事を意味する現在のバインディング・キャッシュ・エントリ（ＢＣＥ）から取得される。第２のＣｏＡは、拒否されたばかりの最新のＣ／ＰＢＵに含まれる。ＢＵ解決照会メッセージに対する応答として、ＨＡは、現在のＭＮの位置から、すなわち、最新ＣｏＡから、ＢＵ解決回答メッセージ（例えばＣ／ＰＢＵ）を１つだけ受信し、そのＢＣＥを対応的に更新する。
【０１８６】
図１１は、ＣＭＩＰからＰＭＩＰへのモビリティ移行におけるＢＵ競合状態シナリオの例示的解決策を示す。ＭＮによって送られた古いＣＢＵは、ＰＭＡによって送られた新しいＰＢＵよりも後でＨＡに到達する。ＰＢＵとＣＢＵの到達の時間差（Δｔ）が事前に構成された時間パラメータＴよりも小さいため、ＨＡはＢＵ競合状態の可能性を検出する。従ってＨＡはＣＢＵを受け入れず、最新ＢＵの解決手順を開始する。ＨＡに関するオプションの１つが、ＣＢＵを削除することであるが、他のオプションは（ＨＡがＢＵ解決回答メッセージを受信する前に登録解除メッセージを受信する部分の説明で、後に示されるように）、ＨＡが、ＢＵ解決回答メッセージの受信前にＢＣＥの更新に関して決定することができるため、ＣＢＵの情報を格納することである。ＢＵ競合状態の結果として、ＨＡはＣＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］をＭＮに、ＰＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］をＰＭＡに送信する。ＭＮへのＣＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］は受信不可能なため、ＭＮからの回答はない。ＰＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］の受信後、ＰＭＡは即時にＰＢＵでＨＡに応答する。ＨＡはＰＢＵを受信すると、そのＢＣＥを更新する。この場合、ＢＣＥは変更されず、ＢＣＥ内の存続期間タイマのみが更新されることを意味する。
【０１８７】
図１２は、ＰＭＩＰからＣＭＩＰへのモビリティ移行におけるＢＵ競合状態シナリオの例示的解決策を示す。ＰＭＡによって送られた古いＰＢＵは、ＭＮによって送られた新しいＣＢＵよりも後でＨＡに到達する。ここでも、条件Δｔ＜Ｔが満たされた場合、ＨＡは最新ＢＵの解決手順を開始する。ＨＡは、ＣＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］をＭＮに、ＰＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］をＰＭＡに送信する。ＰＭＡへのＰＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］は受信されるが、ＭＮがもはやＰＭＡのモビリティ登録データベース内に存在しないため、ＰＭＡはメッセージを破棄する。他方で、ＣＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］メッセージの受信後、ＭＮは、即時にＣＢＵでＨＡに応答する。ＨＡはＣＢＵを受信すると、そのＢＣＥを更新する。この場合、ＢＣＥは変更されず、ＢＣＥ内の存続期間タイマのみが更新されることを意味する。
【０１８８】
前述の段落で説明したように、ＢＵ競合状態の検出の調整は、異なるタイプの連続するＢＵの到達の時間差に基づくものである。しかし、図１２とは対照的に、ＢＵが順番に、互いに非常に短い間隔で到達することも可能である。こうしたケースは図１３に示されており、ＭＮがＰＭＩＰからＣＭＩＰへのハンドオーバを実行する。ＰＢＵはＣＢＵの直前に到達する（すなわち、Δｔ＜Ｔ）。この条件により、ＢＵは正しく（順番に）到達するが、最新ＢＵの解決手順が活動化されることになる。結果として生じる挙動は、ＨＡが最新のＢＵ（すなわちＣＢＵ）を受け入れず、ＣＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］をＭＮに、ＰＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］をＰＭＡに送信することである。ＰＭＡは、ＭＮがもはやこれに接続されていないため、ＰＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］メッセージを破棄する。ＣＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］の受信後、ＭＮは、即時にＣＢＵ［ＳＮ＋１］でＨＡに応答する。表示ＣＢＵ［ＳＮ＋１］は、クライアントＢＵ内のシーケンス番号が１つずつ増加することを意味する。ＨＡはＣＢＵを受信すると、このＭＮに関する対応するプロキシＢＣＥが非活動化される（又は、実施に応じて削除される）ため、ＣＢＵを受け入れてそのＢＣＥを更新する。ＨＡは、ＣＢＵの確認のために、ＣＢＡｃｋをＭＮに返信することができる。図１３のケースを要約すると、ＢＵは順番にＨＡに到達するが、最新ＢＵの解決手順がトリガされる。しかし、最新ＢＵの解決手順が実行された後、ＨＡは正しいＢＵ（このケースではＣＢＵ）を受け入れる。従って、正しい処理は影響を受けない。唯一の影響は、ＣＢＵが受け入れられる前に小さな遅延が導入されることである。この遅延は、ＨＡとＭＮとの間の１往復時間（ＲＴＴ）である。
【０１８９】
以下で、第２の態様による最新ＢＵの解決手順の最適化について説明するが、上記最適化は主にＰＭＡのレベルである。
【０１９０】
幾つかの環境下では、ＰＭＡとＭＮとの間のレイヤ２（Ｌ２）技術は、Ｌ２登録解除をサポートしない可能性がある。これは、ＭＮがＰＭＡを離れた場合、ＰＭＡは、短い期間中、ＭＮが登録されたそのデータベース内に依然としてエントリを有することが可能であることを意味する。この期間中にＰＭＡがＢＵ解決照会メッセージを受信した場合、ＭＮは離れているが、ＰＭＡは肯定的にＨＡに応答することになる。従って、図１４のフローチャートによって示される以下の最適化が提案される。
【０１９１】
第２の態様による本発明の実施の形態によれば、ＰＭＡが所与のＭＮに関するＢＵ解決照会メッセージを受信し、ＰＭＡがこのＭＮに対して有効な登録を有する場合、ＰＭＡは、ＭＮが依然としてＩＰリンクに接続されているか否かをチェックする。これを実行するためには幾つかのオプションがある。オプションの１つは、Ｌ２ポーリング・メッセージをＭＮに送信し、回答を得ることである。ＨＡに関する他のオプションは、近隣要請を送信し、ＭＮから近隣広告を受信することである。ＰＭＡが、ＭＮが依然として接続されているものと判別した場合、ＰＭＡは肯定のＰＢＵ（非ゼロの存続期間オプションを備えた）をＨＡに送信する。さもなければ、ＭＮがＰＭＡに接続されていない場合、ＰＭＡはＢＵ解決照会メッセージを破棄する。
【０１９２】
ＰＭＡが常にＢＵ解決照会メッセージに応答することも可能である。従って、第２のオプションによれば、ＭＮがＰＭＡに登録されている場合、ＰＭＡは肯定のＢＵ解決回答メッセージで応答する。ＭＮがもはやＰＭＡに接続されていない場合、ＰＭＡは否定のＢＵ解決回答メッセージで応答する。
【０１９３】
好ましくは、ＢＵ解決照会メッセージは、リフレッシュ・アドバイス・オプションを備えたバインディング更新確認メッセージによって実施される。リフレッシュ・アドバイス・オプションはゼロに設定され、これは、受信側がバインディング更新で即時に応答しなければならないことを示す。本発明の第２の態様で使用されるこのメッセージの表示は、ＰＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］である。結果として生じるＢＵ解決回答メッセージは、好ましくは、誰がＰＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］に応答するかに応じて、ＣＢＵ又はＰＢＵであり、応答者がＭＮの場合、ＢＵ解決回答メッセージはＣＢＵであり、応答者がＰＭＡの場合、ＢＵ解決回答メッセージはＰＢＵである。肯定のＢＵ解決回答メッセージは、ゼロよりも大きい存続期間オプションを有する通常のＣＢＵ又はＰＢＵである（すなわち、ＰＢＵ［ｌｉｆｅｔｉｍｅ＞０］）。否定のＢＵ解決回答メッセージは、ゼロに等しい存続期間オプションを有するＣＢＵ又はＰＢＵである（すなわち、ＰＢＵ［ｌｉｆｅｔｉｍｅ＝０］）。
【０１９４】
図１４は、最新ＢＵの解決手順をサポートするためのＰＭＡにおける、本発明の第２の態様による例示的実施の形態を示す。最も簡潔な実施では、ＭＮが登録されている（エントリを有する）場合、ＰＭＡはデータベース（ＢＣＥ）のみをチェックする。ＭＮがＢＣＥリスト内にエントリを有する場合、ＰＭＡは、ＢＣＥ内のバインディング存続期間が存続期間オプションの値によって、更新されるべきであることを意味するＰＢＵ［ｌｉｆｅｔｉｍｅ＞０］を送信する。これに対して、ＭＮがＢＣＥ内にない場合、ＰＭＡはＢＵ解決照会メッセージを破棄する。ＰＭＡがＮＡｃｋメッセージを送信するように構成されている場合（すなわち、登録解除メッセージＢＵ［ｌｉｆｅｔｉｍｅ＝０］）、ＭＮがＢＣＥリスト内になければ、ＰＭＡはこのメッセージを送信する。ＭＩＰｖ６では、登録解除メッセージはＢＵ［ｌｉｆｅｔｉｍｅ＝０］であり、これは、ＨＡ内の所与のＣｏＡに関するＭＮのエントリを削除する。ここでＰＭＡは、ＰＭＡ自体でＨＡにおけるプロキシ・バインディングを登録解除するためにＰＢＵ［ｌｉｆｅｔｉｍｅ＝０］を送信するか、又は言い換えれば、ＰＭＡは、ＭＮがこのＰＭＡにもはや位置しないことをＨＡに通知する。オプションで、ＭＮがＢＣＥリスト内に存在するが、ＰＭＡがＬ２使用可能性チェックを実行するように構成される場合、ＰＭＡがこのチェックを実行する。Ｌ２チェックが肯定の場合、ＰＭＡはＰＢＵ［ｌｉｆｅｔｉｍｅ＞０］を送信する。さもなければ、Ｌ２チェックが否定の場合、ＰＭＡは、あたかもＭＮがＢＣＥリスト内で使用不能であるように、同じ動作を実行する。
【０１９５】
以下で、第２の態様による本発明の他の実施の形態について説明する。ＨＡがＣＢＵ又はＰＢＵ登録解除メッセージを受信した場合、これは、両方のＣｏＡのうちの１つがもはや有効でないことを意味する。ＣＭＩＰ−ＨＡの登録解除プロセスについては、「Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏの、「Ｍｏｂｉｌｉｔｙ  Ｓｕｐｐｏｒｔ  ｉｎ  ＩＰｖ６」、ＲＦＣ３７７５、２００４年６月」のセクション１０．３．２に記載されている。ＭＮがホーム・ネットワークに戻った場合、又はＭＮがそのエリアを離れたことをＰＭＡが検出した場合、ＨＡにおけるバインディングは登録解除が必要な場合がある。ＣｏＡがもはや必要ないか又は有効でないことを送信側エンティティ（ＭＮ又はＰＭＡ）が知った場合は、いかなるケースでもＢＵ登録解除メッセージが送信される。従って、ＨＡがＣＢＵ又はＰＢＵ登録解除メッセージを受信した場合、ＨＡはＢＵ競合状態検出手順又は最新ＢＵの解決手順を取り消さなければならない。具体的には、ＢＵ競合状態検出手順の場合、ＨＡはΔｔ時間の測定を停止する場合がある。最新ＢＵの解決手順の場合、ＢＵ解決照会メッセージを送信した後、及びＢＵ解決回答メッセージを受信する前に、ＨＡが登録解除メッセージを受信すると、ＨＡはＢＵ解決回答メッセージを待たずに、登録解除メッセージに基づいて最も新しいＢＵの有効性を決定する。例えば、ＨＡがＣＢＵ後にＰＢＵを受信し、最新ＢＵの解決手順を開始し、登録解除ＣＢＵを受信した場合、ＨＡは、ＢＵ解決回答メッセージが到達する前に、ＰＢＵの受け入れ及びそのバインディングのＣＢＵからの削除を決定する。これとは逆に、ＨＡがＰＢＵの後にＣＢＵを受信し、最新ＢＵの解決手順を開始しており、登録解除ＰＢＵを受信した場合、ＨＡはＣＢＵを受け入れ、ＢＵ解決回答メッセージが届く前に、ＰＢＵからバインディングを削除する。
【０１９６】
第２の態様に従って本発明の解決策を展開するために、ＨＡでの実施が必要な変更について、以下に要約する。
【０１９７】
第１に、前述のＢＵ競合状態検出手順をＨＡで実施するものとする。さらに、上記で定義したような時間パラメータ「Ｔ」をネットワーク・オペレータによって構成するものとする。異なるタイプのＢＵ到達の時間差測定を実施するには、２つのオプションがある。オプションの１つは、ＨＡにおけるあらゆるＰＢＵ及びＣＢＵの到達時間を格納することである。これは、第２の態様による実施の形態により、ＨＡのバインディング・キャッシュ・エントリ（ＢＣＥ）内の新しいフィールドとして実施可能である。異なるタイプの新しいＢＵが到達した場合、ＨＡは、最も新しいＣ／ＰＢＵと以前のＣ／ＰＢＵの到達時間を比較する。他のオプションは、異なるタイプのＢＵの到達の時間差を測定するためのタイマを実装するである。Ｃ／ＰＢＵが到達した後、タイマが開始され、次のＣ／ＰＢＵが到達すると停止される。
【０１９８】
ＨＡで必要な他の変更は、最新ＢＵの解決手順の実施である。さらに、バインディング要求メッセージＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］の、ＭＮの両方のＣｏＡへ、又はＣｏＡのうちの少なくとも１つへの送信を実施するものとする。最新のＢＵは、最新ＢＵの解決手順が完了するまでＨＡによって格納され、その後破棄されるものとする。
【０１９９】
モバイル・ノード及びＰＭＡで必要な変更について、以下に要約する。
【０２００】
通常、ＭＩＰ実施ノードは、未処理のＢＵについてのみ、バインディング確認（ＢＡｃｋ）メッセージを処理する。しかし、ＢＡｃｋ［Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０］メッセージは、ＭＮ又はＰＭＡで対応的に受信された同じＢＵに関する第２のバインディング確認である。従って、ＭＮ又はＰＭＡでのＭＩＰ実施は、リフレッシュ・アドバイス・オプションが０に設定された場合（Ｒｅｆｒ−Ａｄｖ−Ｏｐｔ＝０）のみ、第２のＣＢＡｃｋ又は対応的にＰＢＡｃｋメッセージを処理するように、変更されるものとする。オプションＲｅｆｒ−Ａｄｖ−Ｏｐｔ＝０を有する第２のＣ／ＰＢＡｃｋのみを受け入れる理由は、攻撃者が不必要なＢＡｃｋでＭＮをフラッディングさせようとする可能性のある可能なセキュリティ・スレッドを制限するためである。ＭＮの場合に第２のＣＢＡｃｋを受け入れる特有の一例について、以下で説明する。ＭＮは、未処理のＣＢＵと同じシーケンス番号（ＳＮ）を有するＣＢＡｃｋのみを処理する。ＣＢＡｃｋが処理されると、ＣＢＵはもはや未処理ではない。従って、すでに確認されたＣＢＵに関する第２のＣＢＡｃｋを受け入れるために、ＭＮは変更される必要がある。
【０２０１】
さらに、ＰＭＡは、前述の最適化手順、すなわち、ＭＮがもはやＰＭＡに登録されていない場合、否定回答ＰＢＵ［ｌｉｆｅｔｉｍｅ＝０］をＨＡに送信することに従って、変更される。さらにＰＭＡは、ＰＭＡがＭＮの使用可能性に関して確信できないごとに、ＭＮに対するポーリングを実行するように変更することができる。こうしたポーリングのケースでは、ＰＭＡはＬ２ポーリング・メッセージをＭＮに送信し、回答を得ることができる。ＨＡに関する他のオプションは、近隣要請を送信することであり、ＭＮからの近隣広告の受信によってＭＮの接続が確認されることになる。
【０２０２】
何らかの理由で両方のＢＵ解決照会メッセージが失われる特別なケースも起こり得る。こうしたケースでは、ＨＡで対応するＢＵ解決照会メッセージにＢＵ解決回答メッセージが所与の時間内に到達することはなく、ＨＡはＢＵ解決照会メッセージを再度送信する。
【０２０３】
第２の態様による本発明の他の実施の形態によれば、ＨＡは、両方のＣｏＡにＢＵ解決メッセージ（すなわちＢＡｃｋ）を送信せず、１つのエンティティのみに送信する。例えば、ＨＡは、ＨＡに最後に登録されたＰＭＡのみに、言い換えれば、最後のＰＢＵを送信したＰＭＡのみに、ＢＡｃｋを送信することができる。ＰＭＡはＢＵ解決メッセージを受信した場合、要求されたＭＮが依然として登録されているか否かをチェックする。登録されている場合、ＰＭＡは新しいＰＢＵをＨＡに送信する。登録されていない場合は、否定回答をＨＡに返送する。この変形の利点は、ＰＭＡとＨＡの間の往復時間がほぼ間違いなく短いことである。従って、ＨＡは、ＰＭＡによる高速回答を受信する。この変形を実現するためには、ＢＵ解決メッセージに対して常に応答するようにＰＭＡを変更する必要がある。
【０２０４】
最新ＢＵの解決に関して、様々な変形が可能である。主要な解決策では、リフレッシュ・アドバイス・オプションを伴うバインディング確認の展開が提示された。この解決策は、ＢＡｃｋへの応答が送信者によって署名されたＢＵ又はＰＢＵであるため、結果としてホーム・エージェントがメッセージの送信者を承認することから、好ましい。この方法では、最新のバインディング更新解決の解決策がセキュリティ・スレッドを持たない。しかし、バインディング更新の送信者、すなわちＭＮ及びプロキシ・モビリティ・エージェントをポーリングするためのホーム・エージェントに関する他のオプションが、想定可能である。具体的に言えば、ＢＡｃｋへの代替メッセージが送信可能であり、そのうちの一部を以下に列挙する。
【０２０５】
ＨＡは、気付けアドレス・テスト開始（ＣｏＴｉ）メッセージを、異なるタイプの両方の連続するバインディング更新のＣｏＡに送信することができる。ＣｏＴｉメッセージを受信するエンティティは、ＣｏＴメッセージで回答する。ＨＡはＣｏＴメッセージを受信した場合、ＣｏＴのソースＩＰアドレスに基づいて送信者を決定する。従って、ＨＡはモバイル・ノードの現在の位置を導出することができる。しかし、ＣｏＴメッセージは署名されていないことから、ＨＡは、幾つかの異なるＣｏＡを含み、ＭＮのデータ・フローを妨害する可能性がある攻撃者を区別できないため、最適なセキュリティが提供されない。この点で、このメッセージの使用は可能であるが、ＢＡｃｋを使用するよりも好ましくないとみなされる。
【０２０６】
別の方法としては、ＨＡは、ＩＣＭＰエコー要求を両方のＣｏＡ又はＣｏＡのうちの少なくとも１つに送信することができる。受信した回答に応じて、ＨＡは現在のＣｏＡの有効性を決定することができる。しかし、ファイアウォールは、フラッディング攻撃を避けるために、ＩＣＭＰメッセージをフィルタリング又は破棄することが可能である。この点で、このメッセージの使用は可能であるが、ＢＡｃｋを使用するよりも好ましくないとみなされる。
【０２０７】
第２の態様による本発明の他の実施の形態によれば、第２の態様による本発明の実施の形態に関して前述した原理は、ＰＭＩＰドメイン内の２つのＰＭＡ間でのモバイル・ノードのハンドオーバのケースで使用することができる。本発明の第２の態様で説明された解決策は、シーケンス番号（ＣＢＵ）又はタイムスタンプ（ＰＢＵ）のいずれかを含むことから、ＢＵが直接比較できない場合、最新のＢＵを選択する問題を目標とする。しかし、この解決策は、時間が同期されていない異なるＰＭＡから来るＰＢＵを区別することにも適用可能である。これは、ＭＮが、時間が同期されていないＰＭＩＰドメイン間を移動する場合に発生する可能性がある。この場合、両方のＰＭＩＰドメインから来る連続ＰＢＵはタイムスタンプ・オプションを有するが、タイムスタンプはＰＢＵの新しさに関して決定するには不十分である。こうしたケースでは、第１に、ＨＡはＰＢＵを送信するＰＭＡの欠落した時間同期化に関して（例えば、事前構成を介して）知るべきである。第２に、ＨＡは、それらの非同期ＰＭＡから来るＰＢＵを、異なるタイプからのＢＵとして扱う。ＢＵ競合状態検出手順が競合状態を検出した場合、ＨＡは最新ＢＵの解決手順をトリガする。
【０２０８】
以下で、本発明の第３の態様について説明する。
【０２０９】
本発明の第３の態様の説明で頻繁に使用される幾つかの用語の定義が提供される。
【０２１０】
セキュリティアソシエーションは、２つのノード又は機能エンティティがセキュアな通信をサポートするために共有するセキュリティ情報のセットとして定義可能である。例えば、セキュリティアソシエーションは、データ暗号化アルゴリズム、データ暗号鍵（例えば、秘密鍵又は公開／秘密鍵ペア）、初期化ベクトル、デジタル証明などを含むことができる。通常、フォーリン・ネットワーク内のモバイル・ノードと、ホーム・ネットワーク内のそのホーム・エージェントとの間に、セキュリティアソシエーションが提供される。それ故、たとえモバイル・ノードがフォーリン・ネットワークに接続されている場合であっても、ホーム・エージェントとモバイル・ノードとの間の（例えば、セキュアなトンネルを介した）暗号化及び／又は認証／承認された通信が確保できる。
【０２１１】
トークンは、セキュリティ関連機能及び手順で使用可能な暗号化情報である。１つ又は複数のトークンを使用して、モバイル・ノード及び通信相手ノードは、例えば、通信相手ノードでのモバイル・ノードに対するバインディングの登録に関するメッセージの承認された通信を達成することができる。トークンは、例えば、いわゆるノンスと呼ばれる乱数を使用して、生成可能である。１つ又は複数のトークンを組み合わせて、新しいトークンを形成することができる。
【０２１２】
キー生成トークンは、モバイル・ノードが、バインディング更新を承認するために必要なバインディング管理キーを計算できるようにするためのリターン・ルータビリティ手順において、通信相手ノードによって供給される番号とすることができる。従って、気付けキー生成トークンは、気付けテストで通信相手ノードによって送信されるキー生成トークンであるが、ホーム・キー生成トークンは、ホーム・テストで通信相手ノードによって送信されるキー生成トークンを示す。
【０２１３】
バインディング管理キー（Ｋｂｍ）は、バインディング・キャッシュ管理メッセージ（例えば、バインディング更新又はバインディング確認）を承認するために使用されるキーである。リターン・ルータビリティは、バインディング管理キーを作成するための方法を提供する。
【０２１４】
ノンスは、通常、リターン・ルータビリティ手順に関するキー生成トークンの作成において、通信相手ノードによって内部的に使用される。ノンスは、モバイル・ノード特有のものではなく、通信相手ノード内で秘密裏に維持される。ノンス・インデックスは、キー生成トークン値を作成する際に、ノンス自体を明らかにすることなく、どのノンスが使用されたかを示すために使用される。
【０２１５】
クッキーは、リターン・ルータビリティ手順において偽の通信相手ノードによるスプーフィングを防ぐために、モバイル・ノードによって使用される乱数である。気付け開始クッキーは、気付けテスト開始メッセージ内の通信相手ノードに送信されるクッキーである。この気付け開始クッキーは、モバイル・ノードが応答の真正性をチェックできるようにするために、気付けテスト・メッセージで戻すことができる。同様に、ホーム開始クッキーは、ホーム・テスト・メッセージで戻されることになるホーム・テスト開始メッセージ内の通信相手ノードに送信されるクッキーである。
【０２１６】
気付けアドレスの登録は、その間にモバイル・ノードがバインディング更新をそのホーム・エージェント又は通信相手ノードに送信するプロセスであり、モバイル・ノードに対するバインディングを登録させる。リターン・ルータビリティ手順は、登録を進行させることが可能であり、暗号トークン交換の使用によって、後続の登録を承認するために使用可能である。
【０２１７】
通常、承認されているバインディング更新は、承認バインディング更新と呼ばれる。一般に、承認バインディング更新は、バインディング更新を認証するためのメッセージ認証コードなどの何らかの暗号情報を含むバインディング更新とみなすことができる。前述のように、承認バインディング更新は、例えば、リターン・ルータビリティ手順で通信相手ノードとモバイル・ノードとの間で交換される暗号情報に基づいて生成されることが可能なメッセージ認証コードを含むことができる。
【０２１８】
一般に、メッセージに組み込まれたメッセージ認証コードの使用により、通信パス又は接続などの信頼できない媒体を介して送信されるか、又はこの媒体に格納される情報の保全性をチェックする方法が提供される。典型的には、秘密鍵に基づくこうした保全性チェックを提供するメカニズムは、通常、メッセージ認証コード（ＭＡＣ）と呼ばれる。典型的には、メッセージ認証コードは、秘密鍵を共有する２者間で、これらの当事者間で送信される情報の妥当性を検査するために使用される。ＭＡＣメカニズムは、例えば暗号ハッシュ関数（例えば、ＭＤ５及びＳＨＡ１）に基づくものとすることができる。さらに、採用される秘密鍵は、例えば暗号ハッシュ関数を使用して生成することも可能な、暗号情報とすることができる。本発明の実施の形態で使用される暗号ハッシュ関数に関する詳細は、例えば、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇで入手可能であり、参照により本明細書に組み込むものとするＨ．Ｋｒａｗｃｚｙｋ他の、「ＨＭＡＣ：Ｋｅｙｅｄ−Ｈａｓｈｉｎｇ  ｆｏｒ  Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」、ＩＥＴＦ  ＲＦＣ２１０４、１９９７年２月で見ることができる。
【０２１９】
リターン・ルータビリティは、その後交換されるメッセージを承認できることに基礎を置いたモバイル・ノードと通信相手ノードとの間での暗号情報の交換を含む手順である。一実施の形態では、リターン・ルータビリティ手順は、モバイル・ノードの後続のバインディング更新を認証するために、モバイル・ノードに２つのトークン（ホーム・キー生成トークン及び気付けキー生成トークンを示す）を提供するホーム・テスト及び気付けテストを含むＭＩＰｖ６リターン・ルータビリティ手順と同様である。しかし、以下のセクションから明らかとなるように、本発明の幾つかの実施の形態では、この手順はホーム・テストが不要な（又は言い換えれば、ホーム・テストを「スキップ」できる）ように変更される。さらに他の実施の形態では、バインディング確認の認証にはリターン・ルータビリティは不要である。
【０２２０】
既に前述したように、本発明の目標の１つは、モバイル・ノードが、通信相手ノードでそのバインディング・キャッシュ・エントリがいつスプーフィングされたかを検出できるようにすることである。通信相手ノードでのモバイル・ノードに対するスプーフィングされたバインディング・キャッシュ・エントリの検出は、例えば、攻撃の影響を無効にするような対応策（例えば、通信相手ノードでバインディングを修復する）を即時に実行できるようにする。
【０２２１】
本明細書では、モバイル・ノードのバインディングに対する攻撃を検出するための複数のメカニズムについて概説する。本発明の第３の態様による一実施の形態では、この検出メカニズムは、承認されたバインディング更新を受信した後に、複数のバインディング確認をモバイル・ノードの異なるアドレスに送信する通信相手ノードを含む。モバイル・ノードの新しい気付けアドレスにバインディング確認を送信することに加えて、又はその代わりに、通信相手ノードは、モバイル・ノードのホーム・アドレス及び／又は古い気付けアドレスに、バインディング確認を送信することができる。従って、モバイル・ノードは、対応するバインディング更新を送信していない可能性があるが、バインディング確認を受信することになり、これは、モバイル・ノードによって、通信相手ノードのそのバインディング・エントリへの攻撃成功であると解釈される可能性がある。１つの例示的実施の形態では、モバイル・ノードは、承認されたバインディング更新によって登録解除されたその気付けアドレスが、（オプションで）そこから切り離される前に、この気付けアドレスに向けて送られたバインディング確認を受信するように定義されたネットワークに接続された状態の可能性がある。
【０２２２】
本発明の第３の態様による他の実施の形態では、検出メカニズムは、バインディング・テストを使用して通信相手ノードにおけるバインディング・エントリの正当性をチェックするモバイル・ノードを含む。このテストは、例えば、１つ又は複数のバインディング・テスト・メッセージを通信相手ノードに送信することを含む。バインディング・テスト・メッセージは、通信相手ノードからの回答を必要とする（例えば、ＩＣＭＰエコー要求／応答と同様に）場合がある。モバイル・ノードは、例えばこれらのバインディング・テスト・メッセージを１回、定期的に、又は例えば、通信相手ノードによってある期間中データが受信されていない場合など、場合によって送信することができる。バインディング・テスト・メッセージは、例えば、モバイル・ノードのホーム・エージェントを介してトンネリングすることが可能であるため、結果として、モバイル・ノードのホーム・アドレスをソース・アドレスとして有することになり、通信相手ノードはバインディング・キャッシュ・エントリを回答に使用しなければならない。複数のテスト・メッセージを送信した後、何の回答も受信されない場合、モバイル・ノードは、この応答の欠落を、通信相手ノードでのそのバインディングに対する攻撃成功の指標として解釈することができる。
【０２２３】
本発明の第３の態様による本発明の他の実施の形態では、通信相手ノードでのスプーフィングされたバインディング・キャッシュ・エントリの検出は、送信要請されていないプローブ・メッセージをモバイル・ノードの現在の気付けアドレスに送信する通信相手ノードを含むことができる。プローブ・メッセージは、例えば通信相手ノードによって、ある期間中、定期的に、又は場合によって、モバイル・ノードに送信することができる。プローブ・メッセージは、例えば、バインディング確認メッセージとすることができる。複数の期間中、データ及び／又はバインディング確認が受信されない場合、モバイル・ノードはこれを、通信相手ノードでのそのバインディング・キャッシュ・エントリへの攻撃成功の指標として解釈することができる。
【０２２４】
これらの検出メカニズムは、既存のバインディング手順に加えて、それらをよりセキュアにするために使用可能であるか、又は第１の場所ですべての攻撃を防止しないことを犠牲にして、信号オーバヘッド及びハンドオーバ遅延を低減させるように、バインディング手順を最適化するために使用可能である。しかし、モバイル・ノードが攻撃を検出し、攻撃の影響を無効にするために即時に対策を講じることができるため、セキュリティの低下は防止される。さらに、異なる検出メカニズムを個別に、又は任意の組合せで採用することができる。
【０２２５】
本発明の第３の態様の他の目的は、例えば暗号的に生成されたアドレスを必要としないような、リターン・ルータビリティ手順の最適化及びルート最適化モードに関する。本発明の第３の態様による一実施の形態では、モバイル・ノード及び通信相手ノードによってホーム・テストを初期にのみ実行することが可能であり、ホーム・キー生成トークンは、後続の楽観的な（optimistic）リターン・ルータビリティ・ラウンドで再使用される、すなわち、ホーム・テスト（ＨｏＴ／ＨｏＴｉ交換）がスキップされる。これにより、信号オーバヘッド及びハンドオーバ遅延は低減可能であるが、通信相手ノードでのモバイル・ノードのバインディングに対する時間移動攻撃を容易にする。しかし、この欠点は、例えば本明細書に記載された様々なメカニズムのうちの１つを使用して、モバイル・ノードが攻撃を検出することによって補償可能である。攻撃の検出に応答して、モバイル端末は、例えば完全なリターン・ルータビリティ手順（ホーム・テスト／ホーム・テスト開始交換を含む）を開始して、バインディングを即時に修復し、新しいホーム・キー生成トークンを生成することができる。
【０２２６】
前述のように、本発明の第３の態様による実施の形態では、モバイル・ノードのバインディング・キャッシュ・エントリをスプーフィングしている攻撃者は、承認されたバインディング更新を受信した後に、モバイル・ノードの異なるアドレスに複数のバインディング確認を送信する通信相手ノードに基づいて検出することができる。例えば、モバイル・ノードの新しい気付けアドレスにバインディング確認を送信することに加えて、通信相手ノードは、モバイル・ノードのホーム・アドレスに、及び／又はオプションで古い気付けアドレスに、バインディング確認を送信する。
【０２２７】
図１９は、本発明の例示的実施の形態に従い、モバイル・ノードのホーム・ネットワークを介して送信されたバインディング確認に基づいて、モバイル・ノードが、通信相手ノードでのそのバインディングに対する攻撃を検出することが可能な、攻撃者、モバイル・ノード、通信相手ノード、及びホーム・エージェントの間で交換される例示的メッセージ・シーケンスを示す。例示の目的で、モバイル・ノード及び通信相手ノードは、データ・パケットを交換するためにルート最適化を使用するものと仮定される。
【０２２８】
さらに単なる例示の目的で、攻撃者は、例えば、モバイル・ノードに向けて送られたデータを傍受又は不正変更するために、アドレス・スティーリング／偽装攻撃を実行するものと仮定される。従って攻撃者は、通信相手ノード（ＣＮ）によってリターン・ルータビリティ手順５０１及び後続の気付けアドレス登録手順５０２を巧みに実行する可能性がある。リターン・ルータビリティ手順の結果として、バインディングを認証するための関連する暗号情報を取得すると、その後攻撃者は、例えば、その独自のアドレスをモバイル・ノードの気付けアドレスとして登録し、モバイル・ノードの気付けアドレスに向けて送られたトラフィックをそれ自体に宛先変更するために、バインディング更新を通信相手ノードに送信する５０５。攻撃者はバインディング更新を（例えば、リターン・ルータビリティ手順５０１から取得した暗号情報に基づいて決定されたメッセージ認証コードを含めることによって）有効に認証することができるため、通信相手ノードは、モバイル・ノードの新しい気付けアドレスとしてアドレスをバインディング更新に登録する５０３（すなわち、新しい、スプーフィングされた気付けアドレスを示すように、モバイル・ノードのホーム・アドレスに対するバインディング・キャッシュ・エントリを更新する）ことになる。
【０２２９】
新しい気付けアドレスの登録を確認するために、承認されたバインディング更新に示された新しい気付けアドレスにバインディング確認を送信すること５０５に加えて（又はその代わりに）、通信相手ノードは、（他の）バインディング確認をモバイル・ノードのホーム・アドレスに送信し５０６、その結果、バインディング確認が第１にモバイル・ノードのホーム・エージェントにルーティングされ、ここで、ホーム・エージェントのバインディング・キャッシュでのモバイル・ノード・レジスタの気付けアドレス（すなわち、実際のスプーフィングされていないモバイル・ノードの気付けアドレス）を使用して、バインディング確認がモバイル・ノードに転送される５０７。
【０２３０】
従って、モバイル・ノードは、対応するバインディング更新を送信していないが、バインディング確認を受信し、これはモバイル・ノードによって、通信相手ノードにおけるそのバインディング・エントリに対する攻撃の成功として解釈される可能性がある。より詳細には、モバイル・ノードは、この通信相手ノードに送信された最後の（確認されていない）バインディング更新の再送ウィンドウ内にない（すなわち、シーケンス番号よりも上、又はあるしきい値だけ下の）シーケンス番号を備えたバインディング確認が受信された場合、例えば通信相手ノードでのそのバインディングに対する攻撃を検出することができる５０８。
【０２３１】
さらに、本発明の第３の態様による実施の形態の変形において、通信相手ノードは、バインディング確認をモバイル・ノードのホーム・アドレスに送信すること５０５、５０６に加えて、又はその代わりに、バインディング確認を、モバイル・ノードの以前に登録された気付けアドレス（攻撃の際に有効な気付けアドレスであるものとする）にも送信可能であることに留意されたい。このオプションによって、モバイル・ノードはそのバインディングへの攻撃を認識できるようになる。
【０２３２】
モバイル・ノードはそのバインディングへの攻撃を検出した場合、例えばバインディングを再度修復するために対応策を講じることができる。図１９の例示的実施の形態では、モバイル・ノードは、新しい暗号情報を生成するように、ホーム・テスト５１０及び気付けテスト５１１を含むリターン・ルータビリティ手順５０９を実行する。１つの例示的実施の形態では、ホーム・テストは、クッキーを備えたホーム・テスト開始メッセージをホーム・ネットワーク（すなわちホーム・エージェント）を介して通信相手ノードに送信し、通信相手ノードは応答を送信し、例えばホーム・キー生成トークンを含むホーム・テスト・メッセージを送信することを含むことができる。ホーム・テスト・メッセージは、ホーム・エージェントを介してモバイル・ノードに送信される。これと同様に、気付けテストは、例えば、クッキーを備えた気付けテスト開始メッセージを通信相手ノードに直接送信し、通信相手ノードは応答を送信し、例えば気付けキー生成トークンを含む気付けテスト・メッセージを送信することを含むことができる。
【０２３３】
リターン・ルータビリティ手順から取得された暗号情報を使用して、モバイル・ノード及び通信相手ノードは、後続のバインディング更新を認証するために使用されるバインディング・キーを決定／生成すること５１２、５１３ができる。ステップ５１２、５１３はオプションとすることができる。例えばリターン・ルータビリティ手順は、モバイル・ノード及び通信相手ノードに、後続メッセージの認証に直接使用可能な暗号情報を提供することができる。
【０２３４】
リターン・ルータビリティ手順５０９の正確な実施に関係なく、そこから得られた暗号情報は、その後、モバイル端末によって使用され、通信相手ノードでのその正しい気付けアドレスの登録５１４を認証し、それによってバインディングを修復し、検出された攻撃の影響を無効にする。その後、モバイル・ノードに送信され５１５、ここで気付けアドレスを正しく登録したパケットが、モバイル端末に再度ルーティングされることになる。
【０２３５】
前述の再送ウィンドウは、例えば、再送されたバインディング更新メッセージに関するバインディング確認が受信可能なウィンドウとして定義することができる。例えば、モバイル・ノードがシーケンス番号１１を備えたバインディング更新を送信し、モバイル・ノードの再送タイマが期限切れになる前に、シーケンス番号１１を備えたバインディング確認が受信されない場合、モバイル・ノードは、新しいシーケンス番号（例えば１２）を備えた他のバインディング更新を送信することになる。ここで、シーケンス番号１１を備えたバインディング更新もバインディング確認メッセージも失われないが、代わりに、（ネットワーク内の一時的な輻輳により）再送タイマよりも長い時間だけ遅延している可能性がある。この場合、モバイル・ノードは、現在のシーケンス番号よりも下のシーケンス番号を備えた遅延バインディング確認を受信する。再送ウィンドウは、静的又は動的に構成可能であるため、モバイル・ノードは通常、現在のシーケンス番号から再送サイズを引いたものより下のシーケンス番号を備えたバインディング確認は受信しない。例えば攻撃は、再送ウィンドウ外の、例えば、現在のシーケンス番号よりも上、又はあるしきい値だけ下のシーケンス番号を備えたバインディング確認が、モバイル・ノードで受信された場合、検出可能である。
【０２３６】
しかし、このメカニズムにとってパケット損失は問題である。攻撃が成功し、バインディング確認がバインディング更新メッセージへの回答としてのみ送信され、それらのバインディング確認が失われた場合、モバイル・ノードは攻撃を検出できない。様々なメカニズムを使用して、こうしたパケット損失シナリオに対処することができる。オプションの１つは、モバイル・ノードがバインディング確認メッセージに関する確認を送信することであり、その結果、通信相手ノードはパケット損失を検出し、バインディング確認メッセージを再送することができる。
【０２３７】
本発明の第３の態様による他の実施の形態では、モバイル・ノードは、プローブ・メッセージを通信相手ノードに送信することによって、通信相手ノード内のバインディング・エントリの正当性をチェックするが、これには、（例えば、ＩＣＭＰエコー要求／応答と同様に）通信相手ノードからの回答が必要であり、これによって応答は、通信相手ノードで登録されたモバイル・ノードの気付けアドレスに向けて送られることになる。この実施の形態の変形の１つでは、通信相手ノードは、プローブ・メッセージがモバイル・ノードのホーム・ネットワークを介して（すなわちホーム・エージェントから）受信されるか、モバイル・ノードから直接受信されるかに関係なく、常に、バインディング・キャッシュに登録された気付けアドレスをその応答の宛先として使用する。これらのプローブ・メッセージは、１回、定期的に、又は例えば、通信相手ノードによってある期間中データが受信されていない場合など、場合によって送信することができる。プローブ・メッセージは、ホーム・エージェントを介してトンネリング可能であるため、モバイル・ノードのホーム・アドレスをソース・アドレスとして有し、通信相手ノードは回答にバインディング・キャッシュ・エントリを使用しなければならない。他のオプションは、プローブ・メッセージをモバイル・ノードから通信相手ノードへ直接送信することである。複数回答後、プローブ・メッセージへの回答が受信されない場合、モバイル・ノードはこれを攻撃成功の指標と解釈することができる。
【０２３８】
図２０は、本発明の第３の態様による例示的実施の形態に従ったバインディング・テストに基づいて、モバイル・ノードが、通信相手ノードでのそのバインディングに対する攻撃を検出することが可能な攻撃者、モバイル・ノード、通信相手ノード、及びホーム・エージェントの間で交換される例示的メッセージ・シーケンスを示す。例えば例示の目的で、モバイル・ノード及び通信相手ノードは、データ・パケットを交換するためにルート最適化を使用するものと仮定される。
【０２３９】
図１９に示された例のように、本発明の第３の態様によるこの実施の形態においても、単なる例示の目的で、攻撃者がアドレス・スティーリング又は偽装攻撃を開始するものと仮定される。従って、攻撃者は第１に、リターン・ルータビリティ手順５０１を実行し、その後、通信相手ノードでそのアドレスを登録する５０２、５０３、５０４、５０５。これらのステップは図１９のステップと同様であるため、詳細については、図１９の説明を参照されたい。従って、スプーフィングされたモバイル・ノードの気付けアドレスに向けて送られた通信相手ノードからのすべてのデータは、通信相手ノードのバインディング・キャッシュにおけるモバイル・ノードの新しい気付けアドレスとして、攻撃者のアドレスに、その登録時に提供されることになる６０１。
【０２４０】
図１９とは異なり、この例示的実施の形態では、攻撃者を検出するためにバインディング・テスト・メカニズムが使用されることから、通信相手ノードが、モバイル・ノードのホーム・アドレス又は以前に登録された気付けアドレスにバインディング更新を送信する必要がないことは要求されないことに留意されたい。しかし、他の実施の形態では、バインディング確認に基づいて攻撃者を検出するためのメカニズム、及びバインディング・テストを使用するためのメカニズムを組み合わせて、有利に使用することも可能である。
【０２４１】
本発明の第３の態様によるこの実施の形態で提案されたバインディング・テスト６０２に戻ると、例えば同じことが、例えば、ＩＣＭＰエコー／応答メカニズムと類似のメカニズムを使用する要求応答スキームに基づくものとすることができる。モバイル・ノードは、バインディング・テスト要求メッセージを通信相手ノードに送信する６０３ことができる。図２０に示された例では、バインディング・テスト要求は通信相手ノードに直接送信される。オプションで、モバイル・ノードは、バインディング・テスト要求をそのホーム・エージェントに逆トンネリングし、ここでバインディング・テスト要求を通信相手ノードに転送することができる。いずれのケースでも、通信相手ノードは、バインディング・テスト応答メッセージを送信すること６０５によって、この要求に応答することになる。このメッセージは、通信相手ノードのバインディング・キャッシュから取得された６０４、要求側モバイル・ノードの現在登録されている気付けアドレスに向けて送られる。通信相手ノードでのモバイル・ノードのバインディングが攻撃者によってスプーフィングされているものと仮定し、モバイル端末からのバインディング・テスト要求に対するバインディング・テスト応答が、スプーフィングされている気付けアドレス、すなわち、この例では攻撃者に向けて送られる。
【０２４２】
オプションで、モバイル・ノードは、通信相手ノードでそのバインディング・キャッシュ・エントリを検証するために、複数のバインディング・テスト要求メッセージを送信することができる。これは、図２０で、破線で示されたメッセージ６０６、６０８、及び破線で示された機能ブロック６０７で示されている。
【０２４３】
モバイル・ノードは、バインディング・テスト・メッセージについて、及び１つ又は複数のバインディング要求メッセージがタイムアウトした（すなわち、しきい値期間内に応答を受信しない）場合に、タイマを開始することが可能であり、モバイル・ノードは、この環境を、通信相手ノードでのそのバインディングの破損とみなすことができる。従って図１９の状況と同様に、モバイル・ノードは、例えば、ホーム・テスト５１０及び気付けテスト５１１を含む完全なリターン・ルータビリティ・テスト５０９を実行することによって、オプションで、モバイル・ノード及び通信相手ノードでバインディング・キーを生成すること５１２、５１３、並びにスプーフィングされたバインディングを修理するために、モバイル・ノードの正しい気付けアドレスを再度登録すること５１４によって、適切な対応策を講じることができる。
【０２４４】
図２０に関して前述された実施の形態では、例示の目的で、モバイル・ノードからの対応する要求に応答して、通信相手ノードによってバインディング・テスト応答が送信されること、すなわち、送信要求された応答メッセージであることが仮定されている。本発明の第３の態様による他の実施の形態では、通信相手ノードは送信要請されていないアライブ・メッセージを送信することができる。これらのアライブ・メッセージは、例えば通信相手ノードによって、定期的に又は場合によって（例えば、ある期間中、通信相手ノードによってモバイル・ノードにデータが送信されていない場合）送信することが可能であり、通信相手ノードのバインディング・キャッシュに登録されたモバイル・ノードの現在の気付けアドレスに向けて送られる。例示的な一実施の形態では、送信要請されていないアライブ・メッセージはバインディング確認メッセージである。複数のしきい値期間中、データ及び／又は送信要請されていないアライブ・メッセージが受信されない場合、モバイル・ノードはこれを攻撃成功の指標として解釈することができる。本質的に、送信要請されていないアライブ・メッセージを使用するバインディング・テストは、図２０に示されたメカニズムと同様である。これとは対照的に、モバイル・ノードはバインディング・テスト要求を送信せず（ステップ６０３、６０６）、その気付けアドレスに向けて送られた通信相手ノードからデータ・パケットを受信すると、又は送信要請されていないアライブ・メッセージを受信すると、タイマを再開することができる。さらにこのケースでは、バインディング・テスト応答メッセージ６０５、６０８を、送信要請されていないアライブ・メッセージとみなすことができる。
【０２４５】
上記で概説された本発明の第３の態様による様々な実施の形態による検出メカニズムを、既存のバインディング手順に加えて使用し、それらをよりセキュアにすることができる。例えば、新しいメカニズムによって、モバイル・ノードは、標準的なリターン・ルータビリティ手順／ルート最適化モードでパス上攻撃を検出すること、又は暗号化生成アドレスのスプーフィングのようなあり得ない攻撃をカバーすることが可能である。後者の場合、攻撃者は、既存の暗号化生成アドレスを生成する公開鍵を計算するために強引な攻撃を実行することになる。暗号化生成アドレスを生成するために使用されるセキュリティ・パラメータに応じて、こうした強引な攻撃に必要な労力は現実的な範囲内にあるとすることができる。本明細書で提案された検出メカニズムを使用すれば、こうした攻撃は検出可能であり、その影響を無効にするための動作をトリガすることができる。
【０２４６】
さらに、本明細書で提案されたメカニズムは、第１の場所ですべての攻撃は防止しないが、信号オーバヘッド及びハンドオーバ遅延を低減させる方法で、バインディング手順（リターン・ルータビリティ手順を含む）を最適化するためにも使用可能である。モバイル・ノードは攻撃を検出した場合、攻撃の影響を無効にするための何らかの動作を即時に実行する。
【０２４７】
こうした動作は、上記で例証したような完全なリターン・ルータビリティ手順を含む新しい通信相手登録を開始することによって、通信相手ノードでのバインディング・キャッシュ・エントリの修復とすることができる。
【０２４８】
スプーフィングされたバインディングの修復に加えて、他の追加又は代替の対応策は、攻撃に関して通信相手ノードに通知することの場合がある。攻撃に関する通知に応答して、通信相手ノードは、例えばモバイル・ノードに対するルート最適化を停止すること、及び／又はあるアドレス又はプレフィックスからのそれ以上のバインディング更新メッセージをブロックすることができる。例えば、攻撃者がトラフィックをそれ自体に宛先変更した場合、スプーフィングされた気付けアドレスは、実際に攻撃者の有効アドレスであるため、通信相手ノードにはネットワーク・プレフィックス及び攻撃者のアドレスがわかっている。
【０２４９】
攻撃者がスプーフィングすること、又は攻撃に関する通知が通信相手ノードに報告されないように妨害することを防ぐために、本発明の第３の態様による一実施の形態は、モバイル・ノードが攻撃に関して通信相手ノードにセキュアに通知することに関する。これは、例えば、モバイル・ノードが新しく生成された暗号情報（例えば、バインディング・キー）で署名した通知メッセージを送信することによって、実施可能である。別の方法としては、通信相手ノードとホーム・エージェントとの間に信頼関係（又はセキュリティ阿蘇ｓ-エーション）が存在する場合、さらにモバイル・ノードはホーム・エージェントを介して通信相手ノードに通知を送信する。ホーム・エージェントはメッセージにキーで署名し、これによって通信相手ノードは、通知がホーム・エージェントを介してルーティングされたか否かを検証することができる。通常はモバイル・ノードとホーム・エージェントとの間にセキュリティアソエーションが提供されるため、この手順は、攻撃に関する通知の真正性を保護することができる。
【０２５０】
本発明の第３の態様の他の目的は、モバイル・ノードの気付けアドレスの１つ又は複数の変更を含むセッション全体にわたって、モバイル・ノードと通信相手ノードとの間の通信が維持できること、及び、ホーム・エージェントが（一時的に）到達可能でない場合もルート最適化を使用できることである。特に、新しいバインディングを認証するための暗号情報をモバイル・ノードに提供するために、ホーム・エージェントがリターン・ルータビリティ手順に関与する必要がある場合、モバイル・ノードのホーム・エージェントの停止は、セッション／サービスの中断又は終了につながる場合がある。
【０２５１】
従って、本発明の第３の態様による他の実施の形態は、モバイル・ノードのホーム・エージェントの到達可能性に完全には依存しない、承認された気付けアドレス登録に関する最適化された手順を提供することに関する。
【０２５２】
本発明の第３の態様による１つの例示的実施の形態では、リターン・ルータビリティ手順及び気付けアドレス登録に対する改良点が提案される。
【０２５３】
本発明の第３の態様によるこの実施の形態によれば、リターン・ルータビリティ手順及び後続の気付けアドレス登録が機能強化され、ホーム・アドレス・テストを省略することができる。ホーム・アドレス・テストの一般的な省略では、あるシナリオにおいて偽装攻撃が可能な場合があるため、本明細書に記載された発明の第３の態様による幾つかの実施の形態では、初期ホーム・アドレス・テストの実行を提案している。本発明の第３の態様による他の実施の形態では、通信相手ノードでスプーフィングされたバインディング・キャッシュ・エントリを検出するための様々なメカニズムのうちの１つ又は複数を使用して、時間移動攻撃を検出し、その影響を無効にすることができる。
【０２５４】
本発明の第３の態様による１つの例示的実施の形態によるリターン・ルータビリティ手順及び後続の気付けアドレス登録に対する改良点について、以下で、図２１に関して概説する。図２１は、本発明の第３の態様による例示的実施の形態による、改良されたリターン・ルータビリティ手順及び後続の気付けアドレス登録に従った、モバイル・ノード、通信相手ノード、及びホーム・エージェントの間で交換されるメッセージ・シーケンスの例を示す。
【０２５５】
初期に、モバイル・ノードは、ホーム・テスト７０２及び気付けテスト７０３を含む（完全な）リターン・ルータビリティ手順を実行する７０１。一例では、このリターン・ルータビリティ手順は、ＩＥＴＦ  ＲＦＣ３７７５で提案された手順と同様である。この手順で交換される暗号情報に従って、モバイル・ノード及び通信相手ノードは、それぞれバインディング・キーを生成すること７０４、７０５ができる。
【０２５６】
続いて、モバイル端末は気付けアドレス登録を開始する。モバイル端末は、承認されたバインディング更新を通信相手ノードに送信する７０６。一般に、承認されたバインディング更新は、例えば、どのホーム・アドレスに対して（すなわち、どのモバイル・ノード又はそのインターフェイスに対して）、通信相手ノードのバインディング・キャッシュ内にバインディング・キャッシュ・エントリを生成又は変更すべきであるかを示すためのモバイル・ノードのホーム・アドレスと、登録されることになる新しい気付けアドレスとを含むことができる。さらに、承認されたバインディング更新は、バインディング確認に対するバインディング更新の関連付けを可能にするように、例えばシーケンス番号を含むことができる。バインディング更新の送信者を認証するために、例えばモバイル・ノードは、リターン・ルータビリティ手順で取得された暗号情報、例えばバインディング・キーに基づいて生成されたバインディング更新に対するメッセージ認証コードを含むことができる。
【０２５７】
モバイル・ノードは、後続のリターン・ルータビリティ・ラウンド（「楽観的リターン・ルータビリティ・ラウンド」と呼ばれる場合がある）で、ホーム・アドレス・テストを省略したい場合、承認されたバインディング更新にフラグ（ｐｋｔ＿ｇｅｎ＿ｆｌａｇ）を設定することが可能であり、このフラグは、設定された場合に、後続の楽観的リターン・ルータビリティ・ラウンドで使用されることになる永続キー生成トークンを生成することを通信相手ノードに指示する。バインディング更新のメッセージ認証コード（ＭＡＣ）が正しい場合、通信相手ノードは、承認されたバインディング更新で示されるモバイル・ノードの気付けアドレスを登録し７０７、永続ホーム・キー生成トークンを決定／計算すること７０８ができる。
【０２５８】
例えば、永続キー生成トークンは、少なくともホーム・テスト・メッセージ内のホーム・キー生成トークンに基づいて計算可能である。ホーム・キー生成トークンは、永続キー生成トークンとしても使用可能である。この場合、ホーム・キー生成トークンは、後続の楽観的リターン・ルータビリティ・ラウンドで再使用される。永続キー生成トークンは、この場合、永続ホーム・キー生成トークンと呼ぶことができる。別の方法としては、通信相手ノードは、他の手段で永続トークンを計算することができる。本発明の第３の態様による１つの例示的実施の形態では、永続キー生成トークンは、ハッシュ関数（例えば、ＳＨＡ１）を使用して以下のように計算される。
ｐｅｒｍａｎｅｎｔ  ｋｅｙｇｅｎ  ｔｏｋｅｎ＝Ｆｉｒｓｔ（６４，ＳＨＡ１（Ｋｂｍ｜ｓｅｑｎｏ））
【０２５９】
｜は、モバイル・ノードによって受信／送信されるバインディング更新において、バインディング・キーＫｂｍとシーケンス番号ｓｅｑｎｏとの連結子を示すことに留意されたい。Ｆｉｒｓｔ（ｘ，．．．）は、バインディング・キーＫｂｍとシーケンス番号ｓｅｑｎｏとの連結子に適用されるハッシュ関数ＳＨＡ１の結果から、第１のｘビットを抽出する関数である。この関数で使用されるバインディング・キーは、例えば、リターン・ルータビリティ手順のホーム・テストから取得されたホーム・キー生成トークン、ホーム・テストを含むリターン・ルータビリティ手順から取得された任意の他の暗号情報、又はその組合せとすることが可能なことに留意されたい。本発明の一実施の形態では、バインディング・キーＫｂｍは、本明細書で前述したＩＥＴＦ  ＲＦＣ３７５５に定義されたように計算される。
【０２６０】
本発明の第３の態様による他の実施の形態では、気付けキー生成トークンをバインディング・キーの一部として含めることができる。この利点は、攻撃者が正しい永続キー生成トークンを計算するためには、初期ホーム・テスト・メッセージ及び対応する気付けテスト・メッセージの両方を受信していなければならない点である。永続トークンは、通信相手ノード内のモバイル・ノードに対するバインディング・キャッシュ・エントリに格納することができる。
【０２６１】
さらに通信相手ノードは、バインディング更新の成功を示すバインディング確認をモバイル・ノードに返信すること７０９ができる。その後、モバイル・ノードは、通信相手ノードが実行した方法と同様に、永続ホーム・キー生成トークンを計算７１０及び格納するため、その結果、モバイル・ノード及び通信相手ノードの両方が、対応する永続トークンを生成及び格納する。どちらのノードも有限存続期間をトークンに割り当てることが可能であり、これは事前に決定又は取り決めすることができる。さらに、この存続期間は７分よりも大幅に長い可能性がある。
【０２６２】
モバイル・ノード及び通信相手ノードでモバイル・ノードに対する新しいバインディングを正常に登録すると、モバイル・ノードの更新された気付けアドレスを使用してデータ・パケットを交換すること７１１ができる。
【０２６３】
上記で例証したように、モバイル・ノード及び通信相手ノードで永続トークンを生成すると、この永続トークンをモバイル・ノードの後続の気付けアドレス登録に使用すること、又はより詳細には、モバイル・ノードから送信される後続のバインディング更新の認証に使用することができる。気付けアドレスの後続の登録は、今後ホーム・テストを利用することはできない。幾つかの実施の形態では、気付けテストでさえも使用されない。これにより、例えば通信相手ノードでモバイル・ノードの気付けアドレスを登録するために必要な信号を削減することが可能であり、及び／又はたとえモバイル・ノードにサービスを提供する（又はより詳細には、そのインターフェイスのうちの１つ又は複数についてモバイル・ノードにサービスを提供する）ホーム・エージェントが、例えば障害、攻撃、ネットワーク輻輳などによって、ダウンした場合であっても、気付けアドレスの登録及びルート最適化の使用が可能である。
【０２６４】
図２２は、永続トークンが認証に使用される、本発明の第３の態様による例示的実施の形態に従い、通信相手ノードの気付けアドレスを登録するために、モバイル・ノードと通信相手ノードとの間で交換されるステップ及びメッセージのシーケンスを示す。例えば新しいネットワーク又は他のプレフィックスを使用するネットワークの他の管理ドメインへの接続により、モバイル・ノードによって新しい気付けアドレスが割り当て又は生成されると、モバイル・ノードは、通信相手ノードでその新しい気付けアドレスの登録に備える。この実施の形態では、ホーム・テスト又は気付けテストは実行されない。代わりに、モバイル・ノードは、登録を認証するために、モバイル・ノード及び通信相手ノードに知られた永続キー生成トークンを使用する。従って、モバイル・ノードは、メッセージのコンテンツを認証するように、バインディング更新に含めるためのメッセージ認証コードを計算する８０１。これにより、永続キー生成トークンを使用してメッセージ認証コード（ＭＡＣ）が生成される。
【０２６５】
一例では、メッセージ認証コードは以下のように決定することができる。
ＭＡＣ＝Ｆｉｒｓｔ（９６，ＨＭＡＣ＿ＳＨＡ１（ｐｅｒｍａｎｅｎｔ  ｋｅｙｇｅｎ  ｔｏｋｅｎ，（ｃａｒｅ−ｏｆ  ａｄｄｒｅｓｓ｜ｃｏｒｒｅｓｐｏｎｄｅｎｔ  ｎｏｄｅ  ａｄｄｒｅｓｓ｜Ｂｉｎｄｉｎ  Ｕｐｄａｔｅ）））
【０２６６】
メッセージ認証コードは、登録されることになる（新しい）モバイル・ノードの気付けアドレス、通信相手ノード・アドレス、及びバインディング更新メッセージの連結によって形成されるメッセージ上で、永続キー生成トークンをキーとして使用し、ＨＭＡＣ＿ＳＨＡ１が適用されたハッシュ関数の結果の第１の９６（又は別の方法では他の数、例えば１２８、６４、４８など）ビットによって形成可能である。
【０２６７】
その後、登録のための気付けアドレス、モバイル・ノードのホーム・アドレス、及びＭＡＣを含む承認されたバインディング更新が、通信相手ノードに送信される８０２。バインディング更新が永続キー生成トークンを使用して承認されていることを通信相手ノードに通知するために、バインディング更新は、設定された場合は、永続キー生成トークンを使用してＭＡＣを評価する８０３こと（すなわち、バインディング更新メッセージを認証すること）を通信相手ノードに指示するフラグ（ｐｋｔ＿ＭＡＣ＿ｆｌａｇ）をさらに含むことができる。さらにバインディング更新は、例えば、バインディング更新をバインディング確認に関連付けるために使用可能なシーケンス番号（ｓｅｑｕｅｎｃｅ  ｎｏ．）を含むこともできる。
【０２６８】
通信相手ノードでバインディング更新を認証する８０３と、同様に、そのバインディング・キャッシュ内に気付けアドレスを登録すること８０４ができる。さらに、通信相手ノードは、モバイル・ノードにバインディング確認を送信すること８０５によって登録を確認することができる。このバインディング確認は、例えば、通信相手ノードによって生成されたメッセージ認証コードを含むことができる。バインディング確認内のＭＡＣは、ハッシュ関数が、バインディング更新メッセージではなくバインディング確認メッセージを介して適用されること、及び（オプションで）通信相手ノードのアドレスではなくモバイル・ノードの気付けアドレス又はホーム・アドレスが使用されることを考慮に入れて、バインディング更新の際のＭＡＣと同様に決定することが可能である。
【０２６９】
さらに、例えばバインディング確認は、どのバインディング更新に確認が送信されるかをモバイル・ノードに示すために、（例えば、バインディング更新のそれに等しい）シーケンス番号を含むことができる。さらに、これもオプションで、バインディング確認は、登録状況の指標、すなわち、バインディング更新が永続キー生成トークンに基づいて首尾よく承認されたか否か、及び／又は気付けアドレスの登録が成功したか否かをさらに含むことができる。
【０２７０】
気付けアドレスの登録が成功した場合、モバイル・ノード及び通信相手ノードは、ルート最適化を使用して通信を続行する８０６。
【０２７１】
図２２に関して上記で説明した手順の潜在的欠点の１つは、ホーム・テストが実行されないため、この手順が、モバイル・ノードに向けて送られたデータを傍受又は不正変更するための攻撃、特に、アドレス・スティーリング／偽装攻撃の影響を受けやすいことである。これは、攻撃者がモバイル・ノードと通信相手ノードとの間の通信を傍受した場合、及びそれによって永続キー生成トークンの知識を取得した場合に、攻撃者は、モバイル・ノードのホーム・アドレスに向けて送られたトラフィックを傍受する必要なしに、モバイル・ノードのバインディングをスプーフィングすることができるため、特に問題のある可能性がある。従って、本発明の他の実施の形態によれば、図２２に従った手順は、スプーフィングされたバインディング更新を検出するための前述のメカニズムのうちの１つ又は複数を使用することで改善することができる。
【０２７２】
図２３は、永続トークンが認証に使用される本発明の第３の態様による例示的実施の形態に従い、通信相手ノードの気付けアドレスを登録するために、モバイル・ノード、ホーム・エージェント、及び通信相手ノードの間で交換されるステップ及びメッセージのシーケンスを示す図である。
【０２７３】
図２１と同様に、モバイル・ノードは第１に気付けアドレスを通信相手ノードで登録する。ホーム・テスト７０２及び気付けテスト７０３を含む完全なリターン・ルータビリティ手順７０１が実行され、その後送信された７０５バインディング更新を認証するためにバインディング・キーが生成される７０４、７０５。通信相手ノードは、気付けアドレスを登録し７０７、ｐｋｔ＿ｆｌａｇが設定されるため、本明細書で前述したように、永続キー生成トークンを生成する７０８。モバイル・ノードは、通信相手ノードから受信した７０９確認に応答して、永続キー生成トークンも生成する７１０。
【０２７４】
続いて、モバイル・ノードが新しい気付けアドレスを通信相手ノードで登録するものである場合、モバイル・ノードと通信相手ノードとの間で交換されるメッセージの認証に永続キー生成トークンを使用することができる。この例では、モバイル・ノード及び通信相手ノードは気付けテスト９０１を実行する。モバイル・ノードは気付けテスト開始メッセージを送信し９０１、これに応答して対応する気付けテスト・メッセージを受信する９０３。これにより、モバイル・ノードに気付けキー生成トークンが与えられる（通信相手ノードにも認識される）。
【０２７５】
この例では、モバイル・ノードは、次に、送信されることになるそのバインディング更新を認証するためにメッセージ認証コードを生成する９０４。この例では、バインディング・キーＫｂｍに基づいてＭＡＣがモバイル端末によって生成され、これが次に、受信したばかりの気付けテスト・メッセージの気付けキー生成トークン及び初期リターン・ルータビリティ手順から取得した永続キー生成トークンに基づいて計算されることが想定可能である。気付けアドレス登録手順と組み合わせて気付けテストを実行すること、及び認証のために永続キー生成トークン及び気付けキー生成トークンを使用することは、気付けテストによってフラッディング攻撃が防止できるために有利な可能性がある。例えば、ＭＡＣは以下のように計算可能である。
ＭＡＣ＝Ｆｉｒｓｔ（９６，ＨＭＡＣ＿ＳＨＡ１（Ｋｂｍ，（ｃａｒｅ−ｏｆ  ａｄｄｒｅｓｓ｜ｃｏｒｒｅｓｐｏｎｄｅｎｔ  ｎｏｄｅ  ａｄｄｒｅｓｓ｜Ｂｉｎｄｉｎ  Ｕｐｄａｔｅ）））
【０２７６】
このメカニズムは、永続キー生成トークンの代わりにバインディング・キーＫｂｍを使用することを除いて、上記で概説したものと同様である。ここでも、ハッシュ関数の第１の９６ビットを取ることは単なる例示のためである。
【０２７７】
この例でバインディング・キーＫｂｍは、気付けキー生成トークン及び永続キー生成トークンを使用して生成される。これは例えば以下のように実現可能である。
Ｋｂｍ＝ＳＨＡ１（ｐｅｒｍａｎｅｎｔ  ｋｅｙｇｅｎ  ｔｏｋｅｎ｜ｃａｒｅ−ｏｆ  ｋｅｙｇｅｎ  ｔｏｋｅｎ）
【０２７８】
従って、バインディング・キーは、永続キー生成トークン及び気付けキー生成トークンの連結に暗号ハッシュ関数を適用した結果とすることができる。
【０２７９】
結果として生じるメッセージ認証コード（ＭＡＣ）は、図２２に関して上記で説明したように、バインディング更新に含めることが可能であり、承認されたバインディング更新は通信相手ノードに送信される９０５。一般に、ＭＡＣは、バインディング更新から通信相手に別々に、例えば、別々のメッセージで信号送信することも可能であることに留意されたい。例えば、このメッセージに共通の識別子及びバインディング更新（例えば、シーケンス番号）を使用して、バインディング更新と、バインディング更新のためのＭＡＣを含むメッセージとを関連付けることができる。さらにＭＡＣは、別々のメッセージで送信された場合、バインディング更新のみならず、別のメッセージにも基づいて（例えば、ハッシュ関数への入力としてメッセージの連結を使用することによって）計算することができる。
【０２８０】
永続キー生成トークンがＭＡＣの計算に使用されたことを通信相手ノードに示すために、バインディング更新は、ＭＡＣの計算のための永続キー生成トークンの使用を通信相手ノードに示すそれぞれのフラグｐｋｔ＿ＭＡＣ＿ｆｌａｇを含めることができる。ＭＡＣがバインディング更新とは別に信号送信される場合、フラグは、通信相手ノードが、バインディング更新を認証するためのＭＡＣを含む別のメッセージを受信することになることを示す。
【０２８１】
モバイル・ノードと同様に、フラグが設定された場合、通信相手ノードは永続キー生成トークンを使用してバインディング・キーＫｂｍ（まだ存在しない場合）を計算し、バインディング更新メッセージ内のＭＡＣを検証する９０６。バインディング更新が有効の場合、通信相手ノードはそのキャッシュ内のバインディング更新の気付けアドレスを登録する９０７。さらに、通信相手ノードは、前述のように、バインディング確認をモバイル・ノードの新しい気付けアドレスに送信することができる９０８。本発明の第３の態様によるこの実施の形態では、通信相手ノードは（さらに）、バインディング確認メッセージをモバイル・ノードのホーム・アドレス及び／又はモバイル・ノードの古い気付けアドレスに送信する９０９、９１０。その後、モバイル・ノード及び通信相手ノードは、新しい登録された気付けアドレスを使用してデータを交換することができる９０１１。
【０２８２】
図２４に関して以下で概説するように、通信相手ノードによって送信された２つの後者のバインディング確認メッセージ（すなわち、モバイル・ノードのホーム・アドレスに向けて送られた確認９０９、９１０又は以前に登録された気付けアドレスに送られた確認）のうちのいずれかによって、モバイル・ノードは攻撃を検出することができる。
【０２８３】
図２４は、永続トークンが認証に使用され、モバイル・ノードが、攻撃者が通信相手ノードに対するそのバインディング・キャッシュ・エントリをスプーフィングしたことを検出する本発明の第３の態様による例示的実施の形態に従い、モバイル・ノード、攻撃者、ホーム・エージェント、及び通信相手ノードの間で交換されるステップ及びメッセージの他のシーケンスを示す。これにより、気付けアドレスの登録にはホーム・テストが実行される必要がない（オプションで、上記で概説したように気付けテストも省略可能である）。
【０２８４】
第１に、攻撃者は永続キー生成トークンについての知識を得ているか、又は図２１に示されたものと類似の方法を使用してモバイル・ノードに対するスプーフィングされた気付けアドレス登録を首尾よく実行しているため、有効なホーム・キー生成トークンを所有していることが想定される。オプションで通信相手ノードによって気付けテストが実行されると１００１、攻撃者は、（傍受された）永続キー生成トークン及び（オプションで）気付けテストからの気付けキー生成トークンに基づいて、メッセージ認証コードを生成する１００２。攻撃者は、生成されたＭＡＣを使用して、通信相手ノードに送信された１００３バインディング更新を認証し、バインディング更新が、攻撃者（モバイル・ノード）及び通信相手ノードに知られた永続キー生成トークンに基づいて生成されたＭＡＣを含むことを通信相手ノードに示すために、バインディング更新内にフラグｐｋｔ＿ＭＡＣ＿ｆｌａｇを設定する。
【０２８５】
通信相手ノードは、ＭＡＣを評価し１００４、その評価が正常であった場合、バインディング・キャッシュ内で攻撃者によって示された気付けアドレスを登録する１００５。さらに、通信相手ノードは、バインディングを確認するために、（オプションで）バインディング確認を新しい気付けアドレスに送信する１００６。攻撃を検出できるようにするために、通信相手ノードは、バインディングが更新されたモバイル・ノードのホーム・アドレスにバインディング更新を送信する１００７、１００８。別の方法としては、又はモバイル・ノードのホーム・アドレスに向けて送られたバインディング確認に加えて、通信相手ノードは、バインディング・キャッシュに関して以前に登録された気付けアドレスに、バインディング確認を送信する１００９。この以前に登録された気付けアドレスは、（バインディングが以前にスプーフィングされていない場合）最新のモバイル・ノードの気付けアドレスに対応する。
【０２８６】
偽装攻撃の場合、攻撃者は、到達可能な気付けアドレスを登録するために、モバイル・ノードのホーム・アドレスを備えたバインディング更新メッセージを送信しており、モバイル・ノードは、対応するバインディング更新メッセージを送信することなく、少なくとも１つのバインディング確認メッセージを受信する。上記で概説したように、モバイル・ノードは、例えば、メッセージ内のシーケンス番号によって、バインディング確認メッセージをバインディング更新メッセージにマッピングすることができる１０１０。より詳細には、例えばモバイル・ノードは、バインディング確認が、この通信相手ノードに送信された最後のバインディング更新の再送ウィンドウ内にない（すなわち、シーケンス番号よりも上、又はあるしきい値だけ下の）シーケンス番号と共に受信された場合、攻撃を検出することができる。モバイル・ノードは攻撃を検出した場合、例えば、即時に攻撃の影響を無効にすることができる。図２４では、モバイル・ノードは、ホーム・テスト７０２及び気付けテスト７０３を含むリターン・ルータビリティ手順７０１を開始し、これがバインディングを修復し（７０４、７０５、７０６、７０７、７０９）、オプションで新しい永続キー生成トークンの生成（７０８、７１０）を開始することができる。図２１と同様のこれらのステップの後、通信相手ノードは、モバイル・ノードの正しい気付けアドレスに向けてデータを送信する７１１。
【０２８７】
以下では、最適化のセキュリティ・プロパティがリターン・ルータビリティ手順及び気付けアドレス登録手順に対して提案した簡単な分析について考察する。以下で示されるように、同じことが、ＩＥＴＦ  ＲＦＣ３７５５に提供されたようなＭＩＰｖ６から認識される標準のリターン・ルータビリティ手順／ルート最適化モードのセキュリティ・プロパティに匹敵する。
【０２８８】
初期のホーム・アドレス・テストが実行された場合、本発明の幾つかの実施の形態に従って提案されるような永続キー生成トークンを使用するリターン・ルータビリティ手順では、パス外攻撃は不可能である。時間移動攻撃、すなわち、攻撃者がある時間パス上にあり、その後パス外に移動して攻撃を続行することのみが可能である。
【０２８９】
楽観的リターン・ルータビリティの場合、初期ホーム・テスト／ホーム・テスト開始交換のみが実行可能であるため、時間移動攻撃は、楽観的リターン・ルータビリティ・ラウンドではより厳しいものである。従って、モバイル・ノードが初期の完全なリターン・ルータビリティを実行する時点で、ホーム・エージェントから通信相手ノードへのパス上に位置する攻撃者は、ホーム・テストを傍受可能であり、永続ホーム・キー生成トークンを取得可能である（永続トークンがどのように計算されるかに応じて、攻撃者は、気付けテストを傍受し、気付けキー生成トークンを取得するために、モバイル・ノードから通信相手ノードへのパス上に同時に位置しなければならない可能性がある）。攻撃者が、気付けアドレス・テストのために、請求された気付けアドレスに依然として到達可能でなければならないことを考えると、永続トークンを取得した後、攻撃者はパス外に移動し、（図２４に関して上記で説明したように）楽観的リターン・ルータビリティを使用して、トラフィックを宛先変更することができる。しかし、モバイル・ノードは、本明細書で考察した検出メカニズムのうちの少なくとも１つを使用する場合、例えば、モバイル・ノードによって送信されていないバインディング更新に関して受信したバインディング確認によって、この攻撃を検出することができる。これにより、モバイル・ノードは、ホーム・テスト及び後続の気付け登録を含むリターン・ルータビリティ手順を実行することによって、バインディングの修復などの対応策を講じることができる。従って、攻撃者は、永続キー生成トークンが変更されており、パス上に戻らなければ再度これを取得できないため、その攻撃をパス外で続行することができない。
【０２９０】
攻撃者が、ホーム・テスト及び気付けテストを含むリターン・ルータビリティ手順、並びに後続の気付けアドレス登録を開始し、ホーム・エージェントと通信相手ノードの間のパス上にある間に、永続キー生成トークンを生成することも、発生する可能性がある。この場合、モバイル・ノードはリターン・ルータビリティに関与せず、これに気付くこともない。また、古い気付けアドレスが攻撃者に割り当てられているため、後続の楽観的リターン・ルータビリティ・ラウンドにおける古い気付けアドレスに対するバインディング確認はモバイル・ノードに到達しないことになる。しかし、モバイル・ノードのホーム・アドレスに向けて送られるバインディング確認は、依然としてモバイル・ノードに到達可能であり、モバイル・ノードは攻撃を検出することができる。
【０２９１】
リターン・ルータビリティ手順を使用せず、新しい気付けアドレス登録に先立って気付けテストのみを使用することによって生成される可能性のある新しい脅威は、攻撃者がリターン・ルータビリティ・メッセージをブロックするため、結果として攻撃が成功した後にモバイル・ノードがバインディングを修復できないというものである可能性がある。この脅威を軽減するために、本発明の第３の態様による他の実施の形態では、ホーム・テスト・メッセージ（ＨｏＴｉ／ＨｏＴ）及びモバイル・ノードとホーム・エージェントとの間のすべての信号メッセージを（例えばＩＰｓｅｃを使用して）暗号化し、その結果、攻撃者がそれらのメッセージをすべてブロックできるか又はまったくブロックできないようにすることを提案している。バインディング確認メッセージ及びＩＰｓｅｃメッセージをホーム・エージェントからブロックすることは、モバイル・ノードによって（例えばＩＰｓｅｃデッド・ピア検出を使用して）検出可能であるため、バインディング修復プロセス中のモバイル・ノードは、これをリターン・ルータビリティ・メッセージをブロックするための指標として解釈することができる。
【０２９２】
この場合、モバイル・ノードは、例えば、後続の気付けアドレス登録の認証のために暗号情報を生成するための、ホーム・テスト及び気付けテストを伴うリターン・ルータビリティ手順を使用するように、通信相手ノードに要求するメッセージを通信相手ノードに送信することができる。通信相手ノードに送信されるこの通知は、例えば、ホーム・テスト及び気付けテストを含むモバイル・ノード及び通信相手ノードによって実行された以前のリターン・ルータビリティ手順から取得された暗号情報（例えば、以前に生成されたバインディング・キー）で、署名することができる。
【０２９３】
遭遇する可能性がある他の潜在的な問題は、攻撃を連続的に実行する攻撃者である。この場合、たとえモバイル・ノードが、通信相手ノードでのバインディングを連続的に検出及び修復しても、大量のトラフィックが宛先変更される可能性がある。本発明の第３の態様による実施の形態により、連続攻撃を軽減するためのオプションの１つは、モバイル・ノードが連続攻撃に関して通信相手ノードに通知することである。こうした通知には、例えば、前述のように、ホーム・テスト及び気付けテストを含むモバイル・ノード及び通信相手ノードによって実行された以前のリターン・ルータビリティ手順から取得された暗号情報で署名することができる。通信相手ノードは、例えば、リターン・ルータビリティがそれに関するホーム・テスト及び気付けテストを含まなければならない、気付けアドレス又は気付けアドレス・プレフィックスのブラック・リストを維持することができる。
【０２９４】
楽観的リターン・ルータビリティ・ラウンドは、例えば、永続キー生成トークン、ブラック・リストの維持など、通信相手ノードでの何らかの追加の状態情報を必要とする可能性がある。しかし、この状態は、通信相手ノードによって受信された承認されたバインディング更新の後に、最初に確立される。攻撃者は、通信相手ノードのメモリを使い尽くすために、ランダムなホーム・アドレス及び気付けアドレスと共に、多くの偽のバインディング更新を送信することによって、サービス妨害攻撃を実行する可能性がある。この攻撃を軽減するために、通信相手ノードは、例えばバインディング更新の処理に使用するリソースの量を制限することができる。
【０２９５】
犠牲者は（たとえ追加のバインディング確認を考慮している場合であっても）攻撃者が送信した以上のメッセージを決して受信しないため、増幅を伴う反射攻撃も不可能である
【０２９６】
すでに上記で考察したリターン・ルータビリティ手順の他の潜在的な欠点は、それらの手順がホーム・エージェントの関与を必要とする場合があることである。例えば、ＭＩＰｖ６の場合、これは、モバイル・ノードのホーム・エージェントがダウンした場合（たとえホーム・エージェントがルート最適化トラフィックのデータ・パス上にいない場合であっても）、ルート最適化通信が不可能であることを意味する。
【０２９７】
ホーム・テストを省略する提案されたリターン・ルータビリティ手順は、原理上、ホーム・エージェントへの依存を排除することができる。しかし、ホーム・テストを省略するリターン・ルータビリティ手順及び後続の気付け登録をセキュアにするために、幾つかの実施の形態では、モバイル・ノードのバインディングへの攻撃を検出するためのバインディング確認をモバイル・ノードのホーム・アドレスに送信するなどのメカニズムを使用することが提案される。しかし、モバイル・ノードのホーム・アドレスへのバインディング確認メッセージは、ホーム・エージェントがダウンした場合、もはやモバイル・ノードに到達できないため、モバイル・ノードはそのホーム・エージェントのダウン・タイム中、アドレス・スティーリング／偽装攻撃を検出することができない。これは、攻撃者が例えばサービス妨害攻撃を実行し、ホーム・エージェントをダウンさせることができるか、又は攻撃者がホーム・エージェントを監視し、ホーム・エージェントがいかなる理由であっても到達可能になるまで攻撃を待機することができるため、重大な脅威である可能性がある。
【０２９８】
本発明の第３の態様による例示的実施の形態によるこの脅威に対する対応策の１つは、通信相手ノードがモバイル・ノードの古い気付けアドレス（すなわち、モバイル・ノードのホーム・アドレスに対して以前に登録された気付けアドレス）にバインディング確認を送信することである。通信相手ノードは、バインディング確認をモバイル・ノードの古い気付けアドレスに向けて常に送るか、又はモバイル・ノードのホーム・エージェントがダウンした状況でのみ送るかのいずれかが可能である。
【０２９９】
他の問題点は、ホーム・エージェントがダウンしたことを、通信相手ノード及びモバイル・ノードがどのように認識するかである。オプションの１つは、モバイル・ノードがバインディング更新メッセージを送信した後に、ホーム・エージェントからのバインディング確認メッセージの欠落に基づいて、ホーム・エージェントが到達可能でないことをモバイル・ノードが検出することである。他のオプションは、モバイル・ノードとホーム・エージェントとの間にＩＰｓｅｃセキュリティアソシエーションが存在する場合、ＩＰｓｅｃデッド・ピア検出（ＤＰＤ）を使用してホーム・エージェントの停止を検出することである。
【０３００】
他のオプションは、この目的で新しい定期的なメッセージ交換（例えば、ＩＣＭＰエコー要求／回答メッセージ）を導入することである。ホーム・エージェントがダウンしたことをモバイル・ノードが検出した後、モバイル・ノードは、通知メッセージを使用して、ホーム・エージェントがダウンしていることを通信相手ノードに通知することができる。このメッセージには、例えば、ホーム・テスト及び気付けテストを含むモバイル・ノード及び通信相手ノードによって実行される以前のリターン・ルータビリティ手順から取得された暗号情報（例えば、以前に生成されたバインディング・キー）で、署名することができる。一例では、こうした通知は、例えば、設定された場合、ホーム・エージェントがダウンしたことを示す新しいフラグ（「ｈｏｍｅ  ａｇｅｎｔ  ｄｏｗｎ」フラグ）をバインディング更新に導入することによって、バインディング更新メッセージに含めることができる。
【０３０１】
攻撃者がこうしたスプーフィングされた通知を通信相手ノードに送信するのを防ぐために、例えば通信相手ノードは、通知の署名が有効であること、及び通知がモバイル・ノードの現在登録されている気付けアドレスから送信されたことを検証することができる。さらに、通信相手ノードは、オプションで、例えば要求メッセージ（例えば、ＩＣＭＰエコー要求）をモバイル・ノードのホーム・アドレスに送信することによって、ホーム・エージェントが実際にダウンしたことを検証することができる。複数回の試行の後、何の回答も受信されない場合、通信相手ノードは、ホーム・エージェントが実際にダウンしているものと結論付けることができる。
【０３０２】
モバイル・ノードのホーム・エージェントがダウンしていることが通信相手ノードに通知された場合（及び、オプションで、この通知が確認された場合）、例えば通信相手ノードは、この情報を格納すること、並びに、ホーム・テストがスキップ可能であり、新しく登録された気付けアドレス及び以前に登録された気付けアドレスにバインディング更新の確認が送信される、「ホーム・エージェント・ダウン・モード」に切り替えることが可能である。さらにバインディング更新メッセージは、永続キー生成トークン、及びオプションで、気付けアドレス・テストから取得された暗号情報を使用して、承認することが可能であり、すなわち、ホーム・アドレス・テストは実行されない。永続キー生成トークンは、例えば前述のように計算可能であるか、あるいはホーム・エージェントがダウンする前の最後の正常なホーム・アドレス・テストのホーム・キー生成トークンに基づいて生成可能、又はそれと同等であるものとすることができる。
【０３０３】
従って、ルート最適化を使用したモバイル・ノードと通信相手ノードとの間の通信は、たとえホーム・エージェントがダウンしようとする場合であっても続行可能である。
【０３０４】
本発明の第３の態様による他の実施の形態では、通信相手ノード及び／又はモバイル・ノードは、ホーム・エージェントが依然としてダウンしているか否かを、例えば、ホーム・エージェント・ダウン・プローブ・メッセージをモバイル・ノードのホーム・アドレスに送信することによって、定期的にチェックすることができる（ホーム・エージェント・アドレスは通信相手ノードによって認識できないことに留意されたい）。ホーム・エージェントが再度アップした場合、通信相手ノードは、承認されたバインディング更新に応答し、ホーム・エージェントを介してバインディング確認を再度送信することができる。
【０３０５】
モバイル・ノードのホーム・エージェントがダウンしていないのにもかかわらず、ダウンしているとして通信相手ノードを欺くために、攻撃者がホーム・エージェント・ダウン・プローブ・メッセージをブロックできるという問題を軽減するために、ホーム・エージェントは、例えば、通信相手ノードによって送信されたプローブ・メッセージをインターセプトすること、及び（それらをモバイル・ノードに転送する代わりに）それらに即時に回答することができる。これにより、モバイル・ノードからホーム・エージェントへのパス上にいる攻撃者が、それらのメッセージをブロックするのを防ぐことができる。
【０３０６】
本明細書に記載された本発明の第３の態様による様々な実施の形態で提案されたような、通信相手ノードでのモバイル・ノードのバインディングに対する攻撃を検出するためのメカニズム、並びに、リターン・ルータビリティ手順及び気付けアドレス登録手順に対する改良点は、ＭＩＰｖ６において有利に使用することができる。しかし、本明細書で概説された原理及び観念は、ネットワーク・エンティティのアドレス間のバインディングを登録し、例えば、ｍｏｂｉｋｅ、ＨＩＰ、及びそれらの派生などのメッセージの登録時に確認メッセージを送信する任意のプロトコルにも適用可能である。
【０３０７】
本発明の第３の態様による他の実施の形態では、対応する気付けテスト開始を送信することなく（例えばこれは、気付け開始クッキーに基づいて検出可能である）、他のノードから気付けテスト・メッセージを受信するモバイル・ノードは、この環境を、ノードでのそのバインディングへの攻撃の指標として使用すること、及び本明細書で概説されたような適切な対応策を講じることも可能である。同様に、対応するホーム・テストを送信することなくホーム・テスト・メッセージを受信するモバイル・ノードは、このイベントを、バインディング更新をスプーフィングする試行に関する指標とみなすことができる。
【０３０８】
本発明の様々な態様の他の実施の形態は、ハードウェア及びソフトウェアを使用する前述の様々な実施の形態の実施に関する。様々な態様による本発明の様々な実施の形態は、コンピューティング・デバイス（プロセッサ）を使用して実装又は実行可能であることが理解される。コンピューティング・デバイス又はプロセッサは、例えば汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又は他のプログラミング論理デバイスなどとすることができる。本発明の様々な実施の形態は、これらのデバイスの組合せによっても実行又は具体化することができる。
【０３０９】
さらに、様々な態様による本発明の実施の形態は、プロセッサによって、又はハードウェアで直接実行されるソフトウェア・モジュールを使用しても実装可能である。ソフトウェア・モジュール及びハードウェア実装の組合せも可能である。ソフトウェア・モジュールは、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、レジスタ、ハード・ディスク、ＣＤ−ＲＯＭ、ＤＶＤなどの任意の種類のコンピュータ読み取り可能記憶媒体上に格納することができる。
【０３１０】
前述の段落では、本発明の様々な実施の形態及びそれらの変形について説明してきた。当業者であれば、広義に説明された本発明の趣旨又は範囲を逸脱することなしに、特定の実施の形態に示されるような本発明に対する多数の変形及び／又は変更が実行可能であることを理解されよう。
【図１】
2010507301.tif 000003
【図２】
2010507301.tif 000004
【図３】
2010507301.tif 000005
【図４】
2010507301.tif 000006
【図５】
2010507301.tif 000007
【図６】
2010507301.tif 000008
【図７】
2010507301.tif 000009
【図８】
2010507301.tif 000010
【図９】
2010507301.tif 000011
【図１０】
2010507301.tif 000012
【図１１】
2010507301.tif 000013
【図１２】
2010507301.tif 000014
【図１３】
2010507301.tif 000015
【図１４】
2010507301.tif 000016
【図１５】
2010507301.tif 000017
【図１６】
2010507301.tif 000018
【図１７】
2010507301.tif 000019
【図１８】
2010507301.tif 000020
【図１９】
2010507301.tif 000021
【図２０】
2010507301.tif 000022
【図２１】
2010507301.tif 000023
【図２２】
2010507301.tif 000024
【図２３】
2010507301.tif 000025
【図２４】
2010507301.tif 000026
【手続補正書】
【提出日】平成21年6月24日(2009.6.24)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
モバイル・アンカー・ポイントでモバイル・ノードのモビリティを管理するための方法であって、前記モバイル・ノードは第１のネットワークと第２のネットワークとの間を移動し、前記第１のネットワークは、前記モバイル・ノードのモビリティを管理するためにモバイル・ノード・ベースのモビリティ管理スキームを使用し、前記第２のネットワークは、前記モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・アンカー・ポイントは、前記モバイル・ノード・ベースのモビリティ管理スキーム及び前記ネットワーク・ベースのモビリティ管理スキームの両方を実施し、前記方法は、前記モバイル・アンカー・ポイントによって実行される下記のステップ：
前記第１のネットワーク内の前記モバイル・ノードの第１の位置に関する第１のメッセージを前記モバイル・ノードから受信するステップであって、前記モバイル・ノードは第１のＩＰアドレスを有するステップと、
前記第２のネットワーク内の前記モバイル・ノードの第２の位置に関する第２のメッセージを前記第２のネットワーク内のネットワーク要素から受信するステップであって、前記モバイル・ノードは第２のＩＰアドレスを有するステップと、
前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するステップと、
前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する応答メッセージを受信するステップと、
前記受信した応答メッセージに基づいて、前記第１及び第２のＩＰアドレスのうちのどちらが前記モバイル・ノードの現行ＩＰアドレスであるかを決定するステップとを、
有する方法。
【請求項２】
モバイル・アンカー・ポイントでモバイル・ノードのモビリティを管理するための方法であって、前記モバイル・ノードは、第１のネットワークと第２のネットワークとの間を移動し、前記第１及び第２のネットワークは、前記モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・アンカー・ポイントは、前記ネットワーク・ベースのモビリティ管理スキームを実施し、前記方法は、前記モバイル・アンカー・ポイントによって実行される下記のステップ：
前記第１のネットワーク内の前記モバイル・ノードの第１の位置に関する第１のメッセージを前記第１のネットワーク内の第１のネットワーク要素から受信するステップであって、前記モバイル・ノードが第１のＩＰアドレスを有するステップと、
前記第２のネットワーク内の前記モバイル・ノードの第２の位置に関する第２のメッセージを前記第２のネットワーク内の第２のネットワーク要素から受信するステップであって、前記モバイル・ノードが第２のＩＰアドレスを有するステップと、
前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するステップと、
前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する応答メッセージを受信するステップと、
前記受信した応答メッセージに基づいて、前記第１及び第２のＩＰアドレスのうちのどちらが前記モバイル・ノードの現行ＩＰアドレスであるかを決定するステップとを、
有する方法。
【請求項３】
前記受信した応答メッセージが、前記第１及び第２のＩＰアドレスのうちの少なくとも１つに対する肯定応答メッセージである場合、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つが、前記モバイル・ノードの前記現行ＩＰアドレスとして決定される請求項１に記載の方法。
【請求項４】
前記肯定応答メッセージが、非ゼロの存続期間を有するバインディング更新メッセージである請求項３に記載の方法。
【請求項５】
前記受信した応答メッセージが、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する否定応答メッセージである場合、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つの他方が、前記モバイル・ノードの前記現行ＩＰアドレスとして決定される請求項１に記載の方法。
【請求項６】
前記第１及び第２のメッセージの受信間の時間間隔を測定するステップを更に有し、前記測定された時間間隔が所定の期間よりも短い場合、前記バインディング要求メッセージが、前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの少なくとも１つに送信される請求項１に記載の方法。
【請求項７】
前記所定の期間が、前記第１と第２のネットワーク間での前記モバイル・ノードのハンドオーバで必要な最低期間よりも長いか又は等しい請求項６に記載の方法。
【請求項８】
前記第１のＩＰアドレスが、前記第１のネットワーク内の前記モバイル・ノードに対して構成された第１の気付けアドレスであり、前記第２のＩＰアドレスが、前記第２のネットワーク内の前記モバイル・ノードに対して構成された第２の気付けアドレスである請求項１に記載の方法。
【請求項９】
前記モバイル・アンカー・ポイントへの前記第１のメッセージの第１の到達時間と、前記モバイル・アンカー・ポイントへの前記第２のメッセージの第２の到達時間との時間差を計算するステップを更に有する請求項１に記載の方法。
【請求項１０】
前記モバイル・アンカー・ポイントが前記モバイル・ノードに対するホーム・エージェントであり、
前記第１及び第２のメッセージのうちで最も早く受信されたメッセージのＩＰアドレスを、優先的に前記ホーム・エージェントのバインディング・キャッシュ・エントリ内に格納するステップと、
前記第１及び第２のメッセージのうちで最も遅く受信されたメッセージのＩＰアドレスを前記バインディング更新メッセージの受信まで格納するステップとを、
更に有する請求項１に記載の方法。
【請求項１１】
前記バインディング要求メッセージが、前記第１及び第２のメッセージのうちで最も早く受信されたメッセージの前記格納されたＩＰアドレス、及び前記第１及び第２のメッセージのうちで最も遅く受信されたメッセージの前記格納されたＩＰアドレスに送信される、請求項１０に記載の方法。
【請求項１２】
前記バインディング更新メッセージを受信した場合に、前記第１及び第２のメッセージのうちで最も遅く受信されたメッセージに関する前記格納されたＩＰアドレスを削除するステップと、
前記受信されたバインディング更新メッセージに含まれる前記第１及び第２のＩＰアドレスのうちの前記１つによって、前記第１及び第２のメッセージのうちで最も早く受信されたメッセージに関する前記格納されたＩＰアドレスを更新するステップとを、
更に有する請求項１０に記載の方法。
【請求項１３】
前記受信されたバインディング更新メッセージに含まれる前記第１及び第２のＩＰアドレスのうちの前記１つが、前記第１及び第２のメッセージのうちで最も早く受信されたメッセージに関する前記格納されたＩＰアドレスに対応する場合、前記バインディング・キャッシュ・エントリのタイマ存続期間を更新するステップを更に有する請求項１２に記載の方法。
【請求項１４】
前記バインディング要求メッセージが、バインディング確認メッセージ、気付けアドレス・テスト開始メッセージ、又はインターネット制御メッセージ・プロトコル・メッセージのうちの少なくとも１つである請求項１に記載の方法。
【請求項１５】
前記バインディング要求メッセージが、バインディング確認メッセージであり、
前記バインディング確認メッセージを送信する前に、前記バインディング確認メッセージのリフレッシュ・アドバイス・オプションをゼロに設定するステップを更に有する請求項１に記載の方法。
【請求項１６】
リフレッシュ・アドバイス・オプションがゼロに設定されたバインディング要求メッセージを受信した場合に、前記モバイル・ノード又は前記ネットワーク要素によって、バインディング更新を前記モバイル・アンカー・ポイントに送信するステップを更に有する請求項１５に記載の方法。
【請求項１７】
前記ネットワーク要素によって、前記モバイル・アンカー・ポイントから前記バインディング要求メッセージを受信するステップと、
前記ネットワーク要素によって、前記ネットワーク要素への前記モバイル・ノードの接続をチェックするステップと、
前記モバイル・ノードが前記ネットワーク要素に接続されている場合、前記ネットワーク要素によって、バインディング更新を前記モバイル・アンカー・ポイントに送信するか、又は前記モバイル・ノードが前記ネットワーク要素に接続されていない場合、前記ネットワーク要素によって、前記バインディング要求メッセージを破棄するステップとを、
更に有する請求項１に記載の方法。
【請求項１８】
前記ネットワーク要素によって、前記モバイル・アンカー・ポイントから前記バインディング要求メッセージを受信するステップと、
前記ネットワーク要素によって、前記モバイル・ノードの前記ネットワーク要素への接続をチェックするステップと、
前記モバイル・ノードが前記ネットワーク要素に接続されている場合、ゼロよりも長い存続期間を有するバインディング更新を、又は前記モバイル・ノードが前記ネットワーク要素に接続されていない場合、ゼロに等しい存続期間を有するバインディング更新を、前記ネットワーク要素によって送信するステップとを、
更に有する請求項１に記載の方法。
【請求項１９】
前記チェックするステップが、前記ネットワーク要素によって、レイヤ２ポーリング・メッセージ又は近隣要請メッセージのうちの少なくとも１つを前記モバイル・ノードに送信するステップを有する請求項１７に記載の方法。
【請求項２０】
前記モバイル・アンカー・ポイントによって、前記モバイル・ノードから、又は前記ネットワーク要素から、前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの１つに関するバインディング登録解除メッセージを受信するステップと、
前記バインディング登録解除メッセージを受信した場合に、前記モバイル・アンカー・ポイントによって、前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの他の１つが前記モバイル・ノードの前記現行ＩＰアドレスである旨を決定するステップとを、
更に有する請求項１に記載の方法。
【請求項２１】
前記バインディング登録解除メッセージを受信した場合に、前記バインディング要求メッセージの送信を停止するステップを更に有する請求項２０に記載の方法。
【請求項２２】
前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの１つに対する前記バインディング登録解除メッセージが、前記バインディング要求メッセージの送信後、及び応答メッセージの受信前に受信された場合、前記方法が、前記応答メッセージの受信を待つことなく、前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの他の１つが前記モバイル・ノードの前記現行ＩＰアドレスである旨を決定するステップを更に有する請求項２０に記載の方法。
【請求項２３】
モバイル・ノードのモビリティを管理するためのモバイル・アンカー・ポイントであって、
前記モバイル・ノードは第１のネットワークと第２のネットワークとの間を移動し、前記第１のネットワークは、前記モバイル・ノードのモビリティを管理するためにモバイル・ノード・ベースのモビリティ管理スキームを使用し、前記第２のネットワークは、前記モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・アンカー・ポイントは、前記モバイル・ノード・ベースのモビリティ管理スキーム及び前記ネットワーク・ベースのモビリティ管理スキームの両方を実施し、
前記第１のネットワーク内の前記モバイル・ノードの第１の位置に関する第１のメッセージを前記モバイル・ノードから受信するための受信手段であって、前記モバイル・ノードは第１のＩＰアドレスを有し、前記第２のネットワーク内の前記モバイル・ノードの第２の位置に関する第２のメッセージを前記第２のネットワーク内のネットワーク要素から受信するための受信手段であって、前記モバイル・ノードは第２のＩＰアドレスを有する受信手段と、
前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するための送信手段とを有し、
前記受信手段は、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する応答メッセージを受信するように構成されており、
前記モバイル・アンカー・ポイントは、前記受信した応答メッセージに基づいて、前記第１及び第２のＩＰアドレスのうちのどちらが前記モバイル・ノードの現行ＩＰアドレスであるかを決定するための決定手段を更に有するモバイル・アンカー・ポイント。
【請求項２４】
モバイル・ノードのモビリティを管理するためのモバイル・アンカー・ポイントであって、前記モバイル・ノードは第１のネットワークと第２のネットワークとの間を移動し、前記第１及び第２のネットワークは、前記モバイル・ノードのモビリティを管理するためのネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・アンカー・ポイントは、前記ネットワーク・ベースのモビリティ管理スキームを実施し、
前記第１のネットワーク内の前記モバイル・ノードの第１の位置に関する第１のメッセージを前記第１のネットワーク内の第１のネットワーク要素から受信するための受信手段であって、前記モバイル・ノードは第１のＩＰアドレスを有し、前記第２のネットワーク内の前記モバイル・ノードの第２の位置に関する第２のメッセージを前記第２のネットワーク内の第２のネットワーク要素から受信するための受信手段であって、前記モバイル・ノードは第２のＩＰアドレスを有する受信手段と、
前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの少なくとも１つへバインディング要求メッセージを送信するための送信手段とを有し、
前記受信手段は、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する応答メッセージを受信するように構成されており、
前記モバイル・アンカー・ポイントは、前記受信した応答メッセージに基づいて、前記第１及び第２のＩＰアドレスのうちのどちらが前記モバイル・ノードの現行ＩＰアドレスであるかを決定するための決定手段を更に有するモバイル・アンカー・ポイント。
【請求項２５】
前記決定手段が、前記受信した応答メッセージが前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する肯定応答メッセージである場合、前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つを前記モバイル・ノードの前記現行ＩＰアドレスとして決定するように構成された請求項２３に記載のモバイル・アンカー・ポイント。
【請求項２６】
前記肯定応答メッセージが、非ゼロの存続期間を有するバインディング更新メッセージである請求項２５に記載のモバイル・アンカー・ポイント。
【請求項２７】
前記決定手段が、前記受信した応答メッセージが前記第１及び第２のＩＰアドレスのうちの前記少なくとも１つに対する否定応答メッセージである場合、前記第１及び第２のＩＰアドレスのうちの前記少なくとも他の１つを前記モバイル・ノードの前記現行ＩＰアドレスとして決定するように構成された請求項２３に記載のモバイル・アンカー・ポイント。
【請求項２８】
前記第１及び第２のメッセージの受信間の時間間隔を測定するための測定手段を更に有し、
前記送信手段が、前記測定された時間間隔が所定の期間よりも短い場合、前記バインディング要求メッセージを、前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの少なくとも１つに送信するように構成された請求項２３に記載のモバイル・アンカー・ポイント。
【請求項２９】
前記受信手段が、前記モバイル・ノード、又は前記ネットワーク要素から、前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの１つに関するバインディング登録解除メッセージを受信するように構成され、
前記決定手段が、前記バインディング登録解除メッセージを受信した場合に、前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの１つの他方が、前記モバイル・ノードの前記現行ＩＰアドレスである旨を決定するように構成された請求項２３に記載のモバイル・アンカー・ポイント。
【請求項３０】
前記モバイル・アンカー・ポイントが、前記バインディング登録解除メッセージを受信した場合に、前記バインディング要求メッセージの送信を停止するように構成された請求項２９に記載のモバイル・アンカー・ポイント。
【請求項３１】
前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの１つに対する前記バインディング登録解除メッセージが、前記バインディング要求メッセージの送信後、及び応答メッセージの受信前に受信された場合、前記決定手段が、前記応答メッセージの受信を待つことなく、前記モバイル・ノードの前記第１及び第２のＩＰアドレスのうちの前記他の１つが前記モバイル・ノードの前記現行ＩＰアドレスである旨を決定するように構成された請求項２９に記載のモバイル・アンカー・ポイント。
【請求項３２】
第１のネットワークと第２のネットワークとの間を移動するモバイル・ノードであって、
前記第１のネットワークは、前記モバイル・ノードのモビリティを管理するためにモバイル・ノード・ベースのモビリティ管理スキームを使用し、前記第２のネットワークは、前記モバイル・ノードのモビリティを管理するためにネットワーク・ベースのモビリティ管理スキームを使用し、前記モバイル・ノードは、
前記第１のネットワーク内の前記モバイル・ノードの位置に関するメッセージを前記モバイル・ノードに対するモバイル・アンカー・ポイントに送信するための送信手段であって、前記モバイル・ノードが第１のＩＰアドレスを有する送信手段と、
前記モバイル・ノードの前記第１のＩＰアドレスに対するバインディング要求メッセージを前記モバイル・アンカー・ポイントから受信するための受信手段とを有し、
前記送信手段は、前記受信したバインディング要求メッセージへの応答メッセージを前記モバイル・アンカー・ポイントに送信するように構成されたモバイル・ノード。
【請求項３３】
前記送信手段が、リフレッシュ・アドバイス・オプションがゼロに設定されたバインディング要求メッセージを受信した場合に、バインディング更新を前記モバイル・アンカー・ポイントに送信するように構成された請求項３２に記載のモバイル・ノード。
【請求項３４】
モバイル・ノードのモビリティを管理するためのネットワーク・ベースのモビリティ管理スキームを使用するネットワーク内のネットワーク要素であって、
前記ネットワーク内の前記モバイルの位置に関するメッセージを前記モバイル・ノードに対するモバイル・アンカー・ポイントに送信するための送信手段であって、前記モバイル・ノードはＩＰアドレスを有する送信手段と、
前記モバイル・ノードの前記ＩＰアドレスに対するバインディング要求メッセージを前記モバイル・アンカー・ポイントから受信するための受信手段とを有し、
前記送信手段は、前記受信したバインディング要求メッセージへの応答メッセージを前記モバイル・アンカー・ポイントに送信するように構成されたネットワーク要素。
【請求項３５】
前記送信手段が、リフレッシュ・アドバイス・オプションがゼロに設定されたバインディング要求メッセージを受信した場合に、バインディング更新を前記モバイル・アンカー・ポイントに送信するように構成された請求項３４に記載のネットワーク要素。
【請求項３６】
前記ネットワーク要素への前記モバイル・ノードの接続をチェックするためのチェック手段を更に有し、
前記ネットワーク要素が、前記モバイル・ノードが前記ネットワーク要素に接続されている場合、前記モバイル・アンカー・ポイントにバインディング更新を送信し、前記モバイル・ノードが前記ネットワーク要素に接続されていない場合、前記バインディング要求メッセージを破棄するように構成された請求項３４に記載のネットワーク要素。
【請求項３７】
前記ネットワーク要素への前記モバイル・ノードの接続をチェックするためのチェック手段を更に有し、
前記ネットワーク要素が、前記モバイル・ノードが前記ネットワーク要素に接続されている場合、ゼロよりも長い存続期間を有するバインディング更新を、又は前記モバイル・ノードが前記ネットワーク要素に接続されていない場合、ゼロに等しい存続期間を有するバインディング更新を送信するように構成された請求項３４に記載のネットワーク要素。
【請求項３８】
前記チェック手段が、レイヤ２ポーリング・メッセージ又は近隣要請メッセージのうちの少なくとも１つを前記モバイル・ノードに送信するように構成された請求項３６に記載のネットワーク要素。
【国際調査報告】
2010507301.tif 000027
2010507301.tif 000028
2010507301.tif 000029
2010507301.tif 000030
2010507301.tif 000031
2010507301.tif 000032
2010507301.tif 000033