Network Working Group K. Weniger Internet-Draft Panasonic Expires: May 7, 2007 November 3, 2006 MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing draft-weniger-mobopts-mip6-cnlocpriv-00 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 May 7, 2007. Copyright Notice Copyright (C) The IETF Trust (2006). Weniger Expires May 7, 2007 [Page 1] Internet-Draft CNLocPriv November 2006 Abstract This draft discusses the problem and proposes a solution for simultaneous optimized routing and correspondent node-targeted location privacy for Mobile IPv6. The solution utilizes the MIPv6 bootstrapping mechanisms for the split scenario and requires only changes to the mobile node operation. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 4. Changes to Mobile Node Operation . . . . . . . . . . . . . . . 7 4.1. Optimization of the route for a session that has not yet started . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Optimization of the route for an ongoing session . . . . . 8 5. Location-dependent Home Agent Discovery . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Weniger Expires May 7, 2007 [Page 2] Internet-Draft CNLocPriv November 2006 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. The terminology of [2] and [3] is used. Additionally, the following terms are introduced: IP Reachability Home Agent (IRHA): A home agent as specified in [2] that is used for providing IP reachability for the mobile node. The corresponding home addresses is disclosed to potential correspondent nodes (e.g., by publishing the address in DNS). IP Reachability path: The path between mobile node and correspondent node if the mobile node uses bi-directional tunneling mode with the IRHA. Optimal path: The end-to-end path between mobile node and correspondent node, e.g., the path in MIPv6 Route Optimization mode Optimized path: A path between mobile node and correspondent node that is shorter than the IP reachability path, but may be longer than the optimal path. Optimized routing: Routing data packets over the optimized path Optimized Routing Home Agent (ORHA): A home agent as specified in [2] that is used for providing optimized routing. Eavesdropper-targeted location privacy: Hiding the mobile node's location from nodes eavesdropping on the path between mobile node and correspondent node Correspondent node-targeted location privacy: Hiding the mobile node's location from the correspondent node Weniger Expires May 7, 2007 [Page 3] Internet-Draft CNLocPriv November 2006 2. Motivation Location privacy is the ability to hide a user's location from other users. This is considered to be an important feature, since disclosure of the location can have serious impacts on the user's life. In general, location privacy can be achieved by hiding the relation between identity and location of a user. In Mobile IPv6 [2], care-of address and home address represent topological location and identity of a mobile node, respectively. Consequently, at least either care-of address or home address must be hidden from anyone that is not authorized to obtain the location of the mobile node. Two rather orthogonal sub-problems of location privacy for Mobile IPv6 can be distinguished in this context: hiding the location from eavesdroppers on the path and hiding the location from the correspondent node, which we henceforth call eavesdropper-targeted and correspondent node-targeted location privacy, respectively (see [4] for details about the Mobile IPv6 location privacy problem). This document is concerned with correspondent node-targeted location privacy only, especially with the problem of providing optimized routing at the same time. Eavesdropper-targeted location privacy and any issues not directly related to Mobile IPv6 are out of the scope of this document. An example scenario illustrating the problem of simultaneous optimized routing and correspondent node-targeted location privacy is the following: A mobile node wants to hide its location and uses Mobile IPv6 with a public home address to be reachable. The mobile node requires strong location privacy, which means that hiding the mobility within an access network, but revealing the access network prefix is not acceptable. An application on the correspondent node initiates a delay-sensitive session such as VoIP by sending packets to the mobile node's public home address. The mobile node receives the packets in bi-directional tunneling mode from its home agent. Assuming the mobile node is far away from home, the packet delay and hence the user experience is quite bad. However, if the mobile node uses route optimization mode, it reveals its location to the correspondent node. Note that the correspondent node can also be an attacker that just initiates a session to find out the mobile node's location. Consequently, the mobile node has the choice: either it prefers good user experience without location privacy or location privacy with bad user experience. With current Mobile IPv6, there is no way to achieve both simultaneously. [7] proposes a solution to this problem. The basic idea is to hide the home address (i.e., the identity) from the correspondent node in route optimization mode by using a pseudo home address instead of the real home address. Although the care-of address is revealed to the correspondent node, location privacy is protected by hiding the Weniger Expires May 7, 2007 [Page 4] Internet-Draft CNLocPriv November 2006 identity (i.e., real home address) of the mobile node from the correspondent node. This approach has also been proposed in [6]. However, if the correspondent node initiates the communication this doesn't work, since the real home address is already known by the correspondent node. And even if the real home address is hidden from the correspondent node, location privacy is compromised if the correspondent node is able to figure out the mobile node's identity by any other means on higher layers (e.g., by the voice during a call). [3] and [5] specify the mechanisms for Mobile IPv6 bootstrapping in the split and the integrated scenario, respectively. The former allows a mobile node to bootstrap with any home agent, for which the necessary trust relationships are in place. When bootstrapping with a local home agent, optimized routing can be achieved in bi- directional tunneling mode. However, since the home address obtained from a local home agent belongs to the network the mobile node is currently visiting, it contains location information. Consequently, location privacy may be compromised, if the correspondent node knows that the home agent is local to the mobile node. ROTA [8] is a Mobile IPv6 enhancement that is able to provide simultaneous optimized routing and correspondent node-targeted location privacy. It focused on mobile-to-mobile communication scenarios and hence is able to provide a short route even when the correspondent node is mobile as well. However, it introduces new messages and requires changes to mobile node, home agent as well as correspondent node operation. We believe that Mobile IPv6 should support strong correspondent node- targeted location privacy and optimized routing simultaneously for both mobile node-initiated and correspondent node-initiated sessions. This document proposes a solution that requires only changes to the mobile node operation. Home agent and correspondent node are unchanged and no new messages are introduced. The basic idea is that the mobile node bootstraps with a home agent, henceforth called Optimized Routing Home Agent (ORHA), which is preferrably located topologically close to the correspondent node and which is soley used for optimized communication with this correspondent node. A location close to the correspondent node ensures that no location information is contained in the non-public home address obtained during the bootstrapping process. For mobile node-initiated sessions, the mobile node uses the ORHA in bi-directional tunneling mode and the non-public home address for communication with the correspondent node. For correspondent node-initiated sessions, the mobile node uses the public home address and registers at the correspondent node the non-public home address as care-of address. Weniger Expires May 7, 2007 [Page 5] Internet-Draft CNLocPriv November 2006 3. Applicability Statement To be able to apply this solution, mobile node and ORHA must support the bootstrapping mechanisms for the split scenario as described in [3]. To achieve good route optimization and location privacy properties, a home agent must be deployed topologically as close as possible to the domain where the correspondent node is located. Furthermore, the trust relationships required to bootstrap with this home agent as described in [3] must be in place. Finally, it is assumed that the mobile node implements a mechanism that allows the discovery of home agents located close to correspondent nodes (see Section 5). Weniger Expires May 7, 2007 [Page 6] Internet-Draft CNLocPriv November 2006 4. Changes to Mobile Node Operation The mobile node has to decide for every correspondent node, whether it wants to use bi-directional tunneling mode, route optimization mode or the solution described in this document. How this decision is made and how and when the route optimization is triggered is out of scope of this document. Generally, for non-delay-sensitive services such as simple web browsing, bi-directional tunneling to the home agent should be sufficient and achieves strong correspondent node-targeted location privacy. If no location privacy is required, route optimization mode can be used. The solution is split in two cases: optimization of the route for a communication session that has not yet started and optimization of the route for an ongoing session. A session is defined in this context by the IP addresses of the endpoints used by upper layers, with one of the addresses being a mobile node's home address. The first case applies, e.g., if the mobile nodes wants to initiate a session with a correspondent node and knows before sending the first data packets that optimized routing is needed. The second case applies, e.g., if the correspondent node initiates a session with the mobile node or if the mobile node decides to optimize the route of an ongoing session. 4.1. Optimization of the route for a session that has not yet started The mobile node first tries to discover a home agent, henceforth called Optimized Routing Home Agent (ORHA), which is located preferably topologically close to the correspondent node and close to the optimal path. The reasoning behind the ORHA location is that it can be argued that the closer the home agent is located to the correspondent node, the less location information is included in the home address, and that the closer the home agent is located to the optimal path, the better the route optimization property. For details about the discovery process refer to section Section 5. If the discovery is successful, the mobile node bootstraps with this home agent and uses it in bi-directional tunneling mode for communication with the correspondent node. Existing registrations with home agents are kept for communication with other correspondent nodes. The corresponding home address HoA_OR is not made public, i.e., no DNS update should be triggered for this home address. Since no correspondent node registration is initiated, the care-of address is hidden and correspondent node-targeted location privacy is ensured. The signaling is shown in Figure 1. Weniger Expires May 7, 2007 [Page 7] Internet-Draft CNLocPriv November 2006 +--+ +-------+ +--+ |MN| | ORHA | |CN| +--+ +-------+ +--+ | ORHA discovery | | |<----------------------------------------->| | | MIPv6 bootstrapping | | |<----------------------------------------->| | | BU (HoA_OR,CoA) | | |------------------------------------------>| | | data packets | data packets | |<=========================================>|<------------------->| Figure 1: Signaling flow for optimization of the route for a session that has not yet started 4.2. Optimization of the route for an ongoing session After the mobile node has decided to optimize the route of a session (e.g., after receiving the first data packets tunneled by the IRHA and originated from the correspondent node), it discovers and bootstraps with an ORHA, i.e., with a home agent located preferably close to the correspondent node. Since the session is based on HoA_IR, packets are routed through the IRHA. To achieve optimized routing, the mobile node uses route optimization mode over the reverse tunnel to the ORHA, i.e., care-of test messages, binding update messages, and later data packets destined for the correspondent node are sent over the reverse tunnel to the ORHA. While establishing the optimized path over the ORHA, the mobile node can send and receive data packets over the IRHA. To achieve location privacy, the mobile node uses the IR home address HoA_IR as home address and the OR home address HoA_OR as care-of address in the context of the route optimization mode. This results in the following headers for packets sent by the mobile node for the session with the correspondent node (IPsec for signaling protection to ORHA assumed): Data packets and binding updates: IPv6 header (source = care-of address, destination = ORHA) ESP header in tunnel mode IPv6 header (source = HoA_OR, destination = correspondent node) Destination Options header Home Address option (HoA_IR) Weniger Expires May 7, 2007 [Page 8] Internet-Draft CNLocPriv November 2006 Any protocol Care-of Test Init: IPv6 header (source = care-of address, destination = ORHA) ESP header in tunnel mode IPv6 header (source = HoA_OR, destination = correspondent node) Any protocol Since from the correspondent node's point of view, the OR home address is the care-of address and the IR home address is the home address of the mobile node, data packets sent by the correspondent node contain the IR home address in the routing header and the OR home address in the destination address field of the IP header. Consequently, the data packets are intercepted by the ORHA and tunneled to the mobile node. The signaling is shown in Figure 2. Weniger Expires May 7, 2007 [Page 9] Internet-Draft CNLocPriv November 2006 +--+ +-------+ +-------+ +--+ |MN| | IRHA | | ORHA | |CN| +--+ +-------+ +-------+ +--+ | BU (HoA_IR,CoA) | | | |-------------------->| | | ~ ~ ~ ~ | data packets | data packets | |<===================>|<----------------------------------------->| | ORHA discovery | | |<----------------------------------------->| | | MIPv6 bootstrapping | | |<----------------------------------------->| | | BU (HoA_OR,CoA) | | |------------------------------------------>| | | HoTi | HoTi | |====================>|------------------------------------------>| | CoTi | CoTi | |==========================================>|-------------------->| | HoT | HoT | |<====================|<------------------------------------------| | CoT | CoT | |<==========================================|<--------------------| | BU (HoA_IR,HoA_OR) | BU (HoA_IR,HoA_OR) |==========================================>|-------------------->| | data packets | data packets | |<=========================================>|<------------------->| Figure 2: Signaling flow for optimization of the route for an ongoing session Note that upon changing the care-of address, the mobile node does not send binding updates to the correspondent node over the reverse tunnel to the ORHA, because the care-of address in this context is the ORHA home address. Weniger Expires May 7, 2007 [Page 10] Internet-Draft CNLocPriv November 2006 5. Location-dependent Home Agent Discovery This solution requires the discovery of the ORHA address. This location-dependent home agent discovery problem is currently out of scope of this document. One option could be to that the mobile node uses anycast-based or DNS-based home agent discovery [3] based on the correspondent node's address, prefix or host name (e.g., similar to locating SIP servers [9]). Another option could be to introduce a dedicated server in the mobility service provider's or access network provider's network that is able to map an FQDN or address of a correspondent node to an FQDN or address of a trusted home agent that is located topologically close to the correspondent node. The mobile node would then query this server to discover the ORHA address. Weniger Expires May 7, 2007 [Page 11] Internet-Draft CNLocPriv November 2006 6. Security Considerations An attacker could initiate many fake communication sessions by spoofing the source address, which could trigger the mobile node to discover and bootstrap with many home agents. This could consume significant resources on the mobile node and in the network and may cause a DoS. As a countermeasure, the mobile node should not start bootstrapping automatically or it should limit the number of ORHAs it is registered with. The return routability procedure over the reverse tunnel to the ORHA is not considered less secure than the standard return routability procedure as long as the ORHA is trusted and the ORHA link is not vulnerable to eavesdropping. Weniger Expires May 7, 2007 [Page 12] Internet-Draft CNLocPriv November 2006 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-03 (work in progress), October 2006. [4] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", draft-ietf-mip6-location-privacy-ps-04 (work in progress), October 2006. 7.2. Informative References [5] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in progress), June 2006. [6] Dupont, F., "A Simple Privacy Extension for Mobile IPv6", draft-dupont-mip6-privacyext-04 (work in progress), July 2006. [7] Qiu, Y., "Mobile IPv6 Location Privacy Solutions", draft-irtf-mobopts-location-privacy-solutions-03 (work in progress), October 2006. [8] Weniger, K. and T. Aramaki, "Route Optimization and Location Privacy using Tunneling Agents (ROTA)", draft-weniger-rota-01 (work in progress), October 2005. [9] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Weniger Expires May 7, 2007 [Page 13] Internet-Draft CNLocPriv November 2006 Author's Address Kilian A. Weniger Panasonic R&D Center Germany Monzastr. 4c Langen 63225 Germany Phone: +49 6103 766 137 Email: kilian.weniger@eu.panasonic.com Weniger Expires May 7, 2007 [Page 14] Internet-Draft CNLocPriv November 2006 Full Copyright Statement Copyright (C) The IETF Trust (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. 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). Weniger Expires May 7, 2007 [Page 15]