8.  Security Considerations

   The solutions proposed in this document address one of the security
   issues in the mobile environment, i.e., location privacy.  Throughout
   the document, we provide a detailed analysis of how the proposed
   solutions address the location privacy problem.  We carefully design
   such solutions to make sure that they fit well into the Mobile IPv6
   framework; therefore, the same threat analysis, security mechanisms
   (such as IPsec, the sequence number in binding signaling messages,
   the return routability procedure), and considerations as described in
   RFC 3775 still apply.  Nevertheless, in the following we provide an
   in-depth analysis on security threats involving the use of the
   location privacy solutions and demonstrate that the proposed
   solutions do not introduce any new vulnerability or weaken the
   strength of security protection of the original Mobile IPv6 protocol.

8.1.  Home Binding Update

   Given the strong security of the cryptography algorithm used to
   generate the encrypted home address, eavesdroppers are unable to
   derive the real home address from the encrypted home address and thus
   to correlate the care-of address with the real home address.
   Moreover, the encrypted home address can be updated to prevent
   eavesdroppers from linking the mobile node's ongoing activities.

   During the pseudo home address registration, the home agent verifies
   that the requested pseudo home address is not in use by other mobile
   nodes; therefore, the other mobile node cannot, inadvertently or
   maliciously, intercept ongoing sessions of a victim mobile node by
   registering the same pseudo home address.

   A mobile node may attempt to register a large number of pseudo home
   addresses that may exhaust the pool of available pseudo home
   addresses and prevent other mobile nodes using location privacy
   protection.  The home agent MUST limit the number of pseudo home
   addresses that can be requested by a mobile node.  Also, with the
   IPsec security association between the home agent and the mobile
   node, if any misuse of the pseudo home address registration is
   detected, the home agent can identify the malicious mobile node and
   take further actions.

8.2.  Correspondent Binding Update

   The return routability procedure using the pseudo home address
   follows the same principle of the original return routability
   procedure, i.e., the message exchange verifies that the mobile node
   is reachable at both the pseudo home address and the care-of address
   (this is because the pseudo home address is required to be routable).
   Furthermore, the extended return routability procedure also utilizes
   the same security mechanisms as defined in RFC 3775, such as the
   nonce, the node key, and the sequence number, to protect against
   attacks.  Overall, it provides the same security strength as the
   original return routability procedure.

   The reverse-tunneled correspondent binding update procedure does not
   weaken security either.  Although the real home address is
   transferred in cleartext on the HA-CN path, eavesdroppers on this
   path can already perform more serious attacks against the mobile node
   with the Mobile IPv6 protocol.

8.3.  Route-Optimized Payload Packets

   Using the Encrypted Home Address option in route-optimized packets
   results in the same security implications when the Home Address
   option is used in such packets.  For example, the Encrypted Home
   Address option may be used by attackers to launch reflection attacks,
   e.g., by indicating the IP address of a victim node in the Encrypted
   Home Address option.  Similar to the processing rule for the Home
   Address option specified in RFC 3775, this document restricts the use
   of the Encrypted Home Address option: it can be used only if there is
   an established Binding Cache entry containing the encrypted (pseudo)
   home address.

   With the proposed location privacy solutions, the Encrypted Home
   Address routing header is used to carry the encrypted (pseudo) home
   address.  The same threats specified in RFC 3775 for the Type 2
   routing header are also possible when the routing header carries the
   encrypted (pseudo) home address.  Similar processing rules are also
   used in this document to address such a threat: if the encrypted
   (pseudo) home address in the Encrypted Home Address routing header
   does not match with that stored in the Binding Update List entry, the
   packet will be dropped.

