[要約] 要約：RFC 4882は、IPアドレスの位置情報プライバシーとモバイルIPv6に関する問題を説明しています。 目的：このRFCの目的は、IPアドレスの位置情報のプライバシーに関する問題を特定し、モバイルIPv6のコンテキストでの解決策を提案することです。
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
IPアドレスの場所プライバシーとモバイルIPv6：問題ステートメント
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）The IETF Trust（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プライバシーは、ユーザーコミュニケーションを、機密性の高いユーザーデータを分析および収集するために使用できる無意識のうちに明らかにする情報から保護することに非常に関心があります。例には、特定の見晴らしの良い場所でデータを収集し、特定のトラフィックに関連する情報の収集、（おそらく）1日の特定の時期にアクティビティの特定のユーザーの集団などが含まれます。このドキュメントでは、これを「プロファイリング」問題と呼んでいます。。
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）のプロセスとして定義しています。グローバルスコープを持つ定数識別子は、ローミングを明らかにすることができます。例は、IPアドレスなどのデバイス識別子と、SIP [RFC3261] URI [RFC3986]などのユーザー識別子です。多くの場合、これら2つの識別子間の結合が利用可能です。たとえば、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にとって特に重要です。さらに、ユーザーは、通信員へのローミングを明らかにしたくない場合があります。これは、住所のケアの使用につながります。自宅の住所と同様に、住所の世話はモバイルノードのトポロジカル位置を明らかにすることもできます。
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
o モバイルノード（MN）：ネットワークを自由に回転するモバイルIPv6モバイルノード
o Correspondent Node (CN): A Mobile IPv6 that node corresponds with an MN
o 特派員ノード（CN）：ノードがMNに対応するモバイルIPv6
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
o ホームアドレス（HOA）：MNのホームネットワークで有効なユニキャストIPアドレス
o Care-of Address (CoA): The MN's unicast IP address valid on the visited network
o Care-of Address（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がホームネットワークから訪問されたネットワーク、または訪問されたネットワークから別のネットワークにローミングすると、特派員との通信における住所のケアの使用が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がホームネットワークから訪問されたネットワーク、または訪問されたネットワークから別のネットワークにローミングすると、コミュニケーションでホームアドレスを使用すると、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ソリューションでは、ロケーションのプライバシーに対する保護があります。モバイルノードが、セキュリティペイロード（ESP）暗号化をカプセル化する逆トンネルを使用している場合、Mn -haパスではホームアドレスが明らかにされません。したがって、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アドレスが表示されます。IP通信の詳細に興味がない、または気づかないユーザーは、MNが新しいIPアドレスを取得した場合、違いは見られません。もちろん、どのユーザーもセッションを「TCPDUMP」または「Ethereal」し、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へのケアのケアを保護することができることを見てきました。また、内側のIPパケットのESP暗号化により、MNはMN -HAパスの見物人からホームアドレスを保護できます。ただし、ルートの最適化により、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 -haおよびMn -CNパスに沿ってホームアドレスを開示することからモバイルIPv6シグナル伝達メッセージを保護することを検討する必要があります。
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がルートの最適化を使用したい場合、住所のケアを開示することは避けられません。訪問されたリンク上のMNのオンリンクアドレスであるかどうかに関係なく、CNがローミングを確認するには、バインディングキャッシュエントリの単なる存在で十分です。したがって、ロケーションのプライバシーに関係する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 if appropriate trade-offs with Return Routability signaling are taken into account.
また、セクション4「問題のイラスト」で説明したように、一時的なアドレスの使用とモバイルIPv6シグナル伝達に対するそれらの意味も考慮する必要があります。プライバシー拡張機能[RFC3041]を使用したIPアドレスの使用は、返品可能性シグナル伝達を備えた適切なトレードオフが考慮されている場合、ケアオブアドレスに特に役立ちます。
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.
James Kempf、Qiu Ying、Sam Xia、およびLakshminath Dondetiは、レビューとフィードバックを認められています。ラストコールのレビューと改善とテキストを提案してくれたJari ArkkoとKilian Wenigerに感謝します。問題の範囲を改善するためのテキストを提供してくれたSam Hartmanに感謝します。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Haddad、W.、et al。、「モバイルおよびマルチホームのノードのプライバシー：問題ステートメント」作業中の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] Berners-Lee、T.、Fielding、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. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、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のステートレスアドレスAutoconfigurationのプライバシー拡張」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、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] Polk、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] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
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メッセージが「ホームネットワーク」タイムゾーン（ロケーションプライバシーなど）のタイムスタンプがあることに気付いた場合があります。「時刻。さらに、IPアドレスをISPの物理アドレスまたはプレフィックスチャンクを所有する組織にマッピングできるツールがインターネットに存在します。これを別のステップに導き、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
Rajeev Koodli Nokia Siemens Networks 313 Fairchild Drive Mountain View、CA 94043
EMail: rajeev.koodli@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。