tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5726

Experimental
Pages: 48
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Mobile IPv6 Location Privacy Solutions

Part 1 of 3, p. 1 to 20
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Research Task Force (IRTF)                               Y. Qiu
Request for Comments: 5726               Institute for Infocomm Research
Category: Experimental                                      F. Zhao, Ed.
ISSN: 2070-1721                                                   Google
                                                               R. Koodli
                                                           Cisco Systems
                                                           February 2010


                 Mobile IPv6 Location Privacy Solutions

Abstract

   Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable
   while it roams on the Internet.  However, the location and movement
   of the mobile node can be revealed by the IP addresses used in
   signaling or data packets.  In this document, we consider the Mobile
   IPv6 location privacy problem described in RFC 4882, and propose
   efficient and secure techniques to protect location privacy of the
   mobile node.  This document is a product of the IP Mobility
   Optimizations (MobOpts) Research Group.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Research Task
   Force (IRTF).  The IRTF publishes the results of Internet-related
   research and development activities.  These results might not be
   suitable for deployment.  This RFC represents the consensus of the IP
   Mobility Optimizations Research Group of the Internet Research Task
   Force (IRTF).  Documents approved for publication by the IRSG are not
   a candidate for any level of Internet Standard; see Section 2 of RFC
   5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5726.

Page 2 
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................5
   2. Conventions and Terminology .....................................6
      2.1. Conventions ................................................6
      2.2. Terminology ................................................6
   3. Requirements ....................................................8
   4. Solution Overview ...............................................9
   5. Reverse-Tunneled Correspondent Binding Update ..................11
      5.1. The Procedure .............................................12
      5.2. Route-Optimized Payload Packets ...........................14
      5.3. Mobile Node Operation .....................................15
           5.3.1. Conceptual Data Structures .........................15
           5.3.2. Reverse-Tunneled Correspondent Binding
                  Update to the Correspondent Node ...................15
           5.3.3. Reverse-Tunneled Correspondent Binding
                  Acknowledgement from the Correspondent Node ........16
           5.3.4. Route-Optimized Payload Packets ....................16
           5.3.5. Receiving ICMP Error Message .......................17
           5.3.6. Binding Error from the Correspondent Node ..........17
           5.3.7. Binding Refresh Request from the
                  Correspondent Node .................................17
      5.4. Home Agent Operation ......................................17
      5.5. Correspondent Node Operation ..............................18
           5.5.1. Conceptual Data Structures .........................18
           5.5.2. Reverse-Tunneled Correspondent Binding
                  Update from the Mobile Node ........................18
           5.5.3. Reverse-tunneled Correspondent Binding
                  Acknowledgement to the Mobile Node .................18
           5.5.4. Route-Optimized Payload Packets ....................18
           5.5.5. ICMP Error Message to the Mobile Node ..............19
           5.5.6. Binding Error to the Mobile Node ...................19
           5.5.7. Binding Refresh Request to the Mobile Node .........19
      5.6. Summary ...................................................20
   6. IP Address Location Privacy Solution Using the Pseudo
      Home Address ...................................................20
      6.1. Home Binding Update .......................................20
           6.1.1. Pseudo Home Address Registration ...................20
           6.1.2. Home De-Registration ...............................21
      6.2. Correspondent Binding Update Using the Pseudo Home
           Address ...................................................22
           6.2.1. Return Routability Procedure .......................22
           6.2.2. Route-Optimized Correspondent Binding Update .......24
           6.2.3. Reverse-tunneled Correspondent Binding Update ......25
           6.2.4. Using Different Pseudo Home Addresses with
                  Different Correspondent Nodes ......................25
      6.3. Payload Packets ...........................................25
           6.3.1. Reverse Tunneling Mode .............................25

