draft-ietf-mip6-location-privacy-ps-04.txt   draft-ietf-mip6-location-privacy-ps-05.txt 
MIP6 Working Group Rajeev Koodli MIP6 Working Group Rajeev Koodli
INTERNET DRAFT Nokia Research Center INTERNET DRAFT Nokia Research Center
Informational Informational
23 October 2006 2 February 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-04.txt draft-ietf-mip6-location-privacy-ps-05.txt
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 other groups may also distribute working documents as that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of
and may be updated, replaced, or obsoleted by other documents at six months and may be updated, replaced, or obsoleted by other
any time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
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 be This document is a submission of the IETF MIP6 WG. Comments should
directed to the MIP6 WG mailing list, mip6@ietf.org. be directed to the MIP6 WG mailing list, mip6@ietf.org.
Abstract Abstract
In this document, we discuss Location Privacy as applicable to In this document, we discuss Location Privacy as applicable to
Mobile IPv6. We document the concerns arising from revealing Home Mobile IPv6. We document the concerns arising from revealing Home
Address to an on-looker and from disclosing Care of Address to a Address to an on-looker and from disclosing Care of Address to a
correspondent. correspondent.
Contents Contents
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
2. Problem Definition 2 2. Definitions 3
2.1. Disclosing the Care of Address to the Correspondent Node 2
2.2. Revealing the Home Address to On-lookers . . . . . . . . 3
2.3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Illustration 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. Conclusion 5 4. Problem Illustration 5
5. IANA Considerations 6 5. Conclusion 8
6. Security Considerations 6 6. IANA Considerations 8
7. Acknowledgment 6 7. Security Considerations 8
8. Author's Address 6 8. Acknowledgment 9
A. Background 7 9. References 9
9.1. Normative References . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . 9
Intellectual Property Statement 7 10. Author's Address 10
Disclaimer of Validity 8 A. Background 11
Copyright Statement 8 Intellectual Property Statement 12
Acknowledgment 8 Disclaimer of Validity 12
Copyright Statement 13
Acknowledgment 13
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
communication have become important. IP privacy is broadly concerned for 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
"profiling" problem. to this as the "profiling" problem.
Location privacy is concerned with the problem of revealing roaming, Location privacy is concerned with the problem of revealing
which we define here as the process of a Mobile Node moving from one roaming, which we define here as the process of a Mobile Node
network to another with or without on-going sessions. A constant (MN) moving from one network to another with or without on-going
identifier with global scope can reveal roaming. Such a global scope sessions. A constant identifier with global scope can reveal
identifier could be a device identifier or a user identifier. Often, roaming. Examples are a device identifier such as an IP address,
a binding between these two identifiers is also available, e.g., and a user identifier such as a SIP [9] URI [2]. Often, a binding
through DNS. The location privacy problem is particularly applicable between these two identifiers is available, e.g., through DNS [5].
to Mobile IP where the Home Address on a visited network can reveal Traffic analysis of such IP and Upper Layer Protocol identifiers
device roaming and, together with a user identifier (such as a SIP on single network can indicate device and user roaming. Roaming
URI), can reveal user roaming. Even when the binding between a user could also be inferred by means of profiling constant fields in IP
identifier and the Home Address is unavailable, freely available communication across multiple network movements. For example, an
tools on the Internet can map the Home Address to the owner of the Interface Identifier (IID) [10 ] in the IPv6 address that remains
Home Prefix, which can reveal that a user from a particular ISP unchanged across networks could suggest roaming. The SPI in the
has roamed. So, the location privacy problem is a subset of the IPsec [4] header is another field that may be subject to such
profiling problem in which revealing a globally visible identifier profiling and inference. Inferring roaming in this way typically
compromises a user's location privacy. When location privacy is requires traffic analysis across multiple networks, or colluding
compromised, it could lead to more targetted profiling. attackers, or both. When location privacy is compromised, it could
lead to more targetted profiling of user communication.
Furthermore, a user may not wish to reveal roaming to As can be seen, the location privacy problem spans multiple
correspondent(s). In Mobile IP, this translates to the use protocol layers. Nevertheless, it is important to understand and
of Care of Address. As with Home Address, the Care of Address can specify the problem as applicable to concerned protocols in order
also reveal the topological location of the Mobile Node. to at least mitigate the effects of the problem. In this context,
it 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 Care-of Address. As with Home Address, the Care-of Address
can also reveal the topological location of the Mobile Node.
In this document, the concerns arising from the use of a globally This document describes the concerns arising from the use of Home
visible identifier, such as a Home Address, when roaming are Address from a visited network. This document also outlines the
described. Similarly, the concerns from revealing a Care of Address considerations in disclosing a Care-of Address. This document
to a correspondent are also outlined. The solutions to these is primarily concerned with the vulnerabilities arising from
problems are meant to be specified in a separate document. possible traffic analysis along the MN - CN path and the MN - HA
path, where the disclosure of Mobile IP addresses is sufficient to
reveal roaming. This document does not consider inferring roaming
from profiling fields such as an IID or an SPI for the following
reasons: First, such inference could be done independently, so the
problem is not specific to Mobile IP. Second, with Mobile IP, it
is sufficient to simply monitor the usage of Home Address from a
single visited network in order to deduce roaming. In other words,
the attackers need not conduct traffic profiling across multiple
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 in This document is only concerned with IP Address Location Privacy
the context of Mobile IPv6. It does not address the overall privacy in the context of Mobile IPv6. It does not address the overall
problem. For instance, it does not address privacy issues related to privacy problem. For instance, it does not address privacy
MAC addresses or the relationship of IP and MAC addresses [1]. issues related to MAC addresses or the relationship of IP and MAC
addresses [3], 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.
2. Problem Definition This document assumes that the reader is familiar with the basic
operation of Mobile IPv6 [1] and the associated terminology defined
therein. For convenience, we provide some definitions below.
2.1. Disclosing the Care of Address to the Correspondent Node 2. Definitions
When a Mobile IP MN roams from its home network to a visited network - Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams
or from one visited network to another, use of Care of Address in around networks
communication with a correspondent reveals that the MN has roamed.
This assumes that the correspondent is able to associate the CoA to
HoA, for instance by inspecting the Binding Cache Entry. The HoA
itself is assumed to have been obtained by whatever means (e.g.,
through DNS lookup).
2.2. Revealing the Home Address to On-lookers - Correspondent Node (CN): A Mobile IPv6 that node corresponds
with a MN
When a Mobile IP MN roams from its home network to a visited network - Home Network: The network where the MN is normally present
or from one visited network to another, use of Home Address in when it is not roaming
communication reveals to an on-looker that the MN has roamed. When
a binding of Home Address to a user identifier (such as a SIP
URI or NAI) 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 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 may be compromised if an on-looker is present on - Visited Network: A network which a MN uses to access Internet
the MN - HA path (when bidirectional tunneling is used), or when the when it is roaming
on-looker is present on the MN and CN path (when route optimization
is used).
2.3. Problem Scope - Home Agent: A router on the MN's home network which provides
forwarding support when the MN is roaming
With existing Mobile IPv6 solutions, there is some protection against - Home Address (HoA): The MN's unicast IP address valid on its
location privacy. If a Mobile Node uses reverse tunneling with ESP home network
encryption, then the HoA is not revealed on the MN - HA path. So,
eavesdroppers on the MN - HA path cannot determine roaming. They - Care-of Address (CoA): The MN's unicast IP address valid on the
could, however, still profile fields in the ESP header; however, this visited network
problem is not specific to Mobile IPv6 location privacy.
- Reverse Tunneling or Bidirectional Tunneling: A mechanism used
for packet forwarding between the MN and its Home Agent
- Route Optimization: A mechanism which allows direct routing
of packets between a roaming MN and its CN, without having to
traverse the home network.
3. Problem Definition
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 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 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 On-lookers
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 communication reveals to an on-looker that the MN has roamed.
When a binding of 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 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 may be compromised if an on-looker is present
on the MN - HA path (when bidirectional tunneling is used), or
when the on-looker is present on the MN and CN path (when route
optimization is used).
3.3. Problem Scope
With existing Mobile IPv6 solutions, there is some protection
against location privacy. If a Mobile Node uses reverse tunneling
with 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.
When a MN uses reverse tunneling (regardless of ESP encryption), When a MN uses reverse tunneling (regardless of ESP encryption),
the correspondent does not have access to the CoA. Hence, it cannot the correspondent does not have access to the Care-of Address.
determine that the MN has roamed. Hence, it 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
used without protecting the inner IP packet containing the HoA. is used without protecting the inner IP packet containing the Home
Address.
3. 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
in IP communication, its correspondents can see an IP address valid involved in IP communication, its correspondents can see an
on the home network. Elaborating further, the users involved in peer IP address valid on the home network. Elaborating further,
- peer communication are likely to see a user-friendly identifier the users involved in peer - peer communication are likely
such as a SIP URI, and the communication end-points in the IP to see a user-friendly identifier such as a SIP URI, and the
stack will see IP addresses. Users uninterested in or unaware of communication end-points in the IP stack will see IP addresses.
IP communication details will not see any difference when the MN Users uninterested in or unaware of IP communication details will
acquires a new IP address. Of course any user can ``tcpdump'' or not see any difference when the MN acquires a new IP address.
``ethereal'' a session, capture IP packets and map the MN's IP Of course any user can ``tcpdump'' or ``ethereal'' a session,
address to an approximate geo-location. This mapping may reveal capture IP packets and map the MN's IP address to an approximate
the "home location" of a user, but a correspondent cannot ascertain geo-location. This mapping may reveal the home location of a
whether the user has actually roamed or not. Assessing the physical user, but a correspondent cannot ascertain whether the user has
location based on IP addresses has some similarities to assessing the actually roamed or not. Assessing the physical location based on
geographical location based on the area-code of a telephone number. IP addresses has some similarities to assessing the geographical
The granularity of the physical area corresponding to an IP address location based on the area-code of a telephone number. The
can vary depending on how sophisticated the available tools are, how granularity of the physical area corresponding to an IP address
often an ISP conducts its network re-numbering, etc. And, an IP can vary depending on how sophisticated the available tools are,
address cannot also guarantee that a peer is at a certain geographic how often an ISP conducts its network re-numbering, etc. And,
area due to technologies such as VPN and tunneling. an IP address cannot also guarantee that a peer is at a certain
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 or With its correspondents, the MN can either communicate directly
reverse tunnel its packets through the Home Agent. Using reverse or reverse tunnel its packets through the Home Agent. Using
tunneling does not reveal the new IP address of the MN, although reverse tunneling does not reveal Care-of Address of the MN,
end-to-end delay may vary depending on the particular scenario. With although end-to-end delay may vary depending on the particular
those correspondents with which it can disclose its new IP address scenario. With those correspondents with which it can disclose its
``on the wire'', the MN has the option of using route-optimized Care-of Address ``on the wire'', the MN has the option of using
communication. The transport protocol still sees the Home Address route-optimized communication. The transport protocol still sees
with route optimization. Unless the correspondent runs some the Home Address with route optimization. Unless the correspondent
packet capturing utility, the user cannot see which mode (reverse runs some packet capturing utility, the user cannot see which mode
tunneling or route optimization) is being used, but knows that it is (reverse tunneling or route optimization) is being used, but knows
communicating with the same peer whose URI it knows. This is similar that it is communicating with the same peer whose URI it knows.
to conversing with a roaming cellphone user whose phone number, like This is similar to conversing with a roaming cellphone user whose
the URI, remains unchanged. phone number, like 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
data packets. When equipped with an ability to inspect packets ``on in data packets. When equipped with an ability to inspect packets
the wire'', an on-looker on the MN - HA path can determine that the ``on the wire'', an on-looker on the MN - HA path can determine
MN has roamed and could possibly also determine that the user has that the MN has roamed and could possibly also determine that
roamed. This could compromise the location privacy even if the MN the user has roamed. This could compromise the location privacy
took steps to hide its roaming information from a correspondent. 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 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, the mapping of IP address to geo-location will most likely case, the mapping of IP address to geo-location will most likely
yield results with the same level of granularity. With the freely yield 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 prefix chunk. Since an ISP or an organization is not, rightly, a 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 the profiling of user data. An eavesdropper may specifically track
traffic containing the Home Address, and monitor the movement of the the traffic containing the Home Address, and monitor the movement
Mobile Node with changing Care of Address. The profiling problem is of the Mobile Node with changing Care-of Address. The profiling
not specific to Mobile IPv6, but could be triggered by a compromise problem is not specific to Mobile IPv6, but could be triggered
in location privacy due to revealing the Home Address. by a compromise in location privacy due to revealing the Home
A correspondent may take advantage of the knowledge that a user Address. A correspondent may take advantage of the knowledge that
has roamed when Care of Address is revealed, and modulate actions a user has roamed when Care-of Address is revealed, and modulate
based on such a knowledge. Such an information could cause concern actions based on such a knowledge. Such an information could cause
to a mobile user especially when the correspondent turns out be concern to a mobile user especially when the correspondent turns
untrustworthy. out be untrustworthy. For these reasons, appropriate management
interfaces on the MN to guard against the 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 and binding management signaling. And, changing the Routability [1] and binding management signaling. And, changing
Home Address often has implications on IPsec security association the Home Address often has implications on IPsec security
management. Solutions should be careful in considering the cost of association management. Solutions should be careful in considering
change of either CoA or HoA on signaling. For instance, changing the the cost of change of either Care-of Address or Home Address on
Care of Address often would cause additional Return Routability and signaling.
binding management signaling. And, changing the Home Address often
has implications on IPsec security association management. These
issues need to be addressed in the solutions These issues should be
addressed in the solutions.
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 from the Home reverse tunneling. The Proxy Neighbor Advertisements [7] from the
Agent could serve as hints to the home network nodes that the Mobile Home Agent could serve as hints to the home network nodes that the
Node is away. However, they won't be able to know the Mobile Node's Mobile Node is away. However, they will not be able to know the
current point of attachment unless the MN uses route optimization Mobile Node's current point of attachment unless the MN uses route
with them. optimization with them.
4. Conclusion 5. Conclusion
In this document, we have discussed the location privacy problem In this document, we have discussed the location privacy problem
as applicable to Mobile IPv6. The problem can be summarized as as applicable to Mobile IPv6. The problem can be summarized
follows: disclosing Care of Address to a correspondent and revealing as follows: disclosing Care-of Address to a correspondent and
Home Address to an on-looker can compromise the location privacy revealing Home Address to an on-looker can compromise the location
of a Mobile Node, and hence that of a user. We have seen that privacy of a Mobile Node, and hence that of a user. We have seen
bidirectional tunneling allows a MN to protect its CoA to the CN. that bidirectional tunneling allows a MN to protect its Care-of
And, ESP encryption of inner IP packet allows the MN to protect its Address to the CN. And, ESP encryption of inner IP packet allows
HoA from the on-lookers on the MN - HA path. the MN to protect its Home Address from the on-lookers on the MN -
HA path. However, with route optimization, the MN will reveal its
However, with route optimization, the MN will reveal its CoA to the Care-of Address to the CN. Moreover, route optimization causes the
CN. Moreover, route optimization causes the HoA to be revealed to Home Address to be revealed to on-lookers in the data packets as
on-lookers in the data packets as well as in Mobile IPv6 signaling well as in Mobile IPv6 signaling messages. The solutions to this
messages. The solutions to this problem are expected to be protocol problem are expected to be protocol specifications assuming the
specifications assuming the existing Mobile IPv6 functional entities, existing Mobile IPv6 functional entities, namely, the Mobile Node,
namely, the Mobile Node, its Home Agent and the Correspondent Node. its Home Agent and the Correspondent Node.
5. IANA Considerations 6. IANA Considerations
There are no IANA considerations introduced by this draft. There are no IANA considerations introduced by this draft.
6. Security Considerations 7. Security Considerations
This document discusses location privacy because of IP mobility. This document discusses the location privacy problem specific to
Solutions to provide location privacy, especially any signaling over Mobile IPv6. Any solution must be able to protect (e.g., using
the Internet, must be secure in order to be effective. Individual encryption) the Home Address from disclosure to on-lookers in
solutions must describe the security implications. 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.
7. Acknowledgment Disclosing the Care-of Address is inevitable if a MN wishes to
use route optimization. Regardless of whether Care-of Address
is an on-link address of the MN on the visited link or that of
a co-operating proxy, mere presence of Binding Cache entry is
sufficient for a CN to ascertain roaming. Hence, a MN concerned
with location privacy should exercise prudence in determining
whether to use route optimization with, especially previously
unacquainted, correspondents.
Thanks to James Kempf, Qiu Ying and Sam Xia for the review and The solutions should also consider the use of temporary addresses
feedback. Thanks to Jari Arkko and Kilian Weniger for the last call and their implications on Mobile IPv6 signaling as discussed in
review and for suggesting improvements and text. Section 4. Use of IP addresses with privacy extensions [6] could
be especially useful for Care-of Addresses if appropriate tradeoffs
with Return Routability signaling are taken into account.
Informative References 8. Acknowledgment
[1] W. Haddad and et al. Privacy for Mobile and Multi-homed Nodes: Thanks to James Kempf, Qiu Ying, Sam Xia and Lakshminath Dondeti
MoMiPriv Problem Statement (work in progress). Internet Draft, for the review and feedback. Thanks to Jari Arkko and Kilian
Internet Engineering Task Force, October 2004. Weniger for the last call review and for suggesting improvements
and text.
[2] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for 9. References
Coordinate-based Location Configuration Information. Request for
Comments 3825, Internet Engineering Task Force, July 2004.
8. Author's Address 9.1. Normative References
[1] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in
IPv6. Request for Comments 3775, Internet Engineering Task
Force, June 2004.
9.2. Informative References
[2] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource
Identifiers (URI): Generic Syntax. Request for Comments (Draft
Standard) 2396, Internet Engineering Task Force, August 1998.
[3] W. Haddad and et al., Privacy for Mobile and Multi-homed
Nodes: MoMiPriv Problem Statement (work in progress).
Internet Draft, Internet Engineering Task Force, October 2004.
[4] S. Kent and K. Seo. Security Architecture for the Internet
Protocol. Request for Comments (Proposed Standard) 4301,
Internet Engineering Task Force, December 2005.
[5] P. V. Mockapetris. Domain names - implementation and
specification. Request for Comments (Standard) 1035, Internet
Engineering Task Force, November 1987.
[6] T. Narten and R. Draves. Privacy Extensions for Stateless
Address Autoconfiguration in IPv6. Request for Comments 3041,
Internet Engineering Task Force, January 2001.
[7] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (IPv6). Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998.
[8] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for
Coordinate-based Location Configuration Information. Request
for Comments 3825, Internet Engineering Task Force, July 2004.
[9] J. Rosenberg and et al. SIP: Session Initiation Protocol.
Request for Comments (Proposed Standard) 3261, Internet
Engineering Task Force, June 2002.
[10] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard) 2462,
Internet Engineering Task Force, December 1998.
10. Author's Address
Rajeev Koodli Rajeev Koodli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 975 Page Mill Road, 200
Mountain View, CA 94043 USA Palo Alto, CA 94034 USA
Phone: +1 650 625 2359 Phone: +1 408 425 6684
Fax: +1 650 625 2502 Fax: +1 650 625 2502
E-Mail: Rajeev.Koodli@nokia.com E-Mail: Rajeev.Koodli@nokia.com
A. Background 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 model. Besides, there are attributes beyond an IP address alone
that can reveal hints about location. For instance, even if a that can reveal hints about location. For instance, even if a
correspondent is communicating with the same end-point it is used correspondent is communicating with the same end-point it is used
to, the ``time of the day'' attribute can reveal a hint to the to, the ``time of the day'' attribute can reveal a hint to the
user. Some roaming cellphone users may have noticed that their SMS user. Some roaming cellphone users may have noticed that their SMS
messages carry a timestamp of their ``home network'' timezone (for messages carry a timestamp of their ``home network'' timezone (for
skipping to change at page 7, line 22 skipping to change at page 11, line 27
user. Some roaming cellphone users may have noticed that their SMS user. Some roaming cellphone users may have noticed that their SMS
messages carry a timestamp of their ``home network'' timezone (for messages carry a timestamp of their ``home network'' timezone (for
location privacy or otherwise) which can reveal that the user is in location privacy or otherwise) which can reveal that the user is in
a different timezone when messages are sent during ``normal'' time a different timezone when messages are sent during ``normal'' time
of the day. Furthermore, tools exist on the Internet which can map 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 an IP address to the physical address of an ISP or the organization
which owns the prefix chunk. Taking this to another step, with which owns the prefix chunk. Taking this to another step, with
in-built GPS receivers on IP hosts, applications can be devised in-built GPS receivers on IP hosts, applications can be devised
to map geo-locations to IP network information. Even without GPS to map geo-locations to IP network information. Even without GPS
receivers, geo-location can also be obtained in environments where receivers, geo-location can also be obtained in environments where
[Geopriv] is supported, for instance as a DHCP option [2]. [Geopriv] is supported, for instance as a DHCP option [8].
In summary, a user's physical location can be determined or guessed In summary, a user's physical location can be determined or
with some certainty and with varying levels of granularity by guessed with some certainty and with varying levels of granularity
different means even though IP addresses themselves do not inherently by different means even though IP addresses themselves do not
provide any geo-location information. It is perhaps useful to bear inherently provide any geo-location information. It is perhaps
this broad scope in mind as the problem of IP address location useful to bear this broad scope in mind as the problem of IP
privacy in the presence of IP Mobility is addressed. address location privacy in the presence of IP Mobility is
addressed.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of
Intellectual Property Rights or other rights that might be claimed to any Intellectual Property Rights or other rights that might be
pertain to the implementation or use of the technology described in claimed to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights. Information on the procedures with respect to rights
found in BCP 78 and BCP 79. 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 such proprietary rights by implementers or users of this use of 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
http://www.ietf.org/ipr. at 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 Disclaimer of Validity
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 57 change blocks. 
222 lines changed or deleted 349 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/