idnits 2.17.00 (12 Aug 2021) /tmp/idnits855/draft-haddad-privacy-omipv6-anonymity-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 632. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([CGA-OMIPv6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 2005) is 6183 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'OMIPv6' is mentioned on line 420, but not defined -- Possible downref: Normative reference to a draft: ref. 'CGA-OMIPv6' ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-mip6-ikev2-ipsec has been published as RFC 4877 == Outdated reference: A later version (-03) exists of draft-haddad-momipriv-problem-statement-01 -- No information found for draft-ietf-ipv6-privacy-address-v2 - is the name correct? Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Wassim Haddad 2 Mobility Privacy Suresh Krishnan 3 Internet Draft Ericsson Research 4 Expires December 2005 Francis Dupont 5 Point6 6 Marcelo Bagnulo 7 UC3M 8 Hannes Tschofenig 9 Siemens 10 June 2005 12 Anonymity and Unlinkability Extension for CGA-OMIPv6 14 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with section 6 of BCP 79. 23 This document is an Internet Draft and is in full conformance with 24 all provisions of Section 10 of RFC 2026. 26 This document is an Internet-Draft. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its 28 areas, and its working groups. Note that other groups may also 29 distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet- 33 Drafts as reference material or to cite them other than as 34 "work in progress." 36 The list of current Internet Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Distribution of this memo is unlimited 44 Abstract 46 The "Optimized Mobile IPv6 with CGA" [CGA-OMIPv6] protocol 47 specifies a new route optimization (RO) technique. This document 48 describes a new extension to be added to the CGA-OMIPv6 protocol 49 in order to provide the anonymity and the unlinkability at the 50 IP layer. 52 Table of contents 54 1. Introduction................................................2 55 2. Terminology.................................................2 56 3. Glossary....................................................3 57 4. Problem Statement...........................................4 58 5. Proposed Solution...........................................6 59 6. Packet Format...............................................9 60 7. Privacy Considerations.....................................11 61 8. Security Considerations....................................12 62 9. Normative References.......................................13 63 10. Informative References....................................13 64 11. Authors' Addresses........................................14 65 Intellectual Property Statement...............................16 66 Disclaimer of Validity........................................16 67 Copyright Statement...........................................16 69 1. Introduction 71 CGA-OMIPv6 (called "OMIPv6" in the rest of the document for 72 simplicity) protocol specifies a new route optimization (RO), 73 which reduces the amount of signaling messages, the handover 74 latency and improves the overall security. 76 However, OMIPv6 protocol lacks privacy support, namely 77 anonymity/pseudonymity and unlinkability. Supporting these 78 privacy aspects in OMIPv6 would allow a mobile user to move 79 outside its home network without disclosing its real IPv6 home 80 address, and thereby to prevent the ability to correlate 81 actions at this layer. 83 This document describes privacy extensions to the OMIPv6 84 protocol. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" 89 in this document are to be interpreted as described in RFC 2219 90 [TERM]. 92 3. Glossary 94 Anonymity 96 Anonymity ensures that a user may use a resource or service 97 without disclosing the user's identity. 99 Anonymity in wireless networks means that neither the mobile 100 node nor its system software shall by default expose any 101 information, that allows any conclusions on the owner or 102 current use of the node. 104 Consequently, in scenarios where a device and/or network 105 identifiers are used (e.g., MAC address, IP address), 106 neither the communication partner nor any outside attacker 107 should be able to disclose the relationship between the 108 respective identifier and the user's identity. 110 Pseudonymity 112 Pseudonymity is a weaker property related to anonymity. It 113 means that one cannot identify an entity, but it may be 114 possible to prove that two pseudonymous acts were performed 115 by the same entity. 117 Unlinkability 119 Two events are unlinkable if they are no more and no less 120 related than they are related concerning the a-priori 121 knowledge. 123 Unlinkability ensures that a user may make use of resources 124 or services without others being able to link the use of 125 these services together. 127 In hiding the mobile node's current location, unlinkability 128 feature removes any possible correlation between two 129 successive IP handovers performed by the same mobile node. 131 For more information about privacy aspects and location privacy 132 please refer to [MOMIPRIV]. 134 4. Problem Statement 136 OMIPv6 protocol introduces a new route optimization (RO) mode, 137 which reduces the load of signaling messages, i.e., mainly by 138 eliminating the HoTI/HoT messages, offers a semi-permanent 139 security association (SA) between the mobile node (MN) and the 140 correspondent node (CN) and improves the overall security of 141 the MN <-> CN communication. 143 However, OMIPv6 allows the CN and any potential eavesdropper 144 located on the path between the MN and the CN to first identify 145 the mobile node via its IPv6 Home Address (HoA) and then to 146 trace its movements in real time across the Internet, thus 147 seriously violating its privacy. Such scenario is feasible by 148 simply looking into the Binding Update (BU) message(s) sent by 149 the MN to the CN, which carries among other parameters, the MN's 150 HoA and its new current topological location, i.e., disclosed in 151 its care-of address (CoA). 153 In addition to the BU message(s), the eavesdropper can learn 154 and trace the MN's movements by looking into the data packets 155 exchanged with the CN. 156 In fact, the main RO mode (detailed in [MIPv6]) defined two 157 mobility extension headers, which carry the MN's home address. 158 The first one is the Home Address Option (HAO) and is inserted 159 in each data packet sent by the MN to the CN on the direct path. 160 The second one is a Routing Header (RH) and is inserted in each 161 data packet sent by the CN to the MN on the direct path. 163 Based on the above, it appears that in order to keep the 164 exchange of data packets between the two endpoints flowing on 165 the direct path, only the home address can be hidden from both 166 the CN and any potential eavesdropper(s) located on the direct 167 path. 168 Consequently, any solution for the privacy problem in OMIPv6 169 MUST prevent the CN from falling back to the bidirectional (BT) 170 mode under any circumstance(s), since data packets sent by the 171 CN are addressed to the MN's HoA. The BT mode is detailed in 172 [MIPv6]. 174 But it should be noted that replacing the real MN's HoA with a 175 static (or even dynamic) pseudo-HoA can still allow the 176 eavesdropper to correlate between MN's movements across the 177 Internet, thus breaking the unlinkability feature. Such 178 correlation can be accomplished by simply tracing the BU 179 messages via the sequence number carried by each message. The 180 seriousness of such correlation is tightly related to how 181 difficult is for the eavesdropper to discover the MN's real HoA 182 (e.g., based on prior knowledge and/or other identifier(s), 183 which are already known or can be discovered at a further stage, 184 etc). In fact, such knowledge can reveal all MN's pseudo-HAs and 185 their corresponding CoAs as well as the exact time of each 186 movement. 188 The unlinkability feature can also be broken if an eavesdropper 189 is able to correlate between two data packets exchanged between 190 the MN and the CN and carrying different CoAs, but associated to 191 the same pseudo-HoA. Such correlation may reveal the exact time 192 of the MN's movement(s) regardless of the content of the BU 193 message. In addition, tracing the BU message may also help the 194 eavesdropper correlate between the MIPv6 signaling messages and 195 the data packets (namely the pseudo-HoA and/or CoA carried by 196 the BU message with the address(es) carried by the data packet. 198 Consequently, we argue that any solution for privacy related 199 to the network layer mobility only should also offer the 200 unlinkability feature by fulfilling the following requirements: 202 - prevent disclosing the MN's HoA in any BU message. 204 - avoid using the same pseudo-HoA in more than one BU 205 message. 207 - prevent the possibility of tracing the BU messages via the 208 sequence number. 210 - prevent any correlation between data packets exchanged 211 with the current CoA and the next BU message sent after 212 performing an IP handover. 214 - prevent any correlation between data carried by the BU 215 message and data packets exchanged after receiving the BA 216 message. 218 Finally, it should be noted that any potential solution, which 219 addresses privacy as motivated above, should take the scenario 220 where a mobile node starts communicating end-to-end with a CN 221 from its home network before switching to a foreign network(s) 222 into consideration. 224 5. Proposed Solution 226 Our suggested solution can be used regardless of whether the MN 227 is establishing its session from its home network or from a 228 visited network. It consists of three components: 230 a) the "P" bit that is carried in the Pre-Binding Update (PBU), 231 the Pre-Binding Test (PBT) and the Binding Update (BU) 232 message; this bit demands additional processing guidelines 233 (including sequence number handling). 235 b) replacing the home address carried within the Home Address 236 Option (HAO) with an ephemeral identifier. 238 c) associating the interface identifier (iid) of the MN's home 239 address with the cryptographically-Based Identifiers (CBID). 241 As a first step, a Pre-Binding Update (PBU) message is sent 242 directly from the MN to the CN. The PBU message carried a newly 243 introduced Privacy (P) bit set and thereby asks the CN to skip 244 any home address test, and also to avoid any possible fallback 245 to the bidirectional tunneling mode (described in [MIPv6]) 246 during the subsequent data exchange. 248 The MN MUST set the "P" bit in the PBU message, regardless of 249 the MN's location (also while staying at the home network), and 250 in the BU message sent after receiving the Pre-Binding Test 251 (PBT) message from the CN. 253 Additionally, the MN MUST replace the home address inserted in 254 the Home Address Option (HAO) with a "Virtual Home Address" 255 (VHoA). The VHoA sent in the first BU message MUST be a 256 statistically unique cryptographically generated and verifiable 257 identifier [CBID]. Note that using the CBID technology in Mobile 258 IPv6 for privacy purposes has been introduced in [MIPriv]. 260 During the first exchange of signaling messages between the two 261 endpoints, and in order to enable the CN to check if it is still 262 talking to the same MN when receiving the first BU message, the 263 MN MUST insert in the PBU message the value obtained from 264 hashing the VHoA (note that in this case, the VHoA is the CBID, 265 thus the value is equal to SHA1(CBID) in the PBU message. 267 After receiving the PBU message, the CN computes a challenge 268 from the MN's CoA, the content of the HAO and a local secret. 269 Then it inserts the challenge into the PBT message and returns 270 it to the MN. When the MN gets the PBT message, it sends a BU 271 message carrying the "P" bit, the challenge and inserts the real 272 CBID into the HAO. Note that the iid of the MN's CoA sent in the 273 PBU and the BU messages SHOULD be generated from hashing the 274 CBID in the following way: 276 iid(CoA) = First(64, SHA1(CBID)) 278 Where: 280 - SHA1 is a hashing function 281 - CBID is a cryptographically generated identifier 282 - First(size,input) is a function used to indicate 283 truncation of the input data so that only the first 284 size bits remain to be used. 285 - iid is the interface identifier 287 Upon receiving the first BU message with the "P" bit set, the CN 288 starts by checking its validity. For this purpose, it will hash 289 the content of the HAO, i.e., the CBID, and compares the first 290 64 bits of the resulting hash with the CoA's iid. After that, it 291 will re-compute the challenge and compare it to the one sent in 292 the message. The third step after a successful validation would 293 be to create an entry in the BCE for the MN's VHoA and the CoA. 294 The CN computes also a long lifetime shared secret (i.e., SKbm) 295 and sends it back to the MN in the BA message as described in 296 [OMIPv6]. 298 The presence of the "P" bit in the BU message is also used to 299 request the CN to replace the sequence number carried by the BU 300 message, in its BCE with the "next" value, i.e., expected in 301 the next BU message sent by the MN. Such value is called the 302 "Sequence Value" SQV and is used to prevent replay attacks and 303 to allow the CN to identify the MN's corresponding entry in its 304 BCEs when processing a BU message carrying the "P" bit. 306 In OMIPv6, each time the MN sends a BU message, it MUST 307 increment the sequence number. With the privacy extensions 308 introduced by this document, both endpoints MUST increment the 309 SQV with a constant value equal to the one obtained from hashing 310 the SKbm. Finally, the incremented SQV is hashed, inserted by 311 the MN into the BU message and sent it to the CN. 313 The two entities MUST compute the next SQV (nSQV) in the 314 following way: 316 Khbm = SHA1(SKbm) 318 nSQV = First(64, SHA1((pSQV) | Khbm)) 320 Where: 322 - SKbm is a long lifetime binding management key 323 - Khbm is the hashed binding management key 324 - pSQV is the previous SQV, i.e., SQV sent in the last BU 325 message sent by the MN and already processed by the CN. 326 - nSQV is the hasht value of the next SQV computed during 327 updating the BCE with the BU message carrying the pSQV. 329 The CN MUST compute and store the nSQV during creating/updating 330 the MN's entry in its BCE, and the MN MUST compute and send a 331 new SQV in all subsequent BU messages sent to the CN. 333 In addition, all subsequent BU messages sent after the first 334 one, SHOULD carry a VHoA, which is generated from hashing the 335 nCoA, i.e., nVHoA is equal to SHA1(nCoA), sent in the message. 337 However, it should be noted that the CN SHOULD NOT store in the 338 MN's corresponding entry the new CoA (nCoA) and new VHoA (nVHoA) 339 carried in the BU message. In fact, besides computing the nSQV 340 and storing it in the corresponding entry, the CN SHOULD also 341 compute another address pair (CoA, VHoA) to be used in the data 342 packets exchange following the BCE creation/update. These two 343 addresses are called "expected CoA" (eCoA) and "expected VHoA" 344 (eVHoA). 346 The two expected addresses are computed in the following way: 348 iid(eCoA) = First(64, SHA1(Khbm | nCoA Subnet Prefix)) 350 eVHoA = SHA1(eCoA) 352 Where: 354 - nCoA is the MN's care-of address sent in the BU message. 355 - eVHoA is the pseudo-home address carried in the HAO and 356 RH headers in all data packets. 358 The subnet prefix of the nCoA MUST be the same as the one sent 359 by the MN in the BU message (note that this technique is similar 360 to the one defined in [HBA]). Note that in such scenario, the CN 361 MUST update the MN's entry in its BCE with the eCoA and eVHoA. 362 However, the BA message sent to the MN MUST carry the nCoA and 363 nVHoA. 365 As mentioned above, when the MN sends a BU message carrying the 366 "P" bit, the SQV MUST be used alone by the CN to detect the 367 presence of an entry corresponding to the MN in its BCE. If an 368 entry containing the same SQV is found, then the CN SHOULD 369 proceed to check the signature before updating the corresponding 370 entry with the eCoA, eVHoA and nSQV. 372 6. Packet Format 374 This proposal defines a new bit called the Privacy (P) bit to be 375 added to the Pre-BU and BU messages. The MN MUST set the "P" bit 376 in both messages and in all subsequent BU messages as long as it 377 needs to keep its real home IP address undisclosed. 379 When used in the Pre-BU message, the "P" bit indicates to the CN 380 to limit the address test to the CoA only and also to include 381 the VHoA in computing the nonce value sent in the Pre-Binding 382 Test (PBT) message. 384 When used in the BU message, the "P" bit is used for three 385 different purposes. The first one is to ask the CN to use the 386 sequence number to locate the MN's corresponding BCE. The second 387 one is to notify the CN to NOT send any data packet carrying the 388 MN's home pseudo-address, i.e., VHAO, as destination address. 390 The third purpose is to ask the CN to compute the eCoA, the 391 eVHoA, the new SQV and store them in the MN's corresponding BCE. 393 When used in the Pre-BU message, the structure of the message 394 will be as it follows: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |P| Reserved | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | | 402 + + 403 | | 404 + Care-of Address + 405 | | 406 + + 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 + Pre-Binding Update Cookie + 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | 414 . . 415 . Mobility Options . 416 . . 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 The different fields carried in the Pre-BU message are detailed 420 in [OMIPv6]. 422 When used in the BU message, the structure of the message will 423 be as it follows: 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Sequence # | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 |A|H|L|K|P| Reserved | Lifetime | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 . . 434 . Mobility options . 435 . . 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 The different fields carried in the BU message are detailed in 440 [MIPv6]. 442 7. Privacy Considerations 444 This memo describes an extension, which makes the MN's real 445 identity anonymous for both the CN and any malicious 446 eavesdropper(s) located on the path between the MN and the CN. 448 Our solution aims to present the MN's HoA as any other CoA that 449 the MN may use during its movements across the Internet. 450 However, our solution is based on the assumption that the BU 451 messages exchanged between the MN and its HA are protected with 452 an ESP tunnel according to [MIP6-IKE] and [MIP6-IKEv2]. 454 The suggested solution provides the anonymity feature to the MN 455 during exchanging data packets and signaling messages with the 456 CN. It also provides the unlinkability feature during and after 457 performing IP handovers, by making it difficult for an 458 eavesdropper to correlate between two successive IP handoffs 459 performed by the same MN. The unlinkability between these events 460 aims to enhance the anonymity feature. 461 However, it should be noted that the unlinkability protection is 462 limited against eavesdroppers located on the path between the MN 463 and the CN and does not prevent the CN to trace the MN's 464 movements in real time. 466 The suggested solution allows the MN to select when and where 467 the anonymity feature should be activated. But it should be 468 noted that it works only when the MN initiates the session. 469 Actually, when the CN initiates the session, it uses the MN's 470 home address (HoA). In such scenario, the MN can hide its 471 current location from the CN by switching to the bidirectional 472 tunneling mode. 474 It is worth mentioning that the anonymity concept is very much 475 context dependent. In order to quantify anonymity with concrete 476 situations, one would have to describe the system context, which 477 is practically not always possible for large open systems 478 [ANON]. 479 Consequently, the efficiency of the suggested solution is 480 strongly related to two key factors: the diversity and load of 481 the traffic circulating in parallel with the MN's traffic, on 482 the same portion(s) of the direct path, which is monitored by an 483 eavesdropper(s). 485 Finally, the suggested solution strongly recommends using the 486 Privacy Extension proposal [PRIVACY], in configuring the care-of 487 address(es) sent by the MN in all BU messages except for the BU 488 message sent after receiving a PBT message, i.e., in which the 489 CoA is derived from the CBID. 491 8. Security Considerations 493 The suggested solution does not introduce new attacks nor does 494 it amplify threats. However, it is important to mention that it 495 makes the switch to the MIPv6 BT mode impossible. 497 The suggested solution aims to hide the mobile user's real 498 identity when moving outside its home network or from its home 499 network to foreign networks. Making the MN anonymous (with 500 regard to the used home address) to potential eavesdroppers may 501 help to prevent attacks, thus improves the overall security. 503 9. Normative References 505 [CGA-OMIPv6] W. Haddad, L. Madour, J. Arkko and F. Dupont, 506 "Applying Cryptographically Generated Addresses to 507 Optimize MIPv6 (CGA-OMIPv6)", 508 draft-haddad-mip6-cga-omipv6-04, May, 2005. 510 [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility 511 Support in IPv6", RFC 3775, June 2004. 513 [MIP6-IKE] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec 514 to Protect Mobile IPv6 Signaling Between Mobile 515 Nodes and Home Agents", RFC 3776, June 2004. 517 [MIP6-IKEv2] V. Devarapalli, "Mobile IPv6 Operation with IKEv2 518 and the revised IPsec Architecture", 519 draft-ietf-mip6-ikev2-ipsec-01, February 2005. 521 [TERM] S. Bradner, "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 10. Informative References 526 [ANON] A. Pfitzmann et al. "Anonymity, Unobservability, 527 Pseudonymity, and Identity Management - A Proposal 528 for Terminology", Draft v0.21, September, 2004. 530 [CBID] G. Montenegro, C. Castelluccia, "Cryptographically- 531 Based Identifiers (CBID): Concepts and Applications", 532 ACM Transaction on Information and System Security 533 (TISSEC), February 2004. 535 [HBA] M. Bagnulo, "Hash Based Addresses (HBA)", 536 draft-ietf-multi6-hba-00, December 2004. 538 [MIPriv] C. Castelluccia, F. Dupont, G. Montenegro, "A Simple 539 Privacy Extension to Mobile IPv6", IEEE/IFIP 540 International Conference on Mobile and Wireless 541 Communication Networks (MWCN), Paris, France, October 542 2004. 544 [MOMIPRIV] W. Haddad, E. Nordmark, F. Dupont, M. Bagnulo, S. 545 Park and B. Patil, "Privacy for Mobile and 546 Multi-homed Nodes: MoMiPriv Problem Statement", 547 draft-haddad-momipriv-problem-statement-01, 548 February 2005. 550 [PRIVACY] T. Narten, R. Draves and S. Krishnan, "Privacy 551 Extensions for Stateless Address Autoconfiguration 552 in IPv6", draft-ietf-ipv6-privacy-address-v2-04, 553 May 2005. 555 11. Authors' Addresses 557 Wassim Haddad 558 Ericsson Research 559 8400, Decarie Blvd 560 Town of Mount Royal 561 Quebec H4P 2N2 562 Canada 564 Phone: +1 514 345 7900 (#2334) 565 E-Mail: Wassim.Haddad@ericsson.com 567 Suresh Krishnan 568 Ericsson Research 569 8400, Decarie Blvd 570 Town of Mount Royal 571 Quebec H4P 2N2 572 Canada 574 Phone: +1 514 345 7900 (#2871) 575 E-Mail: Suresh.Krishnan@ericsson.com 577 Francis Dupont 578 Point6 579 c/o GET/ENST Bretagne 580 Campus de Rennes 581 2, rue de la Chataigneraie 582 CS 17607 583 35576 Cesson-Sevigne Cedex 584 France 585 E-Mail: Francis.Dupont@enst-bretagne.fr 587 Marcelo Bagnulo 588 Universidad Carlos III de Madrid 589 Av. Universidad 30 590 Leganes, Madrid 28911 591 SPAIN 593 Phone: +34 91 6249500 594 E-Mail: marcelo@it.uc3m.es 595 URI: http://www.it.uc3m.es 597 Hannes Tschofenig 598 Siemens AG 599 Otto-Hahn-Ring 6 600 81739 Munich 601 Germany 603 EMail: Hannes.Tschofenig@siemens.com 605 Intellectual Property Statement 607 The IETF takes no position regarding the validity or scope of 608 any Intellectual Property Rights or other rights that might be 609 claimed to pertain to the implementation or use of the 610 technology described in this document or the extent to which any 611 license under such rights might or might not be available; nor 612 does it represent that it has made any independent effort to 613 identify any such rights. Information on the IETF's procedures 614 with respect to rights in IETF Documents can be found in BCP 78 615 and BCP 79. 617 Copies of IPR disclosures made to the IETF Secretariat and any 618 assurances of licenses to be made available, or the result of an 619 attempt made to obtain a general license or permission for the 620 use of such proprietary rights by implementers or users of this 621 specification can be obtained from the IETF on-line IPR 622 repository at http://www.ietf.org/ipr. 624 The IETF invites any interested party to bring to its attention 625 any copyrights, patents or patent applications, or other 626 proprietary rights that may cover technology that may be 627 required to implement this standard. Please address the 628 information to the IETF at ietf-ipr@ietf.org. 629 The IETF has been notified of intellectual property rights 630 claimed in regard to some or all of the specification contained 631 in this document. For more information consult the online list 632 of claimed rights. 634 Disclaimer of Validity 636 This document and the information contained herein are provided 637 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 638 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 639 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 640 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 641 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 642 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 643 FOR A PARTICULAR PURPOSE. 645 Copyright Statement 647 Copyright (C) The Internet Society (2005). This document is 648 subject to the rights, licenses and restrictions contained in 649 BCP 78, and except as set forth therein, the authors retain all 650 their rights.