Top      ToC       Page 4 
           6.3.2. Route Optimization Mode ............................26
      6.4. Prefix Discovery ..........................................26
      6.5. Mobile Node Operation .....................................26
           6.5.1. Conceptual Data Structures .........................26
           6.5.2. Binding Update to the Home Agent ...................27
           6.5.3. Binding Acknowledgement from the Home Agent ........27
           6.5.4. Home Test Init to the Home Agent ...................28
           6.5.5. Home Test from the Home Agent ......................28
           6.5.6. Route-Optimized Payload Packets ....................29
           6.5.7. Receiving Binding Refresh Request ..................29
      6.6. Home Agent Operation ......................................29
           6.6.1. Conceptual Data Structures .........................30
           6.6.2. Binding Update from the Mobile Node ................30
           6.6.3. Binding Acknowledgement to the Mobile Node .........31
           6.6.4. Home Test Init from the Mobile Node ................31
           6.6.5. Home Test to the Mobile Node .......................32
      6.7. Correspondent Node Operation ..............................32
   7. Extensions to Mobile IPv6 ......................................32
      7.1. Encrypted Home Address Destination Option .................32
      7.2. Encrypted Home Address Routing Header .....................33
      7.3. Pseudo Home Address Mobility Option .......................34
      7.4. Pseudo Home Address Acknowledgement Mobility Option .......35
   8. Security Considerations ........................................37
      8.1. Home Binding Update .......................................37
      8.2. Correspondent Binding Update ..............................38
      8.3. Route-Optimized Payload Packets ...........................38
   9. Related Work ...................................................39
   10. IANA Considerations ...........................................40
   11. Conclusion ....................................................40
   12. Acknowledgements ..............................................41
   13. References ....................................................41
      13.1. Normative References .....................................41
      13.2. Informative References ...................................42
   Appendix A. Profiling Attack: Discussion ..........................44
     A.1. The Care-of Address ........................................44
     A.2. Profiling on the Encrypted Home Address ....................44
     A.3. The IPsec SPI ..............................................45
     A.4. The IPsec Sequence Number ..................................45
     A.5. The Regular Interval of Signaling Messages..................46
     A.6. The Sequence Number in the Binding Update Message ..........46
     A.7. Multiple Concurrent Sessions ...............................46
     A.8. Summary ....................................................47

Top      ToC       Page 5 
1.  Introduction

   The IP address location privacy problem is concerned with unwittingly
   revealing the current location of a mobile node to eavesdroppers and
   to communicating parties.  In the presence of mobility as specified
   in Mobile IPv6 [6], there are two related problems: disclosing the
   care-of address to a correspondent node, and revealing the home
   address to an eavesdropper (please see the terminology below).  A
   detailed description of the location privacy problem can be found in
   RFC 4882 [11].  This document assumes that the reader is familiar
   with the basic operation of Mobile IPv6 specified in RFC 3775, as
   well as the location privacy problem described in RFC 4882.

   In order to protect location privacy, a mobile node must not disclose
   the binding between its care-of address and its home address.  In
   this document, we propose a set of extensions to the Mobile IPv6
   specification to address the IP address location privacy problem.
   Related to the IP address location privacy is "profiling", where the
   activities of a mobile node are linked and then analyzed.  Profiled
   activities may contribute to compromising a mobile node's location
   privacy, especially when combined with additional information.
   Furthermore, once location privacy is compromised, it may lead to
   more targeted profiling.  Solutions to thwart profiling are
   important; however, they are not central to this document.  We
   discuss profiling in the appendix.

   We propose two IP address location privacy solutions in this
   document.  With the first solution (as described in Section 5), the
   mobile node can communicate with the correspondent node by using the
   real home address without location privacy being breached by
   eavesdroppers.  This is done by using parameters generated during the
   return routability procedure to mask the real home address, which
   provides an evolution towards location privacy protection based on
   return routability messages already specified in RFC 3775.  With the
   second solution (as described in Section 6), an IPsec tunnel mode
   security association with a non-null encryption algorithm is
   negotiated to encrypt signaling messages (including the real home
   address therein) exchanged between the mobile node and the home
   agent, for example, during the home binding update procedure.
   Furthermore, during the return routability procedure and the
   correspondent binding update procedure, a "pseudo home address" (the
   definition of this new term and many other commonly used mobility
   related terms is provided in Section 2) is used to replace the real
   home address in various messages, which allows the mobile node to
   hide its real home address from both the correspondent node and
   eavesdroppers without the need for additional extensions to the
   correspondent node.  Moreover, the mobile node may mask the pseudo

