[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4882

MIP6 Working Group                                        Rajeev Koodli
Internet-Draft                                     Nokia Research Center
Intended status: Informational                         February 19, 2007
Expires: August 23, 2007


     IP Address Location Privacy and Mobile IPv6: Problem Statement
                  draft-ietf-mip6-location-privacy-06.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 23, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   In this document, we discuss Location Privacy as applicable to Mobile
   IPv6.  We document the concerns arising from revealing Home Address
   to an on-looker and from disclosing Care of Address to a
   correspondent.







Koodli                   Expires August 23, 2007                [Page 1]

Internet-Draft            MIP6 Location Privacy            February 2007


Table of Contents

   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































Koodli                   Expires August 23, 2007                [Page 2]

Internet-Draft            MIP6 Location Privacy            February 2007


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.

   Location privacy is concerned with the problem of revealing roaming,
   which we define here as the process of a Mobile Node (MN) moving from
   one network to another with or without on-going sessions.  A constant
   identifier with global scope can reveal roaming.  Examples are a
   device identifier such as an IP address, and a user identifier such
   as a SIP [rfc3261] URI[rfc2396].  Often, a binding between these two
   identifiers is available, e.g., through DNS [rfc1035].  Traffic
   analysis of such IP and Upper Layer Protocol identifiers on single
   network can indicate device and user roaming.  Roaming could also be
   inferred by means of profiling constant fields in IP communication
   across multiple network movements.  For example, an Interface
   Identifier (IID) [rfc2462] in the IPv6 address that remains unchanged
   across networks could suggest roaming.  The SPI in the IPsec
   [rfc4301] header is another field that may be subject to such
   profiling and inference.  Inferring roaming in this way typically
   requires traffic analysis across multiple networks, or colluding
   attackers, or both.  When location privacy is compromised, it could
   lead to more targetted profiling of user communication.

   As can be seen, the location privacy problem spans multiple protocol
   layers.  Nevertheless, we can examine problems encountered by nodes
   using a particular protocol layer.  Roaming is particularly important
   to Mobile IP, which defines a global identifier (Home Address) that
   can reveal device roaming, and in conjunction with a corresponding
   user identifier (such as a SIP URI), can also reveal user roaming.
   Furthermore, a user may not wish to reveal roaming to
   correspondent(s), which translates to the use of Care-of Address.  As
   with Home Address, the Care-of Address can also reveal the
   topological location of the Mobile Node.

   This document scopes the problem of location privacy for the Mobile
   IP protocol.  The primary goal is to prevent attackers on the path
   between the Mobile Node (MN) and the Correspondent Node (CN) from
   detecting roaming due to the disclosure of the Home Address.  The
   attackers are assumed to be able to observe, modify and inject
   traffic at one point between the MN and the CN.  The attackers are



Koodli                   Expires August 23, 2007                [Page 3]

Internet-Draft            MIP6 Location Privacy            February 2007


   assumed not to be able to observe at multiple points and correlate
   observations to detect roaming.  For this reason, MAC addresses, IIDs
   and other fields which can be profiled to detect roaming are only in
   scope to the extent that they can be used by an attacker at one
   point.  Upper layer protocol identifiers that expose roaming are out
   of scope except that a solution to the problem described here needs
   to be usable as a building block in solutions to those problems.

   This document also considers the problem from the exposure of Care-of
   Address to the CN.

   This document is only concerned with IP Address Location Privacy in
   the context of Mobile IPv6.  It does not address the overall privacy
   problem.  For instance, it does not address privacy issues related to
   MAC addresses or the relationship of IP and MAC addresses
   [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
   operation of Mobile IPv6 [rfc3775] and the associated terminology
   defined therein.  For convenience, we provide some definitions below.


2.  Definitions

   o  Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams
      around networks
   o  Correspondent Node (CN): A Mobile IPv6 that node corresponds with
      a MN
   o  Home Network: The network where the MN is normally present when it
      is not roaming
   o  Visited Network: A network which a MN uses to access Internet when
      it is roaming
   o  Home Agent: A router on the MN's home network which provides
      forwarding support when the MN is roaming
   o  Home Address (HoA): The MN's unicast IP address valid on its home
      network
   o  Care-of Address (CoA): The MN's unicast IP address valid on the
      visited network
   o  Reverse Tunneling or Bidirectional Tunneling: A mechanism used 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
      traverse the home network.






Koodli                   Expires August 23, 2007                [Page 4]

Internet-Draft            MIP6 Location Privacy            February 2007


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 can be compromised
   when an on-looker is present on the MN - CN path (when route
   optimization is used).  It may also be compromised when the on-looker
   is present on the MN - HA path (when bidirectional tunneling without
   encryption is used.  See below).

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), the
   correspondent does not have access to the Care-of Address.  Hence, it
   cannot determine that the MN has roamed.

   Hence, the location privacy problem is particularly applicable when
   Mobile IPv6 route optimization is used or when reverse tunneling is
   used without protecting the inner IP packet containing the Home
   Address.





Koodli                   Expires August 23, 2007                [Page 5]

Internet-Draft            MIP6 Location Privacy            February 2007


4.  Problem Illustration

   This section is intended to provide an illustration of the problem
   defined in the previous section.

   Consider a Mobile Node at its home network.  Whenever it is involved
   in IP communication, its correspondents can see an IP address valid
   on the home network.  Elaborating further, the users involved in peer
   - 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.  This mapping may reveal the
   home location of a user, but a correspondent cannot ascertain whether
   the user has actually roamed or not.  Assessing the physical location
   based on IP addresses has some similarities to assessing the
   geographical location based on the area-code of a telephone number.
   The granularity of the physical area corresponding to an IP address
   can vary depending on how sophisticated the available tools are, how
   often an ISP conducts its network re-numbering, etc.  And, 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
   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 Care-of Address of the MN, although end-to-
   end delay may vary depending on the particular scenario.  With those
   correspondents with which it can disclose its Care-of Address ``on
   the wire'', the MN has the option of using route-optimized
   communication.  The transport protocol still sees the Home Address
   with route optimization.  Unless the correspondent runs some packet
   capturing utility, the user cannot see which mode (reverse tunneling
   or route optimization) is being used, but knows that it is
   communicating with the same peer whose URI it knows.  This is similar
   to conversing with a roaming cellphone user whose phone number, like
   the URI, remains unchanged.

   Regardless of whether the MN uses route optimization or reverse
   tunneling (without ESP encryption), its Home Address is revealed in
   data packets.  When equipped with an ability to inspect packets ``on
   the wire'', an on-looker on the MN - HA path can determine that the
   MN has roamed and could possibly also determine that the user has



Koodli                   Expires August 23, 2007                [Page 6]

Internet-Draft            MIP6 Location Privacy            February 2007


   roamed.  This could compromise the location privacy even if the MN
   took steps to hide its roaming information from a correspondent.

   The above description is valid regardless of whether a Home Address
   is statically allocated or is dynamically allocated.  In either case,
   the mapping of IP address to 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.  For these reasons, appropriate security measures on
   the management interfaces on the MN to guard against the disclosure
   or misuse of location information should be considered.

   Applying existing techniques to thwart profiling may have
   implications to Mobile IPv6 signaling performance.  For instance,
   changing the Care-of Address often would cause additional Return
   Routability [rfc3775] and binding management signaling.  And,
   changing the Home Address often has implications on IPsec security
   association management.  Solutions should be careful in considering
   the cost of change of either Care-of Address or Home Address on
   signaling.

   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
   reverse tunneling.  The Proxy Neighbor Advertisements [rfc2461] from
   the Home Agent could serve as hints to the home network nodes that
   the Mobile Node is away.  However, they will not be able to know the
   Mobile Node's current point of attachment unless the MN uses route
   optimization with them.



Koodli                   Expires August 23, 2007                [Page 7]

Internet-Draft            MIP6 Location Privacy            February 2007


5.  Conclusion

   In this document, we have discussed the location privacy problem as
   applicable to 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.  We have seen that
   bidirectional tunneling allows a MN to protect its Care-of Address to
   the CN.  And, ESP encryption of inner IP packet allows 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 Care-of
   Address to the CN.  Moreover, route optimization causes the Home
   Address to be revealed to on-lookers in the data packets as well as
   in Mobile IPv6 signaling messages.  The solutions to this problem are
   expected to be protocol specifications assuming the existing Mobile
   IPv6 functional entities, namely, the Mobile Node, its Home Agent and
   the Correspondent Node.


6.  IANA Considerations

   There are no IANA considerations introduced by this draft.


7.  Security Considerations

   This document discusses the location privacy problem specific to
   Mobile IPv6.  Any solution must be able to protect (e.g., using
   encryption) the Home Address from disclosure to on-lookers in data
   packets when using route optimization or reverse tunneling.  In
   addition, solutions must consider protecting the Mobile IPv6
   signaling messages from disclosing the Home Address along the MN - HA
   and MN - CN paths.

   Disclosing the Care-of Address is inevitable if 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.

   The solutions should also consider the use of temporary addresses and
   their implications on Mobile IPv6 signaling as discussed in Problem
   Illustration.  Use of IP addresses with privacy extensions [rfc3041]
   could be especially useful for Care-of Addresses if appropriate
   tradeoffs with Return Routability signaling are taken into account.



Koodli                   Expires August 23, 2007                [Page 8]

Internet-Draft            MIP6 Location Privacy            February 2007


8.  Acknowledgment

   James Kempf, Qiu Ying, Sam Xia and Lakshminath Dondeti are
   acknowledged for their review and feedback.  Thanks to Jari Arkko and
   Kilian Weniger for the last call review and for suggesting
   improvements and text.  Thanks to Sam Hartman for providing text to
   improve the problem scope.


9.  References

9.1.  Normative References

   [rfc3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004,
              <ftp://ftp.isi.edu/in-notes/rfc3775>.

9.2.  Informative References

   [draft-haddad]
              Haddad, W. et al., "Privacy for Mobile and Multi-homed
              Nodes:   MoMiPriv Problem Statement (work in progress)",
              October 2004.

   [rfc1035]  Mockapetris, P., "Domain names - implementation and
              specification", RFC 1035, November 1987,
              <ftp://ftp.isi.edu/in-notes/rfc1035>.

   [rfc2396]  Berners-Lee, T., Fielding, R., and L. Manister, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998, <ftp://ftp.isi.edu/in-notes/rfc2396>.

   [rfc2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998, <ftp://ftp.isi.edu/in-notes/rfc2461>.

   [rfc2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998,
              <ftp://ftp.isi.edu/in-notes/rfc2462>.

   [rfc3041]  Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001, <ftp://ftp.isi.edu/in-notes/rfc3041>.

   [rfc3261]  Rosenberg, J. et al., "SIP: Session Initiation
              Protocol", RFC 3261, July 2004,
              <ftp://ftp.isi.edu/in-notes/rfc3261>.




Koodli                   Expires August 23, 2007                [Page 9]

Internet-Draft            MIP6 Location Privacy            February 2007


   [rfc3825]  Polk, J. and J. Schnizlein, "DHCP Option for Coordinate-
              based Location Configuration Information", RFC 3825,
              July 2004, <ftp://ftp.isi.edu/in-notes/rfc3825>.

   [rfc4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005,
              <ftp://ftp.isi.edu/in-notes/rfc4301>.


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
   Nokia Research Center
   975 Page Mill Road, 200
   Palo Alto, CA  94304
   USA

   Email: rajeev.koodli@nokia.com






Koodli                   Expires August 23, 2007               [Page 10]

Internet-Draft            MIP6 Location Privacy            February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Koodli                   Expires August 23, 2007               [Page 11]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/