9.  Related Work

   Our work benefits from previous work and discussion on this topic.
   Similar to the concept of the pseudo home address, many documents
   have proposed using a temporary identity to replace the mobile node's
   home address in the IPsec security association, Mobile IPv6 signaling
   messages, and data packets.  However, the details of how to generate
   and update this identity are absent.  In the following, we provide a
   survey of related work.

   RFC 4941 [10] specifies a mechanism to generate randomized interface
   identifiers, which can be used to update the care-of address and the
   home address.  However, with our solution, the prefix of a pseudo
   home address can be different from that of the real home address and
   other pseudo home addresses, which prevents eavesdroppers from
   correlating and analyzing IP traffic based on a common prefix.
   Furthermore, we also discuss the interval of IP address update in the
   mobility scenario in order to resist the profiling attack both
   effectively and efficiently.

   In [16], the authors propose using a temporary identity, called the
   Temporary Mobile Identifier (TMI), to replace the home address, and
   discussed the feasibility of utilizing the Crypto-Based Identifier
   (CBID), Cryptographically Generated Addresses (CGA), or Mobility
   Anchor Point (MAP) to further protect location privacy.  However, as
   a 128-bit random number, the TMI is not routable; therefore, it is
   not suitable to be the source IP address in the Home Test Init
   message forwarded by the home agent to the correspondent node.
   Otherwise, the home agent cannot receive the Home Test message from
   the correspondent node.  Furthermore, the document does not specify
   how to update the TMI to address the profiling attack.

   In [14], the authors propose a mechanism that uses an identity as the
   home address and periodically updates such an identity by using a key
   and a previous identity as inputs to a cryptography algorithm.

   In [15], the authors propose to update the mobile node's home address
   periodically to hide its movement.  The new home address is generated
   from the current local network prefix, the Binding Update session
   key, and the previous home address, and updated every time when the
   return routability procedure is performed.  The generated home
   address is random, routable, recognizable, and recoverable.

   In [18], the authors propose a mechanism to achieve both route
   optimization and location privacy at the same time.  This is done by
   discovering a tunneling agent near the correspondent node and
   bidirectionally tunneling data traffic between the mobile node and
   the tunneling agent.

10.  IANA Considerations

   This document creates a new registry "Pseudo Home Address
   Acknowledgement Status Codes" for the Status field in the Pseudo Home
   Address Acknowledgement mobility option.  The current values are
   described in Section 7.4 and are the following:

      0   Success

      128 Failure, reason unspecified

      129 Administratively prohibited

      130 Incorrect pseudo home address

      131 Invalid pseudo home address

      132 Dynamic pseudo home address assignment not available

11.  Conclusion

   In this document, we have proposed solutions to address location
   privacy issues in the context of mobility.  The main idea is to hide
   the binding between the home address and the care-of address from
   eavesdroppers and the correspondent node.  We have described two
   methods.  The first method extends the return routability to hide the
   real home address in Binding Update and data packets.  This method
   uses the real home address in return routability signaling, and does
   not require any changes to the home agent.  The second method uses
   pseudo home addresses starting from return routability signaling, and
   requires some extensions to the home agent operation.  This method
   protects revealing the real home address on the HA-CN path.  The two
   methods provide a means to hide the real home address from
   eavesdroppers, and the second method can also hide it from the
   correspondents.

   The solutions we have proposed are for the basic Mobile IPv6 protocol
   as specified in RFC 3775.  Recently, many extensions to Mobile IPv6
   have been proposed, such as the NEMO Basic Support protocol [19],
   Dual Stack Mobile IPv6 Support [20], Multiple Care-of Addresses
   Registration [21], Binding Revocation [22], Generic Signaling Message
   [23].  It is expected that the proposed location privacy solutions
   can be applied with some modifications, if needed, to address
   location privacy issues when these extensions are used.  One of our
   future works is to clarify related issues, if any, when the location
   privacy solutions are used with new Mobile IPv6 extensions.

12.  Acknowledgements

   The authors would like to thank the co-authors of previous documents
   from which this document is derived: Vijay Devarapalli, Hannu Flinck,
   Charlie Perkins, Feng Bao, Robert Deng, James Kempf, and Jianying
   Zhou.  In addition, sincere appreciation is also extended to Claude
   Castelluccia, Francis Dupont, Gabriel Montenegro, Greg Daley, Kilian
   Weniger, Takashi Aramaki, Wassim Haddad, Heejin Jang, and Michael
   Welzl for their valuable contributions, review, and discussion.  Work
   by Fan Zhao was done while he was at University of California, Davis
   and Marvell Semiconductor, Inc.

13.  References

13.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Kent, S. and K. Seo, "Security Architecture for the Internet
         Protocol", RFC 4301, December 2005.

   [3]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
         December 2005.

   [4]   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
         RFC 4306, December 2005.

   [5]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

   [6]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [7]   Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
         Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
         Agents", RFC 3776, June 2004.

   [8]   Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
         IKEv2 and the revised IPsec Architecture", RFC 4877,
         April 2007.

   [9]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 4291, February 2006.

   [10]  Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
         for Stateless Address Autoconfiguration in IPv6", RFC 4941,
         September 2007.

   [11]  Koodli, R., "IP Address Location Privacy and Mobile IPv6:
         Problem Statement", RFC 4882, March 2007.

   [12]  Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6,
         UDP, and TCP Headers", RFC 4727, November 2006.

   [13]  Devarapalli, V., "Mobile IPv6 Experimental Messages", RFC 5096,
         December 2007.

