idnits 2.17.1 draft-kempf-mipshop-handover-key-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 504. ** 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 == Line 21 has weird spacing: '... other grou...' == Line 25 has weird spacing: '... months and ...' == Line 151 has weird spacing: '... key corre...' == Line 161 has weird spacing: '...utilize the ...' == Line 186 has weird spacing: '... select an a...' == (16 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4068 (ref. 'FMIP') (Obsoleted by RFC 5268) ** Downref: Normative reference to an Informational RFC: RFC 3756 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 James Kempf 3 Internet Draft DoCoMo Labs USA 4 Document: draft-kempf-mipshop-handover-key-00.txt Rajeev Koodli 5 Nokia Research 6 Center 7 Expires: November, 2006 June, 2006 9 Distributing a Symmetric FMIPv6 Handover Key using SEND 10 (draft-kempf-mipshop-handover-key-00.txt) 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Fast Mobile IPv6 requires that a Fast Binding Update is secured 39 using a security association shared between an Access Router and a 40 Mobile Node in order to avoid certain attacks. In this document, a 41 method for distributing a shared key to secure this signaling is 42 defined. The method utilizes the RSA public key that the Mobile 43 Node used to generate its Cryptographically Generated Address in 44 SEND. The RSA public key is used to encrypt a shared key sent from 45 the Access Router to the Mobile Node prior to handover. The 46 ability of the Mobile Node to decrypt the shared key verifies its 47 possession of the private key corresponding to the CGA public key 48 used to generate the address. This allows the Mobile Node to use 49 the shared key to sign and authorize the routing changes triggered 50 by the Fast Binding Update. 52 Table of Contents 53 1.0 Introduction.............................................2 54 2.0 Brief Review of SEND.....................................3 55 3.0 Handover Key Provisioning and Use........................3 56 4.0 Message Formats..........................................6 57 5.0 Security Considerations..................................8 58 6.0 IANA Considerations......................................9 59 7.0 Normative References.....................................9 60 8.0 Informative References...................................9 61 9.0 Author Information.......................................9 62 10.0 IPR Statements..........................................10 63 11.0 Disclaimer of Validity..................................10 64 12.0 Copyright Statement.....................................10 65 13.0 Acknowledgment..........................................10 67 1.0 Introduction 69 In Fast Mobile IPv6 (FMIPv6) [FMIP], a Fast Binding Update (FBU) 70 is sent from a Mobile Node (MN), undergoing IP handover, to the 71 previous Access Router (AR). The FBU causes a routing change so 72 traffic sent to the MN's previous care-of address on the previous 73 AR is tunneled to the new care-of address on the new AR. The 74 previous AR requires that only an authorized MN be able to change 75 the routing for the old care-of address. If such authorization is 76 not established, an attacker can redirect a victim MN's traffic at 77 will. 79 In this document, a lightweight mechanism is defined by which a 80 key for securing FMIP can be provisioned on the MN. The mechanism 81 utilizes the RSA public key with which the MN generates a care-of 82 Cryptographically Generated Address (CGA) in the SEND protocol 83 [SEND] to encrypt a shared handover key between the MN and the 84 AR". The shared handover key itself is established between the AR 85 and the MN at some arbitrary time prior to handover. In SEND, the 86 CGA public key is used to authorize possession of an address, and, 87 thereby, to perform operations associated with the address. The 88 connection between the address and the CGA public/private key pair 89 is called the key pair's CGA property. The shared handover key 90 derives its authorization potential from the ability of the MN to 91 decrypt the handover key using the CGA private key [CGA]. The 92 timing of the handover key provisioning is independent of the 93 handover timing, thus eliminating any potential additional latency 94 in handover. 96 Handover keys are an instantiation of the purpose built key 97 architectural principle [PBK]. 99 1.1 Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 102 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 RFC 2119 [RFC2119]. 106 In addition, the following terminology is used: 108 CGA key Public key used to generate the CGA according to RFC 3972 109 [CGA]. 111 2.0 Brief Review of SEND 113 SEND protects against a variety of threats to local link address 114 resolution (also known as Neighbor Discovery) and last hop router 115 (AR) discovery in IPv6 [RFC3756]. These threats are not exclusive 116 to wireless networks, but they generally are easier to mount on 117 certain wireless networks because the link between the access 118 point and MN can't be physically secured. 120 SEND utilizes CGAs in order to secure Neighbor Discovery signaling 121 [CGA]. Briefly, a CGA is formed by hashing together the IPv6 122 subnet prefix for a node's subnet, a random nonce, and an RSA 123 public key, and the CGA key. The CGA key is used to sign a 124 Neighbor Advertisement (NA) message sent to resolve the link layer 125 address to the IPv6 address. The combination of the CGA and the 126 signature on the NA proves to a receiving node the sender's 127 authorization to claim the address. The node may opportunistically 128 generate one or several keys specifically for SEND, or it may use 129 a certified key that it distributes more widely. 131 3.0 Handover Key Provisioning and Use 133 3.1 Mobile Node Considerations 135 At some time prior to handover, the MN MUST send an IPv6 Router 136 Solicitation (RS) [RFC2461] exactly as specified for IPv6 Router 137 Discovery. A CGA for the MN MUST be the source address on the 138 packet, and the MN MUST include the SEND CGA Option and SEND 139 Signature Option with the packet, as specified in [SEND]. The MN 140 indicates that it wants to receive a shared handover key by 141 setting the handover authentication Algorithm Type (AT) extension 142 field in the CGA Option (described in Section 4.2) to the MN's 143 preferred authentication algorithm. 145 Receiving routers that are enabled to perform FMIPv6 with SEND 146 handover key distribution reply directly to the CGA with a Router 147 Advertisement (RA) including a Handover Key Option as described in 148 the next section, containing the encrypted, shared handover key 149 and the authentication algorithm type. The MN SHOULD choose an AR 150 from the returned RAs, decrypt the handover key using the private 151 key corresponding to the CGA key, and store the associated 152 handover key for later use along with the algorithm type. If more 153 than one router responds to the RS, the MN MAY keep track of all 154 such keys. The MN MUST use the returned algorithm type provided by 155 the ARs. The MN MUST index the handover keys with the AR's IPv6 156 address, to which the MN later sends the FBU, and the CGA. This 157 allows the MN to select the proper key when communicating with a 158 previous AR. 160 When the MN needs to signal the previous AR using an FMIPv6 FBU, 161 the MN MUST utilize the handover key and the corresponding 162 authentication algorithm to generate an appropriate authenticator 163 for the message. The MN MUST select the appropriate key for the AR 164 using the AR's destination address and the care-of CGA. The MN 165 MUST generate the MAC using the handover key and include it in the 166 FBU message as defined by the FMIPv6 spec using the appropriate 167 algorithm. As specified by FMIPv6 [FMIP], the MN MUST include the 168 care-of CGA in a Home Address Option. 170 3.2 Access Router Considerations 172 When an FMIPv6 capable AR with SEND receives an RS from a MN 173 including a SEND CGA Option with the AT field set and a Signature 174 Option, and the source address is a CGA, the AR MUST verify the 175 signature and CGA as described in [SEND]. If the signature and CGA 176 verify, the AR MUST then determine whether the CGA key already has 177 an associated shared handover key. If the CGA key has an existing 178 handover key, the AR MUST return the existing handover key to the 179 MN. If the CGA key does not have a shared handover key, the AR 180 MUST construct a shared handover key as described in Section 3.3. 181 The AR MUST encrypt the handover key with the MN's CGA key. The AR 182 MUST insert the encrypted handover key into a Handover Key Option 183 (described in Section 4.1) and MUST attach the Handover Key Option 184 to the RA. The AR SHOULD set the AT field of the Handover Key 185 Option to the MN's preferred field if it is supported; otherwise, 186 the AR MUST select an authentication algorithm which is of 187 equivalent strength and set the field to that. The RA is then 188 unicast back to the MN with the CGA as the destination address. 189 The handover key MUST be stored by the AR for future use, indexed 190 by the CGA key and the CGA, and the authentication algorithm type 191 recorded with the key. 193 If either the CGA or the signature do not verify, the AR MUST NOT 194 include a Handover Key Option in the reply. The AR also MUST NOT 195 change any existing key record for the address, since the message 196 may be an attempt by an attacker to disrupt communications for a 197 legitimate MN. 199 When the AR receives an FBU message containing appropriate 200 authorization, the AR MUST find the corresponding handover key 201 using the care-of CGA in the Home Address Option as the index. If 202 a handover key is found, the AR MUST utilize the handover key and 203 the appropriate algorithm to verify the MAC in the Binding 204 Authorization Option according to the procedure described in the 205 FMIPv6 specification. 207 3.3 Key Generation and Lifetime 208 The AR MUST randomly generate a key having sufficient strength to 209 match the authentication algorithm. The actual size of the key 210 depends on the authentication algorithm, but should be 211 sufficiently large to mitigate birthday attacks. Some 212 authentication algorithms may specify a required key size. The AR 213 MUST generate a unique key for each CGA key, and SHOULD take care 214 that the key generation is uncorrelated between keys. 216 The handover key lifetime depends on the lifetime of the CGA key 217 [CGA], which, in turn, is determined by the lifetime of the 218 addresses generated using the CGA key. The CGA key and handover 219 key SHOULD be renewed by the MN when the preferred lifetime of the 220 last address generated with the CGA key expires and MUST be 221 discarded if the valid lifetime of the last address generated with 222 the key expires [RFC2462]. The handover key is renewed by sending 223 a SEND-secured RS as described in Section 3.1 for one of the CGAs 224 associated with the handover key. 226 Unless the MN renews the handover key with another RS, the AR MUST 227 discard the handover key when the valid lifetime of the last CGA 228 to be generated with the key expires. Note that CGAs generated 229 with the CGA key for which there is an associated handover key may 230 expire prior to the expiration of the key, if the MN does not 231 renew the CGAs prior to the expiration of the CGAs' valid 232 lifetime. 234 The AR SHOULD NOT discard the handover key immediately after use 235 if it is still valid. It is possible that the MN may undergo rapid 236 movement to another AR prior to the completion of Mobile IPv6 237 binding update on the new AR, and the MN MAY as a consequence 238 initialize another, subsequent handover optimization to move 239 traffic from the previous AR to another new AR. In that case, 240 keeping the key active until the expiration of the address ensures 241 that the MN can continue to use the handover key for FMIP 242 signaling purposes if necessary. 244 If the MN returns to a previous AR prior to the expiration of the 245 handover key, the MN MAY receive the same handover key as was 246 previously returned, if the MN uses the same CGA key for address 247 generation and the previous care-of CGA has not yet expired. 248 However, the MN MUST NOT assume that it can continue to use the 249 old key without actually receiving the handover key again from the 250 router in an RA, regardless of how much time is left on the valid 251 lifetime of the care-of CGAs. 253 3.4 Signaling Optimization 255 As described here, the signaling for handover key provisioning may 256 require an additional RS-RA exchange beyond that used for basic IP 257 level movement detection [DNA]. This is because a host performing 258 router discovery typically includes a link local IPv6 address as 259 the source address for the RS sent to perform movement detection, 260 and not a global IPv6 address. The care-of address, however, is a 261 global address. Since a MN may not have the collection of prefixes 262 on the subnet when it sends the RS, it may not be able to generate 263 a global IPv6 address until the RA returns with the prefixes 264 supported on the link. While it is possible that the MN may have 265 another source of information about prefixes supported on the link 266 (for example, from a Proxy Router Advertisement [FMIP]), the usual 267 case is that the MN learns these prefixes as part of the initial 268 RS-RA exchange used to perform movement detection. If that is the 269 case, the MN must later perform another RS-RA exchange with the 270 MN's global care-of address as the source address of the RS, and 271 destination address of the returned RA, in order to obtain a 272 handover key tied to the CGA. 274 One possible way to eliminate the need for an additional RS-RA 275 exchange is to tie the handover key on the MN to both the link 276 local IPv6 address and the global IPv6 care-of addresses. However, 277 if this is done, the same CGA key MUST be used for both the link 278 local IPv6 address and the global IPv6 care-of addresses. If the 279 MN requires multiple global IPv6 addresses, it MUST either utilize 280 different subnet prefixes for the different global addresses or 281 use a different 16 octet modifier for the CGA calculation. Note 282 that this optimization does not affect the ability of the MN to 283 generate privacy care-of addresses [RFC3041], since the MN can 284 utilize a different 16 octet modifier for each address. 286 4.0 Message Formats 288 4.1 Handover Key Option 290 The Handover Key Option is a standard IPv6 Neighbor Discovery 291 option in TLV format. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length | Key Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Encrypted Handover Key . . . 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Fields: 303 Type: To be assigned by IANA. 305 Length: The length of the option in units of 8 octets, 306 including the Type and Length fields. 308 Key Length: Length of the encrypted handover key, in units of 309 octets. 311 Encrypted Handover Key: 313 The encrypted handover key. 315 The option is padded to an 8 octet boundary, as required for IPv6 316 Neighbor Discovery Protocol options. 318 4.2 Handover Authentication Algorithm Type Field 320 Handover keys extend the SEND CGA Option to include an Algorithm 321 Type (AT) field. This allows the MN to ask for and the AR to 322 acknowledge a particular algorithm for FBU authentication. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length | Pad Length | AT | Resrvd| 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 . . 331 . CGA Parameters . 332 . . 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 . . 337 . Padding . 338 . . 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Fields: 344 Type: 11 346 Length: The length of the option, including the Type and 347 Length fields, in units of 8 octets. 349 Pad Length: The number of padding octets beyond the end of the 350 CGA Parameters field but within the length 351 specified by the Length field. Padding octets MUST 352 be set to zero by senders and ignored by 353 receivers. 355 AT: A 4-bit algorithm type field describing the 356 algorithm used by FMIPv6 to calculate the 357 authenticator. See [FMIP] for details. 359 Reserved: A 4-bit field reserved for future use. The value 360 MUST be initialized to zero by the sender and MUST 361 be ignored by the receiver. 363 CGA Parameters: 365 A variable-length field containing the CGA 366 Parameters data structure described in Section 4 367 of [CGA]. This specification requires that if both 368 the CGA option and the RSA Signature option are 369 present, then the public key found from the CGA 370 Parameters field in the CGA option MUST be that 371 referred by the Key Hash field in the RSA 372 Signature option. Packets received with two 373 different keys MUST be silently discarded. Note 374 that a future extension may provide a mechanism 375 allowing the owner of an address and the signer to 376 be different parties. 378 Padding: A variable-length field making the option length a 379 multiple of 8, containing as many octets as 380 specified in the Pad Length field. 382 5.0 Security Considerations 384 This document describes a key distribution protocol for the FMIPv6 385 handover optimization protocol. The key distribution protocol 386 utilizes the CGA key of SEND to bootstrap a shared key for 387 authorizing changes due to handover associated with the MN's 388 former address on the wireless interface of the AR. General 389 security considerations involving CGAs apply to the protocol 390 described in this document, see [CGA] for a discussion of security 391 considerations around CGAs. 393 The shared handover key is indexed by the CGA key on the AR. 394 Multiple addresses can be generated using the same CGA key, and 395 handover for these addresses is authorized by the same handover 396 key. If the handover key corresponding to the CGA key used to 397 generate the addresses is compromised, handover authorization for 398 all addresses generated using the CGA key is also compromised. 399 This is similar to the case when the private key corresponding to 400 the public key used to generate the CGAs is compromised, resulting 401 in SEND security for the CGAs being compromised. These risks can 402 be mitigated by using different CGA keys to generate different 403 addresses, at the expense of additional signaling to establish the 404 handover keys. 406 The protocol described in this document coupled with the FBU 407 authorization protocol described in [FMIP] provides protection 408 against redirection of traffic on the previous AR by nodes that 409 are not authorized to claim the previous care-of CGA. This 410 includes nodes having authorized care-of CGAs on the previous AR's 411 wireless link that attempt to redirect traffic for addresses for 412 which they are not authorized. However, this protocol does not 413 protect against redirection attacks against nodes on the new AR's 414 link. In such an attack, the MN sends an FBU to the previous AR 415 with its previous care-of CGA in the Home Address Option, but the 416 address for another node as the new care-of address. The victim on 417 the new link is them bombarded with the MN's traffic. The FMIPv6 418 specification [FMIP] includes a few recommendations about how to 419 mitigate redirection attacks of this sort. 421 6.0 IANA Considerations 423 A new IPv6 Neighbor Discovery option, the Handover Key Option, is 424 defined, and requires a IPv6 Neighbor Discovery option type code 425 from IANA. 427 7.0 Normative References 429 [FMIP] Koodli, R., editor, "Fast Handovers for Mobile IPv6", RFC 430 4068, July 2005. 432 [SEND] Arkko, J., editor, Kempf, J., Zill, B., and Nikander, P., 433 "SEcure Neighbor Discovery (SEND)", RFC 2971, March 2005. 435 [CGA] Aura, T., "Cryptographically Generated Addresses", RFC 3972, 436 March 2005. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", RFC 2119, March 1997. 441 [RFC3756] Nikander, P., editor, Kempf, J., and Nordmark, E., " 442 IPv6 Neighbor Discovery (ND) Trust Models and Threats", 443 RFC 3756, May 2004. 445 [RFC2461] Narten, T., and Nordmark, E., "Neighbor Discovery for IP 446 version 6 (IPv6)", RFC 2461, December 1998. 448 [RFC2462] Thomas, S., and Narten, T., "IPv6 Stateless Address 449 Autoconfiguration", RFC 2462, December 1998. 451 [RFC3041] Narten, T., and Draves, R., "Privacy Extensions for 452 Stateless Address Autoconfiguration in IPv6", RFC 3041, 453 January 2001. 455 8.0 Informative References 457 [DNA] Kempf, J., Narayanan, S., Nordmark, E., Pentland, B., and 458 Choi, JH., "Detecting Network Attachment in IPv6 Networks 459 (DNAv6)", Internet Draft, work in progress. 461 [PBK] Bradner, S., Mankin, A., and Schiller, J., "A Framework for 462 Purpose-Built Keys (PBK)", Internet Draft, work in 463 progress. 465 9.0 Author Information 467 James Kempf Phone: +1 408 451 4711 468 DoCoMo Labs USA Email: kempf@docomolabs-usa.com 469 181 Metro Drive 470 Suite 300 471 San Jose, CA 472 95110 473 USA 475 Rajeev Koodli Phone: +1 650 625 2359 476 Nokia Research Center Fax: +1 650 625 2502 477 313 Fairchild Drive Email: Rajeev.Koodli@nokia.com 478 Mountain View, CA 479 94043 480 USA 482 10.0 IPR Statements 484 The IETF takes no position regarding the validity or scope of any 485 Intellectual Property Rights or other rights that might be claimed 486 to pertain to the implementation or use of the technology described 487 in this document or the extent to which any license under such 488 rights might or might not be available; nor does it represent that 489 it has made any independent effort to identify any such rights. 490 Information on the procedures with respect to rights in RFC 491 documents can be found in BCP 78 and BCP 79. 493 Copies of IPR disclosures made to the IETF Secretariat and any 494 assurances of licenses to be made available, or the result of an 495 attempt made to obtain a general license or permission for the use 496 of such proprietary rights by implementers or users of this 497 specification can be obtained from the IETF on-line IPR repository 498 at http://www.ietf.org/ipr. 500 The IETF invites any interested party to bring to its attention any 501 copyrights, patents or patent applications, or other proprietary 502 rights that may cover technology that may be required to implement 503 this standard. Please address the information to the IETF at 504 ietf-ipr@ietf.org. 506 11.0 Disclaimer of Validity 508 This document and the information contained herein are provided on 509 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 510 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 511 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 512 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 513 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 514 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 515 PARTICULAR PURPOSE. 517 12.0 Copyright Statement 519 Copyright (C) The Internet Society (2006). This document is 520 subject to the rights, licenses and restrictions contained in BCP 521 78, and except as set forth therein, the authors retain all their 522 rights. 524 13.0 Acknowledgment 525 Funding for the RFC Editor function is currently provided by the 526 Internet Society.