One document matched: draft-irtf-mobopts-location-privacy-solutions-07.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<!-- ?rfc strict="yes"? -->
<rfc ipr='full3978' docName='draft-irtf-mobopts-location-privacy-solutions-07'>
<!---------------------------------------------------------------------------->
<!-- FRONT: Title, Authors, Abstract ----------------------------------------->
<!---------------------------------------------------------------------------->
<front>
<title abbrev='MIP6 location privacy solutions'>
Mobile IPv6 Location Privacy Solutions
</title>
<author initials="Y." surname="Qiu" fullname="Ying Qiu">
<organization abbrev="Institute for Infocomm Research">
Institute for Infocomm Research
</organization>
<address>
<postal>
<street>21 Heng Mui Keng Terrace</street>
<city>Singapore</city>
<code>119613</code>
</postal>
<phone>+65-6874-6742</phone>
<email>qiuying@i2r.a-star.edu.sg</email>
</address>
</author>
<author initials="F." surname="Zhao" fullname="Fan Zhao">
<organization abbrev="Marvell">
Marvell Semiconductor, Inc.
</organization>
<address>
<postal>
<street>5488 Marvell Lane</street>
<city>Santa Clara</city> <region>CA</region>
<code>95054</code>
<country>US</country>
</postal>
<phone> </phone>
<email>fanzhao@marvell.com</email>
</address>
</author>
<author initials="R." surname="Koodli" fullname="Rajeev Koodli">
<organization abbrev=" ">
</organization>
<address>
<email>Rajeev.Koodli@gmail.com</email>
</address>
</author>
<date month="February" year="2008" />
<area>Internet</area>
<workgroup>Mobopts Working Group</workgroup>
<keyword>MIP6</keyword>
<keyword>Location Privacy</keyword>
<abstract>
<t>
Mobile IPv6 <xref target="RFC3775"/> 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 <xref target="RFC4882"/> and propose efficient and secure techniques
to protect the location privacy of a mobile node.
</t>
</abstract>
</front>
<!---------------------------------------------------------------------------->
<!-- MIDDLE: Main Text ------------------------------------------------------->
<!---------------------------------------------------------------------------->
<middle>
<!---------------------------------------------------------------------------->
<!-- SECTION 1: INTRODUCTION ------------------------------------------------>
<!---------------------------------------------------------------------------->
<section anchor='sec:intro'
title="Introduction">
<t> 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 authentication. 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 <xref target="RFC4882"/>.
</t>
<t> 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.
</t>
<t>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. 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 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 securely generate 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.
</t>
<t>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.
</t>
</section> <!-- EndSect: INTRODUCTION -->
<?rfc compact="yes"?>
<section anchor='sec:term'
title="Terminology">
<t>Throughout this document we use the commonly adopted terminology defined in
<xref target="RFC3775"/> and <xref target="RFC4882"/>, such as
</t>
<list style="symbols">
<t>Mobile Node (MN): A Mobile IPv6 Mobile Node that freely roams around networks</t>
<t>Correspondent Node (CN): A Mobile IPv6 node that corresponds with an MN</t>
<t>Home Agent: A router on the MN's home network that provides forwarding support when the MN is roaming</t>
<t>Home Address (HoA): The MN's unicast IP address valid on its home network</t>
<t>Care-of Address (CoA): The MN's unicast IP address valid on the visited network</t>
<t>Home Network: The network where the MN is normally present when it is not roaming</t>
<t>Visited Network: The network that the MN uses to access the Internet when it is roaming</t>
<t>Reverse Tunneling or Bidirectional Tunneling: A mechanism used for packet forwarding
between the MN and its Home Agent</t>
<t>Route Optimization: A mechanism that allows direct routing of packets between a roaming
MN and its CN, without having to traverse the home network</t>
<t>Return Routability Procedure: The return routability procedure authorizes registrations
by the use of a cryptographic token exchange.</t>
</list>
<t>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 <xref target="RFC2119"/>.
</t>
</section> <!-- EndSect: TERMINOLOGY -->
<?rfc compact="no"?>
<!---------------------------------------------------------------------------->
<!-- SECTION: Brief Overview of Location Privacy in MIP6 ------------------->
<!---------------------------------------------------------------------------->
<section anchor='sec:overview'
title="Brief Overview of Location Privacy in MIP6">
<t> 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:
<list style="symbols">
<t>Home Binding Updates and Binding Acknowledgements</t>
<t>Return Routability packets</t>
<t>Correspondent Binding Updates and Binding Acknowledgements</t>
<t>Prefix Discovery messages</t>
<t>Data packets between mobile nodes and correspondent nodes in the Route Optimization mode</t>
</list>
</t>
<t>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.
</t>
<t> 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.
</t>
<t>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 .
</t>
<t> In order to prevent the revealing of the location information of moving mobile nodes with Route Optimization mode, the term of Pseudo Home Address is introduced. Following we will propose two schemes to generate the Pseudo Home Addresses. The first scheme described in section 4, which uses the information of Return Routability Signaling, can hide the home address of a mobile node from eavesdroppers and the pseudo home address does not need to be routable because it is not used during RR procedure, but it cannot avoid revealing of the home address to CN during RR procedure. On the other hand, the later scheme described in section 5, which uses cryptography algorithms, can hide the real home address of a mobile node from everyone, even from its correspondent nodes.
</t>
</section> <!-- EndSect: BRIEF OVERVIEW OF LOCATION PRIVACY IN MIP6 -->
<!--------------------------------------------------------------------------->
<!-- SECTION: Location Privacy using Return Routability Signaling ---------->
<!--------------------------------------------------------------------------->
<section anchor='sec:lprr'
title="Pseudo Home Address Generation Using Return Routability Signaling">
<t>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.
</t>
<t>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.
</t>
<section anchor='sec:lprr:ro'
title="Route-Optimized Binding Update to the Correspondent Node">
<t>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.
</t>
<t>The mobile node sets a 'P' bit in the reserved field of the HoTI message showed as following figure to indicate
it wishes to use a pseudo home address in place of the home address. </t>
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The correspondent node, if it supports the 'P' bit, computes a privacy keygen token as follows:
<list style="empty">
<t>privacy keygen token = First (64, MAC_SHA1(Kcn(Home Init Cookie | nonce | 2)))</t>
</list>
</t>
<t>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. Following figure shows the change.
</t>
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Nonce Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Home Init Cookie +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ (Home Keygen Token) Privacy Keygen Token +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The care-of address test procedure is exactly the same as specified in MIP6 protocol <xref target="RFC3775"/>.
</t>
<t>The mobile node computes Kpm and the pseudo home address after the Return Routability procedure as follows:
<list style="empty">
<t>Kpm = SHA1 (privacy keygen token | care-of keygen token)</t>
<t>pseudo home address = String XOR HoA
<list style="empty">
<t>where String = First (128, HMAC_SHA1 (Kpm, (care-of address | Home nonce index | Care-of nonce index)))</t>
</list>
</t>
</list>
</t>
<t>The mobile node then sends the following Binding Update to the correspondent node:
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = correspondent node)</t>
<t>Destination Option
<list style="symbols">
<t>pseudo home address</t>
</list>
</t>
<t>Mobility header
<list style="symbols">
<t>Binding Update = (sequence number, home nonce index, care-of nonce index, Home Init Cookie)</t>
<t>First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | Binding Update)))</t>
</list>
</t>
</list>
Following figure shows the binding update format with 'P' bit.
</t>
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ privacy factor: Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>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 with an extra item of
the pseudo HoA to the mobile node.
</t>
<t>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.
</t>
</section>
<section anchor='sec:lprr:rtm'
title="Reverse-Tunneled Binding Update to the Correspondent Node">
<t>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.
</t>
<t>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:
<list style="empty">
<t>pseudo home address = Enc(Kpm, home address)</t>
<t>Where Enc(.) is a symmetric key encryption algorithm, for example, AES.</t>
</list>
</t>
<t>The format of the Correspondent Binding Update is as follows:
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = home agent)</t>
<t>ESP header in tunnel mode</t>
<t>IPv6 header (source = home address, destination = correspondent node)</t>
<t>Destination Option
<list style="symbols">
<t>pseudo home address</t>
</list>
</t>
<t>Mobility header
<list style="symbols">
<t>Binding Update</t>
<t>Alternate Care-of Address option (care-of address)</t>
</list>
</t>
</list>
</t>
<t>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.
</t>
<t>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.
</t>
<t>In the subsequent data packets that take the optimized route, only the care-of address and
the pseudo home address are visible.
</t>
</section>
</section>
<!---------------------------------------------------------------------------->
<!-- SECTION: IP ADDRESS LOCATION PRIVACY WITH PSEUDO HOME ADDRESS ---------->
<!-- title="IP Address Location Privacy with Pseudo Home Address" --->
<!---------------------------------------------------------------------------->
<section anchor='sec:ipaddr'
title="Pseudo Home Address Generation Using Cryptography Algorithms">
<t>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. Due to
employing cryptography algorithms, this scheme can provide stronger cryptographic
support and the real home address of a mobile node can be hidden from everyone,
even from its correspondent nodes.
</t>
<section anchor='sec:ipaddr:phoa_gen'
title="Pseudo Home Address Generation">
<t>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 <xref target="RFC3776"/>. Afterwards, the home agent updates its Binding
Cache to store the recent pseudo home address in addition to the real home address.
</t>
<section anchor='sec:ipaddr:phoa_gen:requirements'
title="Requirements">
<t>The mechanism to generate the pseudo home address needs to fulfill the
following requirements:
<list style="symbols">
<t>Secure: The attacker could not learn the real home address from the
eavesdropped pseudo home address.</t>
<t>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.</t>
<t>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).</t>
</list>
</t>
</section>
<section anchor='sec:ipaddr:phoa_gen:key'
title="The Shared Key, Kph">
<t>
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 <xref target="RFC3776"/>, 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 <xref target="RFC2409"/> <xref target="RFC4306"/>. If this security association
is manually established, Kph can be generated from the shared manual key, denoted
by Ks, as follows:
<list style="empty">
<t>Kph = HMAC_SHA1(Ks, 0)</t>
</list>
</t>
<t>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 the security association and process them
appropriately.
</t>
</section>
<section anchor='sec:ipaddr:phoa_gen:routable'
title="Routable Pseudo Home Address Generation">
<t>
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:
<list style="empty">
<t>pseudo home address = one of home network prefixes || Enc(Kph, interface ID)</t>
<t>where Enc(.) can be either a block cipher or a stream cipher</t>
</list>
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor='sec:ipaddr:phoa_gen:dynamic'
title="Dynamic Pseudo Home Address">
<t>
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:
<list style="empty">
<t>Ki = HMAC_SHA1(Kph, i)</t>
<t>pseudo home address = home network prefix || Enc(Ki, interface ID)</t>
</list>
</t>
<t>To avoid maintaining a counter between the mobile node and the home agent, Ki can
leverage on the sequence number in the IPsec header.
<list style="empty">
<t>Ki = HMAC_SHA1(Kph, IPsec sequence number)</t>
</list>
</t>
<t>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.
</t>
<t>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 extended sequence number.
</t>
<t>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.
</t>
</section>
</section>
<section anchor='sec:ipaddr:home_bu'
title="Home Binding Updates and Acknowledgements">
<section anchor='sec:ipaddr:home_bu:transport'
title="Solution with IPsec Transport Mode">
<t>
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.
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = home agent)</t>
<t>Destination option header
<list style="symbols">
<t>Home Address option (pseudo home address)</t>
</list>
</t>
<t>ESP header in transport mode</t>
<t>Mobility header
<list style="symbols">
<t>Home Binding Update</t>
<t>Alternative Care-of Address option (care-of address)</t>
</list>
</t>
</list>
</t>
<t>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 <xref target="RFC3776"/> represents the corresponding inbound SAD and SPD entries as follows:
<list style="symbols">
<t>home agent SAD:
<list style="empty">
<t>SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):</t>
<t>source = home_address_1 && destination = home_agent_1 && proto = MH</t>
</list>
</t>
<t>home agent SPD IN:
<list style="empty">
<t>IF source = home_address_1 && destination = home_agent_1 && proto = MH</t>
<t>THEN USE SA SA1</t>
</list>
</t>
</list>
</t>
<t>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 <xref target="RFC3776"/>. 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.
</t>
<t>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:
</t>
<figure>
<artwork>
+-------------------+------------+---------------+--------+----+---+
|pseudo home address|home address|care-of address|lifetime|seq#|...|
+-------------------+------------+---------------+--------+----+---+
</artwork>
</figure>
<t>If the pseudo 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.
</t>
<t>The home agent replies to the mobile node with the following modified Home
Binding Acknowledgement:
<list style="symbols">
<t>IPv6 header (source = home agent, destination = care-of address)</t>
<t>Routing header (type 2)
<list style="symbols">
<t>pseudo home address</t>
</list>
</t>
<t>ESP header in transport mode</t>
<t>Mobility header
<list style="symbols">
<t>Home Binding Acknowledgement</t>
</list>
</t>
</list>
</t>
<t>RFC 3776 <xref target="RFC3776"/> specifies the corresponding outbound SAD and SPD entries as follows:
<list style="symbols">
<t>home agent SAD:
<list style="empty">
<t>SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):</t>
<t>source = home_agent_1 && destination = home_address_1 && proto = MH</t>
</list>
</t>
<t>home agent SPD OUT:
<list style="empty">
<t>IF source = home_agent_1 && destination = home_address_1 && proto = MH</t>
<t>THEN USE SA SA2</t>
</list>
</t>
</list>
</t>
<t>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 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 Binding
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 generate 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.
</t>
<t>Compared with the packet formats defined in RFC 3776 <xref target="RFC3776"/>, 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.
</t>
</section>
<section anchor='sec:ipaddr:home_bu:tunnel'
title="Solution with IPsec Tunneling Mode">
<t>The packet formats above follow the fashion in RFC 3776 <xref target="RFC3776"/>, in the following we show
an alternative that uses the similar packet formats as in <xref target="I-D.draft-ietf-mip6-ikev2-ipsec"/>.
This is applicable when using IKEv2 <xref target="RFC4306"/> and the revised IPsec Architecture <xref target="RFC4301"/>.
</t>
<t>Binding Update:
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = home agent)</t>
<t>ESP header in tunnel mode</t>
<t>IPv6 header (source = home address, destination = home agent)</t>
<t>Mobility header
<list style="symbols">
<t>Home Binding Update</t>
<t>Alternative Care-of Address option (care-of address)</t>
</list>
</t>
</list>
</t>
<t>The home agent processes this Binding Update in the same way as specified in <xref target="I-D.draft-ietf-mip6-ikev2-ipsec"/>. 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.
</t>
<t>The Binding Acknowledgement format looks as follows:
<list style="symbols">
<t>IPv6 header (source = home agent, destination = care-of address)</t>
<t>ESP header in tunnel mode</t>
<t>IPv6 header (source = home agent, destination = home address)</t>
<t>Mobility header
<list style="symbols">
<t>Home Binding Acknowledgement</t>
</list>
</t>
</list>
</t>
<t>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 <xref target="RFC3776"/>.
</t>
</section>
</section>
<section anchor='sec:ipaddr:rr'
title="Processing of Correspondent Binding Updates">
<section anchor='sec:ipaddr:rr:msg'
title="Correspondent Binding Updates Signaling">
<t>When initiating the communication with its correspondent node, the mobile node sends HoTI to
its home agent in the following format:
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = home agent)</t>
<t>ESP header in tunneling mode</t>
<t>IPv6 header (source = pseudo home address, destination = correspondent node)</t>
<t>Mobility header
<list style="symbols">
<t>HoTI</t>
</list>
</t>
</list>
</t>
<t>The mobile node sets a 'Q' bit in the reserved field of the HoTI message showed in following figure to indicate
it uses a pseudo home address generated by cryptography in place of the home address. </t>
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|Q| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The home agent would process the received HoTI message in a similar way as described in
RFC 3776 <xref target="RFC3776"/>. 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:
<list style="symbols">
<t>IPv6 header (source = pseudo home address, destination = correspondent node)</t>
<t>Mobility header
<list style="symbols">
<t>HoTI</t>
</list>
</t>
</list>
</t>
<t>The correspondent node processes this received HoTI message in the same way as in RFC 3775 <xref target="RFC3775"/>
and sends the following HoT message to the home agent.
<list style="symbols">
<t>IPv6 header (source = correspondent node, destination = pseudo home address)</t>
<t>Mobility header
<list style="symbols">
<t>HoT = (home init cookie, home keygen token, home nonce index)</t>
</list>
</t>
</list>
</t>
<t>where home keygen token = First (64, HMAC_SHA1(Kcn, (pseudo home address | nonce | 0)))
and Kcn is the correspondent node's local secret <xref target="RFC3775"/>.
</t>
<t>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:
<list style="symbols">
<t>IPv6 header (source = home agent, destination = care-of address)</t>
<t>ESP header in tunneling mode</t>
<t>IPv6 header (source = correspondent node, destination = pseudo home address)</t>
<t>Mobility header
<list style="symbols">
<t>HoT = (home init cookie, home keygen token, home nonce index)</t>
</list>
</t>
</list>
</t>
<t>The care-of address test is exactly the same as specified in RFC 3775 <xref target="RFC3775"/>. </t>
<t>After receiving both HoT and CoT messages, the mobile node sends the Binding Update to the
correspondent node in the following format:
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = correspondent node)</t>
<t>Destination Option
<list style="symbols">
<t>pseudo home address</t>
</list>
</t>
<t>Mobility header
<list style="symbols">
<t>Binding Update = (sequence number, home nonce index, care-of nonce index, Enc(Kbm, identity_address) )</t>
<t>Binding Authorization Data = First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | Binding Update)))</t>
</list>
</t>
</list>
</t>
<t>where Kbm is the binding management key given by
<list style="empty">
<t>Kbm = SHA1 (home keygen token | care-of keygen token)</t>
<t>home keygen token = First (64, HMAC_SHA1(Kcn, (pseudo home address | nonce | 0)))</t>
<t>care-of keygen token = First (64, HMAC_SHA1(Kcn, (CoA | nonce | 1)))</t>
</list>
</t>
<t>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.
Following figure shows the binding update format with 'Q' bit.
</t>
<figure>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|P|Q| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ privacy factor: Enc(Kbm, identity_address) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>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:
<list style="symbols">
<t>IPv6 header (source = correspondent node, destination = care-of address)</t>
<t>Mobility header
<list style="symbols">
<t>Binding Acknowledgement = sequence number (within the Binding Update message header)</t>
<t>Binding Authorization Data = First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent | BA)))</t>
</list>
</t>
</list>
</t>
<t>The subsequent data traffic between the mobile node and the correspondent node will follow the same
procedure and the packet formats as specified in <xref target="RFC3775"/> except that the pseudo home address is used in
place of the home address.</t>
<t>Data packets from the mobile node to the correspondent node:
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = correspondent node)</t>
<t>Destination option
<list style="symbols">
<t>pseudo home address</t>
</list>
</t>
<t>Payload</t>
</list>
</t>
<t>Data packets from the correspondent node to the mobile node:
<list style="symbols">
<t>IPv6 header (source = correspondent node, destination = care-of address)</t>
<t>Routing Header
<list style="symbols">
<t>pseudo home address</t>
</list>
</t>
<t>Payload</t>
</list>
</t>
</section>
<section anchor='sec:ipaddr:rr:modi'
title="Modifications to Correspondent Node Binding Updates">
<t>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.
</t>
<section anchor='sec:ipaddr:rr:modi:CN'
title="Modifications on Correspondent Node">
<t>A. BINDING CACHE:</t>
<t>Referring to section 9.1, RFC 3775 <xref target="RFC3775"/>, each Binding Cache entry conceptually contains the following fields:
</t>
<list style="symbols">
<t>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.</t>
<t>The care-of address for the mobile node indicated by the home address field in this Binding Cache entry.</t>
<t>A lifetime value.</t>
<t>Sequence Number.</t>
</list>
<t>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.
</t>
<t>Besides the original fields, we only add a new field -- identity_address that is used for ensuring the session continuation. The identity_address could be the real HoA or the first pseudo HoA that was used to establish the session.
</t>
<t><vspace blankLines='1' /></t>
<t>B. OPERATION:</t>
<t>In the BU payload, we introduce a new optional item Enc(Kbm, identity_address), where Enc(.) is a symmetric key encryption algorithm, for example, AES. So the BU processing in CN is little difference. Following is the comparison between the BU process in original MIPv6 (section 9.5.1, RFC 3775 <xref target="RFC3775"/>) and the one with the additional option in our proposal.
</t>
<figure>
<artwork>
original MIPv6 | 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
|
</artwork>
</figure>
<t>From the comparison, we learn that the only difference is the last step: how to identify the owner of the BU. The original MIPv6 is based on the HoA. Ours need one more step -- decrypting Enc(Kbm, 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.
</t>
<t>Following scenario shows the changes of the visited networks, pseudo HoAs, identity_addresses and BU messages.
</t>
<t>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)}.
</t>
<t>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)}.
</t>
<t>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)}.
</t>
<t>After the processing of BU, the CoA is associated with the identity_address (instead of the HoA in original MIP6) in BU cache. The identity_address could be the HoA, or the first pHoA when set up a communication session. So the proposal is not change the processing of forwarding a packet to upperlayer .
</t>
<t>The new protocol is not more insecure than original MIPv6 protocol. As described above, the only difference between new one and original MIPv6 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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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 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).
</t>
<t>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.
</t>
<t></t>
</section>
<section anchor='sec:ipaddr:rr:modi:HA'
title="Modifications on Home Agent">
<t>A. BINDING CACHE:</t>
<t>Referring to section 10.1 and 9.1, RFC 3775 <xref target="RFC3775"/>, each Binding Cache entry conceptually contains the following fields:
</t>
<list style="symbols">
<t>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.</t>
<t>The care-of address for the mobile node indicated by the home address field in this Binding Cache entry.</t>
<t>A lifetime value.</t>
<t>Sequence Number.</t>
</list>
<t>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.
</t>
<t><vspace blankLines='1' /></t>
<t>B. OPERATION:</t>
<t>For correspondent binding update, the processing is not different from the original MIPv6 <xref target="RFC3775"/>, 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.
</t>
<t></t>
</section>
<section anchor='sec:ipaddr:rr:modi:MN'
title="Modifications on Mobile Node">
<t>A. BINDING UPDATE LIST:</t>
<t>According to section 11.1, RFC3775 <xref target="RFC3775"/>, each Binding Update List entry conceptually contains the following fields:
</t>
<list style="symbols">
<t>The IP address of the node to which a Binding Update was sent.</t>
<t>The home address for which that Binding Update was sent.</t>
<t>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. </t>
<t>Lifetime field.</t>
<t>Sequence Number field.</t>
</list>
<t>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.
</t>
<t>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.
</t>
<t><vspace blankLines='1' /></t>
<t>B. OPERATION:</t>
<t>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.
</t>
<t></t>
</section>
<section anchor='sec:ipaddr:rr:modi:others'
title="Other Issues">
<t>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-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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
</section>
</section>
<section anchor='sec:ipaddr:RTM'
title="Reverse-Tunneling Mode">
<t>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.
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = home agent)</t>
<t>ESP header in tunnel mode</t>
<t>IPv6 header (source = home address, destination = correspondent node)</t>
<t>data payload</t>
</list>
</t>
<t>The home agent forwards the data packet to the correspondent node in the following format.
<list style="symbols">
<t>IPv6 header (source = home address, destination = correspondent node)</t>
<t>data payload</t>
</list>
</t>
<t>The correspondent node replies with the following data packet that would be intercepted by the home agent.
<list style="symbols">
<t>IPv6 header (source = correspondent node, destination = home address)</t>
<t>data payload</t>
</list>
</t>
<t>The data packet forwarded by the home agent to the mobile node is as follows.
<list style="symbols">
<t>IPv6 header (source = home agent, destination = care-of address)</t>
<t>ESP header in tunnel mode</t>
<t>IPv6 header (source = correspondent node, destination = home address)</t>
<t>data payload</t>
</list>
</t>
<t>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.
</t>
</section>
<section anchor='sec:ipaddr:pd'
title="Prefix Discovery">
<t>Similar with that described in RFC 3776 <xref target="RFC3776"/>, the following packet format is used for requests
for prefixes from the mobile node to the home agent:
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = home agent)</t>
<t>Destination Options header
<list style="symbols">
<t>Home Address option (pseudo home address)</t>
</list>
</t>
<t>ESP header in transport mode</t>
<t>ICMPv6
<list style="symbols">
<t>Mobile Prefix Solicitation</t>
</list>
</t>
</list>
</t>
<t>Similarly, solicited and unsolicited prefix information advertisements from the home agent
to the mobile node use the following format:
<list style="symbols">
<t>IPv6 header (source = home agent, destination = care-of address)</t>
<t>Routing header (type 2)
<list style="symbols">
<t>pseudo home address</t>
</list>
</t>
<t>ESP header in transport mode</t>
<t>ICMPv6
<list style="symbols">
<t>Mobile Prefix Advertisement</t>
</list>
</t>
</list>
</t>
<t>The packet formats similar with those described in <xref target="I-D.draft-ietf-mip6-ikev2-ipsec"/> can also be used.
<list style="symbols">
<t>IPv6 header (source = care-of address, destination = home agent)</t>
<t>ESP header in tunnel mode</t>
<t>IPv6 header (source = home address, destination = home agent)</t>
<t>ICMPv6
<list style="symbols">
<t>Mobile Prefix Solicitation</t>
</list>
</t>
</list>
</t>
<t>and
<list style="symbols">
<t>IPv6 header (source = home agent, destination = care-of address)</t>
<t>ESP header in tunnel mode</t>
<t>IPv6 header (source = home agent, destination = home address)</t>
<t>ICMPv6
<list style="symbols">
<t>Mobile Prefix Advertisement</t>
</list>
</t>
</list>
</t>
</section>
</section> <!-- EndSect: IP Address Location Privacy with Dynamic Pseudo Home Address -->
<!--------------------------------------------------------------------------->
<!-- SECTION: PROFILING ATTACK -------------------------------------------->
<!--------------------------------------------------------------------------->
<section anchor='sec:profiling' title="Profiling Attack">
<section anchor='sec:profiling:overview' title="Overview">
<t>
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.
</t>
<t>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.
<list style="symbols">
<t>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</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
<section anchor='sec:profiling:discussion' title="Discussion">
<t>
To resist the profiling attack, these invariants need to be updated periodically.
RFC 3041 <xref target="RFC3041"/> 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.
</t>
<section anchor='sec:profiling:discussion:invariant' title="What Invariant
should be Updated to Resist the Profiling Attack Effectively?">
<t>
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 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. We must
update the identity of mobile nodes and should update other invariants as much
as possible.
</t>
</section>
<section anchor='sec:profiling:discussion:often' title="How Often these
Invariants should be Updated?">
<t>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 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.
</t>
</section>
<section anchor='sec:profiling:discussion:scope' title="What is the Scope of
the Profiling Prevention?">
<t>
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.
</t>
</section>
</section>
<section anchor='sec:profiling:seq' title="The Increment of Sequence Numbers in Correspondent Binding Updates">
<t>
RFC 3775 <xref target="RFC3775"/> 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.
</t>
<t>We propose the increment of sequence number as follows:
<list style="symbols">
<t>seq#_increment = First(8, HMAC_SHA1(Kbm, home nonce index | care nonce index))</t>
<t>If seq#_increment = 0, then set seq#_increment = 1</t>
<t>Seq# = (previous Seq# + seq#_increment) modulo (2^16)</t>
</list>
</t>
<t>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.
</t>
</section>
<section anchor='sec:profiling:SPI' title="The Increment of SPI">
<t>
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:
<list style="symbols">
<t>SPI_increment = First(8, HMAC_SHA1(Kph, the current SPI))</t>
<t>If SPI_increment = 0, then set SPI_increment = 1</t>
<t>the new SPI = (the current SPI + SPI_increment) modulo (2^32)</t>
</list>
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.
</t>
</section>
</section>
<!--------------------------------------------------------------------------->
<!-- SECTION: SECURITY CONSIDERATION ------------------------------------->
<!--------------------------------------------------------------------------->
<section anchor='sec:security' title="Security Considerations">
<t>This document addresses a security issue in the mobile environment, location privacy.
The proposed solutions do not introduce any new vulnerability.
</t>
<section anchor='sec:security:home_BU' title="Home Binding Update Procedure">
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor='sec:security:RTM' title="Reverse Tunneling Mode">
<t>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.
</t>
</section>
<section anchor='sec:security:RO' title="Route Optimization Mode">
<t>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.
</t>
<t>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 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.
</t>
</section>
<section anchor='sec:security:RR' title="Return Routability Procedure">
<t>As the pseudo home address is required to be routable, the modified Return
Routability procedure provides the same security strength as in RFC 3775 <xref target="RFC3775"/>.
</t>
</section>
<section anchor='sec:security:IKE' title="Pre-shared Key Establishment">
<t>The target of the solution is focused on IP layer. In this case, all of the session keys have been established and shared already. The process of establishing the session keys on the upper layer, such as IKE, which is beyond our scope.
</t>
</section>
</section>
<!--------------------------------------------------------------------------->
<!-- SECTION: RELATED WORK ------------------------------------------------>
<!--------------------------------------------------------------------------->
<section anchor='sec:relatedwork' title="Related Work">
<t>
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.
</t>
<t>RFC 3041 <xref target="RFC3041"/> 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.
</t>
<t>The draft <xref target="I-D.draft-dupont-mip6-privacyext"/> 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.
</t>
<t>The draft <xref target="I-D.draft-qiu-mip6-mnprivacy"/> proposes to update the identity based on a
key and a previous identity. The packet formats are presented.
</t>
<t>The draft <xref target="I-D.draft-qiu-mip6-hiding-movement"/> 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.
</t>
<t>The draft <xref target="I-D.draft-weniger-rota"/> 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.
</t>
</section>
<?rfc compact="yes"?>
<!--------------------------------------------------------------------------->
<!-- SECTION: IANA CONSIDERATIONS ----------------------------------------->
<!--------------------------------------------------------------------------->
<section anchor='sec:IANA' title="IANA Considerations">
<t>
The document does not define any new mobility header and mobility option, but it uses 2 bits
('P' bit and 'Q' bit) from the reserved fields of HoTI message and Binding Update Message respectively. .
</t>
</section>
<?rfc compact="yes"?>
<!--------------------------------------------------------------------------->
<!-- SECTION: CONCLUSION ------------------------------------------------>
<!--------------------------------------------------------------------------->
<section anchor='sec:conclusion' title="Conclusion">
<t>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.
</t>
<t>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.
</t>
</section> <!-- EndSect: Conclusion -->
<?rfc compact="yes"?>
<!--------------------------------------------------------------------------->
<!-- SECTION: ACKNOWLEDGEMENT ------------------------------------------------>
<!--------------------------------------------------------------------------->
<section anchor='sec:acknowledgement' title="Acknowledgement">
<t>
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.
</t>
</section> <!-- EndSect: Acknowledgement -->
</middle>
<!---------------------------------------------------------------------------->
<!-- BACK: References and Appendix ------------------------------------------->
<!---------------------------------------------------------------------------->
<back>
<references title="References">
<reference anchor='RFC2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'>
<organization /></author>
<date year='1997' month='March' />
</front>
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc2119.txt' />
</reference>
<reference anchor='RFC2401'>
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials='S.' surname='Kent' fullname='S. Kent'>
<organization /></author>
<author initials='R.' surname='Atkinson' fullname='R. Atkinson'>
<organization /></author>
<date year='1998' month='November' />
</front>
<seriesInfo name='RFC' value='2401' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc2401.txt' />
</reference>
<reference anchor='RFC4301'>
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials='S.' surname='Kent' fullname='S. Kent'>
<organization /></author>
<author initials='K.' surname='Seo' fullname='K. Seo'>
<organization /></author>
<date year='2005' month='December' />
</front>
<seriesInfo name='RFC' value='4301' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc4301.txt' />
</reference>
<reference anchor='RFC2406'>
<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials='S.' surname='Kent' fullname='S. Kent'>
<organization /></author>
<author initials='R.' surname='Atkinson' fullname='R. Atkinson'>
<organization /></author>
<date year='1998' month='November' />
</front>
<seriesInfo name='RFC' value='2406' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc2406.txt' />
</reference>
<reference anchor='RFC4303'>
<front>
<title>IP Encapsulating Security Payload (ESP)</title>
<author initials='S.' surname='Kent' fullname='S. Kent'>
<organization /></author>
<date year='2005' month='December' />
</front>
<seriesInfo name='RFC' value='4303' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc4303.txt' />
</reference>
<reference anchor='RFC2409'>
<front>
<title>The Internet Key Exchange (IKE)</title>
<author initials='D.' surname='Harkins' fullname='D. Harkins'>
<organization /></author>
<author initials='D.' surname='Carrel' fullname='D. Carrel'>
<organization /></author>
<date year='1998' month='November' />
</front>
<seriesInfo name='RFC' value='2409' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc2409.txt' />
</reference>
<reference anchor='RFC4306'>
<front>
<title>Internet Key Exchange (IKEv2) Protocol</title>
<author initials='C.' surname='Kaufman' fullname='C. Kaufman'>
<organization /></author>
<date year='2005' month='December' />
</front>
<seriesInfo name='RFC' value='4306' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc4306.txt' />
</reference>
<reference anchor='RFC2460'>
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials='S.' surname='Deering' fullname='S. Deering'>
<organization /></author>
<author initials='R.' surname='Hinden' fullname='R. Hinden'>
<organization /></author>
<date year='1998' month='December' />
</front>
<seriesInfo name='RFC' value='2460' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc2460.txt' />
</reference>
<reference anchor='RFC2473'>
<front>
<title>Generic Packet Tunneling in IPv6 Specification</title>
<author initials='A.' surname='Conta' fullname='A. Conta'>
<organization /></author>
<author initials='S.' surname='Deering' fullname='S. Deering'>
<organization /></author>
<date year='1998' month='December' />
</front>
<seriesInfo name='RFC' value='2473' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc2473.txt' />
</reference>
<reference anchor='RFC3775'>
<front>
<title>Mobility Support in IPv6</title>
<author initials='D.' surname='Johnson' fullname='D. Johnson'>
<organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'>
<organization /></author>
<author initials='J.' surname='Arkko' fullname='J. Arkko'>
<organization /></author>
<date year='2004' month='June' />
</front>
<seriesInfo name='RFC' value='3775' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc3775.txt' />
</reference>
<reference anchor='RFC3776'>
<front>
<title>Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents</title>
<author initials='J.' surname='Arkko' fullname='J. Arkko'>
<organization /></author>
<author initials='V.' surname='Devarapalli' fullname='V. Devarapalli'>
<organization /></author>
<author initials='F.' surname='Dupont' fullname='F. Dupont'>
<organization /></author>
<date year='2004' month='June' />
</front>
<seriesInfo name='RFC' value='3776' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc3776.txt' />
</reference>
<reference anchor='RFC3041'>
<front>
<title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='R.' surname='Draves' fullname='R. Draves'>
<organization /></author>
<date year='2001' month='January' />
</front>
<seriesInfo name='RFC' value='3041' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc3041.txt' />
</reference>
<reference anchor='RFC4291'>
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials='R.' surname='Hinden' fullname='R. Hinden'>
<organization /></author>
<author initials='S.' surname='Deering' fullname='S. Deering'>
<organization /></author>
<date year='2006' month='February' />
</front>
<seriesInfo name='RFC' value='4291' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc4291.txt' />
</reference>
<reference anchor='RFC4882'>
<front>
<title>IP Address Location Privacy and Mobile IPv6: Problem Statement</title>
<author initials='R.' surname='Koodli' fullname='Rajeev Koodli'>
<organization /></author>
<date month='March' year='2007' />
</front>
<seriesInfo name='RFC' value='4882' />
<format type='TXT' octets='393514' target='http://www.ietf.org/rfc/rfc4882.txt' />
</reference>
<reference anchor='I-D.draft-koodli-mip6-location-privacy-solutions'>
<front>
<title>Solutions for IP Address Location Privacy in the presence of IP Mobility</title>
<author initials='R.' surname='Koodli' fullname='Rajeev Koodli'>
<organization /></author>
<author initials='V.' surname='Devarapalli' fullname='V. Devarapalli'>
<organization /></author>
<author initials='H.' surname='Flinck' fullname='H. Flinck'>
<organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'>
<organization /></author>
<date month='February' year='2005' />
</front>
<seriesInfo name='Internet-Draft' value='draft-koodli-mip6-location-privacy-solutions-00' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-koodli-mip6-location-privacy-solutions-00.txt' />
</reference>
<reference anchor='I-D.draft-qiu-mip6-mnprivacy'>
<front>
<title>Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6</title>
<author initials='F.' surname='Bao' fullname='F. Bao'>
<organization /></author>
<author initials='R.' surname='Deng' fullname='R. Deng'>
<organization /></author>
<author initials='J.' surname='Kempf' fullname='J. Kempf'>
<organization /></author>
<author initials='Y.' surname='Qiu' fullname='Y. Qiu'>
<organization /></author>
<author initials='J.' surname='Zhou' fullname='J. Zhou'>
<organization /></author>
<date month='March' year='2005' />
</front>
<seriesInfo name='Internet-Draft' value='draft-qiu-mip6-mnprivacy-00' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-qiu-mip6-mnprivacy-00.txt' />
</reference>
<reference anchor='I-D.draft-qiu-mip6-hiding-movement'>
<front>
<title>Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6</title>
<author initials='F.' surname='Bao' fullname='F. Bao'>
<organization /></author>
<author initials='R.' surname='Deng' fullname='R. Deng'>
<organization /></author>
<author initials='J.' surname='Kempf' fullname='J. Kempf'>
<organization /></author>
<author initials='Y.' surname='Qiu' fullname='Y. Qiu'>
<organization /></author>
<author initials='J.' surname='Zhou' fullname='J. Zhou'>
<organization /></author>
<date month='March' year='2005' />
</front>
<seriesInfo name='Internet-Draft' value='draft-qiu-mip6-hiding-movement-00' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-qiu-mip6-hiding-movement-00.txt' />
</reference>
<reference anchor='I-D.draft-dupont-mip6-privacyext'>
<front>
<title>Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6</title>
<author initials='C.' surname='Castelluccia' fullname='C. Castelluccia'>
<organization /></author>
<author initials='F.' surname='Dupont' fullname='F. Dupont'>
<organization /></author>
<author initials='G.' surname='Montenegro' fullname='G. Montenegro'>
<organization /></author>
<date month='July' year='2005' />
</front>
<seriesInfo name='Internet-Draft' value='draft-dupont-mip6-privacyext-02' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-dupont-mip6-privacyext-02.txt' />
</reference>
<reference anchor='I-D.draft-daley-mip6-locpriv'>
<front>
<title>Location Privacy and Mobile IPv6</title>
<author initials='G.' surname='Daley' fullname='G. Daley'>
<organization /></author>
<date month='January' year='2004' />
</front>
<seriesInfo name='Internet-Draft' value='draft-daley-mip6-locpriv-00' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-daley-mip6-locpriv-00.txt' />
</reference>
<reference anchor='I-D.draft-weniger-rota'>
<front>
<title>Route Optimization and Location Privacy using Tunneling Agents (ROTA)</title>
<author initials='K.' surname='Weniger' fullname='K. Weniger'>
<organization /></author>
<author initials='T.' surname='Aramaki' fullname='T. Aramaki'>
<organization /></author>
<date month='October' year='2005' />
</front>
<seriesInfo name='Internet-Draft' value='draft-weniger-rota-01' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-weniger-rota-01.txt' />
</reference>
<reference anchor='I-D.draft-ietf-mip6-ikev2-ipsec'>
<front>
<title>Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture</title>
<author initials='V.' surname='Devarapalli' fullname='V. Devarapalli'>
<organization /></author>
<author initials='F.' surname='Dupont' fullname='F. Dupont'>
<organization /></author>
<date month='April' year='2006' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mip6-ikev2-ipsec-06' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-06.txt' />
</reference>
</references>
</back>
<!---------------------------------------------------------------------------->
<!-- BACK: References and Appendix ------------------------------------------->
<!---------------------------------------------------------------------------->
<back>
<appendix anchor='apx:history' title="Version History">
<list style="symbols">
<t>v01 to v02</t>
<list style="symbols">
<t>Change the document structure.</t>
<t>Describe the process in detail how to derive a serials of secret keys.</t>
<t>New scheme to protect SPI profiling.</t>
<t>Use multi home link prefixes to generate pseudoHoA.</t>
<t>Propose two schemes of transferring BU message to HA in order to match the different protocols (RFC 3776 and IKEv2 in mobile IP).</t>
</list>
<t>v02 to v03</t>
<list style="symbols">
<t>Merger section 5.3.1.and 5.3.2 and a same BU process is employed to the correspondent node regardless initiator or responder.</t>
<t>Introduce a term of identity address to ensure location privacy and communication session continuity</t>
</list>
<t>v03 to v04</t>
<list style="symbols">
<t>Describe and compare the modifications of processing bindings in more detail. </t>
<t>Reformat section 5.3.</t>
</list>
<t>v04 to v06</t>
<list style="symbols">
<t>Revise the algorithm proposed in section 4. </t>
<t>Update authors information.</t>
</list>
<t>v06 to v07</t>
<list style="symbols">
<t>Add traffic formats.</t>
<t>Update the section of IANA requirement.</t>
<t>Revise according to comments of reviewers Heejin and Vijay. </t>
</list>
</list>
</appendix>
</back>
</rfc>
<!-- End of Doc -->
| PAFTECH AB 2003-2026 | 2026-04-24 10:39:31 |