idnits 2.17.1 draft-irtf-mobopts-location-privacy-solutions-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The mobile node may receive an ICMP Parameter Problem, Code 2, message forwarded by the home agent via the bi-directional tunnel, for example, when the correspondent node does not support the use of the Encrypted Home Address option. If such a message is received, the mobile node SHOULD not attempt to use the location privacy solution with the correspondent node. The mobile node may choose either not to communicate with the correspondent node, or to communicate without location privacy protection. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: To resist this kind of profiling attack, the IPsec SPI needs to be periodically updated. One way is that the mobile node and the home agent rekey the IPsec security association or perform re-authentication periodically. This may result in more signaling overhead. Another way is that the mobile node or the home agent generates a new SPI and then notifies each other by exchanging the Binding Update and Acknowledgement messages protected by an existing IPsec security association with a non-null encryption algorithm. In this way, the information of the new SPI is hidden from eavesdroppers. The new SPI MUST not conflict with other existing SPIs; and if the conflict is detected on one end point, another SPI MUST be generated and be synchronized with the other end point. The new SPI is applied to the next packet that needs to be protected by this IPsec security association. This solution requires close interaction between Mobile IP and IPsec. For example, when the home agent receives a new SPI suggested by the mobile node, it needs to change the corresponding SAD entry. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2009) is 5399 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 1857, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1860, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1863, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1869, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1873, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1877, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1887, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1890, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1895, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1898, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1916, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (ref. '4') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (ref. '6') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 3041 (ref. '10') (Obsoleted by RFC 4941) -- No information found for draft-qiu-mip6-hiding-movement - is the name correct? == Outdated reference: A later version (-04) exists of draft-dupont-mip6-privacyext-02 -- No information found for draft-daley-mip6-locpriv - is the name correct? == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-09 == Outdated reference: A later version (-14) exists of draft-ietf-mext-binding-revocation-01 Summary: 6 errors (**), 0 flaws (~~), 18 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobopts Working Group Y. Qiu 3 Internet-Draft Institute for Infocomm Research 4 Intended status: Experimental F. Zhao, Ed. 5 Expires: January 9, 2010 R. Koodli 6 Starent Networks 7 July 8, 2009 9 Mobile IPv6 Location Privacy Solutions 10 draft-irtf-mobopts-location-privacy-solutions-16 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 9, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable 49 while it roams on the Internet. However, the location and movement 50 of the mobile node can be revealed by the IP addresses used in 51 signaling or data packets. In this document, we consider the Mobile 52 IPv6 location privacy problem described in RFC 4882, and propose 53 efficient and secure techniques to protect location privacy of the 54 mobile node. This document is a product of the IP Mobility 55 Optimizations (MobOpts) Research Group. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 61 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Reverse-Tunneled Correspondent Binding Update . . . . . . . . 13 66 5.1. The Procedure . . . . . . . . . . . . . . . . . . . . . . 13 67 5.2. Route Optimized Payload Packets . . . . . . . . . . . . . 16 68 5.3. Mobile Node Operation . . . . . . . . . . . . . . . . . . 16 69 5.3.1. Conceptual Data Structures . . . . . . . . . . . . . . 16 70 5.3.2. Reverse-tunneled Correspondent Binding Update to 71 the Correspondent Node . . . . . . . . . . . . . . . . 17 72 5.3.3. Reverse-tunneled Correspondent Binding 73 Acknowledgement from the Correspondent Node . . . . . 17 74 5.3.4. Route Optimized Payload Packets . . . . . . . . . . . 17 75 5.3.5. Receiving ICMP Error Message . . . . . . . . . . . . . 18 76 5.3.6. Binding Error from the Correspondent Node . . . . . . 18 77 5.3.7. Binding Refresh Request from the Correspondent Node . 18 78 5.4. Home Agent Operation . . . . . . . . . . . . . . . . . . . 19 79 5.5. Correspondent Node Operation . . . . . . . . . . . . . . . 19 80 5.5.1. Conceptual Data Structures . . . . . . . . . . . . . . 19 81 5.5.2. Reverse-tunneled Correspondent Binding Update from 82 the Mobile Node . . . . . . . . . . . . . . . . . . . 19 83 5.5.3. Reverse-tunneled Correspondent Binding 84 Acknowledgement to the Mobile Node . . . . . . . . . . 19 85 5.5.4. Route Optimized Payload Packets . . . . . . . . . . . 20 86 5.5.5. ICMP Error Message to the Mobile Node . . . . . . . . 20 87 5.5.6. Binding Error to the Mobile Node . . . . . . . . . . . 20 88 5.5.7. Binding Refresh Request to the Mobile Node . . . . . . 20 89 5.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 6. IP Address Location Privacy Solution Using the Pseudo Home 91 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 6.1. Home Binding Update . . . . . . . . . . . . . . . . . . . 22 93 6.1.1. Pseudo Home Address Registration . . . . . . . . . . . 22 94 6.1.2. Home De-registration . . . . . . . . . . . . . . . . . 23 95 6.2. Correspondent Binding Update Using the Pseudo Home 96 Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 6.2.1. Return Routability Procedure . . . . . . . . . . . . . 24 98 6.2.2. Route Optimized Correspondent Binding Update . . . . . 25 99 6.2.3. Reverse-tunneled Correspondent Binding Update . . . . 26 100 6.2.4. Using Different Pseudo Home Addresses with 101 Different Correspondent Nodes . . . . . . . . . . . . 26 102 6.3. Payload Packets . . . . . . . . . . . . . . . . . . . . . 27 103 6.3.1. Reverse Tunneling Mode . . . . . . . . . . . . . . . . 27 104 6.3.2. Route Optimization Mode . . . . . . . . . . . . . . . 27 105 6.4. Prefix Discovery . . . . . . . . . . . . . . . . . . . . . 27 106 6.5. Mobile Node Operation . . . . . . . . . . . . . . . . . . 28 107 6.5.1. Conceptual Data Structures . . . . . . . . . . . . . . 28 108 6.5.2. Binding Update to the Home Agent . . . . . . . . . . . 28 109 6.5.3. Binding Acknowledgement from the Home Agent . . . . . 29 110 6.5.4. Home Test Init to the Home Agent . . . . . . . . . . . 29 111 6.5.5. Home Test from the Home Agent . . . . . . . . . . . . 30 112 6.5.6. Route Optimized Payload Packets . . . . . . . . . . . 30 113 6.5.7. Receiving Binding Refresh Request . . . . . . . . . . 31 114 6.6. Home Agent Operation . . . . . . . . . . . . . . . . . . . 31 115 6.6.1. Conceptual Data Structures . . . . . . . . . . . . . . 31 116 6.6.2. Binding Update from the Mobile Node . . . . . . . . . 31 117 6.6.3. Binding Acknowledgement to the Mobile Node . . . . . . 32 118 6.6.4. Home Test Init from the Mobile Node . . . . . . . . . 33 119 6.6.5. Home Test to the Mobile Node . . . . . . . . . . . . . 33 120 6.7. Correspondent Node Operation . . . . . . . . . . . . . . . 33 121 7. Extensions to Mobile IPv6 . . . . . . . . . . . . . . . . . . 34 122 7.1. Encrypted Home Address Destination Option . . . . . . . . 34 123 7.2. Encrypted Home Address Routing Header . . . . . . . . . . 35 124 7.3. Pseudo Home Address Mobility Option . . . . . . . . . . . 35 125 7.4. Pseudo Home Address Acknowledgement Mobility Option . . . 37 126 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 39 127 8.1. Home Binding Update . . . . . . . . . . . . . . . . . . . 39 128 8.2. Correspondent Binding Update . . . . . . . . . . . . . . . 39 129 8.3. Route-Optimized Payload Packets . . . . . . . . . . . . . 40 130 9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 41 131 10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 42 132 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 42 133 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 43 134 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 135 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43 136 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 137 Appendix A. Profiling Attack: Discussion . . . . . . . . . . . . 45 138 A.1. The Care-of Address . . . . . . . . . . . . . . . . . . . 45 139 A.2. Profiling on the Encrypted Home Address . . . . . . . . . 46 140 A.3. The IPsec SPI . . . . . . . . . . . . . . . . . . . . . . 46 141 A.4. The IPsec Sequence Number . . . . . . . . . . . . . . . . 47 142 A.5. The Regular Interval of Signaling Messages . . . . . . . . 47 143 A.6. The Sequence Number in the Binding Update Message . . . . 47 144 A.7. Multiple Concurrent Sessions . . . . . . . . . . . . . . . 48 145 A.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 48 146 Appendix B. Version History . . . . . . . . . . . . . . . . . . . 48 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 149 1. Introduction 151 The IP address location privacy problem is concerned with unwittingly 152 revealing the current location of a mobile node to eavesdroppers and 153 to communicating parties. In the presence of mobility as specified 154 in Mobile IPv6 [6], there are two related problems: disclosing the 155 care-of address to a correspondent node, and revealing the home 156 address to an eavesdropper (please see the terminology below). A 157 detailed description of the location privacy problem can be found in 158 RFC 4882 [11]. This document assumes that the reader is familiar 159 with the basic operation of Mobile IPv6 specified in RFC 3775, as 160 well as the location privacy problem described in RFC 4882. 162 In order to protect location privacy, a mobile node must not disclose 163 the binding between its care-of address and its home address. In 164 this document, we propose a set of extensions to the Mobile IPv6 165 specification to address the IP address location privacy problem. 166 Related to the IP address location privacy is "profiling", where the 167 activities of a mobile node are linked and then analyzed. Profiled 168 activities may contribute to compromising a mobile node's location 169 privacy, especially when combined with additional information. 170 Furthermore, once location privacy is compromised, it may lead to 171 more targeted profiling. Solutions to thwart profiling are 172 important; however, they are not central to this document. We 173 discuss profiling in the appendix. 175 We propose two IP address location privacy solutions in this 176 document. With the first solution (as described in Section 5), the 177 mobile node can communicate with the correspondent node by using the 178 real home address without location privacy being breached by 179 eavesdroppers. This is done by using parameters generated during the 180 return routability procedure to mask the real home address, which 181 provides an evolution towards location privacy protection based on 182 return routability messages already specified in RFC 3775. With the 183 second solution (as described in Section 6), an IPsec tunnel mode 184 security association with a non-null encryption algorithm is 185 negotiated to encrypt signaling messages (including the real home 186 address therein) exchanged between the mobile node and the home 187 agent, for example, during the home binding update procedure. 188 Furthermore, during the return routability procedure and the 189 correspondent binding update procedure, a "pseudo home address" (the 190 definition of this new term and many other commonly used mobility 191 related terms is provided in Section 2) is used to replace the real 192 home address in various messages, which allows the mobile node to 193 hide its real home address from both the correspondent node and 194 eavesdroppers without additional extensions to the correspondent node 195 needed. Moreover, the mobile node may mask the pseudo home address 196 by using the mechanism specified in Section 5 to further enhance 197 location privacy protection. Each of these two solutions can be 198 implemented on its own without relying on the other. 200 The solutions presented in this document are designed based on the 201 following assumptions. First, we focus on location privacy issues 202 arising when the mobile node attaches to a foreign link; location 203 privacy issues when the mobile node attaches to its home link, if 204 any, are outside the scope of this document. Second, we assume that 205 IPsec [2] is used to secure mobility signaling messages exchanged 206 between the mobile node and the home agent; therefore, location 207 privacy solutions when other security mechanisms are used are beyond 208 the scope of this document. Third, we assume that eavesdroppers are 209 passive attackers, e.g., an eavesdropper along the path traversed by 210 traffic flows from or to the mobile node. We make this assumption 211 because messages generated by active attackers can either be 212 discarded based on local policy at a mobile node or the mobile node 213 could choose to treat such messages like those of any other 214 correspondent nodes. Thus, specific threats to location privacy 215 posed by active attackers are also beyond the scope of this document. 216 Fourth, in order to simplify analysis, we assume that both the 217 correspondent node and the home agent are fixed nodes; if either is 218 mobile, the same analysis and solutions for the mobile node may also 219 apply. Finally, the same solution applies to each of the care-of 220 addresses if a mobile node maintains more than one care-of address. 222 This document represents the consensus of the MobOpts Research Group. 223 It has been reviewed by the Research Group members active in the 224 specific area of work. At the request of their chairs, this document 225 has been comprehensively reviewed by multiple active contributors to 226 the IETF Mobile IP related working groups. 228 2. Conventions and Terminology 230 2.1. Conventions 232 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in RFC 2119 [1]. 236 2.2. Terminology 238 In this document, we introduce two new terms, "pseudo home address" 239 and "encrypted home address". The definition of these two terms is 240 provided in the following. 242 o Pseudo Home Address (pHoA): A unicast IPv6 address formed to 243 replace the real home address used in certain Mobile IPv6 244 signaling or data packets. Without explicit indication, the 245 pseudo home address looks like a regular IPv6 address. 247 o Encrypted Home Address (eHoA): The output when applying an 248 encryption algorithm to the real home address or the pseudo home 249 address with additional inputs, e.g., a key. The real home 250 address can be recovered from the encrypted home address by using 251 a decryption algorithm. 253 In addition, we use commonly adopted mobility-related terms as 254 defined in [6] and [11] throughout this document. Some of these 255 terms are provided below for easier reference. Nevertheless, we 256 assume that readers are familiar with the basic operation of the 257 Mobile IPv6 protocol as defined in RFC 3775, RFC 3776 and RFC 4877. 259 o Mobile Node (MN): A Mobile IPv6 compliant mobile node that can 260 roam on the Internet 262 o Correspondent Node (CN): An IPv6 node that communicates with the 263 mobile node 265 o Home Network: The network where the mobile node is normally 266 present when it is not roaming 268 o Visited Network: The network that the mobile node uses to access 269 the Internet when it is roaming 271 o Home Agent (HA): A router on the mobile node's home network that 272 provides forwarding support when the mobile node is roaming 274 o Home Address (HoA): The mobile node's unicast IP address valid on 275 its home network 277 o Care-of Address (CoA): The mobile node's unicast IP address valid 278 on the visited network 280 o Return Routability (RR): A procedure which enables secure binding 281 between the care-of address and the home address when no pre- 282 existing security association exists between the mobile node and 283 the correspondent node 285 o Home Test Init (HoTI) / Home Test (HoT) / Care-of Test Init (CoTI) 286 / Care-of Test (CoT): Messages used during the return routability 287 procedure 289 o Binding Update (BU): A message used by the mobile node to securely 290 bind its care-of address to its home address at the correspondent 291 node or the home agent 293 o Binding Acknowledgement (BA): A response to the Binding Update 295 o Message Authentication Code (MAC): The value, which is computed 296 using HMAC_SHA1 in this document, that protects both a message's 297 integrity and its authenticity 299 o Route Optimization: A mechanism that allows direct routing of 300 packets between a roaming mobile node and its correspondent node, 301 without having to traverse the home network 303 o Reverse Tunneling or Bidirectional Tunneling: A mechanism used for 304 packet forwarding between a roaming mobile node and its 305 correspondent node via its home agent 307 3. Requirements 309 In this section, we describe the requirements that should be met by 310 the Mobile IPv6 location privacy solutions, hereafter referred to as 311 "the solution". These are some of the basic requirements set forth 312 in order to make the solution readily implementable by those familiar 313 with Mobile IPv6 and the related security protocols used with it 314 (such as IKEv2 and IPsec). 316 R01: The solution must follow the framework and architecture of IPv6 317 and Mobile IPv6 (as specified in RFC 3775, RFC 3776 and RFC 4877). 319 R02: The solution must not interfere with the operation of IPsec. 320 This means that the principles and the operation specified in RFC 321 3776 and RFC 4877 need to be followed. For example, the IPsec 322 security association and policy must be identified by the real home 323 address. 325 R03: The solution should provide back-compatibility in order for 326 different Mobile IPv6 entities to work together even though they may 327 have different capabilities. This requires the mobile node to be 328 able to detect whether the home agent or the correspondent node 329 supports the use of the location privacy solutions. 331 R04: The overhead resulting from the solution, in terms of payloads 332 or messages transmitted and memory, should be kept minimal. 334 4. Solution Overview 336 The IP address location privacy solutions proposed in this document 337 intend to conceal the binding between the mobile node's real home 338 address and its care-of address from eavesdroppers and the 339 correspondent node. In this section, we present an overview of the 340 proposed solutions. 342 With the Mobile IPv6 specification, during the home binding update 343 procedure, both the real home address and the care-of address are in 344 the cleartext when either the IPsec tunnel mode or the IPsec 345 transport mode is used with no encryption. As described in 346 Section 6.1, the solution to prevent the real home address being 347 leaked to eavesdroppers on the MN-HA path during the home binding 348 update procedure is to set up an IPsec tunnel mode security 349 association with a non-null encryption algorithm to encrypt home 350 binding signaling messages and the real home address therein. This 351 method is also used to enable location privacy protection during 352 other mobility signaling message exchanges between the home agent and 353 the mobile node, such as the prefix discovery procedure (see 354 Section 6.4). 356 When communicating with the correspondent node with the reverse 357 tunneling mode, the mobile node can hide its current location from 358 the correspondent node and eavesdroppers along the HA-CN path, since 359 the care-of address is not included in payload packets transmitted on 360 that path. Also, an IPsec security association with a non-null 361 encryption algorithm established between the mobile node and the home 362 agent can conceal the real home address carried in payload packets 363 from eavesdroppers along the MN-HA path. 365 In order to communicate with a correspondent node in the route 366 optimization mode, the mobile node needs to perform the return 367 routability procedure followed by the correspondent binding update 368 procedure. With the current Mobile IPv6 specification, the real home 369 address and the care-of address in the correspondent Binding Update 370 message and payload packets are visible to eavesdroppers. Therefore, 371 in order to send and receive packets through the optimized route and 372 protect location privacy at the same time, the mobile node needs to 373 disclose its care-of address and conceal its real home address. 374 There are two different scenarios and we propose a different solution 375 for each scenario. 377 One scenario is that the correspondent node is able to obtain the 378 mobile node's real home address and initiates communication with the 379 mobile node by using the real home address. In this case, the mobile 380 node needs to continue to use the real home address with the 381 correspondent node in order to maintain session continuity, and to 382 conceal the real home address from eavesdroppers. The solution for 383 this scenario (hereinafter referred to as "reverse-tunneled 384 correspondent binding update") is described in Section 5. With this 385 solution, the mobile node exchanges the same return routability 386 signaling messages as defined in RFC 3775 with the correspondent node 387 and then derives a privacy management key from keygen tokens and uses 388 this key to encrypt the real home address. Finally, it reverse- 389 tunnels an extended correspondent Binding Update message via the home 390 agent to register the encrypted home address and the real home 391 address at the correspondent node. After the correspondent 392 registration, the mobile node and the correspondent node use the 393 registered encrypted home address, instead of the real home address 394 in payload packets exchanged via the optimized route. The encrypted 395 home address is different for different correspondent nodes since the 396 privacy management key would be different. 398 The other scenario is that the mobile node prefers to conceal its 399 real home address to both the correspondent node and the 400 eavesdroppers (typically the mobile node initiates communication in 401 this case, since the correspondent node does not know the real home 402 address). The solution for this scenario is described in 403 Section 6.2. With this solution, the mobile node first obtains a 404 home keygen token generated based on the pseudo home address during 405 the home address test procedure. Subsequently, the mobile node sends 406 the correspondent Binding Update message to register the binding 407 between the pseudo home address and the care-of address at the 408 correspondent node via the optimized route. After the correspondent 409 registration, the mobile node and the correspondent node use the 410 registered pseudo home address, instead of the real home address, in 411 payload packets exchanged via the optimized route. Note that the use 412 of the pseudo home address is completely transparent to the 413 correspondent node. 415 Furthermore, it is feasible to throttle "profiling" on the pseudo 416 home address by using a combination of these two solutions. That is, 417 the mobile node uses the pseudo home address in the extended home 418 address test procedure to obtain a home keygen token; then it uses 419 the pseudo home address instead of the real home address in the 420 reverse-tunneled correspondent binding update procedure. With this 421 solution, the encrypted pseudo home address used in route optimized 422 payload packets looks different to eavesdroppers each time, after a 423 new round of the return routability procedure is completed. 425 Before a pseudo home address is used with a correspondent node, it 426 MUST be registered with the home agent during the home registration 427 procedure. The mobile node indicates the requested pseudo home 428 address in a new mobility option, called Pseudo Home Address option 429 (see Section 7.3), carried in the home Binding Update message, and 430 the home agent indicates the status of pseudo home address 431 registration in another new mobility option, called Pseudo Home 432 Address Acknowledgement option (see Section 7.4), carried in the home 433 Binding Acknowledgement message. The pseudo home address MUST be 434 routable in order for the home agent to intercept packets destined at 435 this pseudo home address. It is statistically difficult for other 436 nodes to derive the real home address from the pseudo home address. 437 A detailed description of pseudo home address generation is provided 438 in Section 6.1.1.1. 440 With extensions introduced in this document, a mobile node is able to 441 discover whether the home agent and the correspondent node support 442 the location privacy solutions or not. When present in the home 443 Binding Update message, the Pseudo Home Address mobility option 444 indicates that the mobile node requests the use of the location 445 privacy solutions. If such a Binding Update message is valid and the 446 home agent supports the location privacy solutions for this 447 particular mobile node, it responds with the Pseudo Home Address 448 Acknowledgement mobility option in the Binding Acknowledgement 449 message. Otherwise, if the home agent does not support the location 450 privacy solutions, it does not include the Pseudo Home Address 451 Acknowledgement mobility option in the Binding Acknowledgement 452 message. Similarly, the presence of the Encrypted Home Address 453 destination option in the correspondent Binding Update message 454 indicates to the correspondent node that the mobile node requests the 455 use of the location privacy solutions. If such a Binding Update 456 message is valid and the correspondent node supports the location 457 privacy solutions for this particular mobile node, it responds with 458 the Encrypted Home Address routing header in the correspondent 459 Binding Acknowledgement message to the mobile node. If the 460 correspondent node does not support the location privacy solutions, 461 it rejects the mobile node's request by returning an ICMP Parameter 462 Problem message with Code value set to 2. Furthermore, a home agent 463 that recognizes such extensions but does not wish to provide location 464 privacy protection MAY redirect the mobile node to another home 465 agent. If the request for using the location privacy solutions is 466 rejected, the mobile node may either proceed without location privacy 467 protection, or try with a different home agent or a correspondent 468 node, or abort the operation. 470 5. Reverse-Tunneled Correspondent Binding Update 472 In this section, we describe a solution that protects location 473 privacy against eavesdroppers when the mobile node uses the real home 474 address during communication with the correspondent node via the 475 optimized route. Note that this solution does not require any change 476 to return routability signaling messages. The detailed description 477 is provided as follows. 479 5.1. The Procedure 481 After the return routability procedure is completed, if the mobile 482 node needs to protect location privacy, and at the same time still 483 uses the real home address with the correspondent node, the mobile 484 node derives a privacy management key, Kpm, from the Kbm, Kpm = 485 HMAC_SHA1 (Kbm, 0). The mobile node uses Kpm to generate the 486 encrypted home address as follows. 488 encrypted home address = Enc(Kpm, the home address) 490 Where Enc(.) is a symmetric key encryption algorithm. AES is the 491 default encryption algorithm. 493 Kpm changes upon every change of Kbm, which itself changes when 494 return routability is run (e.g., upon change of care-of address, 495 expiry of keygen token etc.). So, Kpm is not re-used when a care-of 496 address changes. 498 The mobile node generates a correspondent Binding Update message and 499 reverse-tunnels this message to the correspondent node via the home 500 agent. The format of this message after encapsulation is: 502 IPv6 header (source = care-of address, 503 destination = home agent) 504 ESP header in tunnel mode 505 IPv6 header (source = home address, 506 destination = correspondent node) 507 Destination option header 508 Encrypted Home Address option (encrypted home address) 509 Parameters: 510 Alternative Care-of Address option (care-of address) 511 sequence number (within the Binding Update message header) 512 home nonce index (within the Nonce Indices option) 513 care-of nonce index (within the Nonce Indices option) 514 First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent 515 | BU))) 517 This packet is protected by the IPsec security association with a 518 non-null encryption algorithm. If the home agent can process this 519 packet successfully, it forwards the following packet to the 520 correspondent node. 522 IPv6 header (source = home address, 523 destination = correspondent node) 524 Destination option header 525 Encrypted Home Address option (encrypted home address) 526 Parameters: 527 Alternative Care-of Address option (care-of address) 528 sequence number (within the Binding Update message header) 529 home nonce index (within the Nonce Indices option) 530 care-of nonce index (within the Nonce Indices option) 531 First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent 532 | BU))) 534 After receiving a reverse-tunneled correspondent Binding Update 535 message, the correspondent node performs the operation as described 536 in Section 5.5. If the correspondent Binding Update message is 537 processed successfully and an acknowledgement is requested, the 538 correspondent node constructs a Binding Acknowledgement message shown 539 below. 541 IPv6 header (source = correspondent node, 542 destination = home address) 543 Encrypted Home Address Routing Header 545 IPv6 header (source = correspondent node, 546 destination = home address) 547 Encrypted Home Address Routing Header 549 Upon receiving this Binding Acknowledgement message, the home agent 550 applies the IPsec security association with a non-null encryption 551 algorithm to this message and forwards the following packet to the 552 mobile node. 554 IPv6 header (source = home agent, 555 destination = care-of address) 556 ESP header in tunnel mode 557 IPv6 header (source = correspondent node, 558 destination = home address) 559 Encrypted Home Address Routing Header 561 IPv6 header (source = home agent, 562 destination = care-of address) 563 ESP header in tunnel mode 564 IPv6 header (source = correspondent node, 565 destination = home address) 566 Encrypted Home Address Routing Header 568 The reverse-tunneled correspondent binding update procedure is 569 completed after the mobile node processes the received Binding 570 Acknowledgement message. Note that when the mobile node communicates 571 with a different correspondent node, the encrypted home address looks 572 different. 574 To delete an established Binding Cache entry at the correspondent 575 node, the mobile node reverse-tunnels the following Binding Update 576 message via the home agent. Note that the Encrypted Home Address 577 option is optional during the correspondent binding de-registration 578 and only the home keygen token is used to generate Kbm and Kpm, if 579 needed, in this case. 581 IPv6 header (source = care-of address, 582 destination = home agent) 583 ESP header in tunnel mode 584 IPv6 header (source = home address, 585 destination = correspondent node) 586 Destination option header (optional) 587 Encrypted Home Address option (encrypted home address) 588 Parameters: 589 Alternative Care-of Address option (care-of address) 590 sequence number (within the Binding Update message header) 591 home nonce index (within the Nonce Indices option) 592 care-of nonce index (within the Nonce Indices option) 593 First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent 594 | BU))) 596 If an acknowledgement is requested, the correspondent node returns 597 the following Binding Acknowledgement message to the mobile node. 599 IPv6 header (source = correspondent node, 600 destination = home address) 601 Encrypted Home Address Routing Header (optional) 603 IPv6 header (source = correspondent node, 604 destination = home address) 605 Encrypted Home Address Routing Header (optional) 607 Since the destination IP address in this message is the home address, 608 the home agent will receive this message and forward it to the mobile 609 node via the reverse tunnel. 611 5.2. Route Optimized Payload Packets 613 After the correspondent registration is completed successfully, 614 subsequent payload packets are exchanged via the optimized route 615 between the mobile node and the correspondent node. In such packets, 616 only the encrypted home address carried in the Encrypted Home Address 617 destination option and the Encrypted Home Address routing header are 618 visible to eavesdroppers. 620 The format of payload packets sent from the mobile node to the 621 correspondent node is: 623 IPv6 header (source = care-of address, 624 destination = correspondent node) 625 Destination option header 626 Encrypted Home Address option (encrypted home address) 627 Payload 629 The format of payload packets sent from the correspondent node to the 630 mobile node is: 632 IPv6 header (source = correspondent node, 633 destination = care-of address) 634 Encrypted Home Address Routing header 636 IPv6 header (source = correspondent node, 637 destination = care-of address) 638 Encrypted Home Address Routing header 640 5.3. Mobile Node Operation 642 5.3.1. Conceptual Data Structures 644 The Binding Update List entry for the correspondent registration is 645 extended with a new field to store the current encrypted home address 646 used with a particular correspondent node. The encrypted home 647 address is stored when the mobile node sends a reverse-tunneled 648 correspondent Binding Update message, and the state of the 649 corresponding Binding Update List entry is updated when the mobile 650 node successfully processes the correspondent Binding Acknowledgement 651 message. Note that the encrypted home address field is not valid in 652 the Binding Update List entry for the home registration. 654 Given that the encrypted home address is 128 bit long, it is expected 655 that each encrypted home address or the combination of the encrypted 656 home address and the correspondent node's IP address stored in the 657 Binding Update List is unique. Therefore the mobile node can use the 658 encrypted home address or together with the correspondent node's IP 659 address as a primary key to look up the Binding Update List. 661 5.3.2. Reverse-tunneled Correspondent Binding Update to the 662 Correspondent Node 664 After the return routability procedure, if the mobile node chooses to 665 use the location privacy solution with the correspondent node, e.g. 666 based on its configuration, it generates the encrypted home address, 667 updates or creates a new correspondent Binding Update List entry to 668 store the encrypted home address, then forwards the correspondent 669 Binding Update message through the reverse tunnel established with 670 the home agent. Note that the MAC is generated in the same way as 671 specified in RFC 3775 and it does not cover the encrypted home 672 address. 674 5.3.3. Reverse-tunneled Correspondent Binding Acknowledgement from the 675 Correspondent Node 677 When the mobile node receives a Binding Acknowledgement message from 678 the correspondent node in response to a previously sent reverse- 679 tunneled correspondent Binding Update message, if this Binding 680 Acknowledgement message contains an Encrypted Home Address routing 681 header, the mobile node considers that the correspondent node 682 supports the location privacy solution. The mobile node 683 authenticates this message based on RFC 3775. If succeed, the mobile 684 node decrypts the encrypted home address and compares the result with 685 the real home address, or compares the encrypted home address with 686 the one stored in the Binding Update List entry. If they match, the 687 mobile node considers that the correspondent registration is 688 successful and updates the state of the corresponding Binding Update 689 List entry. If they do not match, the mobile node MAY start the 690 correspondent binding update procedure again. 692 5.3.4. Route Optimized Payload Packets 694 In order to maintain session continuity, upper layers of the IP stack 695 in the mobile node still use the real home address, even after the 696 reverse-tunneled correspondent registration. 698 A possible way of implementation is as follows. When the Mobile IP 699 sublayer at the mobile node receives a packet from the upper layer, 700 the normal processing as specified in RFC 3775 is performed. 701 Subsequently, the Home Address option is replaced with the Encrypted 702 Home Address option carrying the encrypted home address stored in the 703 corresponding Binding Update List entry, and then the mobile node 704 forwards the packet to the correspondent node via the optimized 705 route. 707 On the other hand, when the mobile node receives a payload packet 708 carrying the Encrypted Home Address routing header, the mobile node 709 uses the encrypted home address (optionally together with the IP 710 address of the correspondent node) to look up the Binding Update 711 List. If an entry is found, the mobile node accepts this packet, 712 replaces the Encrypted Home Address option with the Home Address 713 option carrying the real home address and continue with processing 714 based on RFC 3775. If no entry is found, the mobile node silently 715 drops the received packet. 717 5.3.5. Receiving ICMP Error Message 719 The mobile node may receive an ICMP Parameter Problem, Code 2, 720 message forwarded by the home agent via the bi-directional tunnel, 721 for example, when the correspondent node does not support the use of 722 the Encrypted Home Address option. If such a message is received, 723 the mobile node SHOULD not attempt to use the location privacy 724 solution with the correspondent node. The mobile node may choose 725 either not to communicate with the correspondent node, or to 726 communicate without location privacy protection. 728 5.3.6. Binding Error from the Correspondent Node 730 When the mobile node communicates with a correspondent node by using 731 the encrypted home address, a Binding Error message with the Status 732 field set as 1 (unknown binding for Home Address destination option) 733 may be received by the mobile node if there is no valid Binding Cache 734 entry established at the correspondent node. Note that we do not 735 specify a new Status value to be used in this case because the 736 implementation of the Binding Update List entry can contain an 737 indication of whether an encrypted home address is currently used 738 with the correspondent node. Upon receiving the Binding Error 739 message, the mobile node can find out which encrypted home address is 740 invalid by looking at the Home Address field of the Binding Error 741 message. The mobile node may then perform the correspondent binding 742 update procedure to establish a valid binding for the encrypted home 743 address. 745 5.3.7. Binding Refresh Request from the Correspondent Node 747 When the mobile node receives a Binding Refresh Request message sent 748 from the correspondent node and forwarded by the home agent via the 749 bi-directional tunnel, the mobile node needs to perform the 750 correspondent binding update procedure to refresh the binding for the 751 encrypted home address at the correspondent node. 753 5.4. Home Agent Operation 755 With the solution described in this section (i.e., Section 5), there 756 is no new home agent operation to be specified. That is, the home 757 agent behaves based on RFC 3775 when processing signaling or data 758 packets. 760 5.5. Correspondent Node Operation 762 5.5.1. Conceptual Data Structures 764 The Binding Cache entry is extended with a new field to store the 765 current encrypted home address used with a particular mobile node. 766 The encrypted home address is stored when the correspondent node 767 successfully processes a reverse-tunneled correspondent Binding 768 Update message. 770 Given that the encrypted home address is 128 bit long, it is expected 771 that each encrypted home address or the combination of the care-of 772 address and the encrypted home address stored in the Binding Cache 773 entry is unique. Therefore the correspondent node can use the 774 encrypted home address or together with the care-of address as a 775 primary key to look up the Binding Cache. 777 5.5.2. Reverse-tunneled Correspondent Binding Update from the Mobile 778 Node 780 When receiving a reverse-tunneled Binding Update message with the 781 Encrypted Home Address option, if the correspondent node supports the 782 location privacy solution, it verifies the message by using the same 783 method as defined in RFC 3775. If this verification succeeds, the 784 correspondent node generates Kpm and uses it to decrypt the encrypted 785 home address, and compares the result with the source IP address. If 786 they match, the correspondent node stores the encrypted home address 787 in the corresponding Binding Cache entry. 789 5.5.3. Reverse-tunneled Correspondent Binding Acknowledgement to the 790 Mobile Node 792 If an acknowledgement to the reverse-tunneled correspondent Binding 793 Update message is requested by the mobile node, the correspondent 794 node returns a Binding Acknowledgement message with the Encrypted 795 Home Address routing header , if it supports the location privacy 796 solution. The MAC in the Binding Acknowledgement message is 797 generated in the same way as specified in RFC 3775 and does not cover 798 the encrypted home address carried in the Encrypted Home Address 799 routing header. 801 5.5.4. Route Optimized Payload Packets 803 In order to maintain session continuity, upper layers of the IP stack 804 in the correspondent node still use the real home address, even after 805 the reverse-tunneled correspondent registration. 807 A possible way of implementation is as follows. When the IP layer at 808 the correspondent node finishes processing the packet received from 809 the upper layer based on RFC 3775, the Type 2 routing header together 810 with the real home address therein is replaced with the Encrypted 811 Home Address routing header with the encrypted home address found in 812 the corresponding Binding Cache entry. Then this packet is forwarded 813 to the mobile node via the optimized route. 815 On the other hand, when the correspondent node receives a payload 816 packet with the Encrypted Home Address option, it uses the encrypted 817 home address (optionally together with the care-of address of the 818 mobile node) to look up the Binding Cache. If there is an entry, the 819 correspondent node replaces the Encrypted Home Address option with 820 the Home Address option carrying the real home address before 821 forwarding the packet to the upper layer. If no matching entry is 822 found, the correspondent node sends a Binding Error message to the 823 source IP address, i.e., the care-of address of the mobile node. 825 5.5.5. ICMP Error Message to the Mobile Node 827 When receiving a reverse-tunneled correspondent Binding Update 828 message with the Encrypted Home Address option, if the correspondent 829 node does not support location privacy extensions, it sends an ICMP 830 Parameter Problem, Code 2, message to the source IP address (i.e., 831 the home address of the mobile node) and the home agent then forwards 832 this ICMP message to the mobile node via the bi-directional tunnel. 834 5.5.6. Binding Error to the Mobile Node 836 When the correspondent node receives a payload packet with the 837 Encrypted Home Address option for which there is no valid Binding 838 Cache entry, it returns a Binding Error message with the Status code 839 set as 1 back to the source IP address of the packet. Furthermore, 840 the Home Address field in the Binding Error message MUST be copied 841 from the Encrypted Home Address field in the Encrypted Home Address 842 destination option of the offending packet, or set to the unspecified 843 address if no such option appears in the packet. 845 5.5.7. Binding Refresh Request to the Mobile Node 847 When the correspondent node realizes that a Binding Cache entry is 848 about to expire, it sends a Binding Refresh Request message to the 849 real home address of the mobile node stored in the Binding Cache 850 entry. 852 5.6. Summary 854 With the solution in Section 5, the real home address is visible in 855 the Binding Update and Binding Acknowledgment messages along the 856 HA-CN path. Like Mobile IPv6 itself, it has not been designed to 857 change the communications between the home network and the 858 correspondent node; the same issues would affect non-mobile hosts as 859 well. This solution meets all the requirements set forth for the 860 location privacy solutions and provides a simple way to provide 861 location privacy protection while allowing the use of the real home 862 address with the correspondent node. 864 6. IP Address Location Privacy Solution Using the Pseudo Home Address 866 6.1. Home Binding Update 868 When the mobile node attaches to a foreign link, it first performs 869 the home binding update procedure for the real home address with the 870 home agent, as specified in RFC 3775. For hiding the real home 871 address, we require the use of IPsec ESP in tunnel mode. In order to 872 provide location privacy, a non-null encryption transform must be 873 used so that the real home address is encrypted and encapsulated, and 874 made invisible to eavesdroppers on the MN-HA path. The packet 875 formats and processing rules are the same as specified in RFC 3775 876 and RFC 4877. 878 6.1.1. Pseudo Home Address Registration 880 6.1.1.1. Generation 882 To protect location privacy in the route optimization mode, the 883 mobile node replaces the real home address used in certain signaling 884 and payload packets with the pseudo home address. Different from the 885 encrypted home address, the pseudo home address needs to be routable 886 so that the home agent can intercept packets with the pseudo home 887 address used as the destination address. The pseudo home address is 888 generated by concatenating one of the home network prefixes with a 889 random bit string. There are many ways to generate such a random bit 890 string, for example, by using a random number generator or a secure 891 encryption or hash algorithm. 893 Using the pseudo home address instead of the real home address even 894 in return routability and binding update to the correspondent has the 895 following advantages. First, the pseudo home address does not reveal 896 the identity of a mobile node since it is not (or should not be) 897 publicly known. Hence, the signaling on the HA-CN is path is more 898 secure since attackers will not be able to determine the identity of 899 the mobile node based on the pseudo home address. Second, the mobile 900 node can communicate with a correspondent without disclosing its real 901 home address. Finally, the chosen pseudo home address can be 902 different with different correspondents for both signaling and data 903 traffic purposes. 905 The prefix used to form the pseudo home address MUST be managed by 906 the same home agent so that it can forward the return routability 907 messages. Even though it does not have to be the same as that used 908 in the real home address, the prefix is highly recommended to be 909 different. For instance, a home agent may use a different prefix 910 pool for location privacy purposes for a set of mobile nodes. This 911 ensures that the real home address and the pseudo home address are 912 not co-related (assuming the mobile node chooses different IIDs). 914 6.1.1.2. Registration 916 The mobile node MUST register the pseudo home address to be used with 917 the home agent before actually using it with a correspondent node. 918 To do so, the mobile node indicates a pseudo home address in the 919 Pseudo Home Address mobility option in the Binding Update message 920 sent to the home agent. If the home agent supports the location 921 privacy solution, it performs the Duplicate Address Detection to 922 detect whether this pseudo home address conflicts with other pseudo 923 home addresses submitted from different mobile nodes. Based on the 924 result, the home agent indicates whether to accept the pseudo home 925 address by setting the appropriate status code in the Pseudo Home 926 Address Acknowledgement option in the Binding Acknowledgement 927 message. If the home agent prefers the use of a different home 928 network prefix from that of the requested pseudo home address, the 929 home agent returns the new pseudo home address in the Pseudo Home 930 Address Acknowledgement Mobility option to the mobile node. 932 The mobile node MAY register the pseudo home address when it is about 933 to communicate with a correspondent node with location privacy 934 protection. The default lifetime of registered pseudo home addresses 935 is the same as the Home Binding Cache entry; however a mobile node 936 may choose any value and a home agent may grant any value. The 937 mobile node can add or delete any pseudo home address by using the 938 Pseudo Home Address mobility option in the home Binding Update 939 message. The home agent does not have to recover the real home 940 address from the pseudo home address. 942 6.1.2. Home De-registration 944 When the mobile node returns to its home link, the home de- 945 registration procedure is the same as specified in RFC 3775, i.e., 946 the real home address is used as the source IP address in the Binding 947 Update message and the destination IP address in the Binding 948 Acknowledgement message. The de-registration of the real home 949 address results in automatic de-registration of all pseudo home 950 addresses. When the mobile node decides to disconnect from the home 951 agent while at its foreign link, the format of the Binding Update and 952 Acknowledgement is the same as that defined for the home 953 registration, except that the Lifetime field is set to zero. The 954 home agent deletes the corresponding Binding Cache entry including 955 the registered pseudo home address, if any. 957 6.2. Correspondent Binding Update Using the Pseudo Home Address 959 6.2.1. Return Routability Procedure 961 The location privacy solution specified in this section does not 962 introduce any change to the care-of address test procedure as 963 specified in RFC 3775. In the following, we highlight the extensions 964 to the home address test procedure, during which the mobile node 965 obtains a home keygen token generated based on the pseudo home 966 address. 968 The mobile node generates and sends a Home Test Init message to the 969 home agent. The format of this message is: 971 IPv6 header (source = care-of address, destination = home agent) 972 ESP header in tunnel mode 973 IPv6 header (source = home address, destination = correspondent) 974 Mobility Header (HoTI) 975 Home Init Cookie 976 Pseudo Home Address Mobility Option (pseudo home address) 978 The difference from what is specified in RFC 3775 is that the mobile 979 node includes a Pseudo Home Address mobility option (see Section 7.3) 980 in the Home Test Init message. A new option for carrying the pseudo 981 home address is necessary because the the security association 982 between the mobile node and the home agent is based on the real home 983 address. The pseudo home address contained in the Pseudo Home 984 Address option is selected by the mobile node from a set of pseudo 985 home addresses that have been registered with the home agent during 986 the home registration procedure. Note that the Home Test Init 987 message is protected by an IPsec security association in the ESP 988 tunnel mode with a non-null encryption algorithm and a non-null 989 authentication algorithm, as specified in RFC 3776. 991 When receiving a Home Test Init message, the home agent performs the 992 operation as specified in Section 6.6.4. If this operation succeeds 993 when the Pseudo Home Address mobility option is present in the Home 994 Test Init message, the home agent generates a Home Test Init message 995 and forwards to the correspondent node. As shown in the following, 996 the pseudo home address carried in the Pseudo Home Address mobility 997 option is used as the source IP address in the forwarded Home Test 998 Init message. 1000 IPv6 header (source = pseudo home address, destination = correspondent) 1001 Mobility Header (HoTI) 1002 Home Init Cookie 1004 The forwarded Home Test Init message looks the same to the 1005 correspondent node as what is specified in RFC 3775 and the 1006 correspondent node does not realize that the pseudo home address is 1007 used, and just generates a home keygen token using the same algorithm 1008 as specified in RFC 3775. 1010 home keygen token = 1011 First (64, HMAC_SHA1 (Kcn, (pseudo home address | nonce | 0))) 1013 The correspondent node then replies with a Home Test message. As 1014 shown in the following, the format of this message is the same as 1015 that specified in RFC 3776 and the pseudo home address is used as the 1016 destination IP address. 1018 IPv6 header (source = correspondent, destination = pseudo home address) 1019 Mobility Header (HoT) 1020 Home Init Cookie 1021 Home Keygen Token 1022 Home Nonce Index 1024 When the home agent intercepts the Home Test message using proxy 1025 Neighbor Discovery, it performs the operation as specified in 1026 Section 6.6.5. If this operation succeeds, the home agent generates 1027 the following Home Test message and forwards to the mobile node. 1029 IPv6 header (source = home agent, destination = care-of address) 1030 ESP header in tunnel mode 1031 IPv6 header (source = correspondent, destination = home address) 1032 Mobility Header (HoT) 1033 Home Init Cookie 1034 Home Keygen Token 1035 Home Nonce Index 1036 Pseudo Home Address Acknowledgement Mobility Option (pseudo home address) 1038 When the mobile node receives the Home Test message, it performs 1039 operation as specified in Section 6.5.5. If such operation succeeds, 1040 the mobile node obtains a home keygen token computed using the pseudo 1041 home address. After the care-of address test is completed, the 1042 mobile node hashes the care-of keygen token and the home keygen token 1043 together to generate Kbm using the same method as specified in RFC 1044 3775. 1046 6.2.2. Route Optimized Correspondent Binding Update 1048 In this procedure, the mobile node MUST use the same pseudo home 1049 address used during the home address test procedure. The pseudo home 1050 address is carried in the Home Address option in the correspondent 1051 Binding Update message. 1053 IPv6 header (source = care-of address, destination = correspondent) 1054 Destination option header 1055 Home Address destination option (pseudo home address) 1056 Parameters 1057 sequence number (within the Binding Update message header) 1058 home nonce index (within the Nonce Indices option) 1059 care-of nonce index (within the Nonce Indices option) 1060 First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent 1061 | BU))) 1063 When the correspondent node receives the Binding Update message, it 1064 performs the same operation as specified in RFC 3775. If such 1065 operation succeeds and an acknowledgement is requested by the mobile 1066 node, the correspondent node replies with the following Binding 1067 Acknowledgement message. 1069 IPv6 header (source = correspondent, destination = care-of 1070 address) 1071 Parameters 1072 sequence number (within the Binding Update message header) 1073 First (96, HMAC_SHA1 (Kbm, (care-of address | correspondent 1074 | BA))) 1076 After the mobile node receives the Binding Acknowledgement message 1077 indicating that the correspondent registration succeeds, the mobile 1078 node can now use the pseudo home address for communicating with the 1079 correspondent node. 1081 Such a Binding Update message may also be used by the mobile node to 1082 delete a previously established binding at the correspondent node. 1083 In this case, similar to what is specified in RFC 3775, Kbm is 1084 generated exclusively from the home keygen token that is based on the 1085 pseudo home address. 1087 6.2.3. Reverse-tunneled Correspondent Binding Update 1089 The mobile node may choose to use reverse tunneling for sending the 1090 Binding Update. The format of messages during such a procedure is 1091 similar to what is described in Section 5 and Section 6.2.1, except 1092 that a pseudo home address is used in place of the real home address. 1093 The Encrypted Home Address destination and the Encrypted Home Address 1094 routing header SHOULD be used to carry the encrypted pseudo home 1095 address. 1097 6.2.4. Using Different Pseudo Home Addresses with Different 1098 Correspondent Nodes 1100 Based on its configuration and policy, the mobile node can choose to 1101 use the same or different pseudo home addresses when communicating 1102 with different correspondent nodes. Using a different pseudo home 1103 address with each correspondent node may help prevent the mobile 1104 node's activities from being linked and correlated. To do so, the 1105 mobile node selects a different but already registered pseudo home 1106 address and repeats the return routability procedure and the 1107 correspondent binding update procedure with each correspondent node. 1109 In addition, if the mobile node prefers, it MAY use different pseudo 1110 home addresses for different sessions with the same correspondent 1111 node. This typically requires additional configuration at the mobile 1112 node that associates a specific session (for example, identified by 1113 the port number and the protocol number among others) with a specific 1114 pseudo home address. This document does not address details of this 1115 solution. 1117 6.3. Payload Packets 1119 6.3.1. Reverse Tunneling Mode 1121 The format of payload packets reverse-tunneled via the home agent is 1122 the same as that specified for the home address test procedure in 1123 Section 6.2.1. 1125 6.3.2. Route Optimization Mode 1127 When the route optimized correspondent binding update procedure is 1128 performed, the format of payload packets exchanged between the mobile 1129 node and the correspondent node is the same as specified in RFC 3775. 1130 The operation of the mobile node when communicating with the 1131 correspondent node via the route optimization mode is described in 1132 Section 6.5.6. 1134 When the reverse tunneled correspondent binding update procedure is 1135 performed, the format of payload packets exchanged between the mobile 1136 node and the correspondent node is the same as specified in Section 1137 5, except that the encrypted pseudo home address SHOULD be included 1138 in the Encrypted Home Address destination option and the Encrypted 1139 Home Address routing header. 1141 6.4. Prefix Discovery 1143 The solution to protect location privacy during the prefix discovery 1144 procedure is similar to that used during the home binding update 1145 procedure. 1147 6.5. Mobile Node Operation 1149 In this section, we describe the mobile node's operation when the 1150 location privacy solution is used. 1152 6.5.1. Conceptual Data Structures 1154 6.5.1.1. Pseudo Home Address Table 1156 We introduce a new data structure, called Pseudo Home Address table, 1157 to record the information of pseudo home addresses. The mobile node 1158 may maintain a Pseudo Home Address table for each home agent it 1159 registers with. Each entry in the table contains a pseudo home 1160 address and its associated state, i.e., "unconfirmed" or "confirmed". 1161 The mobile node creates or updates entries in the Pseudo Home Address 1162 table when sending the home Binding Update message or receiving the 1163 home Binding Acknowledgement message. The pseudo home address can be 1164 used as a key to search the table. There MUST NOT be any duplicated 1165 pseudo home addresses stored in the Pseudo Home Address table. 1167 6.5.1.2. Binding Update List 1169 The Binding Update List entry is extended with a field, called Pseudo 1170 Home Address. This field MAY be implemented as a pointer that points 1171 to a corresponding entry in the Pseudo Home Address table. This 1172 pointer is initialized as NULL when the Binding Update List entry is 1173 created (for example, when the mobile node sends a Binding Update 1174 message or a Home Test Init message to the home agent). For the 1175 binding sent to a specific home agent, the Pseudo Home Address field 1176 points to the first entry in the Pseudo Home Address table (or NULL 1177 if the table is empty), so that the mobile node can access all the 1178 pseudo home addresses registered at this home agent; on the other 1179 hand, for the binding sent to a specific correspondent node, the 1180 Pseudo Home Address field points to the Pseudo Home Address table 1181 entry that contains the actual pseudo home address used with this 1182 correspondent node (or NULL if no pseudo home address is used with 1183 this correspondent node). 1185 6.5.2. Binding Update to the Home Agent 1187 The mobile node may decide to perform the home registration with 1188 location privacy protection, for example, when it attaches to a 1189 foreign link or when it needs to extend the lifetime of a registered 1190 home binding. 1192 Since IPsec tunnel mode is used, the mobile node MUST negotiate a 1193 non-null encryption algorithm (for example, during the bootstrapping) 1194 and use it to protect the home Binding Update message as specified in 1195 RFC 3775 and RFC 4877. In addition, the mobile node can register a 1196 pseudo home address as described above. If the mobile node does not 1197 wish to register the pseudo home address at this point, but wishes to 1198 discover whether the home agent supports the location privacy 1199 solution, the mobile node includes a Pseudo Home Address mobility 1200 option without the Pseudo Home Address field in the Binding Update 1201 message sent to the home agent. 1203 After sending the home de-registration binding update message, in 1204 addition to the operation specified in RFC 3775, the mobile node MUST 1205 stop using any data structure specific to the location privacy 1206 solution and MAY delete them after the Binding Acknowledgement 1207 message is processed successfully. 1209 6.5.3. Binding Acknowledgement from the Home Agent 1211 With IPsec tunnel mode, the mobile node follows the rules specified 1212 in RFC 3775 and RFC 4877 to processing the Binding Acknowledgement 1213 message. 1215 In addition, if one or more Pseudo Home Address Acknowledgement 1216 mobility options are present in the Binding Acknowledgement message, 1217 the mobile node checks the Status field in each option. If the 1218 Status field in one option is 0 (Success), the pseudo home address, 1219 if not already present, is added into the Pseudo Home Address table, 1220 and the state of the corresponding entry is set to "confirmed". 1221 Otherwise, the mobile node deletes any existing pseudo home address 1222 with the "unconfirmed" state (i.e., either an error code or no 1223 acknowledgement for such a pseudo home address is received) from the 1224 Pseudo Home Address table. 1226 The mobile node considers that the home agent supports the location 1227 privacy solution, if a valid Pseudo Home Address Acknowledgement 1228 mobility option with or without a Pseudo Home Address field is 1229 received. 1231 Note that the mobile node MUST determine whether the home 1232 registration succeeds or not based on what is specified RFC 3775. 1234 6.5.4. Home Test Init to the Home Agent 1236 To enable location privacy protection during communication with the 1237 correspondent node in the route optimization mode, the mobile node 1238 generates a Home Test Init message based on what is specified in RFC 1239 3775 and RFC 3776. In addition, if the Return Routability procedure 1240 is for a new session with the correspondent node, the mobile node 1241 selects any pseudo home address from those already registered with 1242 the home agent and stored in the Pseudo Home Address table; 1243 otherwise, the mobile node must use the same pseudo home address as 1244 used with the same correspondent node before. The selected pseudo 1245 home address is carried in the Pseudo Home Address mobility option of 1246 the generated Home Test Init message. This Home Test Init message is 1247 protected by an IPsec security association with a non-null encryption 1248 algorithm. 1250 After sending the Home Test Init message to the home agent, if there 1251 is no Binding Update List entry existing for the correspondent node, 1252 the mobile node creates one entry that points to the pseudo home 1253 address used; otherwise, the mobile node updates the existing entry. 1255 6.5.5. Home Test from the Home Agent 1257 When the mobile node receives a Home Test message from the home 1258 agent, it processes the packet based on processing rules specified in 1259 RFC 3775 and RFC 3776. If this is a valid packet and there is a 1260 Pseudo Home Address Acknowledgement option included, the mobile node 1261 examines the Status field inside this mobility option as follows: 1263 o If the Status field indicates that the home address test procedure 1264 using the pseudo home address succeeds (the Status field is 0), in 1265 addition to what is specified in RFC 3775, the mobile node 1266 prepares to use the pseudo home address carried in the Pseudo Home 1267 Address Acknowledgement option for the correspondent registration. 1269 o If the Status field indicates that the home address test procedure 1270 using the pseudo home address fails (the Status field is larger 1271 than 127), the mobile node can take steps to correct the cause of 1272 the error and retransmit the Home Test Init message, subject to 1273 the re-transmission limit specified in RFC 3775. If this is not 1274 done or it fails, then the mobile node SHOULD record in its 1275 Binding Update List that the future home address test procedure 1276 SHOULD NOT use the pseudo home address with this correspondent 1277 node. 1279 6.5.6. Route Optimized Payload Packets 1281 After the mobile node completes the route optimized correspondent 1282 registration procedure using the pseudo home address, payload packets 1283 are sent to the correspondent node with the pseudo home address in 1284 the Home Address destination option. 1286 The packet processing rules when sending and receiving route- 1287 optimized packets is the same as in RFC 3775 except that pseudo home 1288 addresses are used. In addition, if encrypted pseudo home addresses 1289 are used, both the mobile node and the correspondent node need to 1290 replace the encrypted address with the pseudo home address before 1291 passing them to the upper layers. 1293 In case that the mobile node masks the pseudo home address and uses 1294 the reverse-tunneled correspondent binding update procedure, the 1295 mobile node performs the operation specified in Section 5.3.4, except 1296 that the pseudo home address rather than the real home address is 1297 expected. 1299 6.5.7. Receiving Binding Refresh Request 1301 When the Mobile Node receives a Binding Refresh Request message from 1302 a correspondent node, the destination IP address may be the pseudo 1303 home address. In this case, the mobile node needs to check the 1304 corresponding Binding Update List entry for the correspondent node. 1305 If the pseudo home address is invalid, the mobile node silently 1306 discards this message. Otherwise, the mobile node refreshes the 1307 binding with the correspondent node by using the same pseudo home 1308 address. 1310 6.6. Home Agent Operation 1312 In this section, we describe the home agent's operation when the 1313 location privacy solution is used. 1315 6.6.1. Conceptual Data Structures 1317 The Binding Cache entry is extended with a field that points to a 1318 list of currently accepted pseudo home addresses. Note that each 1319 registered pseudo home address MUST be unique and all the registered 1320 pseudo home addresses SHOULD be organized in such a way that the 1321 associated Binding Cache entry can be quickly located when a pseudo 1322 home address is used as the key to look up the Binding Cache. 1324 6.6.2. Binding Update from the Mobile Node 1326 If the received Binding Update message contains one or more Pseudo 1327 Home Address mobility options, the home agent MUST ignore such an 1328 option if it does not recognize it. If the home agent recognizes 1329 such an option, a Pseudo Home Address Acknowledgement mobility option 1330 is generated and some fields therein are set as follows: 1332 o If the Pseudo Home Address field received is empty, the Status 1333 field is set to 0 (Success) and the Pseudo Home Address field is 1334 empty. 1336 o If the Pseudo Home Address field received is set to all zero, the 1337 Status field is set is 0 (Success) and a pseudo home address 1338 SHOULD be included in the Pseudo Home Address field, if the home 1339 agent supports the dynamic pseudo home address assignment; 1340 otherwise, the Status field is set to 132 (Dynamic pseudo home 1341 address assignment not available) and the Pseudo Home Address 1342 field is empty. 1344 o The Pseudo Home Address field received may contain an IPv6 1345 address. If the format of such an IP address is incorrect, the 1346 Status field is set to 130 (Incorrect pseudo home address). If 1347 such an IP address is invalid, for example, the prefix is not a 1348 valid home network prefix or this is detected as a duplicated IP 1349 address, the Status field is set to 131 (Invalid pseudo home 1350 address). In both cases, the Pseudo Home Address field is empty. 1351 If the home agent suggests a different pseudo home address, the 1352 Status field is set to 0 (Success) and the new pseudo home address 1353 is included in the Pseudo Home Address field. Otherwise, if the 1354 home agent accepts the requested pseudo home address, the Status 1355 field is set as 0 (Success) and the same IP address is included in 1356 the Pseudo Home Address field. 1358 o If the home agent does not allow the mobile node to use the pseudo 1359 home address with the correspondent node, the Status field SHOULD 1360 be set as 129 (Administratively prohibited) and the Pseudo Home 1361 Address field is empty. 1363 o In case that the home agent does not accept the Pseudo Home 1364 Address mobility option for all other reasons, the Status field 1365 SHOULD be set as 128 (Failure, reason unspecified) and the Pseudo 1366 Home Address is empty. 1368 When receiving a Binding Update message protected with the IPsec 1369 tunnel mode, the home agent performs the operation specified in RFC 1370 4877. 1372 When receiving and successfully processing a Binding Update message 1373 for de-registration from the mobile node, in addition to what is 1374 specified in RFC 3775, the home agent MUST delete data structures 1375 related to the location privacy extension. 1377 6.6.3. Binding Acknowledgement to the Mobile Node 1379 When sending a Binding Acknowledgement message protected with the 1380 IPsec tunnel mode, the home agent performs the operation specified in 1381 RFC 4877. 1383 The processing rules related to the Pseudo Home Address 1384 Acknowledgement mobility option are described in Section 6.6.2. 1386 6.6.4. Home Test Init from the Mobile Node 1388 When receiving a Home Test Init message from the mobile node, the 1389 home agent first verifies this message based on the IPsec processing 1390 rules as specified in RFC 3776. If the verification fails, the home 1391 agent acts based on such IPsec processing rules. Otherwise, if the 1392 Pseudo Home Address option does not exist in the Home Test Init 1393 message, the home agent performs the operation as specified in RFC 1394 3775. Otherwise, the following operation is performed. 1396 1. The home agent looks up its Binding Cache by using the real home 1397 address as a key. If the pseudo home address carried in the 1398 Pseudo Home Address option does not match any pseudo home address 1399 associated with the corresponding Binding Cache entry (including 1400 when the Pseudo Home Address field is set as zero), it MUST 1401 reject the Home Test Init message by sending back a Home Test 1402 message including the Pseudo Home Address Acknowledgement option 1403 with the Status field set as 131 (Invalid pseudo home address). 1405 2. Otherwise, the home agent constructs a Home Test Init message 1406 with the pseudo home address as the source IP address, and 1407 forwards the Home Test Init message to the correspondent node. 1409 6.6.5. Home Test to the Mobile Node 1411 When the home agent intercepts a Home Test message using proxy 1412 Neighbor Discovery, if the destination IP address matches with one of 1413 the real home addresses, the home agent performs the operation as 1414 specified in RFC 3775. Otherwise, the home agent uses the 1415 destination IP address to look up the Binding Cache to find if there 1416 is a matched pseudo home addresses. If not, the home agent discards 1417 this message silently. When a matching pseudo home address is found, 1418 the home agent generates a Home Test message with a Pseudo Home 1419 Address Acknowledgement option and sends it to the mobile node. 1420 Inside the Pseudo Home Address Acknowledgement option, the Status 1421 field is set to zero (Success) and the Pseudo Home Address field is 1422 filled with the found pseudo home address. 1424 6.7. Correspondent Node Operation 1426 With the solution described in this section, when the correspondent 1427 node is involved in the route optimized correspondent binding update 1428 procedure, there is no new operation if only pseudo home addresses 1429 are used without encryption. This specification recommends using 1430 encrypted pseudo home addresses to thwart revealing any prefix 1431 information about a mobile node. The additional operations are the 1432 same as specified in Section 5.5, except that the pseudo home 1433 address, instead of the real home address, is used. 1435 7. Extensions to Mobile IPv6 1437 This section describes the experimental extensions to Mobile IPv6 1438 used in this documents. For experimentation purposes, the 1439 experimental IPv6 Option Type, the experimental IPv6 Routing Header 1440 Type, and the experimental Mobility Option Type as defined in RFC 1441 4727 and RFC 5096 can be used in the Encrypted Home Address 1442 Destination Option, the Encrypted Home Address Routing Header, the 1443 Pseudo Home Address Mobility Option and the Pseudo Home Address 1444 Acknowledgement Mobility Option. In the following, we describe the 1445 format of each extension for illustration purpose. 1447 7.1. Encrypted Home Address Destination Option 1449 This option is used in the Destination Option extension header (Next 1450 Header value = 60). 1452 0 1 2 3 1453 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Option Type | Option Length | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 | | 1458 + + 1459 | | 1460 + Encrypted Home Address + 1461 | | 1462 + + 1463 | | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 Option Type 1468 A type for identifying the use of the encrypted home address in 1469 this option. Implementations of this RFC can use the value 1470 0xFE. This value is reserved in RFC 4727 for all experiments 1471 involving IPv6 destination options. 1473 Encrypted Home Address 1475 The encrypted home address generated from a either real or 1476 pseudo home address. 1478 The processing of other fields in the Encrypted Home Address option 1479 is the same as that of those fields in the Home Address option 1480 described in RFC 3775. Note that if the Encrypted Home Address 1481 option is present in a packet, the encrypted home address therein 1482 MUST NOT be treated as the real source IP address by the receiver. 1484 7.2. Encrypted Home Address Routing Header 1486 The encrypted home address is carried in this routing header. 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Next Header | Hdr Ext Len=2 | Routing Type |Segments Left=1| 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | | 1492 + + 1493 | | 1494 + Encrypted Home Address + 1495 | | 1496 + + 1497 | | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 Routing Type 1502 A type for identifying the use of the encrypted home address in 1503 this option. Implementations of this RFC can use the value 1504 0xFE. This value is reserved in RFC 4727 for all experiments 1505 involving IPv6 routing header. 1507 Encrypted Home Address 1509 The encrypted home address generated from a either real or 1510 pseudo home address. 1512 The processing of other fields in the Encrypted Home Address Routing 1513 Header is the same as described in RFC 3775. Note that if this 1514 routing header is present in a packet, the encrypted home address 1515 therein MUST NOT be treated as the real destination IP address by the 1516 receiver. 1518 7.3. Pseudo Home Address Mobility Option 1520 This mobility option is included in the mobility header, including 1521 the Binding Update message and the Home Test Init message, and 1522 carries zero or one pseudo home address. The alignment requirement 1523 for this option is 4n. 1525 0 1 2 3 1526 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Type | Length |A| Reserved | Prefix length | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | | 1531 + + 1532 | | 1533 + Pseudo Home Address + 1534 | | 1535 + + 1536 | | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 Type 1541 A unique type (together with the 'A' bit in the Reserved field) 1542 for identifying the Pseudo Home Address Acknowledgement 1543 mobility option. For experimental purpose, the value of this 1544 type is 18 as reserved in RFC 5096. 1546 Length 1548 The length of the Pseudo Home Address mobility option excluding 1549 the Type field and the Length field. It MUST be 2 when the 1550 Pseudo Home Address field is not present; otherwise, it MUST be 1551 18. 1553 Reserved Field 1555 The 'A' bit, which MUST be set to zero to indicate that this is 1556 a Pseudo Home Address mobility option. The rest of bits MUST 1557 be set as zero by the sender and ignored by the receiver. 1559 Prefix Length 1561 The length of the home network prefix of the included pseudo 1562 home address. When the Pseudo Home Address field is not 1563 present, the Prefix Length field MUST be set as zero. 1565 Pseudo Home Address 1567 If present, the field contains a pseudo home address that the 1568 mobile node wants to use for location privacy protection or 1569 zero if the mobile node requests a pseudo home address from the 1570 home agent. This field is not present, if the mobile node only 1571 intends to discover whether the home agent supports the 1572 location privacy solutions. The Length field is used to detect 1573 whether the Pseudo Home Address field is present in the Pseudo 1574 Home Address mobility option. 1576 7.4. Pseudo Home Address Acknowledgement Mobility Option 1578 This mobility option is included in the mobility header, including 1579 the Binding Acknowledgement message and the Home Test message sent to 1580 the mobile node, and carries zero or one pseudo home address. This 1581 mobility option is used to indicate the status of the pseudo home 1582 address registration and/or whether the home agent supports the 1583 location privacy solutions. The alignment requirement for this 1584 option is 2n. 1586 0 1 2 3 1587 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Type | Length | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 |A| Reserved | Prefix length | Status | Reserved | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | | 1594 + + 1595 | | 1596 + Pseudo Home Address + 1597 | | 1598 + + 1599 | | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 Type 1604 A unique type (together with the 'A' bit in the Reserved field) 1605 for identifying the Pseudo Home Address Acknowledgement 1606 mobility option. For experimental purpose, the value of this 1607 type is 18 as reserved in RFC 5096. 1609 Length 1611 The length of the Pseudo Home Address Acknowledgement mobility 1612 option excluding the Type field and the Length field. It MUST 1613 be 4 when the Pseudo Home Address field is not present; 1614 otherwise, it MUST be 20. 1616 Reserved 1618 The 'A' bit, which MUST be set to one to indicate that this is 1619 a Pseudo Home Address Acknowledgement mobility option. The 1620 rest of bits MUST be set as zero by the sender and ignored by 1621 the receiver. 1623 Prefix Length 1625 The length of the home network prefix of the included pseudo 1626 home address. When the Pseudo Home Address field is not 1627 present, the Prefix Length MUST be set as zero. 1629 Status 1631 It indicates the status of the pseudo home address 1632 registration. Values from 0 to 127 indicate success. Higher 1633 values indicate failure. The following values are reserved: 1635 0 Success 1636 128 Failure, reason unspecified 1637 129 Administratively prohibited 1638 130 Incorrect pseudo home address 1639 131 Invalid pseudo home address 1640 132 Dynamic pseudo home address assignment not available 1642 Reserved 1644 This field is reserved for future use. It MUST be set to zero 1645 by the sender and ignored by the receiver. 1647 Pseudo Home Address 1649 If present, the field contains a pseudo home address that the 1650 home agent registers for the mobile node to use for location 1651 privacy protection. This field is not present when the home 1652 agent only needs to indicate that it supports the location 1653 privacy solutions as a response to the query from the mobile 1654 node. The Length field is used to detect whether the Pseudo 1655 Home Address field is present in the Pseudo Home Address 1656 Acknowledgement mobility option. 1658 8. Security Consideration 1660 The solutions proposed in this document address one of the security 1661 issues in the mobile environment, i.e., location privacy. Throughout 1662 the document, we provide a detailed analysis of how the proposed 1663 solutions address the location privacy problem when describing them. 1664 We carefully design such solutions to make sure that they fit well 1665 into the Mobile IPv6 framework; therefore, the same threat analysis, 1666 security mechanisms (such as IPsec, the sequence number in binding 1667 signaling messages, the return routability procedure) and 1668 consideration as described in RFC 3775 still apply. Nevertheless, in 1669 the following we provide an in-depth analysis on security threats 1670 involving the use of the location privacy solutions and demonstrate 1671 that the proposed solutions do not introduce any new vulnerability or 1672 weaken the strength of security protection of the original Mobile 1673 IPv6 protocol. 1675 8.1. Home Binding Update 1677 Given the strong security of the cryptography algorithm used to 1678 generate the encrypted home address, eavesdroppers are unable to 1679 derive the real home address from the encrypted home address and thus 1680 to correlate the care-of address with the real home address. 1681 Moreover, the encrypted home address can be updated to prevent 1682 eavesdroppers from linking the mobile node's ongoing activities. 1684 During the pseudo home address registration, the home agent verifies 1685 that the requested pseudo home address is not in use by other mobile 1686 nodes; therefore the other mobile node cannot, inadvertently or 1687 maliciously, intercept ongoing sessions of a victim mobile node by 1688 registering the same pseudo home address. 1690 A mobile node may attempt to register a large number of pseudo home 1691 addresses which may exhaust the pool of available pseudo home 1692 addresses and prevent other mobile nodes using location privacy 1693 protection. The home agent MUST limit the number of pseudo home 1694 addresses that can be requested by a mobile node. Also with the 1695 IPsec security association between the home agent and the mobile 1696 node, if any misuse of the pseudo home address registration is 1697 detected, the home agent can identify the malicious mobile node and 1698 take further actions. 1700 8.2. Correspondent Binding Update 1702 The return routability procedure using the pseudo home address 1703 follows the same principle of the original return routability 1704 procedure, i.e., the message exchange verifies that the mobile node 1705 is reachable at both the pseudo home address and the care-of address 1706 (this is because the pseudo home address is required to be routable). 1707 Furthermore, the extended return routability procedure also utilizes 1708 the same security mechanisms as defined in RFC 3775, such as the 1709 nonce, the node key, and the sequence number, to protect against 1710 attacks. Overall, it provides the same security strength as the 1711 original return routability procedure. 1713 The reverse-tunneled correspondent binding update procedure does not 1714 weaken security either. Although the real home address is 1715 transferred in the cleartext on the HA-CN path, eavesdroppers on this 1716 path can already perform more serious attacks against the mobile node 1717 with the Mobile IPv6 protocol. 1719 8.3. Route-Optimized Payload Packets 1721 Using the Encrypted Home Address option in route optimized packets 1722 results in the same security implications when the Home Address 1723 option is used in such packets. For example, the Encrypted Home 1724 Address option may be used by attackers to launch reflection attacks, 1725 e.g. by indicating the IP address of a victim node in the Encrypted 1726 Home Address option. Similar to the processing rule for the Home 1727 Address option specified in RFC 3775, this document restricts the use 1728 of the Encrypted Home Address option: it can be used only if there is 1729 an established Binding Cache entry containing the encrypted (pseudo) 1730 home address. 1732 With the proposed location privacy solutions, the Encrypted Home 1733 Address routing header is used to carry the encrypted (pseudo) home 1734 address. The same threats specified in RFC 3775 for the Type 2 1735 routing header are also possible when the routing header carries the 1736 encrypted (pseudo) home address. Similar processing rules are also 1737 used in this document to address such a threat: if the encrypted 1738 (pseudo) home address in the Encrypted Home Address routing header 1739 does not match with that stored in the Binding Update List entry, the 1740 packet will be dropped. 1742 9. Related Work 1744 Our work benefits from previous work and discussion on this topic. 1745 Similar to the concept of the pseudo home address, many drafts have 1746 proposed using a temporary identity to replace the mobile node's home 1747 address in the IPsec security association, Mobile IPv6 signaling 1748 messages and data packets. However, the details of how to generate 1749 and update this identity are absent. In the following, we provide a 1750 survey of related work. 1752 RFC 3041 [10] specifies a mechanism to generate randomized interface 1753 identifiers, which can be used to update the care-of address and the 1754 home address. However, with our solution, the prefix of a pseudo 1755 home address can be different from that of the real home address and 1756 other pseudo home addresses, which prevents eavesdroppers from 1757 correlating and analyzing IP traffic based on a common prefix. 1758 Furthermore, we also discuss about the interval of IP address update 1759 in the mobility scenario in order to resist the profiling attack both 1760 effectively and efficiently. 1762 In [18], the authors propose using a temporary identity, called the 1763 Temporary Mobile Identifier (TMI), to replace the home address, and 1764 discussed the feasibility of utilizing the CBID/CGA/MAP to further 1765 protect location privacy. However, as a 128 bit random number, the 1766 TMI is not routable; therefore it is not suitable to be the source IP 1767 address in the Home Test Init message forwarded by the home agent to 1768 the correspondent node. Otherwise, the home agent cannot receive the 1769 Home Test message from the correspondent node. Furthermore, the 1770 draft does not specify how to update the TMI to address the profiling 1771 attack. 1773 In [16], the authors propose a mechanism that uses an identity as the 1774 home address and periodically updates such an identity by using a key 1775 and a previous identity as inputs to a cryptography algorithm. 1777 In [17], the authors propose to update the mobile node's home address 1778 periodically to hide its movement. The new home address is generated 1779 from the current local network prefix, the Binding Update session key 1780 and the previous home address, and updated every time when the return 1781 routability procedure is performed. The generated home address is 1782 random, routable, recognizable and recoverable. 1784 In [20], the authors propose a mechanism to achieve both route 1785 optimization and location privacy at the same time. This is done by 1786 discovering a tunneling agent near the correspondent node and bi- 1787 directionally tunneling data traffic between the mobile node and the 1788 tunneling agent. 1790 10. IANA Consideration 1792 This document creates a new name space "Status Code" for the Status 1793 field in the Pseudo Home Address Acknowledgement Mobility Option. 1794 The current values are described in Section 7.4 and are the 1795 following: 1797 0 Success 1799 128 Failure, reason unspecified 1801 129 Administratively prohibited 1803 130 Incorrect pseudo home address 1805 131 Invalid pseudo home address 1807 132 Dynamic pseudo home address assignment not available 1809 11. Conclusion 1811 In this document, we have proposed solutions to address location 1812 privacy issues in the context of mobility. The main idea is to hide 1813 the binding between the home address and the care-of address from 1814 eavesdroppers and the correspondent node. We have described two 1815 methods. The first method extends the return routability to hide the 1816 real home address in Binding Update and data packets. This method 1817 uses the real home address in return routability signaling, and does 1818 not require any changes to the home agent. The second method uses 1819 pseudo home addresses starting from return routability signaling, and 1820 requires some extensions to the home agent operation. This method 1821 protects revealing the real home address on the HA-CN path. The two 1822 methods provide a means to hide the real home address from 1823 eavesdroppers, and the second method can also hide it from the 1824 correspondents. 1826 The solutions we have proposed are for the basic Mobile IPv6 protocol 1827 as specified in RFC 3775. Recently, many extensions to Mobile IPv6 1828 have been proposed, such as the NEMO Basic Support protocol [21], 1829 Dual Stack Mobile IPv6 Support [22], Multiple Care-of Addresses 1830 Registration [23], Binding Revocation [24], Generic Signaling Message 1831 [25]. It is expected that the proposed location privacy solutions 1832 can be applied with some modifications, if needed, to address 1833 location privacy issues when these extensions are used. One of our 1834 future works is to clarify related issues, if any, when the location 1835 privacy solutions is used with new Mobile IPv6 extensions. 1837 12. Acknowledgement 1839 The authors would like to thank the co-authors of previous drafts 1840 from which this document is derived: Vijay Devarapalli, Hannu Flinck, 1841 Charlie Perkins, Feng Bao, Robert Deng, James Kempf, and Jianying 1842 Zhou. In addition, sincere appreciation is also extended to Claude 1843 Castelluccia, Francis Dupont, Gabriel Montenegro, Greg Daley, Kilian 1844 Weniger, Takashi Aramaki, Wassim Haddad, Heejin Jang, and Michael 1845 Welzl for their valuable contributions, review and discussion. 1847 13. References 1849 13.1. Normative References 1851 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1852 Levels", RFC 2119, March 1997. 1854 [2] Kent, S. and K. Seo, "Security Architecture for the Internet 1855 Protocol", RFC 4301, December 2005. 1857 [3] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, 1858 December 2005. 1860 [4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1861 RFC 4306, December 2005. 1863 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1864 Specification", RFC 2460, December 1998. 1866 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1867 IPv6", RFC 3775, June 2004. 1869 [7] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1870 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1871 Agents", RFC 3776, June 2004. 1873 [8] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1874 IKEv2 and the revised IPsec Architecture", RFC 4877, 1875 April 2007. 1877 [9] Hinden, R. and S. Deering, "IP Version 6 Addressing 1878 Architecture", RFC 4291, February 2006. 1880 [10] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1881 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1883 [11] Koodli, R., "IP Address Location Privacy and Mobile IPv6: 1885 Problem Statement", RFC 4882, March 2007. 1887 [12] Fenner, B., "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, 1888 UDP, and TCP Headers", RFC 4727, November 2006. 1890 [13] Devarapalli, V., "Mobile IPv6 Experimental Messages", RFC 5096, 1891 December 2007. 1893 13.2. Informative References 1895 [14] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1896 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1898 [15] Koodli, R., Devarapalli, V., Flinck, H., and C. Perkins, 1899 "Solutions for IP Address Location Privacy in the presence of 1900 IP Mobility", draft-koodli-mip6-location-privacy-solutions-00 1901 (work in progress), February 2005. 1903 [16] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol 1904 for Protecting Movement of Mobile Nodes in Mobile IPv6", 1905 draft-qiu-mip6-mnprivacy-00 (work in progress), March 2005. 1907 [17] Bao, F., Deng, R., Kempf, J., Qiu, Y., and J. Zhou, "Protocol 1908 for Protecting Movement of Mobile Nodes in Mobile IPv6", 1909 draft-qiu-mip6-hiding-movement-00 (work in progress), 1910 March 2005. 1912 [18] Castelluccia, C., Dupont, F., and G. Montenegro, "Protocol for 1913 Protecting Movement of Mobile Nodes in Mobile IPv6", 1914 draft-dupont-mip6-privacyext-02 (work in progress), July 2005. 1916 [19] Daley, G., "Location Privacy and Mobile IPv6", 1917 draft-daley-mip6-locpriv-00 (work in progress), January 2004. 1919 [20] Weniger, K. and T. Aramaki, "Route Optimization and Location 1920 Privacy using Tunneling Agents (ROTA)", draft-weniger-rota-01 1921 (work in progress), October 2005. 1923 [21] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1924 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1925 January 2005. 1927 [22] Soliman, H., "Mobile IPv6 support for dual stack Hosts and 1928 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work 1929 in progress), November 2007. 1931 [23] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1932 "Multiple Care-of Addresses Registration", 1933 draft-ietf-monami6-multiplecoa-09 (work in progress), 1934 August 2008. 1936 [24] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. 1937 Yegani, "Binding Revocation for IPv6 Mobility", 1938 draft-ietf-mext-binding-revocation-01 (work in progress), 1939 August 2008. 1941 [25] Haley, B. and S. Gundavelli, "Mobile IPv6 Generic Signaling 1942 Message", draft-ietf-mext-generic-signaling-message-00 (work in 1943 progress), August 2008. 1945 Appendix A. Profiling Attack: Discussion 1947 Profiling attacks pose a significant threat to user privacy. By 1948 collecting and analyzing (either online or offline) IP traffic, 1949 attackers can obtain sensitive user information. In the context of 1950 mobility, although the profiling attack does not directly lead to 1951 compromise of location privacy in the way the disclosure of the 1952 binding between the home address and the care-of address does, 1953 attackers can infer the mobile node's roaming and track its movement 1954 (i.e., handover) by profiling the mobile node's communication based 1955 on certain fields in IP packets, such as a constant IPsec SPI used 1956 during the home registration. The more information collected, the 1957 higher probability location privacy is compromised, which in return 1958 results in more targeted profiling. 1960 We have taken the profiling problem into consideration when designing 1961 the solution to IP address location privacy; however, not all aspects 1962 of profiling attacks are addressed since the profiling problem spans 1963 multiple protocol layers. In the following, we provide a broad 1964 discussion on the profiling attack and protection mechanisms. Our 1965 discussion is organized based on how profiling attacks can be 1966 performed. Note that the following sections are not sorted based on 1967 any criteria or may not exhaustively list all the possible attack 1968 means (for example, profiling attacks based on upper layer payloads 1969 in data packets are not discussed). 1971 A.1. The Care-of Address 1973 Eavesdroppers on the MN-HA path and/or the MN-CN path can profile the 1974 mobile node's communication by collecting packets with the same 1975 care-of address. It is recommended that the mobile node periodically 1976 updates its care-of address by using DHCPv6 or IPv6 address privacy 1977 extension, even if it does not change its current attachment point. 1978 Furthermore, it is even better to change the network prefix of the 1979 care-of address periodically, since eavesdroppers may profile IP 1980 packets based on the common network prefix. 1982 Since the binding update procedure needs to be performed once the 1983 care-of address is changed, in order to reduce signaling overheads, 1984 the mobile node may choose to change its care-of address when the 1985 Binding Cache entry at the home agent or the correspondent node is 1986 about to expire. 1988 A.2. Profiling on the Encrypted Home Address 1990 Generated from either a real or pseudo home address, the encrypted 1991 home address can be dynamically updated, because a new key is 1992 generated when a new round of the return routability procedure is 1993 performed, which makes the encrypted home address look different in 1994 subsequent Binding Update and Acknowledgement messages. 1995 Nevertheless, the same encrypted home address is used in payload 1996 packets forwarded via the optimized route before the next round of 1997 the return routability procedure. Given the cost and overhead of 1998 updating the encrypted home address, the proposed location privacy 1999 solutions still provide a reasonable level of protection against such 2000 profiling attacks. 2002 A.3. The IPsec SPI 2004 Eavesdroppers on the MN-HA path can profile the mobile node's 2005 communication based on the SPI of an IPsec security association, 2006 e.g., that for protecting the home Binding Update and Acknowledgement 2007 message or for protecting bidirectional-tunneled payload packets. 2009 To resist this kind of profiling attack, the IPsec SPI needs to be 2010 periodically updated. One way is that the mobile node and the home 2011 agent rekey the IPsec security association or perform re- 2012 authentication periodically. This may result in more signaling 2013 overhead. Another way is that the mobile node or the home agent 2014 generates a new SPI and then notifies each other by exchanging the 2015 Binding Update and Acknowledgement messages protected by an existing 2016 IPsec security association with a non-null encryption algorithm. In 2017 this way, the information of the new SPI is hidden from 2018 eavesdroppers. The new SPI MUST not conflict with other existing 2019 SPIs; and if the conflict is detected on one end point, another SPI 2020 MUST be generated and be synchronized with the other end point. The 2021 new SPI is applied to the next packet that needs to be protected by 2022 this IPsec security association. This solution requires close 2023 interaction between Mobile IP and IPsec. For example, when the home 2024 agent receives a new SPI suggested by the mobile node, it needs to 2025 change the corresponding SAD entry. 2027 A.4. The IPsec Sequence Number 2029 The IPsec sequence number is required to be larger than that in the 2030 previous valid IPsec packet if the anti-replay service is enabled. 2031 However, if the increment of the IPsec sequence number is fixed, for 2032 example, the IPsec sequence number is sequentially increased, it is 2033 possible for eavesdroppers to identify a sequence of IPsec packets 2034 that are from/to the same mobile node and to track the mobile node's 2035 activities. One possible solution is to randomize the increment of 2036 the IPsec sequence number on both end points (i.e., the mobile node 2037 and the home agent) of the IPsec security association. The algorithm 2038 to generate randomness is implementation specific. It can be, for 2039 example, any random number generator, and independently chosen by 2040 each end point. 2042 A.5. The Regular Interval of Signaling Messages 2044 As described in RFC 3775, certain signaling messages may be exchanged 2045 on the regular basis. For example, the correspondent registration 2046 needs to be performed every MAX_RR_BINDING_LIFETIME seconds and the 2047 home binding update procedure needs to be performed regularly, if the 2048 lifetime of the home Binding Cache entry is fixed. Such timing 2049 allows eavesdroppers to perform traffic analyses and correlate 2050 different messages. Due to background traffic and routing dynamics, 2051 the timing of messages observed by an eavesdropper at a certain 2052 vantage point may be irregular. Nevertheless, a better solution is 2053 to randomize the lifetime of the Binding Cache entry in the home 2054 agent and the correspondent node. 2056 A.6. The Sequence Number in the Binding Update Message 2058 RFC 3775 requires that the sequence number in the Binding Update 2059 message be larger than that in the previous valid Binding Update 2060 message for a particular mobile node. However, if the increment of 2061 the sequence number in the home or correspondent Binding Update 2062 message is fixed, for example, the sequence number is sequentially 2063 increased, it is possible for eavesdroppers on the MN-HA or MN-CN 2064 path to identify a sequence of Binding Update messages that are from 2065 the same mobile node and to track the mobile node's movement. One 2066 possible solution is that the mobile node randomizes the increment of 2067 the sequence number used in subsequent Binding Update messages. The 2068 algorithm to generate randomness is implementation specific. It can 2069 be, for example, any random number generator. Note that such an 2070 algorithm is not needed when the sequence number is encrypted, for 2071 example, when the home Binding Update message is protected by an 2072 IPsec tunnel mode security association. 2074 A.7. Multiple Concurrent Sessions 2076 It is possible for (colluded) eavesdroppers to correlate the mobile 2077 node's different sessions with the same or different correspondent 2078 nodes, for example, based on the same pseudo home address and/or the 2079 same care-of address. A possible solution is to use different pseudo 2080 home addresses and different care-of addresses in different sessions. 2081 Note that the mobile node may also use the same pseudo home address 2082 with different correspondent nodes, if the pseudo home address is 2083 masked by different privacy management keys generated during the 2084 return routability procedure with different correspondent nodes. 2085 Because in this way, the encrypted pseudo home addresses used with 2086 different correspondent nodes look different to eavesdroppers. 2088 A.8. Summary 2090 As discussed above, there exist multiple means for eavesdroppers to 2091 correlate observed activities. For example, some IP fields, which 2092 contain certain constant values and remain unchanged for a long time, 2093 allow eavesdroppers to identify and link the mobile node's activities 2094 deterministically; other means may be less reliable when used for 2095 traffic analysis and correlation, nevertheless, they provide 2096 additional hints to malicious attackers. 2098 The solution to the profiling attack is to update certain IP fields 2099 periodically. Generally, the more frequently, the higher the 2100 probability that the profiling attack is resisted and also the higher 2101 the cost in terms of communication and processing overheads and 2102 complexity. As eavesdroppers can profile activities based on 2103 multiple fields, it may not be cost-effective to update some fields 2104 more frequently than others. Furthermore, it may reduce some 2105 overheads, if all the related IP fields are updated together with the 2106 same frequency. 2108 The profiling attack is a complicated issue. A complete solution 2109 would have to consider tradeoffs of many different factors, such as 2110 complexity, effectiveness and efficiency. 2112 Appendix B. Version History 2114 o v01 to v02 2116 * Change the document structure. 2118 * Describe the process in detail how to derive a serials of 2119 secret keys. 2121 * New scheme to protect SPI profiling. 2123 * Use multi home link prefixes to generate pseudoHoA. 2125 * Propose two schemes of transferring the BU message to the HA in 2126 order to match the different protocols (RFC 3776 and IKEv2 in 2127 mobile IP). 2129 o v02 to v03 2131 * Merger section 5.3.1.and 5.3.2 and a same BU process is 2132 employed to the correspondent node regardless initiator or 2133 responder. 2135 * Introduce a term of identity address to ensure location privacy 2136 and communication session continuity 2138 o v03 to v04 2140 * Describe and compare the modifications of processing bindings 2141 in more detail. 2143 * Reformat section 5.3. 2145 o v04 to v06 2147 * Revise the algorithm proposed in section 4. 2149 * Update authors information. 2151 o v06 to v07 2153 * Add traffic formats. 2155 * Update the section of IANA requirement. 2157 * Revise according to comments of reviewers Heejin and Vijay. 2159 o v07 to v08 2161 * Re-edit section 1. 2163 * Update authors information. 2165 o v08 to v09 2167 * Revise according to comments of reviewer Michael Welzl. 2169 o v09 to v10 2171 * Re-organize and revise the document. 2173 o v11 to v12 2175 * IRSG Review comments. 2177 o v13 2179 * IRSG Poll comments. 2181 o v14 2183 * IRSG Poll comments. 2185 o v15 2187 * Revise the section of IANA Consideration. 2189 o v16 2191 * Update the author information and revise the section of IANA 2192 Consideration. 2194 Authors' Addresses 2196 Ying Qiu 2197 Institute for Infocomm Research, Singapore 2198 21 Heng Mui Keng Terrace 2199 Singapore 119613 2201 Phone: +65-6874-6742 2202 Email: qiuying@i2r.a-star.edu.sg 2204 Fan Zhao (editor) 2206 Email: fanzhao828@gmail.com 2208 Rajeev Koodli 2209 Starent Networks, Corp. 2211 Email: rkoodli@starentnetworks.com