idnits 2.17.00 (12 Aug 2021) /tmp/idnits59994/draft-haddad-mip6-cga-omipv6-04.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1168. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1175. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1181. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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. (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 (May 3, 2005) is 6220 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) == Unused Reference: '1' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1072, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1112, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3280 (ref. '4') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3447 (ref. '5') (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 3775 (ref. '6') (Obsoleted by RFC 6275) -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: draft-ietf-mip6-ro-sec has been published as RFC 4225 == Outdated reference: draft-ietf-send-cga has been published as RFC 3972 == Outdated reference: A later version (-01) exists of draft-dupont-mipv6-cn-ipsec-00 -- No information found for draft-ietf-mip6-precfgKbm - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Optimizations W. Haddad 3 Internet-Draft L. Madour 4 Expires: November 4, 2005 J. Arkko 5 Ericsson Research 6 F. Dupont 7 GET/ENST Bretagne 8 May 3, 2005 10 Applying Cryptographically Generated Addresses to Optimize MIPv6 (CGA- 11 OMIPv6) 12 draft-haddad-mip6-cga-omipv6-04 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 4, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This memo suggests a new and enhanced route optimization security 46 mechanism for Mobile IPv6 (MIPv6). The primary motivation for this 47 new mechanism is the reduction of signaling load and handoff delay. 48 The performance improvement achieved is elimination of all signaling 49 while not moving, and 33% of the per-movement signaling. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Efficiency of Current Protocols . . . . . . . . . . . . . . . 3 55 3. Overview of CGA . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1 Requirements . . . . . . . . . . . . . . . . . . . . . 7 58 4.2 Design Rationale . . . . . . . . . . . . . . . . . . . 7 59 4.3 Overview of Signaling . . . . . . . . . . . . . . . . 9 60 4.4 Cryptographic Calculations . . . . . . . . . . . . . . 11 61 4.5 Simultaneous Movements . . . . . . . . . . . . . . . . 12 62 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 63 5.1 The Pre Binding Update Message . . . . . . . . . . . . 12 64 5.2 The Pre Binding Acknowledgement Message . . . . . . . 14 65 5.3 The Pre Binding Test Message . . . . . . . . . . . . . 15 66 5.4 The CGA Key Option . . . . . . . . . . . . . . . . . . 17 67 5.5 The Shared Key Option . . . . . . . . . . . . . . . . 17 68 5.6 The Keep Flow Option . . . . . . . . . . . . . . . . . 18 69 5.7 The Extended Sequence Number Option . . . . . . . . . 19 70 5.8 The Signature (SIG) Option . . . . . . . . . . . . . . 20 71 5.9 Status Codes . . . . . . . . . . . . . . . . . . . . . 21 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 73 7. Performance Considerations . . . . . . . . . . . . . . . . . . 22 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 9.1 Normative References . . . . . . . . . . . . . . . . . 23 77 9.2 Informative References . . . . . . . . . . . . . . . . 24 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 79 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 80 Intellectual Property and Copyright Statements . . . . . . . . 27 82 1. Introduction 84 This document describes a new and enhanced route optimization (RO) 85 security mechanism for Mobile IPv6[6], based on the Cryptographically 86 Generated Addresses (CGAs) as described in [11]. The main goals of 87 this protocol are the reduction of the signaling load and the handoff 88 delay times. In addition, the protocol offers some additional 89 security benefits. 91 This document is a complete specification of an optional, alternative 92 mechanism to the standard scheme, and can be applied independently of 93 other specifications. In particular, it does not depend on ongoing 94 research work related to route optimization schemes, although it is 95 conceivable that some future enhancements can be applied on top of 96 this specification. 98 This rest of this document is structured as follows. Section 2 99 discusses the performance of the current Mobile IPv6 route 100 optimization mechanisms, and Section 3 introduces the concept of 101 CGAs. Section 4 gives an overview of our new mechanism and describes 102 its design rationale. Section 5 describes detailed message formats. 103 Finally, Section 6 and Section 7 analyze the security and performance 104 properties of the mechanism. 106 2. Efficiency of Current Protocols 108 This section discusses the efficiency of the current Mobile IPv6 109 route optimization mechanisms. 111 When evaluating the impact of signaling on performance, one should 112 take into account the whole stack and not inspect just one layer or 113 task. For instance, if the mobile node actually moved, the Mobile 114 IPv6 signaling would have to be compared to the link layer signaling, 115 access control and authentication signaling, and IPv6 tasks such as 116 router discovery, neighbor discovery, and duplicate address 117 detection. Such other signaling introduces delays, in many cases 118 significantly larger delays than exists in Mobile IPv6. In this 119 document we ignore these other delays, however, and concentrate on 120 making the mobility signaling as efficient as possible. But given 121 this, an improvement of, say, 50% in mobility signaling may become 122 just 10% unless other delays are also addressed. Other optimization 123 work is ongoing in other parts of the stack, however. 125 The performance of the current route optimization mechanism can be 126 evaluated according to its impact on handover delay, the amount of 127 bandwidth it uses per movement, the amount of bandwidth it uses when 128 not moving, and the overhead it causes for payload traffic. These 129 are discussed in the following: 131 Payload traffic overhead 133 The primary reason for using route optimization is to avoid 134 routing all traffic through a home agent. We assume that this 135 benefit is significant, particularly when two mobile nodes 136 communicate with each other. However, an overhead is associated 137 both with packets sent via bidirectional tunneling (tunnel) and 138 directly (options for carrying home addresses). A more detailed 139 analysis of the benefits and drawbacks are outside the scope of 140 this document, however, as we concentrate on the signaling aspects 141 only. 143 Latency 145 Basic home registration introduces a latency of zero to one 146 roundtrips before payload traffic can flow, depending on which 147 direction of traffic is looked at and whether the mobile node 148 chooses to wait for an acknowledgement. 150 With route optimization, the combined latency is one to three 151 roundtrips, depending again on the direction of packets and 152 waiting for acknowledgements. 154 More specifically, RFC 3775 allows mobile nodes to send data 155 packets after having sent the home registration Binding Update. 156 (If the Binding Update is lost or packets get reordered, the data 157 packets can be lost as well. But this may happen in any case.) 159 Home agents and correspondent nodes can start to send data packets 160 once they have sent the Binding Acknowledgement. The overall 161 latency until inbound traffic can start flow to the mobile is 162 therefore at least 1.5 roundtrips. 164 RFC 3775 assumes also that the home and care-of tests are run in 165 parallel. Some implementations may perform poorly, however. We 166 have seen implementations that do not run the home and care-of 167 tests in parallel, resulting in an overall delay of 3.5 to 4 168 roundtrips. But even when parallelism is employed, the latency 169 across the two different paths can be different. When two mobile 170 nodes are located close to each other, the home test exchange 171 typically takes longer than the rest of the messaging. 173 Bandwidth usage upon movement 175 As discussed in [12], one full run of the return routability and 176 binding update procedures is about 376 bytes. Assuming relatively 177 infrequent movements, for instance, every half hour, this 178 corresponds to about 1.7 bits/second average bandwidth usage. 180 The situation changes when more frequent movements are assumed. 181 Using a cell size of 100 meters and the speed of 120 km/h, there 182 will be one movement every 3 seconds. This amounts to a constant 183 route optimization-related signaling of about 1,000 bits/second. 184 This can be compared to a highly compressed voice stream which 185 typically have a rate about 10,000 to 30,000 bits/second. 187 Bandwidth usage when not moving 189 Current specifications require a periodic return routability test 190 and the re-establishment of the binding at the correspondent node. 191 This results in an average bandwidth of about 7 bits/second, if 192 performed every seven minutes as required in RFC 3775. While this 193 is an insignificant bandwidth for nodes that are actually 194 communicating, it can still represent a burden for hosts that just 195 have the bindings ready for a possible packet but are not 196 currently communicating. This can be problematic for hosts in 197 standby mode, for instance. 199 In summary, setting up the route optimization requires some signaling 200 and causes some latency. The latency issue is perhaps more critical 201 than the amount of signaling. This is because internet-wide RTTs are 202 typically much longer (some hundreds of milliseconds) than desired 203 latencies for real-time applications such as voice over IP (tens of 204 milliseconds). 206 3. Overview of CGA 208 As described in [11], a Cryptographically Generated Address (CGA) is 209 an IPv6 address, which contains a set of bits generated by hashing 210 the IPv6 address owner's public key. Such feature allows the user to 211 provide a "proof of ownership" of its IPv6 address. 213 The CGA offers three main advantages: it makes the spoofing attack 214 against the IPv6 address much harder and allows to sign messages with 215 the owner's private key. CGA does not require any upgrade or 216 modification in the infrastructure. 218 The CGA offers a method for binding a public key to an IPv6 address. 219 The binding between the public key and the address can be verified by 220 re-computing and comparing the hash value of the public key and other 221 parameters sent in the specific message with the interface identifier 222 in the IPv6 address belonging to the owner. Note that an attacker 223 can always create its own CGA address but he will not be able to 224 spoof someone else's address since he needs to sign the message with 225 the corresponding private key, which is supposed to be known only by 226 the real owner. 228 CGA assures that the interface identifier part of the address is 229 correct, but does little to ensure that the node is actually 230 reachable at that identifier and prefix. As a result, CGA needs to 231 be employed together with a reachability test where redirection 232 denial-of-service attacks are a concern. 234 Each CGA is associated with a public key and auxiliary parameters. 235 For OMIPv6, the public key MUST be formatted as a DER-encoded [7] 236 ASN.1 structure of the type SubjectPublicKeyInfo defined in the 237 Internet X.509 certificate profile [4]. 239 The CGA verification takes as input an IPv6 address and auxiliary 240 parameters. These parameters are the following: 242 o a 128-bit modifier, which can be any value, 244 o a 64-bit subnet prefix, which is equal to the subnet prefix of the 245 CGA, 247 o an 8-bit collision count, which can have values 0, 1 and 2. 249 If the verification succeeds, the verifier knows that the public key 250 in the CGA parameters is the authentic public key of the address 251 owner. In order to sign a message, a node needs the CGA, the 252 associated CGA parameters, the message and the private cryptographic 253 key that corresponds to the public key in the CGA parameters. The 254 node needs to use a 128 bit type tag for the message from the CGA 255 Message Type name space. The type tag is an IANA-allocated 128 bit 256 integer. 258 To sign a message, a node performs the following two steps: 260 1. Concatenate the 128 bit type tag (in the network byte order) and 261 message with the type tag to the left and message to the right. 262 The concatenation is the message to be signed in the next step. 264 2. Generate the RSA signature. The inputs to the generation 265 procedure are the private key and the concatenation created in 266 a). 268 4. Protocol 270 This section discusses first the requirements of the protocol and its 271 design rationale. An overview of the signaling is given after this, 272 followed by the rules regarding the cryptographic calculations and a 273 discussion of behaviour during simultaneous movements of two mobile 274 nodes. 276 4.1 Requirements 278 The main functional requirement is that the mobile node is able to 279 update the correspondent node with its current location. The 280 protocol also needs to work when two mobile nodes communicate with 281 each other. Finally, the solution must be suitable with the rest of 282 the Mobile IPv6 protocol [6], including, for instance, rules on how 283 Mobility Header messages are processed. 285 The desired characteristics of the protocol involve as small latency 286 as possible upon movements, and the avoidance of signaling for non- 287 moving hosts. Other things being equal, a protocol which uses the 288 smallest amount of bandwidth for signaling should be chosen. 290 The security requirements for the protocol are discussed in more 291 depth below: 293 o Attackers should not be able to redirect communication flows of 294 legitimate hosts to themselves, at least not beyond what is 295 already possible in plain IPv6. This requirement applies both to 296 ongoing and future communication flows. 298 o Attackers should not be able to redirect communication flows to 299 third parties. Otherwise, denial-of-service vulnerabilities 300 exist; while such vulnerabilities already exist in the current 301 Internet, we would like to avoid amplification possibilities 302 introduced through mobility mechanisms. 304 Note that this requirement applies even to attackers who are 305 themselves parties in a legitimate communication with another 306 node. 308 o Attackers should not be able to cause denial-of-service through 309 the potentially expensive computations involved in the route 310 optimization protocol itself. 312 4.2 Design Rationale 314 The design of the protocol follows the same principles as in the 315 original return routability protocol, but adds the following 316 mechanisms in order to make it more efficient: 318 CGA 320 CGA provides more assurance about the correctness of claimed 321 address than the pure use of routing paths. This makes it 322 possible to have a significant decrease in the signaling 323 frequency. 325 In addition, the public keys used in the CGA technique allow 326 certain data to be communicated privately between the nodes, which 327 makes some of our other techniques possible. 329 This technique is taken from [17] and [11], and appeared 330 originally in [9] and in [8]. 332 Semi-permanent security associations 334 CGA alone is not very efficient, due to its reliance public key 335 computations and its need for relatively long messages. We employ 336 semi-permanent security associations, created with the help of the 337 CGA public keys. After an initial CGA exchange, this makes 338 subsequent signaling efficient. 340 This technique appeared originally in [14]. 342 Minimal address testing 344 CGA is unable to guarantee that a particular address is actually 345 reachable at a given prefix. For this reason there is a need for 346 both home and care-of address tests. However, due to the higher 347 security of the CGA technique we can make these test much less 348 frequent. 350 The home address test is necessary, because otherwise a malicious 351 mobile node could create a CGA for the victim network prefix, 352 request a stream of packets to its current location from a public 353 server, and then let the binding expire. The result would be a 354 flooding attack against the victim network. In order to avoid 355 this, we require an initial home address test at the same time as 356 the CGA technique is applied. Signaling on subsequent movements 357 does not need to repeat this test, however. 359 This technique appeared originally in [14]. 361 The care-of address test is necessary, because otherwise flooding 362 attacks could be launched against unsuspecting third parties. 363 This test is still performed in our protocol, though in a slightly 364 different form than in RFC 3775. 366 This technique appeared originally in [13]. 368 Home routing while moving 370 Given that the per-movement signaling takes some time, mobile 371 nodes can optionally request their traffic to be routed through 372 their home address while this signaling is being completed. 374 This technique appeared originally in [18]. 376 Extended Sequence Numbers 378 In Secure Neighbor Discovery (SEND), CGA has been applied using 379 time stamps. However, this requires that the mobile nodes have 380 somewhat accurate clocks. In our application the concept of 381 sequence numbers is more appropriate, although the base Mobile 382 IPv6 sequence numbers have to be extended. Upon initial contact 383 the mobile node may send its current sequence number value to the 384 correspondent node, and the mobile is expected to increase this 385 value on every new signaling message to avoid replay attacks. 387 4.3 Overview of Signaling 389 The protocol is divided into two separate cases: establishing the 390 initial contact, and subsequent messaging. The subsequent messaging 391 is much more efficient than the initial contact. 393 The initial phase can be rerun at any time, if either node loses its 394 state, but it should be rerun at least once every 24 hours. 396 The following figure shows the signaling diagram for the initial 397 contact. The options shown MUST be included in the messages, where 398 conformance to this document is claimed. 400 1. MN to CN (via HA): Pre Binding Update 401 2a. CN to MN (via HA): Pre Binding Acknowledgement 402 2b. CN to MN (directly): Pre Binding Test 403 3. MN to CN (directly): Binding Update + ESN + CGA Key + SIG + BAD 404 4. CN to MN (directly): Binding Acknowledgment + ESN + SKey + BAD 406 Steps 1, 2a, and 2b implement an exchange which is needed to ensure 407 that the home and care-of addresses are reachable. It is also needed 408 in order to guard against CPU consumption attacks against CGA RSA 409 computations. The correspondent node SHOULD reject any Pre Binding 410 Update message carrying a home address not included in its IPv6 411 Destination Cache entry [3]. This ensures that at least some 412 communication has taken place before the exchange (see Section 6 for 413 a discussion of the security impacts of this). Steps 2a and 2b 414 provide keygen tokens which are used to construct a Kbm according to 415 the usual RFC 3775 rules. 417 If the correspondent node does not support a Pre Binding Update, it 418 returns a regular Binding Error. Upon receiving a Binding Error, the 419 mobile node decides to fall back to the use of the standard return 420 routability method or bidirectional tunneling, depending on its 421 policy. 423 Step 3 is the usual Binding Update, but includes the mobile node's 424 public key, signature, and its extended sequence number. At the same 425 time, these three options tell the correspondent node that the mobile 426 node supports this optimization. The Binding Authorization Data 427 option is included as well, and protects against replay attacks.. 429 In Step 4, the correspondent node it returns the deliver the semi- 430 permanent security association key in the SKey option, encrypted with 431 the mobile node's public key. It also returns the Extended Sequence 432 Number option. 434 As a result of the initial procedure, the following state has been 435 established in both nodes: 437 o A standard Binding Cache Entry. The lifetime of the binding is 438 not as severely limited as it is in standard Mobile IPv6. The 439 maximum allowed lifetime is 24 hours. 441 o The current extended sequence number value of the mobile node 442 node. 444 o A semi-permanent security association with a key, Kbmperm. 446 o The public keys and other parameters (see [11]) associated with 447 the addresses. 449 Security-wise, we know that the parties own their addresses (via 450 CGA), and we have some assurance that they are at least now at the 451 locations they claim to be (via address tests). The two endpoints 452 MUST silently discard any Binding Update or Acknowledgement message 453 sent and/or received, to/from any of them and not signed with the 454 Kbmperm and with correct Extended Sequence Number and Mobile IPv6 455 sequence number values. The only exception to this rule applies for 456 the valid Binding Update messages sent by the mobile node, containing 457 the CGA Key option. 459 The following figure shows the signaling diagram for subsequent 460 movements. The options shown in brackets MAY be included and other 461 options MUST be included in the messages. 463 1. MN to CN (directly): Care-of Test Init [+ ESN + KeepFlow + BAD] 464 2. CN to MN (directly): Care-of Test 465 3. MN to CN (directly): Binding Update + NI + ESN + BAD 466 4. CN to MN (directly): Binding Acknowledgment + ESN + BAD 468 Steps 1 through 2 implement the care-of address test operation; home 469 address tests are not needed. Note that even the care of address 470 test operation might be optimized away, if some additional mechanisms 471 such as [13] or [19] are employed. Such mechanisms are outside the 472 scope of this document, however. 474 However, Step 1 has also another purpose. Its goal is to inform the 475 correspondent node that it is in the process of moving but has not 476 yet completed the required signaling. If the mobile node has already 477 lost its previous care-of address, it includes the Extended Sequence 478 Number, KeepFlow, and Binding Authorization Data options to tell the 479 correspondent node that its current traffic should be redirected to 480 its home address until the Binding Update arrives. This request is 481 secured through authenticating it with Kbmperm. 483 Step 3 and 4 are the Binding Update and Acknowledgement. Instead of 484 the normal Kbm calculation, they are authenticated via Kbmperm' 485 defined as HMAC_SHA1(care-of keygen token | Kbmperm). Note that the 486 correspondent node will send the Binding Acknowledgment message ONLY 487 after a successful verification of the address owner's public key and 488 the signature in the Binding Update message. The correspondent node 489 MUST use the extended sequence number sent in the Binding Update 490 message to prevent against replay attacks that use past Binding 491 Update messages. 493 Security-wise, at this point we know that we are still talking 494 between the same nodes as we did in the initial contact. We have 495 also verified the care-of address, which assures that there's no 496 flooding attack going on. 498 4.4 Cryptographic Calculations 500 The Signature option is calculated with the mobile node's private key 501 over the following sequence of octets: 503 Mobility Data = care-of address | correspondent | MH Data 505 Where | denotes concatenation and "correspondent" is the 506 correspondent node's IPv6 address. Note that in case the 507 correspondent node is mobile, correspondent refers to the 508 correspondent node's home address. 510 MH Data is the content of the mobility message including the MH 511 header. The Authenticator within the Binding Authorization Data 512 option is zeroed for purposes of calculating the signature. 514 The RSA signature is generated by using the RSASSA-PKCS1-v1_5 [5] 515 signature algorithm with the SHA-1 hash algorithm. 517 When the SKey option is used, the correspondent node MUST encrypt the 518 Kbm with the MN's public key using the RSAES-PKCS1-v1_5 format [5]. 520 4.5 Simultaneous Movements 522 As specified in RFC 3775 [6], Mobility Header messages are generally 523 sent via the mobile node's home agent and to the peer's home address, 524 if it is also mobile. This makes it possible for two mobile nodes to 525 communicate even if they are moving simultaneously. (The exceptions 526 to tunneling via the home agent are the Binding Update/ 527 Acknowledgement messages. In addition, Care-of Test and Init message 528 are also sent directly to the current address.) 530 This approach is also used in this document to ensure that 531 simultaneous movements can be achieved. That is, the Pre Binding 532 Update message MUST be sent via the home agent and addressed to the 533 peer's home address, if it is mobile. The Pre Binding Acknowledgment 534 message MUST be sent via the correspondent node's home agent (if any) 535 and addressed to the source address of the Pre Binding Update 536 message. The Pre Binding Test message MUST be sent via the 537 correspondent node's home agent (again if any), but addressed to the 538 claimed care-of address from the Pre Binding Update message. 540 The Binding Update, Binding Acknowledgement, Care-of Test, and 541 Care-of Test Init messages follow the rules from RFC 3775. 543 5. Message Formats 545 5.1 The Pre Binding Update Message 547 This message is similar to a Binding Update message, but does not yet 548 establish any state at the correspondent node. The purpose of this 549 operation is to initiate the sending of two address tests. 551 This message uses MH Type . The format of 552 the message is the following: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Reserved | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | | 560 + + 561 | | 562 + Care-of Address + 563 | | 564 + + 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | | 568 + Pre Binding Update Cookie + 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | 572 . . 573 . Mobility Options . 574 . . 575 | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Reserved 580 16-bit field reserved for future use. This value MUST be 581 initialized to zero by the sender, and MUST be ignored by the 582 receiver. 584 Care-of Address 586 The current care-of address of the mobile node. 588 Pre Binding Update Cookie 590 64-bit field which contains a random value, a cookie used to 591 ensure that the responses match to requests. 593 Mobility Options 595 Variable-length field of such length that the complete Mobility 596 Header is an integer multiple of 8 octets long. This field 597 contains zero or more TLV-encoded mobility options. The receiver 598 MUST ignore and skip any options which it does not understand. 599 This specification does not define any options valid for this 600 message. 602 If no actual options are present in this message, no padding is 603 necessary and the Header Len field will be set to 3. 605 This message is tunneled through the home agent when the mobile node 606 is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel 607 mode between the home agent and the mobile node. This protection is 608 indicated by the IPsec security policy database, similarly to the 609 protection provided for Home Test Init messages. 611 5.2 The Pre Binding Acknowledgement Message 613 This message acknowledges a Pre Binding Update message. The purpose 614 of this acknowledgement is to provide a part of the key Kbm required 615 in the initial phase of our mechanism. 617 This message uses MH Type . The format of 618 the message is the following: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Reserved | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | | 626 + Pre Binding Update Cookie + 627 | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | | 630 + Home Keygen Token + 631 | | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | | 634 . . 635 . Mobility Options . 636 . . 637 | | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Reserved 642 16-bit field reserved for future use. This value MUST be 643 initialized to zero by the sender, and MUST be ignored by the 644 receiver. 646 Pre Binding Update Cookie 648 This 64-bit field contains the value from the same field in the 649 Pre Binding Update message. 651 Home Keygen Token 653 This 64-bit field contains a Home Keygen Token, calculated as 654 specified in RFC 3775. 656 Mobility Options 658 Variable-length field of such length that the complete Mobility 659 Header is an integer multiple of 8 octets long. This field 660 contains zero or more TLV-encoded mobility options. The receiver 661 MUST ignore and skip any options which it does not understand. 662 This specification does not define any options valid for this 663 message. 665 If no actual options are present in this message, no padding is 666 necessary and the Header Len field will be set to 2. 668 This message is tunneled through the home agent when the mobile node 669 is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel 670 mode between the home agent and the mobile node. This protection is 671 indicated by the IPsec security policy database, similarly to the 672 protection provided for Home Test messages. 674 5.3 The Pre Binding Test Message 676 This message also acknowledges a Pre Binding Update message, and 677 ensures that the mobile node is reachable at its claimed address. 678 The purpose of this acknowledgement is to provide the second part of 679 the key Kbm required in the initial phase of our mechanism. 681 This message uses MH Type . The format of 682 the message is the following: 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Reserved | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | | 690 + Pre Binding Update Cookie + 691 | | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | | 694 + Care-of Keygen Token + 695 | | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | | 698 . . 699 . Mobility Options . 700 . . 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Reserved 706 16-bit field reserved for future use. This value MUST be 707 initialized to zero by the sender, and MUST be ignored by the 708 receiver. 710 Pre Binding Update Cookie 712 This 64-bit field contains the value from the same field in the 713 Pre Binding Update message. 715 Care-of Keygen Token 717 This 64-bit field contains a Care-of Keygen Token, calculated as 718 specified in RFC 3775. 720 Mobility Options 722 Variable-length field of such length that the complete Mobility 723 Header is an integer multiple of 8 octets long. This field 724 contains zero or more TLV-encoded mobility options. The receiver 725 MUST ignore and skip any options which it does not understand. 726 This specification does not define any options valid for this 727 message. 729 If no actual options are present in this message, no padding is 730 necessary and the Header Len field will be set to 2. 732 5.4 The CGA Key Option 734 This option is used to carry the mobile node's CGA public key and 735 other parameters. It SHOULD be inserted in any Binding Update 736 message sent by the mobile node and signed with its CGA corresponding 737 private key. This option contains also all CGA parameters needed by 738 the correspondent node to check the validity of the mobile node's 739 CGA. 741 The format of the option is the following: 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Option Type | Option Length | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | | 749 + + 750 . CGA Parameters . 751 . . 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Option Type 757 . 759 Option Length 761 Length of the option. 763 Option Data 765 This field contains the mobile node's CGA public key and other 766 parameters, in the format defined in [11]. 768 5.5 The Shared Key Option 770 As it has been mentioned above, the correspondent node MUST send a 771 new Kbm each time it receives a Binding Update message containing the 772 CGA Parameter option. For this purpose, this proposal uses a new 773 option called SKey option, which MUST be inserted in the Binding 774 Acknowledgment message. 776 The format of the option is as follows: 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Option Type | Length = 16 | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | | 784 + + 785 | | 786 + Semi-Permanent Key for Binding Management (Kbmperm) + 787 | | 788 + + 789 | | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Option Type 794 . 796 Option Length 798 Length of the option. 800 Option Data 802 This field contains the Kbmperm value. Note that the content of 803 this field MUST be encrypted with the mobile node's public key as 804 defined in Section 4.4. The length of Kbmperm value is 20 octets 805 (before encryption or padding possibly involved [5]). 807 5.6 The Keep Flow Option 809 A mobile node which is in the process of moving may use this option 810 to indicate to the correspondent node that its traffic should be 811 redirected via its home address. This option MUST always be used 812 together with the Extended Sequence Number and Binding Authorization 813 Data options, using the Kbmperm to authenticate the message. 815 The format of the option is as follows: 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Option Type | Length = 16 | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | | 823 + + 824 | | 825 + Home Address + 826 | | 827 + + 828 | | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 Option Type 833 . 835 Option Length 837 Length of the option = 16. 839 Option Data 841 This field contains the home address of the mobile node. This 842 address needs to be carried here, as the Care-of Test Init message 843 could not otherwise be linked to this particular node. 845 5.7 The Extended Sequence Number Option 847 The nodes MUST use the Extended Sequence Number option in all Binding 848 Acknowledgment messages in the initial phase and in all Binding 849 Updates and Acknowledgement messages in the subsequent phase. In 850 addition, the Extended Sequence Number and Binding Authorization Data 851 options MUST be used when the Care-of Test Init and Care-of Test 852 message carries the KeepFlow option. 854 The option format is as follows: 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Option Type | Option Length | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | | 862 + Extended Sequence Number + 863 | | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 Option Type 868 . 870 Option Length 872 Length of the option = 8. 874 Option Data 876 A 64 bit unsigned integer, representing the extended sequence 877 number value. The mobile node MUST increase this value every time 878 it sends a new message to the correspondent node. The 879 correspondent node MUST return the most recent value it has seen. 881 5.8 The Signature (SIG) Option 883 When the mobile node signs the Binding Update message with its CGA 884 private key, it MUST insert the signature in the SIG option. Such 885 scenario occurs when the mobile node sends its first Binding Update 886 message to the correspondent node and if the mobile node reboots 887 during an ongoing session. 889 The option format is as follows: 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Option Type | Option Length | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | | 897 + + 898 . Signature . 899 . . 900 | | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 Option Type 905 . 907 Option Length 909 Length of the option. 911 Option Data 913 This field contains the signature of the MH message it is 914 contained within. 916 5.9 Status Codes 918 The following new Status codes are allocated: 920 Lost Kbmperm State () 922 This code is returned when the correspondent node does not have a 923 Binding Cache Entry, Kbmperm, or has an invalid Binding 924 Authorization Data option. The code MUST only be used in to 925 respond to Binding Updates that contain one of the mobility 926 options defined in this document. 928 6. Security Considerations 930 This draft describes a method to exploit the CGA features in order to 931 authenticate route optimization signaling. In fact, the CGA replaces 932 the authentication by providing a proof of ownership while the RR 933 procedure replaces the authentication by a routing property. 935 This proof of ownership ensures that only the mobile node will be 936 able to change the routing of packets destined to it, modulo 937 exhaustive attacks on the CGA mechanism itself. The feasibility of 938 such attacks and the defenses against them have been discussed in 939 [11]. 941 Note that, as specified, the proof of ownership protection applies 942 only to the correspondent node believing the statements made by the 943 mobile node. There is no guarantee that the answers from the 944 correspondent node truly come from that correspondent node and not 945 from someone who was on the path to the correspondent node during the 946 initial contact phase. This is because we do not require 947 correspondent nodes to have CGAs, and as a result, they can not make 948 any statements that are authenticated in the strong sense. We chose 949 not to protect against this, because this attack is something that 950 already exists in plain IPv6, as is explained in the following. Lets 951 assume that the correspondent node does not care about the IP address 952 of the peers contacting it and that it does not protect its payload 953 packets cryptographically. Then, a man-in-the-middle can always use 954 its own address when communicating to the correspondent node, and the 955 correspondent node's address when communicating to the mobile node. 956 Philosophically, one can also argue that since the problem we attempt 957 to solve here is routing modifications for the mobile node's address, 958 it is sufficient to ensure that these modifications are protected. 960 It should be mentioned that while the CGA can provide a protection 961 against unauthenticated Binding Updates, it can expose the involved 962 nodes to denial-of-service attacks since it is computationally 963 expensive. The draft limits the use of CGA to only the first 964 registration and if/when re-keying is needed. In addition, it is 965 RECOMMENDED that nodes track the amount of resources spent to the CGA 966 processing, and disable the processing of new requests when these 967 resources exceed a predefined limit. 969 The method specified in this document is secure against replay and 970 flooding attacks, due to the introduction of the Extended Sequence 971 Number option, the use of care-of address tests, and the use of an 972 initial home address test. 974 The Pre Binding Update message handling deserves also some 975 discussion. In contrast to existing messages in Mobile IPv6, the 976 responses to this message will be sent to two different addresses. 977 As such, it may be used in amplification and redirect attacks. In 978 the following we discuss these attacks and argue that the 979 vulnerability does not exceed the vulnerabilities already present in 980 the current IPv6 as it is. While the Destination Cache check is a 981 very weak test, it helps in this situation because the attacker must 982 have sent at least one packet beforehand. Thus, the potential 1:2 983 amplification attack is reduced to only a 2:3 amplification. In 984 addition, given that no serious attempt exists today to provide 985 tracing for spoofed packets, it does not matter whether flooding 986 attacks are direct, reflected from some node via a spoofed source 987 address, or reflected via the Pre Binding Update message. 989 7. Performance Considerations 991 Performance of our protocol depends on whether we look at the initial 992 or subsequent runs. The number of messages in the initial run is one 993 less as in base Mobile IPv6, but the size of the messages is 994 increased somewhat. 996 On a mobile node that does not move that often, there is a 997 significant signaling reduction, as the lifetimes can be set higher 998 than in return routability. For instance, a mobile node that stays 999 in the same address for a day will get a 99.52% signaling reduction. 1000 Such long lifetimes can be achieved immediately, as opposed to 1001 methods like [12] that grow them gradually. 1003 On a mobile node that moves fast, the per-movement signaling is 1004 reduced by 33%. 1006 Latency on the initial run is not affected, but on the subsequent 1007 movements there's a significant impact. This is because the home 1008 address test is eliminated. The exact effect depends on network 1009 topology, but if the home agent is far away and the correspondent 1010 node is on the same link, latency is almost completely eliminated. 1012 Additional latency and signaling improvements could be achieved 1013 through mechanisms that optimize the care-of address tests in some 1014 way. This is outside the scope of this document, however. 1016 8. IANA Considerations 1018 This document defines a new CGA Message Type name space for use as 1019 type tags in messages that may be signed using CGA signatures. The 1020 values in this name space are 128-bit unsigned integers. Values in 1021 this name space are allocated on a First Come First Served basis [2]. 1022 IANA assigns new 128-bit values directly without a review. 1024 CGA Message Type values for private use MAY be generated with a 1025 strong random-number generator without IANA allocation. 1027 This document defines a new 128-bit value under the CGA Message Type 1028 [11] namespace, 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13. 1030 This document defines a set of new mobility options, which must be 1031 assigned Option Type values within the mobility option numbering 1032 space of [6]. This document also allocates a new Status code value. 1034 9. References 1036 9.1 Normative References 1038 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1039 Levels", BCP 14, RFC 2119, March 1997. 1041 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1042 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1044 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1045 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1047 [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1048 Public Key Infrastructure Certificate and Certificate Revocation 1049 List (CRL) Profile", RFC 3280, April 2002. 1051 [5] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 1052 (PKCS) #1: RSA Cryptography Specifications Version 2.1", 1053 RFC 3447, February 2003. 1055 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1056 IPv6", RFC 3775, June 2004. 1058 [7] International Telecommunications Union, "Information Technology 1059 - ASN.1 encoding rules: Specification of Basic Encoding Rules 1060 (BER), Canonical Encoding Rules (CER) and Distinguished Encoding 1061 Rules (DER)", ITU-T Recommendation X.690, July 2002. 1063 9.2 Informative References 1065 [8] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", 1066 Computer Communications Review, April 2001. 1068 [9] Nikander, P., "Denial-of-Service, Address Ownership, and Early 1069 Authentication in the IPv6 World", Proceedings of the Cambridge 1070 Security Protocols Workshop, April 2001. 1072 [10] Nikander, P., "Mobile IP version 6 Route Optimization Security 1073 Design Background", draft-ietf-mip6-ro-sec-00 (work in 1074 progress), April 2004. 1076 [11] Aura, T., "Cryptographically Generated Addresses (CGA)", 1077 draft-ietf-send-cga-04 (work in progress), December 2003. 1079 [12] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding 1080 Lifetime Extension", 1081 draft-arkko-mipv6-binding-lifetime-extension-00 (work in 1082 progress), May 2004. 1084 [13] Dupont, F. and J. Combes, "Using IPsec between Mobile and 1085 Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-00 (work 1086 in progress), April 2004. 1088 [14] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)", 1089 draft-haddad-mipv6-omipv6-01 (work in progress), February 2004. 1091 [15] Haddad, W., "Applying Cryptographically Generated Addresses to 1092 BUB (BUB+)", draft-haddad-mip6-cga-bub-00 (work in progress), 1093 May 2004. 1095 [16] Haddad, W., "BUB: Binding Update Backhauling", 1096 draft-haddad-mipv6-bub-01 (work in progress), February 2004. 1098 [17] Roe, M., "Authentication of Mobile IPv6 Binding Updates and 1099 Acknowledgments", draft-roe-mobileip-updateauth-02 (work in 1100 progress), March 2002. 1102 [18] Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding 1103 Updates for Mobile IPv6", 1104 draft-vogt-mip6-early-binding-updates-00 (work in progress), 1105 February 2004. 1107 [19] Vogt, C., Arkko, J., Bless, R., Doll, M., and T. Kuefner, 1108 "Credit-Based Authorization for Mobile IPv6 Early Binding 1109 Updates", draft-vogt-mipv6-credit-based-authorization-00 (work 1110 in progress), May 2004. 1112 [20] Perkins, C., "Preconfigured Binding Management Keys for Mobile 1113 IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), 1114 April 2004. 1116 Authors' Addresses 1118 Wassim Haddad 1119 Ericsson Research 1120 8400, Decarie Blvd 1121 Town of Mount Royal 1122 Quebec H4P 2N2, Canada 1124 Email: wassim.haddad@ericsson.com 1126 Lila Madour 1127 Ericsson Research 1128 8400, Decarie Blvd 1129 Town of Mount Royal 1130 Quebec H4P 2N2, Canada 1132 Email: lila.madour@ericsson.com 1134 Jari Arkko 1135 Ericsson Research 1136 FI-02420 Jorvas 1137 Finland 1139 Email: jari.arkko@ericsson.com 1140 Francis Dupont 1141 GET/ENST Bretagne 1142 Campus de Rennes 2, rue de la Chataigneraie 1143 CS 17607 1144 35576 Cesson-Sevigne Cedex 1145 France 1147 Email: Francis.Dupont@enst-bretagne.fr 1149 Appendix A. Acknowledgments 1151 The authors would like to thank Pekka Nikander, Tuomas Aura, Greg 1152 O'Shea, Mike Roe, Gabriel Montenegro, and Vesa Torvinen for 1153 interesting discussions around CGA. The authors would also like to 1154 acknowledge that [17] pioneered the work in the use of CGA for Mobile 1155 IPv6. Finally, we would like to thank Marcelo Bagnulo, Suresh 1156 Krishnan and Mohan Parthasarathy for their review and comments on 1157 this document. 1159 Intellectual Property Statement 1161 The IETF takes no position regarding the validity or scope of any 1162 Intellectual Property Rights or other rights that might be claimed to 1163 pertain to the implementation or use of the technology described in 1164 this document or the extent to which any license under such rights 1165 might or might not be available; nor does it represent that it has 1166 made any independent effort to identify any such rights. Information 1167 on the procedures with respect to rights in RFC documents can be 1168 found in BCP 78 and BCP 79. 1170 Copies of IPR disclosures made to the IETF Secretariat and any 1171 assurances of licenses to be made available, or the result of an 1172 attempt made to obtain a general license or permission for the use of 1173 such proprietary rights by implementers or users of this 1174 specification can be obtained from the IETF on-line IPR repository at 1175 http://www.ietf.org/ipr. 1177 The IETF invites any interested party to bring to its attention any 1178 copyrights, patents or patent applications, or other proprietary 1179 rights that may cover technology that may be required to implement 1180 this standard. Please address the information to the IETF at 1181 ietf-ipr@ietf.org. 1183 The IETF has been notified of intellectual property rights claimed in 1184 regard to some or all of the specification contained in this 1185 document. For more information consult the online list of claimed 1186 rights. 1188 Disclaimer of Validity 1190 This document and the information contained herein are provided on an 1191 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1192 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1193 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1194 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1195 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1196 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1198 Copyright Statement 1200 Copyright (C) The Internet Society (2005). This document is subject 1201 to the rights, licenses and restrictions contained in BCP 78, and 1202 except as set forth therein, the authors retain all their rights. 1204 Acknowledgment 1206 Funding for the RFC Editor function is currently provided by the 1207 Internet Society.