TOC |
|
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 August 28, 2008.
Mobile IPv6 [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) 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] (Koodli, R., “IP Address Location Privacy and Mobile IPv6: Problem Statement,” March 2007.) and propose efficient and secure techniques to protect the location privacy of a mobile node.
1.
Introduction
2.
Terminology
3.
Brief Overview of Location Privacy in MIP6
4.
Pseudo Home Address Generation Using Return Routability Signaling
4.1.
Route-Optimized Binding Update to the Correspondent Node
4.2.
Reverse-Tunneled Binding Update to the Correspondent Node
5.
Pseudo Home Address Generation Using Cryptography Algorithms
5.1.
Pseudo Home Address Generation
5.1.1.
Requirements
5.1.2.
The Shared Key, Kph
5.1.3.
Routable Pseudo Home Address Generation
5.1.4.
Dynamic Pseudo Home Address
5.2.
Home Binding Updates and Acknowledgements
5.2.1.
Solution with IPsec Transport Mode
5.2.2.
Solution with IPsec Tunneling Mode
5.3.
Processing of Correspondent Binding Updates
5.3.1.
Correspondent Binding Updates Signaling
5.3.2.
Modifications to Correspondent Node Binding Updates
5.4.
Reverse-Tunneling Mode
5.5.
Prefix Discovery
6.
Profiling Attack
6.1.
Overview
6.2.
Discussion
6.2.1.
What Invariant
should be Updated to Resist the Profiling Attack Effectively?
6.2.2.
How Often these
Invariants should be Updated?
6.2.3.
What is the Scope of
the Profiling Prevention?
6.3.
The Increment of Sequence Numbers in Correspondent Binding Updates
6.4.
The Increment of SPI
7.
Security Considerations
7.1.
Home Binding Update Procedure
7.2.
Reverse Tunneling Mode
7.3.
Route Optimization Mode
7.4.
Return Routability Procedure
7.5.
Pre-shared Key Establishment
8.
Related Work
9.
IANA Considerations
10.
Conclusion
11.
Acknowledgement
12.
References
Appendix A.
Version History
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
TOC |
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 [14] (Koodli, R., “IP Address Location Privacy and Mobile IPv6: Problem Statement,” March 2007.).
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. 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.
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.
TOC |
Throughout this document we use the commonly adopted terminology defined in [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and [14] (Koodli, R., “IP Address Location Privacy and Mobile IPv6: Problem Statement,” March 2007.), such as
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
TOC |
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:
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 .
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.
TOC |
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.
TOC |
In the original MIPv6 procedure, the home address is visible in the Binding Update to the correspondent node. The mobile node can make the home address invisible to eavesdroppers by replacing the real home address with a pseudo home address generated as follows.
The mobile node sets a 'P' bit in the reserved field of the HoTI message showed as following figure to indicate it wishes to use a pseudo home address in place of the home address.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The correspondent node, if it supports the 'P' bit, computes a privacy keygen token as follows:
privacy keygen token = First (64, MAC_SHA1(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. Following figure shows the change.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Home Init Cookie + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + (Home Keygen Token) Privacy Keygen Token + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Mobility options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The care-of address test procedure is exactly the same as specified in MIP6 protocol [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
The mobile node computes Kpm and the pseudo home address after the Return Routability procedure as follows:
Kpm = SHA1 (privacy keygen token | care-of keygen token)
pseudo home address = String XOR HoA
where String = First (128, HMAC_SHA1 (Kpm, (care-of address | Home nonce index | Care-of nonce index)))
The mobile node then sends the following Binding Update to the correspondent node:
Following figure shows the binding update format with 'P' bit.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|P| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + privacy factor: Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
TOC |
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 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:
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.
TOC |
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.
TOC |
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] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.). Afterwards, the home agent updates its Binding Cache to store the recent pseudo home address in addition to the real home address.
TOC |
The mechanism to generate the pseudo home address needs to fulfill the following requirements:
TOC |
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] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.), 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] (Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” November 1998.) [7] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.). If this security association is manually established, Kph can be generated from the shared manual key, denoted by Ks, as follows:
Kph = HMAC_SHA1(Ks, 0)
If this security association is established through IKE, Kph is negotiated and renewed by IKE as well, for example, by running the quick mode protected by a previously established IKE security association in phase 2. Either way, Kph is associated with the relevant security association entry in SAD. The location privacy protection option can be negotiated between the home agent and the mobile node. The home agent can distinguish the regular MIP6 signaling packets from those providing the location privacy based on the security association and process them appropriately.
TOC |
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.
TOC |
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)
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 extended sequence number.
In summary, the real home address cannot be revealed from the pseudo home address without the knowledge of Kph. And the pseudo home address fulfills the requirements of being routable and dynamic.
TOC |
TOC |
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.
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] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.) represents the corresponding inbound SAD and SPD entries as follows:
SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
source = home_address_1 && destination = home_agent_1 && proto = MH
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] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.). 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.
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 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.
The home agent replies to the mobile node with the following modified Home Binding Acknowledgement:
RFC 3776 [11] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.) specifies the corresponding outbound SAD and SPD entries as follows:
SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
source = home_agent_1 && destination = home_address_1 && proto = MH
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 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.
Compared with the packet formats defined in RFC 3776 [11] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.), 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.
TOC |
The packet formats above follow the fashion in RFC 3776 [11] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.), in the following we show an alternative that uses the similar packet formats as in [21] (Devarapalli, V. and F. Dupont, “Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture,” April 2006.). This is applicable when using IKEv2 [7] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) and the revised IPsec Architecture [3] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.).
Binding Update:
The home agent processes this Binding Update in the same way as specified in [21] (Devarapalli, V. and F. Dupont, “Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture,” April 2006.). 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:
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] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.).
TOC |
TOC |
When initiating the communication with its correspondent node, the mobile node sends HoTI to its home agent in the following format:
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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|Q| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Init Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The home agent would process the received HoTI message in a similar way as described in RFC 3776 [11] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.). 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:
The correspondent node processes this received HoTI message in the same way as in RFC 3775 [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and sends the following HoT message to the home agent.
where home keygen token = First (64, HMAC_SHA1(Kcn, (pseudo home address | nonce | 0))) and Kcn is the correspondent node's local secret [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
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:
The care-of address test is exactly the same as specified in RFC 3775 [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
After receiving both HoT and CoT messages, the mobile node sends the Binding Update to the correspondent node in the following format:
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. Following figure shows the binding update format with 'Q' bit.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|P|Q| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + privacy factor: Enc(Kbm, identity_address) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) except that the pseudo home address is used in place of the home address.
Data packets from the mobile node to the correspondent node:
Data packets from the correspondent node to the mobile node:
TOC |
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.
TOC |
A. BINDING CACHE:
Referring to section 9.1, RFC 3775 [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), each Binding Cache entry conceptually contains the following fields:
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. 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), 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 [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.)) and the one with the additional option in our proposal.
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 |
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.
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)}.
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 .
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.
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 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.
TOC |
A. BINDING CACHE:
Referring to section 10.1 and 9.1, RFC 3775 [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), each Binding Cache entry conceptually contains the following fields:
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 not different from the original MIPv6 [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), 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.
TOC |
A. BINDING UPDATE LIST:
According to section 11.1, RFC3775 [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), each Binding Update List entry conceptually contains the following fields:
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.
TOC |
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.
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.
TOC |
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.
The home agent forwards the data packet to the correspondent node in the following format.
The correspondent node replies with the following data packet that would be intercepted by the home agent.
The data packet forwarded by the home agent to the mobile node is as follows.
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.
TOC |
Similar with that described in RFC 3776 [11] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.), the following packet format is used for requests for prefixes from the mobile node to the home agent:
Similarly, solicited and unsolicited prefix information advertisements from the home agent to the mobile node use the following format:
The packet formats similar with those described in [21] (Devarapalli, V. and F. Dupont, “Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture,” April 2006.) can also be used.
and
TOC |
TOC |
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.
TOC |
To resist the profiling attack, these invariants need to be updated periodically. RFC 3041 [12] (Narten, T. and R. Draves, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” January 2001.) 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.
TOC |
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.
TOC |
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.
TOC |
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.
TOC |
RFC 3775 [10] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) 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:
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.
TOC |
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:
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.
TOC |
This document addresses a security issue in the mobile environment, location privacy. The proposed solutions do not introduce any new vulnerability.
TOC |
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.
TOC |
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.
TOC |
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 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.
TOC |
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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).
TOC |
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.
TOC |
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] (Narten, T. and R. Draves, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” January 2001.) 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] (Castelluccia, C., Dupont, F., and G. Montenegro, “Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6,” July 2005.) 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] (Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, “Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6,” March 2005.) proposes to update the identity based on a key and a previous identity. The packet formats are presented.
The draft [17] (Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, “Protocol for Protecting Movement of Mobile Nodes in Mobile IPv6,” March 2005.) 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] (Weniger, K. and T. Aramaki, “Route Optimization and Location Privacy using Tunneling Agents (ROTA),” October 2005.) 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.
TOC |
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. .
TOC |
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.
TOC |
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.
TOC |
[1] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, March 1997 (TXT). |
[2] | Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” RFC 2401, November 1998 (TXT). |
[3] | Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” RFC 4301, December 2005 (TXT). |
[4] | Kent, S. and R. Atkinson, “IP Encapsulating Security Payload (ESP),” RFC 2406, November 1998 (TXT). |
[5] | Kent, S., “IP Encapsulating Security Payload (ESP),” RFC 4303, December 2005 (TXT). |
[6] | Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” RFC 2409, November 1998 (TXT). |
[7] | Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” RFC 4306, December 2005 (TXT). |
[8] | Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT). |
[9] | Conta, A. and S. Deering, “Generic Packet Tunneling in IPv6 Specification,” RFC 2473, December 1998 (TXT). |
[10] | Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004 (TXT). |
[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 (TXT). |
[12] | Narten, T. and R. Draves, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” RFC 3041, January 2001 (TXT). |
[13] | Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” RFC 4291, February 2006 (TXT). |
[14] | Koodli, R., “IP Address Location Privacy and Mobile IPv6: Problem Statement,” RFC 4882, March 2007 (TXT). |
[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 (TXT). |
[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 (TXT). |
[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 (TXT). |
[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 (TXT). |
[19] | Daley, G., “Location Privacy and Mobile IPv6,” draft-daley-mip6-locpriv-00 (work in progress), January 2004 (TXT). |
[20] | Weniger, K. and T. Aramaki, “Route Optimization and Location Privacy using Tunneling Agents (ROTA),” draft-weniger-rota-01 (work in progress), October 2005 (TXT). |
[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 (TXT). |
TOC |
TOC |
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 | |
Email: | Rajeev.Koodli@gmail.com |
TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.