One document matched: draft-irtf-mobopts-location-privacy-solutions-06.txt
Differences from draft-irtf-mobopts-location-privacy-solutions-05.txt
Mobopts Working Group Y. Qiu
Internet-Draft Institute for Infocomm Research
Expires: April 14, 2008 F. Zhao
Marvell
R. Koodli
Nokia Research Center
October 12, 2007
Mobile IPv6 Location Privacy Solutions
draft-irtf-mobopts-location-privacy-solutions-06
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 April 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Qiu, et al. Expires April 14, 2008 [Page 1]
Internet-Draft MIP6 location privacy solutions October 2007
Abstract
Mobile IPv6 [10] enables mobile nodes to remain reachable while
roaming on the Internet. With its current specification, the
location of a mobile node can be revealed and its movement can be
tracked by simply monitoring its IP packets. In this document, we
consider the MIP6 location privacy problem described in [14] and
propose efficient and secure techniques to protect the location
privacy of a mobile node.
Qiu, et al. Expires April 14, 2008 [Page 2]
Internet-Draft MIP6 location privacy solutions October 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Brief Overview of Location Privacy in MIP6 . . . . . . . . . . 7
4. Pseudo Home Address Generation Using Return Routability
Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Route-Optimized Binding Update to the Correspondent
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Reverse-Tunneled Binding Update to the Correspondent
Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Pseudo Home Address Generation Using Cryptography
Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Pseudo Home Address Generation . . . . . . . . . . . . . . 11
5.1.1. Requirements . . . . . . . . . . . . . . . . . . . . . 11
5.1.2. The Shared Key, Kph . . . . . . . . . . . . . . . . . 11
5.1.3. Routable Pseudo Home Address Generation . . . . . . . 12
5.1.4. Dynamic Pseudo Home Address . . . . . . . . . . . . . 12
5.2. Home Binding Updates and Acknowledgements . . . . . . . . 13
5.2.1. Solution with IPsec Transport Mode . . . . . . . . . . 13
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. Modification to Correspondent Node Binding Updates . . 20
5.4. Reverse-Tunneling Mode . . . . . . . . . . . . . . . . . . 25
5.5. Prefix Discovery . . . . . . . . . . . . . . . . . . . . . 26
6. Profiling Attack . . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.1. What Invariant should be Updated to Resist the
Profiling Attack Effectively? . . . . . . . . . . . . 28
6.2.2. How Often these Invariants should be Updated? . . . . 29
6.2.3. What is the Scope of the Profiling Prevention? . . . 29
6.3. The Increment of Sequence Numbers in Correspondent
Binding Updates . . . . . . . . . . . . . . . . . . . . . 30
6.4. The Increment of SPI . . . . . . . . . . . . . . . . . . . 30
7. Security Consideration . . . . . . . . . . . . . . . . . . . . 31
7.1. Home Binding Update Procedure . . . . . . . . . . . . . . 31
7.2. Reverse Tunneling Mode . . . . . . . . . . . . . . . . . . 31
7.3. Route Optimization Mode . . . . . . . . . . . . . . . . . 31
7.4. Return Routability Procedure . . . . . . . . . . . . . . . 32
8. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. Version History . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Qiu, et al. Expires April 14, 2008 [Page 3]
Internet-Draft MIP6 location privacy solutions October 2007
Intellectual Property and Copyright Statements . . . . . . . . . . 38
Qiu, et al. Expires April 14, 2008 [Page 4]
Internet-Draft MIP6 location privacy solutions October 2007
1. Introduction
IP address location privacy is about the concern that the location
information of a mobile node is leaked from its IP addresses used
during the communication without authetication. In the presence of
mobility, there are two related aspects: disclosing the care-of
address to a correspondent node, and revealing the home address to an
eavesdropper. 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. 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 the "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. The other approach to generate pseudo home address is by
running cryptography algorithms with a pre-shared secret between the
home agent and the mobile node meanwhile the real home address and
other information as inputs. Both approaches would securely generate
pseudo home address that is not statistically correlated to the real
home address, even the potential commonality of network prefix.
The rest of this document is organized as follows. Section 3
presents a brief overview of MIP6 location privacy. The mechanisms
where 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 section 7 and
8.
Qiu, et al. Expires April 14, 2008 [Page 5]
Internet-Draft MIP6 location privacy solutions October 2007
2. Terminology
Throughout this document we use the commonly adopted terminology
defined in [10] and [14], such as
o Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams
around networks
o Correspondent Node (CN): A Mobile IPv6 that node corresponds with
an MN
o Home Agent: A router on the MN's home network that provides
forwarding support when the MN is roaming
o Home Address (HoA): The MN's unicast IP address valid on its home
network
o Care-of Address (CoA): The MN's unicast IP address valid on the
visited network
o Home Network: The network where the MN is normally present when it
is not roaming
o Visited Network: A network that an MN uses to access the Internet
when it is roaming
o Reverse Tunneling or Bidirectional Tunneling: A mechanism used for
packet forwarding between the MN and its Home Agent
o Route Optimization: A mechanism that allows direct routing of
packets between a roaming MN and its CN, without having to
traverse the home network
o Return Routability Procedure: The return routability procedure
authorizes registrations by the use of a cryptographic token
exchange.
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 April 14, 2008 [Page 6]
Internet-Draft MIP6 location privacy solutions October 2007
3. Brief Overview of Location Privacy in MIP6
The current MIP6 specification does not address location privacy.
For example, 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 without authorization 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 through
certain means; 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. In
the meanwhile, IPsec tunnel enables the mobile node to conceal its
home address from any eavesdropper along the MN-HA path .
Qiu, et al. Expires April 14, 2008 [Page 7]
Internet-Draft MIP6 location privacy solutions October 2007
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. Afterwards, the mobile node uses Kpm to hide its home
address in the Binding Update to the correspondent node, and finally
the correspondent node 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 Return Routability 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. The correspondent node, if it supports the 'P'
bit, computes a privacy keygen token as follows:
privacy keygen token = First (64, Kcn(Home Init Cookie | nonce |
2))
This computation is similar to computing the home keygen token except
that the home address is replaced by the Home Init Cookie which the
MN 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 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)
Qiu, et al. Expires April 14, 2008 [Page 8]
Internet-Draft MIP6 location privacy solutions October 2007
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 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)))
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 address set to all zeros. 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. It may also send a normal
Binding Acknowledgment to the mobile node.
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 not directly to the
correspondent node, but via the home agent. No extension to the
Return Routability signaling packets is required with reverse-
tunneled Binding Updates.
The privacy management key Kpm can be the same as the binding
Qiu, et al. Expires April 14, 2008 [Page 9]
Internet-Draft MIP6 location privacy solutions October 2007
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, for example,
AES.
The format of the Correspondent Binding Update is as follows:
o IPv6 header (source = care-of address, destination = home agent)
o ESP header in tunnel mode
o IPv6 header (source = home address, destination = correspondent
node)
o Destination Option
* pseudo home address
o Mobility header
* Binding Update
* Alternate Care-of Address option (care-of address)
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 source IP
address.
With this mechanism, 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 the 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 take the optimized route, only
the care-of address and the pseudo home address are visible.
Qiu, et al. Expires April 14, 2008 [Page 10]
Internet-Draft MIP6 location privacy solutions October 2007
5. Pseudo Home Address Generation Using Cryptography Algorithms
In this section, we present the mechanism to generate the pseudo home
address between the home agent and the mobile node and illustrate the
different packet formats when using this pseudo home address in the
different scenarios.
5.1. Pseudo Home Address Generation
The mobile node can generate a pseudo home address based on a shared
secret with its home agent and use this pseudo home address to
replace its real home address. When receiving the incoming packets
from the mobile node, the home agent derives the real home address
thereafter and uses the real home address as one of selectors to
check with the local IPsec policy, just like described in RFC 3776
[11]. Afterwards, the home agent updates its Binding Cache to store
the recent pseudo home address in addition to the real home address.
5.1.1. Requirements
The mechanism to generate the pseudo home address needs to fulfill
the following requirements:
o Secure: The attacker could not 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)
Qiu, et al. Expires April 14, 2008 [Page 11]
Internet-Draft MIP6 location privacy solutions October 2007
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 distinuguish the regular MIP6
signaling packets from those providing the location proivacy based on
the security association and process them appropriately.
5.1.3. Routable Pseudo Home Address Generation
The mobile node could formulate its home address in either 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 from all the available
home network prefixes when generating a specific pseudo home address.
Preferably, the mobile node should choose the prefix which is not
used in its real home address.
5.1.4. Dynamic Pseudo Home Address
To update the pseudo home address, one possible way is to generate 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)
Qiu, et al. Expires April 14, 2008 [Page 12]
Internet-Draft MIP6 location privacy solutions October 2007
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
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 some 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 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, it may not be a new problem, because the output of Enc(.)
(the same length as interface ID) may be not longer than IPsec
extened sequece 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.
o IPv6 header (source = care-of address, destination = home agent)
o Destination option header
Qiu, et al. Expires April 14, 2008 [Page 13]
Internet-Draft MIP6 location privacy solutions October 2007
* Home Address option (pseudo home address)
o ESP header in transport mode
o Mobility header
* Home Binding Update
* 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 should return the
established security association between the home agent and the
mobile node. RFC 3776 [11] represents the corresponding inbound SAD
and SPD entries as follows:
o home agent SAD:
SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 && destination = home_agent_1 && proto
= MH
o home agent SPD IN:
IF source = home_address_1 && destination = home_agent_1 &&
proto = MH
THEN USE SA SA1
The home agent checks whether this is a replayed packet; if not, it
uses this security association to process the received IPsec packet.
The home agent also checks with its IPsec SPD by using the home
address as one of selectors. If a block cipher is used to generate
this pseudo home address, the home agent regenerates the pseudo home
address from the real home address retrieved. This procedure is the
same as described before. The home agent compares the output with
the pseudo home address received in the Destination option. If they
match, the home agent accepts this Binding Update message. On the
other hand, if the stream cipher is used, the home agent recovers the
real home address by decrypting the received pseudo home address and
the rest is similar with the procedure documented in RFC 3776 [11].
The encryption/decryption operation over a small payload is
efficient, thus there is no vulnerability to Denial-of-Service
attacks. Note that 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.
Qiu, et al. Expires April 14, 2008 [Page 14]
Internet-Draft MIP6 location privacy solutions October 2007
If it succeeds, 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#|...|
+-------------------+------------+---------------+--------+----+---+
If the pseduo home address is unique in any snapshot of the Binding
Cache, the home agent can look up its Binding Cache by using either
the pseduo home address or the home address.
The home agent replies to the mobile node with the following modified
Home Binding Acknowledgement:
o IPv6 header (source = home agent, destination = care-of address)
o Routing header (type 2)
* pseudo home address
o ESP header in transport mode
o Mobility header
* Home Binding Acknowledgement
RFC 3776 [11] specifies the corresponding outbound SAD and SPD
entries as follows:
o home agent SAD:
SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 && destination = home_address_1 && proto
= MH
o home agent SPD OUT:
IF source = home_agent_1 && destination = home_address_1 &&
proto = MH
THEN USE SA SA2
The detailed procedure is as follows: the home agent generates the
Home Binding Acknowledgement with the mobile node's home address as
the destination IP address, and then this packet is processed based
on the IPsec security association, finally the home agent replaces
Qiu, et al. Expires April 14, 2008 [Page 15]
Internet-Draft MIP6 location privacy solutions October 2007
the real home address with the appropriate pseudo home address. How
the home agent derives the pseudo home address to be used in the Home
Binidng Acknowledgement, especially when the mobile node uses
different pseudo home addresses with different correspondent nodes,
is implementation specific and the details are beyond the scope of
this document. For example, the home agent may record the IPsec
sequence number received in the Home Binding Update and genenrate the
pseudo home address, or the home agent marks the recent
unacknowledged Binding Cache entry and uses the pseudo home address
therein. The home agent can acknowledge the Home Binding Update in
the ascending order of the IPsec sequence number or the time when the
Binding Cache entry is created.
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
The packet formats above follow the fashion in RFC 3776 [11], in the
following we show an alternative that uses the similar packet formats
as in [21]. This is applicable when using IKEv2 [7] and the revised
IPsec Architecture [3].
Binding Update:
o IPv6 header (source = care-of address, destination = home agent)
o ESP header in tunnel mode
o IPv6 header (source = home address, destination = home agent)
o Mobility header
* Home Binding Update
* Alternative Care-of Address option (care-of address)
The home agent processes this Binding Update in the same way as
specified in [21]. Additionally, the home agent uses the retrieved
Kph to generate the pseudo home address and replaces the previous
pseudo home address in respective existing home Binding Cache entry,
if any.
The Binding Acknowledgement format looks as follows:
Qiu, et al. Expires April 14, 2008 [Page 16]
Internet-Draft MIP6 location privacy solutions October 2007
o IPv6 header (source = home agent, destination = care-of address)
o ESP header in tunnel mode
o IPv6 header (source = home agent, destination = home address)
o Mobility header
* Home Binding Acknowledgement
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 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 home agent would process the received HoTI message in a similar
way as described in RFC 3776 [11]. Furthermore, it may derive the
real home address by using pseudo home address as a key to look up
its binding cache and verify the SPD using the real home address as
one of selectors. After that, the home agent generates the following
HoTI and forwards it to the correspondent node:
o IPv6 header (source = pseudo home address, destination =
correspondent node)
o Mobility header
* HoTI
Qiu, et al. Expires April 14, 2008 [Page 17]
Internet-Draft MIP6 location privacy solutions October 2007
The correspondent node processes this received HoTI message in the
same way as in RFC 3775 [10] and sends the following HoT message to
the home agent.
o IPv6 header (source = correspondent node, destination = pseudo
home address)
o Mobility header
* HoT = (home init cookie, home keygen token, home nonce index)
where home keygen token = First (64, HMAC_SHA1(Kcn, (pseudo home
address | nonce | 0))) and Kcn is the correspondent node's local
secret [10].
Since the pseudo home address is routable, the HoT message is
forwarded to the home network and intercepted by the home agent
there. Upon the reception, the home agent uses the pseudo home
address as a key to look up its Binding Cache. The search should
return 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. The packet format is as follows:
o IPv6 header (source = home agent, destination = care-of address)
o ESP header in tunneling mode
o IPv6 header (source = correspondent node, destination = pseudo
home address)
o Mobility header
* HoT = (home init cookie, home keygen token, home nonce index)
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 sends the
Binding Update to the correspondent node in the following format:
o IPv6 header (source = care-of address, destination = correspondent
node)
o Destination Option
* pseudo home address
Qiu, et al. Expires April 14, 2008 [Page 18]
Internet-Draft MIP6 location privacy solutions October 2007
o Mobility header
* Binding Update = (sequence number, home nonce index, care-of
nonce index, Enc(Kbm, identity_address) )
* First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent |
Binding Update)))
where Kbm is the binding management key given by
Kbm = SHA1 (home keygen token | care-of keygen token)
home keygen token = First (64, HMAC_SHA1(Kcn, (pseudo home address
| nonce | 0)))
care-of keygen token = First (64, HMAC_SHA1(Kcn, (CoA | nonce |
1)))
The identity_address ensure that the current session is not broken.
The identity_address could be the real HoA or the first pseudo home
address (pHoA) when established the session.
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 in the Binding Cache. The correspondent node
then generates the following binding acknowledgement and sends back
to the mobile node:
o IPv6 header (source = correspondent node, destination = care-of
address)
o Mobility header
* sequence number (within the Binding Update message header)
* First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent |
BA)))
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.
Data packets from the mobile node to the correspondent node:
o IPv6 header (source = care-of address, destination = correspondent
node)
Qiu, et al. Expires April 14, 2008 [Page 19]
Internet-Draft MIP6 location privacy solutions October 2007
o Destination option
* pseudo home address
o Payload
Data packets from the correspondent node to the mobile node:
o IPv6 header (source = correspondent node, destination = care-of
address)
o Routing Header
* pseudo home address
o Payload
5.3.2. Modification to Correspondent Node Binding Updates
In the proposal, the processing and format of HoTI/HoT and CoTI/CoT
messages is the same as original RR protocol, but use pseudo HoA
instead of real HoA. The subsection analyzes the changes in
correspondent node, home agent and mobile node.
5.3.2.1. Modification on Correspondent Node
A. BINDING CACHE:
Referring to section 9.1, 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
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 routability and with home network prefix.
Section 5.1 described the Pseudo Home Address Generation.
Besides the original fields, we only add a new field --
identity_address that is used for ensuring the session continuation.
Qiu, et al. Expires April 14, 2008 [Page 20]
Internet-Draft MIP6 location privacy solutions October 2007
The identity_address could be the real HoA or the first pseudo HoA
that was used to establish the session.
B. OPERATION:
In the BU payload, we introduce a new optional item Enc(Kbm,
identity_address). So the BU processing in CN is little difference.
Following is the comparison between the BU process in original RR
(section 9.5.1, RFC 3775 [10]) and the one with the additional option
in our proposal.
Original RR | With additional option
-----------------------------------+--------------------------------
|
1) check the packet MUST contain | the same
a unicast routable home address |
|
2) the Sequence Number field in | the same
the Binding Update is greater |
than the Sequence Number |
received in the previous valid |
Binding Update. |
|
3) a Nonce Indices mobility option | the same
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 HoA | Enc(Kbm, identity_address),
| get the identity_address, then
| create/update the BU entry
| according to the identity_address
|
From the comparison, we learn that the only difference is the last
step: how to identify the owner of the BU. The original RR is based
on the HoA. Ours need one more step -- decrypting Enc(Kbm,
Qiu, et al. Expires April 14, 2008 [Page 21]
Internet-Draft MIP6 location privacy solutions October 2007
identity_address) first, then based on the identity_address. The
identity_address could be the real HoA or the first pHoA that is used
to establish the communication session.
Following scenario shows the changes of the visited networks, pseudo
HoAs, identity_addresses and BU messages.
For example, MN began to communicate with CN1 at foreign network1.
At that time, the pseudo HoA is pHoA1. Then identity_address for the
CN1 session is the same as pHoA1, i. e. identity_address1=pHoA1. The
BU11 = {src=CoA1, dest=CN1, opt=pHoA1, orig_payload+Enc(Kbm11,
identity_address1)}.
When MN moves to network2, and then start the connection with CN2.
At this time, the pseudo HoA is pHoA2. Then the identity_addrees for
the CN2 session is the same as pHoA2, i.e. identity_address2=pHoA2.
Meantime, the identity_address for the CN1 session is still pHoA1,
i.e. identity_address1=pHoA1, although the signaling pHoA for both
CN1 and CN2 is changed to pHoA2. The BU message for CN1 is BU12 =
{src=CoA2, dest=CN1, opt=pHoA2, orig_payload+Enc(Kbm12,
identity_address1)}; The BU message for CN2 is BU22 = {src=CoA2,
dest=CN2, opt=pHoA2, orig_payload+Enc(Kbm22, identity_address2)}.
When MN in foreign network i, the signaling pseudo home address is
pHoAi. When MN moving to foreign network j, the signaling pseudo
home address become pHoAj. But the identity_address for CN1 and CN2
are still identity_address1 and identity_address2 respectively. The
BU message for CN1 is BU1j = {src=CoAj, dest=CN1, opt=pHoAj,
orig_payload+Enc(Kbm1j, identity_address1)}; The BU message for CN2
is BU2j = {src=CoAj, dest=CN2, opt=pHoAj, orig_payload+Enc(Kbm2j,
identity_address2)}.
The new protocol is not more insecure than original RR protocol. As
described above, the only difference between new one and original RR
is the optional item Enc(Kbm, identity_address). Without the new
item, the new proposal is the same as RR procedure of CN receiving
the first BU message from MN.
With the new item, CN can also ignore the item if CN does not support
the new proposal or does not care the session continuity.
Before to decrypting the Enc(Kbm, identity_address), CN must verify
the MAC of BU message and accept the Kbm. So the proposal does not
bring new flood attack.
If need much stronger correlation between pHoA and real HoA, we could
send the session Ki (described in section 5.1.4) with HoA together to
CN in encryption, i.e the E(Kbm, HoA|Ki). After decrypting the
Qiu, et al. Expires April 14, 2008 [Page 22]
Internet-Draft MIP6 location privacy solutions October 2007
E(Kbm, HoA|Ki), CN gets HoA and Ki. Then CN can check if pHoA equal
to the home network prefix || Enc(Ki, later 64 bit of real HoA).
Since Ki is just hash value Ki = HMAC_SHA1(Kph, IPsec sequence
number) and CN do not know the seq#, it would not leak the secret
between MN and HA.
5.3.2.2. Modification on Home Agent
A. BINDING CACHE:
Referring to section 10.1 and 9.1, 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
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.
Besides the original fields, we only add a new field for pseudo HoA
and use this field as the key for searching the Binding Cache for the
destination address of a packet being sent.
B. OPERATION:
For correspondent binding update, the processing is no 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 described in
detail the processing of home binding update: verify the pseudo HoA
and store it.
5.3.2.3. Modification 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.
Qiu, et al. Expires April 14, 2008 [Page 23]
Internet-Draft MIP6 location privacy solutions October 2007
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 Lifetime field.
o Sequence Number field.
Since MIPv6 support multi-home addresses, we add the pseudo home
address to the home address field with the real home address
together. The pseudo home address also has the feature of
routability and with home network prefix.
Besides the original fields, here, we also add a field --
identity_address. The identity_address is not involved in HoTI/HoT
and CoTI/CoT process.
B. OPERATION:
The additional operation is that MN needs to generate a pseudo HoA 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 identity_address in the binding update list.
5.3.2.4. Other Issues
Note that it may be desirable for the mobile node 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 identity address by sending the Home Binding
Update before communicating with a new correspondent node. And
during the communication with a specific correspondent node, the
mobile node uses the same identity address. The mobile node usually
can check 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. Note that 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-
Qiu, et al. Expires April 14, 2008 [Page 24]
Internet-Draft MIP6 location privacy solutions October 2007
registration to the home agent to withdraw the corresponding pseudo
home address. The home agnet 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.
The mobile node decides whether a new pseudo home address is needed
or an old pseudo home should be withdrawn based on the communication
activities with the correspondent node. Besides the solution
described above, another way is to leverage on the availability of
upper layer connection information; however it may require an
interface between the IP layer and the upper transport layer.
If the correspondent code as 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
identity address is the real HoA in the binding update message to
correspondent node.
5.4. Reverse-Tunneling Mode
To hide its care-of address from the correspondent node and its home
address from eavesdroppers on the MN-HA path, the mobile node sends
IP data packets via the IPsec-protected reverse tunneling in the
following format.
o IPv6 header (source = care-of address, destination = home agent)
o ESP header in tunnel mode
o IPv6 header (source = home address, destination = correspondent
node)
o data payload
The home agent forwards the data packet to the correspondent node in
the following format.
o IPv6 header (source = home address, destination = correspondent
node)
o data payload
Qiu, et al. Expires April 14, 2008 [Page 25]
Internet-Draft MIP6 location privacy solutions October 2007
The correspondent node replies with the following data packet that
would be intercepted by the home agent.
o IPv6 header (source = correspondent node, destination = home
address)
o data payload
The data packet forwarded by the home agent to the mobile node is as
follows.
o IPv6 header (source = home agent, destination = care-of address)
o ESP header in tunnel mode
o IPv6 header (source = correspondent node, destination = home
address)
o data payload
Note that if the mobile node is the initiator of the communication
with the correspondent node, it may also use the pseudo home address
rather than the real home address in the Reverse Tunneling mode,
which may require the home agent to look up its Binding Cache and to
map the home address to the pseudo home address or the other way
around.
5.5. Prefix Discovery
Similar with that described in RFC 3776 [11], the following packet
format is used for requests for prefixes from the mobile node to the
home agent:
o IPv6 header (source = care-of address, destination = home agent)
o Destination Options header
* Home Address option (pseudo home address)
o ESP header in transport mode
o ICMPv6
* Mobile Prefix Solicitation
Similarly, solicited and unsolicited prefix information
advertisements from the home agent to the mobile node use the
following format:
Qiu, et al. Expires April 14, 2008 [Page 26]
Internet-Draft MIP6 location privacy solutions October 2007
o IPv6 header (source = home agent, destination = care-of address)
o Routing header (type 2)
* pseudo home address
o ESP header in transport mode
o ICMPv6
* Mobile Prefix Advertisement
The packet formats similar with those described in [21] can also be
used.
o IPv6 header (source = care-of address, destination = home agent)
o ESP header in tunnel mode
o IPv6 header (source = home address, destination = home agent)
o ICMPv6
* Mobile Prefix Solicitation
and
o IPv6 header (source = home agent, destination = care-of address)
o ESP header in tunnel mode
o IPv6 header (source = home agent, destination = home address)
o ICMPv6
* Mobile Prefix Advertisement
Qiu, et al. Expires April 14, 2008 [Page 27]
Internet-Draft MIP6 location privacy solutions October 2007
6. Profiling Attack
6.1. Overview
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
probability to compromise the location privacy of mobile nodes, 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, but not limited to,
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 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.
6.2. 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.
6.2.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 other 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
Qiu, et al. Expires April 14, 2008 [Page 28]
Internet-Draft MIP6 location privacy solutions October 2007
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 affetced by the background
traffic and routing dynamics. Nevertheless, these fields and
phenomena provide additional hints to malicious entities. We must
update the identity of mobile nodes and should update other
invariants as much as possible.
6.2.2. How Often these Invariants should be Updated?
Generally, the more frequent the update is, the more likely the
profiling attack is prevented and also the higher costs 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 same frequency because the
granularity of profiling depends on the longest interval of updation.
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.
6.2.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 scope of the profiling
prevention results in different levels of complexity. In the
previous sections, the packet formats when the mobile node uses
different pseudo home addresses when communicating with different
correspondent nodes are described.
It also is worth bearing in mind that attackers must be attached to
certain paths. It seems reasonable to assume that if the mobile node
roams to another foreign subnet, eavesdroppers attaching to the
previous MN-HA and MN-CN paths cannot access the new MN-HA and MN-CN
paths. If this is the case, we only need to consider updating the
invariants when the mobile node stays in the same location.
Qiu, et al. Expires April 14, 2008 [Page 29]
Internet-Draft MIP6 location privacy solutions October 2007
6.3. 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.
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 wrapping around quickly and
generate enough randomness, the first 8 bits of the keyed hash
function output is used.
6.4. The Increment of SPI
To prevent eavesdroppers on the MN-HA path 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.
Qiu, et al. Expires April 14, 2008 [Page 30]
Internet-Draft MIP6 location privacy solutions October 2007
7. Security Consideration
This document addresses a security issue in the mobile environment,
location privacy. The proposed solutions do not introduce any new
vulnerability.
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 is 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 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 either 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 in section 3. By replacing the home
address with the pseudo home address in the messages involved, the
binding between the home address and the care-of address is not
disclosed to eavesdroppers and the correspondent node. And the
Qiu, et al. Expires April 14, 2008 [Page 31]
Internet-Draft MIP6 location privacy solutions October 2007
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 after the first contact. The
mobile node can conceal its home address to eavesdroppers only since
the correspondent node already knows its real home address. Note 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 modified
Return Routability procedure provides the same security strength as
in RFC 3775 [10].
Qiu, et al. Expires April 14, 2008 [Page 32]
Internet-Draft MIP6 location privacy solutions October 2007
8. Related Work
Our work benefits from previous works and discussions. Similar with
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 additional identity are absent.
RFC 3041 [12] specifies the 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 shortest interval to do so in order to resist the profiling
attack effectively and efficiently.
The draft [18] proposes using a temporary identity, TMI, to replace
the home address in the scenarios of mobile client and mobile server,
and also discussed the feasibility of utilizing CBID/CGA/MAP to
further protect the 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.
The draft [16] proposes to update the identity based on a key and a
previous identity. The packet formats are presented.
The draft [17] proposes 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. Also it seems that the home
address is updated as frequently as the Return Routeability
procedure.
The draft [20] intends to achieve both route optimization and
location privacy at the same time. The proposed solution is to
reverse-tunnel the traffic to an additional entity. This kind of
architectural solution achieves only the recoverable location privacy
instead.
9. IANA Considerations
This document may specify IANA Type assignment(s) in subsequent
versions.
Qiu, et al. Expires April 14, 2008 [Page 33]
Internet-Draft MIP6 location privacy solutions October 2007
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 of this mobile node. 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 the binding between the care-of address and the home
address is hidden to eavesdroppers or even correspondent nodes in
some scenarios. Moreover, this pseudo home address is routable, thus
the security of this proposed return routeability test is not
weakened.
We intend to make the best tradeoffs among many related factors
during the design. Also we present the thorough analyses of MIP6
location privacy issues and also some best practices to enhance the
location privacy. This would help design alternative solutions when
a different tradeoff is desired. Furthermore, the mobile node may
also desire to hide its movement to the home agent in some cases; the
details are beyond the scope of this document.
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.
Qiu, et al. Expires April 14, 2008 [Page 34]
Internet-Draft MIP6 location privacy solutions October 2007
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[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.
Qiu, et al. Expires April 14, 2008 [Page 35]
Internet-Draft MIP6 location privacy solutions October 2007
[19] Daley, G., "Location Privacy and Mobile IPv6",
draft-daley-mip6-locpriv-00 (work in progress), January 2004.
[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. 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 BU message to 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.
* Introduce a term of identity address to ensure location privacy
and communication session continuity
o v03 to v04
* Describe and compare the modification of processing bindings in
more detail.
* Reformat section 5.3.
o v04 to v06
Qiu, et al. Expires April 14, 2008 [Page 36]
Internet-Draft MIP6 location privacy solutions October 2007
* Revise the algorithm proposed in section 4.
* Update authors information.
Authors' Addresses
Ying Qiu
Institute for Infocomm Research
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
Phone:
Email: fanzhao@marvell.com
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
US
Email: rajeev.koodl@nokia.com
Qiu, et al. Expires April 14, 2008 [Page 37]
Internet-Draft MIP6 location privacy solutions October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Qiu, et al. Expires April 14, 2008 [Page 38]
| PAFTECH AB 2003-2026 | 2026-04-24 10:41:43 |