13.2.  Informative References

   [14]  Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol
         for Protecting Movement of Mobile Nodes in Mobile IPv6", Work
         in Progress, March 2005.

   [15]  Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol
         for Hiding Movement of Mobile Nodes in Mobile IPv6", Work
         in Progress, March 2005.

   [16]  Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple
         Privacy Extension for Mobile IPv6", Work in Progress,
         July 2006.

   [17]  Daley, G., "Location Privacy and Mobile IPv6", Work
         in Progress, January 2004.

   [18]  Weniger, K. and T. Aramaki, "Route Optimization and Location
         Privacy using Tunneling Agents (ROTA)", Work in Progress,
         October 2005.

   [19]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
         January 2005.

   [20]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
         Routers", RFC 5555, June 2009.

   [21]  Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K.
         Nagami, "Multiple Care-of Addresses Registration", RFC 5648,
         October 2009.

   [22]  Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P.
         Yegani, "Binding Revocation for IPv6 Mobility", Work
         in Progress, October 2009.

   [23]  Haley, B. and S. Gundavelli, "Mobile IPv6 Generic Signaling
         Message", Work in Progress, August 2008.

Appendix A.  Profiling Attack: Discussion

   Profiling attacks pose a significant threat to user privacy.  By
   collecting and analyzing (either online or offline) IP traffic,
   attackers can obtain sensitive user information.  In the context of
   mobility, although the profiling attack does not directly lead to
   compromise of location privacy in the way the disclosure of the
   binding between the home address and the care-of address does,
   attackers can infer the mobile node's roaming and track its movement
   (i.e., handover) by profiling the mobile node's communication based
   on certain fields in IP packets, such as a constant IPsec SPI used
   during the home registration.  The more information collected, the
   higher probability location privacy is compromised, which in return
   results in more targeted profiling.

   We have taken the profiling problem into consideration when designing
   the solution to IP address location privacy; however, not all aspects
   of profiling attacks are addressed since the profiling problem spans
   multiple protocol layers.  In the following, we provide a broad
   discussion on the profiling attack and protection mechanisms.  Our
   discussion is organized based on how profiling attacks can be
   performed.  Note that the following sections are not sorted based on
   any criteria or may not exhaustively list all the possible attack
   means (for example, profiling attacks based on upper-layer payloads
   in data packets are not discussed).

A.1.  The Care-of Address

   Eavesdroppers on the MN-HA path and/or the MN-CN path can profile the
   mobile node's communication by collecting packets with the same
   care-of address.  It is recommended that the mobile node periodically
   updates its care-of address by using DHCPv6 or IPv6 address privacy
   extension, even if it does not change its current attachment point.
   Furthermore, it is even better to change the network prefix of the
   care-of address periodically, since eavesdroppers may profile IP
   packets based on the common network prefix.

   Since the binding update procedure needs to be performed once the
   care-of address is changed, in order to reduce signaling overheads,
   the mobile node may choose to change its care-of address when the
   Binding Cache entry at the home agent or the correspondent node is
   about to expire.

A.2.  Profiling on the Encrypted Home Address

   Generated from either a real or pseudo home address, the encrypted
   home address can be dynamically updated, because a new key is
   generated when a new round of the return routability procedure is

   performed, which makes the encrypted home address look different in
   subsequent Binding Update and Acknowledgement messages.
   Nevertheless, the same encrypted home address is used in payload
   packets forwarded via the optimized route before the next round of
   the return routability procedure.  Given the cost and overhead of
   updating the encrypted home address, the proposed location privacy
   solutions still provide a reasonable level of protection against such
   profiling attacks.

A.3.  The IPsec SPI

   Eavesdroppers on the MN-HA path can profile the mobile node's
   communication based on the SPI of an IPsec security association that
   is for protecting the home Binding Update and Acknowledgement message
   or for protecting bidirectional-tunneled payload packets.

   To resist this kind of profiling attack, the IPsec SPI needs to be
   periodically updated.  One way is that the mobile node and the home
   agent rekey the IPsec security association or perform re-
   authentication periodically.  This may result in more signaling
   overhead.  Another way is that the mobile node or the home agent
   generates a new SPI and then notifies each other by exchanging the
   Binding Update and Acknowledgement messages protected by an existing
   IPsec security association with a non-null encryption algorithm.  In
   this way, the information of the new SPI is hidden from
   eavesdroppers.  The new SPI MUST not conflict with other existing
   SPIs; and if the conflict is detected on one end point, another SPI
   MUST be generated and be synchronized with the other end point.  The
   new SPI is applied to the next packet that needs to be protected by
   this IPsec security association.  This solution requires close
   interaction between Mobile IP and IPsec.  For example, when the home
   agent receives a new SPI suggested by the mobile node, it needs to
   change the corresponding Security Association Database (SAD) entry.