Top      ToC       Page 6 
   home address by using the mechanism specified in Section 5 to further
   enhance location privacy protection.  Each of these two solutions can
   be implemented on its own without relying on the other.

   The solutions presented in this document are designed based on the
   following assumptions.  First, we focus on location privacy issues
   arising when the mobile node attaches to a foreign link; location
   privacy issues when the mobile node attaches to its home link, if
   any, are outside the scope of this document.  Second, we assume that
   IPsec [2] is used to secure mobility signaling messages exchanged
   between the mobile node and the home agent; therefore, location
   privacy solutions when other security mechanisms are used are beyond
   the scope of this document.  Third, we assume that eavesdroppers are
   passive attackers, e.g., an eavesdropper along the path traversed by
   traffic flows from or to the mobile node.  We make this assumption
   because messages generated by active attackers can either be
   discarded based on local policy at a mobile node or the mobile node
   could choose to treat such messages like those of any other
   correspondent nodes.  Thus, specific threats to location privacy
   posed by active attackers are also beyond the scope of this document.
   Fourth, in order to simplify analysis, we assume that both the
   correspondent node and the home agent are fixed nodes; if either is
   mobile, the same analysis and solutions for the mobile node may also
   apply.  Finally, the same solution applies to each of the care-of
   addresses if a mobile node maintains more than one care-of address.

   This document represents the consensus of the MobOpts Research Group.
   It has been reviewed by the Research Group members active in the
   specific area of work.  At the request of their chairs, this document
   has been comprehensively reviewed by multiple active contributors to
   the IETF Mobile IP related working groups.

2.  Conventions and Terminology

2.1.  Conventions

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

2.2.  Terminology

   In this document, we introduce two new terms, "pseudo home address"
   and "encrypted home address".  The definition of these two terms is
   provided in the following.

Top      ToC       Page 7 
   o  Pseudo Home Address (pHoA): A unicast IPv6 address formed to
      replace the real home address used in certain Mobile IPv6
      signaling or data packets.  Without explicit indication, the
      pseudo home address looks like a regular IPv6 address [5].

   o  Encrypted Home Address (eHoA): The output when applying an
      encryption algorithm to the real home address or the pseudo home
      address with additional inputs, e.g., a key.  The real home
      address can be recovered from the encrypted home address by using
      a decryption algorithm.

   In addition, we use commonly adopted mobility-related terms as
   defined in [6] and [11] throughout this document.  Some of these
   terms are provided below for easier reference.  Nevertheless, we
   assume that readers are familiar with the basic operation of the
   Mobile IPv6 protocol as defined in RFC 3775 [6], RFC 3776 [7], and
   RFC 4877 [8].

   o  Mobile Node (MN): A Mobile IPv6 compliant mobile node that can
      roam on the Internet

   o  Correspondent Node (CN): An IPv6 node that communicates with the
      mobile node

   o  Home Network: The network where the mobile node is normally
      present when it is not roaming

   o  Visited Network: The network that the mobile node uses to access
      the Internet when it is roaming

   o  Home Agent (HA): A router on the mobile node's home network that
      provides forwarding support when the mobile node is roaming

   o  Home Address (HoA): The mobile node's unicast IP address valid on
      its home network

   o  Care-of Address (CoA): The mobile node's unicast IP address valid
      on the visited network

   o  Return Routability (RR): A procedure which enables secure binding
      between the care-of address and the home address when no pre-
      existing security association exists between the mobile node and
      the correspondent node

   o  Home Test Init (HoTI) / Home Test (HoT) / Care-of Test Init (CoTI)
      / Care-of Test (CoT): Messages used during the return routability
      procedure

Top      ToC       Page 8 
   o  Binding Update (BU): A message used by the mobile node to securely
      bind its care-of address to its home address at the correspondent
      node or the home agent

   o  Binding Acknowledgement (BA): A response to the Binding Update

   o  Message Authentication Code (MAC): The value, which is computed
      using HMAC_SHA1 in this document, that protects both a message's
      integrity and its authenticity

   o  Route Optimization: A mechanism that allows direct routing of
      packets between a roaming mobile node and its correspondent node,
      without having to traverse the home network

   o  Reverse Tunneling or Bidirectional Tunneling: A mechanism used for
      packet forwarding between a roaming mobile node and its
      correspondent node via its home agent

3.  Requirements

   In this section, we describe the requirements that should be met by
   the Mobile IPv6 location privacy solutions, hereafter referred to as
   "the solution".  These are some of the basic requirements set forth
   in order to make the solution readily implementable by those familiar
   with Mobile IPv6 and the related security protocols used with it
   (such as IKEv2 [4] and IPsec).

   R01: The solution must follow the framework and architecture of IPv6
        and Mobile IPv6 (as specified in RFC 3775, RFC 3776, and RFC
        4877).

   R02: The solution must not interfere with the operation of IPsec.
        This means that the principles and the operation specified in
        RFC 3776 and RFC 4877 need to be followed.  For example, the
        IPsec security association and policy must be identified by the
        real home address.

   R03: The solution should provide back-compatibility in order for
        different Mobile IPv6 entities to work together even though they
        may have different capabilities.  This requires the mobile node
        to be able to detect whether the home agent or the correspondent
        node supports the use of the location privacy solutions.

   R04: The overhead resulting from the solution, in terms of payloads
        or messages transmitted and memory, should be kept minimal.

