Network Working Group R. Koodli
Request for Comments: 4882 Nokia Siemens Networks
Category: Informational May 2007
IP Address Location Privacy and Mobile IPv6: Problem Statement
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
In this document, we discuss location privacy as applicable to Mobile IPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent.
この文書では、我々は、モバイルIPv6への適用可能な位置プライバシーを議論します。我々は傍観者にホームアドレスを明らかにし、対応する気付アドレスを開示から生じる懸念を文書化します。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions .....................................................3
3. Problem Definition ..............................................4
3.1. Disclosing the Care-of Address to the Correspondent Node ...4
3.2. Revealing the Home Address to Onlookers ....................4
3.3. Problem Scope ..............................................4
4. Problem Illustration ............................................5
5. Conclusion ......................................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................8
Appendix A. Background ............................................10
The problems of location privacy, and privacy when using IP for communication, have become important. IP privacy is broadly concerned with protecting user communication from unwittingly revealing information that could be used to analyze and gather sensitive user data. Examples include gathering data at certain vantage points, collecting information related to specific traffic, and monitoring (perhaps) certain populations of users for activity during specific times of the day, etc. In this document, we refer to this as the "profiling" problem.
位置プライバシー、およびプライバシーの問題通信用IPを使用して、重要になってきました。 IPプライバシーは無意識のうちに敏感なユーザデータを分析し、収集するために使用できる情報を明らかにすることから、ユーザの通信を保護すると広く関係します。例は、この文書でなど、特定の有利な点でデータを収集し、特定のトラフィックに関連する情報を収集し、その日の特定の時間の間に（おそらく）活性のためのユーザの特定の集団を監視含む、我々は、「プロファイリング」問題としてこれを参照します。
Location privacy is concerned with the problem of revealing roaming, which we define here as the process of a Mobile Node (MN) moving from one network to another with or without ongoing sessions. A constant identifier with global scope can reveal roaming. Examples are a device identifier such as an IP address, and a user identifier such as a SIP [RFC3261] URI [RFC3986]. Often, a binding between these two identifiers is available, e.g., through DNS [RFC1035]. Traffic analysis of such IP and Upper Layer Protocol identifiers on a single network can indicate device and user roaming. Roaming could also be inferred by means of profiling constant fields in IP communication across multiple network movements. For example, an Interface Identifier (IID) [RFC2462] in the IPv6 address that remains unchanged across networks could suggest roaming. The Security Parameter Index (SPI) in the IPsec [RFC4301] header is another field that may be subject to such profiling and inference. Inferring roaming in this way typically requires traffic analysis across multiple networks, or colluding attackers, or both. When location privacy is compromised, it could lead to more targeted profiling of user communication.
場所のプライバシーは私達が進行中のセッションの有無にかかわらずあるネットワークから別のネットワークに移動するモバイルノード（MN）のプロセスとして、ここで定義するローミング明かすの問題、と懸念しています。グローバルスコープを持つ定数識別子は、ローミングを明らかにすることができます。例としては、SIP [RFC3261] URI [RFC3986]のようにIPアドレスなどのデバイス識別子、およびユーザ識別子です。しばしば、これらの二つの識別子の間の結合DNS [RFC1035]を介して、例えば、利用可能です。単一のネットワーク上のIPや上位層プロトコル識別子のトラフィック分析は、デバイスとユーザのローミングを示すことができます。ローミングは、複数のネットワークの動きを横切ってIP通信で一定フィールドプロファイリングによって推測することができます。例えば、ネットワーク間変わらないIPv6アドレスのインタフェース識別子（IID）[RFC2462]は、ローミングを示唆している可能性があります。 IPsecの[RFC4301]ヘッダーのセキュリティパラメータインデックス（SPI）は、プロファイリングおよび推論の対象とすることができる別の分野です。このように、ローミング推論することは一般的に、複数のネットワーク間でトラフィック分析を必要とする、または共謀攻撃者、またはその両方。位置プライバシーが侵害された場合は、ユーザ通信のよりターゲットを絞ったプロファイリングにつながる可能性があります。
As can be seen, the location privacy problem spans multiple protocol layers. Nevertheless, we can examine problems encountered by nodes using a particular protocol layer. Roaming is particularly important to Mobile IP, which defines a global identifier (Home Address) that can reveal device roaming, and in conjunction with a corresponding user identifier (such as a SIP URI), can also reveal user roaming. Furthermore, a user may not wish to reveal roaming to correspondent(s), which translates to the use of a Care-of Address. As with a Home Address, the Care-of Address can also reveal the topological location of the Mobile Node.
図から分かるように、ロケーション・プライバシーの問題は、複数のプロトコル層にまたがります。それにもかかわらず、我々は特定のプロトコル層を使用してノードが直面する問題を調べることができます。ローミングは、デバイスのローミングを明らかにすることができ、そして（例えばSIP URIなど）は、対応するユーザ識別子に関連して、また、ユーザローミングを明らかにすることができるグローバル識別子（ホームアドレス）を定義し、モバイルIP、特に重要です。さらに、ユーザは、気付アドレスを使用することに変換され、コレスポンデント（S）へのローミング明らかにすることを希望しない場合があります。ホームアドレスと同じように、気付アドレスはまた、モバイルノードの位相的な位置を明らかにすることができます。
This document scopes the problem of location privacy for the Mobile IP protocol. The primary goal is to prevent attackers on the path between the Mobile Node (MN) and the Correspondent Node (CN) from detecting roaming due to the disclosure of the Home Address. The attackers are assumed to be able to observe, modify, and inject traffic at one point between the MN and the CN. The attackers are assumed not to be able to observe at multiple points and correlate observations to detect roaming. For this reason, MAC addresses, IIDs, and other fields that can be profiled to detect roaming are only in scope to the extent that they can be used by an attacker at one point. Upper layer protocol identifiers that expose roaming are out of scope except that a solution to the problem described here needs to be usable as a building block in solutions to those problems.
この文書では、モバイルIPプロトコルのロケーションプライバシーの問題をスコープ。第一の目標は、ホームアドレスの開示によるローミング検出からモバイルノード（MN）と通信相手ノード（CN）との間のパス上の攻撃を防ぐためです。攻撃者は、観察することができるように変更して、MNとCNとの間の一点でトラフィックを注入すると想定されています。攻撃者は、複数のポイントで観察し、ローミングを検出するための観測を相関させることはできないものとされています。この理由のため、MACアドレス、のIID、およびローミングを検出するためにプロファイリングすることができる他のフィールドは、それらが一点で攻撃者によって使用することができる程度の範囲内のみです。ローミングを露出上位層プロトコル識別子は、ここで記載された問題に対する解決策は、これらの問題の解決策におけるビルディングブロックとして使用する必要があることを除いて範囲外です。
This document also considers the problem from the exposure of a Care-of Address to the CN.
また、このドキュメントでは、気付アドレスCNへの暴露から問題を検討します。
This document is only concerned with IP address location privacy in the context of Mobile IPv6. It does not address the overall privacy problem. For instance, it does not address privacy issues related to MAC addresses or the relationship of IP and MAC addresses [HADDAD], or the Upper Layer Protocol addresses. Solutions to the problem specified here should provide protection against roaming disclosure due to using Mobile IPv6 addresses from a visited network.
この文書では、モバイルIPv6のコンテキストでIPアドレス位置プライバシーを持つ唯一の懸念です。これは、全体的なプライバシーの問題に対処していません。例えば、それはMACアドレスやIPアドレスとMACアドレス[HADDAD]、または上位層プロトコルアドレスの関係に関連するプライバシーの問題に対処しません。ここで指定された問題に対する解決策が原因訪問ネットワークからモバイルIPv6アドレスを使用して開示をローミングに対する保護を提供する必要があります。
This document assumes that the reader is familiar with the basic operation of Mobile IPv6 [RFC3775] and the associated terminology defined therein. For convenience, we provide some definitions below.
この文書は、読者がモバイルIPv6 [RFC3775]と、その中に画定された関連用語の基本的な動作に精通していることを前提としています。利便性のために、私たちは以下のいくつかの定義を提供しています。
o Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams around networks
モバイルIPv6モバイルノード自由にネットワークの周りローミング：モバイルノード（MN）O
o Correspondent Node (CN): A Mobile IPv6 that node corresponds with an MN
Oの対応ノード（CN）：モバイルIPv6ノードがMNと対応していること
o Home Network: The network where the MN is normally present when it is not roaming
Oホームネットワーク：それはローミングされていない場合にMNが通常存在するネットワーク
o Visited Network: A network that an MN uses to access the Internet when it is roaming
O訪問先ネットワーク：それはローミングしているときMNは、インターネットへのアクセスに使用するネットワーク
o Home Agent: A router on the MN's home network that provides forwarding support when the MN is roaming
Oホームエージェント：MNがローミングしているときの転送のサポートを提供してMNのホームネットワーク上のルータ
o Home Address (HoA): The MN's unicast IP address valid on its home network
そのホームネットワーク上の有効なMNのユニキャストIPアドレス：Oホームアドレス（HoA）
o Care-of Address (CoA): The MN's unicast IP address valid on the visited network
O気付アドレス（CoA）：訪問先ネットワーク上の有効なMNのユニキャストIPアドレス
o Reverse Tunneling or Bidirectional Tunneling: A mechanism used for packet forwarding between the MN and its Home Agent
Oリバーストンネリングまたは双方向トンネリング：MNとホームエージェント間のパケット転送のために使用されるメカニズム
o Route Optimization: A mechanism that allows direct routing of packets between a roaming MN and its CN, without having to traverse the home network
Oルート最適化：ローミングMNとCNの間のパケットの直接ルーティングを可能にする機構、ホームネットワークを通過することなく
When a Mobile IP MN roams from its home network to a visited network or from one visited network to another, use of Care-of Address in communication with a correspondent reveals that the MN has roamed. This assumes that the correspondent is able to associate the Care-of Address to the Home Address, for instance, by inspecting the Binding Cache Entry. The Home Address itself is assumed to have been obtained by whatever means (e.g., through DNS lookup).
モバイルIP MNが訪問先ネットワークにまたは1つの訪問先ネットワークから別のホームネットワークからローミングする場合、特派と通信している気付アドレスを使用するには、MNがローミングしたことが明らかになりました。これは、特派バインディングキャッシュエントリを調べることによって、例えば、ホームアドレスに気付アドレスを関連付けすることが可能であることを前提としています。ホームアドレス自体は、どんな手段（例えば、DNSルックアップを介して）によって得られていると想定されます。
When a Mobile IP MN roams from its home network to a visited network or from one visited network to another, use of a Home Address in communication reveals to an onlooker that the MN has roamed. When a binding of a Home Address to a user identifier (such as a SIP URI) is available, the Home Address can be used to also determine that the user has roamed. This problem is independent of whether the MN uses a Care-of Address to communicate directly with the correspondent (i.e., uses route optimization), or the MN communicates via the Home Agent (i.e., uses reverse tunneling). Location privacy can be compromised when an onlooker is present on the MN - CN path (when route optimization is used). It may also be compromised when the onlooker is present on the MN - HA path (when bidirectional tunneling without encryption is used; see below).
モバイルIP MNが訪問先ネットワークにそのホームネットワークからローミングするか、1から別のネットワークを訪問したとき、通信中にホームアドレスの使用は、MNがローミングしたことを傍観者に明らかになりました。 （例えば、SIP URIなどの）ユーザ識別子にホームアドレスのバインディングが利用可能である場合、ホームアドレスは、ユーザがローミングしていることを決定するために使用することができます。この問題は、MNは、（すなわち、ルート最適化を使用しています）特派と直接通信する気付アドレスを使用して、またはMNは、ホームエージェント（すなわち、リバーストンネリングを使用しています）を介して通信するかどうかとは無関係です。傍観者は、MN上に存在する場合、ロケーションプライバシーが損なわれる可能性が - （経路最適化が使用されている）、CNパス。傍観者は、MN上に存在する場合にも損なわれる可能性がある - HA路（暗号化せずに、双方向トンネリングを使用する場合、以下を参照のこと）。
With existing Mobile IPv6 solutions, there is some protection against location privacy. If a Mobile Node uses reverse tunneling with Encapsulating Security Payload (ESP) encryption, then the Home Address is not revealed on the MN - HA path. So, eavesdroppers on the MN - HA path cannot determine roaming. They could, however, still profile fields in the ESP header; however, this problem is not specific to Mobile IPv6 location privacy.
既存のモバイルIPv6ソリューションにより、位置プライバシーに対するいくつかの保護があります。 HAパス - モバイルノードは、カプセル化セキュリティペイロード（ESP）の暗号化とリバーストンネリングを使用する場合、ホームアドレスがMNに明らかにされていません。だから、MN上の盗聴者 - HAパスは、ローミング判断することはできません。彼らESPヘッダでできた、しかし、まだプロファイルフィールド。しかし、この問題は、モバイルIPv6位置プライバシーに固有ではありません。
When an MN uses reverse tunneling (regardless of ESP encryption), the correspondent does not have access to the Care-of Address. Hence, it cannot determine that the MN has roamed.
MNは、（関係なく、ESP暗号化の）リバーストンネリングを使用する場合、対応は気付アドレスにアクセスすることはできません。したがって、MNがローミングしたことを判断することはできません。
Hence, the location privacy problem is particularly applicable when Mobile IPv6 route optimization is used or when reverse tunneling is used without protecting the inner IP packet containing the Home Address.
モバイルIPv6ルート最適化が使用される場合、または逆トンネリングがホームアドレスを含む内側IPパケットを保護せずに使用した場合従って、ロケーションプライバシ問題は特に適用可能です。
This section is intended to provide an illustration of the problem defined in the previous section.
このセクションでは、前のセクションで定義された問題の実例を提供することを意図しています。
Consider a Mobile Node at its home network. Whenever it is involved in IP communication, its correspondents can see an IP address valid on the home network. Elaborating further, the users involved in peer-to-peer communication are likely to see a user-friendly identifier such as a SIP URI, and the communication endpoints in the IP stack will see IP addresses. Users uninterested in or unaware of IP communication details will not see any difference when the MN acquires a new IP address. Of course, any user can "tcpdump" or "ethereal" a session, capture IP packets, and map the MN's IP address to an approximate geo-location. This mapping may reveal the home location of a user, but a correspondent cannot ascertain whether the user has actually roamed or not. Assessing the physical location based on IP addresses has some similarities to assessing the geographical location based on the area code of a telephone number. The granularity of the physical area corresponding to an IP address can vary depending on how sophisticated the available tools are, how often an ISP conducts its network re-numbering, etc. Also, an IP address cannot guarantee that a peer is at a certain geographic area due to technologies such as VPN and tunneling.
そのホームネットワークでモバイルノードを考えてみましょう。それはIP通信に関与しているときはいつでも、その特派は、ホームネットワーク上のIPアドレスが有効で見ることができます。さらにエラボレーション、ピア・ツー・ピア通信に関与するユーザは、SIP URIのようなユーザーフレンドリーな識別子を参照する可能性があり、及びIPスタックの通信エンドポイントは、IPアドレスが表示されます。 MNが新しいIPアドレスを取得する場合における無関心やIP通信の詳細を知らないユーザーは任意の違いは表示されません。もちろん、すべてのユーザーが「tcpdumpの」または「エーテル」セッション、IPパケットをキャプチャし、おおよその地理的位置にMNのIPアドレスをマッピングすることができます。このマッピングは、ユーザーの自宅の場所を明らかにすることができるが、特派員は、ユーザーが実際にローミングしているか否かを確認することはできません。 IPアドレスに基づいて物理的な位置を評価することは、電話番号の市外局番に基づいて地理的位置を評価するにはいくつかの類似点を持っています。 IPアドレスに対応する物理領域の粒度は、ピアは、特定の地理的であることを保証することはできませんどのように洗練された利用可能なツールは、ISPが、またなど、IPアドレスをそのネットワークの再番号付けを行ってどのくらいの頻度、あるに応じて変えることができますエリアなVPNトンネリングなどの技術によるもの。
When the MN roams to another network, the location privacy problem consists of two parts: revealing information to its correspondents and to onlookers.
MNは別のネットワークにローミングする場合、ロケーションプライバシーの問題は、2つの部分から構成：その特派へと見物人に情報を明らかに。
With its correspondents, the MN can either communicate directly or reverse-tunnel its packets through the Home Agent. Using reverse tunneling does not reveal the Care-of Address of the MN, although end-to-end delay may vary depending on the particular scenario. With those correspondents with which it can disclose its Care-of Address "on the wire", the MN has the option of using route-optimized communication. The transport protocol still sees the Home Address with route optimization. Unless the correspondent runs some packet capturing utility, the user cannot see which mode (reverse tunneling or route optimization) is being used, but knows that it is communicating with the same peer whose URI it knows. This is similar to conversing with a roaming cellphone user whose phone number, like the URI, remains unchanged.
その特派では、MNは直接通信したり、逆にトンネルするか、そのパケットをホームエージェントを通して。エンドツーエンド遅延は、特定のシナリオに応じて変化し得るがリバーストンネリングを使用して、気付MNのアドレスを明らかにしません。それは「ワイヤー上」その気付アドレスを開示することが可能なものを特派して、MNは経路最適化通信を使用するオプションがあります。トランスポートプロトコルは、まだルート最適化とホームアドレスを見ています。特派員は、いくつかのパケットキャプチャユーティリティを実行しない限り、ユーザーが使用されているモード（トンネルまたは経路最適化をリバース）を参照してください、それはそのURI、それは知っている同じピアと通信していることを知っていることはできません。これは、その電話番号、URIのように、変更されないままローミング携帯電話のユーザーとの会話に似ています。
Regardless of whether the MN uses route optimization or reverse tunneling (without ESP encryption), its Home Address is revealed in data packets. When equipped with an ability to inspect packets "on the wire", an onlooker on the MN - HA path can determine that the MN has roamed and could possibly also determine that the user has roamed. This could compromise the location privacy even if the MN took steps to hide its roaming information from a correspondent.
かかわらず、MNは経路最適化や（ESP暗号化なし）リバーストンネリングを使用するかどうかの、そのホームアドレスは、データパケットに明らかにされています。 「ワイヤー上」パケットを検査する能力を備えた場合には、MN上の傍観者 - HA経路は、MNがローミングしていることを決定することができ、おそらく、ユーザがローミングしていることを決定することができます。これは、MNは通信員からのローミング情報を隠すための措置を講じた場合でも、位置プライバシーを危険にさらす可能性が。
The above description is valid regardless of whether a Home Address is statically allocated or is dynamically allocated. In either case, the mapping of IP address to a geo-location will most likely yield results with the same level of granularity. With the freely available tools on the Internet, this granularity is the physical address of the ISP or the organization that registers ownership of a prefix chunk. Since an ISP or an organization is not, rightly, required to provide a blueprint of its subnets, the granularity remains fairly coarse for a mobile wireless network. However, sophisticated attackers might be able to conduct site mapping and obtain more fine-grained subnet information.
上記の説明は関係なく、ホームアドレスが静的に割り当てられているか、動的に割り当てられているかどうかの有効です。粒度の同じレベルを有するいずれの場合も、ジオロケーションへのIPアドレスのマッピングがあろう可能性が最も高い収率をもたらします。インターネット上で自由に利用できるツールで、この粒度は、ISPまたはプレフィックスチャンクの所有権を登録する組織の物理アドレスです。 ISPまたは組織がないので、当然、そのサブネットの青写真を提供するために必要な、粒度は、モバイル無線ネットワークのためのかなり粗いままです。しかし、洗練された攻撃者は、サイトのマッピングを行い、よりきめ細かいサブネット情報を取得することができるかもしれません。
A compromise in location privacy could lead to more targeted profiling of user data. An eavesdropper may specifically track the traffic containing the Home Address, and monitor the movement of the Mobile Node with a changing Care-of Address. The profiling problem is not specific to Mobile IPv6, but could be triggered by a compromise in location privacy due to revealing the Home Address. A correspondent may take advantage of the knowledge that a user has roamed when the Care-of Address is revealed, and modulate actions based on such knowledge. Such information could cause concern to a mobile user, especially when the correspondent turns out be untrustworthy. For these reasons, appropriate security measures on the management interfaces on the MN to guard against the disclosure or misuse of location information should be considered.
ロケーションプライバシーにおける妥協は、ユーザデータのよりターゲットを絞ったプロファイリングにつながる可能性があります。盗聴者は、特にホームアドレスを含むトラフィックを追跡し、変更気付アドレスでモバイルノードの動きを監視することができます。プロファイリングの問題は、モバイルIPv6に特有のものではなく、原因のホームアドレスを明らかに位置プライバシーで妥協によってトリガすることができます。特派気付アドレスが明らかにされたときに、ユーザーがローミングしているという知識を活用して、そのような知識に基づいて行動を調節することができます。このような情報は、対応が信頼できないことが判明した場合は特に、モバイルユーザーへの懸念を引き起こす可能性があります。これらの理由から、位置情報の開示又は悪用を防ぐために、MNの管理インターフェイスに適切なセキュリティ対策が考慮されるべきです。
Applying existing techniques to thwart profiling may have implications to Mobile IPv6 signaling performance. For instance, changing the Care-of Address often would cause additional Return Routability [RFC3775] and binding management signaling. And, changing the Home Address often has implications on IPsec security association management. Careful consideration should be given to the signaling cost introduced by changing either the Care-of Address or the Home Address.
プロファイリングを阻止するために既存の技術を適用すると、モバイルIPv6のシグナリングのパフォーマンスに影響する可能性があり。例えば、気付アドレスを変更すると、多くの場合、追加の往復経路[RFC3775]と結合管理シグナリングを引き起こします。そして、多くの場合、ホームアドレスを変更すると、IPsecセキュリティアソシエーション管理上の意味を持ちます。慎重な考慮事項は、アドレスのケアやホームアドレスのどちらかを変更することにより、導入されたシグナリングコストに与えられるべきです。
When roaming, an MN may treat its home network nodes as any other correspondents. Reverse tunneling is perhaps sufficient for home network communication, since route-optimized communication will traverse the identical path. Hence, an MN can avoid revealing its Care-of Address to its home network correspondents simply by using reverse tunneling. The Proxy Neighbor Advertisements [RFC2461] from the Home Agent could serve as hints to the home network nodes that the Mobile Node is away. However, they will not be able to know the Mobile Node's current point of attachment unless the MN uses route optimization with them.
ローミングすると、MNは他の通信員としてそのホームネットワーク・ノードを処理することがあります。ルート最適化通信が同一経路を横断するので、逆トンネリングは、ホームネットワーク通信のために、おそらく十分です。したがって、MNは、単純にリバーストンネリングを使用してそのホームネットワーク特派への気付アドレスを明らかに回避することができます。ホームエージェントからプロキシ近隣広告[RFC2461]は、モバイルノードが離れているホームネットワーク・ノードへのヒントとして役立つことができます。しかし、彼らはMNが彼らとルート最適化を使用しない限り、添付ファイルの移動ノードの現在位置を知ることができません。
In this document, we have discussed the location privacy problem as applicable to Mobile IPv6. The problem can be summarized as follows: disclosing the Care-of Address to a correspondent and revealing the Home Address to an onlooker can compromise the location privacy of a Mobile Node, and hence that of a user. We have seen that bidirectional tunneling allows an MN to protect its Care-of Address to the CN. And, ESP encryption of an inner IP packet allows the MN to protect its Home Address from the onlookers on the MN - HA path. However, with route optimization, the MN will reveal its Care-of Address to the CN. Moreover, route optimization causes the Home Address to be revealed to onlookers in the data packets as well as in Mobile IPv6 signaling messages. The solutions to this problem are expected to be protocol specifications that use the existing Mobile IPv6 functional entities, namely, the Mobile Node, its Home Agent, and the Correspondent Node.
この文書では、我々は、モバイルIPv6への適用などの場所のプライバシーの問題を議論してきました。したがって、ユーザのものに対応する気付アドレスを開示し、モバイルノードの位置プライバシーを侵害することができ傍観者にホームアドレスを明らかにし、：この問題は、次のように要約することができます。私たちは、双方向トンネリングは、MNがCNへの気付アドレスを保護することを可能にすることを見てきました。 HAパス - と、内側のIPパケットのESP暗号化は、MNは、MN上の見物人からそのホームアドレスを保護することができます。しかし、経路最適化で、MNはCNへの気付アドレスを明らかにします。また、ルート最適化は、ホームアドレスは、データパケット内だけでなく、モバイルIPv6シグナリングメッセージで見物人に明らかにされます。この問題の解決策は、既存のモバイルIPv6の機能エンティティ、すなわち、モバイルノード、そのホームエージェント、および特派ノードを使用するプロトコル仕様であることが予想されます。
This document discusses the location privacy problem specific to Mobile IPv6. Any solution must be able to protect (e.g., using encryption) the Home Address from disclosure to onlookers in data packets when using route optimization or reverse tunneling. In addition, solutions must consider protecting the Mobile IPv6 signaling messages from disclosing the Home Address along the MN - HA and MN - CN paths.
この文書では、モバイルIPv6への特定の場所のプライバシーの問題について説明します。すべてのソリューションは、ルート最適化を使用した場合、データパケット内の見物人に開示からホームアドレス（暗号化を使用して、例えば）を保護することができたり、トンネルを逆にしなければなりません。また、解決策は、MNに沿ってホームアドレスを開示からモバイルIPv6シグナリングメッセージを保護考慮する必要があります - HAとMN - CNパスを。
Disclosing the Care-of Address is inevitable if an MN wishes to use route optimization. Regardless of whether the Care-of Address is an on-link address of the MN on the visited link or that of a cooperating proxy, mere presence of a Binding Cache Entry is sufficient for a CN to ascertain roaming. Hence, an MN concerned with location privacy should exercise prudence in determining whether to use route optimization with, especially previously unacquainted, correspondents.
MNは経路最適化を使用したい場合は気付アドレスを開示することは避けられません。 CNは、ローミングを確認するためにかかわらず気付アドレスが訪問したリンクや協力プロキシのようにMNのオンリンクのアドレスであるかどうかの、バインディングキャッシュエントリが存在するだけで十分です。そのため、ロケーションプライバシーに関するMNは、特に以前に面識のない、との経路最適化を使用するかどうかを決定する際に特派を慎重に行使しなければなりません。
The solutions should also consider the use of temporary addresses and their implications on Mobile IPv6 signaling as discussed in Section 4, "Problem Illustration". Use of IP addresses with privacy extensions [RFC3041] could be especially useful for Care-of Addresses
ソリューションはまた、「問題のイラスト」、第4章で述べたように、シグナリング一時アドレスとモバイルIPv6上での意味合いの使用を検討すべきです。プライバシー拡張[RFC3041]でIPアドレスを使用すると、気付アドレスのために特に有用である可能性
if appropriate trade-offs with Return Routability signaling are taken into account.
往復経路のシグナル伝達と適切なトレードオフが考慮されている場合。
James Kempf, Qiu Ying, Sam Xia, and Lakshminath Dondeti are acknowledged for their review and feedback. Thanks to Jari Arkko and Kilian Weniger for the last-call review and for suggesting improvements and text. Thanks to Sam Hartman for providing text to improve the problem scope.
ジェームズ・ケンプ、チウ・イン、サム夏、そしてLakshminath Dondetiは彼らのレビューとフィードバックのために認められています。最後のコールレビューのために、改善とテキストを示唆ためのヤリArkkoとキリアンWenigerに感謝します。問題の範囲を改善するためのテキストを提供するためのサム・ハートマンに感謝します。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[HADDAD] Haddad, W., et al., "Privacy for Mobile and Multi-homed Nodes: Problem Statement" Work in Progress, June 2006.
[HADDAD]ハダッド、W.ら、「モバイルおよびマルチホームノードのプライバシー：問題文」。進歩、2006年6月での作業。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[RFC3825]ポーク、J.、Schnizlein、J.、およびM. Linsner、 "座標ベースのロケーションの設定については、動的ホスト構成プロトコル・オプション"、RFC 3825、2004年7月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
Appendix A. Background
付録A.背景
The location privacy topic is broad and often has different connotations. It also spans multiple layers in the OSI reference model. Besides, there are attributes beyond an IP address alone that can reveal hints about location. For instance, even if a correspondent is communicating with the same endpoint it is used to, the "time of day" attribute can reveal a hint to the user. Some roaming cellphone users may have noticed that their SMS messages carry a timestamp of their "home network" time zone (for location privacy or otherwise), which can reveal that the user is in a different time zone when messages are sent during a "normal" time of the day. Furthermore, tools exist on the Internet that can map an IP address to the physical address of an ISP or the organization that owns the prefix chunk. Taking this to another step, with built-in GPS receivers on IP hosts, applications can be devised to map geo-locations to IP network information. Even without GPS receivers, geo-locations can also be obtained in environments where "Geopriv" is supported, for instance, as a DHCP option [RFC3825]. In summary, a user's physical location can be determined or guessed with some certainty and with varying levels of granularity by different means, even though IP addresses themselves do not inherently provide any geo-location information. It is perhaps useful to bear this broad scope in mind as the problem of IP address location privacy in the presence of IP Mobility is addressed.
ロケーションプライバシートピックは幅広く、多くの場合、異なる意味合いを持っています。また、OSI参照モデルでは、複数の層にまたがります。また、場所に関するヒントを明らかにすることができますだけではIPアドレスを超えた属性があります。例えば、通信員は、それがために使用されているのと同じエンドポイントと通信している場合でも、属性「時刻」は、ユーザへのヒントを明らかにすることができます。携帯電話ユーザーをローミング中には、彼らのSMSメッセージは、メッセージが「通常時に送信された場合、ユーザが異なるタイムゾーンにあることを明らかにすることができます（位置プライバシーまたはその他のために）自分の「ホームネットワーク」のタイムゾーンのタイムスタンプを運ぶことに気づいたかもしれませんその日の "時間。さらに、ツールは、ISPの物理アドレスまたはプレフィックスのチャンクを所有する組織にIPアドレスをマッピングすることができ、インターネット上に存在します。 IPホストに内蔵のGPS受信機を用いて、別のステップにこれを取って、アプリケーションは、IPネットワーク情報に地理的位置をマッピングするために考案することができます。 GPS受信機なしで、地理的位置は、「Geoprivは」DHCPオプション[RFC3825]として、例えば、サポートされている環境で得ることができます。 IP自体に対処していても、異なる手段によって要約すると、ユーザの物理的な位置を決定することができる、またはいくつかの確実でかつ粒度のさまざまなレベルと推測本質的に任意のジオロケーション情報を提供しません。 IPモビリティの存在下でのIPアドレス位置プライバシーの問題が対処されるように、心の中で、この広い範囲を負担する、おそらく便利です。
Author's Address
著者のアドレス
Rajeev Koodli Nokia Siemens Networks 313 Fairchild Drive Mountain View, CA 94043
ラジーブKoodliノキア・シーメンス・ネットワーク313フェアチャイルドドライブマウンテンビュー、CA 94043
EMail: rajeev.koodli@nokia.com
メールアドレス：rajeev.koodli@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。