RFC4882 日本語訳

Network Working Group                                          R. Koodli
Request for Comments: 4882                        Nokia Siemens Networks
Category: Informational                                         May 2007

Koodliがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4882 ノキアシーメンスはカテゴリをネットワークでつなぎます: 情報の2007年5月

     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).

IETFが信じる著作権(C)(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に適切であるとして位置のプライバシーについて議論します。 私たちが見物人とaを明らかにすることのでホームAddressを明らかにするので起こる関心を記録する、Care、-、通信員へのAddress。

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

1. 序論…2 2. 定義…3 3. 問題定義…4 3.1. 明らかにする、注意、-、通信員ノードへの…アドレス4 3.2. 見物人にホームアドレスを明らかにします…4 3.3. 問題範囲…4 4. 問題イラスト…5 5. 結論…7 6. セキュリティ問題…7 7. 承認…8 8. 参照…8 8.1. 標準の参照…8 8.2. 有益な参照…8 付録A.バックグラウンド…10

Koodli                       Informational                      [Page 1]

RFC 4882                 MIP6 Location Privacy                  May 2007

[1ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

1.  Introduction

1. 序論

   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.

位置のプライバシーは顕なローミングの問題に関係があります。(私たちはここで進行中のセッションのあるなしにかかわらず1つのネットワークから別のネットワークまで移行するモバイルNode(ミネソタ)のプロセスとローミングを定義します)。 グローバルな範囲がある一定の識別子はローミングを明らかにすることができます。 例は、IPアドレスなどのデバイス識別子と、SIP[RFC3261]URI[RFC3986]などのユーザ識別子です。 しばしば、これらの2つの識別子の間の結合は例えば、DNS[RFC1035]を通して利用可能です。 ただ一つのネットワークにおけるそのようなIPとUpper Layerプロトコル識別子のトラヒック分析はデバイスとユーザローミングを示すことができます。 また、複数のネットワーク運動の向こう側にIPコミュニケーションの固定フィールドの輪郭を描くことによってローミングを推論できました。 例えば、ネットワークの向こう側に変わりがないIPv6アドレスのInterface Identifier(IID)[RFC2462]は、移動するのを示すことができました。 IPsec[RFC4301]ヘッダーのSecurity Parameter Index(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.

見ることができるように、位置のプライバシー問題は複数のプロトコル層にかかっています。 それにもかかわらず、私たちは特定のプロトコル層を使用することにおけるノードによって行きあたられる問題を調べることができます。 ローミングは、特にデバイスローミングを明らかにすることができるグローバルな識別子(ホームAddress)を定義するモバイルIPと対応するユーザ識別子(SIP URIなどの)に関連して重要であり、また、ユーザローミングを明らかにすることができます。 その上、ユーザが通信員にローミングを明らかにしたがっていないかもしれない、Care、-、Address。その通信員は、aの使用に翻訳します。 ホームAddressのようにCare、-、また、AddressはモバイルNodeの位相的な位置を明らかにすることができます。

   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

このドキュメントはモバイルIPプロトコルに関して位置のプライバシーの問題を見ます。 プライマリ目標はモバイルNode(ミネソタ)とCorrespondent Node(CN)の間の経路の攻撃者がホームAddressの公開のためローミングを検出するのを防ぐことです。 ミネソタとCNの間の1ポイントでトラフィックを観測して、変更して、攻撃者が注入できると思われます。 攻撃者はそうです。

Koodli                       Informational                      [Page 2]

RFC 4882                 MIP6 Location Privacy                  May 2007

[2ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

   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.

複数のポイントで見て、ローミングを検出するために観測を関連させることができないと思われます。 この理由で、攻撃者が1ポイントでそれらを使用できるという範囲にはローミングを検出するために輪郭を描かれることができるMACアドレス、IIDs、および他の分野が範囲だけにあります。 範囲の外にここで説明された問題への解決が、ブロックとしてソリューションでそれらの問題に使用可能である必要があるのを除いて、ローミングを暴露する上側の層のプロトコル識別子があります。

   This document also considers the problem from the exposure of a
   Care-of Address to the CN.

また、このドキュメントが、aの暴露から問題であると考える、Care、-、CNへのAddress。

   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の関係がアドレス[ハダド]、またはUpper Layerプロトコルアドレスであると扱いません。 ここで指定された問題の解決は訪問されたネットワークからモバイル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]と関連用語の基本的な操作に詳しいと仮定します。 便宜のために、私たちは以下でのいくつかの定義を提供します。

2.  Definitions

2. 定義

   o  Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams
      around networks

o モバイルノード(ミネソタ): 自由にネットワークをぶらつくモバイルIPv6モバイルNode

   o  Correspondent Node (CN): A Mobile IPv6 that node corresponds with
      an MN

o 通信員ノード(CN): ノードが対応するモバイルIPv6、ミネソタ

   o  Home Network: The network where the MN is normally present when it
      is not roaming

o ホームネットワーク: 移動していないとき通常、ミネソタが存在しているネットワーク

   o  Visited Network: A network that an MN uses to access the Internet
      when it is roaming

o 訪問されたネットワーク: ミネソタが移動しているとき、インターネットにアクセスするのに使用するネットワーク

   o  Home Agent: A router on the MN's home network that provides
      forwarding support when the MN is roaming

o ホームのエージェント: ミネソタが移動しているとき推進サポートを提供するミネソタのホームネットワークに関するルータ

   o  Home Address (HoA): The MN's unicast IP address valid on its home
      network

o ホームアドレス(HoA): ミネソタのホームネットワークで有効なユニキャストIPアドレス

   o  Care-of Address (CoA): The MN's unicast IP address valid on the
      visited network

o 注意、-、アドレス(CoA): ミネソタの訪問されたネットワークで有効なユニキャストIPアドレス

Koodli                       Informational                      [Page 3]

RFC 4882                 MIP6 Location Privacy                  May 2007

[3ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

   o  Reverse Tunneling or Bidirectional Tunneling: A mechanism used for
      packet forwarding between the MN and its Home Agent

o トンネリングか双方向のトンネリングを逆にしてください: ミネソタとそのホームのエージェントの間のパケット推進に使用されるメカニズム

   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 最適化を発送してください: ホームネットワークを横断する必要はなくてローミングミネソタとそのCNの間のパケットのダイレクトルーティングを許すメカニズム

3.  Problem Definition

3. 問題定義

3.1.  Disclosing the Care-of Address to the Correspondent Node

3.1. 明らかにする、注意、-、通信員ノードへのアドレス

   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ミネソタが訪問されたネットワークかある訪問されたネットワークから別のものまでのホームネットワーク、使用から移動するモバイルである、Care、-、通信員とのコミュニケーションのAddressは、ミネソタが移動したのを明らかにします。 これが、通信員が交際できると仮定する、Care、-、例えば、Binding Cache Entryを点検するのによるホームAddressへのAddress。 いかなる手段(例えば、DNSルックアップを通した)でもホームAddress自身が得られたと思われます。

3.2.  Revealing the Home Address to Onlookers

3.2. 見物人にホームアドレスを明らかにします。

   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ミネソタがホームネットワークから訪問されたネットワークまで1つの訪問されたネットワークから別のネットワークまで移動するとき、コミュニケーションにおけるホームAddressの使用は、ミネソタが移動したのを見物人に明らかにします。 ユーザ識別子(SIP URIなどの)へのホームAddressの結合が利用可能であるときに、また、ユーザが歩き回ったことを決定するのにホームAddressを使用できます。 ミネソタがaを使用するかどうかからこの問題が独立している、Care、-、通信員(すなわち、経路最適化を使用する)、またはミネソタと共に直接伝達するAddressはホームのエージェントを通って交信します(すなわち、用途はトンネリングを逆にします)。 見物人がミネソタに出席しているとき、位置のプライバシーに感染することができます--CN経路(経路最適化が使用されているとき)。 また、見物人がミネソタに出席しているとき、それは感染されるかもしれません--HA経路(双方向であることのときに、暗号化なしでトンネルを堀るのは使用されています; 以下を見てください)。

3.3.  Problem Scope

3.3. 問題範囲

   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ソリューションと共に、位置のプライバシーに対する何らかの保護があります。 モバイルNodeがEncapsulating Security有効搭載量(超能力)暗号化がある逆のトンネリングを使用するなら、ホームAddressはミネソタで明らかにされません--HA経路。 そのように、ミネソタの立ち聞きする者--HA経路はローミングを決定できません。 しかしながら、彼らはまだ超能力ヘッダーの分野の輪郭を描いているかもしれません。 しかしながら、この問題はモバイル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.

いつまで、ミネソタが逆のトンネリング(超能力暗号化にかかわらず)を使用して、通信員にはアクセスがないか、Care、-、Address。 したがって、それは、ミネソタが移動したことを決定できません。

Koodli                       Informational                      [Page 4]

RFC 4882                 MIP6 Location Privacy                  May 2007

[4ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

   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経路最適化が使用されているか、または逆のトンネリングがホームAddressを含む内側のIPパケットを保護しないで使用されるとき、したがって、位置のプライバシー問題は特に適用可能です。

4.  Problem Illustration

4. 問題イラスト

   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.

ホームネットワークでモバイルNodeを考えてください。 IPコミュニケーションにかかわるときはいつも、通信員は、IPアドレスがホームネットワークで有効であることを見ることができます。 さらに詳述して、ピアツーピアコミュニケーションにかかわるユーザはSIP URIなどのユーザフレンドリーな識別子を見そうです、そして、IPスタックのコミュニケーション終点はIPアドレスを見るでしょう。 ミネソタが新しいIPアドレスを習得するとき、IPに無関心であるか気づかないコミュニケーションが詳述するユーザは少しの違いも見ないでしょう。 もちろん、あらゆるユーザの缶の「tcpdumpである」か「霊妙な」aセッションのときに、IPがパケットであることを得てください、そして、大体のgeo-位置にミネソタ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.

ミネソタが別のネットワークに移動するとき、位置のプライバシー問題は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.

通信員と共に、ミネソタが直接交信できますか、または逆トンネルはホームのエージェントを通したパケットを交信させます。 逆のトンネリングを使用するのが明らかにしない、Care、-、ミネソタのAddress、終わりであることによって、特定のシナリオによって、遅れは異なるかもしれません。 それが明らかにされることができるそれらの通信員、それ、Care、-、「ワイヤ」のAddress、ミネソタには、ルートで最適化されたコミュニケーションを使用するオプションがあります。 トランスポート・プロトコルは経路最適化でまだAddressを家まで見送っています。 通信員がユーティリティを得るあるパケットを実行しない場合、ユーザは、どのモード(トンネリングか経路最適化を逆にする)が使用されているかを見ることができませんが、それがURIを知っているのと同じ同輩とコミュニケートしているのを知っています。 これは電話番号がURIのように変わりがないローミング携帯電話ユーザと話すのと同様です。

Koodli                       Informational                      [Page 5]

RFC 4882                 MIP6 Location Privacy                  May 2007

[5ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

   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.

ミネソタが経路最適化か逆のトンネリング(超能力暗号化のない)を使用するかどうかにかかわらず、ホームAddressはデータ・パケットで明らかにされます。 --ミネソタで「ワイヤ」のパケット、見物人を点検する能力を備えているとHA経路は、ミネソタが移動したことを決定できて、また、ユーザが歩き回ったことを決定するかもしれません。 ミネソタをローミング情報を通信員から隠すために手を打ったとしても、これは、位置がプライバシーであると感染するかもしれないでしょうに。

   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.

ホームAddressを静的に割り当てるか、またはダイナミックに割り当てることにかかわらず上の記述は有効です。 どちらの場合ではも、geo-位置への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.

位置のプライバシーにおける感染は利用者データのさらに狙ったプロフィールに通じるかもしれません。 立ち聞きする者が明確にホームAddressを含むトラフィックを追跡して、変化によるモバイルNodeの動きをモニターするかもしれない、Care、-、Address。 プロフィール問題をモバイルIPv6に特定ではありませんが、ホームAddressを明らかにするため位置のプライバシーにおける感染は引き起こすことができました。 通信員がユーザがいつを歩き回ったかという知識を利用するかもしれない、Care、-、Addressは明らかにされて、そのような知識に基づく動作を調節してください。 そのような情報はモバイルユーザに心配をかけるかもしれなくて、通信員が特に判明したら信頼できなくいてください。 これらの理由で、ミネソタの管理インタフェースの位置情報の公開か誤用に用心するのが適切であるセキュリティ対策は考えられるべきです。

   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シグナリング性能に持たれているかもしれません。 例えば、変化、Care、-、Addressはしばしば追加Return Routability[RFC3775]と拘束力がある管理シグナリングを引き起こすでしょう。 そして、ホームAddressを変えると、意味はしばしばIPsecセキュリティ協会管理に持たれています。 変化することによって導入されたシグナリング費用に熟慮を与えるべきである、Care、-、AddressかホームAddress。

   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

移動するとき、ミネソタはいかなる他の通信員としてもホームネットワークノードを扱うかもしれません。 ルートで最適化されたコミュニケーションが同じ経路を横断するので、逆のトンネリングは恐らくホームネットワークコミュニケーションに十分です。 したがって、ミネソタが、明らかにするのを避けることができる、それ、Care、-、ホームネットワーク通信員への単に使用するのによるAddress

Koodli                       Informational                      [Page 6]

RFC 4882                 MIP6 Location Privacy                  May 2007

[6ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

   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.

トンネリングを逆にしてください。 ホームのエージェントからのProxy Neighbor Advertisements[RFC2461]はモバイルNodeが離れているというホームネットワークノードへのヒントとして機能するかもしれません。 しかしながら、ミネソタがそれらがある経路最適化を使用しないと、彼らはモバイルNodeの付属の現在のポイントを知ることができないでしょう。

5.  Conclusion

5. 結論

   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に適切であるとして位置のプライバシー問題について議論しました。 以下の通り問題をまとめることができます: 明らかにする、Care、-、通信員へのAddressとホームAddressを見物人に明らかにするのは、位置がモバイルNodeのプライバシーと、したがって、ユーザのものであると感染することができます。 私たちが、ミネソタが双方向のトンネリングによって保護されるのを見た、それ、Care、-、CNへのAddress。 そして、内側のIPパケットの超能力暗号化で、ミネソタはミネソタの見物人からホームAddressを保護できます--HA経路。 しかしながら、ルートで、最適化、ミネソタが啓示を望んでいる、それ、Care、-、CNへのAddress。 そのうえ、経路最適化で、データ・パケットとモバイルIPv6シグナリングメッセージの見物人にホームAddressを明らかにします。 この問題への解決はすなわち、既存のモバイルIPv6機能的な実体を使用するプロトコル仕様と、モバイルNodeと、ホームのエージェントと、Correspondent Nodeであると予想されます。

6.  Security Considerations

6. セキュリティ問題

   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に特定の位置のプライバシー問題について議論します。 経路最適化を使用するとき、データ・パケットに公開から見物人までホームAddressを保護しなければならない(例えば、暗号化を使用します)、さもなければ、どんなソリューションもトンネリングを逆にすることができなければなりません。 さらに、ソリューションは、ミネソタ--HAとミネソタ--CN経路に沿ってホームAddressを明らかにするのからモバイル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.

明らかにする、Care、-、ミネソタが経路最適化を使用したいと思うなら、Addressは必然です。 にかかわらず、Care、-、Addressが訪問されたリンクの上のミネソタのオンリンクアドレスか協力関係を持っているプロキシのものである、CNがローミングを確かめるように、Binding Cache Entryの単なる存在は十分です。 したがって、位置のプライバシーへの当該のミネソタが経路最適化を使用するかどうか決定することにおける思慮を運動させるべきである、以前に特に見慣れない、通信員。

   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アドレスの使用が特に役に立つかもしれない、Care、-、Addresses

Koodli                       Informational                      [Page 7]

RFC 4882                 MIP6 Location Privacy                  May 2007

[7ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

   if appropriate trade-offs with Return Routability signaling are taken
   into account.

Return Routabilityが合図している適切なトレードオフを連れていくなら、説明してください。

7.  Acknowledgments

7. 承認

   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.

ジェームス・ケンフ、Qiu Ying、サム・シャー、およびLakshminath Dondetiはそれらのレビューとフィードバックのために承認されます。 最後の呼び出しレビューとヤリArkkoとキリアン・ウェニガーに改良とテキストを示してくださってありがとうございます。 問題範囲を改良するためにサム・ハートマンにテキストを提供してくださってありがとうございます。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」

8.2.  Informative References

8.2. 有益な参照

   [HADDAD]   Haddad, W., et al., "Privacy for Mobile and Multi-homed
              Nodes: Problem Statement" Work in Progress, June 2006.

そして、[ハダド]ハダド、W.、他、「モバイルのためのプライバシー、マルチ、家へ帰り、ノード:、」 2006年6月の「問題声明」処理中の作業。

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日

   [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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、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)のための隣人発見」、RFC2461、1998年12月。

   [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、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"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

Koodli                       Informational                      [Page 8]

RFC 4882                 MIP6 Location Privacy                  May 2007

[8ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

   [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、「座標ベースの位置の設定情報のためのDynamic Host Configuration Protocolオプション」、RFC3825(2004年7月)。

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。

Koodli                       Informational                      [Page 9]

RFC 4882                 MIP6 Location Privacy                  May 2007

[9ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

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メッセージがそれらの「ホームネットワーク」の時間帯に関するタイムスタンプを運ぶのに気付いたかもしれない、(位置のプライバシーかそうでない、)、1日の「正常な」時間メッセージを送るとき、異なった時間帯にはユーザがいるのを明らかにすることができる。 その上、ツールはIPアドレスをISPの物理アドレスに写像できるインターネットか接頭語塊を所有している組織で存在しています。 IPホストの上のGPS受信機内蔵もう1ステップにこれを取って、geo位置をIPネットワーク情報に写像するためにアプリケーションについて工夫できます。 また、GPS受信機がなくても、例えば"Geopriv"がDHCPオプション[RFC3825]としてサポートされるところで環境でgeo-位置を得ることができます。 概要では、異なった手段でユーザの物理的な位置は、決定するか、または何らかの確実性と異なったレベルの粒状で推測できます、IPアドレス自体は本来少しのgeo-位置情報も提供しませんが。 IP Mobilityの面前でIPアドレス位置のプライバシーの問題が扱われるとき、この広い範囲を覚えておくのは恐らく役に立ちます。

Author's Address

作者のアドレス

   Rajeev Koodli
   Nokia Siemens Networks
   313 Fairchild Drive
   Mountain View, CA 94043

Rajeev Koodliノキアジーメンスネットワーク313フェアチャイルドはマウンテンビュー、カリフォルニア 94043を追い立てます。

   EMail: rajeev.koodli@nokia.com

メール: rajeev.koodli@nokia.com

Koodli                       Informational                     [Page 10]

RFC 4882                 MIP6 Location Privacy                  May 2007

[10ページ]RFC4882MIP6位置のプライバシー2007年5月の情報のKoodli

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Koodli                       Informational                     [Page 11]

Koodli情報です。[11ページ]