Top      ToC       Page 9 
4.  Solution Overview

   The IP address location privacy solutions proposed in this document
   intend to conceal the binding between the mobile node's real home
   address and its care-of address from eavesdroppers and the
   correspondent node.  In this section, we present an overview of the
   proposed solutions.

   With the Mobile IPv6 specification, during the home binding update
   procedure, both the real home address and the care-of address are in
   the cleartext when either the IPsec tunnel mode or the IPsec
   transport mode is used with no encryption.  As described in
   Section 6.1, the solution to prevent the real home address being
   leaked to eavesdroppers on the MN-HA path during the home binding
   update procedure is to set up an IPsec tunnel mode security
   association with a non-null encryption algorithm to encrypt home
   binding signaling messages and the real home address therein.  This
   method is also used to enable location privacy protection during
   other mobility signaling message exchanges between the home agent and
   the mobile node, such as the prefix discovery procedure (see
   Section 6.4).

   When communicating with the correspondent node with the reverse
   tunneling mode, the mobile node can hide its current location from
   the correspondent node and eavesdroppers along the HA-CN path, since
   the care-of address is not included in payload packets transmitted on
   that path.  Also, an IPsec security association with a non-null
   encryption algorithm established between the mobile node and the home
   agent can conceal the real home address carried in payload packets
   from eavesdroppers along the MN-HA path.

   In order to communicate with a correspondent node in the route
   optimization mode, the mobile node needs to perform the return
   routability procedure followed by the correspondent binding update
   procedure.  With the current Mobile IPv6 specification, the real home
   address and the care-of address in the correspondent Binding Update
   message and payload packets are visible to eavesdroppers.  Therefore,
   in order to send and receive packets through the optimized route and
   protect location privacy at the same time, the mobile node needs to
   disclose its care-of address and conceal its real home address.
   There are two different scenarios and we propose a different solution
   for each scenario.

   One scenario is that the correspondent node is able to obtain the
   mobile node's real home address and initiates communication with the
   mobile node by using the real home address.  In this case, the mobile
   node needs to continue to use the real home address with the
   correspondent node in order to maintain session continuity, and to

