この文書はRFC 4882の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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).
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.
この文書で、私たちはモバイルＩＰｖ６に適用する位置プライバシーについ
て議論します。私たちは見物人ホームアドレスを示すことで起こる懸念と、
通信相手へケアオブアドレスを隠す懸念を示します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Definitions
2. 定義
3. Problem Definition
3. 問題定義
3.1. Disclosing the Care-of Address to the Correspondent Node
3.1. ケアオブアドレスの通信相手へ露出
3.2. Revealing the Home Address to Onlookers
3.2. 見物人にホームアドレスを示すこと
3.3. Problem Scope
3.3. 問題範囲
4. Problem Illustration
4. 問題説明
5. Conclusion
5. 結論
6. Security Considerations
6. セキュリティの考察
7. Acknowledgments
7. 謝辞
8. References
8. 参考文献
8.1. Normative References
8.1. 参照する参考文献
8.2. Informative References
8.2. 益な参考文献
Appendix A. Background
付録Ａ，背景
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.
位置のプライバシーと、通信にＩＰを使うときのプライバシーの問題は重要
になりました。分析に使われる情報や過敏な個人情報を知らず知らず提示し
てしまうことに対し通信を保護する事に関しＩＰプライバシーは広く懸念さ
れています。これは、ある有利な地位の集会データ、特定のトラヒックの情
報の収集、１日の特定の時間の行動について(恐らく)ユーザのある集団をモ
ニタする事、などを含みます。この文書ではこれを「プロファイリング」問
題と言います。
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.
位置のプライバシーはローミングの開示の問題に関係があります、ここでロー
ミングは、進行中のセッションのあるなしにかかわらず１つのネットワーク
から別のネットワークへ移動するモバイルノード(ＭＮ)の処理と定義します。
グローバルな範囲で静的な識別子はローミングを明らかにすることができま
す。例えば、ＩＰアドレスなどのデバイス識別子や、ＳＩＰ[RFC3261]やＵ
ＲＩ[RFC3986]などのユーザ識別子です。しばしば、これらの２つの識別子
は、たとえばＤＮＳ[RFC1035]を通して、結合可能です。単一ネットワーク
でのこのようなＩＰとユーザ層プロトコル識別子のトラヒック分析はデバイ
スとユーザローミングを示すことができます。また、複数のネットワーク上
での移動でＩＰ通信で変更のないフィールドのプロファイリングでローミン
グを推定することができます。例えば、ネットワークを移動しても変わらな
いＩＰｖ６アドレスのインターフェース識別子（ＩＩＤ）[RFC2462]は、ロー
ミングを示すことができます。ＩＰｓｅｃ[RFC4301]ヘッダのセキュリティ
パラメータインデックス（ＳＰＩ）はプロファイリングと推論を受けること
があるかもしれない別のフィールドです。このようにローミングを推論する
のは複数のネットワークを通したトラヒック分析、共謀した攻撃者、または
その両方を必要とします。位置のプライバシーが漏れると、対象を絞り込ん
だユーザ通信のプロファイリグに通じるかもしれません。
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.
ご存知のように、位置のプライバシー問題は複数のプロトコル層にかかって
います。それにもかかわらず、私たちは特定のプロトコル層を使用するノー
ドの遭遇する問題を調べることができます。ローミングはモバイルＩＰで特
に重要で、これは装置ローミングを明らかにするグローバル識別子(ホーム
アドレス)を定義し、関連してユーザローミングを明らかにします。その上、
ユーザが通信相手にローミングを明らかにしたくないかもしれず、ケアオブ
アドレスを使用します。ホームアドレスのようにケアオブアドレスもモバイ
ルノードの位相的な位置を明らかにできます。
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.
この文書は、モバイルＩＰプロトコルの位置プライバシ問題を扱います。主
な目的は、ホームアドレスの公開により、移動ノード（ＭＮ）と相手先（Ｃ
Ｎ）の間の攻撃者に、移動が検出されるのを防ぐことです。攻撃者は、ＭＮ
とＣＮの間のある所でトラヒックを観察し、修正し、注入することができる
と仮定します。攻撃者は、複数の場所で観察することはできず、移動を見つ
けるために相関の観察はできないと仮定します。この理由で、移動の検出に
使えるＭＡＣアドレスとＩＩＤとその他のフィールドは、１点にいつ攻撃者
が使える範囲に限定されます。移動を露出させる上層プロトコル識別子は、
ここで記述される問題の解決策がそれらの問題の解決策の一部として使える
場合を除き、範囲外です。
This document also considers the problem from the exposure of a
Care-of Address to the 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.
この文書はモバイルＩＰｖ６環境で、ＩＰアドレス位置プライバシーに関心
を持つだけです。全体的なプライバシー問題に対処しません。たとえば、Ｍ
ＡＣアドレスまたはＩＰとＭＡＣアドレスの関係付け[HADDAD]と関連した問
題に、あるいは上位層プロトコルが対処するプライバシーに対処しません。
ここで指定される問題の解決策は、移動先ネットワークからモバイルＩＰｖ
６アドレスを使うことで移動が公表されることからの保護を提供しなければ
なりません。
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.
この文書は、読者がモバイルＩＰｖ６[RFC3775]の基本的な動作とその中で
定められる関連用語をよく知っていると仮定します。便宜上、我々は下記の
いくつかの定義を提供します。
2. Definitions
2. 定義
o Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams
around networks
o 移動ノード（ＭＮ）：ネットワークで自由に移動する移動ＩＰｖ６移動
ノード
o Correspondent Node (CN): A Mobile IPv6 that node corresponds with
an MN
o 相手ノード（ＣＮ）：ＭＮと通信するモバイルＩＰｖ６
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 ホームアドレス（ＨｏＡ）：ホームネットワーク上で有効なＭＮのユニ
キャストＩＰアドレス
o Care-of Address (CoA): The MN's unicast IP address valid on the
visited network
o ケアオブアドレス（ＣｏＡ）：移動先ネットワーク上で有効なＭＮのユ
ニキャストＩＰアドレス
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 経路最適化：移動しているＭＮとそのＣＮの間で、ホームネットワーク
を経由せずに、パケットの直接のルーティングを可能にするメカニズム
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).
モバイルＩＰのＭＮがホームネットワークから滞在先ネットワークへ移動
するか、ある滞在先ネットワークから別の滞在先へ移動するとき、相手と
通信にケアオブアドレスを使うとＭＮが移動しているのが分かります。
これは通信相手が、たとえば、結合キャッシュ項目を調べることで、ホー
ムアドレスとケアオブアドレスが結びつけることができると仮定します。
ホームアドレス自体は、様々な手段（例えば、ＤＮＳ検索を通して）で得
る事ができると仮定します。
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).
モバイルＩＰのＭＮがそのホームネットワークから訪問先ネットワークへ、
または、１つの訪問先ネットワークから別へ移動するとき、通信でホーム
アドレスを使用する事で、見物人にＭＮが移動したことが露見します。ユー
ザ識別子（例えばSIP URI）とホームアドレスの対応が利用できるとき、
ホームアドレスはユーザが移動したと確定するのに用いることができます。
この問題はＭＮが通信相手と直接と情報交換するためにケアオブアドレス
を使うかどうか（すなわち経路最適化の使用）や、ＭＮがホームエージェ
ントと通信する（すなわち、逆トンネルの使用）とは、別問題です。見物
人がＭＮ−ＨＡ経路間にいる時（暗号化のない双方向トンネルが使われる
時;下記参照）もこれは危険になるかもしれません。
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.
既存のモバイルＩＰｖ６のソリューションで、位置プライバシーからのい
くらかの保護があります。移動ノードが暗号化セキュリティペイロード
(ESP)暗号化で逆のトンネリングを使うならば、ホームアドレスはＭＮ−
ＨＡ経路で明らかになりません。それで、ＭＮ−ＨＡ経路の盗聴者は移動
を決定することができません。しかし彼らは、ＥＳＰヘッダのフィールド
をプロファイリングできます;しかし、この問題はモバイルＩＰｖ６位置
プライバシーに固有でありません。
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.
ＭＮが逆トンネリングを使うとき（ESP暗号化に関係なく）、通信相手は
ケアオブアドレスにアクセスしません。それゆえにＭＮが移動したと確定
することができません。
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.
それゆえに、位置プライバシー問題は、モバイルＩＰｖ６経路最適化が使
われるか、逆トンネリングがホームアドレスを含む内部のＩＰパケットを
保護することなく使われる時に、特に適用できます。
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.
ホームネットワークにいるモバイルノードを考えてください。それがＩＰ
通信をしているときは、通信相手は常にホームネットワークで有効なＩＰ
アドレスを有効であるのを見ることができます。さらに、ピアツーピア通
信に関係するユーザはSIP URIのようなユーザフレンドリな識別子を見て、
ＩＰスタックの通信端はＩＰアドレスにを見るでしょう。ＭＮが新しいＩ
Ｐアドレスを得るとき、ＩＰ通信の詳細に無関心か知らないユーザは少し
の違いもわかりません。もちろん、任意のユーザはセッションの"tcpdump"
や"ethereal"か可能で、ＩＰパケットを取り込み、ＭＮのＩＰアドレスを
およその地理的位置に対応付けます。この対応付けはユーザの国内位置を
明かすかもしれません、しかし、通信相手はユーザが実際に移動したかど
うか確かめることができません。ＩＰアドレスに基づく物理的な位置を評
価することは、電話番号の市外局番に基づく地理的場所を評価することに、
なんらかの類似点があります。ＩＰアドレスと一致している物理的な地域
の精度は、利用できるツールがどれくらい洗練されているか、ＩＳＰがど
れだけ頻繁にネットワークの番号変更をするか等によって異なります。ま
た、（例えばＶＰＮやトンネリングなどの）技術のために、ＩＰアドレス
は特定の地理的地域にいることを保証することができません。
When the MN roams to another network, the location privacy problem
consists of two parts: revealing information to its correspondents
and to onlookers.
ＭＮが他のネットワークに移動する、位置プライバシ問題は２つの部分か
ら成ります：通信相手へと、見物人への、情報の暴露。
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.
その通信相手に対し、ＭＮは直接通信する事も、パケットに逆トンネルで
ホームエージェントを通して通信する事もできます。逆トンネリングを使
うとＭＮのケアオブアドレスを明らかにしませんが、エンド対エンドの遅
延は特定の状況に従い変化するかもしれません。個別にケアオブアドレス
を明らかにすることができる通信相手に対し、ＭＮは経路最適化された通
信を使うオプションがあります。トランスポートプロトコルは、経路最適
化でもホームアドレスを見ます。通信相手が何らかのパケットキャプチャ
を動かさない限り、ユーザはどのモード（逆トンネリングまたは経路最適
化）が使われているか見ることができませんが、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.
ＭＮが経路最適化か（ＥＳＰ暗号化なしの）逆トンネリングを使うかに関
係なく、そのホームアドレスはデータパケットで明らかにされます。ＭＮ−
ＨＡ間経路上の見物人がワイヤ上のパケットを調べる能力を備えていると
き、見物人はＭＮが移動していると確定することができ、ユーザが移動し
ている事も確定できるかもしれません。たとえＭＮが移動している情報を
通信相手から隠すために処置をとっても、これは場所プライバシーを漏洩
しえます。
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.
ホームアドレスが静的に割り当てられるか、動的に割り当てられるかどう
かに関係なく、上記の説明は有効です。いずれにせよ、ＩＰアドレスと地
理的位置への対応は、たぶん同じ程度の精度の結果を与えます。インター
ネットで自由に入手可能なツールで、この精度はプレフィックスの塊の所
有者として登録されているるＩＳＰや組織の実住所です。ＩＳＰまたは組
織が、正しく、そのサブネットの青写真を提供することを要求されていな
いので、精度はモバイル無線ネットワークのためにかなり粗くなります。
しかし、高度な攻撃者は、サイトマッピングを実行して、よりきめが細か
いサブネット情報を得ることができるかもしれません。
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.
位置プライバシの漏洩は、ユーザデータの的を得た探索を可能にします。
盗聴者は特にホームアドレスを含むトラヒックを追うかもしれず、ケアオ
ブアドレスの変更によりモバイルノードの移動を追跡するかもしれません。
プロファイル問題はモバイルＩＰｖ６に固有ではなく、ホームアドレスを
明らかにする位置プライバシの漏洩によって引き起こされえます。ケアオ
ブアドレスが明らかにされるとき、通信相手はユーザが移動したという知
識を利用するかもしれず、このような知識によって行動を調整するかもし
れません。このような情報は、特に通信相手を信頼しなくなる時、モバイ
ルユーザに懸念をもたらす事がありえます。これらの理由から、ＭＮの管
理インターフェースの適当な保安対策は、位置情報の公開や不正使用を警
戒する事を考慮しなければなりません。
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.
プロファイリングを妨害する既存の技術を適用することは、モバイルＩＰ
ｖ６の信号処理の性能に影響を与えるかもしれません。たとえば、ケアオ
ブアドレスを頻繁に変えることは、追加の帰路経路[RFC3775]と結合管理
信号を発生します。そして、ホームアドレスを頻繁に変えることは、ＩＰ
ｓｅｃセキュリティ連携管理に影響を与えます。ケアオブアドレスやホー
ムアドレスを変えることで発生する信号コストは慎重に考慮しなければな
りません。
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.
移動中、ＭＮはそのホームネットワークノードを他の通信相手とみなすか
もしれません。経路最適化された通信が同一の経路を通るので、逆トンネ
リングはおそらくホームネットワークとの通信に十分です。それゆえに、
ＭＮは逆トンネリングを用いて、単純にそのホームネットワーク通信相手
にケアオブアドレスを示すことを避けることができます。ホームエージェ
ントからのプロキシ近隣広告[RFC2461]は、ホームネットワークノードに、
モバイルノードがいないというヒントとして用いることができました。し
かし、ＭＮが彼らと経路最適化を使わない限り、彼らはモバイルノードの
現在の存在位置を知ることができません。
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.
この文書では、モバイルＩＰｖ６に適用できる位置プライバシー問題を議
論しました。問題は、以下の通りにまとめることができます：ケアオブア
ドレスを通信相手に明らかにする事や、見物人にホームアドレスを示すこ
とは、モバイルノードのの位置プライバシと、それゆえに、ユーザの位置
プライバシを露見させることができます。我々は、双方向性トンネリング
がＣＮに対し、ＭＮのケアオブアドレスを保護するのを許すのを見ました。
そして、内部のＩＰパケットのＥＳＰ暗号化は、ＭＮ−ＨＡ間経路上の見
物人に対し、ＭＮのホームアドレスの保護を許します。しかし、経路最適
化で、ＭＮはＣＮにそのケアオブアドレスを示します。さらに、経路最適
化は、モバイルＩＰｖ６信号メッセージ同様に、データパケット内のホー
ムアドレスを見物人に示す原因になります。既存のモバイルＩＰｖ６機能
実体、すなわち、モバイルノード、そのホームエージェントと通信相手の
使うプロトコル仕様で、この問題の解決策が期待されます。
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.
この文書は、モバイルＩＰｖ６固有の位置プライバシ問題を議論します。
解決策は経路最適化または逆のトンネリングを使うとき、データパケット
内のホームアドレスを見物人への公開に対し保護できなければなりません
（例えば、暗号化を使う）。そのうえ、解決策ＭＮ−ＨＡとＭＮ−ＣＮ経
路間でホームアドレスを公開することに対し、モバイルＩＰｖ６信号メッ
セージの保護を考えなければなりません。
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.
ＭＮが経路最適化を使うことを望むならば、ケアオブアドレスを明らかに
することは回避不能です。ケアオブアドレスが訪問先リンクでＭＮのリン
ク上アドレスであるか、代理プロキシのアドレスであるかに関わらず、結
合キャッシュ項目の存在はＣＮが移動を確認するに十分です。それゆえに、
位置プライバシに関心を持つＭＮは、特に以前に見慣れなない通信相手に
対して、経路最適化を使うべきかどうか決定する際に、思慮分別を行使し
なければなりません。
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.
解決は、４章「問題説明」で議論したように、一時的アドレスの使用とその
モバイルＩＰｖ６信号への影響を考慮すべきです。帰路経路信号での適切な
取り扱いが考慮されるならば、プライバシ拡張[RFC3041]のＩＰアドレスの
使用は特にケアオブアドレスに役立ちます。
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.
James KempfとQiu YingとSam XiaとLakshminath Dondetiのレビューと
フィードバックに感謝します。最後の文書の示唆と改良のレビューに対し
Jari ArkkoとKilian Wenigerに感謝します。問題がある範囲を改善する文
書の提供に対しSam Hartmanに感謝します。
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.
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.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[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.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Appendix A. Background
付録Ａ，背景
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.
位置プライバシの話題は広範囲で、しばしば異なる意味を持ちます。それは
ＯＳＩ参考モデルの多数の層に及びます。そのうえ、ＩＰアドレス以外に場
所の明らかにするヒントの属性があります。例えば、通信相手が過去と同じ
相手と通信しているなら、「時刻」属性はユーザーにヒントを示すことがで
きます。あるローミング携帯電話ユーザは（位置プラバシか他の理由で）Ｓ
ＭＳメッセージで「ホーム網」の時間のタイムスタンプを示します、それら
のＳＭＳメッセージが「標準的」時間に送られるなら、異なる時間帯にいる
ことを明らかにするかもしれません。さらに、ＩＰアドレスをプレフィック
ス群を所有するＩＳＰあるいは組織の物理アドレスに変換できるツールがイ
ンターネットに存在します。他の考えとして、ＧＰＳ受信機が組み込まれた
ＩＰホストで、位置情報とＩＰネットワーク情報を対応付けるアプリケーショ
ンが考案できます。ＧＰＳ受信機なしででも、例えばＤＨＣＰオプション
[RFC3825]として「Geopriv」がサポートされる環境で、位置情報が入手でき
ます。概略すれば、ＩＰアドレス自身が本質的に位置情報を提供しないが、
ユーザーの物理的な場所は、異なった手段によって、ある確からしさと様々
なレベルの精度で推測や決定できます。ＩＰアドレスの位置プライバシの問
題がＩＰ移動性で扱われるとき、この広い範囲を心に留めておくことは多分
有用です。
Author's Address
著者のアドレス
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).
著作権（Ｃ）ＩＥＴＦ信託（２００７）。
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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とＩＥＴＦ信託とインターネット技術標準化タスクフォースは、明確にも暗
黙にも、この情報の使用が権利の侵害しないことや商業利用や特別の目的へ
の利用に適当である事の保障を含め、全ての保証を拒否します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。