Mobile IPv6 Working Group Rajeev Koodli INTERNET DRAFT Nokia Research Center 14 February 2005 IP Address Location Privacy and IP Mobility draft-koodli-mip6-location-privacy-00.txt This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 IP Mobility. We discuss two problems: disclosing a new IP address to a correspondent, and revealing a fixed identity to an eavesdropper. We document some of the previous discussion on possible solutions. Koodli Expires 14 August 2005 [Page i] Internet Draft IP Location Privacy 14 February 2005 Contents Abstract i 1. Introduction and Problem Description 1 2. Disclosing the Care of Address 2 3. Revealing the Home Address 3 4. Conclusion 4 5. IANA Considerations 4 6. Security Considerations 4 Intellectual Property Statement 5 Disclaimer of Validity 5 Copyright Statement 6 Acknowledgment 6 1. Introduction and Problem Description Location Privacy with IP communication is interesting, especially with IP mobility. Although there has been some discussion, and even very rough consensus of certain topics, little has been documented. In [2], the terminology and problem description involving IP address and Layer 2 identifier tracing is presented. And, in [1], there is a solution proposal (which pre-dates the current Route Optimization technique for Mobile IPv6) for protecting the Home Address from being revealed to an on-looker. The purpose here is to document the scope of IP Address Location Privacy in the presence of Mobile IPv6. We briefly review some of the available solutions and identify the specific problems that need attention. 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 Koodli Expires 14 August 2005 [Page 1] Internet Draft IP Location Privacy 14 February 2005 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 [4]. 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. For the purposes of this document, we restrict ourselves to IP addresses and IP mobility. There are two problems in this space: Disclosing a new IP address to a correspondent, and revealing a fixed IP address to an eavesdropper. So, a MN may wish to use a fixed Home Address with a correspondent but may not wish to disclose its new Care-of Address, whereas it may not wish to reveal its fixed identity (Home Address) to an on-looker, but has to use the CoA from its visited network. We discuss each separately. 2. Disclosing the Care of Address 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 on this, 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 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 be large, especially for a mobile wireless network. Now consider that the MN roams to a new IP network, acquires a Care of Address and would like to communicate with its correspondents. It 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 performance may vary depending on the Koodli Expires 14 August 2005 [Page 2] Internet Draft IP Location Privacy 14 February 2005 particular scenario. In some instances, the performance difference could be noticeable enough to serve as a hint to the user. In any event, a MN should use reverse tunneling with those correspondents with which it does not wish to reveal that it has a new IP address outside of its home network. 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. The above-mentioned observation is valid regardless of whether a Home Address is fixed or 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, especially with a mobile wireless network. If disclosing a new IP address is acceptable, a protocol such as Hierarchical Mobile IPv6 can hide further changes to IP addresses within an administrative area. In other words, frequency of roaming can be hidden but not roaming itself. Even if a temporary Home Address from the visited network can be assigned to a roaming MN, the user identifier (such as a URI) still remains constant and thus enables detection of roaming. Using changeable URIs would be interesting, but presumably that belongs to a different problem of anonymity. 3. Revealing the Home Address When a MN does decide to use route optimization with a particular correspondent, it is faced with the problem of revealing its Home Address to an eavesdropper, who can determine that the user has roamed as well as profile the user's packets. RFC 3041 [3] identifies the profiling problem associated with using a constant Interface Identifier in IP addresses and recommends guidelines to regularly change the IID. This could work fine for Care od Addresses in Mobile IPv6, although it can increase the frequency of Mobile IPv6 signaling depending on the frequency of changing the IID. When routers advertise multiple prefixes, it may also be useful for a MN to switch to different prefixes for additional protection against profiling. Koodli Expires 14 August 2005 [Page 3] Internet Draft IP Location Privacy 14 February 2005 Applying RFC 3041 to Home Addresses involves further consideration. Since a Home Address can be entered in the DNS, changing it often means updating the DNS often as well. So, a Home Agent may be required to initiate DNS updates upon every change of Home Address for each MN. Changing the Home Address often also means re-negotiating the IPsec security association between each MN and the Home Agent often. Even if these operational overheads were considered acceptable, presence of a constant name that maps to a reachable IP address in the DNS can undermine the utility served by RFC 3041. For these reasons, frequently changing the Home Address is not desirable. This motivates investigation of alternative techniques to disrupt Home Address profiling. 4. Conclusion In this document, we have formulated the IP Location Privacy problem due to IP Mobility. We have alluded to often-talked-about solutions. Perhaps more importantly, we conclude that there is a need for a document that describes the already available solutions, and investigates further solutions for Home Address profiling. The Location Privacy problem with IP communication itself needs broader discussion. Documents such as [2] are good sources for such a discussion. 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. References [1] C. Castelluccia and F. Dupont. A Simple Privacy Exension for Mobile IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, February 2001. [2] 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. Koodli Expires 14 August 2005 [Page 4] Internet Draft IP Location Privacy 14 February 2005 [3] T. Narten and R. Draves. Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Request for Comments 3041, Internet Engineering Task Force, January 2001. [4] 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. 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. Koodli Expires 14 August 2005 [Page 5] Internet Draft IP Location Privacy 14 February 2005 Copyright Statement Copyright (C) The Internet Society (2004). 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. Koodli Expires 14 August 2005 [Page 6]