draft-ietf-mip6-location-privacy-ps-05.txt   draft-ietf-mip6-location-privacy-ps-06.txt 
MIP6 Working Group Rajeev Koodli MIP6 Working Group Rajeev Koodli
INTERNET DRAFT Nokia Research Center Internet-Draft Nokia Research Center
Informational Intended status: Informational February 19, 2007
2 February 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-ps-05.txt draft-ietf-mip6-location-privacy-06.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note Task Force (IETF), its areas, and its working groups. Note that
that other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of six months
six months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a submission of the IETF MIP6 WG. Comments should This Internet-Draft will expire on August 23, 2007.
be directed to the MIP6 WG mailing list, mip6@ietf.org.
Abstract
In this document, we discuss Location Privacy as applicable to
Mobile IPv6. We document the concerns arising from revealing Home
Address to an on-looker and from disclosing Care of Address to a
correspondent.
Contents
Abstract i
1. Introduction 1
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 On-lookers . . . . . . . 4
3.3. Problem Scope . . . . . . . . . . . . . . . . . 4
4. Problem Illustration 5
5. Conclusion 8
6. IANA Considerations 8
7. Security Considerations 8
8. Acknowledgment 9
9. References 9
9.1. Normative References . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . 9
10. Author's Address 10 Copyright Notice
A. Background 11 Copyright (C) The IETF Trust (2007).
Intellectual Property Statement 12 Abstract
Disclaimer of Validity 12 In this document, we discuss Location Privacy as applicable to Mobile
IPv6. We document the concerns arising from revealing Home Address
to an on-looker and from disclosing Care of Address to a
correspondent.
Copyright Statement 13 Table of Contents
Acknowledgment 13 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Definition . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Disclosing the Care-of Address to the Correspondent
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Revealing the Home Address to On-lookers . . . . . . . . . 5
3.3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 5
4. Problem Illustration . . . . . . . . . . . . . . . . . . . . . 6
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
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 The problems of location privacy, and privacy when using IP for
for communication have become important. IP privacy is broadly communication have become important. IP privacy is broadly concerned
concerned with protecting user communication from unwittingly with protecting user communication from unwittingly revealing
revealing information that could be used to analyze and gather information that could be used to analyze and gather sensitive user
sensitive user data. Examples include gathering data at certain data. Examples include gathering data at certain vantage points,
vantage points, collecting information related to specific traffic, collecting information related to specific traffic, and monitoring
and monitoring (perhaps) certain populations of users for activity (perhaps) certain populations of users for activity during specific
during specific times of the day, etc. In this document, we refer times of the day, etc. In this document, we refer to this as the
to this as the "profiling" problem. "profiling" problem.
Location privacy is concerned with the problem of revealing Location privacy is concerned with the problem of revealing roaming,
roaming, which we define here as the process of a Mobile Node which we define here as the process of a Mobile Node (MN) moving from
(MN) moving from one network to another with or without on-going one network to another with or without on-going sessions. A constant
sessions. A constant identifier with global scope can reveal identifier with global scope can reveal roaming. Examples are a
roaming. Examples are a device identifier such as an IP address, device identifier such as an IP address, and a user identifier such
and a user identifier such as a SIP [9] URI [2]. Often, a binding as a SIP [rfc3261] URI[rfc2396]. Often, a binding between these two
between these two identifiers is available, e.g., through DNS [5]. identifiers is available, e.g., through DNS [rfc1035]. Traffic
Traffic analysis of such IP and Upper Layer Protocol identifiers analysis of such IP and Upper Layer Protocol identifiers on single
on single network can indicate device and user roaming. Roaming network can indicate device and user roaming. Roaming could also be
could also be inferred by means of profiling constant fields in IP inferred by means of profiling constant fields in IP communication
communication across multiple network movements. For example, an across multiple network movements. For example, an Interface
Interface Identifier (IID) [10 ] in the IPv6 address that remains Identifier (IID) [rfc2462] in the IPv6 address that remains unchanged
unchanged across networks could suggest roaming. The SPI in the across networks could suggest roaming. The SPI in the IPsec
IPsec [4] header is another field that may be subject to such [rfc4301] header is another field that may be subject to such
profiling and inference. Inferring roaming in this way typically profiling and inference. Inferring roaming in this way typically
requires traffic analysis across multiple networks, or colluding requires traffic analysis across multiple networks, or colluding
attackers, or both. When location privacy is compromised, it could attackers, or both. When location privacy is compromised, it could
lead to more targetted profiling of user communication. lead to more targetted profiling of user communication.
As can be seen, the location privacy problem spans multiple As can be seen, the location privacy problem spans multiple protocol
protocol layers. Nevertheless, it is important to understand and layers. Nevertheless, we can examine problems encountered by nodes
specify the problem as applicable to concerned protocols in order using a particular protocol layer. Roaming is particularly important
to at least mitigate the effects of the problem. In this context, to Mobile IP, which defines a global identifier (Home Address) that
it is particularly important to Mobile IP, which defines a global can reveal device roaming, and in conjunction with a corresponding
identifier (Home Address) that can reveal device roaming, and in user identifier (such as a SIP URI), can also reveal user roaming.
conjunction with a corresponding user identifier (such as a SIP Furthermore, a user may not wish to reveal roaming to
URI), can also reveal user roaming. Furthermore, a user may not correspondent(s), which translates to the use of Care-of Address. As
wish to reveal roaming to correspondent(s), which translates to the with Home Address, the Care-of Address can also reveal the
use of Care-of Address. As with Home Address, the Care-of Address topological location of the Mobile Node.
can also reveal the topological location of the Mobile Node.
This document describes the concerns arising from the use of Home This document scopes the problem of location privacy for the Mobile
Address from a visited network. This document also outlines the IP protocol. The primary goal is to prevent attackers on the path
considerations in disclosing a Care-of Address. This document between the Mobile Node (MN) and the Correspondent Node (CN) from
is primarily concerned with the vulnerabilities arising from detecting roaming due to the disclosure of the Home Address. The
possible traffic analysis along the MN - CN path and the MN - HA attackers are assumed to be able to observe, modify and inject
path, where the disclosure of Mobile IP addresses is sufficient to traffic at one point between the MN and the CN. The attackers are
reveal roaming. This document does not consider inferring roaming assumed not to be able to observe at multiple points and correlate
from profiling fields such as an IID or an SPI for the following observations to detect roaming. For this reason, MAC addresses, IIDs
reasons: First, such inference could be done independently, so the and other fields which can be profiled to detect roaming are only in
problem is not specific to Mobile IP. Second, with Mobile IP, it scope to the extent that they can be used by an attacker at one
is sufficient to simply monitor the usage of Home Address from a point. Upper layer protocol identifiers that expose roaming are out
single visited network in order to deduce roaming. In other words, of scope except that a solution to the problem described here needs
the attackers need not conduct traffic profiling across multiple to be usable as a building block in solutions to those problems.
networks, or collude with each other, or do both in order to infer
roaming when Mobile IP is used. Hence, we limit the scope of this
document to revealing the Mobile IP addresses.
This document is only concerned with IP Address Location Privacy This document also considers the problem from the exposure of Care-of
in the context of Mobile IPv6. It does not address the overall Address to the CN.
privacy problem. For instance, it does not address privacy
issues related to MAC addresses or the relationship of IP and MAC This document is only concerned with IP Address Location Privacy in
addresses [3], or the Upper Layer Protocol addresses. Solution the context of Mobile IPv6. It does not address the overall privacy
to the problem specified here should provide protection against problem. For instance, it does not address privacy issues related to
roaming disclosure due to using Mobile IPv6 addresses from a MAC addresses or the relationship of IP and MAC addresses
visited network. [draft-haddad], or the Upper Layer Protocol addresses. Solution to
the problem specified here should provide protection against roaming
disclosure 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 [1] and the associated terminology defined operation of Mobile IPv6 [rfc3775] and the associated terminology
therein. For convenience, we provide some definitions below. defined therein. For convenience, we provide some definitions below.
2. Definitions 2. Definitions
- 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
- Correspondent Node (CN): A Mobile IPv6 that node corresponds a MN
with a MN o Home Network: The network where the MN is normally present when it
is not roaming
- Home Network: The network where the MN is normally present o Visited Network: A network which a MN uses to access Internet when
when it is not roaming it is roaming
o Home Agent: A router on the MN's home network which provides
- Visited Network: A network which a MN uses to access Internet
when it is roaming
- Home Agent: A router on the MN's home network which 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
- Home Address (HoA): The MN's unicast IP address valid on its network
home network o Care-of Address (CoA): The MN's unicast IP address valid on the
- 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
- Reverse Tunneling or Bidirectional Tunneling: A mechanism used packet forwarding between the MN and its Home Agent
for packet forwarding between the MN and its Home Agent o Route Optimization: A mechanism which allows direct routing of
packets between a roaming MN and its CN, without having to
- Route Optimization: A mechanism which allows direct routing
of 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 When a Mobile IP MN roams from its home network to a visited network
network or from one visited network to another, use of Care-of or from one visited network to another, use of Care-of Address in
Address in communication with a correspondent reveals that the communication with a correspondent reveals that the MN has roamed.
MN has roamed. This assumes that the correspondent is able to This assumes that the correspondent is able to associate the Care-of
associate the Care-of Address to Home Address, for instance by Address to Home Address, for instance by inspecting the Binding Cache
inspecting the Binding Cache Entry. The Home Address itself is Entry. The Home Address itself is assumed to have been obtained by
assumed to have been obtained by whatever means (e.g., through DNS whatever means (e.g., through DNS lookup).
lookup).
3.2. Revealing the Home Address to On-lookers 3.2. Revealing the Home Address to On-lookers
When a Mobile IP MN roams from its home network to a visited When a Mobile IP MN roams from its home network to a visited network
network or from one visited network to another, use of Home Address or from one visited network to another, use of Home Address in
in communication reveals to an on-looker that the MN has roamed. communication reveals to an on-looker that the MN has roamed. When a
When a binding of Home Address to a user identifier (such as binding of Home Address to a user identifier (such as a SIP URI) is
a SIP URI) is available, the Home Address can be used to also available, the Home Address can be used to also determine that the
determine that the user has roamed. This problem is independent user has roamed. This problem is independent of whether the MN uses
of whether the MN uses Care-of Address to communicate directly Care-of Address to communicate directly with the correspondent (i.e.,
with the correspondent (i.e., uses route optimization), or the MN uses route optimization), or the MN communicates via the Home Agent
communicates via the Home Agent (i.e., uses reverse tunneling). (i.e., uses reverse tunneling). Location privacy can be compromised
when an on-looker is present on the MN - CN path (when route
Location privacy may be compromised if an on-looker is present optimization is used). It may also be compromised when the on-looker
on the MN - HA path (when bidirectional tunneling is used), or is present on the MN - HA path (when bidirectional tunneling without
when the on-looker is present on the MN and CN path (when route encryption is used. See below).
optimization is used).
3.3. Problem Scope 3.3. Problem Scope
With existing Mobile IPv6 solutions, there is some protection With existing Mobile IPv6 solutions, there is some protection against
against location privacy. If a Mobile Node uses reverse tunneling location privacy. If a Mobile Node uses reverse tunneling with ESP
with ESP encryption, then the Home Address is not revealed on encryption, then the Home Address is not revealed on the MN - HA
the MN - HA path. So, eavesdroppers on the MN - HA path cannot path. So, eavesdroppers on the MN - HA path cannot determine
determine roaming. They could, however, still profile fields in roaming. They could, however, still profile fields in the ESP
the ESP header; however, this problem is not specific to Mobile header; however, this problem is not specific to Mobile IPv6 location
IPv6 location privacy. privacy.
When a MN uses reverse tunneling (regardless of ESP encryption), When a MN uses reverse tunneling (regardless of ESP encryption), the
the correspondent does not have access to the Care-of Address. correspondent does not have access to the Care-of Address. Hence, it
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 Mobile IPv6 route optimization is used or when reverse tunneling is
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 Consider a Mobile Node at its home network. Whenever it is involved
involved in IP communication, its correspondents can see an in IP communication, its correspondents can see an IP address valid
IP address valid on the home network. Elaborating further, on the home network. Elaborating further, the users involved in peer
the users involved in peer - peer communication are likely - peer communication are likely to see a user-friendly identifier
to see a user-friendly identifier such as a SIP URI, and the such as a SIP URI, and the communication end-points in the IP stack
communication end-points in the IP stack will see IP addresses. will see IP addresses. Users uninterested in or unaware of IP
Users uninterested in or unaware of IP communication details will communication details will not see any difference when the MN
not see any difference when the MN acquires a new IP address. acquires a new IP address. Of course any user can ``tcpdump'' or
Of course any user can ``tcpdump'' or ``ethereal'' a session, ``ethereal'' a session, capture IP packets and map the MN's IP
capture IP packets and map the MN's IP address to an approximate address to an approximate geo-location. This mapping may reveal the
geo-location. This mapping may reveal the home location of a home location of a user, but a correspondent cannot ascertain whether
user, but a correspondent cannot ascertain whether the user has the user has actually roamed or not. Assessing the physical location
actually roamed or not. Assessing the physical location based on based on IP addresses has some similarities to assessing the
IP addresses has some similarities to assessing the geographical geographical location based on the area-code of a telephone number.
location based on the area-code of a telephone number. The The granularity of the physical area corresponding to an IP address
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, often an ISP conducts its network re-numbering, etc. And, an IP
how often an ISP conducts its network re-numbering, etc. And, address cannot also guarantee that a peer is at a certain geographic
an IP address cannot also guarantee that a peer is at a certain area due to technologies such as VPN and tunneling.
geographic area 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 on-lookers.
With its correspondents, the MN can either communicate directly With its correspondents, the MN can either communicate directly or
or reverse tunnel its packets through the Home Agent. Using reverse tunnel its packets through the Home Agent. Using reverse
reverse tunneling does not reveal Care-of Address of the MN, tunneling does not reveal Care-of Address of the MN, although end-to-
although end-to-end delay may vary depending on the particular end delay may vary depending on the particular scenario. With those
scenario. With those correspondents with which it can disclose its correspondents with which it can disclose its Care-of Address ``on
Care-of Address ``on the wire'', the MN has the option of using the wire'', the MN has the option of using route-optimized
route-optimized communication. The transport protocol still sees communication. The transport protocol still sees the Home Address
the Home Address with route optimization. Unless the correspondent with route optimization. Unless the correspondent runs some packet
runs some packet capturing utility, the user cannot see which mode capturing utility, the user cannot see which mode (reverse tunneling
(reverse tunneling or route optimization) is being used, but knows or route optimization) is being used, but knows that it is
that it is communicating with the same peer whose URI it knows. communicating with the same peer whose URI it knows. This is similar
This is similar to conversing with a roaming cellphone user whose to conversing with a roaming cellphone user whose phone number, like
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 tunneling (without ESP encryption), its Home Address is revealed in
in data packets. When equipped with an ability to inspect packets data packets. When equipped with an ability to inspect packets ``on
``on the wire'', an on-looker on the MN - HA path can determine the wire'', an on-looker on the MN - HA path can determine that the
that the MN has roamed and could possibly also determine that MN has roamed and could possibly also determine that the user has
the user has roamed. This could compromise the location privacy roamed. This could compromise the location privacy even if the MN
even if the MN took steps to hide its roaming information from a took steps to hide its roaming information from a correspondent.
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 is statically allocated or is dynamically allocated. In either case,
case, the mapping of IP address to geo-location will most likely the mapping of IP address to geo-location will most likely yield
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 address of the ISP or the organization which registers ownership of a
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 blue-print 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 targetted
profiling of user data. An eavesdropper may specifically track profiling of user data. An eavesdropper may specifically track the
the traffic containing the Home Address, and monitor the movement traffic containing the Home Address, and monitor the movement of the
of the Mobile Node with changing Care-of Address. The profiling Mobile Node with changing Care-of Address. The profiling problem is
problem is not specific to Mobile IPv6, but could be triggered not specific to Mobile IPv6, but could be triggered by a compromise
by a compromise in location privacy due to revealing the Home in location privacy due to revealing the Home Address. A
Address. A correspondent may take advantage of the knowledge that correspondent may take advantage of the knowledge that a user has
a user has roamed when Care-of Address is revealed, and modulate roamed when Care-of Address is revealed, and modulate actions based
actions based on such a knowledge. Such an information could cause on such a knowledge. Such an information could cause concern to a
concern to a mobile user especially when the correspondent turns mobile user especially when the correspondent turns out be
out be untrustworthy. For these reasons, appropriate management untrustworthy. For these reasons, appropriate security measures on
interfaces on the MN to guard against the misuse of location the management interfaces on the MN to guard against the disclosure
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 [1] and binding management signaling. And, changing Routability [rfc3775] and binding management signaling. And,
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. Solutions should be careful in considering
the cost of change of either Care-of Address or Home Address on the cost of change of either Care-of Address or Home Address on
signaling. signaling.
When roaming, a MN may treat its home network nodes as any other When roaming, a 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, a 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 [7] from the reverse tunneling. The Proxy Neighbor Advertisements [rfc2461] from
Home Agent could serve as hints to the home network nodes that the the Home Agent could serve as hints to the home network nodes that
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 In this document, we have discussed the location privacy problem as
as applicable to Mobile IPv6. The problem can be summarized applicable to Mobile IPv6. The problem can be summarized as follows:
as follows: disclosing Care-of Address to a correspondent and disclosing Care-of Address to a correspondent and revealing Home
revealing Home Address to an on-looker can compromise the location Address to an on-looker can compromise the location privacy of a
privacy of a Mobile Node, and hence that of a user. We have seen Mobile Node, and hence that of a user. We have seen that
that bidirectional tunneling allows a MN to protect its Care-of bidirectional tunneling allows a MN to protect its Care-of Address to
Address to the CN. And, ESP encryption of inner IP packet allows the CN. And, ESP encryption of inner IP packet allows the MN to
the MN to protect its Home Address from the on-lookers on the MN - protect its Home Address from the on-lookers on the MN - HA path.
HA path. However, with route optimization, the MN will reveal its However, with route optimization, the MN will reveal its Care-of
Care-of Address to the CN. Moreover, route optimization causes the Address to the CN. Moreover, route optimization causes the Home
Home Address to be revealed to on-lookers in the data packets as Address to be revealed to on-lookers in the data packets as well as
well as in Mobile IPv6 signaling messages. The solutions to this in Mobile IPv6 signaling messages. The solutions to this problem are
problem are expected to be protocol specifications assuming the expected to be protocol specifications assuming the existing Mobile
existing Mobile IPv6 functional entities, namely, the Mobile Node, IPv6 functional entities, namely, the Mobile Node, its Home Agent and
its Home Agent and the Correspondent Node. the Correspondent Node.
6. IANA Considerations 6. IANA Considerations
There are no IANA considerations introduced by this draft. There are no IANA considerations introduced by this draft.
7. Security Considerations 7. 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 encryption) the Home Address from disclosure to on-lookers in data
data packets when using route optimization or reverse tunneling. packets when using route optimization or reverse tunneling. In
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 - signaling messages from disclosing the Home Address along the MN - HA
HA and MN - CN paths. and MN - CN paths.
Disclosing the Care-of Address is inevitable if a MN wishes to Disclosing the Care-of Address is inevitable if a MN wishes to use
use route optimization. Regardless of whether Care-of Address route optimization. Regardless of whether Care-of Address is an on-
is an on-link address of the MN on the visited link or that of link address of the MN on the visited link or that of a co-operating
a co-operating proxy, mere presence of Binding Cache entry is proxy, mere presence of Binding Cache entry is sufficient for a CN to
sufficient for a CN to ascertain roaming. Hence, a MN concerned ascertain roaming. Hence, a MN concerned with location privacy
with location privacy should exercise prudence in determining should exercise prudence in determining whether to use route
whether to use route optimization with, especially previously optimization with, especially previously unacquainted,
unacquainted, correspondents. correspondents.
The solutions should also consider the use of temporary addresses The solutions should also consider the use of temporary addresses and
and their implications on Mobile IPv6 signaling as discussed in their implications on Mobile IPv6 signaling as discussed in Problem
Section 4. Use of IP addresses with privacy extensions [6] could Illustration. Use of IP addresses with privacy extensions [rfc3041]
be especially useful for Care-of Addresses if appropriate tradeoffs could be especially useful for Care-of Addresses if appropriate
with Return Routability signaling are taken into account. tradeoffs with Return Routability signaling are taken into account.
8. Acknowledgment 8. Acknowledgment
Thanks to James Kempf, Qiu Ying, Sam Xia and Lakshminath Dondeti James Kempf, Qiu Ying, Sam Xia and Lakshminath Dondeti are
for the review and feedback. Thanks to Jari Arkko and Kilian acknowledged for their review and feedback. Thanks to Jari Arkko and
Weniger for the last call review and for suggesting improvements Kilian Weniger for the last call review and for suggesting
and text. improvements and text. Thanks to Sam Hartman for providing text to
improve the problem scope.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in [rfc3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
IPv6. Request for Comments 3775, Internet Engineering Task in IPv6", RFC 3775, June 2004,
Force, June 2004. <ftp://ftp.isi.edu/in-notes/rfc3775>.
9.2. Informative References 9.2. Informative References
[2] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource [draft-haddad]
Identifiers (URI): Generic Syntax. Request for Comments (Draft Haddad, W. et al., "Privacy for Mobile and Multi-homed
Standard) 2396, Internet Engineering Task Force, August 1998. Nodes: MoMiPriv Problem Statement (work in progress)",
October 2004.
[3] W. Haddad and et al., Privacy for Mobile and Multi-homed [rfc1035] Mockapetris, P., "Domain names - implementation and
Nodes: MoMiPriv Problem Statement (work in progress). specification", RFC 1035, November 1987,
Internet Draft, Internet Engineering Task Force, October 2004. <ftp://ftp.isi.edu/in-notes/rfc1035>.
[4] S. Kent and K. Seo. Security Architecture for the Internet [rfc2396] Berners-Lee, T., Fielding, R., and L. Manister, "Uniform
Protocol. Request for Comments (Proposed Standard) 4301, Resource Identifiers (URI): Generic Syntax", RFC 2396,
Internet Engineering Task Force, December 2005. August 1998, <ftp://ftp.isi.edu/in-notes/rfc2396>.
[5] P. V. Mockapetris. Domain names - implementation and [rfc2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
specification. Request for Comments (Standard) 1035, Internet Discovery for IP Version 6 (IPv6)", RFC 2461,
Engineering Task Force, November 1987. December 1998, <ftp://ftp.isi.edu/in-notes/rfc2461>.
[6] T. Narten and R. Draves. Privacy Extensions for Stateless [rfc2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Address Autoconfiguration in IPv6. Request for Comments 3041, Autoconfiguration", RFC 2462, December 1998,
Internet Engineering Task Force, January 2001. <ftp://ftp.isi.edu/in-notes/rfc2462>.
[7] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for [rfc3041] Narten, T. and R. Draves, "Privacy Extensions for
IP Version 6 (IPv6). Request for Comments (Draft Standard) Stateless Address Autoconfiguration in IPv6", RFC 3041,
2461, Internet Engineering Task Force, December 1998. January 2001, <ftp://ftp.isi.edu/in-notes/rfc3041>.
[8] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for [rfc3261] Rosenberg, J. et al., "SIP: Session Initiation
Coordinate-based Location Configuration Information. Request Protocol", RFC 3261, July 2004,
for Comments 3825, Internet Engineering Task Force, July 2004. <ftp://ftp.isi.edu/in-notes/rfc3261>.
[9] J. Rosenberg and et al. SIP: Session Initiation Protocol. [rfc3825] Polk, J. and J. Schnizlein, "DHCP Option for Coordinate-
Request for Comments (Proposed Standard) 3261, Internet based Location Configuration Information", RFC 3825,
Engineering Task Force, June 2002. July 2004, <ftp://ftp.isi.edu/in-notes/rfc3825>.
[10] S. Thomson and T. Narten. IPv6 Stateless Address [rfc4301] Kent, S. and K. Seo, "Security Architecture for the
Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Protocol", RFC 4301, December 2005,
Internet Engineering Task Force, December 1998. <ftp://ftp.isi.edu/in-notes/rfc4301>.
10. Author's Address 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 end-point it is used to,
the ``time of the 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'' timezone (for location
privacy or otherwise) which can reveal that the user is in a
different timezone when messages are sent during ``normal'' time of
the day. Furthermore, tools exist on the Internet which can map an
IP address to the physical address of an ISP or the organization
which owns the prefix chunk. Taking this to another step, with in-
built GPS receivers on IP hosts, applications can be devised to map
geo-locations to IP network information. Even without GPS receivers,
geo-location 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.
Author's Address
Rajeev Koodli Rajeev Koodli
Nokia Research Center Nokia Research Center
975 Page Mill Road, 200 975 Page Mill Road, 200
Palo Alto, CA 94034 USA Palo Alto, CA 94304
Phone: +1 408 425 6684 USA
Fax: +1 650 625 2502
E-Mail: Rajeev.Koodli@nokia.com
A. Background Email: rajeev.koodli@nokia.com
The location privacy topic is broad and often has different Full Copyright Statement
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 end-point it is used
to, the ``time of the 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'' timezone (for
location privacy or otherwise) which can reveal that the user is in
a different timezone when messages are sent during ``normal'' time
of the day. Furthermore, tools exist on the Internet which can map
an IP address to the physical address of an ISP or the organization
which owns the prefix chunk. Taking this to another step, with
in-built GPS receivers on IP hosts, applications can be devised
to map geo-locations to IP network information. Even without GPS
receivers, geo-location can also be obtained in environments where
[Geopriv] is supported, for instance as a DHCP option [8].
In summary, a user's physical location can be determined or Copyright (C) The IETF Trust (2007).
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.
Intellectual Property Statement 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.
The IETF takes no position regarding the validity or scope of This document and the information contained herein are provided on an
any Intellectual Property Rights or other rights that might be "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
claimed to pertain to the implementation or use of the technology OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
described in this document or the extent to which any license THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
under such rights might or might not be available; nor does it OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
represent that it has made any independent effort to identify any THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
such rights. Information on the procedures with respect to rights WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
in RFC documents can be found in BCP 78 and BCP 79.
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 Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the attempt made to obtain a general license or permission for the use of
use of 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 specification can be obtained from the IETF on-line IPR repository at
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.
Disclaimer of Validity
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.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 60 change blocks. 
362 lines changed or deleted 332 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/