[要約] RFC 5726は、モバイルIPv6の位置情報プライバシーの解決策に関するものであり、ユーザーの位置情報の保護とプライバシーの確保を目的としています。
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
モバイルIPv6ロケーションプライバシーソリューション
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 Mobility Optimizations（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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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]で指定されているモビリティの存在下では、2つの関連する問題があります。これは、特派員ノードへの住所のケアを開示し、盗聴者に自宅の住所を明らかにすることです（以下の用語を参照してください）。ロケーションプライバシーの問題の詳細な説明は、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で説明されているように）では、モバイルノードは、ロケーションプライバシーが盗聴者に違反されていない実際のホームアドレスを使用して、特派員ノードと通信できます。これは、返品ルー上の手順中に生成されたパラメーターを使用して、RFC 3775ですでに指定されているリターンルーティング可能性メッセージに基づいてロケーションプライバシー保護に基づいた場所のプライバシー保護に向けた進化を提供する実際のホームアドレスをマスクすることによって行われます。非ヌル暗号化アルゴリズムとのIPSECトンネルモードのセキュリティ関連は、モバイルノードとホームエージェントの間で交換されるシグナリングメッセージ（その中の実際のホームアドレスを含む）を暗号化するために交渉されます。さらに、返品ルー上の手順と特派員のバインディング更新手順で、「擬似ホームアドレス」（この新しい用語の定義と他の多くの一般的に使用されるモビリティ関連の用語がセクション2に記載されています）を使用して、実際のホームアドレスを置き換えるために使用されます。さまざまなメッセージにより、モバイルノードは、特派員ノードへの追加の拡張機能を必要とせずに、特派員ノードと盗聴者の両方から実際のホームアドレスを非表示にすることができます。さらに、モバイルノードは、セクション5で指定されたメカニズムを使用して、ロケーションのプライバシー保護をさらに強化することにより、擬似ホームアドレスをマスクする場合があります。これらの2つのソリューションはそれぞれ、他のソリューションに依存せずに実装できます。
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 Research Groupのコンセンサスを表しています。特定の作業分野で活動している研究グループメンバーによってレビューされています。椅子の要請により、このドキュメントは、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].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" ingle "、" low "obs"、 "becommended"、 ""、 "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つの新しい用語を紹介します。これらの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]で定義されているように、一般的に採用されるモビリティ関連用語を使用します。これらの用語の一部は、参照を簡単にするために以下に提供されます。それにもかかわらず、RFC 3775 [6]、RFC 3776 [7]、およびRFC 4877 [8]で定義されているように、読者はモバイルIPv6プロトコルの基本的な操作に精通していると想定しています。
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 Care-of Address（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 Return Routability（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 ホームテストinit（hoti） / home test（hot） / Care-of test init（coti） / Care-of test（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エンティティが異なる機能を備えている場合でも、異なるモバイル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パスの盗聴者に漏れがある実際のホームアドレスが漏れているのを防ぐための解決策は、非ヌル暗号化アルゴリズムとの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.
ルート最適化モードで特派員ノードと通信するために、モバイルノードは、クレENTENTバインディングアップデート手順を使用したリターンルーティング可能性手順を実行する必要があります。現在のモバイルIPv6仕様により、特派員のバインディングアップデートメッセージとペイロードパケットの実際のホームアドレスとケアオブアドレスが盗聴者に表示されます。したがって、最適化されたルートを介してパケットを送信および受信し、同時にロケーションのプライバシーを保護するために、モバイルノードはそのケアのケアを開示し、実際の自宅住所を隠す必要があります。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つのシナリオは、特派員ノードがモバイルノードの実際のホームアドレスを取得し、実際のホームアドレスを使用してモバイルノードとの通信を開始できることです。この場合、モバイルノードは、セッションの継続性を維持し、盗聴者から実際のホームアドレスを隠すために、特派員ノードを使用して実際のホームアドレスを使用し続ける必要があります。このシナリオのソリューション（以下「リバースタンネルクレルドバインディングアップデート」と呼ばれる）のソリューションは、セクション5で説明されています。このソリューションでは、モバイルノードは、RFC 3775で定義されているのと同じ戻りルー上のルーティング可能性シグナリングメッセージを交換し、次に交換します。Keygen Tokensからプライバシー管理キーを導き出し、このキーを使用して実際のホームアドレスを暗号化します。最後に、ホームエージェントを介して拡張された特派員のバインディングアップデートメッセージを逆転させて、暗号化されたホームアドレスと特派員ノードで実際のホームアドレスを登録します。特派員登録後、モバイルノードと特派員ノードは、最適化されたルートを介して交換されるペイロードパケットの実際のホームアドレスの代わりに、登録された暗号化されたホームアドレスを使用します。プライバシー管理キーが異なるため、暗号化されたホームアドレスは異なる特派員ノードで異なります。
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で説明されています。このソリューションを使用すると、モバイルノードは最初に、ホームアドレステスト手順中に擬似ホームアドレスに基づいて生成されたホームキーゲントークンを取得します。その後、モバイルノードは、通信員のバインディングアップデートメッセージを送信して、最適化されたルートを介して、擬似ホームアドレスと特派員ノードのケアオブアドレス間のバインディングを登録します。特派員登録後、モバイルノードと特派員ノードは、最適化されたルートを介して交換されるペイロードパケットで、実際のホームアドレスの代わりに登録された擬似ホームアドレスを使用します。擬似ホームアドレスの使用は、特派員ノードに対して完全に透明であることに注意してください。
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, 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.3を参照）と呼ばれる新しいモビリティオプションで要求された擬似ホームアドレスを示し、ホームエージェントは別の新しい新しいアドレス登録のステータスを示しますPseudo Homeアドレス謝辞オプション（セクション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.
このドキュメントに拡張機能が導入された場合、モバイルノードは、ホームエージェントと特派員ノードがロケーションプライバシーソリューションをサポートしているかどうかを発見できます。ホームバインディングアップデートメッセージに存在する場合、擬似ホームアドレスモビリティオプションは、モバイルノードがロケーションプライバシーソリューションの使用を要求していることを示します。このようなバインディングアップデートメッセージが有効であり、ホームエージェントがこの特定のモバイルノードのロケーションプライバシーソリューションをサポートする場合、拘束力のある確認メッセージの擬似ホームアドレス確認モビリティオプションで応答します。それ以外の場合、ホームエージェントがロケーションプライバシーソリューションをサポートしていない場合、拘束力のある確認メッセージに擬似ホームアドレス確認モビリティオプションは含まれていません。同様に、特派員のバインディングアップデートメッセージに暗号化されたホームアドレスの宛先オプションの存在は、モバイルノードがロケーションプライバシーソリューションの使用を要求することを特派員ノードに示します。このようなバインディングアップデートメッセージが有効であり、特派員ノードがこの特定のモバイルノードのロケーションプライバシーソリューションをサポートする場合、モバイルノードへの特派員バインディング確認メッセージの暗号化されたホームアドレスルーティングヘッダーで応答します。特派員ノードがロケーションプライバシーソリューションをサポートしていない場合、コード値を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のすべての変更により変更されます。これは、リターンルーティング可能性が実行されると変更されます（たとえば、住所のケアの変更、Keygenトークンの有効期限など）。したがって、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:
モバイルノードは、特派員のバインディングアップデートメッセージを生成し、ホームエージェントを介してこのメッセージを特派員ノードにリバースタンネルします。カプセル化後のこのメッセージの形式は次のとおりです。
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)))
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）ESP Header In Tunnel Mode IPv6 Header（Source = Home Address、Destination = crespordent Node）Destination Option Header暗号化ホームアドレスオプション（暗号化ホームアドレス）パラメーター：代替ケア - アドレスオプション（CARE-of Address）シーケンス番号（バインディングアップデートメッセージヘッダー内）ホームNONCEインデックス（NonCe Indicesオプション内）Care-of NonCe Index（NonCe Indicesオプション内）First（96、HMAC_SHA1（KBM、（）住所の世話|特派員| 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)
IPv6ヘッダー（ソース=ホームアドレス、宛先=特派員ノード）宛先オプションヘッダー暗号化ホームアドレスオプション（暗号化されたホームアドレス）
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)))
パラメーター：代替ケアオブアドレスオプション（ケアオブアドレス）シーケンス番号（バインディングアップデートメッセージヘッダー内）ホームNonCEインデックス（NonCEインデックスオプション内）Care-of NonCe Index（NonCe Indicesオプション内）最初（96、hmac_sha1（kbm、（care-of address | crespordent | 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)))
IPv6ヘッダー（SOURCE = CORRESTENTENTノード、宛先=ホームアドレス）暗号化されたホームアドレスルーティングヘッダー暗号化されたホームアドレスパラメーター：シーケンス番号（バインディングアップデートメッセージヘッダー内）最初（96、HMAC_SHA1（KBM、（ケアオブアドレス|対応|）））））
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.
この拘束力のある確認メッセージを受信すると、ホームエージェントは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)))
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）トンネルモードのESPヘッダーIPv6ヘッダー（Source = crespordentノード、宛先=ホームアドレス）暗号化されたホームアドレスルーティングヘッダー暗号化されたホームアドレスパラメーター：シーケンス番号（バインディングアップデート内）メッセージヘッダー）first（96、hmac_sha1（kbm、（Care-of Address | crespordent | 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.
モバイルノードが受信されたバインディング確認メッセージを処理した後、逆回転された特派員のバインディング更新手順が完了します。モバイルノードが異なる特派員ノードと通信すると、暗号化されたホームアドレスが異なるように見えることに注意してください。
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.
特派員ノードで確立されたバインディングキャッシュエントリを削除するには、モバイルノードがホームエージェントを介して次のバインディングアップデートメッセージを逆にターンします。暗号化されたホームアドレスオプションは、特派員のバインディング脱線中にオプションであり、この場合、必要に応じてKBMとKPMを生成するためにHome KeyGenトークンのみを使用していることに注意してください。
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)))
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）ESP Header In Tunnel Mode IPv6 Header（Source = Home Address、Destination = crespordent Node）Destination Option Header（オプション）暗号化されたホームアドレスオプション（暗号化されたホームアドレス）パラメーター：代替のケアオプションオプション（ケアオブアドレス）シーケンス番号（バインディングアップデートメッセージヘッダー内）ホームNONCEインデックス（NonCe Indicesオプション内）Care-of NonCe Index（NonCe Indicesオプション内）最初（96、hmac_sha1（KBM、（住所のケア|特派員| 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)))
IPv6ヘッダー（SOURCE = CORRESTENTENTノード、宛先=ホームアドレス）暗号化されたホームアドレスルーティングヘッダー（オプション）暗号化されたホームアドレスパラメーター：シーケンス番号（バインディングアップデートメッセージヘッダー内）最初（96、HMAC_SHA1（KBM、（Care-of Address |）特派員| 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
IPv6ヘッダー（Source = Care-of Address、Destination = crespordent Node）Destination Option Header暗号化ホームアドレスオプション（暗号化ホームアドレス）ペイロード
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
IPv6ヘッダー（Source = crespordent Node、Destination = Care-of Address）暗号化されたホームアドレスルーティングヘッダー暗号化ホームアドレスペイロード
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.
特派員登録のバインディングアップデートリストエントリは、特定の特派員ノードで使用されている現在の暗号化されたホームアドレスを保存するための新しいフィールドで拡張されます。暗号化されたホームアドレスは、モバイルノードがリバースタンネルの特派員のバインディングアップデートメッセージを送信すると保存され、対応するバインディングアップデートリストエントリの状態は、モバイルノードが通信者のバインディング確認メッセージを正常に処理すると更新されます。暗号化されたホームアドレスフィールドは、ホーム登録のバインディングアップデートリストエントリでは無効であることに注意してください。
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アドレスと一緒に使用して）プライマリキーとして使用して、バインディングアップデートリストを調べます。
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.
返品ルー上の手順の後、モバイルノードが特派員ノードを使用してロケーションプライバシーソリューションを使用することを選択した場合、たとえばモバイルノードの構成に基づいて、暗号化されたホームアドレスを生成し、更新または作成します。暗号化されたホームアドレスは、ホームエージェントに確立された逆トンネルを介して、特派員のバインディングアップデートメッセージを転送します。MacはRFC 3775で指定された方法と同じ方法で生成され、暗号化された自宅の住所をカバーしていないことに注意してください。
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.
モバイルノードが、以前に送信された逆タンネリングバインディングアップデートメッセージに応答して、特派員ノードからバインディング承認メッセージを受信すると、このバインディングの確認メッセージに暗号化されたホームアドレスルーティングヘッダーが含まれている場合、モバイルノードは、特派員ノードがサポートすることを検討します。ロケーションプライバシーソリューション。モバイルノードは、RFC3775に基づいてこのメッセージを認証します。認証が成功した場合、モバイルノードは暗号化されたホームアドレスを復号化し、結果を実際のホームアドレスと比較するか、暗号化されたホームアドレスとバインディングアップデートリストエントリに保存されているものと比較します。。それらが一致する場合、モバイルノードは、特派員の登録が成功し、対応するバインディングアップデートリストエントリの状態を更新することを考慮します。それらが一致しない場合、モバイルノードは、特派員のバインディング更新手順を再度開始する場合があります。
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、コード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.
バインディングキャッシュエントリは、特定のモバイルノードで使用される現在の暗号化されたホームアドレスを保存するための新しいフィールドで拡張されています。暗号化されたホームアドレスは、特派員ノードが正常に逆触発された特派員のバインディングアップデートメッセージを正常に処理するときに保存されます。
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ビットであることを考えると、暗号化された各ホームアドレスまたはバインディングキャッシュエントリに保存されている暗号化されたホームアドレスの組み合わせが一意であると予想されます。したがって、特派員ノードは、暗号化されたホームアドレスを使用（または、ケアオブアドレスと一緒に使用する）を主要なキーとして使用して、バインディングキャッシュを調べることができます。
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.
暗号化されたホームアドレスオプションを使用してリバースタンネルのバインディングアップデートメッセージを受信する場合、Cronferent Nodeがロケーションプライバシーソリューションをサポートする場合、RFC 3775で定義された同じ方法を使用してメッセージを検証します。KPMとそれを使用して、暗号化されたホームアドレスを復号化し、結果をソースIPアドレスと比較します。それらが一致する場合、特派員ノードは、対応するバインディングキャッシュエントリに暗号化されたホームアドレスを保存します。
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.
モバイルノードによって逆タンネルの特派員バインディングアップデートメッセージの謝辞が要求された場合、特派員ノードは、ロケーションプライバシーソリューションをサポートする場合、暗号化されたホームアドレスルーティングヘッダーでバインディング確認メッセージを返します。バインディング承認メッセージの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.
実装の可能な方法は次のとおりです。CRORSPORSERNTENT NODEの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.
暗号化されたホームアドレスオプションを使用して逆タンネリングされた特派員のバインディング更新メッセージを受信する場合、特派員ノードがロケーションプライバシー拡張機能をサポートしていない場合、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アドレスに戻るステータスコードを設定してバインディングエラーメッセージを返します。さらに、バインディングエラーメッセージのホームアドレスフィールドは、暗号化されたホームアドレスの暗号化されたホームアドレスフィールドから、問題のあるパケットのオプションが表示されない場合は、不特定のアドレスに設定するか、コピーする必要があります。
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パスの盗聴者に見えないように、非ヌル暗号化変換を使用する必要があります。パケット形式と処理ルールは、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.
ルート最適化モードのロケーションプライバシーを保護するために、モバイルノードは、特定のシグナル伝達パケットとペイロードパケットで使用される実際のホームアドレスを擬似ホームアドレスに置き換えます。暗号化されたホームアドレスとは異なり、擬似ホームアドレスは、宛先アドレスとして使用される擬似ホームアドレスでホームエージェントがパケットを傍受できるように、ルーティング可能である必要があります。擬似ホームアドレスは、ホームネットワークのプレフィックスの1つをランダムなビット文字列と連結することにより生成されます。たとえば、ランダム数ジェネレーターまたは安全な暗号化またはハッシュアルゴリズムを使用して、このようなランダムなビット文字列を生成する方法はたくさんあります。
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.
ルーティング可能性と特派員へのバインディングアップデートであっても、実際のホームアドレスの代わりに擬似ホームアドレスを使用するのは、次の利点があります。第一に、擬似ホームアドレスは、公開されていない（またはそうすべきではない）ため、モバイルノードの身元を明らかにしません。したがって、攻撃者は擬似ホームアドレスに基づいてモバイルノードのIDを決定できないため、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)).
擬似ホームアドレスを形成するために使用される接頭辞は、同じホームエージェントによって管理されているため、Returbabilityメッセージを転送できるようにする必要があります。実際のホームアドレスで使用されているものと同じである必要はありませんが、プレフィックスは違うことを強くお勧めします。たとえば、ホームエージェントは、モバイルノードのセットにロケーションプライバシー目的で異なるプレフィックスプールを使用する場合があります。これにより、実際のホームアドレスと擬似ホームアドレスが共同関連ではないことが保証されます（モバイルノードが異なるインターフェイス識別子（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.
モバイルノードは、実際に特派員ノードで使用する前に、ホームエージェントに使用する擬似ホームアドレスを登録する必要があります。そのために、モバイルノードは、ホームエージェントに送信されたバインディングアップデートメッセージの擬似ホームアドレスモビリティオプションの擬似ホームアドレスを示します。ホームエージェントがロケーションプライバシーソリューションをサポートする場合、重複するアドレス検出を実行して、この擬似ホームアドレスが異なるモバイルノードから提出された他の擬似ホームアドレスと競合するかどうかを検出します。結果に基づいて、ホームエージェントは、拘束力のある承認メッセージの擬似ホームアドレス謝辞オプションに適切なステータスコードを設定することにより、擬似ホームアドレスを受け入れるかどうかを示します。ホームエージェントが要求された擬似ホームアドレスのそれから異なるホームネットワークのプレフィックスの使用を好む場合、ホームエージェントは、モバイルノードに擬似ホームアドレス謝辞モビリティオプションで新しい擬似ホームアドレスを返します。
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.
モバイルノードは、ロケーションプライバシー保護を使用して特派員ノードと通信しようとしているときに、擬似ホームアドレスを登録する場合があります。登録された擬似ホームアドレスのデフォルトの寿命は、ホームバインディングキャッシュエントリと同じです。ただし、モバイルノードは任意の価値を選択する場合があり、ホームエージェントは任意の価値を付与する場合があります。モバイルノードは、ホームバインディングアップデートメッセージの擬似ホームアドレスモビリティオプションを使用して、擬似ホームアドレスを追加または削除できます。ホームエージェントは、擬似ホームアドレスから実際のホームアドレスを回復する必要はありません。
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 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.
モバイルノードがホームリンクに戻ると、ホームの登録手順はRFC 3775で指定されていると同じです。つまり、実際のホームアドレスは、バインディングアップデートメッセージのソースIPアドレスとして、および宛先IPアドレスのソース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:
モバイルノードは、ホームエージェントにホームテストINITメッセージを生成および送信します。このメッセージの形式は次のとおりです。
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)
IPv6ヘッダー（Source = Care-of Address、Destination = Home Agent）ESP Header In Tunnel Mode IPv6 Header（Source = Home Address、Destination = crespoldent）Home home init cookie pseudo Homeアドレスモビリティオプション（pseudo Homeアドレス）
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で指定されているものとの違いは、モバイルノードには、ホームテストINITメッセージに擬似ホームアドレスモビリティオプション（セクション7.3を参照）が含まれていることです。モバイルノードとホームエージェントとの間のセキュリティ関連は実際のホームアドレスに基づいているため、擬似ホームアドレスを運ぶための新しいオプションが必要です。擬似ホームアドレスオプションに含まれる擬似ホームアドレスは、ホーム登録手順中にホームエージェントに登録された一連の擬似ホームアドレスからモバイルノードによって選択されます。ホームテストINITメッセージは、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.
ホームテストINITメッセージを受信すると、ホームエージェントはセクション6.6.4で指定されているように操作を実行します。擬似ホームアドレスモビリティオプションがホームテストINITメッセージに存在する場合、この操作が成功した場合、ホームエージェントはホームテストINITメッセージを生成し、それを特派員ノードに転送します。以下に示すように、擬似ホームアドレスモビリティオプションで運ばれる擬似ホームアドレスは、転送されたホームテストINITメッセージのソースIPアドレスとして使用されます。
IPv6 header (source = pseudo home address, destination = correspondent) Mobility Header (HoTI) Home Init Cookie
IPv6ヘッダー（ソース=擬似ホームアドレス、目的地=特派員）モビリティヘッダー（hoti）ホームイニシ
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.
転送されたホームテストINITメッセージは、RFC 3775で指定されているものと同様に、通信機ノードと同じように見え、CRORRECTERNETENTノードは擬似ホームアドレスが使用されていることを認識しておらず、RFCで指定した同じアルゴリズムを使用してホームキーゲントークンを生成するだけです。3775。
home keygen token = First (64, HMAC_SHA1 (Kcn, (pseudo home address | nonce | 0)))
Home keygen token = first（64、hmac_sha1（kcn、（pseudo home address | nonce | 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
IPv6ヘッダー（Source = crespordent、Destination =擬似ホームアドレス）モビリティヘッダー（ホット）ホームイニシアホーム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)
IPv6ヘッダー（ソース=ホームエージェント、宛先=ケアオブアドレス）ESPヘッダートンネルモードIPv6ヘッダー（Source = crespordent、Destination = Homeアドレス）モビリティヘッダー（HOT）ホームCookie Home Keygen Token Home NonCe Index擬似住所承認モビリティオプション（擬似ホームアドレス）
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を生成するために、キーゲントークンとホームkeygenトークンを一緒に生成します。
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.
この手順では、モバイルノードは、ホームアドレステスト手順で使用される同じ擬似ホームアドレスを使用する必要があります。擬似ホームアドレスは、特派員のバインディングアップデートメッセージのホームアドレスオプションで運ばれます。
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)))
IPv6ヘッダー（Source = Care-of Address、Destination = cresportent）宛先オプションヘッダーホームアドレス宛先オプション（擬似ホームアドレス）パラメーター：シーケンス番号（バインディングアップデートメッセージヘッダー内）ホームNONCE INDEX（NONCE INDICESオプション内）ケア - of nonce index（nonce indices option option）first（96、hmac_sha1（kbm、（Care-of Address | crespordent | 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.
特派員ノードがバインディングアップデートメッセージを受信すると、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)))
IPv6ヘッダー（Source = crespordent、Destination = Care-of Address）パラメーター：シーケンス番号（バインディングアップデートメッセージヘッダー内）First（96、HMAC_SHA1（KBM、（Care-of Address | Corresporent | 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.
モバイルノードが、特派員の登録が成功したことを示す拘束力のある承認メッセージを受信した後、モバイルノードは、特派員ノードと通信するために擬似ホームアドレスを使用できるようになりました。
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.
このようなバインディングアップデートメッセージは、モバイルノードでも使用されて、特派員ノードで以前に確立されたバインディングを削除することもできます。この場合、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で説明されているものと類似しています。ただし、擬似ホームアドレスが実際のホームアドレスの代わりに使用されていることを除きます。暗号化されたホームアドレスの宛先と暗号化されたホームアドレスルーティングヘッダーを使用して、暗号化された擬似ホームアドレスを運ぶ必要があります。
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.
Pseudo Homeアドレスの情報を記録するために、Pseudo Home Address Tableと呼ばれる新しいデータ構造を紹介します。モバイルノードは、登録するホームエージェントごとに擬似ホームアドレステーブルを維持できます。テーブル内の各エントリには、擬似ホームアドレスとそれに関連する状態、つまり「未確認」または「確認」が含まれています。モバイルノードは、ホームバインディングアップデートメッセージを送信したり、ホームバインディングの確認メッセージを受信したりするときに、擬似ホームアドレステーブルにエントリを作成または更新します。擬似ホームアドレスは、テーブルを検索するためのキーとして使用できます。擬似ホームアドレステーブルに保存されている重複した擬似ホームアドレスはありません。
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).
バインディングアップデートリストエントリは、Pseudo Homeアドレスと呼ばれるフィールドで拡張されます。このフィールドは、擬似ホームアドレステーブルの対応するエントリを指すポインターとして実装できます。このポインターは、バインディングアップデートリストエントリが作成されたときにnullとして初期化されます（たとえば、モバイルノードがバインディングアップデートメッセージまたはホームテストINITメッセージをホームエージェントに送信するとき）。特定のホームエージェントに送信されたバインディングの場合、擬似ホームアドレスフィールドは、擬似ホームアドレステーブルの最初のエントリ（またはテーブルが空の場合は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で指定されているホームバインディングアップデートメッセージを保護する必要があります。ノードは、上記のように擬似ホームアドレスを登録できます。モバイルノードがこの時点で擬似ホームアドレスを登録することを望まないが、ホームエージェントがロケーションプライバシーソリューションをサポートするかどうかを発見したい場合、モバイルノードには、バインディングに擬似ホームアドレスフィールドのない擬似ホームアドレスモビリティオプションが含まれていますホームエージェントに送信されたメッセージを更新します。
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で指定された操作に加えて、Home Dregistration Binding Updateメッセージを送信した後、モバイルノードはロケーションプライバシーソリューションに固有のデータ構造の使用を停止する必要があり、バインディング確認メッセージが正常に処理された後に削除することができます。
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".
さらに、1つまたは複数の擬似ホームアドレスの確認モビリティオプションがバインディング確認メッセージに存在する場合、モバイルノードは各オプションのステータスフィールドをチェックします。1つのオプションのステータスフィールドが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で指定されているものに基づいてホームテストINITメッセージを生成します。特派員ノードとのセッションでは、モバイルノードは、既にホームエージェントに登録され、擬似ホームアドレステーブルに保存されているものから擬似ホームアドレスを選択します。それ以外の場合、モバイルノードは、前に同じ特がったノードで使用されるのと同じ擬似ホームアドレスを使用する必要があります。選択された擬似ホームアドレスは、生成されたホームテストINITメッセージの擬似ホームアドレスモビリティオプションで運ばれます。このホームテストINITメッセージは、非ヌル暗号化アルゴリズムとの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.
ホームテストINITメッセージをホームエージェントに送信した後、CRORSPROSENTENT NODEに存在するバインディングアップデートリストエントリがない場合、モバイルノードは使用される擬似ホームアドレスを指す1つのエントリを作成します。それ以外の場合、モバイルノードは既存のエントリを更新します。
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で指定された処理ルールに基づいてパケットを処理します。これは有効なパケットであり、擬似ホームアドレス謝辞オプションが含まれている場合、モバイルノードが含まれています。次のように、このモビリティオプション内のステータスフィールドを調べます。
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.
o ステータスフィールドが、擬似ホームアドレスを使用したホームアドレステスト手順が成功することを示している場合（ステータスフィールドは0）、RFC 3775で指定されているものに加えて、モバイルノードは擬似ホームで運ばれる擬似ホームアドレスを使用する準備をします特派員登録のアドレス確認オプション。
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.
o ステータスフィールドが、擬似ホームアドレスを使用したホームアドレステスト手順が失敗したことを示している場合（ステータスフィールドは127を超えています）、モバイルノードはエラーの原因を修正し、ホームテストINITメッセージを再送信するための手順を実行できます。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.
バインディングキャッシュエントリは、現在認められている擬似ホームアドレスのリストを指すフィールドで拡張されます。登録された各擬似ホームアドレスは一意でなければならず、登録されたすべての擬似ホームアドレスは、擬似ホームアドレスをバインディングキャッシュを検索するキーとして使用するときに、関連するバインディングキャッシュエントリをすばやく見つけることができるように編成する必要があります。。
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:
受信したバインディングアップデートメッセージに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 受信した擬似ホームアドレスフィールドが空の場合、ステータスフィールドは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 受信した擬似ホームアドレスフィールドがすべてゼロに設定されている場合、ステータスフィールドは設定されています（成功）、ホームエージェントがダイナミックな擬似ホームアドレスの割り当てをサポートする場合、擬似ホームアドレスフィールドに擬似ホームアドレスを含める必要があります。;それ以外の場合、ステータスフィールドは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アドレスの形式が正しくない場合、ステータスフィールドは130に設定されています（誤った擬似ホームアドレス）。このようなIPアドレスが無効である場合、たとえば、プレフィックスが有効なホームネットワークプレフィックスではない場合、またはこれが重複したIPアドレスとして検出されます。ステータスフィールドは131（無効な擬似ホームアドレス）に設定されます。どちらの場合も、擬似ホームアドレスフィールドは空です。ホームエージェントが異なる擬似ホームアドレスを提案する場合、ステータスフィールドは0（成功）に設定され、新しい擬似ホームアドレスは擬似ホームアドレスフィールドに含まれています。それ以外の場合、ホームエージェントが要求された擬似ホームアドレスを受け入れる場合、ステータスフィールドは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 ホームエージェントがモバイルノードがCRORSPRESTENT NODEを使用して擬似ホームアドレスを使用することを許可していない場合、ステータスフィールドは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 ホームエージェントが他のすべての理由で擬似ホームアドレスモビリティオプションを受け入れない場合、ステータスフィールドは128（障害、理由が不特定）に設定され、擬似ホームアドレスは空です。
When receiving a Binding Update message protected with the IPsec tunnel mode, the home agent performs the operation specified in RFC 4877.
IPSECトンネルモードで保護されたバインディングアップデートメッセージを受信すると、ホームエージェントは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.
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トンネルモードで保護された拘束力のある確認メッセージを送信すると、ホームエージェントは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.
モバイルノードからホームテストINITメッセージを受信すると、ホームエージェントは最初にRFC 3776で指定されているIPSEC処理ルールに基づいてこのメッセージを検証します。検証が失敗した場合、ホームエージェントはそのようなIPSEC処理ルールに基づいて動作します。それ以外の場合、擬似ホームアドレスオプションがホームテストINITメッセージに存在しない場合、ホームエージェントは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. ホームエージェントは、実際のホームアドレスをキーとして使用して、バインディングキャッシュを調べます。擬似ホームアドレスオプションに掲載された擬似ホームアドレスが、対応するバインディングキャッシュエントリに関連付けられた擬似ホームアドレスと一致しない場合（擬似ホームアドレスフィールドがゼロとして設定されている場合を含む）、ホームテストINITメッセージを送信して拒否する必要があります擬似ホームアドレス承認オプションを含むホームテストメッセージに戻り、ステータスフィールドセットは131（無効な擬似ホームアドレス）を設定します。
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アドレスとして擬似ホームアドレスを使用してホームテストINITメッセージを作成し、ホームテストINITメッセージを特派員ノードに転送します。
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アドレスが実際のホームアドレスの1つと一致する場合、ホームエージェントはRFC 3775で指定された操作を実行します。結合キャッシュを調べて、一致した擬似ホームアドレスがあるかどうかを確認します。そうでない場合、ホームエージェントはこのメッセージを静かに破棄します。一致する擬似ホームアドレスが見つかると、ホームエージェントは、擬似ホームアドレス謝辞オプションでホームテストメッセージを生成し、モバイルノードに送信します。Pseudo Homeアドレス謝辞オプションの内部では、ステータスフィールドはゼロ（成功）に設定され、擬似ホームアドレスフィールドは見つかった擬似ホームアドレスで満たされています。
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への実験的拡張について説明します。実験目的で、実験的IPv6オプションタイプ、実験的IPv6ルーティングヘッダータイプ、およびRFC 4727 [12]およびRFC 5096 [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.
このモビリティオプションは、バインディングアップデートメッセージやホームテストINITメッセージを含むモビリティヘッダーに含まれており、ゼロまたは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.
擬似ホームアドレス確認モビリティオプションを識別するためのユニークなタイプ（予約済みフィールドの「A」ビットと一緒に）。実験目的のために、このタイプの値は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.
タイプフィールドと長さフィールドを除く擬似ホームアドレスモビリティオプションの長さ。擬似ホームアドレスフィールドが存在しない場合は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.
「A」ビット。これは、これが擬似ホームアドレスモビリティオプションであることを示すためにゼロに設定する必要があります。残りのビットは、送信者によってゼロとして設定され、受信機によって無視される必要があります。
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.
存在する場合、フィールドには、モバイルノードがホームエージェントに擬似ホームアドレスを要求する場合、モバイルノードがロケーションプライバシー保護に使用したいという擬似ホームアドレスが含まれています。モバイルノードがホームエージェントがロケーションプライバシーソリューションをサポートするかどうかを発見することのみを意図している場合、このフィールドは存在しません。長さフィールドは、擬似ホームアドレスフィールドが擬似ホームアドレスモビリティオプションに存在するかどうかを検出するために使用されます。
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.
このモビリティオプションは、拘束力のある確認メッセージやモバイルノードに送信されたホームテストメッセージなど、モビリティヘッダーに含まれており、ゼロまたは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.
擬似ホームアドレス確認モビリティオプションを識別するためのユニークなタイプ（予約済みフィールドの「A」ビットと一緒に）。実験目的のために、このタイプの値は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.
擬似ホームアドレス確認モビリティオプションの長さタイプフィールドと長さフィールドを除くオプション。擬似ホームアドレスフィールドが存在しない場合は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.
「A」ビット。これは、これが擬似ホームアドレス謝辞モビリティオプションであることを示すために設定する必要があります。残りのビットは、送信者によってゼロとして設定され、受信機によって無視される必要があります。
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
0成功128失敗、理由不特定129管理上禁止130誤った擬似ホームアドレス131無効な擬似ホームアドレス132ダイナミック擬似ホームアドレスの割り当ては利用できない
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.
存在する場合、フィールドには、ホームエージェントがモバイルノードを登録してロケーションプライバシー保護に使用する擬似ホームアドレスが含まれています。このフィールドは、ホームエージェントがモバイルノードからのクエリへの応答としてロケーションプライバシーソリューションをサポートすることを示す必要がある場合に存在しません。長さフィールドは、擬似ホームアドレスフィールドが擬似ホームアドレス確認モビリティオプションに存在するかどうかを検出するために使用されます。
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.
擬似ホームアドレスを使用した返品ルー上の手順は、元の返品ルーティング可能性手順の同じ原則に従います。つまり、メッセージ交換は、モバイルノードが擬似ホームアドレスとケアオブアドレスの両方で到達可能であることを確認します（これは擬似のためですホームアドレスはルーティング可能である必要があります）。さらに、拡張された返品ルー上の手順は、攻撃から保護するために、NonCE、ノードキー、シーケンス番号など、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で指定されたホームアドレスオプションの処理ルールと同様に、このドキュメントは、暗号化されたホームアドレスオプションの使用を制限します。暗号化された（pseudo）ホームアドレスを含む確立されたバインディングキャッシュエントリがある場合にのみ使用できます。
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.
提案されたロケーションプライバシーソリューションにより、暗号化されたホームアドレスルーティングヘッダーを使用して、暗号化された（pseudo）ホームアドレスを運ぶために使用されます。タイプ2ルーティングヘッダーのRFC 3775で指定された同じ脅威は、ルーティングヘッダーが暗号化された（pseudo）ホームアドレスを運ぶ場合にも可能です。このドキュメントでは、同様の処理ルールもこのような脅威に対処するために使用されています。暗号化された（擬似）ホームアドレスルーティングヘッダーの暗号化された（擬似）ホームアドレスが、バインディングアップデートリストエントリに保存されているものと一致しない場合、パケットはドロップされます。
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.
私たちの仕事は、以前の仕事とこのトピックに関する議論の恩恵を受けています。擬似ホームアドレスの概念と同様に、多くのドキュメントが一時的なIDを使用して、IPSECセキュリティ協会のモバイルノードのホームアドレス、モバイルIPv6シグナリングメッセージ、およびデータパケットを置き換えることを提案しています。ただし、このアイデンティティを生成および更新する方法の詳細はありません。以下では、関連する研究の調査を提供します。
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アドレス更新の間隔についても説明します。
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はルーティングできません。したがって、ホームエージェントが特派員ノードに転送するホームテストINITメッセージのソース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]では、著者はホームアドレスとしてアイデンティティを使用するメカニズムを提案し、キーと以前のアイデンティティを暗号化アルゴリズムへの入力として定期的に更新します。
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:
このドキュメントでは、擬似ホームアドレス確認モビリティオプションのステータスフィールドの新しいレジストリ「擬似ホームアドレス確認ステータスコード」を作成します。現在の値はセクション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つの方法について説明しました。最初の方法は、バインディングアップデートとデータパケットで実際のホームアドレスを非表示にするための返品ルーティング可能性を拡張します。この方法では、ルーティング可能性シグナル伝達の見返りに実際のホームアドレスを使用しており、ホームエージェントの変更は必要ありません。2番目の方法では、返品ルー上の信号から始まる擬似ホームアドレスを使用し、ホームエージェントの操作にいくつかの拡張機能を必要とします。この方法は、HA-CNパスの実際のホームアドレスを明らかにすることを保護します。2つの方法は、盗聴者から実際のホームアドレスを隠す手段を提供し、2番目の方法は特派員からそれを隠すこともできます。
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.
提案したソリューションは、RFC 3775で指定されている基本的なモバイルIPv6プロトコル用です。最近、NEMO基本サポートプロトコル[19]、デュアルスタックモバイルIPv6サポート[20]、複数の複数のモバイルIPv6への多くの拡張が提案されています。Care-of Careは、登録[21]、拘束力のある取り消し[22]、一般的なシグナル伝達メッセージ[23]に対処します。提案されたロケーションプライバシーソリューションは、必要に応じて、これらの拡張機能を使用したときにロケーションプライバシーの問題に対処するために、いくつかの変更を加えることができると予想されます。私たちの将来の作業の1つは、新しいモバイル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.
著者は、Vijay Devarapalli、Hannu Flinck、Charlie Perkins、Feng Bao、Robert Deng、James Kempf、およびJianying Zhou：Vijay Devarapalli、Hannu Flinck、Charlie Perkins、およびJianying Zhouなどの以前の文書の共著者に感謝したいと思います。さらに、Claude Castelluccia、Francis Dupont、Gabriel Montenegro、Greg Daley、Kilian Weniger、Kilian Weniger、Kilian Weniger、Takashi aramaki、Wassim Haddad、Heejin Jang、Michael Welzlにも、貴重な貢献、レビュー、議論に誠実な感謝が拡大されています。ファンZhaoによる仕事は、彼がカリフォルニア大学、デイビス、Marvell Semiconductor、Inc.にいた間に行われました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[2] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[3] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[3] Kent、S。、「セキュリティペイロード（ESP）のカプセル化IP」、RFC 4303、2005年12月。
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[4] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[5] Deering、S。and 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] Johnson、D.、Perkins、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. Dupont、「IPSECを使用してモバイルノードとホームエージェント間のモバイルIPv6シグナル伝達を保護する」、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. Dupont、「IKEV2および改訂されたIPSECアーキテクチャによるモバイルIPv6操作」、RFC 4877、2007年4月。
[9] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[9] Hinden、R。and S. Deering、「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. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、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] Fenner、B。、「IPv4、IPv6、ICMPV4、ICMPV6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
[13] Devarapalli, V., "Mobile IPv6 Experimental Messages", RFC 5096, December 2007.
[13] Devarapalli、V。、「モバイルIPv6実験メッセージ」、RFC 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] Bao、F.、Deng、R.、Kempf、J.、Qiu、Y。、およびJ. Zhou、「モバイル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] Bao、F.、Deng、R.、Kempf、J.、Qiu、Y。、およびJ. Zhou、「モバイルIPv6におけるモバイルノードの移動を隠すためのプロトコル」、2005年3月、進行中の作業。
[16] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple Privacy Extension for Mobile IPv6", Work in Progress, July 2006.
[16] Castelluccia、C.、Dupont、F。、およびG. Montenegro、「モバイルIPv6の単純なプライバシー拡張機能」は、2006年7月に進行中です。
[17] Daley, G., "Location Privacy and Mobile IPv6", Work in Progress, January 2004.
[17] Daley、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. Aramaki、「トンネリングエージェント（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.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、2005年1月。
[20] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[20] Soliman、H。、「デュアルスタックホストとルーターのモバイルIPv6サポート」、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.、Ernst、T。、およびK. Nagami、「複数のケアオブアドレス登録」、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.、Khalil、M.、Gundavelli、S.、Chowdhury、K。、およびP. Yegani、「IPv6 Mobilityの拘束力のある取り消し」、2009年10月の作業。
[23] Haley, B. and S. Gundavelli, "Mobile IPv6 Generic Signaling Message", Work in Progress, August 2008.
[23] Haley、B。and S. Gundavelli、「モバイルIPv6ジェネリックシグナル伝達メッセージ」、2008年8月の作業。
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アドレスの場所のプライバシーに対するソリューションを設計する際に、プロファイリングの問題を考慮しました。ただし、プロファイリングの問題が複数のプロトコル層にまたがるため、プロファイリング攻撃のすべての側面が対処されるわけではありません。以下では、プロファイリング攻撃と保護メカニズムに関する幅広い議論を提供します。私たちの議論は、プロファイリング攻撃の実行方法に基づいて組織されています。次のセクションは、基準に基づいてソートされていないか、考えられるすべての攻撃手段を徹底的にリストすることはできないことに注意してください（たとえば、データパケットの上層層ペイロードに基づいて攻撃をプロファイリングすることは説明されていません）。
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アドレスアドレスプライバシー拡張機能を使用して、定期的にケアオブアドレスを更新することをお勧めします。さらに、Eavesdroppersは共通のネットワークプレフィックスに基づいて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.
シグナリングオーバーヘッドを減らすために、バインディング更新手順を実行する必要があるため、モバイルノードは、ホームエージェントまたは特派員ノードでのバインディングキャッシュ入力が行われたときにモバイルノードを選択することができます。期限切れです。
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.
リアルまたはプソイドホームアドレスのいずれかから生成された暗号化されたホームアドレスを動的に更新できます。これは、リターンルー上のプロシージャの新しいラウンドが実行されると新しいキーが生成されるため、暗号化されたホームアドレスが後続のバインディングアップデートで異なるように見えます。謝辞メッセージ。それにもかかわらず、同じ暗号化されたホームアドレスは、リターンルーティング可能性手順の次のラウンドの前に最適化されたルートを介して転送されるペイロードパケットで使用されます。暗号化されたホームアドレスを更新するコストとオーバーヘッドを考えると、提案されているロケーションプライバシーソリューションは、このようなプロファイリング攻撃に対する合理的なレベルの保護を提供します。
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を定期的に更新する必要があります。1つの方法は、モバイルノードとホームエージェントがIPSECセキュリティ協会を再キーまたは定期的に再認証することです。これにより、オーバーヘッドが増える可能性があります。もう1つの方法は、モバイルノードまたはホームエージェントが新しいSPIを生成し、既存のIPSECセキュリティ関連によって非ヌル暗号化アルゴリズムと保護されているバインディングアップデートと確認メッセージを交換することにより、相互に通知することです。このようにして、新しいSPIの情報は盗聴者から隠されています。新しいSPIは、他の既存のSPIと競合してはなりません。また、一方のエンドポイントで競合が検出された場合、別のSPIを生成し、もう1つのエンドポイントと同期する必要があります。新しいSPIは、このIPSECセキュリティ協会によって保護される必要がある次のパケットに適用されます。このソリューションでは、モバイルIPとIPSECの間の密接な相互作用が必要です。たとえば、ホームエージェントがモバイルノードによって提案された新しいSPIを受信する場合、対応するセキュリティ協会データベース（SAD）エントリを変更する必要があります。
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.
Anti Replayサービスが有効になっている場合、IPSECシーケンス番号は、以前の有効なIPSECパケットのそれよりも大きくする必要があります。ただし、IPSECシーケンス番号の増分が固定されている場合（たとえば、IPSECシーケンス番号が順次増加します）、盗聴者は同じモバイルノードにあるIPSECパケットのシーケンスを識別し、モバイルノードのアクティビティ。考えられる解決策の1つは、IPSECセキュリティ協会の両方のエンドポイント（つまり、モバイルノードとホームエージェント）のIPSECシーケンス番号の増分をランダム化することです。ランダム性を生成するアルゴリズムは実装固有です。たとえば、あらゆる乱数ジェネレーターであり、各エンドポイントで独立して選択される可能性があります。
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秒ごとに実行する必要があり、ホームバインディングアップデート手順を定期的に実行する必要があります。このようなタイミングにより、盗聴者はトラフィック分析を実行し、異なるメッセージを相関させることができます。バックグラウンドトラフィックとルーティングダイナミクスのため、特定の視点で盗聴者によって観察されるメッセージのタイミングは不規則である可能性があります。それにもかかわらず、より良い解決策は、ホームエージェントと特派員ノードの結合キャッシュエントリの寿命をランダム化することです。
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では、バインディングアップデートメッセージのシーケンス番号が、特定のモバイルノードの以前の有効なバインディングアップデートメッセージのシーケンス番号よりも大きくなることが必要です。ただし、ホームまたは特派員のバインディングアップデートメッセージのシーケンス番号の増分が固定されている場合（たとえば、シーケンス番号が順次増加します）、MN-HAまたはMN-CNパスの盗聴者がシーケンスを識別することが可能です同じモバイルノードからのバインディングアップデートメッセージのメッセージとモバイルノードの動きを追跡します。考えられる解決策の1つは、モバイルノードが後続のバインディングアップデートメッセージで使用されるシーケンス番号の増分をランダム化することです。ランダム性を生成するアルゴリズムは実装固有です。たとえば、あらゆる乱数ジェネレーターにすることができます。このようなアルゴリズムは、シーケンス番号が暗号化されている場合、たとえば、ホームバインディングアップデートメッセージがIPSECトンネルモードセキュリティアソシエーションによって保護されている場合には不要であることに注意してください。
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.
（共謀した）盗聴者は、同じ擬似ホームアドレスや同じケアアドレスに基づいて、モバイルノードの異なるセッションを同じまたは異なる特派員ノードと相関させる可能性があります。可能な解決策は、さまざまなセッションで異なる擬似ホームアドレスとさまざまなケアの住所を使用することです。モバイルノードは、異なる特派員ノードを使用した返品ルー上の手順中に生成された異なるプライバシー管理キーによって擬似ホームアドレスがマスクされている場合、異なる特派員ノードを持つ同じ擬似ホームアドレスを使用する場合があることに注意してください。このように、異なる特派員ノードで使用される暗号化された擬似ホームアドレスは、盗聴者とは異なるように見えます。
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
Ying Qiu Instocomm Research、Singapore 1 Fusionopolis Way＃21-01 Connexis（South Tower）シンガポール138632
Phone: +65-6408 2053
EMail: qiuying@i2r.a-star.edu.sg
Fan Zhao (editor) Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 US
ファンZhao（編集者）Google Inc. 1600 Amphitheater Parkway Mountain View、CA 94043 US
EMail: fanzhao@google.com
Rajeev Koodli Cisco Systems
Rajeev Koodli Cisco Systems
EMail: rkoodli@cisco.com