Top      ToC       Page 10 
   conceal the real home address from eavesdroppers.  The solution for
   this scenario (hereinafter referred to as "reverse-tunneled
   correspondent binding update") is described in Section 5.  With this
   solution, the mobile node exchanges the same return routability
   signaling messages as defined in RFC 3775 with the correspondent node
   and then derives a privacy management key from keygen tokens and uses
   this key to encrypt the real home address.  Finally, it reverse-
   tunnels an extended correspondent Binding Update message via the home
   agent to register the encrypted home address and the real home
   address at the correspondent node.  After the correspondent
   registration, the mobile node and the correspondent node use the
   registered encrypted home address, instead of the real home address
   in payload packets exchanged via the optimized route.  The encrypted
   home address is different for different correspondent nodes since the
   privacy management key would be different.

   The other scenario is that the mobile node prefers to conceal its
   real home address from both the correspondent node and the
   eavesdroppers (typically the mobile node initiates communication in
   this case, since the correspondent node does not know the real home
   address).  The solution for this scenario is described in
   Section 6.2.  With this solution, the mobile node first obtains a
   home keygen token generated based on the pseudo home address during
   the home address test procedure.  Subsequently, the mobile node sends
   the correspondent Binding Update message to register the binding
   between the pseudo home address and the care-of address at the
   correspondent node via the optimized route.  After the correspondent
   registration, the mobile node and the correspondent node use the
   registered pseudo home address, instead of the real home address, in
   payload packets exchanged via the optimized route.  Note that the use
   of the pseudo home address is completely transparent to the
   correspondent node.

   Furthermore, it is feasible to throttle "profiling" on the pseudo
   home address by using a combination of these two solutions.  That is,
   the mobile node uses the pseudo home address in the extended home
   address test procedure to obtain a home keygen token; then, it uses
   the pseudo home address instead of the real home address in the
   reverse-tunneled correspondent binding update procedure.  With this
   solution, the encrypted pseudo home address used in route optimized
   payload packets looks different to eavesdroppers each time, after a
   new round of the return routability procedure is completed.

   Before a pseudo home address is used with a correspondent node, it
   MUST be registered with the home agent during the home registration
   procedure.  The mobile node indicates the requested pseudo home
   address in a new mobility option, called the Pseudo Home Address
   option (see Section 7.3), carried in the home Binding Update message,

Top      ToC       Page 11 
   and the home agent indicates the status of pseudo home address
   registration in another new mobility option, called Pseudo Home
   Address Acknowledgement option (see Section 7.4), carried in the home
   Binding Acknowledgement message.  The pseudo home address MUST be
   routable in order for the home agent to intercept packets destined at
   this pseudo home address.  It is statistically difficult for other
   nodes to derive the real home address from the pseudo home address.
   A detailed description of pseudo home address generation is provided
   in Section 6.1.1.1.

   With extensions introduced in this document, a mobile node is able to
   discover whether the home agent and the correspondent node support
   the location privacy solutions or not.  When present in the home
   Binding Update message, the Pseudo Home Address mobility option
   indicates that the mobile node requests the use of the location
   privacy solutions.  If such a Binding Update message is valid and the
   home agent supports the location privacy solutions for this
   particular mobile node, it responds with the Pseudo Home Address
   Acknowledgement mobility option in the Binding Acknowledgement
   message.  Otherwise, if the home agent does not support the location
   privacy solutions, it does not include the Pseudo Home Address
   Acknowledgement mobility option in the Binding Acknowledgement
   message.  Similarly, the presence of the Encrypted Home Address
   destination option in the correspondent Binding Update message
   indicates to the correspondent node that the mobile node requests the
   use of the location privacy solutions.  If such a Binding Update
   message is valid and the correspondent node supports the location
   privacy solutions for this particular mobile node, it responds with
   the Encrypted Home Address routing header in the correspondent
   Binding Acknowledgement message to the mobile node.  If the
   correspondent node does not support the location privacy solutions,
   it rejects the mobile node's request by returning an ICMP Parameter
   Problem message with Code value set to 2.  Furthermore, a home agent
   that recognizes such extensions but does not wish to provide location
   privacy protection MAY redirect the mobile node to another home
   agent.  If the request for using the location privacy solutions is
   rejected, the mobile node may either proceed without location privacy
   protection, or try with a different home agent or a correspondent
   node, or abort the operation.

5.  Reverse-Tunneled Correspondent Binding Update

   In this section, we describe a solution that protects location
   privacy against eavesdroppers when the mobile node uses the real home
   address during communication with the correspondent node via the
   optimized route.  Note that this solution does not require any change
   to return routability signaling messages.  The detailed description
   is as follows.

Top      ToC       Page 12 
5.1.  The Procedure

   After the return routability procedure is completed, if the mobile
   node needs to protect location privacy, and at the same time still
   uses the real home address with the correspondent node, the mobile
   node derives a privacy management key, Kpm, from the Kbm, where Kpm =
   HMAC_SHA1 (Kbm, 0).  The mobile node uses Kpm to generate the
   encrypted home address as follows.

      encrypted home address = Enc(Kpm, the home address)

      Where Enc() is a symmetric key encryption algorithm.  AES is the
      default encryption algorithm.

   Kpm changes upon every change of Kbm, which itself changes when
   return routability is run (e.g., upon change of care-of address,
   expiry of keygen token, etc.).  So, Kpm is not re-used when a care-of
   address changes.

   The mobile node generates a correspondent Binding Update message and
   reverse-tunnels this message to the correspondent node via the home
   agent.  The format of this message after encapsulation is:

       IPv6 header (source = care-of address,
                    destination = home agent)
       ESP header in tunnel mode
       IPv6 header (source = home address,
                    destination = correspondent node)
       Destination option header
           Encrypted Home Address option (encrypted home address)
       Parameters:
           Alternative Care-of Address option (care-of address)
           sequence number (within the Binding Update message header)
           home nonce index (within the Nonce Indices option)
           care-of nonce index (within the Nonce Indices option)
           First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
               | BU)))

   This packet is protected by the IPsec security association with a
   non-null encryption algorithm.  If the home agent can process this
   packet successfully, it forwards the following packet to the
   correspondent node.

       IPv6 header (source = home address,
                    destination = correspondent node)
       Destination option header
           Encrypted Home Address option (encrypted home address)

