Internet Research Task Force (IRTF) Y. Qiu
Request for Comments: 5726 Institute for Infocomm Research
Category: Experimental F. Zhao, Ed.
ISSN: 2070-1721 Google
R. Koodli
Cisco Systems
February 2010
Mobile IPv6 Location Privacy Solutions
Abstract
抽象
Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group.
モバイルIPv6（RFC 3775）は、インターネット上でローミングしながら、到達可能なままにモバイルノードを可能にします。しかしながら、モバイルノードの位置及び移動がシグナリングまたはデータパケットで使用されるIPアドレスによって明らかにすることができます。この文書では、我々は、RFC 4882に記述モバイルIPv6ロケーションプライバシーの問題を考えると、移動ノードの位置のプライバシーを保護するために、効率的かつ安全な手法を提案します。この文書では、IPモビリティの最適化（MobOpts）研究グループの製品です。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the IP Mobility Optimizations Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（IRTF）のIPモビリティの最適化研究グループのコンセンサスを表しています。 IRSGによって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5726.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5726で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................5
2. Conventions and Terminology .....................................6
2.1. Conventions ................................................6
2.2. Terminology ................................................6
3. Requirements ....................................................8
4. Solution Overview ...............................................9
5. Reverse-Tunneled Correspondent Binding Update ..................11
5.1. The Procedure .............................................12
5.2. Route-Optimized Payload Packets ...........................14
5.3. Mobile Node Operation .....................................15
5.3.1. Conceptual Data Structures .........................15
5.3.2. Reverse-Tunneled Correspondent Binding
Update to the Correspondent Node ...................15
5.3.3. Reverse-Tunneled Correspondent Binding
Acknowledgement from the Correspondent Node ........16
5.3.4. Route-Optimized Payload Packets ....................16
5.3.5. Receiving ICMP Error Message .......................17
5.3.6. Binding Error from the Correspondent Node ..........17
5.3.7. Binding Refresh Request from the
Correspondent Node .................................17
5.4. Home Agent Operation ......................................17
5.5. Correspondent Node Operation ..............................18
5.5.1. Conceptual Data Structures .........................18
5.5.2. Reverse-Tunneled Correspondent Binding
Update from the Mobile Node ........................18
5.5.3. Reverse-tunneled Correspondent Binding
Acknowledgement to the Mobile Node .................18
5.5.4. Route-Optimized Payload Packets ....................18
5.5.5. ICMP Error Message to the Mobile Node ..............19
5.5.6. Binding Error to the Mobile Node ...................19
5.5.7. Binding Refresh Request to the Mobile Node .........19
5.6. Summary ...................................................20
6. IP Address Location Privacy Solution Using the Pseudo
Home Address ...................................................20
6.1. Home Binding Update .......................................20
6.1.1. Pseudo Home Address Registration ...................20
6.1.2. Home De-Registration ...............................21
6.2. Correspondent Binding Update Using the Pseudo Home
Address ...................................................22
6.2.1. Return Routability Procedure .......................22
6.2.2. Route-Optimized Correspondent Binding Update .......24
6.2.3. Reverse-tunneled Correspondent Binding Update ......25
6.2.4. Using Different Pseudo Home Addresses with
Different Correspondent Nodes ......................25
6.3. Payload Packets ...........................................25
6.3.1. Reverse Tunneling Mode .............................25
6.3.2. Route Optimization Mode ............................26
6.4. Prefix Discovery ..........................................26
6.5. Mobile Node Operation .....................................26
6.5.1. Conceptual Data Structures .........................26
6.5.2. Binding Update to the Home Agent ...................27
6.5.3. Binding Acknowledgement from the Home Agent ........27
6.5.4. Home Test Init to the Home Agent ...................28
6.5.5. Home Test from the Home Agent ......................28
6.5.6. Route-Optimized Payload Packets ....................29
6.5.7. Receiving Binding Refresh Request ..................29
6.6. Home Agent Operation ......................................29
6.6.1. Conceptual Data Structures .........................30
6.6.2. Binding Update from the Mobile Node ................30
6.6.3. Binding Acknowledgement to the Mobile Node .........31
6.6.4. Home Test Init from the Mobile Node ................31
6.6.5. Home Test to the Mobile Node .......................32
6.7. Correspondent Node Operation ..............................32
7. Extensions to Mobile IPv6 ......................................32
7.1. Encrypted Home Address Destination Option .................32
7.2. Encrypted Home Address Routing Header .....................33
7.3. Pseudo Home Address Mobility Option .......................34
7.4. Pseudo Home Address Acknowledgement Mobility Option .......35
8. Security Considerations ........................................37
8.1. Home Binding Update .......................................37
8.2. Correspondent Binding Update ..............................38
8.3. Route-Optimized Payload Packets ...........................38
9. Related Work ...................................................39
10. IANA Considerations ...........................................40
11. Conclusion ....................................................40
12. Acknowledgements ..............................................41
13. References ....................................................41
13.1. Normative References .....................................41
13.2. Informative References ...................................42
Appendix A. Profiling Attack: Discussion ..........................44
A.1. The Care-of Address ........................................44
A.2. Profiling on the Encrypted Home Address ....................44
A.3. The IPsec SPI ..............................................45
A.4. The IPsec Sequence Number ..................................45
A.5. The Regular Interval of Signaling Messages..................46
A.6. The Sequence Number in the Binding Update Message ..........46
A.7. Multiple Concurrent Sessions ...............................46
A.8. Summary ....................................................47
The IP address location privacy problem is concerned with unwittingly revealing the current location of a mobile node to eavesdroppers and to communicating parties. In the presence of mobility as specified in Mobile IPv6 [6], there are two related problems: disclosing the care-of address to a correspondent node, and revealing the home address to an eavesdropper (please see the terminology below). A detailed description of the location privacy problem can be found in RFC 4882 [11]. This document assumes that the reader is familiar with the basic operation of Mobile IPv6 specified in RFC 3775, as well as the location privacy problem described in RFC 4882.
IPアドレスのロケーションプライバシ問題が無意識盗聴者及び通信相手移動ノードの現在の位置を明らかにも関します。コレスポンデントノードに気付アドレスを開示し、盗聴者に自宅の住所を明らかに（下記の用語を参照してください）：モバイルIPv6に指定されているモビリティの存在下では、[6]、二つの関連問題があります。ロケーションプライバシーの問題の詳細な説明は、RFC 4882 [11]に見出すことができます。この文書は、読者がRFC 3775で指定されたモバイルIPv6の基本的な動作、ならびにRFC 4882に記載ロケーションプライバシーの問題に精通していることを前提としています。
In order to protect location privacy, a mobile node must not disclose the binding between its care-of address and its home address. In this document, we propose a set of extensions to the Mobile IPv6 specification to address the IP address location privacy problem. Related to the IP address location privacy is "profiling", where the activities of a mobile node are linked and then analyzed. Profiled activities may contribute to compromising a mobile node's location privacy, especially when combined with additional information. Furthermore, once location privacy is compromised, it may lead to more targeted profiling. Solutions to thwart profiling are important; however, they are not central to this document. We discuss profiling in the appendix.
ロケーションプライバシーを保護するために、モバイルノードはその気付アドレスとホームアドレスとの間の結合を開示していなければなりません。この文書では、IPアドレス位置プライバシーの問題に対処するためのモバイルIPv6仕様の拡張セットを提案します。 IPアドレス位置プライバシーに関連するモバイル・ノードの活動がリンクされ、その後に分析されている「プロファイリング」、です。プロファイリングの活動は、追加情報と組み合わせる場合は特に、モバイルノードのロケーションプライバシーを犠牲にすることに寄与することができます。位置プライバシーが侵害されるとさらに、それはよりターゲットを絞ったプロファイリングにつながる可能性があります。プロファイリングを阻止するためのソリューションが重要です。しかし、彼らはこのドキュメントの中心ではありません。私たちは、付録にプロファイリングを議論します。
We propose two IP address location privacy solutions in this document. With the first solution (as described in Section 5), the mobile node can communicate with the correspondent node by using the real home address without location privacy being breached by eavesdroppers. This is done by using parameters generated during the return routability procedure to mask the real home address, which provides an evolution towards location privacy protection based on return routability messages already specified in RFC 3775. With the second solution (as described in Section 6), an IPsec tunnel mode security association with a non-null encryption algorithm is negotiated to encrypt signaling messages (including the real home address therein) exchanged between the mobile node and the home agent, for example, during the home binding update procedure. Furthermore, during the return routability procedure and the correspondent binding update procedure, a "pseudo home address" (the definition of this new term and many other commonly used mobility related terms is provided in Section 2) is used to replace the real home address in various messages, which allows the mobile node to hide its real home address from both the correspondent node and eavesdroppers without the need for additional extensions to the correspondent node. Moreover, the mobile node may mask the pseudo home address by using the mechanism specified in Section 5 to further enhance location privacy protection. Each of these two solutions can be implemented on its own without relying on the other.
私たちは、この文書に記載されている2つのIPアドレス位置プライバシーのソリューションを提案しています。最初の溶液（セクション5に記載されているように）を用いて、モバイルノードは、盗聴者により侵害されるロケーションプライバシなし実際のホームアドレスを用いて通信相手ノードと通信することができます。これは、すでに第二の溶液（第6節で説明したように）でRFC 3775.に指定されたリターン・ルータビリティ・メッセージに基づいて位置プライバシーの保護に向けた進展を提供し、実際のホームアドレスを、マスクするように、リターン・ルータビリティ手順の間に生成したパラメータを使用して行われ、非ヌル暗号化アルゴリズムとIPsecトンネルモードのセキュリティアソシエーションは、（その中の実際のホームアドレスを含む）シグナリングメッセージを暗号化するためにネゴシエートされているホーム結合更新手順の間に、例えば、モバイルノードとホームエージェントの間で交換。さらに、リターン・ルータビリティ手順と対応結合更新手順、「疑似ホームアドレス」（この新しい用語や他の多くの一般的に使用されるモビリティ関連する用語の定義は、セクション2に設けられている）の間に、実際のホームアドレスを交換するために使用されますモバイルノードは、コレスポンデントノードへの追加の拡張機能を必要とせずに、通信相手ノードと盗聴者の両方からその実際のホームアドレスを非表示にすることができ、様々なメッセージ。また、モバイルノードは、さらに、ロケーションプライバシ保護を強化するために、セクション5で指定されたメカニズムを使用して、擬似ホーム・アドレスをマスクしてもよいです。これら二つの溶液のそれぞれは、他に頼らず、独自に実装することができます。
The solutions presented in this document are designed based on the following assumptions. First, we focus on location privacy issues arising when the mobile node attaches to a foreign link; location privacy issues when the mobile node attaches to its home link, if any, are outside the scope of this document. Second, we assume that IPsec [2] is used to secure mobility signaling messages exchanged between the mobile node and the home agent; therefore, location privacy solutions when other security mechanisms are used are beyond the scope of this document. Third, we assume that eavesdroppers are passive attackers, e.g., an eavesdropper along the path traversed by traffic flows from or to the mobile node. We make this assumption because messages generated by active attackers can either be discarded based on local policy at a mobile node or the mobile node could choose to treat such messages like those of any other correspondent nodes. Thus, specific threats to location privacy posed by active attackers are also beyond the scope of this document. Fourth, in order to simplify analysis, we assume that both the correspondent node and the home agent are fixed nodes; if either is mobile, the same analysis and solutions for the mobile node may also apply. Finally, the same solution applies to each of the care-of addresses if a mobile node maintains more than one care-of address.
この文書のソリューションは、以下の仮定に基づいて設計されています。まず、モバイルノードが外部リンクに接続するときに生じる場所のプライバシーの問題に焦点を当てます。ロケーションプライバシーの問題があれば、移動ノードは、そのホームリンクに接続するとき、このドキュメントの範囲外です。第二に、我々は、IPsecは、[2]、モバイルノードとホームエージェントの間で交換モビリティシグナリングメッセージを保護するために使用されていることを前提としています。従って、他のセキュリティ・メカニズムが使用される場所のプライバシーソリューションは、この文書の範囲を超えています。第三に、我々は、例えば、トラフィックが横断する経路に沿って、盗聴者から、またはモバイルノードに流れる盗聴者は、受動的攻撃者であると仮定する。アクティブな攻撃者によって生成されたメッセージは、いずれかのモバイルノードでローカルポリシーに基づいて廃棄することができたり、移動ノードが他の通信員ノードのものと同じようなメッセージを処理することを選択することができるので、私たちはこの仮定を作ります。このように、能動的攻撃者によってもたらされる位置プライバシーに特有の脅威は、この文書の範囲外でもあります。第四に、分析を簡単にするために、我々は、コレスポンデントノードとホームエージェントの両方が固定ノードであると仮定します。いずれかがモバイルである場合、モバイルノードに対して同じ分析および溶液も適用することができます。モバイルノードが複数の気付アドレスを保持している場合最後に、同ソリューションは、気付アドレスのそれぞれに適用されます。
This document represents the consensus of the MobOpts Research Group. It has been reviewed by the Research Group members active in the specific area of work. At the request of their chairs, this document has been comprehensively reviewed by multiple active contributors to the IETF Mobile IP related working groups.
この文書では、MobOpts研究グループのコンセンサスを表しています。それは仕事の特定の領域に積極的に研究グループのメンバーによって検討されています。その椅子の要請で、この文書は包括IETFモバイルIP関連のワーキンググループに複数のアクティブな貢献者によって検討されています。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにありますRFC 2119に記載されるように解釈される[1]。
In this document, we introduce two new terms, "pseudo home address" and "encrypted home address". The definition of these two terms is provided in the following.
この文書では、我々は、2つの新しい用語、「疑似ホームアドレス」と「暗号化されたホームアドレス」をご紹介します。これら二つの用語の定義を以下に提供されます。
o Pseudo Home Address (pHoA): A unicast IPv6 address formed to replace the real home address used in certain Mobile IPv6 signaling or data packets. Without explicit indication, the pseudo home address looks like a regular IPv6 address [5].
O疑似ホームアドレス（phoAの）：特定のモバイルIPv6シグナリングまたはデータパケットで使用される実際のホームアドレスを交換するように形成されたユニキャストIPv6アドレス。明示的な表示がなければ、疑似ホームアドレスは、通常のIPv6アドレス[5]のように見えます。
o Encrypted Home Address (eHoA): The output when applying an encryption algorithm to the real home address or the pseudo home address with additional inputs, e.g., a key. The real home address can be recovered from the encrypted home address by using a decryption algorithm.
O暗号化ホームアドレス（eHoA）：例えば、実際の自宅の住所または追加の入力を持つ疑似ホームアドレスに鍵を暗号化アルゴリズムを適用し、出力。実際のホームアドレスは、復号アルゴリズムを使用して暗号化されたホームアドレスから回収することができます。
In addition, we use commonly adopted mobility-related terms as defined in [6] and [11] throughout this document. Some of these terms are provided below for easier reference. Nevertheless, we assume that readers are familiar with the basic operation of the Mobile IPv6 protocol as defined in RFC 3775 [6], RFC 3776 [7], and RFC 4877 [8].
加えて、我々は、この文書全体で定義されるように、一般的に採用モビリティ関連用語を使用し[6]、[11]。これらの用語のいくつかは、簡単に参照するために、以下に提供されます。それにもかかわらず、我々は、[8] [7] RFC 3776 [6] RFC 3775で定義されるように読者がモバイルIPv6プロトコルの基本的な操作に精通していると仮定し、そしてRFC 4877。
o Mobile Node (MN): A Mobile IPv6 compliant mobile node that can roam on the Internet
Oモバイルノード（MN）：インターネット上でローミングすることができ、モバイルIPv6対応モバイルノード
o Correspondent Node (CN): An IPv6 node that communicates with the mobile node
Oの対応ノード（CN）：モバイルノードと通信IPv6ノード
o Home Network: The network where the mobile node is normally present when it is not roaming
Oホームネットワーク：それはローミングされていない場合、モバイルノードが通常存在するネットワーク
o Visited Network: The network that the mobile node uses to access the Internet when it is roaming
それがローミングしているとき、モバイルノードは、インターネットへのアクセスに使用するネットワーク：Oネットワークを訪問
o Home Agent (HA): A router on the mobile node's home network that provides forwarding support when the mobile node is roaming
Oホームエージェント（HA）：モバイルノードがローミングしているときの転送のサポートを提供し、モバイルノードのホームネットワーク上のルータ
o Home Address (HoA): The mobile node's unicast IP address valid on its home network
Oホームアドレス（HoA）：ホームネットワーク上の有効な移動ノードのユニキャストIPアドレス
o Care-of Address (CoA): The mobile node's unicast IP address valid on the visited network
O気付アドレス（CoA）：訪問先ネットワーク上の有効な移動ノードのユニキャストIPアドレス
o Return Routability (RR): A procedure which enables secure binding between the care-of address and the home address when no pre-existing security association exists between the mobile node and the correspondent node
Oリターンルータビリティ（RR）：なし既存のセキュリティアソシエーションがモバイルノードとコレスポンデントノードとの間に存在しない場合気付アドレスとホームアドレスとの間の結合を確保でき手順
o Home Test Init (HoTI) / Home Test (HoT) / Care-of Test Init (CoTI) / Care-of Test (CoT): Messages used during the return routability procedure
Oホーム試験開始（HoTIメッセージ）/ホーム試験（ホット）/気付テスト開始（CoTIの）/気付テスト（COT）：リターン・ルータビリティ手順の間に使用されるメッセージ
o Binding Update (BU): A message used by the mobile node to securely bind its care-of address to its home address at the correspondent node or the home agent
O結合更新（BU）：セキュア通信相手ノードまたはホームエージェントにホームアドレスをその気付アドレスをバインドするためにモバイルノードによって使用されるメッセージ
o Binding Acknowledgement (BA): A response to the Binding Update
O結合確認（BA）：バインディング更新に応答
o Message Authentication Code (MAC): The value, which is computed using HMAC_SHA1 in this document, that protects both a message's integrity and its authenticity
Oメッセージ認証コード（MAC）：本書でHMAC_SHA1を使用して計算された値は、メッセージの完全性と真正性の両方を保護
o Route Optimization: A mechanism that allows direct routing of packets between a roaming mobile node and its correspondent node, without having to traverse the home network
Oルート最適化：ローミングモバイルノードとコレスポンデントノードとの間のパケットの直接ルーティングを可能にする機構、ホームネットワークを通過することなく
o Reverse Tunneling or Bidirectional Tunneling: A mechanism used for packet forwarding between a roaming mobile node and its correspondent node via its home agent
Oリバーストンネリングまたは双方向トンネリング：そのホームエージェントを経由してローミングモバイルノードとコレスポンデントノードとの間のパケット転送のために使用されるメカニズム
In this section, we describe the requirements that should be met by the Mobile IPv6 location privacy solutions, hereafter referred to as "the solution". These are some of the basic requirements set forth in order to make the solution readily implementable by those familiar with Mobile IPv6 and the related security protocols used with it (such as IKEv2 [4] and IPsec).
このセクションでは、以下「ソリューション」と呼ばれるモバイルIPv6位置プライバシー・ソリューション、が満たすべき要件について説明します。これらは、モバイルIPv6とそれに使用される関連するセキュリティプロトコルに精通した者によって溶液が容易に実現可能にするために記載された基本的な要件の一部である（例えば、IKEv2の[4]とIPsec）。
R01: The solution must follow the framework and architecture of IPv6 and Mobile IPv6 (as specified in RFC 3775, RFC 3776, and RFC 4877).
R01は：溶液は、IPv6およびモバイルIPv6（RFC 3775、RFC 3776、およびRFC 4877に指定されている）のフレームワークとアーキテクチャに従わなければなりません。
R02: The solution must not interfere with the operation of IPsec. This means that the principles and the operation specified in RFC 3776 and RFC 4877 need to be followed. For example, the IPsec security association and policy must be identified by the real home address.
R02：ソリューションでは、IPsecの動作を妨害してはなりません。これは、原則とRFC 3776で指定された操作およびRFC 4877に従うする必要があることを意味します。例えば、IPsecセキュリティ協会と政策は、実際のホームアドレスによって識別されなければなりません。
R03: The solution should provide back-compatibility in order for different Mobile IPv6 entities to work together even though they may have different capabilities. This requires the mobile node to be able to detect whether the home agent or the correspondent node supports the use of the location privacy solutions.
R03：ソリューションは、さまざまなモバイルIPv6のエンティティが、彼らは異なる機能を持っていても一緒に仕事をするために戻って互換性を提供する必要があります。これは、ホームエージェントやコレスポンデントノードは、ロケーションプライバシソリューションの使用をサポートしているかどうかを検出できるようにするには、モバイルノードが必要です。
R04: The overhead resulting from the solution, in terms of payloads or messages transmitted and memory, should be kept minimal.
R04：ペイロードまたはメッセージ送信とメモリの点で溶液から生じるオーバーヘッドは、最小限に保たれるべきです。
The IP address location privacy solutions proposed in this document intend to conceal the binding between the mobile node's real home address and its care-of address from eavesdroppers and the correspondent node. In this section, we present an overview of the proposed solutions.
この文書で提案されているIPアドレス位置プライバシー・ソリューションは、モバイルノードの実際のホームアドレスと、盗聴者からその気付アドレスとコレスポンデントノード間の結合を隠すつもり。この節では、提案されたソリューションの概要を提示します。
With the Mobile IPv6 specification, during the home binding update procedure, both the real home address and the care-of address are in the cleartext when either the IPsec tunnel mode or the IPsec transport mode is used with no encryption. As described in Section 6.1, the solution to prevent the real home address being leaked to eavesdroppers on the MN-HA path during the home binding update procedure is to set up an IPsec tunnel mode security association with a non-null encryption algorithm to encrypt home binding signaling messages and the real home address therein. This method is also used to enable location privacy protection during other mobility signaling message exchanges between the home agent and the mobile node, such as the prefix discovery procedure (see Section 6.4).
モバイルIPv6の仕様では、ホームバインディング更新手順、実際のホームアドレスと気付アドレスの両方の間にIPsecトンネルモードまたはIPsecトランスポートモードのいずれかを暗号化なしで使用されるクリアテキストです。 6.1節で述べたように、実際のホームアドレスを防ぐための解決策は、家庭バインディング更新手順の間にMN-HAパス上の盗聴者に漏洩するには、家を暗号化するnull以外の暗号化アルゴリズムとIPsecトンネルモードセキュリティアソシエーションを設定することですその中のシグナリングメッセージと実際のホームアドレスをバインディング。この方法はまた、接頭語発見手順とホームエージェントとモバイルノードとの間の他のモビリティ・シグナリング・メッセージ交換、（セクション6.4を参照）の間に位置プライバシーの保護を可能にするために使用されます。
When communicating with the correspondent node with the reverse tunneling mode, the mobile node can hide its current location from the correspondent node and eavesdroppers along the HA-CN path, since the care-of address is not included in payload packets transmitted on that path. Also, an IPsec security association with a non-null encryption algorithm established between the mobile node and the home agent can conceal the real home address carried in payload packets from eavesdroppers along the MN-HA path.
リバーストンネリングモードとコレスポンデントノードと通信する際に気付アドレスがそのパス上で送信ペイロードパケットに含まれていないので、モバイルノードは、HA-CN経路に沿って通信相手ノードと盗聴者から、その現在位置を隠すことができます。また、モバイルノードとホームエージェントとの間で設立された非ヌル暗号化アルゴリズムとのIPsecセキュリティアソシエーションは、MN-HA経路に沿って、盗聴者からペイロードパケットで運ばれた実際のホームアドレスを隠すことができます。
In order to communicate with a correspondent node in the route optimization mode, the mobile node needs to perform the return routability procedure followed by the correspondent binding update procedure. With the current Mobile IPv6 specification, the real home address and the care-of address in the correspondent Binding Update message and payload packets are visible to eavesdroppers. Therefore, in order to send and receive packets through the optimized route and protect location privacy at the same time, the mobile node needs to disclose its care-of address and conceal its real home address. There are two different scenarios and we propose a different solution for each scenario.
ルート最適化モードで通信相手ノードと通信するために、モバイルノードは、更新手順を結合相手続いリターン・ルータビリティ手順を実行する必要があります。現在のモバイルIPv6の仕様では、実際のホームアドレスと気付アドレス対応Binding Updateメッセージとペイロードパケットでは、盗聴者に表示されます。そのため、送受信したパケットを最適化された経路を通って、同時に位置プライバシーを保護するために、モバイルノードはその気付アドレスを開示し、その実際のホームアドレスを隠すために必要です。そこ2つの異なるシナリオがあり、私たちは各シナリオごとに異なる解決策を提案します。
One scenario is that the correspondent node is able to obtain the mobile node's real home address and initiates communication with the mobile node by using the real home address. In this case, the mobile node needs to continue to use the real home address with the correspondent node in order to maintain session continuity, and to conceal the real home address from eavesdroppers. The solution for this scenario (hereinafter referred to as "reverse-tunneled correspondent binding update") is described in Section 5. With this solution, the mobile node exchanges the same return routability signaling messages as defined in RFC 3775 with the correspondent node and then derives a privacy management key from keygen tokens and uses this key to encrypt the real home address. Finally, it reverse-tunnels an extended correspondent Binding Update message via the home agent to register the encrypted home address and the real home address at the correspondent node. After the correspondent registration, the mobile node and the correspondent node use the registered encrypted home address, instead of the real home address in payload packets exchanged via the optimized route. The encrypted home address is different for different correspondent nodes since the privacy management key would be different.
1つのシナリオは、コレスポンデントノードは、モバイルノードの実際のホームアドレスを取得することができ、実際のホームアドレスを用いて移動ノードとの通信を開始していることです。この場合、移動ノードは、セッション継続性を維持するために、コレスポンデントノードとの実際のホームアドレスを使用すると、盗聴者から実際のホームアドレスを隠すために継続する必要があります。このシナリオの溶液（以下、「逆トンネリング対応バインディング更新」と呼ぶ）は、移動ノードの交換は、その後、通信相手ノードとRFC 3775で定義されており、同じリターン・ルータビリティは、シグナリングメッセージを、この溶液のセクション5に記載されていますkeygenのトークンからのプライバシー管理キーを導出し、実際のホームアドレスを暗号化するために、このキーを使用しています。最後に、暗号化されたホームアドレスとコレスポンデントノードの実際のホームアドレスを登録するには、ホームエージェントを経由して、拡張特派Binding Updateメッセージを、トンネルに逆転します。通信員登録後、モバイルノードとコレスポンデントノードではなく、ペイロードパケットの本当のホームアドレスの登録暗号化されたホームアドレスを、使用して最適なルートを介して交換。プライバシー管理キーは異なるだろうので、暗号化されたホームアドレスが異なる通信員ノードのために異なっています。
The other scenario is that the mobile node prefers to conceal its real home address from both the correspondent node and the eavesdroppers (typically the mobile node initiates communication in this case, since the correspondent node does not know the real home address). The solution for this scenario is described in Section 6.2. With this solution, the mobile node first obtains a home keygen token generated based on the pseudo home address during the home address test procedure. Subsequently, the mobile node sends the correspondent Binding Update message to register the binding between the pseudo home address and the care-of address at the correspondent node via the optimized route. After the correspondent registration, the mobile node and the correspondent node use the registered pseudo home address, instead of the real home address, in payload packets exchanged via the optimized route. Note that the use of the pseudo home address is completely transparent to the correspondent node.
他のシナリオでは、モバイルノードがコレスポンデントノードと盗聴者（コレスポンデントノードは、実際のホームアドレスを知らないため、通常、モバイルノードが、この場合には通信を開始）の両方からその実際のホームアドレスを隠すことを好むということです。このシナリオのためのソリューションは、セクション6.2に記載されています。このソリューションにより、モバイルノードは、最初のホームアドレステスト手順の間の疑似ホームアドレスに基づいて生成されたホーム鍵生成トークンを取得します。その後、モバイルノードは、疑似ホームアドレスと気付けアドレス相手ノードでの最適なルートを経由しての間の結合を登録するための特派Binding Updateメッセージを送信します。コレス登録後、モバイルノードとコレスポンデント・ノードではなく実際のホームアドレスの登録擬似ホーム・アドレスを使用し、ペイロードパケットに最適化された経路を介して交換しました。疑似ホームアドレスの使用は、通信相手ノードに対して完全に透過的であることに注意してください。
Furthermore, it is feasible to throttle "profiling" on the pseudo home address by using a combination of these two solutions. That is, the mobile node uses the pseudo home address in the extended home address test procedure to obtain a home keygen token; then, it uses the pseudo home address instead of the real home address in the reverse-tunneled correspondent binding update procedure. With this solution, the encrypted pseudo home address used in route optimized payload packets looks different to eavesdroppers each time, after a new round of the return routability procedure is completed.
さらに、これら2つのソリューションの組み合わせを使用することにより、擬似ホームアドレスに「プロファイリングを」スロットルすることが可能です。すなわち、移動ノードがホーム鍵生成トークンを取得するために、拡張ホーム・アドレス試験手順における擬似ホーム・アドレスを使用し、です。そして、それは疑似ホームアドレスの代わりに、逆トンネリング対応結合更新手順で実際のホームアドレスを使用しています。リターン・ルータビリティ手順の新ラウンドが完了した後に、このソリューションを使用すると、ルート最適化されたペイロードパケットで使用される暗号化された疑似ホームアドレスは、盗聴者たびに違って見えます。
Before a pseudo home address is used with a correspondent node, it MUST be registered with the home agent during the home registration procedure. The mobile node indicates the requested pseudo home address in a new mobility option, called the Pseudo Home Address option (see Section 7.3), carried in the home Binding Update message,
疑似ホームアドレスは、通信相手ノードで使用される前に、ホーム登録手続きの際にホームエージェントに登録しなければなりません。モバイルノードは、ホームBinding Updateメッセージで運ばれた疑似ホームアドレスオプションを（7.3節を参照）と呼ばれる、新しいモビリティオプションで要求された擬似的なホームアドレスを示し、
and the home agent indicates the status of pseudo home address registration in another new mobility option, called Pseudo Home Address Acknowledgement option (see Section 7.4), carried in the home Binding Acknowledgement message. The pseudo home address MUST be routable in order for the home agent to intercept packets destined at this pseudo home address. It is statistically difficult for other nodes to derive the real home address from the pseudo home address. A detailed description of pseudo home address generation is provided in Section 6.1.1.1.
ホームエージェントは、擬似ホーム確認メッセージをバインディング家庭で運ば謝辞オプション（7.4節を参照）、アドレスと呼ばれる別の新しいモビリティオプション、擬似ホームアドレス登録の状態を示します。疑似ホームアドレスは、この疑似ホームアドレスに宛てのパケットを傍受するために、ホームエージェントのための順序でルーティング可能でなければなりません。他のノードが擬似ホームアドレスから実際のホームアドレスを導出することは、統計的に困難です。擬似ホーム・アドレス生成の詳細な説明は、セクション6.1.1.1で提供されています。
With extensions introduced in this document, a mobile node is able to discover whether the home agent and the correspondent node support the location privacy solutions or not. When present in the home Binding Update message, the Pseudo Home Address mobility option indicates that the mobile node requests the use of the location privacy solutions. If such a Binding Update message is valid and the home agent supports the location privacy solutions for this particular mobile node, it responds with the Pseudo Home Address Acknowledgement mobility option in the Binding Acknowledgement message. Otherwise, if the home agent does not support the location privacy solutions, it does not include the Pseudo Home Address Acknowledgement mobility option in the Binding Acknowledgement message. Similarly, the presence of the Encrypted Home Address destination option in the correspondent Binding Update message indicates to the correspondent node that the mobile node requests the use of the location privacy solutions. If such a Binding Update message is valid and the correspondent node supports the location privacy solutions for this particular mobile node, it responds with the Encrypted Home Address routing header in the correspondent Binding Acknowledgement message to the mobile node. If the correspondent node does not support the location privacy solutions, it rejects the mobile node's request by returning an ICMP Parameter Problem message with Code value set to 2. Furthermore, a home agent that recognizes such extensions but does not wish to provide location privacy protection MAY redirect the mobile node to another home agent. If the request for using the location privacy solutions is rejected, the mobile node may either proceed without location privacy protection, or try with a different home agent or a correspondent node, or abort the operation.
このドキュメントで紹介拡張子を持つ、モバイルノードは、ホームエージェントとコレスポンデントノードは、ロケーションプライバシーのソリューションがサポートされるかどうかを発見することができます。存在する場合、家庭Binding Updateメッセージで、疑似ホームアドレスモビリティオプションは、モバイルノードは、ロケーションプライバシー・ソリューションを使用することを要求していることを示しています。このようBinding Updateメッセージが有効で、ホームエージェントは、この特定の移動ノードのための位置プライバシー・ソリューションをサポートしている場合、それはBinding Acknowledgementメッセージで疑似ホームアドレスの受け付けモビリティオプションを指定して応答します。ホームエージェントが位置プライバシー・ソリューションをサポートしていない場合はそれ以外の場合、それはBinding Acknowledgementメッセージで疑似ホームアドレスの受け付けモビリティオプションが含まれていません。同様に、Binding Updateメッセージ特派における暗号化ホームアドレス宛先オプションの存在は、モバイルノードが位置プライバシー・ソリューションの使用を要求し、通信相手ノードに指示します。このようBinding Updateメッセージが有効であるとコレスポンデントノードは、この特定のモバイルノードのための位置プライバシー・ソリューションをサポートしている場合、それはモバイルノードに確認メッセージをバインディング通信員にルーティングヘッダ暗号化ホームアドレスで応答します。コレスポンデントノードは、ロケーションプライバシソリューションをサポートしていない場合、それはさらに2、そのような拡張を認識しますが、ロケーションプライバシーの保護を提供することを望まないホームエージェントに設定されたコード値を持つICMPパラメータ問題メッセージを返すことによって、モバイルノードの要求を拒否します別のホームエージェントにモバイルノードをリダイレクトすることができます。ロケーションプライバシーのソリューションを使用するための要求が拒否された場合、移動ノードは、どちらの場所のプライバシー保護せずに先に進むか、別のホームエージェントやコレスポンデントノードとしてみてください、または操作を中止することができます。
In this section, we describe a solution that protects location privacy against eavesdroppers when the mobile node uses the real home address during communication with the correspondent node via the optimized route. Note that this solution does not require any change to return routability signaling messages. The detailed description is as follows.
このセクションでは、モバイルノードが最適化された経路を介してコレスポンデントノードとの通信時に実際のホームアドレスを使用する場合に盗聴者に対するロケーションプライバシーを保護ソリューションについて説明します。このソリューションは、ルータビリティシグナリングメッセージを返すように変更する必要はないことに注意してください。次のように詳細な説明があります。
After the return routability procedure is completed, if the mobile node needs to protect location privacy, and at the same time still uses the real home address with the correspondent node, the mobile node derives a privacy management key, Kpm, from the Kbm, where Kpm = HMAC_SHA1 (Kbm, 0). The mobile node uses Kpm to generate the encrypted home address as follows.
リターン・ルータビリティ手順が完了した後に、移動ノードは、ロケーションプライバシーを保護する必要があると同時に、まだコレスポンデントノードとの実際のホームアドレスを使用している場合、モバイルノードは、Kbmを、よりプライバシー管理キー、KPMを導出しますKPM = HMAC_SHA1（Kbmを、0）。モバイルノードは、次のように暗号化されたホームアドレスを生成するために、KPMを使用しています。
encrypted home address = Enc(Kpm, the home address)
暗号化されたホームアドレス=なお、Enc（KPM、ホームアドレス）
Where Enc() is a symmetric key encryption algorithm. AES is the default encryption algorithm.
どこENCは（）対称鍵暗号化アルゴリズムです。 AESは、デフォルトの暗号化アルゴリズムです。
Kpm changes upon every change of Kbm, which itself changes when return routability is run (e.g., upon change of care-of address, expiry of keygen token, etc.). So, Kpm is not re-used when a care-of address changes.
KPMは、リターン・ルータビリティが実行されるとき、それ自体が変化たKbmのあらゆる変化すると変化する（例えば、気付アドレス、キー生成トークンの有効期限等の変更時）。だから、KPMはとき気付アドレスの変更を再使用されていません。
The mobile node generates a correspondent Binding Update message and reverse-tunnels this message to the correspondent node via the home agent. The format of this message after encapsulation is:
モバイルノードは、Updateメッセージと逆トンネルのホームエージェントを介して相手ノードにこのメッセージをバインド対応を生成します。カプセル化した後、このメッセージの形式は次のとおりです。
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Destination option header
Encrypted Home Address option (encrypted home address)
Parameters:
Alternative Care-of Address option (care-of address)
sequence number (within the Binding Update message header)
home nonce index (within the Nonce Indices option)
care-of nonce index (within the Nonce Indices option)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))
This packet is protected by the IPsec security association with a non-null encryption algorithm. If the home agent can process this packet successfully, it forwards the following packet to the correspondent node.
このパケットは、非ヌル暗号化アルゴリズムとのIPsecセキュリティアソシエーションにより保護されています。ホームエージェントが正常にこのパケットを処理することができれば、それは相手ノードに次のパケットを転送します。
IPv6 header (source = home address,
destination = correspondent node)
Destination option header
Encrypted Home Address option (encrypted home address)
Parameters: Alternative Care-of Address option (care-of address) sequence number (within the Binding Update message header) home nonce index (within the Nonce Indices option) care-of nonce index (within the Nonce Indices option) First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BU)))
パラメータ：代替気付アドレスオプション（気付アドレス）シーケンス番号（Binding Updateメッセージのヘッダ内の）ホームナンス指数（ノンスインデックスオプション内）気付けナンス指数（ナンスインデックスオプション内）まず（96、 HMAC_SHA1（Kbmを、（気付アドレス|特派| BU）））
After receiving a reverse-tunneled correspondent Binding Update message, the correspondent node performs the operation as described in Section 5.5. If the correspondent Binding Update message is processed successfully and an acknowledgement is requested, the correspondent node constructs a Binding Acknowledgement message shown below.
セクション5.5で説明したように逆トンネリング対応付け更新メッセージを受け取った後、通信相手ノードは、動作を実行します。対応付け更新メッセージを正常に処理され、肯定応答が要求された場合、通信相手ノードは、以下に示す結合確認メッセージを構築します。
IPv6 header (source = correspondent node,
destination = home address)
Encrypted Home Address routing header
encrypted home address
Parameters:
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
Upon receiving this Binding Acknowledgement message, the home agent applies the IPsec security association with a non-null encryption algorithm to this message and forwards the following packet to the mobile node.
このBinding Acknowledgementメッセージを受信すると、ホームエージェントは、このメッセージにnull以外の暗号化アルゴリズムとのIPsecセキュリティアソシエーションを適用し、モバイルノードに、次のパケットを転送します。
IPv6 header (source = home agent,
destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent node,
destination = home address)
Encrypted Home Address routing header
encrypted home address
Parameters:
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
The reverse-tunneled correspondent binding update procedure is completed after the mobile node processes the received Binding Acknowledgement message. Note that when the mobile node communicates with a different correspondent node, the encrypted home address looks different.
モバイルノードは、受信したBinding Acknowledgementメッセージを処理した後、逆トンネリング対応バインディング更新手順が完了する。モバイルノードが異なるコレスポンデントノードと通信するときに、暗号化された自宅の住所が異なって見えることに注意してください。
To delete an established Binding Cache entry at the correspondent node, the mobile node reverse-tunnels the following Binding Update message via the home agent. Note that the Encrypted Home Address option is optional during the correspondent binding de-registration and only the home keygen token is used to generate Kbm and Kpm, if needed, in this case.
コレスポンデントノードの確立のBinding Cacheエントリーを削除するには、モバイルノードは、ホームエージェントを経由して、次のBinding Updateメッセージ-トンネルを逆転します。暗号化されたホームアドレスオプションが必要な場合は、この場合には、KbmをとKPMを生成するために使用される登録解除のみホーム鍵生成トークンを結合特派時のオプションであることに注意してください。
IPv6 header (source = care-of address,
destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address,
destination = correspondent node)
Destination option header (optional)
Encrypted Home Address option (encrypted home address)
Parameters:
Alternative Care-of Address option (care-of address)
sequence number (within the Binding Update message header)
home nonce index (within the Nonce Indices option)
care-of nonce index (within the Nonce Indices option)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))
If an acknowledgement is requested, the correspondent node returns the following Binding Acknowledgement message to the mobile node.
肯定応答が要求された場合、通信相手ノードは、モバイルノードに次のバインディング確認メッセージを返します。
IPv6 header (source = correspondent node,
destination = home address)
Encrypted Home Address routing header (optional)
encrypted home address
Parameters:
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
Since the destination IP address in this message is the home address, the home agent will receive this message and forward it to the mobile node via the reverse tunnel.
このメッセージの宛先IPアドレスはホームアドレスであるので、ホーム・エージェントは、このメッセージを受信し、リバーストンネルを介してモバイルノードに転送します。
After the correspondent registration is completed successfully, subsequent payload packets are exchanged via the optimized route between the mobile node and the correspondent node. In such packets, only the encrypted home address carried in the Encrypted Home Address destination option and the Encrypted Home Address routing header are visible to eavesdroppers.
コレスポンデント登録が正常に完了した後、後続のペイロード・パケットは、モバイルノードとコレスポンデントノードとの間の最適化された経路を介して交換されます。このようなパケットでは、暗号化ホームアドレス宛先オプションとルーティングヘッダ暗号化ホームアドレスに運ばのみ暗号化されたホームアドレスが盗聴者に表示されます。
The format of payload packets sent from the mobile node to the correspondent node is:
コレスポンデント・ノードにモバイルノードから送信されたペイロードパケットのフォーマットは次のとおりです。
IPv6 header (source = care-of address,
destination = correspondent node)
Destination option header
Encrypted Home Address option (encrypted home address)
Payload
The format of payload packets sent from the correspondent node to the mobile node is:
モバイルノードに通信相手ノードから送信されたペイロードパケットのフォーマットは次のとおりです。
IPv6 header (source = correspondent node,
destination = care-of address)
Encrypted Home Address routing header
encrypted home address
Payload
The Binding Update List entry for the correspondent registration is extended with a new field to store the current encrypted home address used with a particular correspondent node. The encrypted home address is stored when the mobile node sends a reverse-tunneled correspondent Binding Update message, and the state of the corresponding Binding Update List entry is updated when the mobile node successfully processes the correspondent Binding Acknowledgement message. Note that the encrypted home address field is not valid in the Binding Update List entry for the home registration.
通信員登録のための結合更新リストエントリは、特定の対応ノードで現在使用されている暗号化されたホームアドレスを格納するための新しいフィールドで拡張されます。モバイルノードがBinding Updateメッセージリバーストンネリング対応を送信するときに暗号化されたホームアドレスが格納され、モバイルノードが正常に確認メッセージをバインディング対応を処理するときに、対応する結合更新リストエントリの状態が更新されます。暗号化されたホーム・アドレス・フィールドは、ホーム登録のための結合更新リストエントリでは有効ではないことに注意してください。
Given that the encrypted home address is 128 bits long, it is expected that each encrypted home address or the combination of the encrypted home address and the correspondent node's IP address stored in the Binding Update List is unique. Therefore, the mobile node can use the encrypted home address (or use it together with the correspondent node's IP address) as a primary key to look up the Binding Update List.
暗号化されたホームアドレスは128ビット長であることを考えると、バインディング更新リストに保存されている暗号化された各ホームアドレスまたは暗号化されたホームアドレスの組み合わせと対応ノードのIPアドレスが一意であることが期待されます。したがって、モバイルノードは、暗号化されたホームアドレスを使用することができます（または対応ノードのIPアドレスと一緒にそれを使用する）バインディング更新リストをルックアップするために主キーとして。
5.3.2. Reverse-Tunneled Correspondent Binding Update to the Correspondent Node
5.3.2. 通信員ノードへのリバーストンネリング特派バインディングアップデート
After the return routability procedure, if the mobile node chooses to use the location privacy solution with the correspondent node, e.g., based on the mobile node's configuration, it generates the encrypted home address, updates or creates a new correspondent Binding Update List entry to store the encrypted home address, then forwards the correspondent Binding Update message through the reverse tunnel established with the home agent. Note that the MAC is generated in the same way as specified in RFC 3775, and it does not cover the encrypted home address.
リターン・ルータビリティ手順の後、モバイルノードは、コレスポンデントノードとロケーションプライバシソリューションを使用することを選択した場合、例えば、モバイルノードの構成に基づいて、それは暗号化されたホームアドレスを生成し、更新や店舗への新しい対応結合更新リストエントリを作成します暗号化されたホームアドレスは、その後、ホームエージェントに設立リバーストンネルを通してBinding Updateメッセージ通信員を転送します。 MACは、RFC 3775で指定されたのと同じ方法で生成されることに注意してください、そして、それは暗号化されたホームアドレスをカバーしていません。
5.3.3. Reverse-Tunneled Correspondent Binding Acknowledgement from the Correspondent Node
5.3.3. リバーストンネリング特派バインディング確認を相手ノードから
When the mobile node receives a Binding Acknowledgement message from the correspondent node in response to a previously sent reverse-tunneled correspondent Binding Update message, if this Binding Acknowledgement message contains an Encrypted Home Address routing header, the mobile node considers that the correspondent node supports the location privacy solution. The mobile node authenticates this message based on RFC 3775. If authentication is successful, the mobile node decrypts the encrypted home address and compares the result with the real home address, or compares the encrypted home address with the one stored in the Binding Update List entry. If they match, the mobile node considers that the correspondent registration is successful and updates the state of the corresponding Binding Update List entry. If they do not match, the mobile node MAY start the correspondent binding update procedure again.
モバイルノードは、このBinding Acknowledgementメッセージは、ヘッダをルーティング暗号化されたホームアドレスが含まれている場合、モバイルノードは、コレスポンデントノードがサポートしていることを考慮し、Binding Updateメッセージ以前に送信されたリバーストンネリング対応に応答して、通信相手ノードからバインディング確認メッセージを受信した場合ロケーションプライバシソリューション。モバイルノードがRFC 3775.認証に成功した場合に基づいて、このメッセージを認証し、モバイルノードは、暗号化されたホームアドレスを復号化し、実際のホームアドレスとの結果を比較し、または結合更新リストエントリに格納されている1つで暗号化されたホームアドレスとを比較し。それらが一致した場合、モバイルノードは、コレスポンデント登録が成功したことを考慮し、対応するバインディング更新リストエントリの状態を更新します。それらが一致しない場合は、モバイルノードは再び対応バインディング更新手順を開始することができます。
In order to maintain session continuity, upper layers of the IP stack in the mobile node still use the real home address, even after the reverse-tunneled correspondent registration.
セッションの継続性を維持するために、モバイルノードにおけるIPスタックの上位層はまだでも逆トンネリング通信員登録した後、実際のホームアドレスを使用します。
A possible way of implementation is as follows. When the Mobile IP sublayer at the mobile node receives a packet from the upper layer, the normal processing as specified in RFC 3775 is performed. Subsequently, the Home Address option is replaced with the Encrypted Home Address option carrying the encrypted home address stored in the corresponding Binding Update List entry, and then the mobile node forwards the packet to the correspondent node via the optimized route.
次のように実装可能な方法です。モバイルノードにモバイルIPサブレイヤは、上位レイヤからパケットを受信すると、RFC 3775で指定されるように、通常の処理が行われます。その後、ホームアドレスオプションは、対応するバインディング更新リストエントリに格納されている暗号化ホームアドレスを運ぶ暗号化ホームアドレスオプションに置き換えられ、その後、モバイルノードは、最適化された経路を介して相手ノードにパケットを転送します。
On the other hand, when the mobile node receives a payload packet carrying the Encrypted Home Address routing header, the mobile node uses the encrypted home address (optionally together with the IP address of the correspondent node) to look up the Binding Update List. If an entry is found, the mobile node accepts this packet, replaces the Encrypted Home Address option with the Home Address option carrying the real home address, and continues with processing based on RFC 3775. If no entry is found, the mobile node silently drops the received packet.
一方、モバイルノードはルーティングヘッダ暗号化ホームアドレスを運ぶペイロードパケットを受信した場合に、モバイルノードは、バインディング更新リストをルックアップするために暗号化されたホームアドレス（オプションとともに対応ノードのIPアドレス）を使用しています。エントリが見つかった場合、移動ノードは、このパケットを受け付け、実際のホームアドレスを運ぶホームアドレスオプションで暗号化されたホームアドレスオプションを置き換え、エントリが見つからない場合、RFC 3775.に基づいて処理を続行し、モバイルノードは静かに落ちます受信したパケット。
The mobile node may receive an ICMP Parameter Problem, Code 2, message forwarded by the home agent via the bidirectional tunnel, for example, when the correspondent node does not support the use of the Encrypted Home Address option. If such a message is received, the mobile node SHOULD not attempt to use the location privacy solution with the correspondent node. The mobile node may choose either not to communicate with the correspondent node, or to communicate without location privacy protection.
コレスポンデントノードは、暗号化されたホームアドレスオプションの使用をサポートしていないとき、モバイルノードは、ICMPパラメータ問題、コード2、例えば、双方向トンネルを介してホームエージェントによって転送されたメッセージを受け取ることができます。そのようなメッセージを受信した場合、モバイルノードは、コレスポンデントノードとロケーション・プライバシー・ソリューションを使用しないでください。モバイルノードは、コレスポンデントノードと通信するために、または場所のプライバシー保護なしで通信していないのいずれかを選択できます。
When the mobile node communicates with a correspondent node by using the encrypted home address, a Binding Error message with the Status field set as 1 (unknown binding for Home Address destination option) may be received by the mobile node if there is no valid Binding Cache entry established at the correspondent node. Note that we do not specify a new Status value to be used in this case because the implementation of the Binding Update List entry can contain an indication of whether an encrypted home address is currently used with the correspondent node. Upon receiving the Binding Error message, the mobile node can find out which encrypted home address is invalid by looking at the Home Address field of the Binding Error message. The mobile node may then perform the correspondent binding update procedure to establish a valid binding for the encrypted home address.
モバイルノードは、暗号化されたホームアドレス、1（不明はホームアドレス宛先オプションのバインディング）有効なバインディングキャッシュが存在しない場合は、モバイルノードによって受信することができるように設定ステータス・フィールドでのバインディングエラーメッセージを使用することにより、通信相手ノードと通信する場合コレスポンデントノードで確立エントリー。結合更新リスト項目の実装は、暗号化されたホームアドレスが現在対応ノードで使用されているかどうかの指示を含むことができますので、我々はこの場合に使用される新しいステータス値を指定しないことに注意してください。結合エラーメッセージを受信すると、移動ノードは、暗号化されたホームアドレスが結合エラーメッセージのホームアドレスフィールドを見て、無効であるかを調べることができます。モバイルノードは、暗号化されたホームアドレスのバインディングを有効に確立する対応結合更新手順を実行することができます。
When the mobile node receives a Binding Refresh Request message sent from the correspondent node and forwarded by the home agent via the bidirectional tunnel, the mobile node needs to perform the correspondent binding update procedure to refresh the binding for the encrypted home address at the correspondent node.
モバイルノードは、双方向トンネルを介して通信相手ノードから送信され、ホーム・エージェントによって転送バインディングリフレッシュ要求メッセージを受信すると、モバイルノードは、コレスポンデント・ノードにおける暗号化されたホームアドレスのバインディングを更新する対応付け更新手続きを実行する必要があります。
With the solution described in this section (i.e., Section 5), there is no new home agent operation to be specified. That is, the home agent behaves based on RFC 3775 when processing signaling or data packets.
このセクションで説明溶液（すなわち、セクション5）は、指定される新しいホームエージェントの動作はありません。シグナリングまたはデータパケットを処理するときには、ホームエージェントは、RFC 3775に基づいて振る舞います。
The Binding Cache entry is extended with a new field to store the current encrypted home address used with a particular mobile node. The encrypted home address is stored when the correspondent node successfully processes a reverse-tunneled correspondent Binding Update message.
Binding Cacheエントリーは、特定の移動ノードと現在使用されている暗号化されたホームアドレスを格納するための新しいフィールドで拡張されます。コレスポンデントノードが正常に更新メッセージをバインディングリバーストンネリング対応を処理するときに暗号化されたホームアドレスが格納されています。
Given that the encrypted home address is 128 bits long, it is expected that each encrypted home address or the combination of the care-of address and the encrypted home address stored in the Binding Cache entry is unique. Therefore, the correspondent node can use the encrypted home address (or use it together with the care-of address) as a primary key to look up the Binding Cache.
暗号化されたホームアドレスは128ビット長であることを考えると、暗号化された各ホームアドレスまたは気付アドレスの組み合わせと結合キャッシュ項目に保存されている暗号化されたホームアドレスが一意であることが期待されます。バインディングキャッシュをルックアップするために主キーとしてそのため、コレスポンデントノードは、暗号化されたホームアドレスを使用することができます（または気付アドレスと一緒にそれを使用します）。
5.5.2. Reverse-Tunneled Correspondent Binding Update from the Mobile Node
5.5.2. モバイルノードからのリバーストンネリング特派バインディングアップデート
When receiving a reverse-tunneled Binding Update message with the Encrypted Home Address option, if the correspondent node supports the location privacy solution, it verifies the message by using the same method as defined in RFC 3775. If this verification succeeds, the correspondent node generates Kpm and uses it to decrypt the encrypted home address, and compares the result with the source IP address. If they match, the correspondent node stores the encrypted home address in the corresponding Binding Cache entry.
暗号化ホームアドレスオプションでの逆トンネリングさBinding Updateメッセージを受信すると、通信相手ノードは、ロケーション・プライバシー・ソリューションをサポートしている場合、RFC 3775.に定義された、この検証が成功した場合、それは同じ方法を使用してメッセージを確認し、対応するノードが生成しますKPMとは、暗号化されたホームアドレスを復号化するためにそれを使用し、送信元IPアドレスとの結果を比較します。それらが一致する場合は、コレスポンデントノードは、対応するバインディングキャッシュエントリ内の暗号化されたホームアドレスを格納します。
5.5.3. Reverse-tunneled Correspondent Binding Acknowledgement to the Mobile Node
5.5.3. リバーストンネリングモバイルノードに特派バインディング確認を
If an acknowledgement to the reverse-tunneled correspondent Binding Update message is requested by the mobile node, the correspondent node returns a Binding Acknowledgement message with the Encrypted Home Address routing header, if it supports the location privacy solution. The MAC in the Binding Acknowledgement message is generated in the same way as specified in RFC 3775 and does not cover the encrypted home address carried in the Encrypted Home Address routing header.
リバーストンネリング対応付け更新メッセージに対する肯定応答をモバイルノードによって要求された場合、それは位置プライバシーソリューションをサポートしている場合、通信相手ノードは、ヘッダルーティング暗号化されたホームアドレスにバインディング確認メッセージを返します。 Binding AcknowledgementメッセージにおけるMACは、RFC 3775で指定し、ルーティングヘッダ暗号化ホームアドレスで運ばれた暗号化されたホームアドレスをカバーしていないのと同じように生成されます。
In order to maintain session continuity, upper layers of the IP stack in the correspondent node still use the real home address, even after the reverse-tunneled correspondent registration.
セッションの継続性を維持するためには、コレスポンデントノードにおけるIPスタックの上位層はまだでも逆トンネリング通信員登録した後、実際のホームアドレスを使用します。
A possible way of implementation is as follows. When the IP layer at the correspondent node finishes processing the packet received from the upper layer based on RFC 3775, the Type 2 routing header together with the real home address therein is replaced with the Encrypted Home Address routing header with the encrypted home address found in the corresponding Binding Cache entry. Then, this packet is forwarded to the mobile node via the optimized route.
次のように実装可能な方法です。コレスポンデント・ノードにおけるIP層はRFC 3775に基づいて、上位層から受信したパケットの処理を完了すると、実際のホームアドレスと一緒にタイプ2ルーティングヘッダは、その中に見出される暗号化されたホームアドレスを使用して暗号化ホームアドレスルーティングヘッダに置き換えられ対応するバインディングキャッシュエントリ。次いで、このパケットは、最適化された経路を介して移動ノードに転送されます。
On the other hand, when the correspondent node receives a payload packet with the Encrypted Home Address option, it uses the encrypted home address (optionally together with the care-of address of the mobile node) to look up the Binding Cache. If there is an entry, the correspondent node replaces the Encrypted Home Address option with the Home Address option carrying the real home address before forwarding the packet to the upper layer. If no matching entry is found, the correspondent node sends a Binding Error message to the source IP address, i.e., the care-of address of the mobile node.
コレスポンデントノードは、暗号化されたホームアドレスオプションとペイロードパケットを受信する一方、それはバインディングキャッシュを検索する（気付モバイルノードのアドレスと、必要に応じて一緒に）暗号化されたホームアドレスを使用しています。エントリがある場合は、コレスポンデントノードは、上位層にパケットを転送する前に、実際のホームアドレスを運ぶホームアドレスオプションで暗号化されたホームアドレスオプションを置き換えます。一致するエントリが見つからない場合、通信相手ノードは、送信元IPアドレス、すなわち、気付モバイルノードのアドレスに結合すると、エラーメッセージを送信します。
When receiving a reverse-tunneled correspondent Binding Update message with the Encrypted Home Address option, if the correspondent node does not support location privacy extensions, it sends an ICMP Parameter Problem, Code 2, message to the source IP address (i.e., the home address of the mobile node) and the home agent then forwards this ICMP message to the mobile node via the bidirectional tunnel.
コレスポンデントノードは、ロケーションプライバシの拡張機能をサポートしていない場合、暗号化されたホームアドレスオプションでBinding Updateメッセージリバーストンネリング対応を受信した場合、それは、ICMPパラメータ問題、コード2、送信元IPアドレス（すなわち、ホームアドレスにメッセージを送信します前方このICMPメッセージをモバイルノードへの双方向トンネルを経由して、移動ノードの）とホームエージェント。
When the correspondent node receives a payload packet with the Encrypted Home Address option for which there is no valid Binding Cache entry, it returns a Binding Error message with the Status code set as 1 back to the source IP address of the packet. Furthermore, the Home Address field in the Binding Error message MUST be copied from the Encrypted Home Address field in the Encrypted Home Address destination option of the offending packet, or set to the unspecified address if no such option appears in the packet.
コレスポンデントノードが有効なバインディングキャッシュエントリが存在しないいる暗号化ホームアドレスオプションとペイロードパケットを受信すると、パケットの送信元IPアドレスに戻って1として設定されたステータスコードと結合エラーメッセージを返します。さらに、バインディングエラーメッセージでのホームアドレスフィールドには、問題のあるパケットの暗号化ホームアドレス宛先オプションで暗号化ホームアドレスフィールドからコピーされ、またはそのようなオプションがパケットに表示されない場合、未指定アドレスに設定しなければなりません。
When the correspondent node realizes that a Binding Cache entry is about to expire, it sends a Binding Refresh Request message to the real home address of the mobile node stored in the Binding Cache entry.
コレスポンデントノードが結合キャッシュ項目の有効期限が近づいていることを認識すると、それが結合キャッシュ項目に保存されているモバイルノードの実際のホームアドレスに結合更新要求メッセージを送信します。
With the solution in Section 5, the real home address is visible in the Binding Update and Binding Acknowledgement messages along the HA-CN path. Like Mobile IPv6 itself, it has not been designed to change the communications between the home network and the correspondent node; the same issues would affect non-mobile hosts as well. This solution meets all the requirements set forth for the location privacy solutions and provides a simple way to provide location privacy protection while allowing the use of the real home address with the correspondent node.
第5節でのソリューションを使用すると、実際のホームアドレスは、HA-CN経路に沿ったバインディング更新と結合確認メッセージに表示されます。モバイルIPv6自体と同様に、ホームネットワークとコレスポンデントノードとの間の通信を変更するように設計されていません。同じ問題は、非モバイルホストに影響を与えます。このソリューションは、位置プライバシー・ソリューションのために記載のすべての要件を満たし、コレスポンデントノードとの実際のホームアドレスの使用を可能にしながら、位置プライバシーの保護を提供するための簡単な方法を提供します。
When the mobile node attaches to a foreign link, it first performs the home binding update procedure for the real home address with the home agent, as specified in RFC 3775. For hiding the real home address, we require the use of IPsec Encapsulating Security Payload (ESP) [3] in tunnel mode. In order to provide location privacy, a non-null encryption transform must be used so that the real home address is encrypted and encapsulated, and made invisible to eavesdroppers on the MN-HA path. The packet formats and processing rules are the same as specified in RFC 3775 and RFC 4877.
モバイルノードが外部リンクに接続すると、それは最初のホームエージェントと実際のホームアドレスの更新手順を結合自宅を行い、実際のホームアドレスを隠すためにRFC 3775.に指定されているように、我々は、IPsecカプセル化セキュリティペイロードを使用する必要がトンネルモード（ESP）[3]。実際のホームアドレスを暗号化してカプセル化され、MN-HAパス上の盗聴者に見えなくなるように、ロケーションプライバシーを提供するためには、null以外の暗号化を使用する必要があります変換します。パケットフォーマットおよび処理ルールは、RFC 3775及びRFC 4877に指定されたと同じです。
To protect location privacy in the route optimization mode, the mobile node replaces the real home address used in certain signaling and payload packets with the pseudo home address. Different from the encrypted home address, the pseudo home address needs to be routable so that the home agent can intercept packets with the pseudo home address used as the destination address. The pseudo home address is generated by concatenating one of the home network prefixes with a random bit string. There are many ways to generate such a random bit string, for example, by using a random number generator or a secure encryption or hash algorithm.
ルート最適化モードで位置プライバシーを保護するために、モバイルノードは、疑似ホームアドレスを持つ特定のシグナリングとペイロードパケットで使用される実際のホームアドレスに置き換えられます。暗号化されたホームアドレスとは異なり、擬似ホームアドレスは、ホームエージェントは、宛先アドレスとして使用する疑似ホームアドレスにパケットを傍受できるように、ルーティング可能である必要があります。疑似ホームアドレスは、ランダムなビット列とのホームネットワーク接頭語のいずれかを連結することにより生成されます。例えば、乱数発生器または安全な暗号化またはハッシュアルゴリズムを使用して、ランダムビット列を生成するための多くの方法があります。
Using the pseudo home address instead of the real home address even in return routability and binding update to the correspondent has the following advantages. First, the pseudo home address does not reveal the identity of a mobile node since it is not (or should not be) publicly known. Hence, the signaling on the HA-CN is path is more secure since attackers will not be able to determine the identity of the mobile node based on the pseudo home address. Second, the mobile node can communicate with a correspondent without disclosing its real home address. Finally, the chosen pseudo home address can be different with different correspondents for both signaling and data traffic purposes.
でも、リターン・ルータビリティに代わり、実際のホームアドレスの疑似ホームアドレスを使用し、対応への更新を結合すると、次のような利点があります。それが公に知られていない（またはすべきではない）ので、まず、擬似ホームアドレスは、モバイルノードの身元を明らかにしていません。したがって、HA-CN上のシグナリングは、攻撃者が擬似ホーム・アドレスに基づいて、モバイルノードのアイデンティティを決定することができないので、パスがより安全です。第二に、モバイルノードは、その本当のホームアドレスを開示することなく対応と通信することができます。最後に、選択した擬似ホームアドレスは、シグナリングおよびデータトラフィックの両方の目的のために異なる特派と異なる場合があります。
The prefix used to form the pseudo home address MUST be managed by the same home agent so that it can forward the return routability messages. Even though it does not have to be the same as that used in the real home address, the prefix is highly recommended to be different. For instance, a home agent may use a different prefix pool for location privacy purposes for a set of mobile nodes. This ensures that the real home address and the pseudo home address are not co-related (assuming the mobile node chooses different interface identifiers (IIDs)).
それはリターン・ルータビリティ・メッセージを転送できるように、疑似ホームアドレスを形成するのに使用されるプレフィックスは、同じホームエージェントによって管理されなければなりません。それは本当のホームアドレスに使用されているものと同じである必要はありませんが、接頭辞は非常に異なっていることが推奨されます。例えば、ホームエージェントは、モバイルノードのセットのための場所のプライバシーのために、異なるプレフィックスプールを使用することができます。これは、（モバイルノードが異なるインタフェース識別子（のIID）を選択したと仮定して）実際のホームアドレスと擬似ホーム・アドレスを共関連していないことを保証します。
The mobile node MUST register the pseudo home address to be used with the home agent before actually using it with a correspondent node. To do so, the mobile node indicates a pseudo home address in the Pseudo Home Address mobility option in the Binding Update message sent to the home agent. If the home agent supports the location privacy solution, it performs the Duplicate Address Detection to detect whether this pseudo home address conflicts with other pseudo home addresses submitted from different mobile nodes. Based on the result, the home agent indicates whether to accept the pseudo home address by setting the appropriate status code in the Pseudo Home Address Acknowledgement option in the Binding Acknowledgement message. If the home agent prefers the use of a different home network prefix from that of the requested pseudo home address, the home agent returns the new pseudo home address in the Pseudo Home Address Acknowledgement mobility option to the mobile node.
モバイルノードは、実際には、通信相手ノードでそれを使用する前に、ホームエージェントで使用する疑似ホームアドレスを登録する必要があります。そうするために、モバイルノードは、ホームエージェントに送信されたバインディング更新メッセージで疑似ホームアドレスモビリティオプションで疑似ホームアドレスを示します。ホームエージェントが位置プライバシー・ソリューションをサポートしている場合、それは別の移動ノードから提出され、他の疑似ホームアドレスと、この疑似ホームアドレスの競合かどうかを検出するために、重複アドレス検出を実行します。その結果に基づいて、ホームエージェントはBinding Acknowledgementメッセージで疑似ホームアドレス謝辞オプションで適切なステータスコードを設定することにより、擬似ホームアドレスを受け入れるかどうかを示します。ホームエージェントは、要求された疑似ホームアドレスとは異なるホームネットワークプレフィックスを使用することを好む場合、ホームエージェントは、モバイルノードへの疑似ホームアドレスの受け付けモビリティオプションの新しい擬似ホームアドレスを返します。
The mobile node MAY register the pseudo home address when it is about to communicate with a correspondent node with location privacy protection. The default lifetime of registered pseudo home addresses is the same as the Home Binding Cache entry; however, a mobile node may choose any value and a home agent may grant any value. The mobile node can add or delete any pseudo home address by using the Pseudo Home Address mobility option in the home Binding Update message. The home agent does not have to recover the real home address from the pseudo home address.
場所のプライバシー保護とコレスポンデントノードと通信しようとするときに、モバイルノードは、疑似ホームアドレスを登録することもできます。登録済みの疑似ホームアドレスのデフォルトの寿命はホームBinding Cacheエントリーと同じです。しかし、モバイルノードは、任意の値を選択することができ、ホームエージェントは、任意の値を付与することができます。モバイルノードは、ホームBinding Updateメッセージでの疑似ホームアドレスモビリティオプションを使用して、任意の疑似ホームアドレスを追加または削除することができます。ホームエージェントは、疑似ホームアドレスから実際のホームアドレスを回復する必要はありません。
When the mobile node returns to its home link, the home de-registration procedure is the same as specified in RFC 3775, i.e., the real home address is used as the source IP address in the Binding
ときにモバイルノードに戻り、そのホーム・リンクに、ホーム登録解除手順は、RFC 3775で指定された、すなわち、実際のホームアドレスをバインディング内のソースIPアドレスとして使用されるものと同じです
Update message and the destination IP address in the Binding Acknowledgement message. The de-registration of the real home address results in automatic de-registration of all pseudo home addresses. When the mobile node decides to disconnect from the home agent while at its foreign link, the format of the Binding Update and Acknowledgement is the same as that defined for the home registration, except that the Lifetime field is set to zero. The home agent deletes the corresponding Binding Cache entry including the registered pseudo home address, if any.
メッセージとBinding Acknowledgementメッセージの宛先IPアドレスを更新します。すべての疑似ホームアドレスの自動登録解除の本当のホームアドレス結果の登録解除。モバイルノードが外部リンクにしながら、ホームエージェントから切断することを決定した場合、バインディング更新肯定応答の形式は、寿命フィールドはゼロに設定されていることを除いて、ホーム登録のために定義されたものと同じです。もしあれば、ホームエージェントは、登録された擬似的なホームアドレスを含む対応するバインディングキャッシュエントリを削除します。
The location privacy solution specified in this section does not introduce any change to the care-of address test procedure as specified in RFC 3775. In the following, we highlight the extensions to the home address test procedure, during which the mobile node obtains a home keygen token generated based on the pseudo home address.
以下では、RFC 3775.に指定されている気付アドレスの試験手順に変更を導入しない、このセクションで指定された場所のプライバシーのソリューションは、私たちは、モバイルノードがホームを取得する時にホーム・アドレス試験手順への拡張を、ハイライトkeygenの疑似ホームアドレスに基づいて生成されたトークン。
The mobile node generates and sends a Home Test Init message to the home agent. The format of this message is:
モバイルノードが生成し、ホームエージェントにホーム試験開始メッセージを送信します。このメッセージの形式は次のとおりです。
IPv6 header (source = care-of address, destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address, destination = correspondent)
Mobility Header (HoTI)
Home Init Cookie
Pseudo Home Address mobility option (pseudo home address)
The difference from what is specified in RFC 3775 is that the mobile node includes a Pseudo Home Address mobility option (see Section 7.3) in the Home Test Init message. A new option for carrying the pseudo home address is necessary because the security association between the mobile node and the home agent is based on the real home address. The pseudo home address contained in the Pseudo Home Address option is selected by the mobile node from a set of pseudo home addresses that have been registered with the home agent during the home registration procedure. Note that the Home Test Init message is protected by an IPsec security association in the ESP tunnel mode with a non-null encryption algorithm and a non-null authentication algorithm, as specified in RFC 3776.
RFC 3775で指定されているものとの違いは、モバイルノードがホーム試験開始メッセージで疑似ホームアドレスモビリティオプションを（7.3節を参照）が含まれていることです。モバイルノードとホームエージェント間のセキュリティアソシエーションは、実際のホームアドレスに基づいているため、疑似ホームアドレスを運ぶための新しいオプションが必要です。疑似ホームアドレスオプションに含まれる疑似ホームアドレスは、ホーム登録手順の間にホームエージェントに登録されている疑似ホームアドレスのセットから移動ノードが選択されています。 RFC 3776で指定されるようにホーム試験開始メッセージは、非ヌル暗号化アルゴリズムおよび非ヌル認証アルゴリズムとESPトンネルモードのIPsecセキュリティアソシエーションにより保護されていることに留意されたいです。
When receiving a Home Test Init message, the home agent performs the operation as specified in Section 6.6.4. If this operation succeeds when the Pseudo Home Address mobility option is present in the Home Test Init message, the home agent generates a Home Test Init message and forwards it to the correspondent node. As shown in the following, the pseudo home address carried in the Pseudo Home Address mobility option is used as the source IP address in the forwarded Home Test Init message.
ホーム試験開始メッセージを受信すると、ホームエージェントは、セクション6.6.4で指定された操作を実行します。疑似ホームアドレスモビリティオプションは、ホーム試験開始メッセージに存在しているときは、この操作が成功した場合、ホームエージェントはホーム試験開始メッセージを生成し、対応するノードに転送します。以下に示すように、疑似ホームアドレスモビリティオプションで運ば疑似ホームアドレスが転送さホーム試験開始メッセージの送信元IPアドレスとして使用されます。
IPv6 header (source = pseudo home address,
destination = correspondent)
Mobility Header (HoTI)
Home Init Cookie
The forwarded Home Test Init message looks the same to the correspondent node as what is specified in RFC 3775 and the correspondent node does not realize that the pseudo home address is used, and just generates a home keygen token using the same algorithm as specified in RFC 3775.
転送されたホーム試験開始メッセージは、RFC 3775で指定されているものとして、コレスポンデントノードに同じに見えるとコレスポンデントノードは、疑似ホームアドレスが使用されていることを認識し、ちょうどRFCで指定されたのと同じアルゴリズムを使用して、ホーム鍵生成トークンを生成しません。 3775。
home keygen token = First (64, HMAC_SHA1 (Kcn, (pseudo home address | nonce | 0)))
ホーム鍵生成トークン=最初の（64、HMAC_SHA1（Kcnを、（疑似ホームアドレス|ナンス| 0）））
The correspondent node then replies with a Home Test message. As shown in the following, the format of this message is the same as that specified in RFC 3776, and the pseudo home address is used as the destination IP address.
コレスポンデント・ノードは、ホームテストメッセージで応答します。以下に示すように、このメッセージのフォーマットは、RFC 3776で指定されたものと同じであり、擬似ホーム・アドレスを宛先IPアドレスとして使用されます。
IPv6 header (source = correspondent,
destination = pseudo home address)
Mobility Header (HoT)
Home Init Cookie
Home Keygen Token
Home Nonce Index
When the home agent intercepts the Home Test message using proxy Neighbor Discovery, it performs the operation as specified in Section 6.6.5. If this operation succeeds, the home agent generates the following Home Test message and forwards to the mobile node.
ホームエージェントは、プロキシ近隣探索を使用してホームテストメッセージをインターセプトすると、セクション6.6.5で指定されるように、それは操作を実行します。この操作が成功した場合、ホームエージェントは、モバイルノードに次のホームテストメッセージや転送を生成します。
IPv6 header (source = home agent, destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent, destination = home address)
Mobility Header (HoT)
Home Init Cookie
Home Keygen Token
Home Nonce Index
Pseudo Home Address Acknowledgement mobility option
(pseudo home address)
When the mobile node receives the Home Test message, it performs operation as specified in Section 6.5.5. If such operation succeeds, the mobile node obtains a home keygen token computed using the pseudo home address. After the care-of address test is completed, the mobile node hashes the care-of keygen token and the home keygen token together to generate Kbm using the same method as specified in RFC 3775.
モバイルノードがホームテストメッセージを受信した場合、セクション6.5.5で指定されるように、それが動作を行います。このような操作が成功した場合、モバイルノードは、疑似ホームアドレスを使用して計算ホーム鍵生成トークンを取得します。気付アドレスのテストが完了した後、モバイルノードは、RFC 3775で指定されたのと同じ方法を用いたKbmを生成するために一緒に気付キー生成トークン、ホームキー生成トークンをハッシュ。
In this procedure, the mobile node MUST use the same pseudo home address used during the home address test procedure. The pseudo home address is carried in the Home Address option in the correspondent Binding Update message.
この手順では、モバイルノードは、ホーム・アドレス・テスト手順中に使用されるのと同じ擬似ホーム・アドレスを使用しなければなりません。疑似ホームアドレスが通信員Binding Updateメッセージでのホームアドレスオプションで運ばれます。
IPv6 header (source = care-of address,
destination = correspondent)
Destination option header
Home Address destination option (pseudo home address)
Parameters:
sequence number (within the Binding Update message header)
home nonce index (within the Nonce Indices option)
care-of nonce index (within the Nonce Indices option)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BU)))
When the correspondent node receives the Binding Update message, it performs the same operation as specified in RFC 3775. If such operation succeeds and an acknowledgement is requested by the mobile node, the correspondent node replies with the following Binding Acknowledgement message.
コレスポンデント・ノードはBinding Updateメッセージを受信すると、それはそのような操作が成功した場合、RFC 3775.に指定と同様の操作を行い、肯定応答がモバイルノードによって要求され、コレスポンデント・ノードは、以下のバインディング確認メッセージで応答します。
IPv6 header (source = correspondent,
destination = care-of address)
Parameters:
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
After the mobile node receives the Binding Acknowledgement message indicating that the correspondent registration succeeds, the mobile node can now use the pseudo home address for communicating with the correspondent node.
モバイルノードは、コレスポンデント登録が成功したことを示すBinding Acknowledgementメッセージを受信した後、モバイルノードは現在、コレスポンデントノードと通信するための擬似ホーム・アドレスを使用することができます。
Such a Binding Update message may also be used by the mobile node to delete a previously established binding at the correspondent node. In this case, similar to what is specified in RFC 3775, Kbm is generated exclusively from the home keygen token that is based on the pseudo home address.
そのようなBinding Updateメッセージはまた、以前に確立された通信相手ノードでバインディングを削除するには、モバイルノードによって使用されてもよいです。この場合は、RFC 3775で指定されているものと同様、Kbmを疑似ホームアドレスに基づいてホーム鍵生成トークンから独占的に生成されます。
The mobile node may choose to use reverse tunneling for sending the Binding Update. The format of messages during such a procedure is similar to what is described in Sections 5 and 6.2.1, except that a pseudo home address is used in place of the real home address. The Encrypted Home Address destination and the Encrypted Home Address routing header SHOULD be used to carry the encrypted pseudo home address.
モバイルノードは、バインディングアップデートを送信するためのリバーストンネリングを使用することもできます。このような手順の間のメッセージのフォーマットは、疑似ホームアドレスが実際のホームアドレスの代わりに使用されていることを除いて、セクション5及び6.2.1に記述されているものと同様です。暗号化ホームアドレス宛先とルーティングヘッダ暗号化ホームアドレスは暗号化された擬似的なホームアドレスを運ぶために使用されるべきです。
6.2.4. Using Different Pseudo Home Addresses with Different Correspondent Nodes
6.2.4. 異なる対応ノードで異なる擬似ホームアドレスを使用して
Based on its configuration and policy, the mobile node can choose to use the same or different pseudo home addresses when communicating with different correspondent nodes. Using a different pseudo home address with each correspondent node may help prevent the mobile node's activities from being linked and correlated. To do so, the mobile node selects a different but already registered pseudo home address and repeats the return routability procedure and the correspondent binding update procedure with each correspondent node.
その設定とポリシーに基づいて、モバイルノードは、異なる通信相手ノードと通信するときに、同じまたは異なる疑似ホームアドレスを使用するように選択することができます。各コレスポンデントノードと異なる疑似ホームアドレスを使用すると、リンクと相関しているから、移動ノードの活動を防ぐのに役立つことがあります。そうするために、モバイルノードは異なるが、既に登録済みの疑似ホームアドレスを選択し、リターン・ルータビリティ手順及び各コレスポンデントノードとの対応バインディングアップデート手順を繰り返します。
In addition, if the mobile node prefers, it MAY use different pseudo home addresses for different sessions with the same correspondent node. This typically requires additional configuration at the mobile node that associates a specific session (for example, identified by the port number and the protocol number, among others) with a specific pseudo home address. This document does not address details of this solution.
モバイルノードが好む場合はさらに、それは同じコレスポンデントノードと異なるセッションごとに異なる疑似ホームアドレスを使用するかもしれません。これは、典型的には、特定の擬似ホーム・アドレスを（とりわけ、ポート番号、プロトコル番号によって識別される例えば、）特定のセッションを関連付け、モバイルノードに追加の構成を必要とします。この文書では、このソリューションの詳細は扱っていません。
The format of payload packets reverse-tunneled via the home agent is the same as that specified for the home address test procedure in Section 6.2.1.
ペイロードパケットのフォーマットは、逆トンネリングホームエージェントを経由して、セクション6.2.1におけるホーム・アドレス試験手順に指定したものと同じです。
When the route-optimized correspondent binding update procedure is performed, the format of payload packets exchanged between the mobile node and the correspondent node is the same as specified in RFC 3775. The operation of the mobile node when communicating with the correspondent node via the route optimization mode is described in Section 6.5.6.
RFC 3775.モバイルノードの操作で指定された経路を介して通信相手ノードと通信するときに、ルート最適化対応バインディング更新手順が実行されると、ペイロードパケットのフォーマットは、モバイルノードとコレスポンデントノードとの間で交換さは同じです最適化モードでは、セクション6.5.6に記載されています。
When the reverse tunneled correspondent binding update procedure is performed, the format of payload packets exchanged between the mobile node and the correspondent node is the same as specified in Section 5, except that the encrypted pseudo home address SHOULD be included in the Encrypted Home Address destination option and the Encrypted Home Address routing header.
逆更新手順が実行される結合相手をトンネリングするとき、ペイロードパケットのフォーマットは、モバイルノードとコレスポンデントノードとの間で交換は、暗号化された擬似ホーム・アドレスが暗号化ホームアドレス宛先に含まれるべきであることを除いて、セクション5で指定されたものと同じですオプションやルーティングヘッダ暗号化ホーム住所。
The solution to protect location privacy during the prefix discovery procedure is similar to that used during the home binding update procedure.
プレフィックス発見手順の間に位置プライバシーを保護するためのソリューションは、ホームバインディング更新手続きの際に使用されるものと同様です。
In this section, we describe the mobile node's operation when the location privacy solution is used.
このセクションでは、位置プライバシー溶液が使用されているモバイルノードの動作を説明します。
We introduce a new data structure, called Pseudo Home Address table, to record the information of pseudo home addresses. The mobile node may maintain a Pseudo Home Address table for each home agent it registers with. Each entry in the table contains a pseudo home address and its associated state, i.e., "unconfirmed" or "confirmed". The mobile node creates or updates entries in the Pseudo Home Address table when sending the home Binding Update message or receiving the home Binding Acknowledgement message. The pseudo home address can be used as a key to search the table. There MUST NOT be any duplicated pseudo home addresses stored in the Pseudo Home Address table.
私たちは、疑似ホームアドレスの情報を記録するために、疑似ホームアドレステーブルと呼ばれる新しいデータ構造を、ご紹介します。モバイルノードは、それはに登録されている各ホームエージェントのための疑似ホームアドレステーブルを維持することができます。テーブルの各エントリは、疑似ホームアドレスとそれに関連する状態が含まれている、すなわち、「未確認」または「確認しました」。 Binding Updateメッセージや確認メッセージをバインディング自宅を受け自宅を送信する際に、移動ノードは、疑似ホームアドレステーブルのエントリを作成または更新。疑似ホームアドレスがテーブルを検索するためのキーとして使用することができます。疑似ホームアドレステーブルに格納されている任意の重複擬似自宅の住所があってはなりません。
The Binding Update List entry is extended with a field, called Pseudo Home Address. This field MAY be implemented as a pointer that points to a corresponding entry in the Pseudo Home Address table. This pointer is initialized as NULL when the Binding Update List entry is created (for example, when the mobile node sends a Binding Update message or a Home Test Init message to the home agent). For the binding sent to a specific home agent, the Pseudo Home Address field points to the first entry in the Pseudo Home Address table (or NULL if the table is empty), so that the mobile node can access all the pseudo home addresses registered at this home agent; on the other hand, for the binding sent to a specific correspondent node, the Pseudo Home Address field points to the Pseudo Home Address table entry that contains the actual pseudo home address used with this correspondent node (or NULL if no pseudo home address is used with this correspondent node).
結合更新リストエントリは、疑似ホームアドレスと呼ばれるフィールド、と拡張されます。このフィールドは、疑似ホームアドレステーブル内の対応するエントリを指すポインタとして実装することができます。結合更新リストエントリが作成されるとき、このポインタはNULLとして初期化される（例えば、モバイルノードがBinding Updateメッセージやホームエージェントにホーム試験開始メッセージを送信した場合）。特定のホームエージェントに送信された結合のために、疑似ホームアドレステーブルの最初のエントリに疑似ホームアドレスフィールドポイント（またはNULL表が空の場合）、移動ノードがで登録されたすべての疑似ホームアドレスにアクセスできるように、このホームエージェント。一方、結合のための疑似ホームアドレスフィールドポイントは何の疑似ホームアドレスが使用されていない場合は、このコレスポンデントノード（またはNULLで使用される実際の疑似ホームアドレスが含まれている疑似ホームアドレステーブルエントリに、特定のコレスポンデントノードに送信されます）このコレスポンデントノードと。
The mobile node may decide to perform the home registration with location privacy protection, for example, when it attaches to a foreign link or when it needs to extend the lifetime of a registered home binding.
それが結合登録家庭の寿命を延長する必要があるとき、それは外部リンクに接続するとき、またはモバイルノードは、例えば、ロケーションプライバシー保護機能を備えたホーム登録を行うことを決定してもよいです。
Since IPsec tunnel mode is used, the mobile node MUST negotiate a non-null encryption algorithm (for example, during the bootstrapping) and use it to protect the home Binding Update message as specified in RFC 3775 and RFC 4877. In addition, the mobile node can register a pseudo home address as described above. If the mobile node does not wish to register the pseudo home address at this point, but wishes to discover whether the home agent supports the location privacy solution, the mobile node includes a Pseudo Home Address mobility option without the Pseudo Home Address field in the Binding Update message sent to the home agent.
IPsecトンネルモードを使用しているので、モバイルノードは、（ブートストラップ時など）、非ヌル暗号化アルゴリズムをネゴシエートする必要があり、モバイルは、また、RFC 3775及びRFC 4877.に指定されている家庭Binding Updateメッセージを保護するために使用します上記のように、ノードは、疑似ホームアドレスを登録することができます。モバイルノードが、この時点での擬似ホームアドレスを登録したいが、ホームエージェントは、位置プライバシー・ソリューションをサポートしているかどうかを発見することを希望しない場合は、モバイルノードは、バインディングで疑似ホームアドレスフィールドのない疑似ホームアドレスモビリティオプションを含んでいますホームエージェントに送信されたメッセージを更新します。
After sending the home de-registration binding update message, in addition to the operation specified in RFC 3775, the mobile node MUST stop using any data structure specific to the location privacy solution and MAY delete them after the Binding Acknowledgement message is processed successfully.
RFC 3775で指定された動作に加えて、ホーム登録解除バインディング更新メッセージを送信した後、モバイルノードは、ロケーションプライバシ溶液に固有のデータ構造の使用を停止しなければならないとBinding Acknowledgementメッセージが正常に処理された後にそれらを削除してもよいです。
With IPsec tunnel mode, the mobile node follows the rules specified in RFC 3775 and RFC 4877 to process the Binding Acknowledgement message.
IPsecトンネルモードでは、モバイルノードは、バインディング確認メッセージを処理するためにRFC 3775及びRFC 4877で指定された規則に従います。
In addition, if one or more Pseudo Home Address Acknowledgement mobility options are present in the Binding Acknowledgement message, the mobile node checks the Status field in each option. If the Status field in one option is 0 (Success), the pseudo home address, if not already present, is added into the Pseudo Home Address table, and the state of the corresponding entry is set to "confirmed".
また、一つ以上の疑似ホームアドレスの受け付けモビリティオプションはBinding Acknowledgementメッセージに存在している場合、モバイルノードは、各オプションにStatusフィールドをチェックします。 1つのオプションのStatusフィールドが0（成功）、疑似ホームアドレスである場合には、既に存在しない場合は、疑似ホームアドレステーブルに追加され、対応するエントリの状態を「確認」に設定されています。
Otherwise, the mobile node deletes any existing pseudo home address with the "unconfirmed" state (i.e., either an error code or no acknowledgement for such a pseudo home address is received) from the Pseudo Home Address table.
そうでない場合、モバイルノードは、擬似ホームアドレステーブルから「未確認」状態（即ち、エラーコードまたはホームアドレスを受信し、そのような擬似なしの確認応答のいずれか）を有する任意の既存の擬似ホーム・アドレスを削除します。
The mobile node considers that the home agent supports the location privacy solution, if a valid Pseudo Home Address Acknowledgement mobility option with or without a Pseudo Home Address field is received.
モバイルノードは、疑似ホームアドレスフィールドの有無にかかわらず、有効な疑似ホームアドレスの受け付けモビリティオプションを受信した場合、ホームエージェントは、ロケーションプライバシー・ソリューションをサポートしていることを考慮しています。
Note that the mobile node MUST determine whether the home registration succeeds or not based on what is specified RFC 3775.
モバイルノードがホーム登録が成功するか、RFC 3775に指定されているものに基づいていないかどうかを判断しなければならないことに注意してください。
To enable location privacy protection during communication with the correspondent node in the route optimization mode, the mobile node generates a Home Test Init message based on what is specified in RFC 3775 and RFC 3776. In addition, if the return routability procedure is for a new session with the correspondent node, the mobile node selects any pseudo home address from those already registered with the home agent and stored in the Pseudo Home Address table; otherwise, the mobile node must use the same pseudo home address as used with the same correspondent node before. The selected pseudo home address is carried in the Pseudo Home Address mobility option of the generated Home Test Init message. This Home Test Init message is protected by an IPsec security association with a non-null encryption algorithm.
ルート最適化モードでは、コレスポンデントノードとの通信中に位置プライバシー保護を有効にするには、モバイルノードは、リターン・ルータビリティ手順は、新規のためであれば、また、RFC 3775およびRFC 3776.に指定された内容に基づいて、ホーム試験開始メッセージを生成し、コレスポンデントノードとのセッションは、モバイルノードは、既にホームエージェントに登録し、疑似ホームアドレステーブルに保存されているものから任意の疑似ホームアドレスを選択します。前に同じ相手ノードで使用されるようなそうでない場合は、モバイルノードは、同じ疑似ホームアドレスを使用する必要があります。選択された疑似ホームアドレスを生成ホーム試験開始メッセージの疑似ホームアドレスモビリティオプションで運ばれます。このホーム試験開始メッセージがnull以外の暗号化アルゴリズムとのIPsecセキュリティアソシエーションにより保護されています。
After sending the Home Test Init message to the home agent, if there is no Binding Update List entry existing for the correspondent node, the mobile node creates one entry that points to the pseudo home address used; otherwise, the mobile node updates the existing entry.
コレスポンデントノードのために、既存のいかなる結合更新リストエントリが存在しない場合は、ホームエージェントにホーム試験開始メッセージを送信した後、モバイルノードが使用疑似ホームアドレスを指すつのエントリを作成します。そうでない場合は、モバイルノードは、既存のエントリを更新します。
When the mobile node receives a Home Test message from the home agent, it processes the packet based on processing rules specified in RFC 3775 and RFC 3776. If this is a valid packet and there is a Pseudo Home Address Acknowledgement option included, the mobile node examines the Status field inside this mobility option as follows:
モバイルノードがホームエージェントからホームテストメッセージを受信した場合、これは有効なパケットであると疑似ホームアドレスの確認応答オプションが含まれている場合、それは、RFC 3775およびRFC 3776.に指定された処理規則に基づいて、移動ノードのパケットを処理します次のように、このモビリティオプション内のStatusフィールドを調べます。
o If the Status field indicates that the home address test procedure using the pseudo home address succeeds (the Status field is 0), in addition to what is specified in RFC 3775, the mobile node prepares to use the pseudo home address carried in the Pseudo Home Address Acknowledgement option for the correspondent registration.
Statusフィールドは、疑似ホームアドレスを使用してホームアドレステスト手順は、RFC 3775で指定されているものに加えて、（Statusフィールドが0である）が成功したことを示している場合は、O、モバイルノードは、擬似で運ばれた疑似ホームアドレスを使用する準備します通信員登録のためのホームアドレス確認応答オプション。
o If the Status field indicates that the home address test procedure using the pseudo home address fails (the Status field is larger than 127), the mobile node can take steps to correct the cause of the error and retransmit the Home Test Init message, subject to the retransmission limit specified in RFC 3775. If this is not done or it fails, then the mobile node SHOULD record in its Binding Update List that the future home address test procedure SHOULD NOT use the pseudo home address with this correspondent node.
ステータスフィールドは、（Statusフィールドが127より大きい）擬似ホーム・アドレスを使用して、ホーム・アドレス試験手順が失敗したことを示す場合、O、モバイルノードは、エラーの原因を修正するためのステップを取るとホーム試験開始メッセージを再送信することができ、被写体これが行われていないか、それが失敗した場合、RFC 3775.に指定された再送限度に、移動ノードは、将来のホームアドレステスト手順は、このコレスポンデントノードとの疑似ホームアドレスを使用しないようにその結合更新リストに記録する必要があります。
After the mobile node completes the route-optimized correspondent registration procedure using the pseudo home address, payload packets are sent to the correspondent node with the pseudo home address in the Home Address destination option.
モバイルノードは、疑似ホームアドレスを使用してルート最適化通信員登録手続きを完了した後、ペイロードパケットは、ホームアドレス宛先オプションで疑似ホームアドレスとコレスポンデントノードに送信されます。
The packet processing rules when sending and receiving route-optimized packets are the same as in RFC 3775 except that pseudo home addresses are used. In addition, if encrypted pseudo home addresses are used, both the mobile node and the correspondent node need to replace the encrypted address with the pseudo home address before passing them to the upper layers.
送信及び経路最適化パケットをパケット受信処理規則が使用される擬似ホーム・アドレスを除いてRFC 3775と同じです。また、暗号化された擬似的なホームアドレスが使用されている場合は、モバイルノードとコレスポンデントノードの両方が上位層に渡す前に、擬似ホームアドレスと暗号化されたアドレスを交換する必要があります。
In the case that the mobile node masks the pseudo home address and uses the reverse-tunneled correspondent binding update procedure, the mobile node performs the operation specified in Section 5.3.4, except that the pseudo home address rather than the real home address is expected.
モバイルノードマスク擬似ホーム・アドレスとは、更新手順を結合リバーストンネリング対応を使用する場合には、モバイルノードは、擬似ホーム・アドレスではなく実際のホームアドレスが期待されていることを除いて、セクション5.3.4で指定された動作を行います。
When the Mobile Node receives a Binding Refresh Request message from a correspondent node, the destination IP address may be the pseudo home address. In this case, the mobile node needs to check the corresponding Binding Update List entry for the correspondent node. If the pseudo home address is invalid, the mobile node silently discards this message. Otherwise, the mobile node refreshes the binding with the correspondent node by using the same pseudo home address.
モバイルノードが通信相手ノードからバインディングリフレッシュ要求メッセージを受信すると、宛先IPアドレスは、擬似ホーム・アドレスであってもよいです。この場合、モバイルノードは、コレスポンデントノードに対応するバインディング更新リスト項目をチェックする必要があります。疑似ホームアドレスが無効の場合は、モバイルノードは静かにこのメッセージを破棄します。それ以外の場合は、モバイルノードは、同じ疑似ホームアドレスを使用して、通信相手ノードとの結合を更新します。
In this section, we describe the home agent's operation when the location privacy solution is used.
このセクションでは、位置プライバシー溶液が使用されているホームエージェントの操作を説明します。
The Binding Cache entry is extended with a field that points to a list of currently accepted pseudo home addresses. Note that each registered pseudo home address MUST be unique and all the registered pseudo home addresses SHOULD be organized in such a way that the associated Binding Cache entry can be quickly located when a pseudo home address is used as the key to look up the Binding Cache.
Binding Cacheエントリーは、現在受け入れられて疑似ホームアドレスのリストを指すフィールドで拡張されます。登録された各疑似ホームアドレスは一意である必要があり、登録済みのすべての疑似ホームアドレスは疑似ホームアドレスをバインディングキャッシュを検索するためのキーとして使用される場合に関連した結合キャッシュ項目を迅速に配置することができるように整理する必要があることに注意してください。
If the received Binding Update message contains one or more Pseudo Home Address mobility options, the home agent MUST ignore such an option if it does not recognize it. If the home agent recognizes such an option, a Pseudo Home Address Acknowledgement mobility option is generated and some fields therein are set as follows:
受信Binding Updateメッセージが1つまたは複数の疑似ホームアドレスモビリティオプションが含まれている場合、それはそれを認識しない場合、ホームエージェントは、このようなオプションを無視しなければなりません。ホームエージェントは、このようなオプションを認識すると、次のように、擬似ホームアドレス謝辞モビリティオプションが生成され、一部のフィールドは、そこに設定されます。
o If the Pseudo Home Address field received is empty, the Status field is set to 0 (Success), and the Pseudo Home Address field is empty.
受信疑似ホームアドレスフィールドが空の場合は、O、Statusフィールドは0（成功）に設定し、疑似ホームアドレスフィールドが空です。
o If the Pseudo Home Address field received is set to all zero, the Status field is set is 0 (Success), and a pseudo home address SHOULD be included in the Pseudo Home Address field, if the home agent supports the dynamic pseudo home address assignment; otherwise, the Status field is set to 132 (Dynamic pseudo home address assignment not available) and the Pseudo Home Address field is empty.
O受信疑似ホームアドレスフィールドは全てゼロに設定されている場合は、Statusフィールドが設定されている0（成功）で、ホームエージェントがダイナミック疑似ホームアドレスをサポートしている場合、擬似ホームアドレスは、疑似ホームアドレスフィールドに含まれるべきです割り当て;それ以外の場合は、Statusフィールドは、（ダイナミック疑似ホームアドレスの割り当ては利用できません）132に設定し、疑似ホームアドレスフィールドが空です。
o The Pseudo Home Address field received may contain an IPv6 address. If the format of such an IP address is incorrect, the Status field is set to 130 (Incorrect pseudo home address). If such an IP address is invalid, for example, the prefix is not a valid home network prefix or this is detected as a duplicated IP address, the Status field is set to 131 (Invalid pseudo home address). In both cases, the Pseudo Home Address field is empty. If the home agent suggests a different pseudo home address, the Status field is set to 0 (Success), and the new pseudo home address is included in the Pseudo Home Address field. Otherwise, if the home agent accepts the requested pseudo home address, the Status field is set as 0 (Success), and the same IP address is included in the Pseudo Home Address field.
O受信疑似ホームアドレスフィールドは、IPv6アドレスが含まれていてもよいです。 IPアドレスの形式が正しくない場合は、Statusフィールドは130（不正な疑似ホームアドレス）に設定されています。たとえば、IPアドレスが無効である場合には、例えば、接頭辞は、有効なホームネットワークプレフィックスではありませんか、これが重複IPアドレスとして検出され、Statusフィールドは、131（無効な疑似ホームアドレス）に設定されています。どちらの場合も、疑似ホームアドレスフィールドは空です。ホームエージェントが異なる疑似ホームアドレスを提案した場合、Statusフィールドは0（成功）に設定され、新しい擬似ホームアドレスは、疑似ホームアドレスフィールドに含まれています。ホームエージェントは、要求された疑似ホームアドレスを受け入れる場合それ以外の場合は、Statusフィールドは0（成功）として設定され、同じIPアドレスが疑似ホームアドレスフィールドに含まれています。
o If the home agent does not allow the mobile node to use the pseudo home address with the correspondent node, the Status field SHOULD be set as 129 (Administratively prohibited) and the Pseudo Home Address field is empty.
ホームエージェントは、モバイルノードは、コレスポンデントノードとの疑似ホームアドレスを使用することを許可しない場合は、O、Statusフィールドは129に設定してください（管理上禁止）と疑似ホームアドレスフィールドは空です。
o In case that the home agent does not accept the Pseudo Home Address mobility option for all other reasons, the Status field SHOULD be set as 128 (Failure, reason unspecified) and the Pseudo Home Address is empty.
Oホームエージェントは、すべての他の理由のための疑似ホームアドレスモビリティオプションを受け入れないこと場合は、Statusフィールドには、128（失敗、詳細不明の理由）として設定する必要があり、疑似ホームアドレスは空です。
When receiving a Binding Update message protected with the IPsec tunnel mode, the home agent performs the operation specified in RFC 4877.
IPsecトンネルモードで保護されたBinding Updateメッセージを受信した場合、ホームエージェントは、RFC 4877で指定された動作を行います。
When receiving and successfully processing a Binding Update message for de-registration from the mobile node, in addition to what is specified in RFC 3775, the home agent MUST delete data structures related to the location privacy extension.
受信に成功移動ノードから登録解除するためのBinding Updateメッセージを処理する場合、RFC 3775で指定されているものに加えて、ホームエージェントがロケーションプライバシ拡張に関連するデータ構造を削除する必要があります。
When sending a Binding Acknowledgement message protected with the IPsec tunnel mode, the home agent performs the operation specified in RFC 4877.
IPsecトンネルモードで保護Binding Acknowledgementメッセージを送信する場合、ホームエージェントは、RFC 4877で指定された動作を行います。
The processing rules related to the Pseudo Home Address Acknowledgement mobility option are described in Section 6.6.2.
疑似ホームアドレスの受け付けモビリティオプションに関連した処理ルールは、セクション6.6.2で説明されています。
When receiving a Home Test Init message from the mobile node, the home agent first verifies this message based on the IPsec processing rules as specified in RFC 3776. If the verification fails, the home agent acts based on such IPsec processing rules. Otherwise, if the Pseudo Home Address option does not exist in the Home Test Init message, the home agent performs the operation as specified in RFC 3775. Otherwise, the following operation is performed.
検証が失敗した場合は、モバイルノードからホーム試験開始メッセージを受信した場合RFC 3776.で指定されるように、ホーム・エージェントは、最初のIPsec処理規則に基づいて、このメッセージを検証し、ホームエージェントは、IPsec処理規則に基づいて作用します。疑似ホームアドレスオプションは、ホーム試験開始メッセージに存在しない場合はそれ以外の場合は、以下の操作が行われたRFC 3775.に指定されているそれ以外の場合は、ホームエージェントが動作を実行します。
1. The home agent looks up its Binding Cache by using the real home address as a key. If the pseudo home address carried in the Pseudo Home Address option does not match any pseudo home address associated with the corresponding Binding Cache entry (including when the Pseudo Home Address field is set as zero), it MUST reject the Home Test Init message by sending back a Home Test message including the Pseudo Home Address Acknowledgement option with the Status field set as 131 (Invalid pseudo home address).
1.ホームエージェントは、キーとして実際のホームアドレスを使用して、その結合キャッシュを検索します。疑似ホームアドレスオプションで運ば疑似ホームアドレスは、（疑似ホームアドレスフィールドはゼロに設定されている場合も含む）に対応するバインディングキャッシュエントリに関連付けられたすべての疑似ホームアドレスと一致しない場合は、送信することにより、ホーム試験開始メッセージを拒絶しなければなりません131（無効な疑似ホームアドレス）として設定Statusフィールドで疑似ホームアドレスの確認応答オプションなどのバックホームテストメッセージ。
2. Otherwise, the home agent constructs a Home Test Init message with the pseudo home address as the source IP address, and forwards the Home Test Init message to the correspondent node.
2.そうでない場合は、ホームエージェントは、送信元IPアドレスとして擬似ホームアドレスとホーム試験開始メッセージを構築し、コレスポンデントノードにホーム試験開始メッセージを転送します。
When the home agent intercepts a Home Test message using proxy Neighbor Discovery, if the destination IP address matches with one of the real home addresses, the home agent performs the operation as specified in RFC 3775. Otherwise, the home agent uses the destination IP address to look up the Binding Cache to find if there is a matched pseudo home addresses. If not, the home agent discards this message silently. When a matching pseudo home address is found, the home agent generates a Home Test message with a Pseudo Home Address Acknowledgement option and sends it to the mobile node. Inside the Pseudo Home Address Acknowledgement option, the Status field is set to zero (Success) and the Pseudo Home Address field is filled with the found pseudo home address.
ホームエージェントは、プロキシ近隣探索を使用してホームテストメッセージをインターセプトすると、宛先IPアドレスは、実際のホームアドレスのいずれかと一致する場合、それ以外の場合はRFC 3775.に指定されているように、ホームエージェントが動作を行い、ホームエージェントは、宛先IPアドレスを使用していますマッチした擬似的なホームアドレスがあるかどうかを見つけるためにバインディングキャッシュを検索します。ない場合は、ホームエージェントは静かにこのメッセージを破棄します。マッチング疑似ホームアドレスが発見された場合、ホームエージェントは、疑似ホームアドレスの確認応答オプションを指定してホームテストメッセージを生成し、モバイルノードに送信します。疑似ホームアドレスの確認応答オプションの内部では、Statusフィールドがゼロ（成功）に設定され、疑似ホームアドレスフィールドが見つかった疑似ホームアドレスで満たされています。
With the solution described in this section, when the correspondent node is involved in the route-optimized correspondent binding update procedure, there is no new operation if only pseudo home addresses are used without encryption. This specification recommends using encrypted pseudo home addresses to thwart revealing any prefix information about a mobile node. The additional operations are the same as specified in Section 5.5, except that the pseudo home address, instead of the real home address, is used.
コレスポンデントノードが経路最適化対応バインディング更新手続きに関与している場合にのみ擬似ホームアドレスを暗号化せずに使用されている場合は、このセクションで説明するソリューションを使用すると、新たな操作はありません。この仕様は、モバイルノードに関する任意のプレフィックス情報を明らかに阻止するために暗号化された擬似的なホームアドレスを使用することをお勧めします。追加の操作ではなく、実際のホームアドレスの疑似ホームアドレスは、使用されていることを除いて、5.5節で指定されたと同じです。
This section describes the experimental extensions to Mobile IPv6 used in this document. For experimentation purposes, the experimental IPv6 Option Type, the experimental IPv6 Routing Header Type, and the experimental Mobility Option Type as defined in RFC 4727 [12] and RFC 5096 [13] can be used in the Encrypted Home Address destination option, the Encrypted Home Address routing header, the Pseudo Home Address mobility option, and the Pseudo Home Address Acknowledgement mobility option. In the following, we describe the format of each extension for illustration purpose.
このセクションでは、このドキュメントで使用されているモバイルIPv6への実験的な拡張機能について説明します。実験目的のために、RFC 4727 [12]およびRFC 5096で定義されるような実験のIPv6オプションタイプ、実験的なIPv6ルーティングヘッダタイプ、および実験モビリティオプションタイプ[13]暗号化され、暗号化されたホームアドレス宛先オプションで使用することができますルーティングヘッダホームアドレス、疑似ホームアドレスモビリティオプション、および疑似ホームアドレスの受け付けモビリティオプション。以下では、説明の目的のために、各拡張のフォーマットを記述する。
This option is used in the Destination Option extension header (Next Header value = 60).
このオプションは、宛先オプション拡張ヘッダ（次ヘッダ値= 60）で使用されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
オプションタイプ
A type for identifying the use of the encrypted home address in this option. Implementations of this RFC can use the value 0xFE. This value is reserved in RFC 4727 for all experiments involving IPv6 destination options.
このオプションで暗号化されたホームアドレスの使用を識別するためのタイプ。このRFCの実装は価値0xFEのを使用することができます。この値は、IPv6宛先オプションを含むすべての実験のためにRFC 4727で予約されています。
Encrypted Home Address
暗号化ホーム住所
The encrypted home address generated from a either real or pseudo home address.
どちらか本当か疑似ホームアドレスから生成された暗号化ホームアドレス。
The processing of other fields in the Encrypted Home Address option is the same as that of those fields in the Home Address option described in RFC 3775. Note that if the Encrypted Home Address option is present in a packet, the encrypted home address therein MUST NOT be treated as the real source IP address by the receiver.
暗号化ホームアドレスオプション内の他のフィールドの処理はRFC 3775.ノートに記載ホームアドレスオプションでそれらのフィールドのものと同じである暗号化ホームアドレスオプションがパケットに存在している場合は、暗号化されたホームアドレスが、その中にはならないこと受信機による実際の送信元IPアドレスとして扱われます。
The encrypted home address is carried in this routing header.
暗号化されたホームアドレスは、このルーティングヘッダで運ばれます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 | Routing Type |Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Routing Type
ルーティングタイプ
A type for identifying the use of the encrypted home address in this option. Implementations of this RFC can use the value 0xFE. This value is reserved in RFC 4727 for all experiments involving IPv6 routing header.
このオプションで暗号化されたホームアドレスの使用を識別するためのタイプ。このRFCの実装は価値0xFEのを使用することができます。この値は、IPv6ルーティングヘッダを含む全ての実験は、RFC 4727に貯留されています。
Encrypted Home Address
暗号化ホーム住所
The encrypted home address generated from a either real or pseudo home address.
どちらか本当か疑似ホームアドレスから生成された暗号化ホームアドレス。
The processing of other fields in the Encrypted Home Address routing header is the same as described in RFC 3775. Note that if this routing header is present in a packet, the encrypted home address therein MUST NOT be treated as the real destination IP address by the receiver.
RFCに記載されるように暗号化されたホームアドレスルーティングヘッダ内の他のフィールドの処理は同じである3775.このルーティングヘッダがパケットに存在している場合、暗号化されたホームアドレスがその中により実際の送信先IPアドレスとして扱われてはならないことを注意受信機。
This mobility option is included in the mobility header, including the Binding Update message and the Home Test Init message, and carries zero or one pseudo home address. The alignment requirement for this option is 4n.
このモビリティオプションはBinding Updateメッセージとホーム試験開始メッセージを含む、モビリティヘッダに含まれ、かつ0または1擬似ホーム・アドレスを搬送されます。このオプションのアライメント要件は4Nです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |A| Reserved | Prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
A unique type (together with the 'A' bit in the Reserved field) for identifying the Pseudo Home Address Acknowledgement mobility option. For experimental purpose, the value of this type is 18 as reserved in RFC 5096.
ユニークなタイプ疑似ホームアドレスの受け付けモビリティオプションを特定するための（一緒に予約済みフィールドの「」ビットを持ちます）。 RFC 5096に貯留されている実験目的のために、このタイプの値は18です。
Length
長さ
The length of the Pseudo Home Address mobility option excluding the Type field and the Length field. It MUST be 2 when the Pseudo Home Address field is not present; otherwise, it MUST be 18.
TypeフィールドとLengthフィールドを除く疑似ホームアドレスモビリティオプションの長さ。疑似ホームアドレスフィールドが存在しない場合には2でなければなりません。それ以外の場合は18でなければなりません。
Reserved Field
予約フィールド
The 'A' bit, which MUST be set to zero to indicate that this is a Pseudo Home Address mobility option. The rest of bits MUST be set as zero by the sender and ignored by the receiver.
これは疑似ホームアドレスモビリティオプションであることを示すためにゼロに設定しなければならない「」ビット、。残りのビットは送信者によってゼロに設定し、受信側で無視しなければなりません。
Prefix Length
プレフィックス長
The length of the home network prefix of the included pseudo home address. When the Pseudo Home Address field is not present, the Prefix Length field MUST be set as zero.
付属疑似ホームアドレスのホームネットワークプレフィックスの長さ。疑似ホームアドレスフィールドが存在しない場合は、プレフィックス長フィールドはゼロとして設定しなければなりません。
Pseudo Home Address
疑似ホームアドレス
If present, the field contains a pseudo home address that the mobile node wants to use for location privacy protection or zero if the mobile node requests a pseudo home address from the home agent. This field is not present if the mobile node only intends to discover whether the home agent supports the location privacy solutions. The Length field is used to detect whether the Pseudo Home Address field is present in the Pseudo Home Address mobility option.
存在する場合、フィールドは、モバイルノードは、モバイルノードがホームエージェントからの疑似ホームアドレスを要求した場合、ロケーションプライバシー保護またはゼロのために使用したい疑似ホームアドレスが含まれています。モバイルノードが唯一のホームエージェントが位置プライバシー・ソリューションをサポートしているかどうかを発見しようとする場合、このフィールドは存在しません。 Lengthフィールドは、疑似ホームアドレスフィールドは疑似ホームアドレスモビリティオプションに存在しているかどうかを検出するために使用されます。
This mobility option is included in the mobility header, including the Binding Acknowledgement message and the Home Test message sent to the mobile node, and carries zero or one pseudo home address. This mobility option is used to indicate the status of the pseudo home address registration and/or whether the home agent supports the location privacy solutions. The alignment requirement for this option is 2n.
このモビリティオプションはBinding Acknowledgementメッセージとモバイルノードに送信されるホームテストメッセージを含む、モビリティヘッダに含まれ、かつ0または1擬似ホーム・アドレスを搬送されます。このモビリティオプションは、疑似ホームアドレスの登録および/またはホームエージェントが位置プライバシー・ソリューションをサポートしているかどうかの状態を示すために使用されます。このオプションのアライメント要件は2Nです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | Prefix length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
A unique type (together with the 'A' bit in the Reserved field) for identifying the Pseudo Home Address Acknowledgement mobility option. For experimental purpose, the value of this type is 18 as reserved in RFC 5096.
ユニークなタイプ疑似ホームアドレスの受け付けモビリティオプションを特定するための（一緒に予約済みフィールドの「」ビットを持ちます）。 RFC 5096に貯留されている実験目的のために、このタイプの値は18です。
Length
長さ
The length of the Pseudo Home Address Acknowledgement mobility option excluding the Type field and the Length field. It MUST be 4 when the Pseudo Home Address field is not present; otherwise, it MUST be 20.
擬似ホームの長さは、TypeフィールドとLengthフィールドを除く謝辞モビリティオプションアドレス。疑似ホームアドレスフィールドが存在しない場合には4でなければなりません。それ以外の場合は20でなければなりません。
Reserved
予約済み
The 'A' bit, which MUST be set to one to indicate that this is a Pseudo Home Address Acknowledgement mobility option. The rest of bits MUST be set as zero by the sender and ignored by the receiver.
1に設定しなければならない「」ビットは、これが疑似ホームアドレスの受け付けモビリティオプションであることを示します。残りのビットは送信者によってゼロに設定し、受信側で無視しなければなりません。
Prefix Length
プレフィックス長
The length of the home network prefix of the included pseudo home address. When the Pseudo Home Address field is not present, the Prefix Length MUST be set as zero.
付属疑似ホームアドレスのホームネットワークプレフィックスの長さ。疑似ホームアドレスフィールドが存在しない場合は、プレフィックス長はゼロとして設定しなければなりません。
Status
状態
It indicates the status of the pseudo home address registration. Values from 0 to 127 indicate success. Higher values indicate failure. The following values are reserved:
それは、疑似ホームアドレス登録の状態を示します。 0から127までの値は、成功を示します。より高い値は失敗を示しています。次の値が予約されています：
0 Success
128 Failure, reason unspecified
129 Administratively prohibited
130 Incorrect pseudo home address
131 Invalid pseudo home address
132 Dynamic pseudo home address assignment not available
Reserved
予約済み
This field is reserved for future use. It MUST be set to zero by the sender and ignored by the receiver.
このフィールドは、将来の使用のために予約されています。これは、送信者によってゼロに設定し、受信機で無視しなければなりません。
Pseudo Home Address
疑似ホームアドレス
If present, the field contains a pseudo home address that the home agent registers for the mobile node to use for location privacy protection. This field is not present when the home agent only needs to indicate that it supports the location privacy solutions as a response to the query from the mobile node. The Length field is used to detect whether the Pseudo Home Address field is present in the Pseudo Home Address Acknowledgement mobility option.
存在する場合、フィールドは、モバイルノードが位置プライバシー保護のために使用するためにホームエージェントが登録疑似ホームアドレスが含まれています。ホームエージェントは唯一それがモバイルノードからのクエリに対する応答として位置プライバシー・ソリューションをサポートしていることを示す必要がある場合、このフィールドは存在しません。 Lengthフィールドは、疑似ホームアドレスフィールドは疑似ホームアドレスの受け付けモビリティオプションに存在しているかどうかを検出するために使用されます。
The solutions proposed in this document address one of the security issues in the mobile environment, i.e., location privacy. Throughout the document, we provide a detailed analysis of how the proposed solutions address the location privacy problem. We carefully design such solutions to make sure that they fit well into the Mobile IPv6 framework; therefore, the same threat analysis, security mechanisms (such as IPsec, the sequence number in binding signaling messages, the return routability procedure), and considerations as described in RFC 3775 still apply. Nevertheless, in the following we provide an in-depth analysis on security threats involving the use of the location privacy solutions and demonstrate that the proposed solutions do not introduce any new vulnerability or weaken the strength of security protection of the original Mobile IPv6 protocol.
ソリューションは、この文書アドレス、モバイル環境でのセキュリティ問題の1、すなわち、位置プライバシーに提案しました。ドキュメントでは、我々は提案されたソリューションは、ロケーションプライバシーの問題に対処する方法の詳細な分析を提供しています。我々は慎重に、彼らはモバイルIPv6フレームワークにうまく適合していることを確認するために、このようなソリューションを設計します。従って、同一の脅威分析、セキュリティ機構（IPsecなどは、シグナリングメッセージ、リターン・ルータビリティ手順結合におけるシーケンス番号）RFC 3775に記載されているように、および考慮事項が適用されます。それにもかかわらず、以下に私たちは、位置プライバシー・ソリューションの使用を伴うセキュリティ上の脅威に関する詳細な分析を提供し、提案されたソリューションは、すべての新しい脆弱性を導入したり、元のモバイルIPv6プロトコルのセキュリティ保護の強度を弱めていないことを示しています。
Given the strong security of the cryptography algorithm used to generate the encrypted home address, eavesdroppers are unable to derive the real home address from the encrypted home address and thus to correlate the care-of address with the real home address. Moreover, the encrypted home address can be updated to prevent eavesdroppers from linking the mobile node's ongoing activities.
暗号化されたホームアドレスを生成するために使用される暗号化アルゴリズムの強力なセキュリティを考えると、盗聴者は、暗号化されたホームアドレスから実際のホームアドレスを導出するため、実際のホームアドレスと気付アドレスを関連付けることはできません。また、暗号化されたホームアドレスは、モバイルノードの継続的な活動をリンクから盗聴を防ぐために更新することができます。
During the pseudo home address registration, the home agent verifies that the requested pseudo home address is not in use by other mobile nodes; therefore, the other mobile node cannot, inadvertently or maliciously, intercept ongoing sessions of a victim mobile node by registering the same pseudo home address.
疑似ホームアドレス登録時に、ホームエージェントは、要求された擬似的なホームアドレスは、他のモバイルノードによって使用されていないことを確認します。そのため、他のモバイルノードは、不注意または悪意を持って、同じ疑似ホームアドレスを登録することにより、被害者の移動ノードの進行中のセッションを傍受することはできません。
A mobile node may attempt to register a large number of pseudo home addresses that may exhaust the pool of available pseudo home addresses and prevent other mobile nodes using location privacy protection. The home agent MUST limit the number of pseudo home addresses that can be requested by a mobile node. Also, with the IPsec security association between the home agent and the mobile node, if any misuse of the pseudo home address registration is detected, the home agent can identify the malicious mobile node and take further actions.
モバイルノードは、利用可能な擬似ホーム・アドレスのプールを排気し、位置プライバシー保護を使用して、他の移動ノードを防止することができる擬似ホーム・アドレスの多数を登録しようと試みることができます。ホームエージェントは、モバイルノードによって要求することができる擬似ホームアドレスの数を制限しなければなりません。疑似ホームアドレス登録の誤用が検出された場合も、ホームエージェントとモバイルノード間のIPsecセキュリティアソシエーションで、ホームエージェントは、悪質なモバイル・ノードを識別し、さらに行動を取ることができます。
The return routability procedure using the pseudo home address follows the same principle of the original return routability procedure, i.e., the message exchange verifies that the mobile node is reachable at both the pseudo home address and the care-of address (this is because the pseudo home address is required to be routable). Furthermore, the extended return routability procedure also utilizes the same security mechanisms as defined in RFC 3775, such as the nonce, the node key, and the sequence number, to protect against attacks. Overall, it provides the same security strength as the original return routability procedure.
疑似ホームアドレスを使用して、帰路経路手順、すなわち、元のリターン・ルータビリティ手順の同じ原理を、以下の、メッセージ交換は、モバイルノードが擬似ホームアドレスと気付アドレス（これは疑似ための両方で到達可能であることを確認しますホームアドレス）がルーティング可能であることが必要です。攻撃から保護するために、そのようなノンス、ノードのキー、およびシーケンス番号として、RFC 3775で定義されるようにさらに、拡張リターン・ルータビリティ手順は、同じセキュリティ・メカニズムを利用します。全体的に、それは本来のリターンルータビリティ手順と同じセキュリティ強度を提供します。
The reverse-tunneled correspondent binding update procedure does not weaken security either. Although the real home address is transferred in cleartext on the HA-CN path, eavesdroppers on this path can already perform more serious attacks against the mobile node with the Mobile IPv6 protocol.
リバーストンネリング対応結合更新手順は、いずれかのセキュリティを弱めていません。実際のホームアドレスはHA-CNパス上に平文で転送されますが、このパス上の盗聴者は、既にモバイルIPv6プロトコルとモバイルノードに対して、より深刻な攻撃を行うことができます。
Using the Encrypted Home Address option in route-optimized packets results in the same security implications when the Home Address option is used in such packets. For example, the Encrypted Home Address option may be used by attackers to launch reflection attacks, e.g., by indicating the IP address of a victim node in the Encrypted Home Address option. Similar to the processing rule for the Home Address option specified in RFC 3775, this document restricts the use of the Encrypted Home Address option: it can be used only if there is an established Binding Cache entry containing the encrypted (pseudo) home address.
ホームアドレスオプションは、このようなパケットで使用されたときに経路最適化パケットで暗号化されたホームアドレスオプションを使用すると、同じセキュリティへの影響につながります。例えば、暗号化されたホームアドレスオプションは、暗号化されたホームアドレスオプションで犠牲者ノードのIPアドレスを示すことによって、例えば、反射攻撃を開始するために、攻撃者が使用することができます。 RFC 3775で指定されたホームアドレスオプションのための処理規則と同様に、この文書は暗号化されたホームアドレスオプションの使用を制限：暗号化された（擬似）ホームアドレスを含む確立バインディングキャッシュエントリが存在する場合にのみ使用することができます。
With the proposed location privacy solutions, the Encrypted Home Address routing header is used to carry the encrypted (pseudo) home address. The same threats specified in RFC 3775 for the Type 2 routing header are also possible when the routing header carries the encrypted (pseudo) home address. Similar processing rules are also used in this document to address such a threat: if the encrypted (pseudo) home address in the Encrypted Home Address routing header does not match with that stored in the Binding Update List entry, the packet will be dropped.
提案された位置プライバシーソリューションにより、暗号化ホームアドレスのルーティングヘッダは暗号化された（擬似）ホームアドレスを運ぶために使用されます。ルーティングヘッダは暗号化された（擬似）ホーム・アドレスを搬送する際にタイプ2ルーティングヘッダは、RFC 3775で指定された同じ脅威も可能です。同様の処理規則はまた、このような脅威に対処するため、このドキュメントで使用されています。暗号化ホームアドレスルーティングヘッダ内の暗号化された（擬似）ホームアドレスが結合更新リストエントリに記憶されているものと一致しない場合、パケットはドロップされます。
Our work benefits from previous work and discussion on this topic. Similar to the concept of the pseudo home address, many documents have proposed using a temporary identity to replace the mobile node's home address in the IPsec security association, Mobile IPv6 signaling messages, and data packets. However, the details of how to generate and update this identity are absent. In the following, we provide a survey of related work.
前作とこの話題についての議論から、私たちの仕事のメリット。疑似ホームアドレスの概念と同様に、多くの文書は、IPsecセキュリティアソシエーション、モバイルIPv6シグナリングメッセージ、およびデータパケット内のモバイルノードのホームアドレスを交換するために、一時的なアイデンティティを使用して提案しました。しかし、このIDを生成し、更新する方法の詳細は存在しません。以下では、関連研究の調査を提供しています。
RFC 4941 [10] specifies a mechanism to generate randomized interface identifiers, which can be used to update the care-of address and the home address. However, with our solution, the prefix of a pseudo home address can be different from that of the real home address and other pseudo home addresses, which prevents eavesdroppers from correlating and analyzing IP traffic based on a common prefix. Furthermore, we also discuss the interval of IP address update in the mobility scenario in order to resist the profiling attack both effectively and efficiently.
RFC 4941 [10]アドレスの気付とホームアドレスを更新するために使用することができるランダムインタフェース識別子を生成するためのメカニズムを、指定します。しかし、私たちのソリューションで、擬似的なホームアドレスのプレフィックスが相関すると、共通のプレフィックスに基づいてIPトラフィックを分析することから、盗聴を防止し、実際のホームアドレスと他の疑似ホームアドレス、のそれとは異なる場合があります。さらに、我々はまた、両方の効果的かつ効率的にプロファイリング攻撃に抵抗するために、モビリティシナリオにおけるIPアドレス更新の間隔を議論します。
In [16], the authors propose using a temporary identity, called the Temporary Mobile Identifier (TMI), to replace the home address, and discussed the feasibility of utilizing the Crypto-Based Identifier (CBID), Cryptographically Generated Addresses (CGA), or Mobility Anchor Point (MAP) to further protect location privacy. However, as a 128-bit random number, the TMI is not routable; therefore, it is not suitable to be the source IP address in the Home Test Init message forwarded by the home agent to the correspondent node. Otherwise, the home agent cannot receive the Home Test message from the correspondent node. Furthermore, the document does not specify how to update the TMI to address the profiling attack.
[16]では、著者は一時的なアイデンティティを使用して提案する、ホームアドレスを交換するために、一時的モバイル識別子（TMI）と呼ばれ、暗号ベースの識別子（CBID）、暗号的に生成されたアドレス（CGA）を利用の実現可能性を検討し、またはモビリティアンカーポイント（MAP）は、場所のプライバシーを保護します。しかし、128ビットの乱数として、TMIはルーティング可能ではありません。したがって、相手ノードにホームエージェントによって転送ホーム試験開始メッセージの送信元のIPアドレスが適当ではありません。それ以外の場合は、ホームエージェントは、コレスポンデントノードからホームテストメッセージを受信することはできません。さらに、ドキュメントは、プロファイリングの攻撃に対処するためにTMIを更新する方法を指定しません。
In [14], the authors propose a mechanism that uses an identity as the home address and periodically updates such an identity by using a key and a previous identity as inputs to a cryptography algorithm.
[14]において、著者らは、ホームアドレスとしてIDを使用し、定期的に鍵と暗号化アルゴリズムへの入力として前のアイデンティティを使用して、このような識別情報を更新するメカニズムを提案します。
In [15], the authors propose to update the mobile node's home address periodically to hide its movement. The new home address is generated from the current local network prefix, the Binding Update session key, and the previous home address, and updated every time when the return routability procedure is performed. The generated home address is random, routable, recognizable, and recoverable.
[15]では、著者はその動きを隠すために、定期的に、モバイルノードのホームアドレスを更新することを提案します。新しいホームアドレスは、現在のローカルネットワークプレフィックス、バインディング更新セッションキー、および以前のホームアドレスから生成され、リターン・ルータビリティ手順が実行されるたびに更新されます。生成されたホームアドレスは、ランダムにルーティング可能な、認識、および回復可能です。
In [18], the authors propose a mechanism to achieve both route optimization and location privacy at the same time. This is done by discovering a tunneling agent near the correspondent node and bidirectionally tunneling data traffic between the mobile node and the tunneling agent.
[18]において、著者らは、同時に両方のルート最適化とロケーション・プライバシーを達成するためのメカニズムを提案します。これは、コレスポンデントノードの近くにトンネリング・エージェントを発見し、双方向モバイルノードとトンネリングエージェント間のデータトラフィックをトンネリングすることによって行われます。
This document creates a new registry "Pseudo Home Address Acknowledgement Status Codes" for the Status field in the Pseudo Home Address Acknowledgement mobility option. The current values are described in Section 7.4 and are the following:
この文書では、疑似ホームアドレスの受け付けモビリティオプションのStatusフィールドに「疑似ホーム応答ステータスコードをアドレス」新しいレジストリを作成します。電流値は、7.4節に記載されており、以下の通りです。
0 Success
0成功
128 Failure, reason unspecified
128失敗、詳細不明の理由
129 Administratively prohibited
管理上禁止さ129
130 Incorrect pseudo home address
130の不正な疑似ホームアドレス
131 Invalid pseudo home address
131の無効な疑似ホームアドレス
132 Dynamic pseudo home address assignment not available
利用できない132ダイナミック疑似ホームアドレスの割り当て
In this document, we have proposed solutions to address location privacy issues in the context of mobility. The main idea is to hide the binding between the home address and the care-of address from eavesdroppers and the correspondent node. We have described two methods. The first method extends the return routability to hide the real home address in Binding Update and data packets. This method uses the real home address in return routability signaling, and does not require any changes to the home agent. The second method uses pseudo home addresses starting from return routability signaling, and requires some extensions to the home agent operation. This method protects revealing the real home address on the HA-CN path. The two methods provide a means to hide the real home address from eavesdroppers, and the second method can also hide it from the correspondents.
この文書では、我々は、移動性の文脈におけるロケーションプライバシーの問題に対処するためのソリューションを提案してきました。主なアイデアは、ホームアドレスと気付アドレス盗聴からとコレスポンデントノードとの間の結合を非表示にすることです。我々は2つの方法を記載しています。第一の方法は、更新およびデータパケットを結合する際に、実際のホームアドレスを非表示にするには、リターン・ルータビリティを拡張します。この方法では、リターン・ルータビリティ・シグナリングにおける実際のホームアドレスを使用し、ホームエージェントを変更する必要はありません。第二の方法は、リターン・ルータビリティ・シグナリングから始まる疑似ホームアドレスを使用し、ホームエージェントの動作にいくつかの拡張が必要です。この方法は、HA-CNパス上の実際のホームアドレスを明らかに保護します。二つの方法は、盗聴者から実際のホームアドレスを非表示にする手段を提供し、そして第二の方法はまた、特派からそれを隠すことができます。
The solutions we have proposed are for the basic Mobile IPv6 protocol as specified in RFC 3775. Recently, many extensions to Mobile IPv6 have been proposed, such as the NEMO Basic Support protocol [19], Dual Stack Mobile IPv6 Support [20], Multiple Care-of Addresses Registration [21], Binding Revocation [22], Generic Signaling Message [23]. It is expected that the proposed location privacy solutions can be applied with some modifications, if needed, to address location privacy issues when these extensions are used. One of our future works is to clarify related issues, if any, when the location privacy solutions are used with new Mobile IPv6 extensions.
我々が提案した解決策は最近、モバイルIPv6への多くの拡張は、NEMOベーシックサポートプロトコル[19]、デュアルスタックモバイルIPv6サポート[20]、複数として、提案されているRFC 3775.に指定されている基本的なモバイルIPv6プロトコルのためにされています気付アドレスの登録[21]、失効結合[22]、一般的なシグナリングメッセージ[23]。これらの拡張機能が使用された場合、ロケーションプライバシーの問題に対処するために、必要に応じて提案された位置プライバシーソリューションは、いくつかの変更を適用することができると予想されます。私たちの今後の課題の一つは、場所のプライバシーソリューションは、新たなモバイルIPv6の拡張機能で使用されている場合、もしあれば、関連する問題を明らかにすることです。
The authors would like to thank the co-authors of previous documents from which this document is derived: Vijay Devarapalli, Hannu Flinck, Charlie Perkins, Feng Bao, Robert Deng, James Kempf, and Jianying Zhou. In addition, sincere appreciation is also extended to Claude Castelluccia, Francis Dupont, Gabriel Montenegro, Greg Daley, Kilian Weniger, Takashi Aramaki, Wassim Haddad, Heejin Jang, and Michael Welzl for their valuable contributions, review, and discussion. Work by Fan Zhao was done while he was at University of California, Davis and Marvell Semiconductor, Inc.
ビジェイDevarapalli、ハンヌ・フリンク、チャーリー・パーキンス、風水バオ、ロバート・鄧小平、ジェームズケンプ、およびJianying周：著者は、この文書が由来する前の文書の共著者に感謝したいと思います。また、心からの感謝も彼らの貴重な貢献、レビュー、およびディスカッションのためのクロード・カステルッシア、フランシスデュポン、ガブリエルモンテネグロ、グレッグ・デイリー、キリアンWeniger、隆荒巻ワッシムハダッド、Heejinチャン、そしてマイケル・Welzlに拡張されます。彼はカリフォルニア大学デイビスとマーベルセミコンダクター社であったファン趙によって作業が行われていました
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[2]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[3] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[3]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[4]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[6]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[7] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[7] Arkko、J.、Devarapalli、V.、およびF.デュポン、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、RFC 3776、2004年6月を。
[8] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.
[8] Devarapalli、V.とF.デュポン、RFC 4877、2007年4月 "のIKEv2および改訂されたIPsecアーキテクチャとのモバイルIPv6の操作"。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[9] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[10] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[10] Narten氏、T.、Draves、R.、およびS.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[11] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", RFC 4882, March 2007.
[11] Koodli、R.、 "IPアドレス所在地プライバシーとモバイルIPv6：問題文"、RFC 4882、2007年3月。
[12] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[12]フェナー、B.、RFC 4727、2006年11月 "のIPv4、IPv6の、ICMPv4の、ICMPv6の、UDP、およびTCPヘッダーで実験値"。
[13] Devarapalli, V., "Mobile IPv6 Experimental Messages", RFC 5096, December 2007.
[13] devarapalli、VEの。、 "20モバイル6に実験的メッセージ"、rphak 5096、2007年12月。
[14] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6", Work in Progress, March 2005.
[14]バオ、F.、トウ、R.、ケンプ、J.、秋、Y.、およびJ.周、 "モバイルIPv6におけるモバイルノードの移動を保護するためのプロトコル"、進歩、2005年3月に働いています。
[15] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol for Hiding Movement of Mobile Nodes in Mobile IPv6", Work in Progress, March 2005.
[15]バオ、F.、トウ、R.、ケンプ、J.、秋、Y.、およびJ.周、 "モバイルIPv6におけるモバイルノードの移動を隠すためのプロトコル"、進歩、2005年3月に働いています。
[16] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple Privacy Extension for Mobile IPv6", Work in Progress, July 2006.
[16]カステルッシア、C.、デュポン、F.、およびG.モンテネグロ、 "モバイルIPv6のための簡単なプライバシー拡張"、進歩、2006年7月での作業。
[17] Daley, G., "Location Privacy and Mobile IPv6", Work in Progress, January 2004.
[17]デイリー、G.、 "場所のプライバシーとモバイルIPv6"、進歩、2004年1月での作業。
[18] Weniger, K. and T. Aramaki, "Route Optimization and Location Privacy using Tunneling Agents (ROTA)", Work in Progress, October 2005.
[18] Weniger、K.およびT.荒巻、 "トンネルエージェントを使用してルート最適化とロケーションプライバシ（ROTA）"、進歩、2005年10月に作業。
[19] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[19] Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP. Thubert、 "ネットワークモビリティ（NEMO）基本サポートプロトコル"、RFC 3963、2005年1月。
[20] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[20] "デュアルスタックホストとルータのためのモバイルIPv6のサポート" ソリマン、H.、RFC 5555、2009年6月。
[21] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009.
[21] Wakikawa、R.、Devarapalli、V.、Tsirtsis、G.、エルンスト、T.、およびK.永見を、 "複数の気付アドレスの登録"、RFC 5648、2009年10月。
[22] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", Work in Progress, October 2009.
[22] Muhanna、A.、カリル、M.、Gundavelli、S.、チョードリ、K.、およびP. Yegani、 "IPv6のモビリティバインディング取消"、進歩、2009年10月に働いています。
[23] Haley, B. and S. Gundavelli, "Mobile IPv6 Generic Signaling Message", Work in Progress, August 2008.
[23]ヘイリー、B.とS. Gundavelli、 "モバイルIPv6ジェネリックシグナリングメッセージ"、進歩、2008年8月の作業。
Appendix A. Profiling Attack: Discussion
付録A.プロファイリング攻撃：ディスカッション
Profiling attacks pose a significant threat to user privacy. By collecting and analyzing (either online or offline) IP traffic, attackers can obtain sensitive user information. In the context of mobility, although the profiling attack does not directly lead to compromise of location privacy in the way the disclosure of the binding between the home address and the care-of address does, attackers can infer the mobile node's roaming and track its movement (i.e., handover) by profiling the mobile node's communication based on certain fields in IP packets, such as a constant IPsec SPI used during the home registration. The more information collected, the higher probability location privacy is compromised, which in return results in more targeted profiling.
プロファイリング攻撃は、ユーザーのプライバシーへの重大な脅威となっています。 IPトラフィックを収集および分析（オンラインまたはオフライン）することにより、攻撃者はユーザーの機密情報を入手することができます。モビリティの文脈では、プロファイリング攻撃が直接ホームアドレスと気付アドレスとの間の結合の開示は、攻撃者がモバイルノードのローミングを推測し、その動きを追跡することができない方法で、ロケーションプライバシーの妥協にはつながらないものの、ホーム登録の間に使用されるような一定のIPSec SPIなどのIPパケット内の特定のフィールドに基づいて、移動ノードの通信をプロファイリングすることにより（すなわち、ハンドオーバ）。より収集された情報、より高い確率ロケーションプライバシが侵害され、戻り結果のよりターゲットを絞ったプロファイリングです。
We have taken the profiling problem into consideration when designing the solution to IP address location privacy; however, not all aspects of profiling attacks are addressed since the profiling problem spans multiple protocol layers. In the following, we provide a broad discussion on the profiling attack and protection mechanisms. Our discussion is organized based on how profiling attacks can be performed. Note that the following sections are not sorted based on any criteria or may not exhaustively list all the possible attack means (for example, profiling attacks based on upper-layer payloads in data packets are not discussed).
IPアドレス位置プライバシーへのソリューションを設計する際に我々は考慮プロファイリング問題をとっています。しかし、プロファイリング攻撃のではないすべての側面は、プロファイリングの問題は、複数のプロトコル層にまたがるため、対処されています。以下では、プロファイリング攻撃と防御のメカニズムについて幅広い議論を提供しています。私たちの議論は、プロファイリング攻撃を実行することができるかに基づいて編成されます。以下のセクションでは、任意の基準に基づいてソートされていないか（議論されていないデータパケットの上位レイヤペイロードに基づいて攻撃をプロファイリングなど）徹底的にすべての可能な攻撃手段をリストしなくてもよいことに留意されたいです。
A.1. The Care-of Address
A.1。気付アドレス
Eavesdroppers on the MN-HA path and/or the MN-CN path can profile the mobile node's communication by collecting packets with the same care-of address. It is recommended that the mobile node periodically updates its care-of address by using DHCPv6 or IPv6 address privacy extension, even if it does not change its current attachment point. Furthermore, it is even better to change the network prefix of the care-of address periodically, since eavesdroppers may profile IP packets based on the common network prefix.
MN-HA経路及び/又はMN-CN経路上の盗聴者は、同一の気付アドレスを持つパケットを収集することによって、移動ノードの通信をプロファイリングすることができます。移動ノードは定期的にそれが現在のアタッチメントポイントを変更しない場合でも、DHCPv6のアドレスまたはIPv6アドレスのプライバシーの拡張機能を使用することによって、その気付アドレスを更新することをお勧めします。盗聴者は、共通のネットワークプレフィックスに基づいてIPパケットをプロファイリングするので、気付アドレスを定期的にネットワークプレフィックスを変更することでも良いです。
Since the binding update procedure needs to be performed once the care-of address is changed, in order to reduce signaling overheads, the mobile node may choose to change its care-of address when the Binding Cache entry at the home agent or the correspondent node is about to expire.
気付アドレスは、シグナリングオーバーヘッドを減少させるために、モバイルノードは、ホームエージェントの結合キャッシュ項目や相手ノードの気付アドレスを変更することもできます、変更されるとバインディング更新手順を実行する必要があるので、有効期限が近づいています。
A.2. Profiling on the Encrypted Home Address
A.2。暗号化されたホームアドレスにプロファイリング
Generated from either a real or pseudo home address, the encrypted home address can be dynamically updated, because a new key is generated when a new round of the return routability procedure is performed, which makes the encrypted home address look different in subsequent Binding Update and Acknowledgement messages. Nevertheless, the same encrypted home address is used in payload packets forwarded via the optimized route before the next round of the return routability procedure. Given the cost and overhead of updating the encrypted home address, the proposed location privacy solutions still provide a reasonable level of protection against such profiling attacks.
どちらか本当か疑似ホームアドレスから生成された新しいキーが生成されるため、暗号化されたホームアドレスが動的に更新することができ、リターン・ルータビリティ手順の新ラウンドは、暗号化されたホームアドレスを作るた、行った場合、後続の結合更新に違って見えると確認メッセージ。それにもかかわらず、同じ暗号化されたホームアドレスは、リターン・ルータビリティ手順の次のラウンドの前に最適化された経路を介して転送ペイロードパケットで使用されています。暗号化されたホームアドレスを更新するコストとオーバーヘッドを考えると、提案されている場所のプライバシーソリューションは、まだ、このようなプロファイリング攻撃に対する保護の合理的なレベルを提供します。
A.3. The IPsec SPI
A.3。 IPsecのSPI
Eavesdroppers on the MN-HA path can profile the mobile node's communication based on the SPI of an IPsec security association that is for protecting the home Binding Update and Acknowledgement message or for protecting bidirectional-tunneled payload packets.
MN-HA経路上の盗聴者は、ホームバインディング更新肯定応答メッセージを保護するため、または双方向トンネリングペイロード・パケットを保護するためのものであるIPsecセキュリティアソシエーションのSPIに基づいて、移動ノードの通信をプロファイリングすることができます。
To resist this kind of profiling attack, the IPsec SPI needs to be periodically updated. One way is that the mobile node and the home agent rekey the IPsec security association or perform re-authentication periodically. This may result in more signaling overhead. Another way is that the mobile node or the home agent generates a new SPI and then notifies each other by exchanging the Binding Update and Acknowledgement messages protected by an existing IPsec security association with a non-null encryption algorithm. In this way, the information of the new SPI is hidden from eavesdroppers. The new SPI MUST not conflict with other existing SPIs; and if the conflict is detected on one end point, another SPI MUST be generated and be synchronized with the other end point. The new SPI is applied to the next packet that needs to be protected by this IPsec security association. This solution requires close interaction between Mobile IP and IPsec. For example, when the home agent receives a new SPI suggested by the mobile node, it needs to change the corresponding Security Association Database (SAD) entry.
プロファイリングこの種の攻撃に抵抗するために、IPsecのSPIは定期的に更新する必要があります。一つの方法は、モバイルノードとホームエージェントは、IPsecセキュリティ協会キーを再生成または定期的に再認証を実行することです。これは、より多くのシグナリングオーバーヘッドをもたらすことができます。もう一つの方法は、モバイルノードまたはホームエージェントは、新しいSPIを生成していることであると、非ヌル暗号化アルゴリズムを既存のIPSecセキュリティアソシエーションにより保護バインディング更新と受信確認メッセージを交換することにより、相互に通知します。このように、新しいSPIの情報が盗聴者から隠されています。新しいSPIは、他の既存のSPIと競合しないようにしなければなりません。競合は、1つのエンドポイントで検出された場合に、別のSPIを生成しなければならなくて、他の端点と同期させます。新しいSPIは、このIPsecセキュリティ協会によって保護される必要がある次のパケットに適用されます。このソリューションは、モバイルIPとIPsecとの間の緊密な相互作用が必要です。ホームエージェントは、モバイルノードによって提案された新しいSPIを受信したときに例えば、それは、対応するセキュリティアソシエーションデータベース（SAD）エントリを変更する必要があります。
A.4. The IPsec Sequence Number
A.4。 IPsecのシーケンス番号
The IPsec sequence number is required to be larger than that in the previous valid IPsec packet if the anti-replay service is enabled. However, if the increment of the IPsec sequence number is fixed (for example, the IPsec sequence number is sequentially increased), it is possible for eavesdroppers to identify a sequence of IPsec packets that are from/to the same mobile node and to track the mobile node's activities. One possible solution is to randomize the increment of the IPsec sequence number on both end points (i.e., the mobile node and the home agent) of the IPsec security association. The algorithm to generate randomness is implementation specific. It can be, for example, any random number generator, and independently chosen by each end point.
IPsecのシーケンス番号は、アンチリプレイサービスが有効になっている場合は、以前の有効なIPsecパケットに比べて大きくする必要があります。盗聴者は/同じモバイルノードへと追跡するからであるIPsecパケットのシーケンスを識別するためのIPSecシーケンス番号のインクリメントが固定されている場合は、（例えば、IPsecのシーケンス番号を順次増加させる）ことが可能ですモバイルノードの活動。一つの可能な解決策は、IPsecセキュリティアソシエーションの両端点のIPSecシーケンス番号（即ち、モバイルノードとホームエージェント）の増加をランダム化することです。ランダム性を生成するためのアルゴリズムが実装固有のものです。これは、例えば、任意の乱数発生器であり、かつ独立して各エンドポイントによって選択することができます。
A.5. The Regular Interval of Signaling Messages
A.5。シグナリングメッセージの定期的な間隔
As described in RFC 3775, certain signaling messages may be exchanged on a regular basis. For example, the correspondent registration needs to be performed every MAX_RR_BINDING_LIFETIME seconds and the home binding update procedure needs to be performed regularly, if the lifetime of the home Binding Cache entry is fixed. Such timing allows eavesdroppers to perform traffic analyses and correlate different messages. Due to background traffic and routing dynamics, the timing of messages observed by an eavesdropper at a certain vantage point may be irregular. Nevertheless, a better solution is to randomize the lifetime of the Binding Cache entry in the home agent and the correspondent node.
RFC 3775に記載されているように、特定のシグナリング・メッセージは定期的に交換することができます。例えば、通信員登録は、すべてのMAX_RR_BINDING_LIFETIME秒を実行する必要があると家庭バインディング更新手順は、キャッシュエントリをバインド家の寿命が固定されている場合、定期的に実行する必要があります。このような時期には、盗聴者がトラフィックの分析を実行し、異なるメッセージを相関させることができます。バックグラウンドトラフィック及びルーティングダイナミクスに、特定の視点での盗聴者によって観察されたメッセージのタイミングが不規則であってもよいです。それにも関わらず、よりよい解決策は、ホームエージェントと、コレスポンデント・ノードにおける結合キャッシュ項目の寿命をランダム化することです。
A.6. The Sequence Number in the Binding Update Message
A.6。バインディング更新メッセージ内のシーケンス番号
RFC 3775 requires that the sequence number in the Binding Update message be larger than that in the previous valid Binding Update message for a particular mobile node. However, if the increment of the sequence number in the home or correspondent Binding Update message is fixed (for example, the sequence number is sequentially increased), it is possible for eavesdroppers on the MN-HA or MN-CN path to identify a sequence of Binding Update messages that are from the same mobile node and to track the mobile node's movement. One possible solution is that the mobile node randomizes the increment of the sequence number used in subsequent Binding Update messages. The algorithm to generate randomness is implementation specific. It can be, for example, any random number generator. Note that such an algorithm is not needed when the sequence number is encrypted, for example, when the home Binding Update message is protected by an IPsec tunnel mode security association.
RFC 3775は、Binding Updateメッセージのシーケンス番号は、特定のモバイルノードのために以前の有効なBinding Updateメッセージの場合よりも大きいことが必要です。家庭または対応付け更新メッセージ内のシーケンス番号のインクリメント（例えば、シーケンス番号が順次増加する）固定されている場合は、それが盗聴可能であるMN-HAまたはMN-CNパス配列を同定します同じモバイルノードからのものであり、モバイルノードの動きを追跡するために、Binding Updateメッセージの。一つの可能な解決策は、モバイルノードが、後続のバインディング更新メッセージで使用されるシーケンス番号のインクリメントをランダム化することです。ランダム性を生成するためのアルゴリズムが実装固有のものです。それは、例えば、任意の乱数発生器とすることができます。シーケンス番号が暗号化されている場合、ホームBinding UpdateメッセージはIPsecトンネルモードセキュリティアソシエーションにより保護されている場合、このようなアルゴリズムは、例えば、必要とされないことに留意されたいです。
A.7. Multiple Concurrent Sessions
A.7。複数の同時セッション
It is possible for (colluded) eavesdroppers to correlate the mobile node's different sessions with the same or different correspondent nodes, for example, based on the same pseudo home address and/or the same care-of address. A possible solution is to use different pseudo home addresses and different care-of addresses in different sessions. Note that the mobile node may also use the same pseudo home address with different correspondent nodes, if the pseudo home address is masked by different privacy management keys generated during the return routability procedure with different correspondent nodes. In this way, the encrypted pseudo home addresses used with different correspondent nodes look different to eavesdroppers.
（共謀）盗聴者が同一の疑似ホームアドレスおよび/または同じ気付アドレスに基づいて、例えば、同じまたは異なる通信員ノードとモバイルノードの異なるセッションを相関することが可能です。可能な解決策は、異なる疑似ホームアドレスと異なる別のセッションで気付アドレスを使用することです。疑似ホームアドレスが異なる通信相手ノードとリターン・ルータビリティ手順の間に生成された異なるプライバシー管理キーによってマスクされている場合、モバイルノードはまた、異なる通信相手ノードと同じ疑似ホームアドレスを使用することができることに注意してください。このように、異なる通信相手ノードで使用される暗号化された疑似ホームアドレスは、盗聴者に違って見えます。
A.8. Summary
A.8。概要
As discussed above, there exist multiple means for eavesdroppers to correlate observed activities. For example, some IP fields, which contain certain constant values and remain unchanged for a long time, allow eavesdroppers to identify and link the mobile node's activities deterministically. Other means may be less reliable when used for traffic analysis and correlation; nevertheless, they provide additional hints to malicious attackers.
上述したように、盗聴者が観察活動を相関させるための複数の手段が存在します。例えば、ある一定の値が含まれていると長い時間のために変更されないまま、いくつかのIPフィールドは、盗聴者が決定論的に、モバイルノードの活動を特定し、リンクすることができます。トラフィック分析と相関のために使用されたときに他の手段が少なく信頼性が高い可能性があります。それにもかかわらず、彼らは、悪意のある攻撃者に追加のヒントを提供します。
The solution to the profiling attack is to update certain IP fields periodically. Generally, the more frequently, the higher the probability that the profiling attack is resisted and also the higher the cost in terms of communication and processing overheads and complexity. As eavesdroppers can profile activities based on multiple fields, it may not be cost-effective to update some fields more frequently than others. Furthermore, it may reduce some overheads, if all the related IP fields are updated together with the same frequency.
プロファイリング攻撃に対する解決策は、定期的に特定のIPフィールドを更新することです。一般的に、より頻繁に、より高いプロファイリング攻撃は、通信や処理のオーバーヘッドと複雑さの点でもコスト高抵抗している確率。盗聴者が複数のフィールドに基づいた活動をプロファイリングことができるように、それは費用対効果が他よりも頻繁にいくつかのフィールドを更新することではないかもしれません。すべての関連IPフィールドが同じ頻度で一緒に更新されている場合はさらに、それは、いくつかのオーバーヘッドを減らすことができます。
The profiling attack is a complicated issue. A complete solution would have to consider tradeoffs of many different factors, such as complexity, effectiveness, and efficiency.
プロファイリング攻撃は複雑な問題です。完全なソリューションは、このような複雑性、有効性、効率性など、さまざまな要因のトレードオフを考慮しなければなりません。
Authors' Addresses
著者のアドレス
Ying Qiu Institute for Infocomm Research, Singapore 1 Fusionopolis Way #21-01 Connexis (South Tower) Singapore 138632
インフォコム研究のための英秋研究所、シンガポール1フューウェイ＃21から01 Connexis（サウスタワー）シンガポール138632
Phone: +65-6408 2053 EMail: qiuying@i2r.a-star.edu.sg
電話：+ 65-6408 2053 Eメール：qiuying@i2r.a-star.edu.sg
Fan Zhao (editor) Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 US
ファン趙（エディタ）グーグル株式会社1600アンフィシアターパークウェイマウンテンビュー、カリフォルニア州94043米国
EMail: fanzhao@google.com
メールアドレス：fanzhao@google.com
Rajeev Koodli Cisco Systems
ラジブkudliシスコシステムズ
EMail: rkoodli@cisco.com
メールアドレス：rkoodli@cisco.com