idnits 2.17.1 draft-haddad-mip6-cga-omipv6-02.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.5 on line 1161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1146. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1167), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** 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? 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 (June 18, 2004) is 7251 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 1003, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1077, 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: A later version (-03) exists of draft-ietf-mip6-ro-sec-00 == Outdated reference: A later version (-06) exists of draft-ietf-send-cga-04 == 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: 11 errors (**), 0 flaws (~~), 9 warnings (==), 7 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: December 17, 2004 J. Arkko 5 Ericsson Research 6 F. Dupont 7 GET/ENST Bretagne 8 June 18, 2004 10 Applying Cryptographically Generated Addresses to Optimize MIPv6 11 (CGA-OMIPv6) 12 draft-haddad-mip6-cga-omipv6-02 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3667. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 17, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This memo suggests a new and enhanced route optimization security 45 mechanism for Mobile IPv6 (MIPv6). The primary motivation for this 46 new mechanism is the reduction of signaling load and handoff delay. 47 The performance improvement achieved is elimination of all signaling 48 while not moving, and 33% of the per-movement signaling. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Efficiency of Current Protocols . . . . . . . . . . . . . . . 3 54 3. Overview of CGA . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 7 57 4.2 Design Rationale . . . . . . . . . . . . . . . . . . . . 7 58 4.3 Overview of Signaling . . . . . . . . . . . . . . . . . 9 59 4.4 Cryptographic Calculations . . . . . . . . . . . . . . . 11 60 4.5 Simultaneous Movements . . . . . . . . . . . . . . . . . 12 61 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 62 5.1 The Pre Binding Update Message . . . . . . . . . . . . . 12 63 5.2 The Pre Binding Acknowledgement Message . . . . . . . . 14 64 5.3 The Pre Binding Test Message . . . . . . . . . . . . . . 15 65 5.4 The CGA Key Option . . . . . . . . . . . . . . . . . . . 17 66 5.5 The Shared Key Option . . . . . . . . . . . . . . . . . 17 67 5.6 The Keep Flow Option . . . . . . . . . . . . . . . . . . 18 68 5.7 The Clock Option . . . . . . . . . . . . . . . . . . . . 19 69 5.8 The Signature (SIG) Option . . . . . . . . . . . . . . . 20 70 5.9 Status Codes . . . . . . . . . . . . . . . . . . . . . . 21 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 72 7. Performance Considerations . . . . . . . . . . . . . . . . . . 22 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 74 Normative References . . . . . . . . . . . . . . . . . . . . . 23 75 Informative References . . . . . . . . . . . . . . . . . . . . 23 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 77 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 78 Intellectual Property and Copyright Statements . . . . . . . . 26 80 1. Introduction 82 This memo describes a new and enhanced route optimization (RO) 83 security mechanism for Mobile IPv6[6], based on the Cryptographically 84 Generated Addresses (CGAs) as described in [11]. The main goals of 85 this protocol are the reduction of the signaling load and the handoff 86 delay times. In addition, the protocol offers some additional 87 security benefits. 89 This version of the draft is now a standalone document and no longer 90 depends on past proposals such as [14], [16], or [15]. Design 91 rationale behind the mechanism is explained, as well as its 92 performance implications. Some modifications of the signaling have 93 been also been made: 95 o Selection of a new shared secret happens now through the use of 96 the CGA Key option and the Lost Kbmperm State Status code value. 98 o An integrated care-of test is provided in this method, while 99 allowing other optimizations of such tests. 101 o Payload packets can be routed via the home address while a care-of 102 test is ongoing. 104 o Avoiding flooding attacks related to untested home addresses. 106 o Options have been renamed. 108 This rest of this document is structured as follows. Section 2 109 discusses the performance of the current Mobile IPv6 route 110 optimization mechanisms, and Section 3 introduces the concept of 111 CGAs. Section 4 gives an overview of our new mechanism and describes 112 its design rationale. Section 5 describes detailed message formats. 113 Finally, Section 6 and Section 7 analyze the security and performance 114 properties of the mechanism. 116 2. Efficiency of Current Protocols 118 This section discusses the efficiency of the current Mobile IPv6 119 route optimization mechanisms. 121 When evaluating the impact of signaling on performance, one should 122 take into account the whole stack and not inspect just one layer or 123 task. For instance, if the mobile node actually moved, the Mobile 124 IPv6 signaling would have to be compared to the link layer signaling, 125 access control and authentication signaling, and IPv6 tasks such as 126 router discovery, neighbor discovery, and duplicate address 127 detection. Such other signaling introduces delays, in many cases 128 significantly larger delays than exists in Mobile IPv6. In this 129 document we ignore these other delays, however, and concentrate on 130 making the mobility signaling as efficient as possible. But given 131 this, an improvement of, say, 50% in mobility signaling may become 132 just 10% unless other delays are also addressed. Other optimization 133 work is ongoing in other parts of the stack, however. 135 The performance of the current route optimization mechanism can be 136 evaluated according to its impact on handover delay, the amount of 137 bandwidth it uses per movement, the amount of bandwidth it uses when 138 not moving, and the overhead it causes for payload traffic. These are 139 discussed in the following: 141 Payload traffic overhead 143 The primary reason for using route optimization is to avoid 144 routing all traffic through a home agent. We assume that this 145 benefit is significant, particularly when two mobile nodes 146 communicate with each other. A more detailed analysis of the 147 benefits and drawbacks are outside the scope of this document, 148 however, as we concentrate on the signaling aspects only. 150 Latency 152 Basic home registration introduces a latency of zero to one 153 roundtrips before payload traffic can flow, depending on which 154 direction of traffic is looked at and whether the mobile node 155 chooses to wait for an acknowledgement. 157 With route optimization, the combined latency is one to three 158 roundtrips, depending again on the direction of packets and 159 waiting for acknowledgements. 161 More specifically, RFC 3775 allows mobile nodes to send data 162 packets after having sent the home registration Binding Update. 163 (If the Binding Update is lost or packets get reordered, the data 164 packets can be lost as well. But this may happen in any case.) 166 Home agents and correspondent nodes can start to send data packets 167 once they have sent the Binding Acknowledgement. The overall 168 latency until inbound traffic can start flow to the mobile is 169 therefore at least 1.5 roundtrips. 171 RFC 3775 assumes also that the home and care-of tests are run in 172 parallel. Some implementations may perform poorly, however. We 173 have seen implementations that do not run the home and care-of 174 tests in parallel, resulting in an overall delay of 3.5 to 4 175 roundtrips. But even when parallelism is employed, the latency 176 across the two different paths can be different. When two mobile 177 nodes are located close to each other, the home test exchange 178 typically takes longer than rest of the messaging. 180 Bandwidth usage upon movement 182 As discussed in [12], one full run of the return routability and 183 binding update procedures is about 376 bytes. Assuming relatively 184 infrequent movements, for instance, every half hour, this 185 corresponds to about 1.7 bits/second average bandwidth usage. 187 The situation changes when more frequent movements are assumed. 188 Using a cell size of 100 meters and the speed of 120 km/h, there 189 will be one movement every 3 seconds. This amounts to a constant 190 route optimization-related signaling of about 1,000 bits/second. 191 This can be compared to a highly compressed voice stream which 192 typically have a rate about 10,000 to 30,000 bits/second. 194 Bandwidth usage when not moving 196 Current specifications require a periodic return routability test 197 and the re-establishment of the binding at the correspondent node. 198 This results in an average bandwidth of about 7 bits/second, if 199 performed every seven minutes as required in RFC 3775. While this 200 is an insignificant bandwidth for nodes that are actually 201 communicating, it can still represent a burden for hosts that just 202 have the bindings ready for a possible packet but are not 203 currently communicating. This can be problematic for hosts in 204 standby mode, for instance. 206 In summary, setting up the route optimization requires some signaling 207 and causes some latency. The latency issue is perhaps more critical 208 than the amount of signaling. This is because internet-wide RTTs are 209 typically much longer (some hundreds of milliseconds) than desired 210 latencies for real-time applications such as voice over IP (tens of 211 milliseconds). 213 3. Overview of CGA 215 As described in [11], a Cryptographically Generated Address (CGA) is 216 an IPv6 address, which contains a set of bits generated by hashing 217 the IPv6 address owner's public key. Such feature allows the user to 218 provide a "proof of ownership" of its IPv6 address. 220 The CGA offers three main advantages: it makes the spoofing attack 221 against the IPv6 address much harder and allows to sign messages with 222 the owner's private key. CGA does not require any upgrade or 223 modification in the infrastructure. 225 The CGA offers a method for binding a public key to an IPv6 address. 226 The binding between the public key and the address can be verified by 227 re-computing and comparing the hash value of the public key and other 228 parameters sent in the specific message with the interface identifier 229 in the IPv6 address belonging to the owner. Note that an attacker can 230 always create its own CGA address but he will not be able to spoof 231 someone else's address since he needs to sign the message with the 232 corresponding private key, which is supposed to be known only by the 233 real owner. 235 CGA assures that the interface identifier part of the address is 236 correct, but does little to ensure that the node is actually 237 reachable at that identifier and prefix. As a result, CGA needs to be 238 employed together with a reachability test where redirection 239 denial-of-service attacks are a concern. 241 Each CGA is associated with a public key and auxiliary parameters. 242 For OMIPv6, the public key MUST be formatted as a DER-encoded [7] 243 ASN.1 structure of the type SubjectPublicKeyInfo defined in the 244 Internet X.509 certificate profile [4]. 246 The CGA verification takes as input an IPv6 address and auxiliary 247 parameters. These parameters are the following: 249 o a 128-bit modifier, which can be any value, 251 o a 64-bit subnet prefix, which is equal to the subnet prefix of the 252 CGA, 254 o an 8-bit collision count, which can have values 0, 1 and 2. 256 If the verification succeeds, the verifier knows that the public key 257 in the CGA parameters is the authentic public key of the address 258 owner. In order to sign a message, a node needs the CGA, the 259 associated CGA parameters, the message and the private cryptographic 260 key that corresponds to the public key in the CGA parameters. The 261 node needs to use a 128 bit type tag for the message from the CGA 262 Message Type name space. The type tag is an IANA-allocated 128 bit 263 integer. 265 To sign a message, a node performs the following two steps: 267 1. Concatenate the 128 bit type tag (in the network byte order) and 268 message with the type tag to the left and message to the right. 269 The concatenation is the message to be signed in the next step. 271 2. Generate the RSA signature. The inputs to the generation 272 procedure are the private key and the concatenation created in 273 a). 275 4. Protocol 277 4.1 Requirements 279 We will first consider the requirements of the protocol. The main 280 functional requirement is that the mobile node is able to update the 281 correspondent node with its current location. The protocol also needs 282 to work when two mobile nodes communicate with each other. Finally, 283 the solution must be suitable with the rest of the Mobile IPv6 284 protocol [6], including, for instance, rules on how Mobility Header 285 messages are processed. 287 The desired characteristics of the protocol involve as small latency 288 as possible upon movements, and the avoidance of signaling for 289 non-moving hosts. Other things being equal, a protocol which uses the 290 smallest amount of bandwidth for signaling should be chosen. 292 The security requirements for the protocol are discussed in more 293 depth below: 295 o Attackers should not be able to redirect communication flows of 296 legitimate hosts to themselves, at least not beyond what is 297 already possible in plain IPv6. This requirement applies both to 298 ongoing and future communication flows. 300 o Attackers should not be able to redirect communication flows to 301 third parties. Otherwise, denial-of-service vulnerabilities exist; 302 while such vulnerabilities already exist in the current Internet, 303 we would like to avoid amplification possibilities introduced 304 through mobility mechanisms. 306 Note that this requirement applies even to attackers who are 307 themselves parties in a legitimate communication with another 308 node. 310 o Attackers should not be able to cause denial-of-service through 311 the potentially expensive computations involved in the route 312 optimization protocol itself. 314 4.2 Design Rationale 316 The design of the protocol follows the same principles as in the 317 original return routability protocol, but adds the following 318 mechanisms in order to make it more efficient: 320 CGA 322 CGA provides more assurance about the correctness of claimed 323 address than the pure use of routing paths. This makes it possible 324 to have a significant decrease in the signaling frequency. 326 In addition, the public keys used in the CGA technique allow 327 certain data to be communicated privately between the nodes, which 328 makes some of our other techniques possible. 330 This technique is taken from [17] and [11], and appeared 331 originally in [9] and in [8]. 333 Semi-permanent security associations 335 CGA alone is not very efficient, due to its reliance public key 336 computations and its need for relatively long messages. We employ 337 semi-permanent security associations, created with the help of the 338 CGA public keys. After an initial CGA exchange, this makes 339 subsequent signaling efficient. 341 This technique appeared originally in [14]. 343 Minimal address testing 345 CGA is unable to guarantee that a particular address is actually 346 reachable at a given prefix. For this reason there is a need for 347 both home and care-of address tests. However, due to the higher 348 security of the CGA technique we can make these test much less 349 frequent. 351 The home address test is necessary, because otherwise a malicious 352 mobile node could create a CGA for the victim network prefix, 353 request a stream of packets to its current location from a public 354 server, and then let the binding expire. The result would be a 355 flooding attack against the victim network. In order to avoid 356 this, we require an initial home address test at the same time as 357 the CGA technique is applied. Signaling on subsequent movements 358 does not need to repeat this test, however. 360 This technique appeared originally in [14]. 362 The care-of address test is necessary, because otherwise flooding 363 attacks could be launched against unsuspecting third parties. This 364 test is still performed in our protocol, though in a slightly 365 different form than in RFC 3775. 367 This technique appeared originally in [13]. 369 Home routing while moving 371 Given that the per-movement signaling takes some time, mobile 372 nodes can optionally request their traffic to be routed through 373 their home address while this signaling is being completed. 375 This technique appeared originally in [18]. 377 Logical Clocks 379 In Secure Neighbor Discovery (SEND), CGA has been applied using 380 time stamps. However, this requires that the mobile nodes have 381 somewhat accurate clocks. In our application the concept of 382 logical clocks is more appropriate. This is because upon initial 383 contact the mobile node may send its current logical clock value 384 to the correspondent node, and the mobile is expected to increase 385 this clock value on every new signaling message to avoid replay 386 attacks. (In essence, such logical clocks are an extended sequence 387 number space.) 389 4.3 Overview of Signaling 391 The protocol is divided into two separate cases: establishing the 392 initial contact, and subsequent messaging. The subsequent messaging 393 is much more efficient than the initial contact. 395 The initial phase can be rerun at any time, if either node loses its 396 state, but it should be rerun at least once every day. 398 The following figure shows the signaling diagram for the initial 399 contact. The options shown MUST be included in the messages, where 400 conformance to this document is claimed. 402 1. MN to CN (via HA): Pre Binding Update 403 2a. CN to MN (via HA): Pre Binding Acknowledgement 404 2b. CN to MN (directly): Pre Binding Test 405 3. MN to CN (directly): Binding Update + Clock + CGA Key + SIG + BAD 406 4. CN to MN (directly): Binding Acknowledgment + Clock + SKey + BAD 408 Steps 1, 2a, and 2b implement an exchange which is needed to ensure 409 that the home and care-of addresses are reachable. It is also needed 410 in order to guard against CPU consumption attacks against CGA RSA 411 computations. The correspondent node SHOULD reject any Pre Binding 412 Update message carrying a home address not included in its IPv6 413 Destination Cache entry [3]. This ensures that at least some 414 communication has taken place before the exchange (see Section 6 for 415 a discussion of the security impacts of this). Steps 2a and 2b 416 provide keygen tokens which are used to construct a Kbm according to 417 the usual RFC 3775 rules. 419 If the correspondent node does not support a Pre Binding Update, it 420 returns a regular Binding Error. Upon receiving a Binding Error, the 421 mobile node decides to fall back to the use of the standard return 422 routability method or bidirectional tunneling, depending on its 423 policy. 425 Step 3 is the usual Binding Update, but includes the mobile node's 426 public key, signature, and its logical clock. At the same time, these 427 three options tell the correspondent node that the mobile node 428 supports this optimization. The Binding Authorization Data option is 429 included as well, and protects against replay attacks.. 431 In Step 4, the correspondent node it returns the deliver the 432 semi-permanent security association key in the SKey option, encrypted 433 with the mobile node's public key. It also returns the Clock option. 435 As a result of the initial procedure, the following state has been 436 established in both nodes: 438 o A standard Binding Cache Entry. The lifetime of the binding is not 439 as severely limited as it is in standard Mobile IPv6. The maximum 440 allowed lifetime is 24 hours. 442 o The current logical clock value of the mobile node 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 Clock and sequence number values. The only 455 exception to this rule applies for the valid Binding Update messages 456 sent by the mobile node, containing the CGA Key option. 458 The following figure shows the signaling diagram for subsequent 459 movements. The options shown in brackets MAY be included and other 460 options MUST be included in the messages. 462 1. MN to CN (directly): Care-of Test Init [+ Clock + KeepFlow + BAD] 463 2. CN to MN (directly): Care-of Test 464 3. MN to CN (directly): Binding Update + NI + Clock + BAD 465 4. CN to MN (directly): Binding Acknowledgment + Clock + BAD 467 Steps 1 through 2 implement the care-of address test operation; home 468 address tests are not needed. Note that even the care of address test 469 operation might be optimized away, if some additional mechanisms such 470 as [13] or [19] are employed. Such mechanisms are outside the scope 471 of this document, however. 473 However, Step 1 has also another purpose. Its goal is to inform the 474 correspondent node that it is in the process of moving but has not 475 yet completed the required signaling. If the mobile node has already 476 lost its previous care-of address, it includes the Clock, KeepFlow, 477 and Binding Authorization Data options to tell the correspondent node 478 that its current traffic should be redirected to its home address 479 until the Binding Update arrives. This request is secured through 480 authenticating it with Kbmperm. 482 Step 3 and 4 are the Binding Update and Acknowledgement. Instead of 483 the normal Kbm calculation, they are authenticated via Kbmperm' 484 defined as HMAC_SHA1(care-of keygen token | Kbmperm). Note that the 485 correspondent node will send the Binding Acknowledgment message ONLY 486 after a successful verification of the address owner's public key and 487 the signature in the Binding Update message. The correspondent node 488 MUST use the logical clock sent in the Binding Update message to 489 prevent against replay attacks that use past Binding Update messages. 491 Security-wise, at this point we know that we are still talking 492 between the same nodes as we did in the initial contact. We have also 493 verified the care-of address, which assures that there's no flooding 494 attack going on. 496 4.4 Cryptographic Calculations 498 Rules for Signature option with the mobile node's private key are the 499 following: 501 Mobility Data = care-of address | correspondent | MH Data 503 Signature = ENCRYPT( SHA1 (Mobility 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 TBD format. 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 the 552 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 the 618 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. The 678 purpose of this acknowledgement is to provide the second part of the 679 key Kbm required in the initial phase of our mechanism. 681 This message uses MH Type . The format of the 682 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 message 736 sent by the mobile node and signed with its CGA corresponding private 737 key. This option contains also all CGA parameters needed by the 738 correspondent node to check the validity of the mobile node's CGA. 740 The format of the option is the following: 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Option Type | Option Length | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | | 748 + + 749 . CGA Parameters . 750 . . 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Option Type 756 . 758 Option Length 760 Length of the option. 762 Option Data 764 This field contains the mobile node's CGA public key and other 765 parameters, in the format defined in [11]. 767 5.5 The Shared Key Option 769 As it has been mentioned above, the correspondent node MUST send a 770 new Kbm each time it receives a Binding Update message containing the 771 CGA Parameter option. For this purpose, this proposal uses a new 772 option called SKey option, which MUST be inserted in the Binding 773 Acknowledgment message. 775 The format of the option is as follows: 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Option Type | Length = 16 | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | | 783 + + 784 | | 785 + Key for Binding Management (Kbm) + 786 | | 787 + + 788 | | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Option Type 793 . 795 Option Length 797 Length of the option = 16. 799 Option Data 801 This field contains the Kbm value. Note that the content of this 802 field MUST be encrypted with the mobile node's public key. 804 5.6 The Keep Flow Option 806 A mobile node which is in the process of moving may use this option 807 to indicate to the correspondent node that its traffic should be 808 redirected via its home address. This option MUST always be used 809 together with the Clock and Binding Authorization Data options, using 810 the Kbmperm to authenticate the message. 812 The format of the option is as follows: 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Option Type | Length = 16 | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | | 820 + + 821 | | 822 + Home Address + 823 | | 824 + + 825 | | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Option Type 830 . 832 Option Length 834 Length of the option = 16. 836 Option Data 838 This field contains the home address of the mobile node. This 839 address needs to be carried here, as the Care-of Test Init message 840 could not otherwise be linked to this particular node. 842 5.7 The Clock Option 844 The nodes MUST use the Clock option in all Binding Acknowledgment 845 messages in the initial phase and in all Binding Updates and 846 Acknowledgement messages in the subsequent phase. In addition, the 847 Clock and Binding Authorization Data options MUST be used when the 848 Care-of Test Init and Care-of Test message carries the KeepFlow 849 option. 851 The option format is as follows: 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Option Type | Option Length | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | | 859 + Logical Clock + 860 | | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 Option Type 865 . 867 Option Length 869 Length of the option = 8. 871 Option Data 873 A 64 bit unsigned integer, representing a logical clock value. The 874 mobile node MUST increase this value every time it sends a new 875 message to the correspondent node. The correspondent node MUST 876 return the most recent value it has seen. 878 5.8 The Signature (SIG) Option 880 When the mobile node signs the Binding Update message with its CGA 881 private key, it MUST insert the signature in the SIG option. Such 882 scenario occurs when the mobile node sends its first Binding Update 883 message to the correspondent node and if the mobile node reboots 884 during an ongoing session. 886 The option format is as follows: 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Option Type | Option Length | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | | 894 + + 895 . Signature . 896 . . 897 | | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Option Type 902 . 904 Option Length 906 Length of the option. 908 Option Data 910 This field contains the signature of the MH message it is 911 contained within. 913 5.9 Status Codes 915 The following new Status codes are allocated: 917 Lost Kbmperm State () 919 This code is returned when the correspondent node does not have a 920 Binding Cache Entry, Kbmperm, or has an invalid Binding 921 Authorization Data option. The code MUST only be used in to 922 respond to Binding Updates that contain one of the mobility 923 options defined in this document. 925 6. Security Considerations 927 This draft describes a method to exploit the CGA features in order to 928 authenticate route optimization signaling. In fact, the CGA replaces 929 the authentication by providing a proof of ownership while the RR 930 procedure replaces the authentication by a routing property. 932 However, it should be mentioned that while the CGA can provide a 933 protection against unauthenticated Binding Updates, it can expose the 934 involved nodes to denial-of-service attacks since it is 935 computationally expensive. The draft limits the use of CGA to only 936 the first registration and if/when re-keying is needed. In addition, 937 it is RECOMMENDED that nodes track the amount of resources spent to 938 the CGA processing, and disable the processing of new requests when 939 these resources exceed a predefined limit. 941 The Pre Binding Update message handling deserves also some 942 discussion. In contrast to existing messages in Mobile IPv6, the 943 responses to this message will be sent to two different addresses. As 944 such, it may be used in amplification and redirect attacks. In the 945 following we discuss these attacks and argue that the vulnerability 946 does not exceed the vulnerabilities already present in the current 947 IPv6 as it is. While the Destination Cache check is a very weak test, 948 it helps in this situation because the attacker must have sent at 949 least one packet beforehand. Thus, the potential 1:2 amplification 950 attack is reduced to only a 2:3 amplification. In addition, given 951 that no serious attempt exists today to provide tracing for spoofed 952 packets, it does not matter whether flooding attacks are direct, 953 reflected from some node via a spoofed source address, or reflected 954 via the Pre Binding Update message. 956 7. Performance Considerations 958 Performance of our protocol depends on whether we look at the initial 959 or subsequent runs. The number of messages in the initial run is one 960 less as in base Mobile IPv6, but the size of the messages is 961 increased somewhat. 963 On a mobile node that does not move that often, there is a 964 significant signaling reduction, as the lifetimes can be set higher 965 than in return routability. For instance, a mobile node that stays in 966 the same address for a day will get a 99.52% signaling reduction. 967 Such long lifetimes can be achieved immediately, as opposed to 968 methods like [12] that grow them gradually. 970 On a mobile node that moves fast, the per-movement signaling is 971 reduced by 33%. 973 Latency on the initial run is not affected, but on the subsequent 974 movements there's a significant impact. This is because the home 975 address test is eliminated. The exact effect depends on network 976 topology, but if the home agent is far away and the correspondent 977 node is on the same link, latency is almost completely eliminated. 979 Additional latency and signaling improvements could be achieved 980 through mechanisms that optimize the care-of address tests in some 981 way. This is outside the scope of this document, however. 983 8. IANA Considerations 985 This document defines a new CGA Message Type name space for use as 986 type tags in messages that may be signed using CGA signatures. The 987 values in this name space are 128-bit unsigned integers. Values in 988 this name space are allocated on a First Come First Served basis [2]. 989 IANA assigns new 128-bit values directly without a review. 991 CGA Message Type values for private use MAY be generated with a 992 strong random-number generator without IANA allocation. 994 This document defines a new 128-bit value under the CGA Message Type 995 [11] namespace, 0x5F27 0586 8D6C 4C56 A246 9EBB 9B2A 2E13. 997 This document defines a set of new mobility options, which must be 998 assigned Option Type values within the mobility option numbering 999 space of [6]. This document also allocates a new Status code value. 1001 Normative References 1003 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1004 Levels", BCP 14, RFC 2119, March 1997. 1006 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1007 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1009 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 1010 IP Version 6 (IPv6)", RFC 2461, December 1998. 1012 [4] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 1013 Public Key Infrastructure Certificate and Certificate Revocation 1014 List (CRL) Profile", RFC 3280, April 2002. 1016 [5] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 1017 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 1018 3447, February 2003. 1020 [6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1021 IPv6", RFC 3775, June 2004. 1023 [7] International Telecommunications Union, "Information Technology 1024 - ASN.1 encoding rules: Specification of Basic Encoding Rules 1025 (BER), Canonical Encoding Rules (CER) and Distinguished Encoding 1026 Rules (DER)", ITU-T Recommendation X.690, July 2002. 1028 Informative References 1030 [8] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", 1031 Computer Communications Review, April 2001. 1033 [9] Nikander, P., "Denial-of-Service, Address Ownership, and Early 1034 Authentication in the IPv6 World", Proceedings of the Cambridge 1035 Security Protocols Workshop, April 2001. 1037 [10] Nikander, P., "Mobile IP version 6 Route Optimization Security 1038 Design Background", draft-ietf-mip6-ro-sec-00 (work in 1039 progress), April 2004. 1041 [11] Aura, T., "Cryptographically Generated Addresses (CGA)", 1042 draft-ietf-send-cga-04 (work in progress), December 2003. 1044 [12] Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding 1045 Lifetime Extension", 1046 draft-arkko-mipv6-binding-lifetime-extension-00 (work in 1047 progress), May 2004. 1049 [13] Dupont, F. and J. Combes, "Using IPsec between Mobile and 1050 Correspondent IPv6 Nodes", draft-dupont-mipv6-cn-ipsec-00 (work 1051 in progress), April 2004. 1053 [14] Haddad, W. and S. Krishnan, "Optimizing Mobile IPv6 (OMIPv6)", 1054 draft-haddad-mipv6-omipv6-01 (work in progress), February 2004. 1056 [15] Haddad, W., "Applying Cryptographically Generated Addresses to 1057 BUB (BUB+)", draft-haddad-mip6-cga-bub-00 (work in progress), 1058 May 2004. 1060 [16] Haddad, W., "BUB: Binding Update Backhauling", 1061 draft-haddad-mipv6-bub-01 (work in progress), February 2004. 1063 [17] Roe, M., "Authentication of Mobile IPv6 Binding Updates and 1064 Acknowledgments", draft-roe-mobileip-updateauth-02 (work in 1065 progress), March 2002. 1067 [18] Vogt, C., Bless, R., Doll, M. and T. Kuefner, "Early Binding 1068 Updates for Mobile IPv6", 1069 draft-vogt-mip6-early-binding-updates-00 (work in progress), 1070 February 2004. 1072 [19] Vogt, C., Arkko, J., Bless, R., Doll, M. and T. Kuefner, 1073 "Credit-Based Authorization for Mobile IPv6 Early Binding 1074 Updates", draft-vogt-mipv6-credit-based-authorization-00 (work 1075 in progress), May 2004. 1077 [20] Perkins, C., "Preconfigured Binding Management Keys for Mobile 1078 IPv6", draft-ietf-mip6-precfgKbm-00 (work in progress), April 1079 2004. 1081 Authors' Addresses 1083 Wassim Haddad 1084 Ericsson Research 1085 8400, Decarie Blvd 1086 Town of Mount Royal 1087 Quebec H4P 2N2, Canada 1089 EMail: wassim.haddad@ericsson.com 1090 Lila Madour 1091 Ericsson Research 1092 8400, Decarie Blvd 1093 Town of Mount Royal 1094 Quebec H4P 2N2, Canada 1096 EMail: lila.madour@ericsson.com 1098 Jari Arkko 1099 Ericsson Research 1101 FI-02420 Jorvas 1102 Finland 1104 EMail: jari.arkko@ericsson.com 1106 Francis Dupont 1107 GET/ENST Bretagne 1108 Campus de Rennes 2, rue de la Chataigneraie 1109 CS 17607 1110 35576 Cesson-Sevigne Cedex 1111 France 1113 EMail: Francis.Dupont@enst-bretagne.fr 1115 Appendix A. Acknowledgments 1117 The authors would like to thank Tuomas Aura, Greg O'Shea, Mike Roe, 1118 and Gabriel Montenegro for interesting discussions around CGA. The 1119 authors would also like to acknowledge that [17] pioneered the work 1120 in the use of CGA for Mobile IPv6. Finally, we would like to thank 1121 Marcelo Bagnulo, Suresh Krishnan and Mohan Parthasarathy for their 1122 review and comments on this document. 1124 Intellectual Property Statement 1126 The IETF takes no position regarding the validity or scope of any 1127 Intellectual Property Rights or other rights that might be claimed to 1128 pertain to the implementation or use of the technology described in 1129 this document or the extent to which any license under such rights 1130 might or might not be available; nor does it represent that it has 1131 made any independent effort to identify any such rights. Information 1132 on the IETF's procedures with respect to rights in IETF Documents can 1133 be found in BCP 78 and BCP 79. 1135 Copies of IPR disclosures made to the IETF Secretariat and any 1136 assurances of licenses to be made available, or the result of an 1137 attempt made to obtain a general license or permission for the use of 1138 such proprietary rights by implementers or users of this 1139 specification can be obtained from the IETF on-line IPR repository at 1140 http://www.ietf.org/ipr. 1142 The IETF invites any interested party to bring to its attention any 1143 copyrights, patents or patent applications, or other proprietary 1144 rights that may cover technology that may be required to implement 1145 this standard. Please address the information to the IETF at 1146 ietf-ipr@ietf.org. 1148 The IETF has been notified of intellectual property rights claimed in 1149 regard to some or all of the specification contained in this 1150 document. For more information consult the online list of claimed 1151 rights. 1153 Disclaimer of Validity 1155 This document and the information contained herein are provided on an 1156 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1157 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1158 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1159 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1160 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1161 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1163 Copyright Statement 1165 Copyright (C) The Internet Society (2004). This document is subject 1166 to the rights, licenses and restrictions contained in BCP 78, and 1167 except as set forth therein, the authors retain all their rights. 1169 Acknowledgment 1171 Funding for the RFC Editor function is currently provided by the 1172 Internet Society.