MIP6 Working Group Rajeev Koodli
INTERNET DRAFT Nokia Research Center
Informational
25 June 2006
IP Address Location Privacy and Mobile IPv6: Problem Statement
draft-ietf-mip6-location-privacy-ps-02.txt
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
http://www.ietf.org/shadow.html.
This document is a submission of the IETF MIP6 WG. Comments should 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.
Koodli Expires 25 December 2006 [Page i]
Internet Draft IP Location Privacy Problem 25 June 2006
Contents
Abstract i
1. Introduction 1
2. Problem Definition 2
2.1. Disclosing the Care of Address to the Correspondent Node 2
2.2. Revealing the Home Address to On-lookers . . . . . . . . 3
3. Problem Illustration 3
4. Conclusion 5
5. IANA Considerations 5
6. Security Considerations 5
7. Acknowledgment 6
8. Author's Address 6
A. Background 6
Intellectual Property Statement 7
Disclaimer of Validity 7
Copyright Statement 7
Acknowledgment 8
1. Introduction
The problems of location privacy, and privacy when using IP for
communication have become important. IP privacy is broadly concerned
with protecting user communication from unwittingly revealing
information that could be used to analyze and gather sensitive user
data. Examples include gathering data at certain vantage points,
collecting information related to specific traffic, and monitoring
(perhaps) certain populations of users for activity during specific
times of the day, etc. In this document, we refer to this as the
"profiling" problem.
Koodli Expires 25 December 2006 [Page 1]
Internet Draft IP Location Privacy Problem 25 June 2006
Location privacy is concerned with the problem of revealing roaming,
which we define here as the process of a Mobile Node moving from one
network to another with or without on-going sessions. A constant
identifier with global scope can reveal roaming. Such a global scope
identifier could be a device identifier or a user identifier. Often,
a binding between these two identifiers is also available, e.g.,
through DNS. The location privacy problem is particularly applicable
to Mobile IP where the Home Address on a visited network can reveal
device roaming and, together with a user identifier (such as a SIP
URI), can reveal user roaming. Even when the binding between a user
identifier and the Home Address is unavailable, freely available
tools on the Internet can map the Home Address to the owner of the
Home Prefix, which can reveal that a user from a particular ISP
has roamed. So, the location privacy problem is a subset of the
profiling problem in which revealing a globally visible identifier
compromises a user's location privacy. When location privacy is
compromised, it could lead to more targetted profiling.
Furthermore, a user may not wish to reveal roaming to
correspondent(s). In Mobile IP, this 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
visible identifier, such as a Home Address, when roaming are
described. Similarly, the concerns from revealing a Care of Address
to a correspondent are also outlined. The solutions to these
problems are meant to be specified in a separate document.
This document is only concerned with IP Address Location Privacy in
the presence of IP Mobility, as applied to Mobile IPv6. It does not
address the overall profiling problem. Specifically, it does not
concern itself with MAC addresses. Some other work may address the
problem of profiling IP and MAC identifiers (see for instance [1]).
2. Problem Definition
2.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 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).
Koodli Expires 25 December 2006 [Page 2]
Internet Draft IP Location Privacy Problem 25 June 2006
2.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 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
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. Problem Illustration
This section is intended to provide the overall scope under which the
above problems are applicable.
Consider a Mobile Node at its home network. Whenever it is involved
in IP communication, its correspondents can see an IP address valid
on the home network. Elaborating further, the users involved in peer
- peer communication are likely to see a user-friendly identifier
such as a SIP URI, and the communication end-points in the IP
stack will see IP addresses. Users uninterested in or unaware of
IP communication details will not see any difference when the MN
acquires a new IP address. Of course any user can ``tcpdump'' or
``ethereal'' a session, capture IP packets and map the MN's IP
address to an approximate geo-location. When this mapping reveals a
``home location'' of the user, the correspondent can conclude that
the user has not roamed. Assessing the physical location based on
IP addresses is similar to assessing the geographical location based
on the area-code of a telephone number. The granularity of the
physical area corresponding to an IP address can vary depending on
how sophisticated the available tools are, how often an ISP conducts
its network re-numbering, etc.
When the MN roams to another network, the location privacy problem
consists of two parts: revealing information to its correspondents
and to on-lookers.
With its correspondents, the MN can either communicate directly or
reverse tunnel its packets through the Home Agent. Using reverse
tunneling does not reveal the new IP address of the MN, although
end-to-end delay may vary depending on the particular scenario. The
Koodli Expires 25 December 2006 [Page 3]
Internet Draft IP Location Privacy Problem 25 June 2006
difference in delay may be noticeable enough to serve as a hint to
the correspondent, but such a hint cannot always be used to infer
that the MN has roamed. With those correspondents with which it can
disclose its new IP address ``on the wire'', the MN has the option
of using route-optimized communication. The transport protocol
still sees the Home Address with route optimization. Unless the
correspondent runs some packet capturing utility, the user cannot see
which mode (reverse tunneling or route optimization) is being used,
but knows that it is communicating with the same peer whose URI it
knows. This is similar to conversing with a roaming cellphone user
whose phone number, like the URI, remains unchanged.
Regardless of whether the MN uses route optimization or reverse
tunneling, its Home Address is revealed in data packets. When
equipped with an ability to inspect packets ``on the wire'', an
on-looker can determine that the MN has roamed and could possibly
also determine that the user has roamed. This could compromise
the location privacy even if the MN took steps to hide its roaming
information from a correspondent.
The above description is valid regardless of whether a Home Address
is static or is dynamically allocated. In either case, the mapping
of IP address to geo-location will most likely yield results with
the same level of granularity. With the freely available tools on
the Internet, this granularity is the physical address of the ISP or
the organization which registers ownership of a prefix chunk. Since
an ISP or an organization is not, rightly, required to provide a
blue-print of its subnets, the granularity remains fairly coarse for
a mobile wireless network. However, sophisticated attackers might
be able to conduct site mapping and obtain more fine-grained subnet
information.
A compromise in location privacy could lead to more targetted
profiling of user data. An eavesdropper may specifically track the
traffic containing the Home Address, and monitor the movement of the
Mobile Node with changing Care of Address. The profiling problem is
not specific to Mobile IPv6, but could be triggered by a compromise
in location privacy due to revealing the Home Address.
A correspondent may take advantage of the knowledge that a user
has roamed when Care of Address is revealed, and modulate actions
based on such a knowledge. Such an information could cause concern
to a mobile user especially when the correspondent turns out be
untrustworthy.
When roaming, a MN may treat its home network nodes as any other
correspondents. Reverse tunneling is perhaps sufficient for home
network communication, since route-optimized communication will
traverse the identical path. Hence, a MN can avoid revealing its
Care of Address to its home network correspondents simply by using
Koodli Expires 25 December 2006 [Page 4]
Internet Draft IP Location Privacy Problem 25 June 2006
reverse tunneling. The Proxy Neighbor Advertisements from the Home
Agent could serve as hints to the home network nodes that the Mobile
Node is away. However, they won't be able to know the Mobile Node's
current point of attachment unless the MN uses route optimization
with them.
Finally, it is also worthwhile to note that both the Home Address
and the Care of Address could be subject to profiling, just as
any other user traffic. However, applying existing techniques to
thwart profiling may have implications to Mobile IPv6 signaling
performance. For instance, changing the Care of Address often would
cause additional Return Routability and 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.
4. Conclusion
In this document, we have formulated the IP Location Privacy problem
in the presence of Mobile IPv6. The problem can be summarized as
follows: disclosing Care of Address to a correspondent and revealing
Home Address to an on-looker can compromise the location privacy of a
Mobile Node, and hence that of a user. Solutions to this problem are
expected to specifically address the use of Mobile IPv6 addresses,
and not other identifiers (such as MAC addresses).
The solutions to the location privacy problem described in this
document are expected to be protocol specifications assuming the
existing Mobile IPv6 functional entities, namely, the Mobile Node,
its Home Agent and the Correspondent Node.
5. IANA Considerations
There are no IANA considerations introduced by this draft.
6. Security Considerations
This document discusses location privacy because of IP mobility.
Solutions to provide location privacy, especially any signaling over
the Internet, must be secure in order to be effective. Individual
solutions must describe the security implications.
Koodli Expires 25 December 2006 [Page 5]
Internet Draft IP Location Privacy Problem 25 June 2006
7. Acknowledgment
Thanks to Jari Arkko, James Kempf, Qiu Ying and Sam Xia for the
review and feedback. Thanks to Kilian Weniger for the last call
review and for suggesting improvements.
References
[1] 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.
[2] 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.
8. Author's Address
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043 USA
Phone: +1 650 625 2359
Fax: +1 650 625 2502
E-Mail: Rajeev.Koodli@nokia.com
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 [2].
Koodli Expires 25 December 2006 [Page 6]
Internet Draft IP Location Privacy Problem 25 June 2006
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.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
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 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 Internet Society (2006). 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.
Koodli Expires 25 December 2006 [Page 7]
Internet Draft IP Location Privacy Problem 25 June 2006
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Koodli Expires 25 December 2006 [Page 8]