Top      ToC       Page 13 
       Parameters:
           Alternative Care-of Address option (care-of address)
           sequence number (within the Binding Update message header)
           home nonce index (within the Nonce Indices option)
           care-of nonce index (within the Nonce Indices option)
           First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
               | BU)))

   After receiving a reverse-tunneled correspondent Binding Update
   message, the correspondent node performs the operation as described
   in Section 5.5.  If the correspondent Binding Update message is
   processed successfully and an acknowledgement is requested, the
   correspondent node constructs a Binding Acknowledgement message shown
   below.

       IPv6 header (source = correspondent node,
                    destination = home address)
       Encrypted Home Address routing header
           encrypted home address
       Parameters:
           sequence number (within the Binding Update message header)
           First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
               | BA)))

   Upon receiving this Binding Acknowledgement message, the home agent
   applies the IPsec security association with a non-null encryption
   algorithm to this message and forwards the following packet to the
   mobile node.

       IPv6 header (source = home agent,
                    destination = care-of address)
       ESP header in tunnel mode
       IPv6 header (source = correspondent node,
                    destination = home address)
       Encrypted Home Address routing header
           encrypted home address
       Parameters:
           sequence number (within the Binding Update message header)
           First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
               | BA)))

   The reverse-tunneled correspondent binding update procedure is
   completed after the mobile node processes the received Binding
   Acknowledgement message.  Note that when the mobile node communicates
   with a different correspondent node, the encrypted home address looks
   different.

Top      ToC       Page 14 
   To delete an established Binding Cache entry at the correspondent
   node, the mobile node reverse-tunnels the following Binding Update
   message via the home agent.  Note that the Encrypted Home Address
   option is optional during the correspondent binding de-registration
   and only the home keygen token is used to generate Kbm and Kpm, if
   needed, in this case.

       IPv6 header (source = care-of address,
                    destination = home agent)
       ESP header in tunnel mode
       IPv6 header (source = home address,
                    destination = correspondent node)
       Destination option header (optional)
           Encrypted Home Address option (encrypted home address)
       Parameters:
           Alternative Care-of Address option (care-of address)
           sequence number (within the Binding Update message header)
           home nonce index (within the Nonce Indices option)
           care-of nonce index (within the Nonce Indices option)
           First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
               | BU)))

   If an acknowledgement is requested, the correspondent node returns
   the following Binding Acknowledgement message to the mobile node.

       IPv6 header (source = correspondent node,
                    destination = home address)
       Encrypted Home Address routing header (optional)
           encrypted home address
       Parameters:
           sequence number (within the Binding Update message header)
           First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
               | BA)))

   Since the destination IP address in this message is the home address,
   the home agent will receive this message and forward it to the mobile
   node via the reverse tunnel.

5.2.  Route-Optimized Payload Packets

   After the correspondent registration is completed successfully,
   subsequent payload packets are exchanged via the optimized route
   between the mobile node and the correspondent node.  In such packets,
   only the encrypted home address carried in the Encrypted Home Address
   destination option and the Encrypted Home Address routing header are
   visible to eavesdroppers.

Top      ToC       Page 15 
   The format of payload packets sent from the mobile node to the
   correspondent node is:

       IPv6 header (source = care-of address,
                    destination = correspondent node)
       Destination option header
           Encrypted Home Address option (encrypted home address)
       Payload

   The format of payload packets sent from the correspondent node to the
   mobile node is:

       IPv6 header (source = correspondent node,
                    destination = care-of address)
       Encrypted Home Address routing header
           encrypted home address
       Payload

5.3.  Mobile Node Operation

