MIP6 Working Group Rajeev Koodli INTERNET DRAFT Nokia Research Center Informational
23 October 20062 February 2007 IP Address Location Privacy and Mobile IPv6: Problem Statement draft-ietf-mip6-location-privacy-ps-04.txtdraft-ietf-mip6-location-privacy-ps-05.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, email@example.com. 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 2 2.1.4 3.1. Disclosing the Care ofCare-of Address to the Correspondent Node 2 2.2.4 3.2. Revealing the Home Address to On-lookers . . . . . . . . 3 2.3.4 3.3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . 3 3.4 4. Problem Illustration 3 4. Conclusion5 5. Conclusion 8 6. IANA Considerations 6 6.8 7. Security Considerations 6 7. Acknowledgment 68 8. Acknowledgment 9 9. References 9 9.1. Normative References . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . 9 10. Author's Address 610 A. Background 711 Intellectual Property Statement 712 Disclaimer of Validity 812 Copyright Statement 813 Acknowledgment 813 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. Such a global scope identifier could beExamples are a device identifier orsuch as an IP address, and a user identifier.identifier such as a SIP  URI . Often, a binding between these two identifiers is alsoavailable, e.g., through DNS. The location privacy problem is particularly applicable to MobileDNS . Traffic analysis of such IP where the Home Addressand Upper Layer Protocol identifiers on a visitedsingle network can revealindicate device roaming and, together with a user identifier (such as a SIP URI), can revealand 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 ownerRoaming could also be inferred by means of profiling constant fields in IP communication across multiple network movements. For example, an Interface Identifier (IID) [10 ] in the Home Prefix, which can revealIPv6 address that a user from a particular ISP has roamed. So,remains unchanged across networks could suggest roaming. The SPI in the location privacy problemIPsec  header is a subset of theanother field that may be subject to such profiling problemand inference. Inferring roaming in which revealing a globally visible identifier compromises a user's location privacy.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.profiling of user communication. As can be seen, the location privacy problem spans multiple protocol layers. Nevertheless, it is important to understand and specify the problem as applicable to concerned protocols in order 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). In Mobile IP, thiscorrespondent(s), which translates to the use of Care ofCare-of Address. As with Home Address, the Care ofCare-of Address can also reveal the topological location of the Mobile Node. In this document,This document describes the concerns arising from the use of Home Address from a globally visible identifier, such asvisited network. This document also outlines the considerations in disclosing a Home Address, whenCare-of Address. This document is primarily concerned with the vulnerabilities arising from 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 are described. Similarly,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 concerns from revealing a Careusage of Home Address tofrom a correspondent are also outlined. The solutions to these problems are meantsingle visited network in order to be specifieddeduce roaming. In other words, the attackers need not conduct traffic profiling across multiple networks, or collude with each other, or do both in a separate document.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 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 ., 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  and the associated terminology defined therein. For convenience, we provide some definitions below. 2. Definitions - Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams around networks - Correspondent Node (CN): A Mobile IPv6 that node corresponds with a MN - Home Network: The network where the MN is normally present when it is not roaming - 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 - Home Address (HoA): The MN's unicast IP address valid on its home network - Care-of Address (CoA): The MN's unicast IP address valid on the visited network - 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 126.96.36.199. Disclosing the Care ofCare-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 ofCare-of Address in communication with a correspondent reveals that the MN has roamed. This assumes that the correspondent is able to associate the CoACare-of Address to HoA,Home Address, for instance by inspecting the Binding Cache Entry. The HoAHome Address itself is assumed to have been obtained by whatever means (e.g., through DNS lookup). 188.8.131.52. 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)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 ofCare-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). 184.108.40.206. 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 HoAHome 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 CoA.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 HoA. 3.Home Address. 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"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 the new IP addressCare-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 new IP addressCare-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 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 ofCare-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 ofCare-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 management interfaces on the MN to guard against the 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 ofCare-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. Solutions should be careful in considering the cost of change of either CoA or HoA on signaling. For instance, changing the Care ofCare-of Address often would cause additional Return Routability and binding management signaling. And, changing theor Home Address often has implicationson IPsec security association management. These issues need to be addressed in the solutions These issues should be addressed in the solutions.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 ofCare-of Address to its home network correspondents simply by using 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'twill not be able to know the Mobile Node's current point of attachment unless the MN uses route optimization with them. 4.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 ofCare-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 CoACare-of Address to the CN. And, ESP encryption of inner IP packet allows the MN to protect its HoA from the on-lookers on theprotect 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 - HA path. However,concerned with route optimization, the MN will reveal its CoAlocation privacy should exercise prudence in determining whether to the CN. Moreover,use route optimization causes the HoA to be revealed to on-lookers in the data packets as well as in Mobile IPv6 signaling messages.with, especially previously unacquainted, correspondents. The solutions to this problem are expected to be protocol specifications assumingshould also consider the existinguse of temporary addresses and their implications on 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 becausesignaling as discussed in Section 4. Use of IP mobility. Solutions to provide location privacy,addresses with privacy extensions  could be especially anyuseful for Care-of Addresses if appropriate tradeoffs with Return Routability signaling over the Internet, must be secure in order to be effective. Individual solutions must describe the security implications. 7.are taken into account. 8. Acknowledgment Thanks to James Kempf, Qiu Ying andYing, Sam Xia and Lakshminath Dondeti for the review and feedback. Thanks to Jari Arkko and Kilian Weniger for the last call review and for suggesting improvements and text. Informative9. References 9.1. Normative References  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  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.  W. Haddad and et al.al., Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement (work in progress). Internet Draft, Internet Engineering Task Force, October 2004.  S. Kent and K. Seo. Security Architecture for the Internet Protocol. Request for Comments (Proposed Standard) 4301, Internet Engineering Task Force, December 2005.  P. V. Mockapetris. Domain names - implementation and specification. Request for Comments (Standard) 1035, Internet Engineering Task Force, November 1987.  T. Narten and R. Draves. Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Request for Comments 3041, Internet Engineering Task Force, January 2001.  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.  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. J. Rosenberg and et al. SIP: Session Initiation Protocol. Request for Comments (Proposed Standard) 3261, Internet Engineering Task Force, June 2002.  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 Nokia Research Center 313 Fairchild Drive Mountain View,975 Page Mill Road, 200 Palo Alto, CA 9404394034 USA Phone: +1 650 625 2359408 425 6684 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 .. 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 firstname.lastname@example.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 SOCIETYSOCIETY, 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 Internet Society (2006).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 Funding for the RFC Editor function is currently provided by the Internet Society.