One document matched: draft-irtf-mobopts-location-privacy-solutions-09.txt
Differences from draft-irtf-mobopts-location-privacy-solutions-08.txt
Mobopts Working Group Y. Qiu
Internet-Draft Institute for Infocomm Research
Expires: January 15, 2009 F. Zhao
Marvell
R. Koodli
Starent Networks
July 14, 2008
Mobile IPv6 Location Privacy Solutions
draft-irtf-mobopts-location-privacy-solutions-09
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 January 15, 2009.
Qiu, et al. Expires January 15, 2009 [Page 1]
Internet-Draft MIP6 location privacy solutions July 2008
Abstract
Mobile IPv6 (RFC 3775) enables mobile nodes to remain reachable while
roaming on the Internet. However, the location of a mobile node can
be revealed and its movement tracked by simply monitoring the Mobile
IPv6 addresses in the IP packets. In this document, we consider the
MIP6 location privacy problem described in RFC 4882 and propose
efficient and secure techniques to protect the location privacy of a
mobile node. This document is a product of the IP Mobility
Optimizations (MobOpts) Research Group.
Qiu, et al. Expires January 15, 2009 [Page 2]
Internet-Draft MIP6 location privacy solutions July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Brief Overview of Location Privacy in MIP6 . . . . . . . . . . 7
4. Pseudo Home Address Generation Using Return Routability
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Route-Optimized Binding Update to the Correspondent
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Reverse-Tunneled Binding Update to the Correspondent
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Pseudo Home Address Generation Using Cryptography
Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Pseudo Home Address Generation . . . . . . . . . . . . . . 13
5.1.1. Requirements . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. The Shared Key, Kph . . . . . . . . . . . . . . . . . 13
5.1.3. Routable Pseudo Home Address Generation . . . . . . . 14
5.1.4. Dynamic Pseudo Home Address . . . . . . . . . . . . . 14
5.2. Home Binding Updates and Acknowledgements . . . . . . . . 15
5.2.1. Solution with IPsec Transport Mode . . . . . . . . . . 15
5.2.2. Solution with IPsec Tunneling Mode . . . . . . . . . . 16
5.3. Processing of Correspondent Binding Updates . . . . . . . 17
5.3.1. Correspondent Binding Updates Signaling . . . . . . . 17
5.3.2. Modifications to Correspondent Node Binding Updates . 19
5.4. Prefix Discovery . . . . . . . . . . . . . . . . . . . . . 24
6. Profiling Attacks . . . . . . . . . . . . . . . . . . . . . . 25
6.1. The Increment of Sequence Numbers in Correspondent
Binding Updates . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.1. Home Binding Update Procedure . . . . . . . . . . . . . . 27
7.2. Reverse Tunneling Mode . . . . . . . . . . . . . . . . . . 27
7.3. Route Optimization Mode . . . . . . . . . . . . . . . . . 27
7.4. Return Routability Procedure . . . . . . . . . . . . . . . 28
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Profiling Attacks: Discussion . . . . . . . . . . . . 32
A.1. What Invariant Should Be Updated to Resist the
Profiling Attack Effectively? . . . . . . . . . . . . . . 32
A.2. How Often Should These Invariants Be Updated? . . . . . . 32
A.3. What Is the Scope of the Profiling Prevention? . . . . . 33
A.4. The Increment of SPI . . . . . . . . . . . . . . . . . . . 33
Appendix B. Version History . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Qiu, et al. Expires January 15, 2009 [Page 3]
Internet-Draft MIP6 location privacy solutions July 2008
1. Introduction
IP address location privacy is concerned with unwittingly revealing
the current location of a mobile node on the Internet to onlookers
and also, without authorization, to the communicating parties. In
the presence of mobility as defined in Mobile IPv6 [10], there are
two related aspects: disclosing the care-of address to a
correspondent node, and revealing the home address to an
eavesdropper. Care-of Address and Home Address are defined in [10],
as are many other terms used in this document. This document
provides many of those definitions in a following section, but
nevertheless assumes that the reader is familiar with the basic
operation of the Mobile IPv6 protocol.
In order to protect its location privacy, a mobile node must not
disclose the binding between its care-of address and home address.
Related to IP address location privacy is "profiling", where the
activities of a mobile node are linked and then analyzed. The
profiled activities may contribute to compromising a mobile node's
location privacy, especially when combined with additional out-of-
band information. Furthermore, once the location privacy is
compromised, it may lead to more targeted profiling. Therefore, in
addition to protecting IP address location privacy, solutions should
consider how to thwart profiling of various fields, especially those
specific to mobility protocol operations. The location privacy
problem is described in detail in [14].
In this document, we focus on the location privacy related threats
posed by passive attackers. In order to compromise the location
privacy of mobile nodes, these attackers are required to be at
certain locations, for example, an eavesdropper along the paths
traversed by the traffic flows of mobile nodes. The threats posed by
active attackers are beyond the scope of this document. Furthermore,
in order to simplify analysis, we assume that both correspondent
nodes and home agents are fixed nodes. If either is mobile, the same
analysis and solutions for mobile nodes may also apply.
The basic idea is to use a "pseudo home address" to replace the real
home address. One approach is by masking the real home address using
Return Routability parameters to generate the pseudo home address.
This approach, described in Section 4, provides an evolution towards
location privacy based on Return Routability messages which are
already specified in RFC 3775. The other approach to generate the
pseudo home address is by running cryptography algorithms with a pre-
shared secret between the home agent and the mobile node using the
real home address and other information as inputs. This approach,
described in Section 5, can provide stronger cryptographic support at
the cost of some additional operations. Both approaches would
Qiu, et al. Expires January 15, 2009 [Page 4]
Internet-Draft MIP6 location privacy solutions July 2008
securely generate a pseudo home address that is not statistically
correlated to the real home address, and even the potential
commonality of network prefix. Each approach can be implemented on
its own without relying on the other.
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.
The rest of this document is organized as follows. Section 3
presents a brief overview of MIP6 location privacy. The mechanisms
where the pseudo home address is generated using the Return
Routability test and cryptography algorithms are presented in Section
4 and Section 5 respectively. The profiling attacks and related
considerations are addressed in Section 6. Finally we present the
security consideration and summarize related works in sections 7 and
8 respectively.
2. Terminology
Throughout this document we use the commonly adopted terminology
defined in [10] and in [14]. Some of the commonly used terms in this
document are provided below for easier reference.
o Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams on
the Internet
o Correspondent Node (CN): The IPv6 node that communicates with a
MN.
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 Pseudo Home Address (pHoA): A temporary address that is used to
hide the real home address
Qiu, et al. Expires January 15, 2009 [Page 5]
Internet-Draft MIP6 location privacy solutions July 2008
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 CoA and the HoA when no pre-existing security
association exists between a CN and an MN.
o Home Test Init (HoTI) / Home Test (HoT) / Care-of Test Init (CoTI)
/ Care-of Test (CoT): The messages used to perform the return
routability procedure.
o Binding Update (BU): A message used by a mobile node to securely
bind CoA to its HoA at a CN or an HA.
o Binding Acknowledgement (BA): A response to 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 the mobile node and its home agent
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].
Qiu, et al. Expires January 15, 2009 [Page 6]
Internet-Draft MIP6 location privacy solutions July 2008
3. Brief Overview of Location Privacy in MIP6
When using Mobile IPv6, both the home address and the care-of address
are available in the following packets:
o Home Binding Updates and Binding Acknowledgements
o Return Routability packets
o Correspondent Binding Updates and Binding Acknowledgements
o Prefix Discovery messages
o Data packets between mobile nodes and correspondent nodes in the
Route Optimization mode
Hence, correspondent nodes, eavesdroppers and of course the home
agent(s) can learn the complete IP location information
deterministically from a mobile node.
With Route Optimization mode, in order to receive the packets through
the optimized route and protect its location privacy, the mobile node
must disclose its care-of address and conceal the real home address
at the same time. If the mobile node is the initiator of the
communication, it can conceal its home address from both
correspondent nodes and eavesdroppers. When the correspondent node
is the initiator, it may already know the real home address;
therefore, the mobile node can conceal its home address from
eavesdroppers only.
With Reverse Tunneling mode, a mobile node can hide its current
location from its correspondent node and eavesdroppers along the
HA-CN path since the care-of address is invisible on that path. At
the same time, the IPsec tunnel enables the mobile node to conceal
its home address from any eavesdropper along the MN-HA path.
In order to prevent the revealing of the location information of
mobile nodes with Route Optimization mode, the term Pseudo Home
Address is introduced. In the following sections, we propose two
mechanisms to generate the Pseudo Home Addresses. The first,
described in section 4, uses the information of Return Routability
Signaling to hide the home address of a mobile node from
eavesdroppers. The pseudo home address used in this mechansm does
not need to be routable because it is not used during the return
routability procedure, but it cannot avoid revealing of the home
address to the correspondent node during the return routability
procedure. On the other hand, the scheme described in section 5 uses
cryptography algorithms, and can hide the real home address of a
Qiu, et al. Expires January 15, 2009 [Page 7]
Internet-Draft MIP6 location privacy solutions July 2008
mobile node from everyone, even from its correspondent nodes.
Qiu, et al. Expires January 15, 2009 [Page 8]
Internet-Draft MIP6 location privacy solutions July 2008
4. Pseudo Home Address Generation Using Return Routability Signaling
In this section, we describe how to generate a pseudo home address by
making use of information exchanged during the Return Routability
procedure. This could provide an easier transition to location
privacy with MIPv6. In this solution, it is not needed to derive a
pseudo home address with the home agent.
The basic idea is that both the correspondent node and the mobile
node derive a shared privacy management key, Kpm, from the keygen
tokens exchanged in the home address and care-of address test
procedures. Subsequently, the mobile node uses Kpm to hide its home
address in the Binding Update to the correspondent node which
authenticates the received Binding Update and restores the mobile
node's home address therein. We describe this in the following
sections.
4.1. Route-Optimized Binding Update to the Correspondent Node
In the original MIPv6 procedure, the home address is visible in the
Binding Update to the correspondent node. The mobile node can make
the home address invisible to eavesdroppers by replacing the real
home address with a pseudo home address generated as follows.
The mobile node sets a 'P' bit in the reserved field of the HoTI
message to indicate it wishes to use a pseudo home address in place
of the home address.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The correspondent node, if it supports the 'P' bit, computes a
privacy keygen token as follows:
privacy keygen token = First (64, HMAC_SHA1(Kcn(Home Init Cookie |
nonce | 2)))
Qiu, et al. Expires January 15, 2009 [Page 9]
Internet-Draft MIP6 location privacy solutions July 2008
This computation is similar to computing the home keygen token except
that the home address is replaced by the Home Init Cookie which the
mobile node sends in the HoTI message. The privacy keygen token is
returned in the HoT message as a Mobility Header Option along with
the home keygen token. The following figure shows the change.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Home Init Cookie +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ (Home Keygen Token) Privacy Keygen Token +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The care-of address test procedure is exactly the same as specified
in MIP6 protocol [10].
The mobile node computes Kpm and the pseudo home address after the
Return Routability procedure as follows:
Kpm = SHA1 (privacy keygen token | care-of keygen token)
pseudo home address = String XOR HoA
where String = First (128, HMAC_SHA1 (Kpm, (care-of address |
Home nonce index | Care-of nonce index)))
The mobile node then sends the following Binding Update message to
the correspondent node:
o IPv6 header (source = care-of address, destination = correspondent
node)
o Destination Option
* pseudo home address
o Mobility header
* Binding Update = (sequence number, home nonce index, care-of
nonce index, Home Init Cookie)
* First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent |
Binding Update)))
Qiu, et al. Expires January 15, 2009 [Page 10]
Internet-Draft MIP6 location privacy solutions July 2008
The Binding Update MUST include a new Home Init Cookie Mobility
Header option whose format is shown below.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a correspondent node receives a Binding Update with a new
destination option carrying the pseudo home address, it must first
compute Kpm as above. The computation is similar to how it would
compute Kbm, except that the privacy keygen token is computed with
the Home Init Cookie. With Kpm, the correspondent node computes the
String and recovers the home address. It can then compute the home
keygen token and Kbm, and verify the MAC for the Binding Update. If
the Binding Update processing is successful, the pseudo home address
is considered valid. The correspondent node then stores the nonce
indices, and Kbm itself.
The String is computed once by both the mobile node and the
correspondent node, and hence the pseudo home address as computed
above remains constant, until one of the address cookies expires or
the mobile node undergoes a handover.
4.2. Reverse-Tunneled Binding Update to the Correspondent Node
The mobile node may send the Binding Update via the home agent. No
extension to the Return Routability signaling is required with
reverse-tunneled Binding Updates.
The privacy management key Kpm can be the same as the binding
management key Kbm and the mobile node generates the pseudo home
address as follows:
pseudo home address = Enc(Kpm, home address)
Where Enc(.) is a symmetric key encryption algorithm. This
document requres AES as the default encryption algorithm.
The format of the Binding Update to the CN is the same as that in
[10], with the pseudo home address in the destination option. The
Alternate CoA option MUST be present, and MUST contain the MN's CoA.
Qiu, et al. Expires January 15, 2009 [Page 11]
Internet-Draft MIP6 location privacy solutions July 2008
When the correspondent node receives a Binding Update with an
Alternate Care-of Address option and a Pseudo Home Address option, it
first computes Kbm, verifies the MAC for the Binding Update, and then
recovers the home address from the pseudo home address, and verifies
whether it is actually the same home address present as the one in
the source IP address. Only then does it accept the pseudo home
address.
With the reverse-tunneled Binding Update, the home address is visible
as the source IP address along the HA-CN path. However the
eavesdroppers on the HA-CN path can launch an attack to compromise
the Return Routability procedure anyway. So, within the limitations
of the existing Return Routability mechanism, this approach only
requires a new destination option type and the associated processing
to hide the home address from eavesdroppers. In the subsequent data
packets that use the optimized route, only the care-of address and
the pseudo home address are visible.
Qiu, et al. Expires January 15, 2009 [Page 12]
Internet-Draft MIP6 location privacy solutions July 2008
5. Pseudo Home Address Generation Using Cryptography Algorithms
In this section, we present a mechanism to generate the pseudo home
address between the home agent and the mobile node, and we also
illustrate the different packet formats when using this pseudo home
address in the different scenarios. This mechanism can hide the real
home address of a mobile node even from the correspondent nodes.
5.1. Pseudo Home Address Generation
5.1.1. Requirements
The mechanism to generate the pseudo home address needs to fulfill
the following requirements:
o Secure: The attacker must not be able to learn the real home
address from the eavesdropped pseudo home address.
o Routable: When used in the Return Routability procedure, the
pseudo home address must be routable, i.e., this IPv6 address
should use one of home network prefixes.
o Dynamic: To prevent the profiling attack based on the pseudo home
address, it is desired that this pseudo home address can be
updated periodically. Note that the update must not break the
continuity of the current upper layer session(s).
5.1.2. The Shared Key, Kph
The pseudo home address is generated based on a shared secret,
denoted by Kph, between the mobile node and the home agent. As
specified in RFC 3776 [11], IPsec is required to protect the
signaling messages between the mobile node and the home agent; thus
the trust relationship is in the form of an IPsec security
association established either manually or through IKE [6] [7]. If
this security association is manually established, Kph can be
generated from the shared manual key, denoted by Ks, as follows:
Kph = HMAC_SHA1(Ks, 0)
If this security association is established through IKE, Kph is
negotiated and renewed by IKE as well, for example, by running the
quick mode protected by a previously established IKE security
association in phase 2. Either way, Kph is associated with the
relevant security association entry in SAD. The location privacy
protection option can be negotiated between the home agent and the
mobile node. The home agent can distinguish the regular MIP6
signaling packets from those providing the location privacy based on
Qiu, et al. Expires January 15, 2009 [Page 13]
Internet-Draft MIP6 location privacy solutions July 2008
the security association and process them appropriately.
5.1.3. Routable Pseudo Home Address Generation
The mobile node could formulate its real home address in either a
stateful or stateless manner. The computation of a routable pseudo
home address is as follows:
pseudo home address = one of home network prefixes || Enc(Kph,
interface ID)
where Enc(.) can be either a block cipher or a stream cipher
AES is a popular block cipher that takes a 128-bit block as input and
generates a 128-bit block as output. When AES is applied, the mobile
node and the home agent need to append some padding, such as a
sequence of zeros, to the Interface ID since it is typically shorter
than 128 bits. Also only the first n bits from the output of AES are
used so that the pseudo home address is still 128 bit long. If a
stream cipher, such as RC4, is used, the interface ID is masked by a
sequence of random bits, thus no additional padding or trimming is
required. More details regarding how to process inbound and outbound
packets are presented in the following sections.
Note that the home agent should know the length of home network
prefix, for example by looking up a home network prefix table; thus
it can correctly identify the encrypted portion in the pseudo home
address. Also, the mobile node may choose any prefix from all the
available home network prefixes when generating a specific pseudo
home address. Preferably, the mobile node should choose a prefix
which is not used in its real home address.
5.1.4. Dynamic Pseudo Home Address
To update the pseudo home address, the mobile node generates a
sequence of secret keys, {K0, K1, ..., Kn} from Kph and use these
derived keys to generate new pseudo home addresses as follows:
Ki = HMAC_SHA1(Kph, i)
pseudo home address = home network prefix || Enc(Ki, interface ID)
To avoid maintaining a counter between the mobile node and the home
agent, Ki can leverage on the sequence number in the IPsec header.
Ki = HMAC_SHA1(Kph, IPsec sequence number)
Whenever the mobile node sends a new Home Binding Update, it
Qiu, et al. Expires January 15, 2009 [Page 14]
Internet-Draft MIP6 location privacy solutions July 2008
generates a new key with Kph and the current IPsec sequence number as
inputs. As the sequence number in the IPsec header is incremented by
at least one every time, the pseudo home address will look different
to eavesdroppers on the MN-HA path. Also the mobile node and the
home agent do not need to maintain state when generating the pseudo
home address; IPsec anti-replay service, if supported, can detect the
reused pseudo home address. If the home agent does not support the
anti-replay service, for example when a manual key is used, the
mobile node should still use a new sequence number every time;
although an eavesdropper could replay the eavesdropped pseudo home
address, it is not a new vulnerability.
If IKE is used, Kph is updated whenever an IPsec security association
expires. If the lifetime of the IPsec security association is based
on the number of packets sent, given that the extended sequence
number is 64 bits, it is expected that there is no duplicated pseudo
home address within a sufficiently long time period. On the other
hand, if Kph is derived from a manual secret key, the same output of
Enc(Ki, interface ID) may appear after the sequence number wraps
around. However, this is not a new problem, because the output of
Enc(.) (the same length as interface ID) may not be longer than IPsec
extended sequence number.
In summary, the real home address cannot be revealed from the pseudo
home address without the knowledge of Kph, and the pseudo home
address fulfills the requirements of being routable and dynamic.
5.2. Home Binding Updates and Acknowledgements
5.2.1. Solution with IPsec Transport Mode
When the mobile node moves to a new foreign subnet, it sends the
following modified Home Binding Update to its home agent, which
usually happens before any other signaling message is sent.
o IPv6 header (source = care-of address, destination = home agent)
o Destination option header
* Home Address option (pseudo home address)
o ESP header in transport mode
o Mobility header
* Home Binding Update
Qiu, et al. Expires January 15, 2009 [Page 15]
Internet-Draft MIP6 location privacy solutions July 2008
* Alternative Care-of Address option (care-of address)
When the home agent receives the Binding Update from the mobile node,
it first looks up its SAD using SPI, optionally together with IPsec
protocol type and destination IP address. This lookup returns the
established security association between the home agent and the
mobile node. RFC 3776 [11] specifies the corresponding inbound SAD
and SPD entries.
The home agent checks whether this is a replayed packet; if not, it
uses the existing security association to process the received IPsec
packet. The home agent needs to check with its IPsec SPD by using
the real home address as one of selectors. So, the home agent first
recovers the real home address from the received pseudo home address
and applies the rest of the procedure documented in RFC 3776 [11].
The encryption/decryption operation over a small payload (128 bits)
is efficient, and does not cause significant vulnerability to Denial-
of-Service attacks. The home agent should restore the network prefix
associated with the mobile node's real home address if a different
home network prefix is used to generate the pseudo home address.
If it succeeds in the above operations, the home agent stores the
pseudo home address in the home Binding Cache. The organization of
the Binding Cache is extended by adding a new field of pseudo home
address as follows:
+-------------------+------------+---------------+--------+----+---+
|pseudo home address|home address|care-of address|lifetime|seq#|...|
+-------------------+------------+---------------+--------+----+---+
The home agent replies to the mobile node with the Binding
Acknowledgement which contains the pseudo home address in the Type 2
Routng Header. Again, the rules specified in RFC 3776 [11] for the
corresponding outbound SAD and SPD entries are applied on the home
address first. And then the home agent replaces the real home
address with the appropriate pseudo home address.
Compared with the packet formats defined in RFC 3776 [11], the pseudo
home address replaces the real home address. In case that the mobile
node fails to receive the Binding Acknowledgement, it will retransmit
the Binding Update but with a new IPsec sequence number and thus a
new pseudo home address, which prevents the replay attack and the
profiling attack targeting at the pseudo home address.
5.2.2. Solution with IPsec Tunneling Mode
With IKEv2 [7] and the revised IPsec Architecture [3], the Home
Binding Update and Home Binding Acknowledgment use IPsec ESP in
Qiu, et al. Expires January 15, 2009 [Page 16]
Internet-Draft MIP6 location privacy solutions July 2008
tunnel mode. We do not include the header formats for brevity.
When the mobile node returns home, it can use the pseudo home address
or the real home address as the source IP address in the
communication with its home agent, for example, for the de-
registration Binding Update. The packet formats are similar to those
defined in RFC 3776 [11].
5.3. Processing of Correspondent Binding Updates
5.3.1. Correspondent Binding Updates Signaling
When initiating the communication with its correspondent node, the
mobile node sends a HoTI to its home agent in the following format:
o IPv6 header (source = care-of address, destination = home agent)
o ESP header in tunneling mode
o IPv6 header (source = pseudo home address, destination =
correspondent node)
o Mobility header
* HoTI
The mobile node sets a 'Q' bit in the reserved field of the HoTI
message shown in the following figure to indicate that it uses a
pseudo home address generated by cryptography in place of the home
address.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|Q| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The home agent processes the received HoTI message in a similar way
as described in RFC 3776 [11]. It derives the real home address by
Qiu, et al. Expires January 15, 2009 [Page 17]
Internet-Draft MIP6 location privacy solutions July 2008
using the pseudo home address as a key to look up its binding cache
and verify the SPD using the real home address as one of the
selectors. Subsequently, the home agent forwards the HoTI with
pseudo home address as source IP address to the correspondent node.
The correspondent node processes this received HoTI message (using
the pseudo home address as the value for the otherwise present home
address) in the same way as in RFC 3775 [10] and sends the HoT
message addressed to the pseudo home address towards the home agent.
If the 'Q' bit is set, the CN sets a corresponding 'Q'bit in HOT.
This allows the home agent to determine that pseudo home address is
present.
Since the pseudo home address is routable, the HoT message is
forwarded to the home network and intercepted by the home agent.
Upon reception, the home agent uses the pseudo home address as a key
to look up its Binding Cache which returns the real home address of
the mobile node. Then the home agent uses the corresponding security
association to process and forward the HoT message to the mobile
node's pseudo home address.
The care-of address test is exactly the same as specified in RFC 3775
[10].
After receiving both HoT and CoT messages, the mobile node first
computes the binding management Kbm using the care-of keygen token
and the home keygen token (which itself is computed using the pseudo
home address). The Binding Update has an additional field: Enc(Kbm,
invariant-pseudo-HoA), where invariant-pseudo-HoA is the very first
pseudo home address used with the particular correpondent node. This
is necessary because the pseudo home address keeps changing, yet we
need to ensure session continuity. In other words, the invariant
address seen by the upper layer protocols at the correspondent node
is invariant-pseudo-HoA at all times. We explain this further below.
Otherwise, the rest of the fields in the Binding Update is the same
as in RFC 3775.
The following figure shows the new Encrypted invariant-pseudo-HoA
option.
Qiu, et al. Expires January 15, 2009 [Page 18]
Internet-Draft MIP6 location privacy solutions July 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Enc (Kbm, invariant-pseudo-HoA) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
After receiving the Binding Update, the correspondent node first
computes the home keygen token and the care-of keygen token, then
computes Kbm and verifies the MAC. If the MAC is valid, it keeps the
pseudo home address and the invariant-pseudo-HoA in the Binding
Cache. The correspondent node then generates a Binding
Acknowledgement and sends it back to the mobile node's pseudo home
address.
The subsequent data traffic between the mobile node and the
correspondent node will follow the same procedure and the packet
formats as specified in [10] except that the pseudo home address is
used in place of the home address. And, equally importantly, the
correspondent node presents the invariant-pseudo-HoA to the upper
layers.
5.3.2. Modifications to Correspondent Node Binding Updates
In this document, the processing and format of the HoTI/HoT and the
CoTI/CoT messages is the same as the original return routability
protocol; however a pseudo home address and invariant-pseudo-HoA are
proposed. The following subsections analyze the changes in
correspondent node, home agent and mobile node.
5.3.2.1. Modifications on Correspondent Node
A. BINDING CACHE:
Referring to section 9.1 of RFC 3775 [10], each Binding Cache entry
conceptually contains the following fields:
o The home address of the mobile node for which this is the Binding
Cache entry. This field is used as the key for searching the
Qiu, et al. Expires January 15, 2009 [Page 19]
Internet-Draft MIP6 location privacy solutions July 2008
Binding Cache for the destination address of a packet being sent.
o The care-of address for the mobile node indicated by the home
address field in this Binding Cache entry.
o A lifetime value.
o Sequence Number.
We replace the home address by the pseudo HoA in the home address
field. The pseudo HoA is routable and contains the prefix of its
home network. In Section 5.1, we describe the Pseudo Home Address
Generation.
In addition to the original fields, we add a new field invariant-
pseudo-HoA which is used for ensuring the session continuation. The
invariant-pseudo-HoA is the very first pseudo home address that a MN
uses with a particular correspondent. It is typically different for
different correspondent nodes.
B. OPERATION:
In the Binding Update message, we introduce a new option Enc(Kbm,
invariant-pseudo-HoA), where Enc(.) is a symmetric key encryption
algorithm, AES being the default algorithm. Hence the processing of
Binding Update at correspondent nodes is slightly different.
Following is the comparison between the Binding Update process in
original MIPv6 (section 9.5.1, RFC 3775 [10]) and the one with the
additional option specified in this document.
Qiu, et al. Expires January 15, 2009 [Page 20]
Internet-Draft MIP6 location privacy solutions July 2008
original MIPv6 | With additional option
-----------------------------------+--------------------------------
|
1) check the packet MUST contain | the same
a unicast routable home address |
|
2) verify if the Sequence Number | the same
field in the Binding Update is |
greater than the Sequence |
Number received in the previous |
valid Binding Update. |
|
3) validate that a Nonce Indices | the same
mobility option MUST be present |
|
4) the correspondent node MUST | In the network i, we use the
re-generate the home keygen | same pHoA_i in HoTI_i and BU_i
token and the care-of keygen | messages, and CoTI and CoT as
token from the information | usual, so the new method can
contained in the packet. It | generate the valid Kbm and then
then generates the binding | pass the step.
management key Kbm and uses |
it to verify the authenticator |
field in the Binding Update |
|
5) create/update the BU entry | first decrypt the new item
according to the HoA | Enc(Kbm, invariant-pseudo-HoA),
| extract the invariant-pseudo-HoA, then
| create/update the BU entry
| according to the invariant-pseudo-HoA
|
From the comparison, we learn that the only difference is the last
step: how to identify the owner of the binding update . The original
MIPv6 is based on the HoA. The new mechanism with the additional
option needs one more step: decrypting Enc(Kbm, invariant-pseudo-HoA)
first, then create/update the binding update entry based on the
invariant-pseudo-HoA. It is this invariant-pseudo-HoA which is seen
by the upper layer protocols. The following examples illustrate the
usage of invariant-pseudo-HoA.
Consider that a mobile node begins to communicate with CN1 at
network1. Let the pseudo HoA be pHoA1. Then, the invariant-pseudo-
HoA for the CN1 session is the same as pHoA1, i.e., invariant-pseudo-
HoA1=pHoA1. Hence Binding Update 1 to CN1 is BU11 = {src=CoA1,
dest=CN1, opt=pHoA1, original paramaters + Enc(Kbm11, invariant-
pseudo-HoA1)}.
Qiu, et al. Expires January 15, 2009 [Page 21]
Internet-Draft MIP6 location privacy solutions July 2008
Assume that when the mobile node moves to network2, it begins a new
session with CN2. At this time, the pseudo HoA is pHoA2. Then the
invariant-pseudo-HoA for the CN2 session is the same as pHoA2, i.e.
invariant-pseudo-HoA2=pHoA2. The invariant-pseudo-HoA for the CN1
session is still pHoA1, i.e. invariant-pseudo-HoA1=pHoA1, although
the signaling pHoA for both CN1 and CN2 is changed to pHoA2. The
binding update message for CN1 is BU12 = {src=CoA2, dest=CN1,
opt=pHoA2, original parameters + Enc(Kbm12, invariant-pseudo-HoA1)}.
The binding update message for CN2 is BU21 = {src=CoA2, dest=CN2,
opt=pHoA2, orig_payload+Enc(Kbm21, invariant-pseudo-HoA2)}.
When the mobile node is in foreign network i, the signaling pseudo
home address is pHoAi. When the mobile node is moving to foreign
network j, the signaling pseudo home address becomes pHoAj. But the
invariant-pseudo-HoA for CN1 and CN2 are still invariant-pseudo-HoA1
and invariant-pseudo-HoA2 respectively. The binding update message
for CN1 is BU1j = {src=CoAj, dest=CN1, opt=pHoAj, original parameters
+ Enc(Kbm1j, invariant-pseudo-HoA1)}; The binding update message for
CN2 is BU2j = {src=CoAj, dest=CN2, opt=pHoAj, original parameters +
Enc(Kbm2j, invariant-pseudo-HoA2)}.
After the processing of binding update, the CoA is associated with
the invariant-pseudo-HoA (instead of the HoA in original MIP6) in the
binding update cache. Since this invariant-pseudo-HoA remains
constant, there is no change to the processing of forwarding to upper
layers.
The new protocol is no more insecure than original MIPv6 protocol.
As described above, the only difference between new one and original
MIPv6 is the option Enc(Kbm, invariant-pseudo-HoA). Without this new
item, the new proposal is the same as the return routability
procedure of the correspondent code receiving the first binding
update message from the mobile node . The new option is skippable,
and hence a correspondent can ignore the option if it does not
consider session continuity important.
Before decrypting the Enc(Kbm, invariant-pseudo-HoA), the
correspondent code must verify the MAC of the binding update message
and accept the Kbm. This ensures that there are no new flooding
attacks.
5.3.2.2. Modifications on Home Agent
A. BINDING CACHE:
In addition to the original fields, we add a new field the pseudo HoA
and use this field as the key for searching the Binding Cache for the
destination address of a packet being sent.
Qiu, et al. Expires January 15, 2009 [Page 22]
Internet-Draft MIP6 location privacy solutions July 2008
B. OPERATION:
The processing is not different from the original MIPv6 [10], but the
key for searching the binding cache is the pseudo HoA instead of the
real HoA. Section 5.2 describes in detail the processing of home
binding update.
5.3.2.3. Modifications on Mobile Node
A. BINDING UPDATE LIST:
According to section 11.1, RFC3775 [10], each Binding Update List
entry conceptually contains the following fields:
o The IP address of the node to which a Binding Update was sent.
o The home address for which that Binding Update was sent.
o The care-of address sent in that Binding Update. This value is
necessary for the mobile node to determine if it has sent a
Binding Update while giving its new care-of address to this
destination after changing its care-of address.
o The Lifetime field.
o The Sequence Number field.
Since MIPv6 supports multihomed addresses, we add the pseudo home
address to the home address field along with the real home address.
The pseudo home address also has the feature of routability and
contains the prefix of its home network.
Besides the original fields, here, we add new a field invariant-
pseudo-HoA. The invariant-pseudo-HoA is not involved in the HoTI/HoT
and the CoTI/CoT process.
B. OPERATION:
The additional operation is that the mobile node needs to generate a
pseudo home address at every new location and store/update the pseudo
home address in the binding update list. If the mobile node is an
initiator and uses the pseudo address to initiate a communication, it
also keeps the pseudo home address as the invariant-pseudo-HoA in the
binding update list.
Qiu, et al. Expires January 15, 2009 [Page 23]
Internet-Draft MIP6 location privacy solutions July 2008
5.3.2.4. Other Issues
At times, it may be desirable for the mobile node to use different
pseudo home addresses when communicating with different correspondent
nodes. To do so, the mobile node needs to register the new pseudo
home address as the invariant by sending the Home Binding Update
before communicating with a new correspondent node. During the
communication with a specific correspondent node, the mobile node
uses the same invariant-pseudo-HoA. The mobile node typically checks
its Correspondent Binding list to see whether a new pseudo home
address is needed. If the correspondent node appears in the
Correspondent Binding list, the mobile node uses the existing pseudo
home address. Otherwise, the mobile node sends a Home Binding Update
to the home agent. With a new IPsec sequence number, both the home
agent and the mobile node will generate a new pseudo home address for
this correspondent node. The mobile node may extend its
Correspondent Binding list to store the pseudo home address
associated with a correspondent node. When the communication with a
correspondent node is ended, the mobile node may send an explicit de-
registration to the home agent to withdraw the corresponding pseudo
home address. The home agent may also implicitly withdraw the pseudo
home address, for example, when the Return Routability procedure is
not renewed within a certain time period. The strategy to update the
home agent's Binding Cache is beyond the scope of this document.
If the correspondent node is the initiator, the correspondent node
may already know the real home address of the mobile node. When this
is a concern, the mobile node should not publish its home address,
e.g. via DNS. It may be able to make use of runtime binding of user
identity to a dynamic home address, for instance using SIP Proxies.
When the correspondent node contacts the mobile node at its home
address, the mobile node may wish to communicate with the
correspondent node via an optimized route. In this case, the
invariant-pseudo-HoA defaults to the real HoA in the binding update
message to the correspondent node.
5.4. Prefix Discovery
The packet formats are similar to that described in RFC 3776 [11]
except for the use of pseudo home address in place of the real home
address.
Qiu, et al. Expires January 15, 2009 [Page 24]
Internet-Draft MIP6 location privacy solutions July 2008
6. Profiling Attacks
The pseudo home address provides the IP address location privacy;
however, eavesdroppers could still collect, link, and (either online
or offline) analyze the activities of mobile nodes based on certain
observed fields. The more information collected, the higher the
probability to compromise the privacy of mobile nodes becomes, which
in return results in more targeted profiling.
In the presence of mobility, there exist many invariants, such as
fields in the packets and communication patterns, which allows
eavesdroppers to easily correlate the observed activities. For
example, eavesdroppers can use the following information to profile
the activities of mobile nodes.
o On the MN-HA path: the care-of address, the home address, the
pseudo home address, the IPsec sequence number, SPI,
Initialization Vector (IV), the timing of the HoTI messages
o On the HA-CN path: eavesdroppers on this path could intercept the
traffic to or from mobile nodes, thus we do not consider the
threats arising from this path.
o On the MN-CN path: the care-of address, the home address or the
pseudo home address, the sequence number in the Correspondent
Binding Update, the interval of Return Routability packets, etc.
We can see that mobility introduces some fields which can be
profiled, just as fields in other protocol header fields. We have
shown above how to create pseudo home addresses dynamically.
Location Privacy with Mobile IPv6 is primarily concerned with the two
new IP addresses that Mobile IP defines. Whereas profiling is
important, it does not directly lead to compromise in location
privacy the way the two Mobile IP addresses do. In order to thwart
profiling the Mobile IP addresses themselves and the fields in the
Binding Update, existing known mechanisms can be used. In the
following, we only show how to improve safety against the profiling
of Sequence Number field in the binding messages. The appendix
contains a much broader discussion of profiling and means to protect
against it.
6.1. The Increment of Sequence Numbers in Correspondent Binding Updates
RFC 3775 [10] only requires that the sequence number in the Binding
Update is greater than that received in the previous valid Binding
Update for this home address. However, if the increment of sequence
number is fixed, an eavesdropper is able to identify the activities
of mobile node.
Qiu, et al. Expires January 15, 2009 [Page 25]
Internet-Draft MIP6 location privacy solutions July 2008
We propose the increment of sequence number as follows:
o seq#_increment = First(8, HMAC_SHA1(Kbm, home nonce index | care
nonce index))
o If seq#_increment = 0, then set seq#_increment = 1
o Seq# = (previous Seq# + seq#_increment) modulo (2^16)
To avoid causing the sequence number to wrap around quickly and
generate enough randomness, the first 8 bits of the keyed hash
function output are used.
Qiu, et al. Expires January 15, 2009 [Page 26]
Internet-Draft MIP6 location privacy solutions July 2008
7. Security Considerations
This document addresses location privacy in the mobile environment,
location privacy. The proposed solutions do not introduce any new
vulnerability. However, the following security considerations are
identified.
7.1. Home Binding Update Procedure
When the mobile node roams to a new foreign subnet, it sends the
modified Home Binding Update to its home agent and receives the
modified Home Binding Acknowledgement from its home agent. In both
messages, the pseudo home address is used in place of the home
address. Eavesdroppers are unable to derive the real home address
from the pseudo home address and thus to correlate the care-of
address with the home address. Moreover, the pseudo home address can
be updated to prevent eavesdroppers from linking the mobile node's
ongoing activities together.
The home agent can derive the real home address from the received
pseudo home address efficiently because the encryption/decryption
operation is done over a small amount of data (in this case, less
than 128 bits), thus the home agent could resist the Denial-of-
Service attack when attackers flood with the forged Home Binding
Updates.
7.2. Reverse Tunneling Mode
In this mode, the correspondent node sends data packets to the mobile
node's home address, thus it is not aware of the movement of the
mobile node. The home agent intercepts the data packets from the
correspondent node and tunnels them to the mobile node's care-of
address by IPsec ESP tunneling mode. Thus the home address is not
visible to the eavesdroppers on the MN-HA path since the inner IPv6
header is encrypted.
7.3. Route Optimization Mode
In this mode, since the mobile node communicates with the
correspondent node using its care-of address, the mobile node has to
hide its home address from eavesdroppers and even correspondent
nodes. This is accomplished as follows.
If the mobile node is the initiator of the communication with the
correspondent node, it performs the modified Correspondent Binding
Update procedure as described earlier in this document. By replacing
the home address with the pseudo home address in the messages
involved, the binding between the home address and the care-of
Qiu, et al. Expires January 15, 2009 [Page 27]
Internet-Draft MIP6 location privacy solutions July 2008
address is not disclosed to eavesdroppers and the correspondent node,
and the continuity of the current session is kept. If the
correspondent node is the initiator of the communication with the
mobile node, the mobile node also performs the modified Correspondent
Binding Update procedure with the correspondent node. However, the
mobile node can conceal its home address to eavesdroppers only since
the correspondent node already knows its real home address. The same
analysis also applies to the data packets.
7.4. Return Routability Procedure
As the pseudo home address is required to be routable, the extended
Return Routability procedure provides the same security strength as
in RFC 3775 [10].
Qiu, et al. Expires January 15, 2009 [Page 28]
Internet-Draft MIP6 location privacy solutions July 2008
8. Related Work
Our work benefits from previous work and discussion in this area.
Similar to this document, many drafts proposed using a temporary
identity to replace the mobile node's home address in IPsec SA, MIP6
signaling messages and data packets. However, the details of how to
generate and update this identity are absent.
RFC 3041 [12] specifies a mechanism to update a stateless IPv6
address periodically. Although it is possible to update the care-of
address and the home address based on RFC 3041, we further consider
the interval to do so for resisting the profiling attack effectively
and efficiently in the context of mobility.
In [18], the authors proposed using a temporary identity, TMI, to
replace the home address, and also discussed the feasibility of
utilizing the CBID/CGA/MAP to further protect location privacy.
However, as a 128 bit random number, TMI is not suitable to be the
source IP address in the HoTI message forwarded by the home agent to
the correspondent node, because TMI is not routable and the home
agent cannot receive the HoT message from the correspondent node.
Furthermore the draft does not specify how to update TMI or address
profiling attacks.
In [16], the authors proposed to update the identity used as the home
address based on a key and a previous identity. The packet formats
are presented.
In [17], the authors proposed to update the mobile node's home
address periodically to hide the movement. The new identity is
generated from the current local network prefix, the binding update
session key and the previous home address. The new home address is
random, routable, recognizable and recoverable. And the home address
is updated every time when the Return Routability procedure runs.
In [20], the authors proposed an architectural solution, i.e.
reverse-tunneling the traffic to an additional entity, in order to
achieve both route optimization and location privacy at the same
time.
9. IANA Considerations
The document defines a new destination option called pseudo home
address destination option described in Section 4.1, and in
Section 5.1.3. This option needs a new Type assignment from IANA
from the IPv6 parameters registry.
Qiu, et al. Expires January 15, 2009 [Page 29]
Internet-Draft MIP6 location privacy solutions July 2008
The document defines the following new Mobility Header options which
need Type assignment from the Mobility Header options registry: the
Home Initi Cookie option described in Section 4.1 and the Encrypted
invariant-pseudo-HoA option described in Section 5.3.1.
10. Conclusion
In this document, we introduced efficient and secure solutions to
protect location privacy of a mobile node. The central idea is to
use a pseudo home address instead of the mobile node's real home
address in IP packets. It is possible to update this pseudo home
address whenever the mobile node moves to a new location or starts a
communication with a new correspondent node. This results in a
binding between the care-of address and the home address that is
hidden to eavesdroppers or even correspondent nodes in some
scenarios. Moreover, this pseudo home address is routable, thus the
security of the return routability test is not weakened.
11. Acknowledgement
The authors wish to thank the co-authors of previous drafts from
which this draft 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 Wassim Haddad,
Claude Castelluccia, Francis Dupont, Gabriel Montenegro, Greg Daley,
Kilian Weniger and Takashi Aramaki for their valuable contributions
and discussions.
12. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[3] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
Qiu, et al. Expires January 15, 2009 [Page 30]
Internet-Draft MIP6 location privacy solutions July 2008
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[9] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[11] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[12] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[13] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[14] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", RFC 4882, March 2007.
[15] 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.
[16] 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.
[17] 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.
[18] 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.
[19] Daley, G., "Location Privacy and Mobile IPv6",
draft-daley-mip6-locpriv-00 (work in progress), January 2004.
Qiu, et al. Expires January 15, 2009 [Page 31]
Internet-Draft MIP6 location privacy solutions July 2008
[20] Weniger, K. and T. Aramaki, "Route Optimization and Location
Privacy using Tunneling Agents (ROTA)", draft-weniger-rota-01
(work in progress), October 2005.
[21] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture",
draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006.
Appendix A. Profiling Attacks: Discussion
To resist the profiling attack, these invariants need to be updated
periodically. RFC 3041 [12] takes a similar approach to provide the
privacy protection: the IPv6 address is updated over time. In the
context of mobility support, there are the following three specific
issues to be addressed.
A.1. What Invariant Should Be Updated to Resist the Profiling Attack
Effectively?
Different invariants allow eavesdroppers to correlate the observed
activities with the different levels of assurance. Obviously a
constant identity allows eavesdroppers to link the activities of a
mobile node in a deterministic way; and other invariants may be less
reliable because they are affected by different factors. For
example, a malicious entity may profile the traffic based on the
care-of address, however the mobile node may renew its care-of
address via DHCP or IPv6 address privacy extension; the sequence
numbers appearing in the IPsec headers as well as the Correspondent
Binding Updates in one flow may mix with those in another flow; the
timing of MIP6 Return Routability packets is easily affected by the
background traffic and routing dynamics. Nevertheless, these fields
and phenomena provide additional hints to malicious entities. Hence,
it is highly desirable to update the identity of mobile nodes and
other invariants as much as possible.
A.2. How Often Should These Invariants Be Updated?
Generally, the more frequent the update is, the more likely the
profiling attack is prevented and also the higher the costs will be
in terms of communication and processing overheads. As the malicious
entity has many choices to profile the activities, one might consider
updating all the possible invariants with the same frequency because
the granularity of profiling depends on the longest interval of
update. In other words, from the cost-effectiveness perspective, it
is not necessary to update some invariants too frequently if other
invariants cannot be updated so frequently.
Qiu, et al. Expires January 15, 2009 [Page 32]
Internet-Draft MIP6 location privacy solutions July 2008
A.3. What Is the Scope of the Profiling Prevention?
From the perspective of a mobile node, the activities when
communicating with different correspondent nodes should not be
correlated, nor should the different sessions with the same
correspondent node. The former case requires that the mobile node
use different pseudo home addresses when communicating with different
correspondent nodes and the latter case requires that the mobile node
use different pseudo home addresses in the different sessions with
the same correspondent node. If the mobile node performs handover
during the communication with its correspondent node, it is desired
that eavesdroppers near the correspondent node cannot track the
movements of the mobile node. Different levels of the profiling
prevention results in different levels of complexity.
A.4. The Increment of SPI
To prevent eavesdroppers on the MN-HA path from correlating the
packets based on the constant SPI, both the mobile node and the home
agent can update the SPI based on the following method:
o SPI_increment = First(8, HMAC_SHA1(Kph, the current SPI))
o If SPI_increment = 0, then set SPI_increment = 1
o the new SPI = (the current SPI + SPI_increment) modulo (2^32)
The mobile node and the home agent could update the SPI when a Home
Binding Update is sent or received. The new SPI is applied to the
next Home Binding Update procedure.
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).
Qiu, et al. Expires January 15, 2009 [Page 33]
Internet-Draft MIP6 location privacy solutions July 2008
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.
* 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.
Qiu, et al. Expires January 15, 2009 [Page 34]
Internet-Draft MIP6 location privacy solutions July 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 January 15, 2009 [Page 35]
Internet-Draft MIP6 location privacy solutions July 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 January 15, 2009 [Page 36]
| PAFTECH AB 2003-2026 | 2026-04-24 09:07:37 |