A.4.  The IPsec Sequence Number

   The IPsec sequence number is required to be larger than that in the
   previous valid IPsec packet if the anti-replay service is enabled.
   However, if the increment of the IPsec sequence number is fixed (for
   example, the IPsec sequence number is sequentially increased), it is
   possible for eavesdroppers to identify a sequence of IPsec packets
   that are from/to the same mobile node and to track the mobile node's
   activities.  One possible solution is to randomize the increment of
   the IPsec sequence number on both end points (i.e., the mobile node
   and the home agent) of the IPsec security association.  The algorithm
   to generate randomness is implementation specific.  It can be, for
   example, any random number generator, and independently chosen by
   each end point.

A.5.  The Regular Interval of Signaling Messages

   As described in RFC 3775, certain signaling messages may be exchanged
   on a regular basis.  For example, the correspondent registration
   needs to be performed every MAX_RR_BINDING_LIFETIME seconds and the
   home binding update procedure needs to be performed regularly, if the
   lifetime of the home Binding Cache entry is fixed.  Such timing
   allows eavesdroppers to perform traffic analyses and correlate
   different messages.  Due to background traffic and routing dynamics,
   the timing of messages observed by an eavesdropper at a certain
   vantage point may be irregular.  Nevertheless, a better solution is
   to randomize the lifetime of the Binding Cache entry in the home
   agent and the correspondent node.

A.6.  The Sequence Number in the Binding Update Message

   RFC 3775 requires that the sequence number in the Binding Update
   message be larger than that in the previous valid Binding Update
   message for a particular mobile node.  However, if the increment of
   the sequence number in the home or correspondent Binding Update
   message is fixed (for example, the sequence number is sequentially
   increased), it is possible for eavesdroppers on the MN-HA or MN-CN
   path to identify a sequence of Binding Update messages that are from
   the same mobile node and to track the mobile node's movement.  One
   possible solution is that the mobile node randomizes the increment of
   the sequence number used in subsequent Binding Update messages.  The
   algorithm to generate randomness is implementation specific.  It can
   be, for example, any random number generator.  Note that such an
   algorithm is not needed when the sequence number is encrypted, for
   example, when the home Binding Update message is protected by an
   IPsec tunnel mode security association.

A.7.  Multiple Concurrent Sessions

   It is possible for (colluded) eavesdroppers to correlate the mobile
   node's different sessions with the same or different correspondent
   nodes, for example, based on the same pseudo home address and/or the
   same care-of address.  A possible solution is to use different pseudo
   home addresses and different care-of addresses in different sessions.
   Note that the mobile node may also use the same pseudo home address
   with different correspondent nodes, if the pseudo home address is
   masked by different privacy management keys generated during the
   return routability procedure with different correspondent nodes.  In
   this way, the encrypted pseudo home addresses used with different
   correspondent nodes look different to eavesdroppers.

A.8.  Summary

   As discussed above, there exist multiple means for eavesdroppers to
   correlate observed activities.  For example, some IP fields, which
   contain certain constant values and remain unchanged for a long time,
   allow eavesdroppers to identify and link the mobile node's activities
   deterministically.  Other means may be less reliable when used for
   traffic analysis and correlation; nevertheless, they provide
   additional hints to malicious attackers.

   The solution to the profiling attack is to update certain IP fields
   periodically.  Generally, the more frequently, the higher the
   probability that the profiling attack is resisted and also the higher
   the cost in terms of communication and processing overheads and
   complexity.  As eavesdroppers can profile activities based on
   multiple fields, it may not be cost-effective to update some fields
   more frequently than others.  Furthermore, it may reduce some
   overheads, if all the related IP fields are updated together with the
   same frequency.

   The profiling attack is a complicated issue.  A complete solution
   would have to consider tradeoffs of many different factors, such as
   complexity, effectiveness, and efficiency.

Authors' Addresses

   Ying Qiu
   Institute for Infocomm Research, Singapore
   1 Fusionopolis Way
   #21-01 Connexis (South Tower)
   Singapore  138632

   Phone: +65-6408 2053
   EMail: qiuying@i2r.a-star.edu.sg


   Fan Zhao (editor)
   Google Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   EMail: fanzhao@google.com


   Rajeev Koodli
   Cisco Systems

   EMail: rkoodli@cisco.com