Network Working Group Feng BAO INTERNET-DRAFT Robert DENG Expires: September 6, 2005 James KEMPF Network Working Group Ying QIU Jianying ZHOU March 7, 2005 Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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. Distribution of this memo is unlimited. Abstract When a mobile node roams, its location information can be revealed by monitoring the IP addresses in its IP packets. This document proposes a technique for hiding a mobile node's care-of adress from its correspondent node and its home address from an eavesdropper using reverse tunelling. It also proposes another technique for preventing movement tracing of a mobile node by an eavesdropper during route optimization. Expires: September 6, 2005 [Page 1] Internet Draft MNprivacy March 7, 2005 Table of Contents 1. INTRODUCTION ................................................. 2 2. ASSUMPTION ................................................... 2 3. HIDING CoA FROM CORRESPONDENT NODE AND EAVESDROPPER VIA REVERSE TUNNELING ............................................ 3 4. HIDING HoA FROM AN EAVESDROPPER VIA ROUTE OPTIMIZATION ....... 3 4.1 Home Test Init from the Mobile Node ........................ 4 4.2 Home Test from Correspondent Node .......................... 4 4.3 Home Test to the Mobile Node ............................... 4 4.4 Binding Update to the Correspondent Node ................... 5 5. SECURITY CONSIDERATIONS ...................................... 5 6. CONCLUSION ................................................... 5 7. ACKNOWLEDGEMENTS ............................................. 5 8. REFERENCES ................................................... 6 9. AUTHORS' ADDRESSES ........................................... 6 Intellectual Property and Copyright Statements ................... 7 1. INTRODUCTION A mobile node (MN) can be uniquely identified by its Home Address (HoA). According to the current Mobile IPv6 specifications RFC3775 [1], a MN will be assigned a care-of address (CoA) when it roams to a foreign network and the MN will inform its Home Agent(HA) and Correspondent Node (CN) about its new CoA through a binding update process. Since the CoA includes location information of its current foreign network (prefix of the subnet) and the binding message as well as the subsequent IP packets contains both HoA and CoA, it is easy to find out the location of a mobile node (and its user) by keeping track of messages containing its HoA. In many circumstances, the users of mobile nodes desire to hide their geographical locations from their correspondent nodes as well as from eavesdroppers. This document proposes a technique for hiding a mobile node's care-of adress from its correspondent node and its home address from an eavesdropper using reverse tunelling mode. It also proposes another technique for preventing movement tracing of a MN by an eavesdropper during route optimization. 2. ASSUMPTIONS As in Mobile IPv6 RFC3775 [1], we assume that communications between a Mobile Node (MN) and its Home Agent (HA) are protected via IPSec Security Associations (SAs) (RFC3776 [2]). In particular, we assume that the MN and the HA shares a secret key Kph. This Kph could be derived from the secret key pre-established manually between the MN and HA or derived from the secret key set up during IKE phase 1 between the MN and the HA. Expires: September 6, 2005 [Page 2] Internet Draft MNprivacy March 7, 2005 In addition, the MN and its HA shares a "Pseudo HoA" which is a 128 bits random number. This Pseudo HoA and/or the real HoA will be used as selectors/indexes for the IPSec Security Associations (SAs) between the MN and HA. 3. HIDING CoA FROM CORRESPONDENT NODE AND HoA FROM AN EAVESDROPPER VIA REVERSE TUNNELING To hide its CoA from the CN and its HoA from an eavesdropper, the MN communicates Mobile IP signaling and IP data packets with its HA via reverse tunneling. When the MN sends a Home Binding Update from a visited network to its HA, it uses the following packet form to hide its HoA from being monitored on the access network: IPv6 header (source = CoA, destination = HA) Destination option header Home Address option (Pseudo HoA) ESP header in transport mode Mobility header Binding Update Alternative CoA option (CoA) The HA uses the following packet form to reply a Binding Acknowledgement to the MN that is not on the home link: IPv6 header (source = HA, destination = CoA) Routing header (type 2) Pseudo HoA ESP header in transport mode Mobility header Binding Acknowledgement In case the MN fails to receive the Binding Acknowledgement, the MN will retranismit the Binding Update but with a new sequence number in order to detect replay attack. The MN and HA each computes a new Pseudo HoA as follows: Pseudo HoA = HMAC_SHA1(Kph, Old Pseudo HoA)) The MN and HA then each replaces the old Pseudo HoA with the new one in their respective databases. This updating of Pseudo HoA is only performed once right after the successful home binding update and acknowledgement. Expires: September 6, 2005 [Page 3] Internet Draft MNprivacy March 7, 2005 4. HIDING HoA FROM AN EAVESDROPPER VIA ROUTE OPTIMIZATION The application of pseudo HoAs as described in Section 3 can be used to hide HoA of the MN from an eavesdropper during route optimization. 4.1 Home Test Init from the Mobile Node The MN sends HoTI to HA with the following packet form: IPv6 header (source = CoA, destination = HA) ESP header in tunneling mode IPv6 header (source = HoA, destination = CN) Mobility header HoTI The HoTI is then forwarded to the CN in the following form: IPv6 header (source = HoA, destination = CN) Destination option Pseudo HoA Mobility header HoTI 4.2 Home Test from Correspondent Node Upon receiving the HoTI from HA, the CN replies with HoT in the following form: IPv6 header (source = CN, destination = HoA) Mobility header HoT = (home init cookie, home keygen token, home nonce index) where home keygen token = First (64, HMAC_SHA1(Kcn, (Pseudo HoA | nonce | 0))) and Kcn is the CN's local secret [1]. 4.3 Home Test to the Mobile Node The HA receives the following HoT packet from the CN: IPv6 header (source = CN, destination = HoA) Mobility header HoT Expires: September 6, 2005 [Page 4] Internet Draft MNprivacy March 7, 2005 The HA then sends HoT to the MN in the following form: IPv6 header (source = HA, destination = CoA) ESP header in tunneling mode IPv6 header (source = CN, destination = HoA) Mobility header HoT 4.4 Binding Update to the Correspondent Node The MN sends the CoTI to the CN and the CN replies to the MN with CoT, in exactly the same ways as specified in the RR [1]. After receiving the HoT and CoT, the MN sends the Binding Update to the CN in the following packet form: IPv6 header (source = CoA, destination = CN) Destination Option E(Kbm, HoA) Mobility header Binding Update = (Pseudo HoA, home nonce index, ...) where Kbm is the binding update key given by Kbm = SHA1 (home keygen token | care-of keygen token) home keygen token = First (64, HMAC_SHA1(Kcn, (Pseudo HoA | nonce | 0))) Expires: September 6, 2005 [Page 5] Internet Draft MNprivacy March 7, 2005 Care-of keygen token = First (64, HMAC_SHA1(Kcn, (CoA | nonce | 1))) and E(Kbm, HoA) is a symmetric key encryption of the HoA under the secret binding update key Kbm. After receiving the BU, the CN first computes home keygen token and care-of keygen token. The CN then computes Kbm and decrypts E(Kbm, HoA) to recover HoA. The CN then keeps both HoA and Pseudo HoA in its binding cache table. The subsequent data traffic between the MN and the CN will follow the same procedure and packet format as specified in [1] except that the Pseudo HoA is used in place of the HoA. 5. SECURITY CONSIDERATIONS The techniques proposed here assume that the RR procedure is secure. In particular, an eavesdropper is not able to eavesdrop at the HA-CN path [1]. 6. CONCLUSION The proposal presents techniques for providing location privacy for mobile nodes. When using reverse tunneling, the proposal hides a MN's HoA from an eavesdropper and CoA from the CN. When using the route optimization, the proposal hides a MN's CoA from an eavesdropper. 7. ACKNOWLEDGEMENTS 8. REFERENCES [1] D. B. Johson and C. Perkins, "Mobility Support in IPv6", RFC 3775, June 2004. [2] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. Expires: September 6, 2005 [Page 6] Internet Draft MNprivacy March 7, 2005 9. AUTHORS' ADDRESSES Feng BAO Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-8456 EMail: baofeng@i2r.a-star.edu.sg Robert H. DENG Singapore Management University 469 Bukit Timah Road Singapore 259756 Phone: +65-6822-0920 EMail: robertdeng@smu.edu.sg James KEMPF DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose California 95110 USA Email: kempf@docomolabs-usa.com Ying QIU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6742 EMail: qiuying@i2r.a-star.edu.sg Jianying ZHOU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6668 EMail: jyzhou@i2r.a-star.edu.sg Expires: September 6, 2005 [Page 7] Internet Draft MNprivacy March 7, 2005 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 IETF's procedures with respect to rights in IETF 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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. Expires: September 6, 2005 [Page 8] Internet Draft MNprivacy March 7, 2005 ACKNOWLEDGMENT Funding for the RFC Editor function is currently provided by the Internet Society. Expires: September 6, 2005 [Page 9]