[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/