Mobile IPv6 Working Group Rajeev Koodli INTERNET DRAFT Vijay Devarapalli 14 February 2005 Hannu Flinck Charlie Perkins Nokia Research Center Solutions for IP Address Location Privacy in the presence of IP Mobility draft-koodli-mip6-location-privacy-solutions-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 solutions to the following two problems: disclosing a new IP address (CoA) to a correspondent, and revealing a fixed identity (HoA) to an eavesdropper. Koodli, Devarapalli Expires 14 August 2005 [Page i] Internet Draft IP Location Privacy Solutions 14 February 2005 Contents Abstract i 1. Introduction and Problem Description 1 2. Solutions for Disclosing Care-of Address 2 2.1. Reverse Tunneling . . . . . . . . . . . . . . . . . . . . 2 2.1.1. IP Header Formats for Binding Updates and Acknowledgments . . . . . . . . . . . . . . . . . 2 2.1.2. Packet Formats for Mobile Prefix Discovery . . . 3 2.2. HMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solutions for Home Address Profiling 4 3.1. Temporary Home Address . . . . . . . . . . . . . . . . . 4 3.1.1. IP Reachability for Temporary Home Addresses . . 4 3.1.2. IPsec SAs for Temporary Home Addresses . . . . . 5 3.1.3. Managing a List of Home Addresses . . . . . . . . 5 3.2. Privacy Label in place of Home Address . . . . . . . . . 6 3.2.1. Privacy Key Computation with Reverse-tunneled Binding Updates . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Privacy Key Computation with Route-Optimized Binding Updates . . . . . . . . . . . . . . . . . . . . . 8 3.3. Packet Format for Privacy Label . . . . . . . . . . . . . 9 4. IANA Considerations 9 5. Security Considerations 10 Intellectual Property Statement 11 Disclaimer of Validity 12 Copyright Statement 12 Acknowledgment 12 1. Introduction and Problem Description IP Address Location Privacy in the presence of IP Mobility is an important problem for which some solutions are already frequently discussed. However, details are not documented. Furthermore, solutions for Home Address profiling may benefit from more investigation. In this document, we first define the problem and then specify the details of solutions. We introduce a ``Privacy Koodli, Devarapalli Expires 14 August 2005 [Page 1] Internet Draft IP Location Privacy Solutions 14 February 2005 Label'' as a mechanism to hide Home Address during route-optimized communication. A related document [2] describes the IP address location privacy problem in greater detail. There are two problems related to IP address location privacy in the presence of mobility: Disclosing a new IP address (CoA) to a correspondent, and revealing a fixed IP address (HoA) to an eavesdropper. So, a MN may not mind using 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 consider each separately. 2. Solutions for Disclosing Care-of Address 2.1. Reverse Tunneling The Mobile Node (MN) can hide its current location from the Correspondent Node (CN) by reverse tunneling all its traffic through the Home Agent. The MN, in addition can hide its Home Address from any eavesdroppers on the access network by also reverse tunneling IPsec-encrypted Mobile IP signaling and data traffic with its Home Agent. As we discuss this solution, we also provide the IP header formats to be used. 2.1.1. IP Header Formats for Binding Updates and Acknowledgments When the MN sends a Binding Update from a visited link to its Home Agent, it should use the following packet format to prevent the Home Address from being revealed on the access network. IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = home agent) Mobility header Binding Update Alternate Care-of Address option (care-of address) The Home Agent should use the following IP header format to send a binding acknowledgment to a MN that is not on the home link. IPv6 header (source = home agent, destination = care-of address) Koodli, Devarapalli Expires 14 August 2005 [Page 2] Internet Draft IP Location Privacy Solutions 14 February 2005 ESP header in tunnel mode IPv6 header (source = home agent, destination = home address) Mobility header Binding Acknowledgment 2.1.2. Packet Formats for Mobile Prefix Discovery RFC 3776 [1] requires that Mobile Prefix Discovery messages are authenticated using IPsec. In order to prevent the home address from being visible to the access network, the MN must use IPsec encryption in addition to authentication. When the MN sends a Mobile Prefix Solicitation message to the Home Agent, it should use the following IP header format. IPv6 header (source = care-of address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = home agent) ICMPv6 Mobile Prefix Solicitation The Home Agent should tunnel the Mobile Prefix Advertisement message to the MN. IPv6 header (source = home agent, destination = care-of address) ESP header in tunnel mode IPv6 header (source = home agent, destination = home address) ICMPv6 Mobile Prefix Advertisement For Return Routability signaling messages, the packet formats defined in section 3.2 of RFC 3776 [1] are sufficient to prevent disclosing the Home Address of the MN to the access network. For payload traffic with any CN, the MN should use IPsec ESP in tunnel mode. The packet formats are defined in section 3.4 of RFC 3776. 2.2. HMIPv6 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 made hidden but not roaming itself. Even if a temporary Koodli, Devarapalli Expires 14 August 2005 [Page 3] Internet Draft IP Location Privacy Solutions 14 February 2005 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. Solutions for Home Address Profiling 3.1. Temporary Home Address The MN can prevent profiling based on its Home Address by avoiding extended use of the same Home Address. It can use RFC 3041 [3] to generate a temporary Home Address for communication. However, the use of temporary address has the following issues. 3.1.1. IP Reachability for Temporary Home Addresses If a MN configures a new temporary Home Address, it is not reachable at its new configured Home Address until the DNS is updated and the CN obtains the new Home Address. Sessions initiated by the CN will still use the MN's permanent Home Address. If the DNS entry for the MN is updated with the new temporary Home Address, then the MN becomes reachable at the new Home Address. The DNS update must be performed securely in order to prevent malicious modifications. For the MN to send a dynamic DNS update, it needs to have a security association with the DNS server. Having security associations between the DNS servers on the home link and every mobile node would present substantial administrative difficulties. Instead the MN can request the Home Agent to update the DNS entry for the MN. If the MN wants the Home Agent to update the DNS entry for the temporary Home Address, it includes a new mobility option, the DNS Update option in the Binding Update. The message format for the DNS update mobility option is shown in 3.1.1.1. The DNS update mobility option is protected by the existing security associations used for protecting the binding update. If the Binding Update is processed successfully, the Home Agent updates the DNS entry for the MN by sending a DNS update message from the MN's Home Address. The procedure for sending a DNS update message is specified in RFC 2136 [4]. Koodli, Devarapalli Expires 14 August 2005 [Page 4] Internet Draft IP Location Privacy Solutions 14 February 2005 3.1.1.1. DNS Update mobility option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN identity (FQDN/NAI.... ) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBA Option Length 8 bit unsigned integer indicating the length of the option excluding the type and length fields. MN identity The identity of the MN to be used by the home agent to send a Dynamic DNS update. It is a variable length field. 3.1.2. IPsec SAs for Temporary Home Addresses A number of IPsec security associations are created between the MN and the Home Agent to protect signaling messages. These security associations have to be re-negotiated when the MN's HoA changes. If a dynamic keying protocol such as IKE is used, the MN runs IKE every time it configures a new temporary Home Address. In case of IKEv1, the MN uses an identifier such as FQDN or NAI as Phase 1 identity, and the new Home Address as the Phase 2 identity. If IKEv2 is used, the MN must set the TSi (Traffic Selector-initiator) payload to its new temporary Home Address in the CREATE_CHILD_SA exchange. In case the IPsec SAs were created manually, the IPsec SAs for the new Home Address cannot be created withouth manual intervention. 3.1.3. Managing a List of Home Addresses The MN could have multiple permanent and temporary home addresses at any time. It should follow the recommendations listed below for handling multiple Home Addresses. - The MN should not delete the older Home Addresses as soon as it configures a new Home Address. It should maintain the list of Koodli, Devarapalli Expires 14 August 2005 [Page 5] Internet Draft IP Location Privacy Solutions 14 February 2005 all Home Addresses that were ever used. The list can be used to make sure that the same Home Address is not used again. - The MN should not attempt to update its DNS entry if there are active sessions using the old Home Address. - The MN should not delete the binding cache entries for the old Home Address as soon as the new Home Address is generated. It should wait for a period of time (configurable at the MN) before sending de-registration binding updates for the old Home Address. - The security associations based on the old home address should not be deleted immediately. If the security associations were created dynamically, they should be deleted when they expire. In summary, using temporary Home Addresses raises the following considerations. - Dynamic DNS update signaling upon change of a Home Address for each MN interested in avoiding Home Address profiling. - IKE re-negotiation upon change of a Home Address for each MN interested in avoiding Home Address profiling. - Managing multiple Home Addresses with care to ensure that it continues to be reachable at all times. Each of the above can be addressed, as we illustrated above. However, techniques which do not incur the overheads visible above need consideration. This motivates investigation of alternative techniques to disrupt Home Address profiling. 3.2. Privacy Label in place of Home Address It is desirable to not reveal the Home Address at all in packets sent by the MN to its correspondent. So, some other field can be used to substitute the HoA, but such a field must be communicated securely and the field itself must not become a target of profiling. We define a field which we call a Privacy Label, which is computed using the fields used for computing the Binding Update, and is sent as a destination option in place of the Home Address. The field is used by a correspondent to recover the Home Address from the Privacy Label in packets including the Binding Update packet. The Privacy Label is recomputed whenever return routability is run to provide a default protection against profiling. Changing the label on per-packet basis might be feasible and may be specified in the future revisions of this draft (if it turns out to be useful). Koodli, Devarapalli Expires 14 August 2005 [Page 6] Internet Draft IP Location Privacy Solutions 14 February 2005 The computation of Privacy Label is as follows: Privacy-Label = String XOR HoA ---- (1), where, String = First (128, HMAC_SHA1 (Kpm, (CoA | Home Nonce Index | Care-of Nonce Index))) ---- (2), Kpm is the privacy management key. Its computation depends on the way the Binding Update is sent. 3.2.1. Privacy Key Computation with Reverse-tunneled Binding Updates In this case, the packet header format is as follows: IPv6 header (source = home address, destination = home agent) ESP header in tunnel mode IPv6 header (source = home address, destination = correspondent node) Destination Option Privacy Label Mobility header Binding Update Alternate Care-of Address option (care-of address) The privacy management key Kpm is the same as the binding management key Kbm. When a CN receives a BU with alternate-CoA option and a new destination option containing the Privacy Label, it first computes the Kbm, verifies the MAC for the Binding Update, and then computes the String as specified in Equation (2) above. It can then recover the Home Address from the Privacy Label, and verify if it is actually the Home Address present in the source IP address. When the Binding Update is reverse-tunneled through the Home Agent, the Home Address is visible as the source IP address along the HA - CN path. Also, it should be possible to send the Binding Update directly. Koodli, Devarapalli Expires 14 August 2005 [Page 7] Internet Draft IP Location Privacy Solutions 14 February 2005 3.2.2. Privacy Key Computation with Route-Optimized Binding Updates With route-optimization, the Home Address is visible in the Binding Update. It is necessary for a CN to compute the home keygen token, the Kbm and subsequently verify the MAC for the Binding Update. With the Privacy Label, the Home Address is made invisible. Hence, it becomes necessary to compute a separate key for computing the Privacy Label that does not depend on the Home Address. The protocol extension is as follows. The MN sets a 'P' bit in the Reserved field of the HOTI message to indicate it wishes to use a Privacy Label in place of the Home Address. The CN, if it supports the 'P' bit, computes a Privacy Keygen Token as follows: Privacy Keygen Token = First (64, Kcn (HoA set to all zeros | nonce | 0)) This computation is similar to computing the home keygen token except that the HoA is set to all zeros. The Privacy Keygen Token is returned in the HOT message as a Mobility Header Option along with the home keygen token. The MN computes a session key Kpm after the return routability procedure as follows: Kpm = SHA1 (Privacy Keygen Token | care-of keygen token) --- (3) The String and Privacy Label computation are the same as defined above in Section 3.2. When a CN receives a Binding Update without the alternate-CoA option, but with a new destination option carrying the Privacy Label, it must first compute Kpm as specified in Equation (3). The computation is similar to how it would compute Kbm, except that the Privacy Keygen Token is computed with HoA set to all zeros. With Kpm, the CN computes the String and recovers the HoA. It can then compute the home keygen token, the Kbm, and verify the MAC for the Binding Update. If Binding Update processing is successful, the Privacy Label is considered valid. The CN then stores the nonce indices, and the Kbm itself. The CN sends a normal Binding Acknowledgment to the MN. In subsequent data packets, the MN computes the Privacy Label as defined in Section 3.2.1. Koodli, Devarapalli Expires 14 August 2005 [Page 8] Internet Draft IP Location Privacy Solutions 14 February 2005 The String is computed once by both the MN and the CN, and hence the the Privacy Label as computed above remains constant, until one of the address cookies expires or the MN undergoes a handover. 3.3. Packet Format for Privacy Label The packet format for Privacy Label is shown in Figure 3.3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Privacy Label + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBA Option Length 8 bit unsigned integer indicating the length of the option excluding the type and length fields. Privacy Label The Privacy Label as computed above 4. IANA Considerations The Privacy Label destination option introduced in 3.3 requires IANA assignment from the destinations options space. The DNS Update mobility option described in 3.1.1.1 requires IANA assignment from the mobility options space. Koodli, Devarapalli Expires 14 August 2005 [Page 9] Internet Draft IP Location Privacy Solutions 14 February 2005 5. Security Considerations The Privacy Keygen Token (with route-optimized Binding Updates) might be considered vulnerable since it uses all zeros in the HoA field. So, an eavesdropper does not have to intercept packets to determine the HoA. However, both Kcn and the nonce used are internal to a CN, and hence the computation is adequately secure. And, the HA - MN path can be encrypted to protect it from eavesdropping. An eavesdropper in the HA - CN path can tamper with the 'P' bit, perhaps setting it to force a CN to calculate the Privacy Keygen Token. The resulting DoS attack on the CN is limited to computing a one-time token. The computation of the String in the Privacy Label involves a MAC computation in addition to the MAC computation for the Binding Update; however, the computation of care-of keygen token is common to both the MAC computations. When a MN receives an unintended Privacy Keygen Token, it MUST discard it. The attacker can also unset the 'P' bit, in which case, the MN may be lead to believe that the CN does not support the privacy extension. However, an attacker on the HA - CN path can introduce many more acts that affect the Mobile IPv6 operation in the first place. For instance, the attacker can modify the Home Cookie so that it does not match what the MN maintains, and hence affect the return routability operation. References [1] J. Arkko, V. Devarapalli, and F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents. Request for Comments 3776, Internet Engineering Task Force, June 2004. [2] R. Koodli. IP Address Location Privacy and Mobility. Internet Draft, Internet Engineering Task Force. draft-koodli-location-privacy-00.txt, 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] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System (DNS UPDATE). Request for Comments (Proposed Standard) 2136, Internet Engineering Task Force, April 1997. Koodli, Devarapalli Expires 14 August 2005 [Page 10] Internet Draft IP Location Privacy Solutions 14 February 2005 Authors' Address Rajeev Koodli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: rajeev.koodl@nokia.com Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: vijay.devarapalli@nokia.com Hannu Flinck Nokia Research Center Itamerenkatu 11-13 Helsinki, Finland Email: hannu.flinck@nokia.com Charlie Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: charliep@iprg.nokia.com 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. Koodli, Devarapalli Expires 14 August 2005 [Page 11] Internet Draft IP Location Privacy Solutions 14 February 2005 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. 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, Devarapalli Expires 14 August 2005 [Page 12]