One document matched: draft-irtf-mobopts-location-privacy-solutions-10.txt
Differences from draft-irtf-mobopts-location-privacy-solutions-09.txt
Mobopts Working Group Y. Qiu
Internet-Draft Institute for Infocomm Research
Expires: May 7, 2009 F. Zhao
Marvell
R. Koodli
Starent Networks
November 3, 2008
Mobile IPv6 Location Privacy Solutions
draft-irtf-mobopts-location-privacy-solutions-10
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Draft will expire on May 7, 2009.
Qiu, et al. Expires May 7, 2009 [Page 1]
Internet-Draft MIP6 location privacy solutions November 2008
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 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10
5. Reverse-Tunneled Correspondent Binding Update . . . . . . . . 13
5.1. The Procedure . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Route Optimized Payload Packets . . . . . . . . . . . . . 15
5.3. Mobile Node Operation . . . . . . . . . . . . . . . . . . 16
5.3.1. Conceptual Data Structures . . . . . . . . . . . . . . 16
5.3.2. Reverse-tunneled Correspondent Binding Update to
the Correspondent Node . . . . . . . . . . . . . . . . 16
5.3.3. Reverse-tunneled Correspondent Binding
Acknowledgement from the Correspondent Node . . . . . 17
5.3.4. Route Optimized Payload Packets . . . . . . . . . . . 17
5.3.5. Receiving ICMP Error Message . . . . . . . . . . . . . 18
5.3.6. Binding Error from the Correspondent Node . . . . . . 18
5.3.7. Binding Refresh Request from the Correspondent Node . 18
5.4. Home Agent Operation . . . . . . . . . . . . . . . . . . . 18
5.5. Correspondent Node Operation . . . . . . . . . . . . . . . 19
5.5.1. Conceptual Data Structures . . . . . . . . . . . . . . 19
5.5.2. Reverse-tunneled Correspondent Binding Update from
the Mobile Node . . . . . . . . . . . . . . . . . . . 19
5.5.3. Reverse-tunneled Correspondent Binding
Acknowledgement to the Mobile Node . . . . . . . . . . 19
5.5.4. Route Optimized Payload Packets . . . . . . . . . . . 19
5.5.5. ICMP Error Message to the Mobile Node . . . . . . . . 20
5.5.6. Binding Error to the Mobile Node . . . . . . . . . . . 20
5.5.7. Binding Refresh Request to the Mobile Node . . . . . . 20
5.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. IP Address Location Privacy Solution Using the Pseudo Home
Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Home Binding Update . . . . . . . . . . . . . . . . . . . 22
Qiu, et al. Expires May 7, 2009 [Page 2]
Internet-Draft MIP6 location privacy solutions November 2008
6.1.1. Home Registration with IPsec Transport Mode . . . . . 22
6.1.2. Home Registration with IPsec Tunnel Mode . . . . . . . 25
6.1.3. Pseudo Home Address Registration . . . . . . . . . . . 25
6.1.4. Home De-registration . . . . . . . . . . . . . . . . . 26
6.2. Correspondent Binding Update Using the Pseudo Home
Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1. Return Routability Procedure . . . . . . . . . . . . . 27
6.2.2. Route Optimized Correspondent Binding Update . . . . . 29
6.2.3. Reverse-tunneled Correspondent Binding Update . . . . 30
6.2.4. Using Different Pseudo Home Addresses with
Different Correspondent Nodes . . . . . . . . . . . . 30
6.3. Payload Packets . . . . . . . . . . . . . . . . . . . . . 30
6.3.1. Reverse Tunneling Mode . . . . . . . . . . . . . . . . 30
6.3.2. Route Optimization Mode . . . . . . . . . . . . . . . 31
6.4. Prefix Discovery . . . . . . . . . . . . . . . . . . . . . 31
6.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 31
6.5.1. Conceptual Data Structures . . . . . . . . . . . . . . 31
6.5.2. Binding Update to the Home Agent . . . . . . . . . . . 32
6.5.3. Binding Acknowledgement from the Home Agent . . . . . 33
6.5.4. Home Test Init to the Home Agent . . . . . . . . . . . 34
6.5.5. Home Test from the Home Agent . . . . . . . . . . . . 35
6.5.6. Route Optimized Payload Packets . . . . . . . . . . . 35
6.5.7. Receiving ICMP Error Messages . . . . . . . . . . . . 36
6.5.8. Receiving Binding Refresh Request . . . . . . . . . . 36
6.6. Home Agent Operation . . . . . . . . . . . . . . . . . . . 37
6.6.1. Conceptual Data Structures . . . . . . . . . . . . . . 37
6.6.2. Binding Update from the Mobile Node . . . . . . . . . 37
6.6.3. Binding Acknowledgement to the Mobile Node . . . . . . 38
6.6.4. Home Test Init from the Mobile Node . . . . . . . . . 39
6.6.5. Home Test to the Mobile Node . . . . . . . . . . . . . 39
6.6.6. Binding Refresh Request to the Mobile Node . . . . . . 40
6.7. Correspondent Node Operation . . . . . . . . . . . . . . . 40
7. Extensions to Mobile IPv6 . . . . . . . . . . . . . . . . . . 41
7.1. Encrypted Home Address Destination Option . . . . . . . . 41
7.2. Extensions to the Type 2 Routing Header . . . . . . . . . 41
7.3. Pseudo Home Address Mobility Option . . . . . . . . . . . 42
7.4. Pseudo Home Address Acknowledgement Mobility Option . . . 44
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 46
8.1. Home Binding Update . . . . . . . . . . . . . . . . . . . 46
8.2. Correspondent Binding Update . . . . . . . . . . . . . . . 47
8.3. Route-Optimized Payload Packets . . . . . . . . . . . . . 47
9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 48
10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 49
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 49
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 49
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.1. Normative References . . . . . . . . . . . . . . . . . . . 50
13.2. Informative References . . . . . . . . . . . . . . . . . . 50
Qiu, et al. Expires May 7, 2009 [Page 3]
Internet-Draft MIP6 location privacy solutions November 2008
Appendix A. Profiling Attack: Discussion . . . . . . . . . . . . 52
A.1. The Care-of Address . . . . . . . . . . . . . . . . . . . 52
A.2. Profiling on the Encrypted Home Address . . . . . . . . . 52
A.3. The IPsec SPI . . . . . . . . . . . . . . . . . . . . . . 53
A.4. The IPsec Sequence Number . . . . . . . . . . . . . . . . 53
A.5. The Regular Interval of Signaling Messages . . . . . . . . 54
A.6. The Sequence Number in the Binding Update Message . . . . 54
A.7. Multiple Concurrent Sessions . . . . . . . . . . . . . . . 54
A.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 55
Appendix B. Version History . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 58
Qiu, et al. Expires May 7, 2009 [Page 4]
Internet-Draft MIP6 location privacy solutions November 2008
1. Introduction
IP address location privacy is concerned with unwittingly revealing
the current location of a mobile node to eavesdroppers and to
communicating parties. In the presence of mobility as defined in
Mobile IPv6 [6], there are two related aspects: disclosing the
care-of address to a correspondent node, and revealing the home
address to an eavesdropper. A detailed description of the location
privacy problem can be found 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 tackle the IP address location privacy problem. An
issue related to 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. Therefore, in addition to
protecting IP address location privacy, solutions to thwart profiling
activities based on various IP fields, especially those related to
Mobile IPv6 operation, should be considered.
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 causing location privacy 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), the real home address,
for example, when used during the home binding update procedure, is
encrypted by using a cryptography algorithm; 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 instead of 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 additional
extensions to the correspondent node needed. Moreover, the mobile
node may mask the pseudo home address by using the mechanism
specified in Section 5 to further enhance location privacy
protection. Each of these two solutions addresses different needs
arising from different scenarios and can be implemented on its own
without relying on the other. In addition to the IP address location
privacy solutions, we also discuss and propose solutions to address
Qiu, et al. Expires May 7, 2009 [Page 5]
Internet-Draft MIP6 location privacy solutions November 2008
the profiling attack in the appendix of this document.
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 not in the scope of this document. Second, we assume that
IPsec 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; that is, 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. Last, we assume that an entity involved in the
Mobile IPv6 operation, if supporting, MUST support the entirety of
location privacy extensions applicable to itself; otherwise, it MUST
not support any of such extensions. Note that such entity may choose
to use one or a combination of some solutions described in this
document to meet its needs of location privacy protection.
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.
o Pseudo Home Address (pHoA): An unicast IPv6 address formed to
replace the real home address used in certain Mobile IPv6
signaling or data packets. Without explicit indication, the
Qiu, et al. Expires May 7, 2009 [Page 6]
Internet-Draft MIP6 location privacy solutions November 2008
pseudo home address looks like a regular IPv6 address.
o Encrypted Home Address (eHoA): The output when applying an
encryption algorithm to the real 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 such 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, RFC 3776 and RFC 4877.
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
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
Qiu, et al. Expires May 7, 2009 [Page 7]
Internet-Draft MIP6 location privacy solutions November 2008
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
Qiu, et al. Expires May 7, 2009 [Page 8]
Internet-Draft MIP6 location privacy solutions November 2008
3. Requirements
In this section, we detail the requirements that MUST be met by the
Mobile IPv6 location privacy solutions, hereafter referred to as "the
solution".
R01: The solution MUST follow the framework and architecture of IPv6
and Mobile IPv6 (as specified in RFC 3775, RFC 3776 and RFC 4877).
Existing standards, including the Mobile IPv6 protocol and other
protocols that interact with Mobile IPv6, MUST be reused as much as
possible and extended only if deemed necessary and to the extent
needed for providing required location privacy protection. This
means that the solution MUST be implemented in the IP layer level
with most new functions introduced into the Mobile IP sublayer.
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 MUST be followed, for example, the IPsec security
association and policy MUST be identified by the real home address.
R03: The solution MUST 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 solution MUST comply with the usual IETF security policies
and recommendations, and particularly, it MUST not weaken security
protection provided in RFC 3775. In addition, security issues
specific to the solution MUST be fully addressed.
R05: The overhead resulted from the solution, in terms of payloads or
messages transmitted and memory, MUST be kept as minimal.
Qiu, et al. Expires May 7, 2009 [Page 9]
Internet-Draft MIP6 location privacy solutions November 2008
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, if needed. In this section, we present an
overview of the proposed IP address location privacy solutions for
Mobile IPv6.
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, if no encryption. The solution to prevent
the real home address being leaked to eavesdroppers on the MN-HA path
during the home binding update procedure is described in Section 6.1.
When the IPsec transport mode is used, the real home address carried
in the home address destination option is encrypted by using a secret
key shared between the mobile node and the home agent. The encrypted
home address is carried in a new IPv6 destination option, called
Encrypted Home Address option (see Section 7.1) in the home Binding
Update message and in the Type 2 routing header with a new 'E' bit
set as 1 (see Section 7.2) in the home Binding Acknowledgement
message. Both the home agent and the mobile node can recover the
real home address from the encrypted home address. Note that the
IPsec related operation as specified in RFC 3776 and RFC 4877 is not
changed with the use of the encrypted home address. When the IPsec
tunnel mode is used, the solution is that when setting up an IPsec
security association, the mobile node and the home agent MUST
negotiate a non-null encryption algorithm to encrypt home binding
signaling messages and the real home address therein. The methods
described above are 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.
To communicate with the correspondent node with 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, both the real
Qiu, et al. Expires May 7, 2009 [Page 10]
Internet-Draft MIP6 location privacy solutions November 2008
home address and the care-of address are visible to eavesdroppers in
the correspondent Binding Update message and payload packets.
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 may be able to or already
know the real home address, for example, when the correspondent node
is the initiator of the communication. 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 conceals 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; then, it 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 other scenario is that the mobile node prefers to conceal its
real home address to both the correspondent node and eavesdroppers,
for example, when the mobile node is the initiator of the
communication and the correspondent node does not know the real home
address. The solution for this scenario is described in Section 6.2.
With this solution, firstly the mobile node obtains a home keygen
token generated based on the pseudo home address during the home
address test procedure; then 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, we can 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
Qiu, et al. Expires May 7, 2009 [Page 11]
Internet-Draft MIP6 location privacy solutions November 2008
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.
Such pseudo home address, before used with the correspondent node,
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 Pseudo Home Address option
(see Section 7.3), carried in the home Binding Update message 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; furthermore, 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 can be found
in Section 6.1.3.1.
With extensions introduced in this document, the 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 Encrypted Home Address destination option
and/or the Pseudo Home Address mobility option indicate that the
mobile node requests the use of the location privacy solutions. If
such Binding Update message is valid and the home agent supports the
location privacy solutions for this particular mobile node, it
responds with the Type 2 routing header with the 'E' bit set and/or
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 Binding Update message is valid and the correspondent node
supports the location privacy solutions for this particular mobile
node, it responds with the Type 2 routing header with the 'E' bit set
in the correspondent Binding Acknowledgement message to the mobile
node. If either the home agent or the correspondent node does not
support the location privacy solutions, it rejects the mobile node's
request by returning an ICMP Parameter Problem, Code 2, message.
Furthermore, a home agent that recognizes such extensions but does
not want to enable location privacy protection MAY redirect the
mobile node to another home agent. If the request of using the
location privacy solutions is rejected, the mobile node MAY either
proceed without location privacy protection or choose to connect to a
different home agent or stop communicating with such home agent or
correspondent node.
Qiu, et al. Expires May 7, 2009 [Page 12]
Internet-Draft MIP6 location privacy solutions November 2008
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 provided as follows.
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 use
the real home address with the correspondent node, the mobile node
derives a privacy management key, Kpm, from the Kbm, 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.
The mobile node generates a correspondent Binding Update message and
reverse-tunnels such message to the correspondent node via the home
agent. The format of such message after encapsulation is shown as
follows. Note that the encrypted home address is carried in the
Encrypted Home Address option as defined in Section 7.1.
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, e.g., the same security association
used for protecting other bi-directionally tunneled payload packets.
If the home agent can process this packet successfully, it forwards
Qiu, et al. Expires May 7, 2009 [Page 13]
Internet-Draft MIP6 location privacy solutions November 2008
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)
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)))
The operation performed by the correspondent node, after a reverse-
tunneled correspondent Binding Update message is received, is
described in Section 5.5. If such correspondent Binding Update
message is processed successfully and an acknowledgement is
requested, the correspondent node constructs a Binding
Acknowledgement message shown as follows.
IPv6 header (source = correspondent node,
destination = home address)
Type 2 Routing header with the 'E' bit set
encrypted home address
Parameters:
Alternative Care-of Address option (care-of address)
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
Once 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)
Type 2 Routing header with the 'E' bit set
encrypted home address
Parameters:
Alternative Care-of Address option (care-of address)
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
Qiu, et al. Expires May 7, 2009 [Page 14]
Internet-Draft MIP6 location privacy solutions November 2008
The reverse-tunneled correspondent binding update procedure is
completed after the mobile node processes the received Binding
Acknowledgement message.
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.
Such message is received and forwarded by the home agent to the
mobile node.
IPv6 header (source = correspondent node,
destination = home address)
Type 2 Routing header with the 'E' bit set (optional)
encrypted home address
Parameters:
Alternative Care-of Address option (care-of address)
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
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 Type 2 routing header is visible to
Qiu, et al. Expires May 7, 2009 [Page 15]
Internet-Draft MIP6 location privacy solutions November 2008
eavesdroppers.
The format of payload packets sent from the mobile node to the
correspondent node is shown as follows.
IPv6 header (source = care-of address,
destination = correspondent node)
Destination option header
Encrypted Home Address option (encrypted home address)
Payloads
The format of payload packets sent from the correspondent node to the
mobile node is shown as follows.
IPv6 header (source = correspondent node,
destination = care-of address)
Type 2 Routing header with the 'E' bit set
encrypted home address
Payloads
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 when successfully processing
the correspondent Binding Acknowledgement message, the mobile node
updates the state of the corresponding Binding Update List entry.
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 bit 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 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, for
example, based on its configuration, it generates the encrypted home
address and the reverse-tunneled correspondent Binding Update message
Qiu, et al. Expires May 7, 2009 [Page 16]
Internet-Draft MIP6 location privacy solutions November 2008
as shown before. Note that the MAC is generated in the same way as
specified in RFC 3775 and it does not need to cover the encrypted
home address. The mobile node then either updates an existing or
creates a new correspondent Binding Update List entry to store the
encrypted home address, and forwards such message to the
correspondent node through the reverse tunnel established with the
home agent.
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, and if such message
contains a Type 2 routing header with the 'E' bit set, the mobile
node considers that the correspondent node supports the location
privacy solution. The mobile node authenticates such message based
on RFC 3775. If succeed, 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 successfully completed 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
Note that 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 that 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. After that, 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 Type 2 routing header with the 'E' bit set, 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 there is one matched entry found, the mobile node accepts
such packet, replaces the Encrypted Home Address option with the Home
Address option carrying the real home address and processes such
Qiu, et al. Expires May 7, 2009 [Page 17]
Internet-Draft MIP6 location privacy solutions November 2008
packet based on RFC 3775. If no entry is found, the mobile node
silently drops such packet.
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 bi-directional tunnel,
for example, when the correspondent node does not support the use of
the Encrypted Home Address option. If such message is received, the
mobile node MUST not attempt to use the location privacy solution
with such correspondent node. The mobile node may choose either not
to or to communicate with the correspondent node 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, while there is no valid Binding Cache
entry established at the correspondent node, 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. Note that we
do not specify a new Status value to be used in this case. This is
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. Once receiving such
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 either perform the correspondent
binding update procedure to establish a valid binding or communicate
with the correspondent node in the bi-directional tunneling mode.
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
bi-directional tunnel, the mobile node needs to perform the
correspondent binding update procedure to refresh the binding at the
correspondent node.
5.4. Home Agent Operation
With the solution described in this section, 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.
Qiu, et al. Expires May 7, 2009 [Page 18]
Internet-Draft MIP6 location privacy solutions November 2008
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 bit 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 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 this message by using the same
method as defined in RFC 3775: the home address is the source IP
address in this packet and the care-of address is carried in the
Alternative Care-of Address option. If such authentication 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 Type 2
routing header with the 'E' bit set, if it supports the location
privacy solution. The MAC in such Binding Acknowledgement message is
generated in the same way as specified in RFC 3775 and does not need
to cover the encrypted home address carried in the Type 2 routing
header.
5.5.4. Route Optimized Payload Packets
Note that 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.
Qiu, et al. Expires May 7, 2009 [Page 19]
Internet-Draft MIP6 location privacy solutions November 2008
A possible way of implementation is that when the IP layer at the
correspondent node finishes processing the packet received from the
upper layer based on RFC 3775, the real home address in the Type 2
routing header is replaced with the encrypted home address found in
the corresponding Binding Cache entry and the 'E' bit is set as 1.
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 one matched
entry found, 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
matched 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
such ICMP error message to the mobile node via the bi-directional
tunnel.
5.5.6. Binding Error to the Mobile Node
When the correspondent node receives a payload packet with the
Encrypted Home Address option; however, there is no valid Binding
Cache entry for this encrypted home address, it returns a Binding
Error message with the Status code set as 1 to the source IP address
of such 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 appeared
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.
Qiu, et al. Expires May 7, 2009 [Page 20]
Internet-Draft MIP6 location privacy solutions November 2008
5.6. Summary
With this solution, the real home address is visible as the source IP
address along the HA-CN path. However, eavesdroppers on the HA-CN
path can launch an attack to compromise the return routability
procedure anyway. Despite the limitations of the existing return
routability mechanism, this solution meets all the requirements we
set 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.
Qiu, et al. Expires May 7, 2009 [Page 21]
Internet-Draft MIP6 location privacy solutions November 2008
6. IP Address Location Privacy Solution Using the Pseudo Home Address
6.1. Home Binding Update
When the mobile node attaches to a foreign link, it performs the home
binding update procedure with the home agent, as specified in RFC
3775. In this section, we describe extensions to such procedure for
providing location privacy protection.
6.1.1. Home Registration with IPsec Transport Mode
As specified in RFC 3776, the IPsec transport security association is
used to protect home registration signaling messages and the real
home address is included in the Home Address destination option and
the Type 2 routing header. To prevent eavesdroppers on the MN-HA
path from breaching location privacy, we encrypt the real home
address and use the encrypted home address in mobility signaling
messages.
6.1.1.1. Encrypted Home Address
Generation
The mobile node generates the encrypted home address by encrypting
the real home address with a secret key, denoted by Kph, shared
between the home agent and the mobile node. The real home address
can be restored by decrypting the encrypted home address with the
shared secret key. Note that encrypted home address is not
routable.
As specified in RFC 3776 and RFC 4877, an IPsec security
association is established between the home agent and the mobile
node either manually or dynamically through IKEv2, for example,
during bootstrapping [12]. Kph can be generated either from the
shared manual key or the dynamic keying material for the child
security association, for example, Kph = HMAC_SHA1(Ks, 0) where Ks
is either the shared manual key or Ks = SHA1(KEYMAT) [4]. Note
that with such Kph generation methods, extensions to the IKEv2
protocol, e.g., explicit Kph negotiation, are not needed; because
the implementation of the Mobile IP function can simply fetch the
locally stored manual key or keying materials to generate Kph, if
Kph is deemed as needed.
How Kph is stored and retrieved is implementation specific. As an
example, Kph can be stored in the associated IPsec security
association entry in the Security Association Database (SAD),
which allows the mobile node and the home agent to retrieve Kph by
using the Security Parameters Index (SPI) to look up the SAD.
Qiu, et al. Expires May 7, 2009 [Page 22]
Internet-Draft MIP6 location privacy solutions November 2008
With Kph, the encrypted home address is computed by the mobile
node as follows:
encrypted home address = Enc(Kph, home address)
where Enc(.) is a symmetric key encryption algorithm
With Kph, the real home address is recovered from the encrypted
home address as follows:
home address = Dec(Kph, encrypted home address)
where Dec(.) is the same as Enc(.)
The encryption and decryption algorithm recommended in this
document is AES with 128 bit long input and output. There is no
additional padding or trimming needed with such AES algorithm.
Dynamic Update
The lifetime of Kph is associated with that of the IPsec security
association; therefore Kph is updated when such IPsec security
association is renewed or re-established. Within the lifetime of
Kph, the mobile node MAY want to generate and use different
encrypted home addresses to prevent tracking and profiling. To do
so, the mobile node can first generate a sequence of secret keys,
denoted by {K0, K1, ..., Kn}, from Kph, and then use Ki to
generate different encrypted home addresses. To avoid maintaining
an additional counter, the mobile node reuses the sequence number
in the IPsec header for generating Ki. Furthermore, given the
mobile node's normal movement pattern [6] and the long extended
IPsec sequence number (64 bit), it is expected that there is no
duplicated encrypted home address generated during the lifetime of
the IPsec security association. The procedure to generate the
encrypted home address with Ki is shown as follows.
Ki = HMAC_SHA1(Kph, IPsec sequence number)
encrypted home address = Enc(Ki, home address)
The procedure for the home agent to restore the real home address
is similar to what is described above: the home agent firstly
generates Ki based on Kph and the IPsec sequence number in the
received home Binding Update message, and then uses Ki to decrypt
the encrypted home address.
Note that during the home binding update procedure, the encrypted
home address is generated only by the mobile node; the home agent
Qiu, et al. Expires May 7, 2009 [Page 23]
Internet-Draft MIP6 location privacy solutions November 2008
does not need to generate the encrypted home address using the
method described above, since it can simply copy and return the
received encrypted home address to the mobile node in a response.
In other procedures initiated by the home agent, such as Binding
Revocation [22], the home agent MAY need to generate the encrypted
home address and the mobile node derives the real home address by
using the method described above.
Summary
The encrypted home address generated by using the mechanism
presented above has the following characteristics.
First, thanks to the strength of AES, eavesdroppers cannot recover
the real home address from the encrypted home address without the
knowledge of the secret key shared between the home agent and the
mobile node; and multiple dynamically updated encrypted home
addresses cannot be correlated and the knowledge of many encrypted
home addresses does not increase the possibility for eavesdroppers
to recover the real home address.
Second, the encrypted home address can be dynamically updated to
throttle the profiling attack. That is, a different encrypted
home address is present in every Binding Update message sent to
the home agent, since the IPsec sequence number is incremented in
each Binding Update message. An old encrypted home address cannot
be reused in conjunction with an either new or old IPsec sequence
number because either the real home address cannot be decrypted
correctly or the packet is detected as a replayed packet by the
IPsec anti-replay service, if available. In case that the anti-
replay service is not supported, for example when a manual key is
used, the mobile node should still use a (sequentially) increasing
sequence number in the IPsec header to prevent an eavesdropped
encrypted home address being replayed. Nevertheless, this is not
a new vulnerability and does not compromise the security of the
Mobile IPv6 protocol.
6.1.1.2. The Procedure
The format of the modified home Binding Update message when the IPsec
ESP transport mode is used is shown as follows.
Qiu, et al. Expires May 7, 2009 [Page 24]
Internet-Draft MIP6 location privacy solutions November 2008
IPv6 header (source = care-of address, destination = home agent)
Destination option header
Encrypted Home Address option (encrypted home address)
ESP header in transport mode
Mobility header
Home Binding Update
Alternative Care-of Address option (care-of address)
Pseudo Home Address option (pseudo home address)
In order to receive the response, including the indication of
location privacy support, from the home agent, the mobile node needs
to set the Acknowledgement (A) bit in the Binding Update message.
The format of the modified home Binding Acknowledgement message when
the IPsec ESP transport mode is used is shown as follows.
IPv6 header (source = home agent, destination = care-of address)
Type 2 Routing header with the 'E' bit set
encrypted home address
ESP header in transport mode
Mobility header
Binding Acknowledgement
Pseudo Home Address Acknowledgement option (pseudo home address)
Note that in the home Binding Acknowledgement message, the encrypted
home address carried in the Type 2 routing header is the same as the
one received in the Encrypted Home Address option of the home Binding
Update message.
6.1.2. Home Registration with IPsec Tunnel Mode
As specified in RFC 4877, the IPsec ESP tunnel mode security
association can be used to protect the home binding signaling
messages. To provide location privacy, a non-null encryption
transform MUST be negotiated during the establishment of the IPsec
security association. Therefore, the real home address is encrypted
and encapsulated, and made invisible to eavesdroppers on the MN-HA
path. The packet formats and processing rules are the same as
specified in RFC 3775 and RFC 4877.
6.1.3. Pseudo Home Address Registration
6.1.3.1. Generation
To protect location privacy in the route optimization mode, the
mobile node replaces the real home address used in certain signaling
and payload packets with the pseudo home address. Different from the
encrypted home address, the pseudo home address needs to be routable
Qiu, et al. Expires May 7, 2009 [Page 25]
Internet-Draft MIP6 location privacy solutions November 2008
so that the home agent can intercept packets with the pseudo home
address used as the destination address. Therefore, the pseudo home
address is generated by concatenating one of the home network
prefixes with a random bit string. There are many ways to generate
such random bit string, for example, by using a random number
generator or a secure encryption or hash algorithm, which prevents
eavesdroppers from revealing the real home address. The prefix used
to form the pseudo home address MUST be managed by the same home
agent; however, it does not have to be the same as that assigned to
the mobile node for generating the home address. Therefore, such
pseudo home address ensures that, when used in the home address test
messages, the same route path between the home agent and the
correspondent node as when the real home address is used is
traversed.
6.1.3.2. Registration
The mobile node MUST register the pseudo home address to be used with
the home agent before actually using it. To do so, the mobile node
indicates a pseudo home address in the Pseudo Home Address mobility
option in the Binding Update message sent to the home agent. If the
home agent supports the location privacy solution, it performs the
Duplicate Address Detection to detect whether this pseudo home
address conflicts with other pseudo home addresses submitted from
different mobile nodes. Based on the result, the home agent
indicates whether to accept the pseudo home address by setting up the
appropriate status code in the Pseudo Home Address Acknowledgement
option in the Binding Acknowledgement message. If the home agent
prefers the use of a different home network prefix from that of the
requested pseudo home address, the home agent returns the new pseudo
home address in the Pseudo Home Address Acknowledgement Mobility
option to the mobile node.
The mobile node MAY register the pseudo home address when it is about
to communicate with a correspondent node with location privacy
protection. In order to save message overhead, the mobile node MAY
register multiple pseudo home addresses in one Binding Update
message. The lifetime of registered pseudo home addresses is the
same as the Home Binding Cache entry. The mobile node can add or
delete any pseudo home address by using the Pseudo Home Address
mobility option in the home Binding Update message. The home agent
do not have to recover the real home address from such pseudo home
address.
6.1.4. Home De-registration
When the mobile node returns to its home link, the home de-
registration procedure is the same as specified in RFC 3775, i.e.,
Qiu, et al. Expires May 7, 2009 [Page 26]
Internet-Draft MIP6 location privacy solutions November 2008
the real home address is used as the source IP address in the Binding
Update message and the destination IP address in the Binding
Acknowledgement message. When the mobile node decides to disconnect
from the home agent while at its foreign link, the format of the
Binding Update and Acknowledgement is the same as that defined for
the home registration, except that the Lifetime field is set as zero.
The home agent deletes the corresponding Binding Cache entry
including the registered pseudo home address, if any.
6.2. Correspondent Binding Update Using the Pseudo Home Address
In this section, we specify a location privacy solution that allows
the mobile node to communicate with the correspondent node in the
route optimization mode without disclosing the real home address to
the correspondent node and eavesdroppers. This solution is needed
when the mobile node wants to conceal its real home address from the
correspondent node and the correspondent node cannot obtain the
mobile node's home address through other means, for example, by DNS
query. In this case, the pseudo home address is used to replace the
real home address in certain messages exchanged during the return
routability procedure and the correspondent binding update procedure.
There are two ways to send the correspondent Binding Update message,
either via the optimized route or the reverse tunnel. While the
former does not require the correspondent node to have any additional
support beyond what is specified in RFC 3775, RFC 3776 and RFC 4877,
the latter provides better location privacy protection by masking the
pseudo home address with parameters generated during the return
routability procedure.
6.2.1. Return Routability Procedure
The location privacy solution specified in this section does not
introduce any change to the care-of address test procedure as
specified in RFC 3775. In the following, we highlight the extensions
to the home address test procedure, during which the mobile node
obtains a home keygen token generated based on the pseudo home
address.
The mobile node generates and sends a Home Test Init message to the
home agent. The format of such message is shown as follows.
IPv6 header (source = care-of address, destination = home agent)
ESP header in tunnel mode
IPv6 header (source = home address, destination = correspondent)
Mobility Header (HoTI)
Home Init Cookie
Pseudo Home Address Mobility Option (pseudo home address)
Qiu, et al. Expires May 7, 2009 [Page 27]
Internet-Draft MIP6 location privacy solutions November 2008
The difference from what is specified in RFC 3775 is that the mobile
node includes a Pseudo Home Address mobility option (see Section 7.3)
in the Home Test Init message. The pseudo home address contained in
the Pseudo Home Address option is selected by the mobile node from a
set of pseudo home addresses that have been registered with the home
agent during the home registration procedure. Note that the Home
Test Init message is protected by an IPsec security association in
the ESP tunnel mode with a non-null encryption algorithm and a non-
null authentication algorithm, as specified in RFC 3776.
When receiving a Home Test Init message, the home agent performs
operation as specified in Section 6.6.4. If such operation succeeds
when the Pseudo Home Address mobility option is present in the Home
Test Init message, the home agent generates a Home Test Init message
and forwards to the correspondent node. As shown in the following,
the pseudo home address carried in the Pseudo Home Address mobility
option is used as the source IP address in the forwarded Home Test
Init message.
IPv6 header (source = pseudo home address, destination = correspondent)
Mobility Header (HoTI)
Home Init Cookie
The forwarded Home Test Init message looks the same to the
correspondent node as what is specified in RFC 3775 and the
correspondent node does not realize that the pseudo home address is
used, and just generates a home keygen token using the same algorithm
as specified in RFC 3775.
home keygen token =
First (64, HMAC_SHA1 (Kcn, (pseudo home address | nonce | 0)))
The correspondent node then replies with a Home Test message. As
shown in the following, the format of such Home Test message is the
same as that specified in RFC 3776 and the pseudo home address is
used as the destination IP address.
IPv6 header (source = correspondent, destination = pseudo home address)
Mobility Header (HoT)
Home Init Cookie
Home Keygen Token
Home Nonce Index
When the home agent intercepts such Home Test message using proxy
Neighbor Discovery, it performs operation as specified in
Section 6.6.5. If such operation succeeds, the home agent generates
the following Home Test message and forwards to the mobile node.
Qiu, et al. Expires May 7, 2009 [Page 28]
Internet-Draft MIP6 location privacy solutions November 2008
IPv6 header (source = home agent, destination = care-of address)
ESP header in tunnel mode
IPv6 header (source = correspondent, destination = home address)
Mobility Header (HoT)
Home Init Cookie
Home Keygen Token
Home Nonce Index
Pseudo Home Address Acknowledgement Mobility Option (pseudo home address)
When the mobile node receives the Home Test message, it performs
operation as specified in Section 6.5.5. If such operation succeeds,
the mobile node obtains a home keygen token computed using the pseudo
home address. After the care-of address test is completed, the
mobile node hashes the care-of keygen token and the home keygen token
together to generate Kbm using the same method as specified in RFC
3775.
6.2.2. Route Optimized Correspondent Binding Update
In this procedure, the mobile node MUST use the same pseudo home
address used during the home address test procedure. As shown in the
following, such pseudo home address is carried by the Home Address
option in the correspondent Binding Update message.
IPv6 header (source = care-of address, destination = correspondent)
Destination option header
Home Address destination option (pseudo home address)
Parameters
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)))
When the correspondent node receives the Binding Update message, it
performs the same operation as specified in RFC 3775. If such
operation succeeds and an acknowledgement is requested by the mobile
node, the correspondent node replies with the following Binding
Acknowledgement message.
IPv6 header (source = correspondent, destination = care-of address)
Parameters
sequence number (within the Binding Update message header)
First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent
| BA)))
After the mobile node receives the Binding Acknowledgement message
indicating that the correspondent registration succeeds, the mobile
Qiu, et al. Expires May 7, 2009 [Page 29]
Internet-Draft MIP6 location privacy solutions November 2008
node can now use the pseudo home address for communicating with the
correspondent node.
Such Binding Update message may also be used by the mobile node to
delete a previously established binding at the correspondent node.
In this case, similar to what is specified in RFC 3775, Kbm is
generated exclusively from the home keygen token that is based on the
pseudo home address.
6.2.3. Reverse-tunneled Correspondent Binding Update
The mobile node may choose to use a masked pseudo home address during
communication with the correspondent node. To do so, the mobile node
performs the reverse-tunneled correspondent binding update procedure
and uses the pseudo home address instead of the real home address
during such procedure. The format of messages during such procedure
is similar to what is described in Section 5 and Section 6.2.1. Note
that only one Pseudo Home Address mobility option is included in the
reversed tunneled correspondent Binding Update message.
6.2.4. Using Different Pseudo Home Addresses with Different
Correspondent Nodes
Based on its configuration and policy, the mobile node can choose to
use the same or different pseudo home addresses when communicating
with different correspondent nodes. Using a different pseudo home
address with each correspondent node may help prevent the mobile
node's activities from being linked and correlated. To do so, the
mobile node selects a different but already registered pseudo home
address and repeats the return routability procedure and the
correspondent binding update procedure with each correspondent node.
In addition, if the mobile node prefers, it MAY use different pseudo
home addresses for different sessions with the same correspondent
node. This typically requires additional configuration at the mobile
node that associates a specific session (for example, identified by
the port number and the protocol number among others) with a specific
pseudo home address. This document does not intend to go into the
details of such solution.
6.3. Payload Packets
6.3.1. Reverse Tunneling Mode
The format of payload packets reverse-tunneled via the home agent is
the same as specified in RFC 3775, except that an IPsec tunnel mode
security association with a non-null encryption algorithm MUST be
applied to such payload packets. Therefore, the binding between the
Qiu, et al. Expires May 7, 2009 [Page 30]
Internet-Draft MIP6 location privacy solutions November 2008
real home address and the care-of address is not leaked to
eavesdroppers along the MN-HA path.
6.3.2. Route Optimization Mode
When the route optimized correspondent binding update procedure is
performed, the format of payload packets exchanged between the mobile
node and the correspondent node is the same as specified in RFC 3775.
Note that the pseudo home address is used in the Home Address
destination and the Type 2 routing header. However, such difference
is transparent to the correspondent node. The operation of the
mobile node when communicating with the correspondent node via the
route optimization mode is described in Section 6.5.6 in details.
When the reverse tunneled correspondent binding update procedure is
performed, the format of payload packets exchanged between the mobile
node and the correspondent node is the same as specified in
Section 5, except that the encrypted home address destination option
and the Type 2 routing header actually contain an encrypted pseudo
home address. The operation of the mobile node and the correspondent
node is described in Section 5.3 and Section 5.5 in details.
6.4. Prefix Discovery
Similar to the home Binding Update/Acknowledgement message, the ICMP
Mobile Prefix Solicitation/Advertisement message can be protected by
IPsec either in the transport mode or the tunnel mode. The solutions
to protect location privacy during the prefix discovery procedure are
similar to those used during the home binding update procedure.
6.5. Mobile Node Operation
In this section, we describe the mobile node's operation when the
location privacy solution is used.
6.5.1. Conceptual Data Structures
6.5.1.1. Pseudo Home Address Table
We introduce a new data structure, called Pseudo Home Address table,
to record the information of pseudo home addresses. The mobile node
may maintain a Pseudo Home Address table for each home agent it
registers with. Each entry in the table contains a pseudo home
address and its associated state, i.e., "unconfirmed" or "confirmed".
The mobile node usually creates new entries or updates existing ones
with the "unconfirmed" state in the Pseudo Home Address table when
sending the home Binding Update message to (re)register new or
existing pseudo home address(es), and updates entries when receiving
Qiu, et al. Expires May 7, 2009 [Page 31]
Internet-Draft MIP6 location privacy solutions November 2008
the home Binding Acknowledgement message. The pseudo home address
can be used as a key to search the table. There MUST be no
duplicated pseudo home addresses stored in the Pseudo Home Address
table.
6.5.1.2. Binding Update List
The Binding Update List entry is extended with an additional field,
called Encrypted Home Address. This field is valid in the Binding
Update List entry for a home binding only and contains the encrypted
home address used in the Binding Update message sent to a particular
home agent. The Binding Update List can be searched by using the
encrypted home address as a key.
The Binding Update List entry is extended with another additional
field, called Pseudo Home Address. This field MAY be implemented as
a pointer that points to a corresponding entry in the Pseudo Home
Address table and initialized as NULL when the Binding Update List
entry is created (for example, when the mobile node sends a Binding
Update message or a Home Test Init message to the home agent). For
the binding sent to a specific home agent, the Pseudo Home Address
field points to the first entry in the Pseudo Home Address table (or
NULL if the table is empty), so that the mobile node can access all
the pseudo home addresses registered at this home agent; on the other
hand, for the binding sent to a specific correspondent node, the
Pseudo Home Address field points to the Pseudo Home Address table
entry that contains the actual pseudo home address used with this
correspondent node (or NULL if no pseudo home address is used with
this correspondent node).
6.5.2. Binding Update to the Home Agent
The mobile node may decide to perform the home registration with
location privacy protection, for example, when it attaches to a
foreign link or when it needs to extend the lifetime of a registered
home binding.
If the IPsec transport mode is used, after performing the operation
specified in RFC 3775 and RFC 3776, the mobile node generates the
encrypted home address from the real home address using the method
described in Section 6.1.1.1, replaces the Home Address option in the
generated Binding Update message with the Encrypted Home Address
option that carries the encrypted home address. If the mobile node
needs to register some pseudo home addresses, for example, it wants
to communicate with a correspondent node immediately after the home
registration procedure, it includes one or more Pseudo Home Address
mobility options in the Binding Update message. The mobile node may
indicate the requested pseudo home address or zero in the Pseudo Home
Qiu, et al. Expires May 7, 2009 [Page 32]
Internet-Draft MIP6 location privacy solutions November 2008
Address field, if it requests the home agent to dynamically assign
one. Finally, the mobile node sends the Binding Update message to
the home agent, updates its Binding Update List entry and the Pseudo
Home Address table to record the encrypted home address and the
pseudo home address(es) used (with "unconfirmed" state).
If the IPsec tunnel mode is used, the mobile node MUST negotiate a
non-null encryption algorithm, for example, during the bootstrapping,
and use it to protect the home Binding Update message as specified in
RFC 3775 and RFC 4877. In addition, the mobile node can register the
pseudo home address as described above. If the mobile node does not
want to register the pseudo home address right now, but just wants to
discover whether the home agent supports the location privacy
solution, the mobile node includes a Pseudo Home Address mobility
option without the Pseudo Home Address field in the Binding Update
message sent to the home agent.
In case that the mobile node needs to retransmit a Binding Update
message, for example, due to failure to receive a Binding
Acknowledgement message within a predefined time period, it generates
and uses a new encrypted home address in the re-transmitted Binding
Update message.
After sending the home de-registration binding update message, in
addition to the operation specified in RFC 3775, the mobile node MUST
stop using any data structure specific to the location privacy
solution and MAY delete them after the Binding Acknowledgement
message is processed successfully.
6.5.3. Binding Acknowledgement from the Home Agent
If the IPsec transport mode is used, when the mobile node receives a
Binding Acknowledgement message with the 'E' bit set in the Type 2
routing header, the mobile node searches its Binding Update List
using the encrypted home address as a key. If the mobile node finds
a valid Binding Update List entry pending for an acknowledgement, the
mobile node replaces the encrypted home address carried in the
Binding Acknowledgement message with the real home address stored in
the found Binding Update List entry. Then the mobile node follows
the rules specified in RFC 3775 and RFC 3776 to process the Binding
Acknowledgement message. If not found, the mobile node MAY follow
the same method as described in Section 6.1.1.1 to decrypt the real
home address from the encrypted home address before further
processing.
If the IPsec tunnel mode is used, the mobile node follows the rules
specified in RFC 3775 and RFC 4877 to processing the Binding
Acknowledgement message.
Qiu, et al. Expires May 7, 2009 [Page 33]
Internet-Draft MIP6 location privacy solutions November 2008
In addition, if one or more Pseudo Home Address Acknowledgement
mobility options are present in the Binding Acknowledgement message,
the mobile node checks the Status field in each option. If the
Status field in one option is 0 (Success), such pseudo home address,
if not existing, is added into the Pseudo Home Address table, and the
state of the corresponding entry is set as "confirmed"; if the Status
field in one option is '132', the mobile node SHOULD NOT request the
home agent to dynamically assign the pseudo home address in the
future; otherwise, the mobile node deletes any existing pseudo home
address with the "unconfirmed" state (i.e., either an error code or
no acknowledgement for such pseudo home address is received) from the
Pseudo Home Address table.
The mobile mode considers that the home agent supports the location
privacy solution, if one or more of the following is received:
o A valid Pseudo Home Address Acknowledgement mobility option with
or without a Pseudo Home Address field
o A valid Binding Acknowledgement message with the 'E' bit set in
the Type 2 routing header
Note that the mobile node MUST determine whether the home
registration succeeds or not based on what is specified RFC 3775.
6.5.4. Home Test Init to the Home Agent
To enable location privacy protection during communication with the
correspondent node in the route optimization mode, the mobile node
generates a Home Test Init message based on what is specified in RFC
3775 and RFC 3776. In addition, if the Return Routability procedure
is for a new session with the correspondent node, the mobile node
selects any pseudo home address from those already registered with
the home agent and stored in the Pseudo Home Address table;
otherwise, the mobile node must use the same pseudo home address as
used with the same correspondent node before. The selected pseudo
home address is carried in the Pseudo Home Address mobility option of
the generated Home Test Init message. Note that this Home Test Init
message is protected by an IPsec security association with a non-null
encryption algorithm.
After sending the Home Test Init message to the home agent, if there
is no Binding Update List entry existing for the correspondent node,
the mobile node creates one entry that points to the pseudo home
address used; otherwise, the mobile node updates the existing entry.
Qiu, et al. Expires May 7, 2009 [Page 34]
Internet-Draft MIP6 location privacy solutions November 2008
6.5.5. Home Test from the Home Agent
When the mobile node receives a Home Test message from the home
agent, it processes the packet based on processing rules specified in
RFC 3775 and RFC 3776. If this is a valid packet and there is a
Pseudo Home Address Acknowledgement option included, the mobile node
examines the Status field inside this mobility option as follows:
o If the Status field indicates that the home address test procedure
using the pseudo home address succeeds (the Status field is 0), in
addition to what is specified in RFC 3775, the mobile node
prepares to use the pseudo home address carried in the Pseudo Home
Address Acknowledgement option for the correspondent registration.
o If the Status field indicates that the home address test procedure
using the pseudo home address fails (the Status field is larger
than 127), the mobile node can take steps to correct the cause of
the error and retransmit the Home Test Init message, subject to
the re-transmission limit specified in RFC 3775. If this is not
done or it fails, then the mobile node SHOULD record in its
Binding Update List that the future home address test procedure
SHOULD NOT use the pseudo home address with this correspondent
node.
6.5.6. Route Optimized Payload Packets
After the mobile node completes the route optimized correspondent
registration procedure using the pseudo home address, payload packets
are sent to the correspondent node with the pseudo home address in
the Home Address destination option. Note that payload packets when
generated by upper layer applications still use the real home
address. As an example of implementation, when such packets are
passed to the Mobile IP layer, the operation specified in RFC 3775 is
performed firstly. Then, the destination IP address (i.e., the
correspondent node) is used to look up the Binding Update List to
look for the pseudo home address to be used. If found, the pseudo
home address is used to replace the real home address in the Home
Address destination option; otherwise, the real home address is used.
When the mobile node receives a payload packet with the Type 2
routing header, it needs to detect whether the location privacy
solution is used. If so, it needs to replace the pseudo home address
with the real home address before passing the received packet to the
transport layer. As an example of implementation, the mobile node
uses the source IP address (i.e., the correspondent node) to look up
the Binding Update List. The mobile node performs one of the
following operations:
Qiu, et al. Expires May 7, 2009 [Page 35]
Internet-Draft MIP6 location privacy solutions November 2008
o If the found Binding Update List entry contains a pseudo home
address that matches with the IP address carried in the Type 2
routing header, the mobile node accepts the packet and replaces
the pseudo home address with the real home address. The rest of
operation is the same as specified in RFC 3775.
o If the found Binding Update List entry does not contain a pseudo
home address and the IP address carried in the Type 2 routing
header matches with the real home address, the mobile node
performs the operation specified in RFC 3775.
o In all other cases, the mobile node silently drops the received
payload packet.
In case that the mobile node masks the pseudo home address and uses
the reverse-tunneled correspondent binding update procedure, the
mobile node performs the operation specified in Section 5.3.4, except
that the pseudo home address rather than the real home address is
expected.
6.5.7. Receiving ICMP Error Messages
When the mobile node receives an ICMP Parameter Problem, Code 2,
message as a response to the previously sent home Binding Update
message, the mobile node MUST conclude that the home agent does not
support the location privacy solution, and update the corresponding
Binding Update List entry. The mobile node MAY discover and register
with a different home agent, or continue with the same home agent
without requesting the location privacy support.
6.5.8. Receiving Binding Refresh Request
The Mobile Node may receive the Binding Refresh Request message from
either the home agent or the correspondent node. If from the
correspondent node, when the location privacy solution is used, the
destination IP address is the pseudo home address. In this case, the
mobile node needs to check the corresponding Binding Update List
entry with such correspondent node, if such pseudo home address is
invalid, the mobile node silently discards such message. Otherwise,
the mobile node refreshes the binding with the correspondent node by
using the same pseudo home address. If the Binding Refresh Request
message with the encrypted home address is received from the home
agent, the mobile node needs to derive the real home address firstly
and then process such message. After that, the mobile node performs
the home registration procedure with the home agent as described in
Section 6.1.
Qiu, et al. Expires May 7, 2009 [Page 36]
Internet-Draft MIP6 location privacy solutions November 2008
6.6. Home Agent Operation
In this section, we describe the home agent's operation when the
location privacy solution is used.
6.6.1. Conceptual Data Structures
The Binding Cache entry is extended with an additional field that
points to a list of currently accepted pseudo home addresses. Note
that each registered pseudo home address MUST be unique and all the
registered pseudo home addresses SHOULD be organized in such a way
that the associated Binding Cache entry can be quickly located when a
pseudo home address is used as the key to look up the Binding Cache.
6.6.2. Binding Update from the Mobile Node
When the home agent receives a Binding Update message with an
Encrypted Home Address destination option, if the home agent does not
recognize this destination option, it MUST send back an ICMP
Parameter Problem, Code 2, message to the source IP address and drop
the received Binding Update message. If the home agent recognizes
this destination option, it looks up the SAD using the SPI,
optionally together with the IPsec protocol type and the destination
IP address. This returns the established security association used
to process this received Binding Update message; otherwise, the home
agent proceeds based on the IPsec related processing rules. The home
agent SHOULD obtain Kph that may be stored with this security
association. If Kph cannot be generated, the home agent MUST ignore
the whole message and log the error. Otherwise, the home agent
generates Ki based on Kph and the IPsec sequence number, recovers the
real home address from the encrypted home address using the method
specified in Section 6.1.1.1, and finally replaces the encrypted home
address with the real home address. After transformation, the
received Binding Update message looks like a RFC3775 compliant
Binding Update message, thus the home agent continue to perform the
operation specified in RFC 3775 and RFC 3776. The following
operation will be performed if there is no any error during the
Mobile IPv6 processing.
If the received Binding Update message contains one or more Pseudo
Home Address mobility options, the home agent MUST ignore such option
if it does not recognize it. If the home agent recognizes such
option, a Pseudo Home Address Acknowledgement mobility option is
generated and some fields therein are set as follows:
o If the Pseudo Home Address field received is empty, the Status
field is set as 0 (Success) and the Pseudo Home Address field is
empty.
Qiu, et al. Expires May 7, 2009 [Page 37]
Internet-Draft MIP6 location privacy solutions November 2008
o If the Pseudo Home Address field received is set as all zero, the
Status field is set is 0 (Success) and a pseudo home address
SHOULD be included in the Pseudo Home Address field, if the home
agent supports the dynamic pseudo home address assignment;
otherwise, the Status field is set as 132 (Dynamic pseudo home
address assignment not available) and the Pseudo Home Address
field is empty.
o The Pseudo Home Address field received may contain an IPv6
address. If the format of such an IP address is incorrect, the
Status field is set as 130 (Incorrect pseudo home address). Or if
such IP address is invalid, for example, the prefix is not a valid
home network prefix or this is detected as a duplicated IP address
when the home agent performs the Duplicate Address Detection on
such IP address, the Status field is set as 131 (Invalid pseudo
home address). In both cases, the Pseudo Home Address field is
empty. Or if the home agent suggests a different pseudo home
address, the Status field is set as 0 (Success) and the new pseudo
home address is included in the Pseudo Home Address field.
Otherwise, if the home agent accepts the requested pseudo home
address, the Status field is set as 0 (Success) and the same IP
address is included in the Pseudo Home Address field.
o If the home agent does not allow the mobile node to use the pseudo
home address with the correspondent node, the Status field SHOULD
be set as 129 (Administratively prohibited) and the Pseudo Home
Address field is empty.
o In case that the home agent does not accept the Pseudo Home
Address mobility option for all other reasons, the Status field
SHOULD be set as 128 (Failure, reason unspecified) and the Pseudo
Home Address is empty.
When receiving a Binding Update message protected with the IPsec
tunnel mode, the home agent performs the operation specified in RFC
4877.
When receiving and successfully processing a Binding Update message
for de-registration from the mobile node, in addition to what is
specified in RFC 3775, the home agent MUST delete data structures
related to the location privacy extension.
6.6.3. Binding Acknowledgement to the Mobile Node
If the mobile node sets the 'A' bit in the Binding Update message,
the home agent generates a Binding Acknowledgement message using the
real home address with the proper status code set. Then this Binding
Acknowledgement message is processed by applying the IPsec security
Qiu, et al. Expires May 7, 2009 [Page 38]
Internet-Draft MIP6 location privacy solutions November 2008
association, as specified in RFC 3776. Finally, the home agent sets
the 'E' bit in the Type 2 routing header and replaces the real home
address therein with the encrypted home address received from the
Encrypted Home Address destination option in the Binding Update
message.
The processing rules related to the Pseudo Home Address
Acknowledgement mobility option are described in Section 6.6.2.
When sending a Binding Acknowledgement message protected with the
IPsec tunnel mode, the home agent performs the operation specified in
RFC 4877.
6.6.4. Home Test Init from the Mobile Node
When receiving a Home Test Init message from the mobile node, the
home agent firstly verifies such message based on the IPsec
processing rules as specified in RFC 3776. If fail, the home agent
acts based on such IPsec processing rules. Otherwise, if the Pseudo
Home Address option does not exist in the Home Test Init message, the
home agent performs the operation as specified in RFC 3775.
Otherwise, the following operation is performed.
1. The home agent looks up its Binding Cache by using the real home
address as a key, if the pseudo home address carried in the
Pseudo Home Address option does not match any pseudo home address
associated with the corresponding Binding Cache entry (including
when the Pseudo Home Address field is set as zero), it MUST
reject such Home Test Init message by sending back a Home Test
message including the Pseudo Home Address Acknowledgement option
with the Status field set as 131 (Invalid pseudo home address).
If there are multiple Pseudo Home Address options received, the
home agent MAY use the first option and ignore others.
2. Otherwise, the home agent constructs a Home Test Init message
with the pseudo home address as the source IP address, and
forwards the Home Test Init message to the correspondent node.
6.6.5. Home Test to the Mobile Node
When the home agent intercepts a Home Test message using proxy
Neighbor Discovery, if the destination IP address matches with one of
the real home addresses, the home agent performs the operation as
specified in RFC 3775. Otherwise, the home agent uses the
destination IP address to look up the Binding Cache to find if there
is a matched pseudo home addresses. If not, the home agent discards
such message silently; otherwise, the home agent generates a Home
Test message with a Pseudo Home Address Acknowledgement option and
Qiu, et al. Expires May 7, 2009 [Page 39]
Internet-Draft MIP6 location privacy solutions November 2008
sends it to the mobile node. Inside the Pseudo Home Address
Acknowledgement option, the Status field is set as zero (Success) and
the Pseudo Home Address field is filled with the found pseudo home
address.
6.6.6. Binding Refresh Request to the Mobile Node
As specified in RFC 3775, the correspondent node may send a Binding
Refresh Request message to the home address to request the Binding
Cache entry to be refreshed. With the location privacy solution
used, the correspondent node may send the Binding Refresh Request
message to a pseudo home address registered in one Binding Cache
entry. In this case, when the home agent receives a Binding Refresh
Request message from the correspondent node, if the destination IP
address is one of registered real home addresses, the home agent
performs the operation specified in RFC 3775; otherwise, if such IP
address is one of registered pseudo home addresses, the home agent
finds the mobile node's real home address and sends the Binding
Refresh Request message via the bi-directional tunnel to the mobile
node.
If the home agent wants to send a Binding Refresh Request message to
the mobile node, it MAY apply the same IPsec security association for
the home binding messages to the Binding Refresh Request message.
6.7. Correspondent Node Operation
With the solution described in this section, when the correspondent
node is involved in the route optimized correspondent binding update
procedure, there is no new operation to be specified. That is, the
correspondent node behaves based on RFC 3775 when processing
signaling or data packets using the pseudo home address. On the
other hand, when the correspondent node is involved in the reverse-
tunnel correspondent binding update procedure with the pseudo home
address used, the additional correspondent node operation is the same
as specified in Section 5.5, except that the pseudo home address,
instead of the real home address, is used.
Qiu, et al. Expires May 7, 2009 [Page 40]
Internet-Draft MIP6 location privacy solutions November 2008
7. Extensions to Mobile IPv6
7.1. Encrypted Home Address Destination Option
This option is used in the Destination Option extension header (Next
Header value = 60). Its format is shown as follows.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type
A unique type for identifying the use of the encrypted home
address (to be determined by IANA).
Encrypted Home Address
The encrypted home address generated from a either real or
pseudo home address.
The processing of other fields in the Encrypted Home Address option
is the same as that of those fields in the Home Address option
described in RFC 3775. Note that if the Encrypted Home Address
option is present in a packet, the encrypted home address therein
MUST not be treated as the real source IP address by the receiver.
7.2. Extensions to the Type 2 Routing Header
A new bit in the Reserved field of the Type 2 routing header is used
to indicate that the encrypted home address is carried in this
routing header. The format of the modified Type 2 routing header is
shown as follows.
Qiu, et al. Expires May 7, 2009 [Page 41]
Internet-Draft MIP6 location privacy solutions November 2008
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len=2 |Routing Type=2 |Segments Left=1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Encrypted Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encrypted Home Address (E)
The Encrypted Home Address (E) bit is set to indicate that the
encrypted home address is carried in the routing header.
Encrypted Home Address
The encrypted home address generated from a either real or
pseudo home address.
The processing of other fields in this type of the routing header is
the same as described in RFC 3775. Note that if the Type 2 routing
header with the 'E' set is present in a packet, the encrypted home
address therein MUST not be treated as the real destination IP
address by the receiver.
7.3. Pseudo Home Address Mobility Option
This mobility option is included in the mobility header, including
the Binding Update message and the Home Test Init message, and
carries zero or one pseudo home address. The alignment requirement
for this option is 4n. Its format is shown as follows.
Qiu, et al. Expires May 7, 2009 [Page 42]
Internet-Draft MIP6 location privacy solutions November 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD) | Length | Prefix length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A unique type for identifying the Pseudo Home Address mobility
option (to be determined by IANA).
Length
The length of the Pseudo Home Address mobility option excluding
the Type field and the Length field. It MUST be 2 when the
Pseudo Home Address field is not present; otherwise, it MUST be
18.
Prefix Length
The length of the home network prefix of the included pseudo
home address. When the Pseudo Home Address field is not
present, the Prefix Length field MUST be set as zero.
Reserved
This field is reserved for future use. It MUST be set as zero
by the sender and ignored by the receiver.
Pseudo Home Address
If present, the field contains a pseudo home address that the
mobile node wants to use for location privacy protection or
zero if the mobile node requests a pseudo home address from the
home agent. This field is not present, if the mobile node only
intends to discover whether the home agent supports the
location privacy solutions. The Length field is used to detect
whether the Pseudo Home Address field is present in the Pseudo
Home Address mobility option.
Qiu, et al. Expires May 7, 2009 [Page 43]
Internet-Draft MIP6 location privacy solutions November 2008
7.4. Pseudo Home Address Acknowledgement Mobility Option
This mobility option is included in the mobility header, including
the Binding Acknowledgement message and the Home Test message sent to
the mobile node, and carries zero or one pseudo home address. This
mobility option is used to indicate the status of the pseudo home
address registration and/or whether the home agent supports the
location privacy solutions. The alignment requirement for this
option is 2n. Its format is shown as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix length | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Pseudo Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A unique type for identifying the Pseudo Home Address
Acknowledgement mobility option (to be determined by IANA).
Length
The length of the Pseudo Home Address Acknowledgement mobility
option excluding the Type field and the Length field. It MUST
be 4 when the Pseudo Home Address field is not present;
otherwise, it MUST be 20.
Prefix Length
The length of the home network prefix of the included pseudo
home address. When the Pseudo Home Address field is not
present, the Prefix Length MUST be set as zero.
Status
It indicates the status of the pseudo home address
registration. Values from 0 to 127 indicate success. Higher
Qiu, et al. Expires May 7, 2009 [Page 44]
Internet-Draft MIP6 location privacy solutions November 2008
values indicate failure. The following values are reserved:
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
Reserved
This field is reserved for future use. It MUST be set to zero
by the sender and ignored by the receiver.
Pseudo Home Address
If present, the field contains a pseudo home address that the
home agent registers for the mobile node to use for location
privacy protection. This field is not present, when the home
agent only needs to indicate that it supports the location
privacy solutions as a response to the query from the mobile
node. The Length field is used to detect whether the Pseudo
Home Address field is present in the Pseudo Home Address
Acknowledgement mobility option.
Qiu, et al. Expires May 7, 2009 [Page 45]
Internet-Draft MIP6 location privacy solutions November 2008
8. Security Consideration
The solutions proposed in this document address one of 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 when describing the
solutions. 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
consideration as described in RFC 3775 still apply. Nevertheless, in
the following we provide 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 strength 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.
The home agent can derive the real home address from the received
encrypted home address efficiently due to the use of the symmetric
cryptography algorithm on a small amount of data (in this case, 128
bits), thus the home agent can resist the Denial-of-Service attack
when attackers flood the home agent with forged home Binding Update
messages in order to exhaust CPU resource.
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 malicious mobile node cannot intercept ongoing
sessions of a victim mobile node by registering the same pseudo home
address.
A malicious mobile node may attempt to register a larger number of
pseudo home addresses in order to exhaust the pool of available
pseudo home addresses and to 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 the misuse of the pseudo home address registration is
detected, the home agent can identify the malicious mobile node and
take further actions.
Qiu, et al. Expires May 7, 2009 [Page 46]
Internet-Draft MIP6 location privacy solutions November 2008
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 the cleartext on the HA-CN path, eavesdroppers on such
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,
such as 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
such encrypted (pseudo) home address.
With the proposed location privacy solutions, the Type 2 routing
header is extended to carry the encrypted (pseudo) home address, if
the 'E' bit is set. The same threats specified in RFC 3775 for the
Type 2 routing header are also possible when such routing header
carries the encrypted (pseudo) home address. Similar processing
rules are also used in this document to address such threat: if the
encrypted (pseudo) home address in the Type 2 routing header does not
match with that stored in the Binding Update List entry, the packet
will be dropped.
Qiu, et al. Expires May 7, 2009 [Page 47]
Internet-Draft MIP6 location privacy solutions November 2008
9. Related Work
Our work benefits from previous work and discussion on this topic.
Similar to the concept of the pseudo home address, many drafts 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 3041 [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 about 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 proposed using a temporary identity, called the
Temporary Mobile Identifier (TMI), to replace the home address, and
discussed the feasibility of utilizing the CBID/CGA/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
draft does not specify how to update the TMI to address the profiling
attack.
In [14], the authors proposed a mechanism that uses an identity as
the home address and periodically updates such identity by using a
key and a previous identity as inputs to a cryptography algorithm.
In [15], the authors proposed 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 proposed 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 bi-
directionally tunneling data traffic between the mobile node and such
tunneling agent.
Qiu, et al. Expires May 7, 2009 [Page 48]
Internet-Draft MIP6 location privacy solutions November 2008
10. IANA Consideration
In this document, a new destination option, called the Encrypted Home
Address destination option, is described in Section 7.1. This option
needs a new type assignment from IANA from the IPv6 parameters
registry. Furthermore, two new Mobility Header options, the Pseudo
Home Address mobility option and the Pseudo Home Address
Acknowledgement mobility option, are defined in Section 7.3 and
Section 7.4 respectively. These two options need type assignment
from the Mobility Header options registry.
In addition, this document reserves a bit, called 'E' bit, from the
Reserved field of the Type 2 routing header as described in
Section 7.2.
11. Conclusion
In this document, we 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, if possible. To do so, we
apply cryptography algorithms to encrypt the real home address and
generate the routable pseudo home address, design the new format of
various mobility signaling messages and payload packets, and extend
the functionality of mobility entities. Furthermore, we extensively
discuss the profiling problem, and provide recommendations and
solutions to mitigate the effects of the profiling attack. The
solutions fulfill our requirements and achieve our design goals.
The solutions we 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 no or minor modifications 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 is used with new Mobile IPv6 extensions.
12. Acknowledgement
The authors would like to thank the co-authors of previous drafts
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
Qiu, et al. Expires May 7, 2009 [Page 49]
Internet-Draft MIP6 location privacy solutions November 2008
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.
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", 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. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[11] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", RFC 4882, March 2007.
13.2. Informative References
[12] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
Qiu, et al. Expires May 7, 2009 [Page 50]
Internet-Draft MIP6 location privacy solutions November 2008
[13] Koodli, R., Devarapalli, V., Flinck, H., and C. Perkins,
"Solutions for IP Address Location Privacy in the presence of
IP Mobility", draft-koodli-mip6-location-privacy-solutions-00
(work in progress), February 2005.
[14] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol
for Protecting Movement of Mobile Nodes in Mobile IPv6",
draft-qiu-mip6-mnprivacy-00 (work in progress), March 2005.
[15] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol
for Protecting Movement of Mobile Nodes in Mobile IPv6",
draft-qiu-mip6-hiding-movement-00 (work in progress),
March 2005.
[16] Castelluccia, C., Dupont, F., and G. Montenegro, "Protocol for
Protecting Movement of Mobile Nodes in Mobile IPv6",
draft-dupont-mip6-privacyext-02 (work in progress), July 2005.
[17] Daley, G., "Location Privacy and Mobile IPv6",
draft-daley-mip6-locpriv-00 (work in progress), January 2004.
[18] Weniger, K. and T. Aramaki, "Route Optimization and Location
Privacy using Tunneling Agents (ROTA)", draft-weniger-rota-01
(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 (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work
in progress), November 2007.
[21] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-09 (work in progress),
August 2008.
[22] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P.
Yegani, "Binding Revocation for IPv6 Mobility",
draft-ietf-mext-binding-revocation-01 (work in progress),
August 2008.
[23] Haley, B. and S. Gundavelli, "Mobile IPv6 Generic Signaling
Message", draft-ietf-mext-generic-signaling-message-00 (work in
progress), August 2008.
Qiu, et al. Expires May 7, 2009 [Page 51]
Internet-Draft MIP6 location privacy solutions November 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 IPsec sequence number is used or a new round of
Qiu, et al. Expires May 7, 2009 [Page 52]
Internet-Draft MIP6 location privacy solutions November 2008
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,
e.g., that for protecting the home Binding Update and Acknowledgement
message or for protecting bidirectional-tunneled payload packets.
To resist this kind of the 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 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 such 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 activities of such
mobile node. 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, for example, it
can be any random number generator, and independently chosen by each
end point.
Qiu, et al. Expires May 7, 2009 [Page 53]
Internet-Draft MIP6 location privacy solutions November 2008
A.5. The Regular Interval of Signaling Messages
As described in RFC 3775, certain signaling messages may be exchanged
on the 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 analysis 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 movement of such mobile node.
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, for example, it can be any random number generator. Note
that such algorithm is not needed when the sequence number is
encrypted, for example, in the home Binding Update message 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 such pseudo home address is
masked by different privacy management keys generated during the
return routability procedure with different correspondent nodes.
Because in this way, the encrypted pseudo home addresses used with
different correspondent nodes look different to eavesdroppers.
Qiu, et al. Expires May 7, 2009 [Page 54]
Internet-Draft MIP6 location privacy solutions November 2008
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
deterministicly; 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 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.
Appendix B. Version History
o v01 to v02
* Change the document structure.
* Describe the process in detail how to derive a serials of
secret keys.
* New scheme to protect SPI profiling.
* Use multi home link prefixes to generate pseudoHoA.
* Propose two schemes of transferring the BU message to the HA in
order to match the different protocols (RFC 3776 and IKEv2 in
mobile IP).
o v02 to v03
* Merger section 5.3.1.and 5.3.2 and a same BU process is
employed to the correspondent node regardless initiator or
responder.
Qiu, et al. Expires May 7, 2009 [Page 55]
Internet-Draft MIP6 location privacy solutions November 2008
* Introduce a term of identity address to ensure location privacy
and communication session continuity
o v03 to v04
* Describe and compare the modifications of processing bindings
in more detail.
* Reformat section 5.3.
o v04 to v06
* Revise the algorithm proposed in section 4.
* Update authors information.
o v06 to v07
* Add traffic formats.
* Update the section of IANA requirement.
* Revise according to comments of reviewers Heejin and Vijay.
o v07 to v08
* Re-edit section 1.
* Update authors information.
o v08 to v09
* Revise according to comments of reviewer Michael Welzl.
o v09 to v10
* Re-organize and revise the document.
Qiu, et al. Expires May 7, 2009 [Page 56]
Internet-Draft MIP6 location privacy solutions November 2008
Authors' Addresses
Ying Qiu
Institute for Infocomm Research, Singapore
21 Heng Mui Keng Terrace
Singapore 119613
Phone: +65-6874-6742
Email: qiuying@i2r.a-star.edu.sg
Fan Zhao
Marvell Semiconductor, Inc.
5488 Marvell Lane
Santa Clara, CA 95054
US
Email: fanzhao@marvell.com
Rajeev Koodli
Starent Networks, Corp.
Email: rkoodli@starentnetworks.com
Qiu, et al. Expires May 7, 2009 [Page 57]
Internet-Draft MIP6 location privacy solutions November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
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.
Qiu, et al. Expires May 7, 2009 [Page 58]
| PAFTECH AB 2003-2026 | 2026-04-24 09:06:10 |