5.3.1.  Conceptual Data Structures

   The Binding Update List entry for the correspondent registration is
   extended with a new field to store the current encrypted home address
   used with a particular correspondent node.  The encrypted home
   address is stored when the mobile node sends a reverse-tunneled
   correspondent Binding Update message, and the state of the
   corresponding Binding Update List entry is updated when the mobile
   node successfully processes the correspondent Binding Acknowledgement
   message.  Note that the encrypted home address field is not valid in
   the Binding Update List entry for the home registration.

   Given that the encrypted home address is 128 bits long, it is
   expected that each encrypted home address or the combination of the
   encrypted home address and the correspondent node's IP address stored
   in the Binding Update List is unique.  Therefore, the mobile node can
   use the encrypted home address (or use it together with the
   correspondent node's IP address) as a primary key to look up the
   Binding Update List.

5.3.2.  Reverse-Tunneled Correspondent Binding Update to the
        Correspondent Node

   After the return routability procedure, if the mobile node chooses to
   use the location privacy solution with the correspondent node, e.g.,
   based on the mobile node's configuration, it generates the encrypted
   home address, updates or creates a new correspondent Binding Update
   List entry to store the encrypted home address, then forwards the

Top      ToC       Page 16 
   correspondent Binding Update message through the reverse tunnel
   established with the home agent.  Note that the MAC is generated in
   the same way as specified in RFC 3775, and it does not cover the
   encrypted home address.

5.3.3.  Reverse-Tunneled Correspondent Binding Acknowledgement from the
        Correspondent Node

   When the mobile node receives a Binding Acknowledgement message from
   the correspondent node in response to a previously sent reverse-
   tunneled correspondent Binding Update message, if this Binding
   Acknowledgement message contains an Encrypted Home Address routing
   header, the mobile node considers that the correspondent node
   supports the location privacy solution.  The mobile node
   authenticates this message based on RFC 3775.  If authentication is
   successful, the mobile node decrypts the encrypted home address and
   compares the result with the real home address, or compares the
   encrypted home address with the one stored in the Binding Update List
   entry.  If they match, the mobile node considers that the
   correspondent registration is successful and updates the state of the
   corresponding Binding Update List entry.  If they do not match, the
   mobile node MAY start the correspondent binding update procedure
   again.

5.3.4.  Route-Optimized Payload Packets

   In order to maintain session continuity, upper layers of the IP stack
   in the mobile node still use the real home address, even after the
   reverse-tunneled correspondent registration.

   A possible way of implementation is as follows.  When the Mobile IP
   sublayer at the mobile node receives a packet from the upper layer,
   the normal processing as specified in RFC 3775 is performed.
   Subsequently, the Home Address option is replaced with the Encrypted
   Home Address option carrying the encrypted home address stored in the
   corresponding Binding Update List entry, and then the mobile node
   forwards the packet to the correspondent node via the optimized
   route.

   On the other hand, when the mobile node receives a payload packet
   carrying the Encrypted Home Address routing header, the mobile node
   uses the encrypted home address (optionally together with the IP
   address of the correspondent node) to look up the Binding Update
   List.  If an entry is found, the mobile node accepts this packet,
   replaces the Encrypted Home Address option with the Home Address
   option carrying the real home address, and continues with processing
   based on RFC 3775.  If no entry is found, the mobile node silently
   drops the received packet.

Top      ToC       Page 17 
5.3.5.  Receiving ICMP Error Message

   The mobile node may receive an ICMP Parameter Problem, Code 2,
   message forwarded by the home agent via the bidirectional tunnel, for
   example, when the correspondent node does not support the use of the
   Encrypted Home Address option.  If such a message is received, the
   mobile node SHOULD not attempt to use the location privacy solution
   with the correspondent node.  The mobile node may choose either not
   to communicate with the correspondent node, or to communicate without
   location privacy protection.

5.3.6.  Binding Error from the Correspondent Node

   When the mobile node communicates with a correspondent node by using
   the encrypted home address, a Binding Error message with the Status
   field set as 1 (unknown binding for Home Address destination option)
   may be received by the mobile node if there is no valid Binding Cache
   entry established at the correspondent node.  Note that we do not
   specify a new Status value to be used in this case because the
   implementation of the Binding Update List entry can contain an
   indication of whether an encrypted home address is currently used
   with the correspondent node.  Upon receiving the Binding Error
   message, the mobile node can find out which encrypted home address is
   invalid by looking at the Home Address field of the Binding Error
   message.  The mobile node may then perform the correspondent binding
   update procedure to establish a valid binding for the encrypted home
   address.

5.3.7.  Binding Refresh Request from the Correspondent Node

   When the mobile node receives a Binding Refresh Request message sent
   from the correspondent node and forwarded by the home agent via the
   bidirectional tunnel, the mobile node needs to perform the
   correspondent binding update procedure to refresh the binding for the
   encrypted home address at the correspondent node.

5.4.  Home Agent Operation

   With the solution described in this section (i.e., Section 5), there
   is no new home agent operation to be specified.  That is, the home
   agent behaves based on RFC 3775 when processing signaling or data
   packets.

Top      ToC       Page 18 
5.5.  Correspondent Node Operation

5.5.1.  Conceptual Data Structures

   The Binding Cache entry is extended with a new field to store the
   current encrypted home address used with a particular mobile node.
   The encrypted home address is stored when the correspondent node
   successfully processes a reverse-tunneled correspondent Binding
   Update message.

   Given that the encrypted home address is 128 bits long, it is
   expected that each encrypted home address or the combination of the
   care-of address and the encrypted home address stored in the Binding
   Cache entry is unique.  Therefore, the correspondent node can use the
   encrypted home address (or use it together with the care-of address)
   as a primary key to look up the Binding Cache.

5.5.2.  Reverse-Tunneled Correspondent Binding Update from the Mobile
        Node

   When receiving a reverse-tunneled Binding Update message with the
   Encrypted Home Address option, if the correspondent node supports the
   location privacy solution, it verifies the message by using the same
   method as defined in RFC 3775.  If this verification succeeds, the
   correspondent node generates Kpm and uses it to decrypt the encrypted
   home address, and compares the result with the source IP address.  If
   they match, the correspondent node stores the encrypted home address
   in the corresponding Binding Cache entry.

5.5.3.  Reverse-tunneled Correspondent Binding Acknowledgement to the
        Mobile Node

   If an acknowledgement to the reverse-tunneled correspondent Binding
   Update message is requested by the mobile node, the correspondent
   node returns a Binding Acknowledgement message with the Encrypted
   Home Address routing header, if it supports the location privacy
   solution.  The MAC in the Binding Acknowledgement message is
   generated in the same way as specified in RFC 3775 and does not cover
   the encrypted home address carried in the Encrypted Home Address
   routing header.

5.5.4.  Route-Optimized Payload Packets

   In order to maintain session continuity, upper layers of the IP stack
   in the correspondent node still use the real home address, even after
   the reverse-tunneled correspondent registration.

Top      ToC       Page 19 
   A possible way of implementation is as follows.  When the IP layer at
   the correspondent node finishes processing the packet received from
   the upper layer based on RFC 3775, the Type 2 routing header together
   with the real home address therein is replaced with the Encrypted
   Home Address routing header with the encrypted home address found in
   the corresponding Binding Cache entry.  Then, this packet is
   forwarded to the mobile node via the optimized route.

   On the other hand, when the correspondent node receives a payload
   packet with the Encrypted Home Address option, it uses the encrypted
   home address (optionally together with the care-of address of the
   mobile node) to look up the Binding Cache.  If there is an entry, the
   correspondent node replaces the Encrypted Home Address option with
   the Home Address option carrying the real home address before
   forwarding the packet to the upper layer.  If no matching entry is
   found, the correspondent node sends a Binding Error message to the
   source IP address, i.e., the care-of address of the mobile node.

5.5.5.  ICMP Error Message to the Mobile Node

   When receiving a reverse-tunneled correspondent Binding Update
   message with the Encrypted Home Address option, if the correspondent
   node does not support location privacy extensions, it sends an ICMP
   Parameter Problem, Code 2, message to the source IP address (i.e.,
   the home address of the mobile node) and the home agent then forwards
   this ICMP message to the mobile node via the bidirectional tunnel.

5.5.6.  Binding Error to the Mobile Node

   When the correspondent node receives a payload packet with the
   Encrypted Home Address option for which there is no valid Binding
   Cache entry, it returns a Binding Error message with the Status code
   set as 1 back to the source IP address of the packet.  Furthermore,
   the Home Address field in the Binding Error message MUST be copied
   from the Encrypted Home Address field in the Encrypted Home Address
   destination option of the offending packet, or set to the unspecified
   address if no such option appears in the packet.

5.5.7.  Binding Refresh Request to the Mobile Node

   When the correspondent node realizes that a Binding Cache entry is
   about to expire, it sends a Binding Refresh Request message to the
   real home address of the mobile node stored in the Binding Cache
   entry.

Top      ToC       Page 20 
5.6.  Summary

   With the solution in Section 5, the real home address is visible in
   the Binding Update and Binding Acknowledgement messages along the
   HA-CN path.  Like Mobile IPv6 itself, it has not been designed to
   change the communications between the home network and the
   correspondent node; the same issues would affect non-mobile hosts as
   well.  This solution meets all the requirements set forth for the
   location privacy solutions and provides a simple way to provide
   location privacy protection while allowing the use of the real home
   address with the correspondent node.



(page 20 continued on part 2)

Next RFC Part