draft-ietf-mip6-location-privacy-ps-06.txt   rfc4882.txt 
MIP6 Working Group Rajeev Koodli Network Working Group R. Koodli
Internet-Draft Nokia Research Center Request for Comments: 4882 Nokia Siemens Networks
Intended status: Informational February 19, 2007
Expires: August 23, 2007
IP Address Location Privacy and Mobile IPv6: Problem Statement IP Address Location Privacy and Mobile IPv6: Problem Statement
draft-ietf-mip6-location-privacy-06.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2007. 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 Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
In this document, we discuss Location Privacy as applicable to Mobile In this document, we discuss location privacy as applicable to Mobile
IPv6. We document the concerns arising from revealing Home Address IPv6. We document the concerns arising from revealing a Home Address
to an on-looker and from disclosing Care of Address to a to an onlooker and from disclosing a Care-of Address to a
correspondent. correspondent.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions .....................................................3
3. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Definition ..............................................4
3.1. Disclosing the Care-of Address to the Correspondent 3.1. Disclosing the Care-of Address to the Correspondent Node ...4
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Revealing the Home Address to Onlookers ....................4
3.2. Revealing the Home Address to On-lookers . . . . . . . . . 5 3.3. Problem Scope ..............................................4
3.3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Illustration ............................................5
4. Problem Illustration . . . . . . . . . . . . . . . . . . . . . 6 5. Conclusion ......................................................7
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations .........................................7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments .................................................8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. References ......................................................8
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References .......................................8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References .....................................8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 Appendix A. Background ............................................10
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
The problems of location privacy, and privacy when using IP for The problems of location privacy, and privacy when using IP for
communication have become important. IP privacy is broadly concerned communication, have become important. IP privacy is broadly
with protecting user communication from unwittingly revealing concerned with protecting user communication from unwittingly
information that could be used to analyze and gather sensitive user revealing information that could be used to analyze and gather
data. Examples include gathering data at certain vantage points, sensitive user data. Examples include gathering data at certain
collecting information related to specific traffic, and monitoring vantage points, collecting information related to specific traffic,
(perhaps) certain populations of users for activity during specific and monitoring (perhaps) certain populations of users for activity
times of the day, etc. In this document, we refer to this as the during specific times of the day, etc. In this document, we refer to
"profiling" problem. this as the "profiling" problem.
Location privacy is concerned with the problem of revealing roaming, Location privacy is concerned with the problem of revealing roaming,
which we define here as the process of a Mobile Node (MN) moving from which we define here as the process of a Mobile Node (MN) moving from
one network to another with or without on-going sessions. A constant one network to another with or without ongoing sessions. A constant
identifier with global scope can reveal roaming. Examples are a identifier with global scope can reveal roaming. Examples are a
device identifier such as an IP address, and a user identifier such device identifier such as an IP address, and a user identifier such
as a SIP [rfc3261] URI[rfc2396]. Often, a binding between these two as a SIP [RFC3261] URI [RFC3986]. Often, a binding between these two
identifiers is available, e.g., through DNS [rfc1035]. Traffic identifiers is available, e.g., through DNS [RFC1035]. Traffic
analysis of such IP and Upper Layer Protocol identifiers on single analysis of such IP and Upper Layer Protocol identifiers on a single
network can indicate device and user roaming. Roaming could also be network can indicate device and user roaming. Roaming could also be
inferred by means of profiling constant fields in IP communication inferred by means of profiling constant fields in IP communication
across multiple network movements. For example, an Interface across multiple network movements. For example, an Interface
Identifier (IID) [rfc2462] in the IPv6 address that remains unchanged Identifier (IID) [RFC2462] in the IPv6 address that remains unchanged
across networks could suggest roaming. The SPI in the IPsec across networks could suggest roaming. The Security Parameter Index
[rfc4301] header is another field that may be subject to such (SPI) in the IPsec [RFC4301] header is another field that may be
profiling and inference. Inferring roaming in this way typically subject to such profiling and inference. Inferring roaming in this
requires traffic analysis across multiple networks, or colluding way typically requires traffic analysis across multiple networks, or
attackers, or both. When location privacy is compromised, it could colluding attackers, or both. When location privacy is compromised,
lead to more targetted profiling of user communication. it could lead to more targeted profiling of user communication.
As can be seen, the location privacy problem spans multiple protocol As can be seen, the location privacy problem spans multiple protocol
layers. Nevertheless, we can examine problems encountered by nodes layers. Nevertheless, we can examine problems encountered by nodes
using a particular protocol layer. Roaming is particularly important using a particular protocol layer. Roaming is particularly important
to Mobile IP, which defines a global identifier (Home Address) that to Mobile IP, which defines a global identifier (Home Address) that
can reveal device roaming, and in conjunction with a corresponding can reveal device roaming, and in conjunction with a corresponding
user identifier (such as a SIP URI), can also reveal user roaming. user identifier (such as a SIP URI), can also reveal user roaming.
Furthermore, a user may not wish to reveal roaming to Furthermore, a user may not wish to reveal roaming to
correspondent(s), which translates to the use of Care-of Address. As correspondent(s), which translates to the use of a Care-of Address.
with Home Address, the Care-of Address can also reveal the As with a Home Address, the Care-of Address can also reveal the
topological location of the Mobile Node. topological location of the Mobile Node.
This document scopes the problem of location privacy for the Mobile This document scopes the problem of location privacy for the Mobile
IP protocol. The primary goal is to prevent attackers on the path IP protocol. The primary goal is to prevent attackers on the path
between the Mobile Node (MN) and the Correspondent Node (CN) from between the Mobile Node (MN) and the Correspondent Node (CN) from
detecting roaming due to the disclosure of the Home Address. The detecting roaming due to the disclosure of the Home Address. The
attackers are assumed to be able to observe, modify and inject attackers are assumed to be able to observe, modify, and inject
traffic at one point between the MN and the CN. The attackers are 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 assumed not to be able to observe at multiple points and correlate
observations to detect roaming. For this reason, MAC addresses, IIDs observations to detect roaming. For this reason, MAC addresses,
and other fields which can be profiled to detect roaming are only in IIDs, and other fields that can be profiled to detect roaming are
scope to the extent that they can be used by an attacker at one only in scope to the extent that they can be used by an attacker at
point. Upper layer protocol identifiers that expose roaming are out one point. Upper layer protocol identifiers that expose roaming are
of scope except that a solution to the problem described here needs out of scope except that a solution to the problem described here
to be usable as a building block in solutions to those problems. needs to be usable as a building block in solutions to those
problems.
This document also considers the problem from the exposure of Care-of This document also considers the problem from the exposure of a
Address to the CN. Care-of Address to the CN.
This document is only concerned with IP Address Location Privacy in This document is only concerned with IP address location privacy in
the context of Mobile IPv6. It does not address the overall privacy the context of Mobile IPv6. It does not address the overall privacy
problem. For instance, it does not address privacy issues related to problem. For instance, it does not address privacy issues related to
MAC addresses or the relationship of IP and MAC addresses MAC addresses or the relationship of IP and MAC addresses [HADDAD],
[draft-haddad], or the Upper Layer Protocol addresses. Solution to or the Upper Layer Protocol addresses. Solutions to the problem
the problem specified here should provide protection against roaming specified here should provide protection against roaming disclosure
disclosure due to using Mobile IPv6 addresses from a visited network. due to using Mobile IPv6 addresses from a visited network.
This document assumes that the reader is familiar with the basic This document assumes that the reader is familiar with the basic
operation of Mobile IPv6 [rfc3775] and the associated terminology operation of Mobile IPv6 [RFC3775] and the associated terminology
defined therein. For convenience, we provide some definitions below. defined therein. For convenience, we provide some definitions below.
2. Definitions 2. Definitions
o Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams o Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams
around networks around networks
o Correspondent Node (CN): A Mobile IPv6 that node corresponds with o Correspondent Node (CN): A Mobile IPv6 that node corresponds with
a MN an MN
o Home Network: The network where the MN is normally present when it o Home Network: The network where the MN is normally present when it
is not roaming is not roaming
o Visited Network: A network which a MN uses to access Internet when
it is roaming o Visited Network: A network that an MN uses to access the Internet
o Home Agent: A router on the MN's home network which provides when it is roaming
o Home Agent: A router on the MN's home network that provides
forwarding support when the MN is roaming forwarding support when the MN is roaming
o Home Address (HoA): The MN's unicast IP address valid on its home o Home Address (HoA): The MN's unicast IP address valid on its home
network network
o Care-of Address (CoA): The MN's unicast IP address valid on the o Care-of Address (CoA): The MN's unicast IP address valid on the
visited network visited network
o Reverse Tunneling or Bidirectional Tunneling: A mechanism used for o Reverse Tunneling or Bidirectional Tunneling: A mechanism used for
packet forwarding between the MN and its Home Agent packet forwarding between the MN and its Home Agent
o Route Optimization: A mechanism which allows direct routing of
o Route Optimization: A mechanism that allows direct routing of
packets between a roaming MN and its CN, without having to packets between a roaming MN and its CN, without having to
traverse the home network. traverse the home network
3. Problem Definition 3. Problem Definition
3.1. Disclosing the Care-of Address to the Correspondent Node 3.1. Disclosing the Care-of Address to the Correspondent Node
When a Mobile IP MN roams from its home network to a visited network 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 or from one visited network to another, use of Care-of Address in
communication with a correspondent reveals that the MN has roamed. communication with a correspondent reveals that the MN has roamed.
This assumes that the correspondent is able to associate the Care-of This assumes that the correspondent is able to associate the Care-of
Address to Home Address, for instance by inspecting the Binding Cache Address to the Home Address, for instance, by inspecting the Binding
Entry. The Home Address itself is assumed to have been obtained by Cache Entry. The Home Address itself is assumed to have been
whatever means (e.g., through DNS lookup). obtained by whatever means (e.g., through DNS lookup).
3.2. Revealing the Home Address to On-lookers 3.2. Revealing the Home Address to Onlookers
When a Mobile IP MN roams from its home network to a visited network When a Mobile IP MN roams from its home network to a visited network
or from one visited network to another, use of Home Address in or from one visited network to another, use of a Home Address in
communication reveals to an on-looker that the MN has roamed. When a communication reveals to an onlooker that the MN has roamed. When a
binding of Home Address to a user identifier (such as a SIP URI) is 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 available, the Home Address can be used to also determine that the
user has roamed. This problem is independent of whether the MN uses user has roamed. This problem is independent of whether the MN uses
Care-of Address to communicate directly with the correspondent (i.e., a Care-of Address to communicate directly with the correspondent
uses route optimization), or the MN communicates via the Home Agent (i.e., uses route optimization), or the MN communicates via the Home
(i.e., uses reverse tunneling). Location privacy can be compromised Agent (i.e., uses reverse tunneling). Location privacy can be
when an on-looker is present on the MN - CN path (when route compromised when an onlooker is present on the MN - CN path (when
optimization is used). It may also be compromised when the on-looker route optimization is used). It may also be compromised when the
is present on the MN - HA path (when bidirectional tunneling without onlooker is present on the MN - HA path (when bidirectional tunneling
encryption is used. See below). without encryption is used; see below).
3.3. Problem Scope 3.3. Problem Scope
With existing Mobile IPv6 solutions, there is some protection against With existing Mobile IPv6 solutions, there is some protection against
location privacy. If a Mobile Node uses reverse tunneling with ESP location privacy. If a Mobile Node uses reverse tunneling with
encryption, then the Home Address is not revealed on the MN - HA Encapsulating Security Payload (ESP) encryption, then the Home
path. So, eavesdroppers on the MN - HA path cannot determine Address is not revealed on the MN - HA path. So, eavesdroppers on
roaming. They could, however, still profile fields in the ESP the MN - HA path cannot determine roaming. They could, however,
header; however, this problem is not specific to Mobile IPv6 location still profile fields in the ESP header; however, this problem is not
privacy. specific to Mobile IPv6 location privacy.
When a MN uses reverse tunneling (regardless of ESP encryption), the When an MN uses reverse tunneling (regardless of ESP encryption), the
correspondent does not have access to the Care-of Address. Hence, it correspondent does not have access to the Care-of Address. Hence, it
cannot determine that the MN has roamed. cannot determine that the MN has roamed.
Hence, the location privacy problem is particularly applicable when Hence, the location privacy problem is particularly applicable when
Mobile IPv6 route optimization is used or when reverse tunneling is Mobile IPv6 route optimization is used or when reverse tunneling is
used without protecting the inner IP packet containing the Home used without protecting the inner IP packet containing the Home
Address. Address.
4. Problem Illustration 4. Problem Illustration
This section is intended to provide an illustration of the problem This section is intended to provide an illustration of the problem
defined in the previous section. defined in the previous section.
Consider a Mobile Node at its home network. Whenever it is involved Consider a Mobile Node at its home network. Whenever it is involved
in IP communication, its correspondents can see an IP address valid in IP communication, its correspondents can see an IP address valid
on the home network. Elaborating further, the users involved in peer on the home network. Elaborating further, the users involved in
- peer communication are likely to see a user-friendly identifier peer-to-peer communication are likely to see a user-friendly
such as a SIP URI, and the communication end-points in the IP stack identifier such as a SIP URI, and the communication endpoints in the
will see IP addresses. Users uninterested in or unaware of IP IP stack will see IP addresses. Users uninterested in or unaware of
communication details will not see any difference when the MN IP communication details will not see any difference when the MN
acquires a new IP address. Of course any user can ``tcpdump'' or acquires a new IP address. Of course, any user can "tcpdump" or
``ethereal'' a session, capture IP packets and map the MN's IP "ethereal" a session, capture IP packets, and map the MN's IP address
address to an approximate geo-location. This mapping may reveal the to an approximate geo-location. This mapping may reveal the home
home location of a user, but a correspondent cannot ascertain whether location of a user, but a correspondent cannot ascertain whether the
the user has actually roamed or not. Assessing the physical location user has actually roamed or not. Assessing the physical location
based on IP addresses has some similarities to assessing the based on IP addresses has some similarities to assessing the
geographical location based on the area-code of a telephone number. geographical location based on the area code of a telephone number.
The granularity of the physical area corresponding to an IP address The granularity of the physical area corresponding to an IP address
can vary depending on how sophisticated the available tools are, how can vary depending on how sophisticated the available tools are, how
often an ISP conducts its network re-numbering, etc. And, an IP often an ISP conducts its network re-numbering, etc. Also, an IP
address cannot also guarantee that a peer is at a certain geographic address cannot guarantee that a peer is at a certain geographic area
area due to technologies such as VPN and tunneling. due to technologies such as VPN and tunneling.
When the MN roams to another network, the location privacy problem When the MN roams to another network, the location privacy problem
consists of two parts: revealing information to its correspondents consists of two parts: revealing information to its correspondents
and to on-lookers. and to onlookers.
With its correspondents, the MN can either communicate directly or With its correspondents, the MN can either communicate directly or
reverse tunnel its packets through the Home Agent. Using reverse reverse-tunnel its packets through the Home Agent. Using reverse
tunneling does not reveal Care-of Address of the MN, although end-to- tunneling does not reveal the Care-of Address of the MN, although
end delay may vary depending on the particular scenario. With those end-to-end delay may vary depending on the particular scenario. With
correspondents with which it can disclose its Care-of Address ``on those correspondents with which it can disclose its Care-of Address
the wire'', the MN has the option of using route-optimized "on the wire", the MN has the option of using route-optimized
communication. The transport protocol still sees the Home Address communication. The transport protocol still sees the Home Address
with route optimization. Unless the correspondent runs some packet with route optimization. Unless the correspondent runs some packet
capturing utility, the user cannot see which mode (reverse tunneling capturing utility, the user cannot see which mode (reverse tunneling
or route optimization) is being used, but knows that it is or route optimization) is being used, but knows that it is
communicating with the same peer whose URI it knows. This is similar communicating with the same peer whose URI it knows. This is similar
to conversing with a roaming cellphone user whose phone number, like to conversing with a roaming cellphone user whose phone number, like
the URI, remains unchanged. the URI, remains unchanged.
Regardless of whether the MN uses route optimization or reverse Regardless of whether the MN uses route optimization or reverse
tunneling (without ESP encryption), its Home Address is revealed in tunneling (without ESP encryption), its Home Address is revealed in
data packets. When equipped with an ability to inspect packets ``on data packets. When equipped with an ability to inspect packets "on
the wire'', an on-looker on the MN - HA path can determine that the the wire", an onlooker on the MN - HA path can determine that the MN
MN has roamed and could possibly also determine that the user has has roamed and could possibly also determine that the user has
roamed. This could compromise the location privacy even if the MN roamed. This could compromise the location privacy even if the MN
took steps to hide its roaming information from a correspondent. took steps to hide its roaming information from a correspondent.
The above description is valid regardless of whether a Home Address The above description is valid regardless of whether a Home Address
is statically allocated or is dynamically allocated. In either case, is statically allocated or is dynamically allocated. In either case,
the mapping of IP address to geo-location will most likely yield the mapping of IP address to a geo-location will most likely yield
results with the same level of granularity. With the freely results with the same level of granularity. With the freely
available tools on the Internet, this granularity is the physical available tools on the Internet, this granularity is the physical
address of the ISP or the organization which registers ownership of a address of the ISP or the organization that registers ownership of a
prefix chunk. Since an ISP or an organization is not, rightly, prefix chunk. Since an ISP or an organization is not, rightly,
required to provide a blue-print of its subnets, the granularity required to provide a blueprint of its subnets, the granularity
remains fairly coarse for a mobile wireless network. However, remains fairly coarse for a mobile wireless network. However,
sophisticated attackers might be able to conduct site mapping and sophisticated attackers might be able to conduct site mapping and
obtain more fine-grained subnet information. obtain more fine-grained subnet information.
A compromise in location privacy could lead to more targetted A compromise in location privacy could lead to more targeted
profiling of user data. An eavesdropper may specifically track the profiling of user data. An eavesdropper may specifically track the
traffic containing the Home Address, and monitor the movement of the traffic containing the Home Address, and monitor the movement of the
Mobile Node with changing Care-of Address. The profiling problem is Mobile Node with a changing Care-of Address. The profiling problem
not specific to Mobile IPv6, but could be triggered by a compromise is not specific to Mobile IPv6, but could be triggered by a
in location privacy due to revealing the Home Address. A compromise in location privacy due to revealing the Home Address. A
correspondent may take advantage of the knowledge that a user has correspondent may take advantage of the knowledge that a user has
roamed when Care-of Address is revealed, and modulate actions based roamed when the Care-of Address is revealed, and modulate actions
on such a knowledge. Such an information could cause concern to a based on such knowledge. Such information could cause concern to a
mobile user especially when the correspondent turns out be mobile user, especially when the correspondent turns out be
untrustworthy. For these reasons, appropriate security measures on untrustworthy. For these reasons, appropriate security measures on
the management interfaces on the MN to guard against the disclosure the management interfaces on the MN to guard against the disclosure
or misuse of location information should be considered. or misuse of location information should be considered.
Applying existing techniques to thwart profiling may have Applying existing techniques to thwart profiling may have
implications to Mobile IPv6 signaling performance. For instance, implications to Mobile IPv6 signaling performance. For instance,
changing the Care-of Address often would cause additional Return changing the Care-of Address often would cause additional Return
Routability [rfc3775] and binding management signaling. And, Routability [RFC3775] and binding management signaling. And,
changing the Home Address often has implications on IPsec security changing the Home Address often has implications on IPsec security
association management. Solutions should be careful in considering association management. Careful consideration should be given to the
the cost of change of either Care-of Address or Home Address on signaling cost introduced by changing either the Care-of Address or
signaling. the Home Address.
When roaming, a MN may treat its home network nodes as any other When roaming, an MN may treat its home network nodes as any other
correspondents. Reverse tunneling is perhaps sufficient for home correspondents. Reverse tunneling is perhaps sufficient for home
network communication, since route-optimized communication will network communication, since route-optimized communication will
traverse the identical path. Hence, a MN can avoid revealing its traverse the identical path. Hence, an MN can avoid revealing its
Care-of Address to its home network correspondents simply by using Care-of Address to its home network correspondents simply by using
reverse tunneling. The Proxy Neighbor Advertisements [rfc2461] from reverse tunneling. The Proxy Neighbor Advertisements [RFC2461] from
the Home Agent could serve as hints to the home network nodes that 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 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 Mobile Node's current point of attachment unless the MN uses route
optimization with them. optimization with them.
5. Conclusion 5. Conclusion
In this document, we have discussed the location privacy problem as In this document, we have discussed the location privacy problem as
applicable to Mobile IPv6. The problem can be summarized as follows: applicable to Mobile IPv6. The problem can be summarized as follows:
disclosing Care-of Address to a correspondent and revealing Home disclosing the Care-of Address to a correspondent and revealing the
Address to an on-looker can compromise the location privacy of a Home Address to an onlooker can compromise the location privacy of a
Mobile Node, and hence that of a user. We have seen that Mobile Node, and hence that of a user. We have seen that
bidirectional tunneling allows a MN to protect its Care-of Address to bidirectional tunneling allows an MN to protect its Care-of Address
the CN. And, ESP encryption of inner IP packet allows the MN to to the CN. And, ESP encryption of an inner IP packet allows the MN
protect its Home Address from the on-lookers on the MN - HA path. to protect its Home Address from the onlookers on the MN - HA path.
However, with route optimization, the MN will reveal its Care-of However, with route optimization, the MN will reveal its Care-of
Address to the CN. Moreover, route optimization causes the Home Address to the CN. Moreover, route optimization causes the Home
Address to be revealed to on-lookers in the data packets as well as Address to be revealed to onlookers in the data packets as well as in
in Mobile IPv6 signaling messages. The solutions to this problem are Mobile IPv6 signaling messages. The solutions to this problem are
expected to be protocol specifications assuming the existing Mobile expected to be protocol specifications that use the existing Mobile
IPv6 functional entities, namely, the Mobile Node, its Home Agent and IPv6 functional entities, namely, the Mobile Node, its Home Agent,
the Correspondent Node. and the Correspondent Node.
6. IANA Considerations
There are no IANA considerations introduced by this draft.
7. Security Considerations 6. Security Considerations
This document discusses the location privacy problem specific to This document discusses the location privacy problem specific to
Mobile IPv6. Any solution must be able to protect (e.g., using Mobile IPv6. Any solution must be able to protect (e.g., using
encryption) the Home Address from disclosure to on-lookers in data encryption) the Home Address from disclosure to onlookers in data
packets when using route optimization or reverse tunneling. In packets when using route optimization or reverse tunneling. In
addition, solutions must consider protecting the Mobile IPv6 addition, solutions must consider protecting the Mobile IPv6
signaling messages from disclosing the Home Address along the MN - HA signaling messages from disclosing the Home Address along the MN - HA
and MN - CN paths. and MN - CN paths.
Disclosing the Care-of Address is inevitable if a MN wishes to use Disclosing the Care-of Address is inevitable if an MN wishes to use
route optimization. Regardless of whether Care-of Address is an on- route optimization. Regardless of whether the Care-of Address is an
link address of the MN on the visited link or that of a co-operating on-link address of the MN on the visited link or that of a
proxy, mere presence of Binding Cache entry is sufficient for a CN to cooperating proxy, mere presence of a Binding Cache Entry is
ascertain roaming. Hence, a MN concerned with location privacy sufficient for a CN to ascertain roaming. Hence, an MN concerned
should exercise prudence in determining whether to use route with location privacy should exercise prudence in determining whether
optimization with, especially previously unacquainted, to use route optimization with, especially previously unacquainted,
correspondents. correspondents.
The solutions should also consider the use of temporary addresses and The solutions should also consider the use of temporary addresses and
their implications on Mobile IPv6 signaling as discussed in Problem their implications on Mobile IPv6 signaling as discussed in Section
Illustration. Use of IP addresses with privacy extensions [rfc3041] 4, "Problem Illustration". Use of IP addresses with privacy
could be especially useful for Care-of Addresses if appropriate extensions [RFC3041] could be especially useful for Care-of Addresses
tradeoffs with Return Routability signaling are taken into account. if appropriate trade-offs with Return Routability signaling are taken
into account.
8. Acknowledgment 7. Acknowledgments
James Kempf, Qiu Ying, Sam Xia and Lakshminath Dondeti are James Kempf, Qiu Ying, Sam Xia, and Lakshminath Dondeti are
acknowledged for their review and feedback. Thanks to Jari Arkko and acknowledged for their review and feedback. Thanks to Jari Arkko and
Kilian Weniger for the last call review and for suggesting Kilian Weniger for the last-call review and for suggesting
improvements and text. Thanks to Sam Hartman for providing text to improvements and text. Thanks to Sam Hartman for providing text to
improve the problem scope. improve the problem scope.
9. References 8. References
9.1. Normative References 8.1. Normative References
[rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004, in IPv6", RFC 3775, June 2004.
<ftp://ftp.isi.edu/in-notes/rfc3775>.
9.2. Informative References 8.2. Informative References
[draft-haddad] [HADDAD] Haddad, W., et al., "Privacy for Mobile and Multi-homed
Haddad, W. et al., "Privacy for Mobile and Multi-homed Nodes: Problem Statement" Work in Progress, June 2006.
Nodes: MoMiPriv Problem Statement (work in progress)",
October 2004.
[rfc1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", RFC 1035, November 1987, specification", STD 13, RFC 1035, November 1987.
<ftp://ftp.isi.edu/in-notes/rfc1035>.
[rfc2396] Berners-Lee, T., Fielding, R., and L. Manister, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifier (URI): Generic Syntax", STD 66, RFC
August 1998, <ftp://ftp.isi.edu/in-notes/rfc2396>. 3986, January 2005.
[rfc2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461, December
December 1998, <ftp://ftp.isi.edu/in-notes/rfc2461>. 1998.
[rfc2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998, Autoconfiguration", RFC 2462, December 1998.
<ftp://ftp.isi.edu/in-notes/rfc2462>.
[rfc3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001, <ftp://ftp.isi.edu/in-notes/rfc3041>. January 2001.
[rfc3261] Rosenberg, J. et al., "SIP: Session Initiation [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Protocol", RFC 3261, July 2004, A., Peterson, J., Sparks, R., Handley, M., and E.
<ftp://ftp.isi.edu/in-notes/rfc3261>. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[rfc3825] Polk, J. and J. Schnizlein, "DHCP Option for Coordinate- [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
based Location Configuration Information", RFC 3825, Configuration Protocol Option for Coordinate-based
July 2004, <ftp://ftp.isi.edu/in-notes/rfc3825>. Location Configuration Information", RFC 3825, July 2004.
[rfc4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005, Internet Protocol", RFC 4301, December 2005.
<ftp://ftp.isi.edu/in-notes/rfc4301>.
Appendix A. Background Appendix A. Background
The location privacy topic is broad and often has different The location privacy topic is broad and often has different
connotations. It also spans multiple layers in the OSI reference connotations. It also spans multiple layers in the OSI reference
model. Besides, there are attributes beyond an IP address alone that model. Besides, there are attributes beyond an IP address alone that
can reveal hints about location. For instance, even if a can reveal hints about location. For instance, even if a
correspondent is communicating with the same end-point it is used to, correspondent is communicating with the same endpoint it is used to,
the ``time of the day'' attribute can reveal a hint to the user. the "time of day" attribute can reveal a hint to the user. Some
Some roaming cellphone users may have noticed that their SMS messages roaming cellphone users may have noticed that their SMS messages
carry a timestamp of their ``home network'' timezone (for location carry a timestamp of their "home network" time zone (for location
privacy or otherwise) which can reveal that the user is in a privacy or otherwise), which can reveal that the user is in a
different timezone when messages are sent during ``normal'' time of different time zone when messages are sent during a "normal" time of
the day. Furthermore, tools exist on the Internet which can map an the day. Furthermore, tools exist on the Internet that can map an IP
IP address to the physical address of an ISP or the organization address to the physical address of an ISP or the organization that
which owns the prefix chunk. Taking this to another step, with in- owns the prefix chunk. Taking this to another step, with built-in
built GPS receivers on IP hosts, applications can be devised to map GPS receivers on IP hosts, applications can be devised to map geo-
geo-locations to IP network information. Even without GPS receivers, locations to IP network information. Even without GPS receivers,
geo-location can also be obtained in environments where "Geopriv" is geo-locations can also be obtained in environments where "Geopriv" is
supported, for instance as a DHCP option [rfc3825]. In summary, a supported, for instance, as a DHCP option [RFC3825]. In summary, a
user's physical location can be determined or guessed with some user's physical location can be determined or guessed with some
certainty and with varying levels of granularity by different means certainty and with varying levels of granularity by different means,
even though IP addresses themselves do not inherently provide any even though IP addresses themselves do not inherently provide any
geo-location information. It is perhaps useful to bear this broad geo-location information. It is perhaps useful to bear this broad
scope in mind as the problem of IP address location privacy in the scope in mind as the problem of IP address location privacy in the
presence of IP Mobility is addressed. presence of IP Mobility is addressed.
Author's Address Author's Address
Rajeev Koodli Rajeev Koodli
Nokia Research Center Nokia Siemens Networks
975 Page Mill Road, 200 313 Fairchild Drive
Palo Alto, CA 94304 Mountain View, CA 94043
USA
Email: rajeev.koodli@nokia.com EMail: rajeev.koodli@nokia.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 11, line 45 skipping to change at page 11, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 77 change blocks. 
236 lines changed or deleted 208 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/