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)
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  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 , 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 , 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 , 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 , 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:
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
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
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 ,
Dual Stack Mobile IPv6 Support , Multiple Care-of Addresses
Registration , Binding Revocation , Generic Signaling Message
. 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.
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.1. Normative References
 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
 Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
 Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
 Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
 Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", RFC 4877,
 Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
 Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6", RFC 4941,
 Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", RFC 4882, March 2007.
 Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6,
UDP, and TCP Headers", RFC 4727, November 2006.
 Devarapalli, V., "Mobile IPv6 Experimental Messages", RFC 5096,
13.2. Informative References
 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.
 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.
 Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple
Privacy Extension for Mobile IPv6", Work in Progress,
 Daley, G., "Location Privacy and Mobile IPv6", Work
in Progress, January 2004.
 Weniger, K. and T. Aramaki, "Route Optimization and Location
Privacy using Tunneling Agents (ROTA)", Work in Progress,
 Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
 Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K.
Nagami, "Multiple Care-of Addresses Registration", RFC 5648,
 Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P.
Yegani, "Binding Revocation for IPv6 Mobility", Work
in Progress, October 2009.
 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
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.
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
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.
Institute for Infocomm Research, Singapore
1 Fusionopolis Way
#21-01 Connexis (South Tower)
Phone: +65-6408 2053
Fan Zhao (editor)
1600 Amphitheatre Parkway
Mountain View, CA 94043