idnits 2.17.1 draft-dupont-mipshop-omipv6-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) 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 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 (February 17, 2006) is 6642 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) ** Downref: Normative reference to an Informational RFC: RFC 3792 (ref. 'CGA') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-04) exists of draft-arkko-mipshop-cga-cba-02 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Dupont 3 Internet-Draft CELAR 4 Expires: August 21, 2006 W. Haddad 5 Ericsson Research 6 February 17, 2006 8 Optimizing Mobile IPv6 (OMIPv6) 9 draft-dupont-mipshop-omipv6-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 21, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes an optimization to the Mobile IPv6 (MIPv6) 43 protocol, which uses the crypto-based identifier (CBID) technology to 44 securely establish a long lifetime bidirectional security association 45 (SA) between the mobile node (MN) and the correspondent node (CN) and 46 to reduce the IP handoff latency as well as the amount of signaling 47 messages. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions used in this document . . . . . . . . . . . . . . 3 53 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Quick Overview of Crypto-based Identifiers (CBID) . . . . . . 4 55 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 56 6. New Messages and Option Formats . . . . . . . . . . . . . . . 7 57 6.1. The Pre-Binding Update Message . . . . . . . . . . . . . . 7 58 6.2. The Pre-Binding Acknowledgment (PBA) Message . . . . . . . 8 59 6.3. The Pre-Binding Test (PBT) Message . . . . . . . . . . . . 10 60 6.4. The Imprint Option . . . . . . . . . . . . . . . . . . . . 11 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 66 Intellectual Property and Copyright Statements . . . . . . . . . . 15 68 1. Introduction 70 Mobile IPv6 protocol as described in [MIPv6] introduces a new mode 71 called route optimization (RO), which enables direct communication 72 between the MN and the CN. 74 However, the RO mode requires a considerable amount of redundant 75 signaling messages, which in turn create a significant latency 76 problem and raises many security concerns. These problems are 77 seriously undermining the possibility of any wide deployment of the 78 RO mode in its current design. 80 This document describes an optimization to the Mobile IPv6 (MIPv6) 81 protocol, which uses the crypto-based identifier [CBID] technology to 82 securely establish a long lifetime bidirectional SA between the MN 83 and the CN and to reduce the IP handoff latency as well as the amount 84 of signaling messages. 86 2. Conventions used in this document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [TERM]. 92 3. Problem Statement 94 MIPv6 RO mode security is based on the return routability (RR) 95 procedure. The RR allows the CN to check the reachability of the 96 MN's home address (HoA) and its new care-of address (CoA), and to 97 enable both endpoints to share a secret, (Kbm), in order to 98 authenticate the binding update and acknowledgment (BU/BA) messages 99 exchanged between them. 101 The RR consists on exchanging four signaling messages, i.e., the 102 HoTI/HoT and CoTI/CoT, between the MN and the CN, prior to sending a 103 BU message to the CN. However, the CoTI/CoT messages are exchanged 104 in clear on the direct path between the MN and the CN, and the HoTI/ 105 HoT messages are exchanged in clear between the MN's home agent (HA) 106 and the CN. Consequently, such exchange raises many security 107 concerns as it is open to many attacks. 109 In addition, it is required according to [MIPv6-Sec] to repeat the RR 110 procedure during each IP handoff and/or during a maximum of 420 111 seconds, even if the MN does not move. Such requirement boost 112 significantly the amount of signaling messages as well as the handoff 113 latency and makes the HA a single point of failure. 115 In order to address the RR issues, a new proposal based on using the 116 cryptographically generated address [CGA] is under design. The new 117 proposal, i.e., [OMIPv6-CGA], allows the MN to provide the CN with a 118 proof of ownership of its HoA's Interface Identifier (IID) and 119 enables both endpoints to share a long lifetime shared secret. 120 However, the suggested proposal does not allow the MN to provide any 121 proof of ownership of its CoA's IID and is open to session hijacking 122 and DoS attacks at some critical stage. It should be noted that 123 these attacks don't require the malicious node to be located 124 simultaneously on the HA-CN path and on the direct path between the 125 two endpoints. In fact, launching these attacks require the 126 malicious node to be located only on the path between the MN's HA and 127 the CN (i.e., HA-CN). 129 OMIPv6-CGA requires the MN to perform one RR procedure (as defined in 130 MIPv6) prior to establishing a long lifetime bidirectional security 131 association (SA). For this purpose, when the MN moves for the first 132 time to a foreign network or decide to switch to the RO mode from a 133 foreign network, it MUST send a HoTI and CoTI messages to the CN. 134 However, the fact that the (HoTI, HoT) pair of messages goes in clear 135 between the HA-CN makes them visible to a malicious node located on 136 the same path. Consequently, the malicious node can easily discover 137 the home keygen token sent by the CN to the MN in the HoT message. 138 In order to launch a successful attack against a MN using the OMIPv6- 139 CGA procedure, the malicious node has to send the first BU message to 140 the CN on behalf of the MN, i.e., before the MN sends its own BU 141 message. For this purpose, the malicious node has to always keep at 142 hand a fresh care-of keygen token. This can be easily done by using, 143 for example its own IPv6 address to exchange at anytime a CoTI/CoT 144 messages with the CN, in order to get a new care-of keygen token. 146 Sending a first and valid BU message to the CN, on behalf of the MN, 147 allows the malicious node to hijack the MN's ongoing session and 148 prevents it from establishing a long lifetime bidirectional SA with 149 the CN. OMIPv6-CGA protocol requires that the first BU message 150 received by the CN from the MN be authenticated with the Kbm and 151 signed with the MN's CGA public key. 153 In this memo, we introduce an alternative solution to the CGA 154 technology, which offers the same features described in [OMIPv6-CGA] 155 and also prevents the attack described above. 157 4. Quick Overview of Crypto-based Identifiers (CBID) 159 A CBID is a 128-bit opaque identifier, which has a strong 160 cryptographic binding with its components, i.e., generated from the 161 MN's key pair. Consequently, using identifiers that satisfy the CBID 162 structure offers the advantage that other nodes, e.g., CNs, can 163 safely trust the node when it claims ownership of that identifier. 165 A CBID is generated as follows: 167 CBID = First(128,SHA1 (imprint | PK)) 169 where: 170 imprint is a 128-bit field, which is a random value. 171 PK is the MN's public key formatted as a DER encoding of the 172 SubjectPublicKeyInfo structure. 173 SHA1 is a one way hash function. 174 | denotes a concatenation. 175 First(x,y) means that only the high order x bits are considered from 176 the resulting hash value. 178 This memo introduces some changes to the procedure used to generate a 179 CBID, in order to further reduce the possibility of having a 180 collision. The new suggested method to generate a CBID consists of 181 the three following steps: 182 1. Input = 128-bit imprint | Public Key 183 2. Hash = SHA256 (Input) 184 3. CBID = Encode_128 (Hash) 185 where Encode_128 is an extraction function, which output is obtained 186 by extracting the first most significant 128-bit from the resulting 187 hash, i.e., Encode_128 (Hash) = First (128, Hash). 189 5. Protocol Description 191 The following diagram shows the mobility signaling exchange between 192 the MN and the CN for the initial contact: 194 1. MN to CN (via HA): Pre-Binding Update (PBU) 195 2a. CN to MN (via HA): Pre-Binding Acknowledgment (PBA) 196 2b. CN to MN (directly): Pre-Binding Test (PBT) 197 3. MN to CN (directly): Binding Update (BU) 198 4. CN to MN (directly): Binding Acknowledgment (BA) 200 The suggested protocol is described in the following steps: 201 - When the MN moves for the first time to a foreign network, it 202 sends a Pre-Binding Update (PBU) message to the CN via its HA, 203 i.e., the PBU message is encrypted between the MN and the HA. The 204 PBU message contains the MN's HoA and CoA. In addition, the 64- 205 bit HoA and CoA's IIDs MUST be configured from equally splitting 206 the 128-bit crypto-based identifier. For example, the HoA's IID 207 SHOULD be equal to the 64 rightmost significant bits and the CoA's 208 IID should be equal to the remaining 64 bits. 210 - After receiving a PBU message, the CN computes two keygen tokens 211 and sends them in two different messages, i.e., the Pre-Binding 212 Acknowledgment (PBA) is sent via the MN's HA and MUST carry the 213 home keygen token, and the Pre-Binding Test (PBT) is sent on the 214 direct path and MUST carry the care-of keygen token. 215 In order to prevent a malicious node located on the path between 216 the MN's HA and the CN from hijacking the MN's ongoing session, by 217 exploiting the discovery of the home keygen token sent in clear in 218 the HoT message (as described earlier), this memo suggests that 219 the CN MUST compute the two keygen tokens by using the MN's CoA 220 and the 128-bit CBID. For this purpose, the home keygen token 221 MUST be computed in the following way: 222 Home Keygen Token := 223 First (64, HMAC_SHA1 (Kcn, (CBID | nonce | 0))) 224 and the care-of Keygen token MUST be computed in the following 225 way: 226 Care-of Keygen Token:= 227 First (64, HMAC_SHA1 (Kcn, (CoA | nonce | 1))) 228 where HMAC_SHA1 is detailed in [HMAC], and Kcn and nonce are 229 detailed in [MIPv6]. 230 - When the MN gets the PBA and PBT messages, it combines the two 231 tokens in the same way as described in [MIPv6], and uses the 232 result to authenticate the BU message, which is sent on the direct 233 path to the CN. In addition, the BU message MUST be signed with 234 the MN's private key and MUST carry the 128-bit imprint and the 235 MN's corresponding public key. For this purpose, this document 236 defines a new option in the BU message to carry the imprint and 237 use the same option defined in [OMIPv6-CGA] to carry the public 238 key in the BU message. 239 - When the CN gets the BU message, it starts by checking the 240 validity of the CBID. This is done by repeating the three steps 241 described above, and comparing the resulting value with the one 242 obtained from combining the two IIDs used in configuring the HoA 243 and CoA. If the two values are identical, then the CN re-computes 244 the two tokens and checks the authenticity of the the BU message. 245 After that, the CN checks the RSA signature. 246 If the signature is valid, then the CN creates a Binding Cache 247 Entry (BCE) for the MN, computes a shared secret (SK) and encrypts 248 it with the MN's public key. The CN inserts the encrypted SK in 249 the BA message and sends it to the MN. The BA message MUST be 250 authenticated with the shared secret. 251 - After checking the authenticity of the BA message, the MN decrypts 252 SK with its private key and establishes the bidirectional SA. 253 Note that the SA lifetime is by default 24 hours, after which the 254 two nodes should re-key by repeating steps described above. 255 - After establishing the SA, all subsequent BU/BA exchange MUST be 256 authenticated only with SK until the expiration of the SA. The RR 257 procedure SHOULD NOT be repeated before the SK lifetime expires. 259 - For any subsequent IP handoff, the MN MAY autoconfigure its CoA by 260 using as IID the first 64 bits resulting from hashing SK, the new 261 network prefix and the previous CoA (pCoA), i.e., 262 CoA's IID:= First (64, SHA1 (SK | new network prefix | pCoA)) 264 6. New Messages and Option Formats 266 Our proposal introduces 3 new messages and one new option, which are 267 described in the following: 269 6.1. The Pre-Binding Update Message 271 This message is similar to a Binding Update message, but does not yet 272 establish any state at the correspondent node. The purpose of this 273 operation is to initiate the sending of two address reachability 274 tests. 276 This message uses MH Type . The format of 277 the message is the following: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Reserved | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 + + 286 | | 287 + Care-of Address + 288 | | 289 + + 290 | | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | | 293 + Pre-Binding Update Cookie + 294 | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 . . 298 . Mobility Options . 299 . . 300 | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Reserved 16-bit field reserved for future use. This value MUST be 304 initialized to zero by the sender, and MUST be ignored by the 305 receiver. 307 Care-of Address 308 The current care-of address of the mobile node. 310 Pre-Binding Update Cookie 311 64-bit field which contains a random value, a cookie used to 312 ensure that the responses match to requests. 314 Mobility Options 315 Variable-length field of such length that the complete Mobility 316 Header is an integer multiple of 8 octets long. This field 317 contains zero or more TLV-encoded mobility options. The receiver 318 MUST ignore and skip any options which it does not understand. 319 This specification does not define any options valid for this 320 message. 322 If no actual options are present in this message, no padding is 323 necessary and the Header Length field will be set to 3. 325 This message is tunneled through the home agent when the mobile 326 node is away from home. Such tunneling SHOULD employ IPsec ESP in 327 tunnel mode between the home agent and the mobile node. This 328 protection is indicated by the IPsec security policy database, 329 similarly to the protection provided for Home Test Init messages. 331 6.2. The Pre-Binding Acknowledgment (PBA) Message 333 This message acknowledges a Pre-Binding Update message. The purpose 334 of this acknowledgment is to provide a part of the key Kbm required 335 in the initial phase of our mechanism. 337 This message uses MH Type . The format of 338 the message is the following: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Reserved | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 + Pre-Binding Update Cookie + 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | | 350 + Home Keygen Token + 351 | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 . . 355 . Mobility Options . 356 . . 357 | | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Reserved 361 16-bit field reserved for future use. This value MUST be 362 initialized to zero by the sender, and MUST be ignored by the 363 receiver. 365 Pre-Binding Update Cookie 366 This 64-bit field contains the value from the same field in the 367 Pre-Binding Update message. 369 Home Keygen Token 370 This 64-bit field contains a Home Keygen Token, calculated as 371 specified in RFC3775. 373 Mobility Options 374 Variable-length field of such length that the complete Mobility 375 Header is an integer multiple of 8 octets long. This field 376 contains zero or more TLV-encoded mobility options. The receiver 377 MUST ignore and skip any options which it does not understand. 378 This specification does not define any options valid for this 379 message. 381 If no actual options are present in this message, no padding is 382 necessary and the Header Length field will be set to 2. 384 This message is tunneled through the home agent when the mobile 385 node is away from home. Such tunneling SHOULD employ IPsec ESP in 386 tunnel mode between the home agent and the mobile node. This 387 protection is indicated by the IPsec security policy database, 388 similarly to the protection provided for Home Test messages. 390 6.3. The Pre-Binding Test (PBT) Message 392 This message also acknowledges a Pre Binding Update message, and 393 ensures that the mobile node is reachable at its claimed address. 394 The purpose of this acknowledgment is to provide the second part of 395 the key Kbm required in the initial phase of our mechanism. 397 This message uses MH Type . The format of 398 the message is the following: 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Reserved | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | 406 + Pre-Binding Update Cookie + 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 + Care-of Keygen Token + 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | 414 . . 415 . Mobility Options . 416 . . 417 | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Reserved 421 16-bit filed reserved for future use. This value MUST be 422 initialized to zero by the sender, and MUST be ignored by the 423 receiver. 425 Pre-Binding Update Cookie 426 This 64-bit field contains the value from the same field in the 427 Pre-Binding Update message. 429 Care-of Keygen Token 430 This 64-bit field contains a Care-of Keygen Token, calculated as 431 specified in RFC3775. 433 Mobility Options 434 Variable-length field of such length that the complete Mobility 435 Header is an integer multiple of 8 octets long. This field 436 contains zero or more TLV-encoded mobility options. The receiver 437 MUST ignore and skip any options which it does not understand. 438 This specification does not define any options valid for this 439 message. 441 If no actual options are present in this message, no padding is 442 necessary and the Header Length field will be set to 2. 444 6.4. The Imprint Option 446 This option is carried by the first BU message sent by the MN to the 447 CN. The Imprint option allows the CN to check the ownership of the 448 two IPv6 addresses, i.e., HoA and CoA, used in the BU message. 450 This option is used in the BU message structure described in [OMIPv6- 451 CGA]. 453 The option format is as follows: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Option Type | Option Length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | | 461 + + 462 | | 463 + Imprint + 464 | | 465 + + 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Option Type 470 . 472 Option Length 473 Length of the option = 16 475 Option Data 476 This field contains the 128-bit imprint value used to compute the 477 CBID. 479 7. Security Considerations 481 This memo describes a solution, which addresses a particular security 482 threat related to the presence of a static malicious node on the path 483 between the HA and the CN. As described earlier, such threat can 484 easily prevent the mobile node from establishing a long lifetime 485 shared secret with the CN, and severely disrupts the other 486 alternatives, which are limited to using the classic RO mode as 487 defined in [MIPv6]. For this purpose, the suggested solution allows 488 the MN to provide the CN with a double proof of ownership of its HoA 489 and CoA IIDs and introduces a new way to compute the first home 490 keygen token. Note that this document considers only the case of 491 establishing a long lifetime security association. 493 The suggested solution offers a simple protection against this 494 particular threat, and hence increases the overall security of the 495 return routability procedure. 497 Finally, the suggested solution does not introduce nor enhance any 498 new or existing threats to the return routability. 500 8. References 502 8.1. Normative References 504 [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", 505 RFC 3792, March 2005. 507 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 508 Hashing for Message Authentication", RFC 2104, 509 February 1997. 511 [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 512 for IPv6", RFC 3775, June 2004. 514 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 515 Requirement Levels", RFC 2119, BCP , March 1997. 517 8.2. Informative References 519 [CBID] Montenegro, G. and C. Castelluccia, "Crypto-Based 520 Identifiers (CBID): Concepts and Applications", ACM 521 Transaction on Information and System Security (TISSEC), 522 February 2004. 524 [MIPv6-Sec] 525 Nikander, P., Arkko, J., Aura, T., and E. Nordmark, 526 "Mobile IPv6 version 6 Route Optimization Security Design 527 Background", Internet 528 Draft, draft-ietf-mip6-ro-sec-03.txt, June 2005. 530 [OMIPv6-CGA] 531 Arkko, J., Vogt, C., and W. Haddad, "Applying 532 Cryptographically Generated Addresses and Credit-Based 533 Authorization to Optimize Mobile (OMIPv6)", Internet 534 Draft, draft-arkko-mipshop-cga-cba-02.txt, October 2005. 536 Authors' Addresses 538 Francis Dupont 539 CELAR 541 Email: Francis.Dupont@point6.net 543 Wassim Haddad 544 Ericsson Research 545 8400 Decarie Blvd. 546 Town of Mount Royal, QC 547 Canada 549 Phone: +1 514 345 7900 #2334 550 Email: Wassim.Haddad@ericsson.com 552 Intellectual Property Statement 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at 574 ietf-ipr@ietf.org. 576 Disclaimer of Validity 578 This document and the information contained herein are provided on an 579 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 580 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 581 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 582 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 583 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 584 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 586 Copyright Statement 588 Copyright (C) The Internet Society (2006). This document is subject 589 to the rights, licenses and restrictions contained in BCP 78, and 590 except as set forth therein, the authors retain all their rights. 592 Acknowledgment 594 Funding for the RFC Editor function is currently provided by the 595 Internet Society.