Network Working Group K. Weniger Internet-Draft Panasonic Expires: August 31, 2007 February 27, 2007 MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing draft-weniger-mobopts-mip6-cnlocpriv-01 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 31, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Weniger Expires August 31, 2007 [Page 1] Internet-Draft CNLocPriv February 2007 Abstract This draft discusses the problem of simultaneous optimized routing and correspondent node-targeted location privacy for Mobile IPv6 and proposes a solution. The solution utilizes the MIPv6 bootstrapping mechanisms and requires no new network entities and no changes to home agent or correspondent node. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Assumptions and 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 August 31, 2007 [Page 2] Internet-Draft CNLocPriv February 2007 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 provides IP reachability and global session continuity for the mobile node. Home Address for IP Reachability (HoA_IR): A home address used for IP reachability and session continuity and that is registered at the IRHA. This home addresses is disclosed to potential correspondent nodes (e.g., by publishing the address in DNS). 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. The IP Reachability path is the path between mobile node and correspondent node if the mobile node uses bi-directional tunneling mode with the IRHA. The optimal path is the end-to-end path between mobile node and correspondent node, e.g., the path in MIPv6 Route Optimization mode. 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. It must support the bootstrapping mechanisms specified in [3]. Home Address for Optimized Routing (HoA_OR): A home address used for optimized routing and session continuity and that is registered at the ORHA. This home address is usually not public (i.e., not published in DNS). Eavesdropper-targeted location privacy: Hiding the mobile node's location from nodes eavesdropping on the path between mobile node and correspondent node (and home agent) Correspondent node-targeted location privacy: Hiding the mobile node's location from the correspondent node Weniger Expires August 31, 2007 [Page 3] Internet-Draft CNLocPriv February 2007 2. Introduction 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], the care-of address and the home address represent the topological location and identity of a mobile node, respectively. Consequently, at least either the care-of address or the 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: 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 location privacy issue 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, i.e., hiding only the mobility within an access network and revealing the access network prefix to the correspondent node 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. The mobile node and the correspondent node are located in the United States, whereas the mobile node's home agent is located in Europe. Since the mobile node is far away from home, the packet delay and hence the user experience is far from what could be achieved. 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: it can have good user experience without location privacy or location privacy with bad user experience. Currently, there is no way to achieve both simultaneously with Mobile IPv6. We believe that this is not acceptable and 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. Weniger Expires August 31, 2007 [Page 4] Internet-Draft CNLocPriv February 2007 Qui et. al. [9] propose a solution to this problem. The basic idea is to hide the home address 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 identity (i.e., real home address) of the mobile node from the correspondent node. This approach has also been proposed in [8]. However, if the correspondent node initiates the communication, location privacy is usually compromised, 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 [6] 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 is compromised, if the correspondent node knows that the home agent is local to the mobile node. This document proposes a solution to provide strong correspondent node-targeted location privacy and optimized routing simultaneously, which requires only changes to the mobile node operation. Home agent and correspondent node are unchanged and no new entities or messages are introduced. The basic idea is that the mobile node uses a mobility service provided close to the correspondent node's domain. More specifically, the mobile node bootstraps with a home agent (the ORHA), which is located topologically close to the correspondent node and which is used for optimized communication with this correspondent node. A location close to the correspondent node ensures that no location information is contained in the home address HoA_OR anchored at the ORHA. For mobile node-initiated sessions, the mobile node uses the ORHA in bi-directional tunneling mode and HoA_OR on higher layers. For correspondent node-initiated sessions, the public home address HoA_IR is used on higher layers and the mobile node registers at the correspondent node HoA_OR as care-of address. Weniger Expires August 31, 2007 [Page 5] Internet-Draft CNLocPriv February 2007 3. Assumptions and Applicability Statement The mechanisms defined in this document require that the mobile node is able to utilize a mobility service, which is offered close to the correspondent node's domain. To allow optimized communication with any correspondent node, it is required that home agent services are offered to the mobile node from various topological locations. This typically requires that a mobility service provider (MSP) offers mobility service from many different locations or that multiple MSPs have some kind of roaming relationships with the mobile node's mobility service authorizer (MSA), so that a group of MSPs offers mobility service from many different locations. Such roaming relationships can be based on an AAA infrastructure and are not particular to this document: the MIPv6 bootstrapping solutions for the split scenario [3] and the integrated scenario [6] also require that a roaming relationship between MSP and MSA exist (see also [5]). For instance, in the integrated scenario, the access service authorizer (ASA) is also the mobility service authorizer (MSA). An important point of the integrated scenario is that the access service provider (ASP) the mobile node is currently visiting is typically also an MSP (i.e., provides local home agent service). This means that roaming relationships between many MSPs and the mobile node's MSA are required and that home agent services are offered to the mobile node from various topological locations, which represent the requirements mentioned in the beginning of this section. In conclusion, it is expected that the home agents, roaming relationships, and the credentials needed for [6] can be re-used by the mechanisms defined in this document. It is further assumed that a mechanism for discovery of home agents located close to correspondent nodes is available (see Section 5). However, it is not required that the home agent (ORHA) is located in the correspondent node's domain. A domain nearby to the correspondent node's domain is sufficient to achieve location privacy and improved routing efficiency. Since the ORHA learns the location of the mobile node, the mobile node must be sure that the ORHA doesn't reveal the mobile node's location to nodes not authorized to get the location, i.e., the ORHA must be trusted by the mobile node. It is assumed that the ORHA discovery mechanism only returns trusted home agents or that the mobile node is able to verify whether the ORHA is trusted. Note that even if the ORHA and the correspondent node are in the same domain, this doesn't imply that the ORHA reveals the mobile node's location to the correspondent node. This is also true in today's networks, where it is ensured that users of a service provided by a particular operator don't know the location of other users using a service provided by the same operator. Weniger Expires August 31, 2007 [Page 6] Internet-Draft CNLocPriv February 2007 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, Mobile IPv6 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 an 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 ORHA is located to the correspondent node, the less location information is included in the HoA_OR, and that the closer the ORHA is located to the optimal path, the better the route optimization property. The ORHA must be trusted and must be operated by an MSP that has a roaming relationship to the MN's MSA. For details about the discovery process refer to section Section 5. If the discovery is successful, the mobile node bootstraps with the ORHA and uses it in bi-directional tunneling mode for communication with the correspondent node. Existing registrations with other home agents are kept for communication with other correspondent nodes. The 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 August 31, 2007 [Page 7] Internet-Draft CNLocPriv February 2007 +--+ +-------+ +--+ |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 Location privacy is provided, since the correspondent node only learns HoA_OR, which has no relation to the mobile node's location. 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. Since the communication 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 HoA_IR as home address and 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 Weniger Expires August 31, 2007 [Page 8] Internet-Draft CNLocPriv February 2007 Home Address option (HoA_IR) 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, HoA_OR is the care-of address and the HoA_IR is the home address of the mobile node, data packets sent by the correspondent node contain the HoA_IR in the routing header and the HoA_OR 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 August 31, 2007 [Page 9] Internet-Draft CNLocPriv February 2007 +--+ +-------+ +-------+ +--+ |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 Location privacy is provided, since the correspondent node only learns HoA_OR and HoA_IR, which both have no relation to the mobile node's location. 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 HoA_OR. Weniger Expires August 31, 2007 [Page 10] Internet-Draft CNLocPriv February 2007 5. Location-dependent Home Agent Discovery This solution requires the discovery of the ORHA address, i.e., of a home agent located close to the correspondent node. A specification of such location-dependent home agent discovery 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 [10]). The drawback of this method is that only ORHAs located in correspondent node's domain can be discovered, i.e., it is not possible to discover an ORHA in nearby domains. This limits the applicability, since it cannot be assumed that a home agent is deployed in every correspondent node's domain. Another option could be to query a dedicated server (can be a server in the public Internet or a server provided by the mobility service provider or authorizer) that has a list of home agents and that is able to map an FQDN or address of a correspondent node to an FQDN or address of a home agent that is located topologically close to the correspondent node. The mobile node would query this server to discover the ORHA address. One option to realize this is to re-use DHCP-based HA assignment with the options and mechanisms defined in [6] and [7]. The mobile node would put the correspondent node's domain as target domain in the Home Network Identifier DHCP Option. A new id-type may be needed to indicate that a domain nearby to the target domain is requested, if the correspondent node's domain cannot be used as MSP. The mobile node's MSA would then determine and assign a home network or home agent to the mobile node, which is in or close to the correspondent node's domain. Note that the mobile node must verify that the discovered ORHA is trusted by the mobile node, if the HA assignment/discovery mechanism does also return untrusted ORHAs. This verification should be done before the mobile node reveals its location to the ORHA. The details of this verification is currently out of scope. Weniger Expires August 31, 2007 [Page 11] Internet-Draft CNLocPriv February 2007 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 when the correspondent node initiates a session or it should limit the number of ORHAs it is registered with. Fake sessions should be identified as such as fast as possible and the mobile node should de-register immediately from the corresponding ORHA. The ORHA knows the location of the mobile node and could distribute it to third parties without authorization from the mobile node. Hence, the mobile node must verify that the ORHA is trusted before the mobile node reveals its location to the ORHA. 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. This document is concerned with correspondent node-targeted location privacy only. Eavesdropper-targeted location privacy and any location privacy issue not directly related to Mobile IPv6 are out of the scope of this document. Weniger Expires August 31, 2007 [Page 12] Internet-Draft CNLocPriv February 2007 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-04 (work in progress), December 2006. [4] Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", draft-ietf-mip6-location-privacy-ps-05 (work in progress), February 2007. 7.2. Informative References [5] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in progress), May 2006. [6] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-02 (work in progress), February 2007. [7] Jang, H., "DHCP Option for Home Information Discovery in MIPv6", draft-ietf-mip6-hiopt-01 (work in progress), January 2007. [8] Dupont, F., "A Simple Privacy Extension for Mobile IPv6", draft-dupont-mip6-privacyext-04 (work in progress), July 2006. [9] Qiu, Y., "Mobile IPv6 Location Privacy Solutions", draft-irtf-mobopts-location-privacy-solutions-04 (work in progress), November 2006. [10] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Weniger Expires August 31, 2007 [Page 13] Internet-Draft CNLocPriv February 2007 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 August 31, 2007 [Page 14] Internet-Draft CNLocPriv 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). Weniger Expires August 31, 2007 [Page 15]