One document matched: draft-qiu-mip6-mnprivacy-00.txt

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
                 <draft-qiu-mip6-mnprivacy-00.txt>


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]