idnits 2.17.1 draft-ietf-ipsecme-ikev2-redirect-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.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 502. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 11, 2008) is 5612 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) ** Obsolete normative reference: RFC 4306 (ref. '2') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '3') (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Devarapalli 3 Internet-Draft WiChorus 4 Intended status: Standards Track K. Weniger 5 Expires: June 14, 2009 Panasonic 6 December 11, 2008 8 Re-direct Mechanism for IKEv2 9 draft-ietf-ipsecme-ikev2-redirect-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 14, 2009. 36 Abstract 38 IKEv2 is a protocol for setting up VPN tunnels from a remote location 39 to a gateway so that the VPN client can access services in the 40 network behind the gateway. Currently there is no standard mechanism 41 specified that allows an overloaded VPN gateway or a VPN gateway that 42 is being shut down for maintenance to re-direct the VPN client to 43 attach to another gateway. This document proposes a re-direct 44 mechanism for IKEv2. The proposed mechanism can also be used in 45 Mobile IPv6 to enable the home agent to re-direct the mobile node to 46 another home agent. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. IKEv2 Exchange with Redirect . . . . . . . . . . . . . . . . . 4 53 4. Use of Anycast Addresses with the Re-direct Mechanism . . . . 5 54 5. Gateway Initiated Redirect . . . . . . . . . . . . . . . . . . 6 55 6. Redirect Messages . . . . . . . . . . . . . . . . . . . . . . 7 56 6.1. REDIRECT_SUPPORTED . . . . . . . . . . . . . . . . . . . . 7 57 6.2. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6.3. REDIRECTED_FROM . . . . . . . . . . . . . . . . . . . . . 8 59 6.4. REDIRECT_ACK . . . . . . . . . . . . . . . . . . . . . . . 9 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 65 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 67 Intellectual Property and Copyright Statements . . . . . . . . . . 13 69 1. Introduction 71 IKEv2 [2] is used for setting up IPsec-based VPNs. The IP address of 72 the VPN gateway can be configured on the VPN client. But this does 73 not scale well, when the number of VPN gateways is large. Dynamic 74 discovery of VPN gateways using DNS is quite widely used too. 75 However, using DNS is not flexible when it comes to assigning a VPN 76 gateway to the VPN client based on the load on the VPN gateways. The 77 VPN client typically tries to connect to the IP address of the VPN 78 gateways that appears first in the DNS response. If the VPN tunnel 79 setup fails, then the VPN client tries to attach to the other VPN 80 gateways returned in the DNS response. 82 This document proposes a re-direct mechanism for IKEv2 that enables a 83 VPN gateway to re-direct the VPN client to another VPN gateway, for 84 example, based on the load condition. The re-direct is done during 85 the IKE_SA_INIT exchange. The re-direct mechanism can also be used 86 in conjunction with anycast addresses. In this case, anycast address 87 for the cluster of VPN gateways is stored in the DNS instead of a 88 list of unicast IP addresses of the VPN gateways. 90 The re-direct can also happen because of administrative or optimal 91 routing reasons. This document does not attempt to provide an 92 exhaustive list of reasons for re-directing a VPN client to another 93 VPN gateway. 95 Mobile IPv6 [3] may use IKEv2 for mutual authentication between the 96 mobile node and the home agent. IKEv2 may also be used for home 97 address configuration and setting up IPsec security associations for 98 protecting Mobile IPv6 signaling messages [4]. The IKEv2 exchange 99 precedes the exchange of Mobile IPv6 signaling messages. Therefore 100 the mechanism described in this document can be also be used by a 101 Mobile IPv6 home agent to re-direct a mobile node to another home 102 agent. 104 There is a Home Agent Switch mechanism available for re-directing a 105 mobile node to another home agent, described in [5]. The Home Agent 106 Switch mechanism can only be used after the binding cache had been 107 created at the home agent for the mobile node. The disadvantage with 108 this is that quite a bit of state is created on the home agent before 109 the mobile node can be re-directed to another home agent. The 110 mechanism described in this document can be used for re-directing a 111 mobile node before any state related to the Mobile IPv6 binding is 112 created on the home agent. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [1]. 120 3. IKEv2 Exchange with Redirect 122 To redirect an IKEv2 session to another VPN gateway, the VPN gateway 123 that initially received the IKE_SA_INIT request selects another VPN 124 gateway and responds to the VPN client with a REDIRECT Notification 125 payload. The mechanism by which the initial VPN gateway selects 126 another VPN gateway is out of scope for this document. The IP 127 address of the selected VPN gateway is sent in the REDIRECT payload. 129 The VPN client indicates support for the IKEv2 redirect mechanism by 130 including a REDIRECT_SUPPORTED notification message in the initial 131 IKE_SA_INIT request. If the IKE_SA_INIT request did not include the 132 REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT 133 payload to the VPN client. 135 Initiator Responder (initial VPN GW) 136 --------- ------------------------- 138 (IP_I:500 -> Initial_IP_R:500) 139 HDR(A,0), SAi1, KEi, Ni, --> 140 N(REDIRECT_SUPPORTED) 142 (Initial_IP_R:500 -> IP_I:500) 143 <-- HDR(A,0), N(REDIRECT, IP_R) 145 When the VPN client receives the IKE_SA_INIT response with the 146 REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the 147 VPN gateway listed in the REDIRECT payload. The VPN client includes 148 the IP address of the original VPN gateway that re-directed the 149 client. The IKEv2 exchange then proceeds as normal with the selected 150 VPN gateway. 152 Initiator Responder (Selected VPN GW) 153 --------- --------------------------- 155 (IP_I:500 -> IP_R:500) 156 HDR(A,0), SAi1, KEi, Ni, --> 157 N(REDIRECTED_FROM, Initial_IP_R) 159 (IP_R:500 -> IP_I:500) 160 <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ] 162 (IP_I:500 -> IP_R:500) 163 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] 164 [IDr,]AUTH, SAi2, TSi, TSr} --> 166 (IP_R:500 -> IP_I:500) 167 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 168 SAr2, TSi, TSr} 170 When this mechanism is used with Mobile IPv6, a mobile node's 171 security associations with its home agent may expire while it still 172 has a valid binding cache entry at the home agent. In this case, the 173 mobile node MUST NOT use the original home agent address as the 174 destination address in the IKE_SA_INIT exchange to setup new security 175 associations. It MUST try to setup security associations with its 176 existing home agent. 178 4. Use of Anycast Addresses with the Re-direct Mechanism 180 The use of anycast addresses will avoid having to configure a 181 particular VPN gateway's IP address in the DNS. Instead, the anycast 182 address that represents the group of VPN gateways is stored in the 183 DNS. When the VPN client performs a DNS lookup for the VPN gateway, 184 it receives the anycast address of the VPN gateway in the DNS 185 response. 187 If an anycast address is returned in response to DNS resolution of an 188 FQDN, the IKEv2 transaction between the VPN client and the VPN 189 gateway is slightly modified. The VPN client sends the IKE_SA_INIT 190 request to the anycast address. The IKE_SA_INIT request is routed to 191 one of the VPN gateways that is part of the anycast group. The VPN 192 gateway that receives the IKE_SA_INIT request responds with an 193 IKE_SA_INIT reply from the anycast address. 195 Initiator Responder (any VPN GW) 196 --------- ------------------------- 198 (IP_I:500 -> ANYCAST:500) 199 HDR(A,0), SAi1, KEi, Ni) --> 200 N(REDIRECT_SUPPORTED) 202 (ANYCAST:500 -> IP_I:500) 203 <-- HDR(A,0), N(REDIRECT, IP_R) 205 If the destination address on the IKE_SA_INIT request is an anycast 206 address, the VPN gateway that received the IKE_SA_INIT request MUST 207 include the REDIRECT payload to re-direct the VPN client to a unicast 208 address of one of the VPN gateway. The VPN gateway that received the 209 IKE_SA_INIT request MAY re-direct the client to its own unicast 210 address, if it is not overloaded. 212 The rest of the IKEv2 exchange is the same as described in Section 3. 214 5. Gateway Initiated Redirect 216 The re-direct mechanism may also be used by a VPN gateway to re- 217 direct the client to another VPN gateway in middle of a session. To 218 re-direct a client, the gateway should send an INFORMATIONAL message 219 with the REDIRECT Notify payload. The REDIRECT payload MUST carry 220 information about the new VPN gateway. When the client receives this 221 message, it MUST send an INFORMATIONAL message with the REDIRECT_ACK 222 Notify payload. Until the client responds with an INFORMATIONAL 223 message with the REDIRECT_ACK payload, the gateway SHOULD re-transmit 224 the re-direct INFORMATIONAL message as described in [2]. The 225 following illustrates the INFORMATIONAL message exchange for gateway- 226 initiated redirect. 228 Initiator (VPN client) Responder (VPN GW) 229 ---------------------- ------------------ 231 <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} 233 HDR, SK {N[REDIRECT_ACK]} --> 235 The INFORMATIONAL message exchange described above is protected by 236 the existing IKEv2 SA between the client and the gateway. 238 Once the client responds to the gateway with the REDIRECT_ACK 239 payload, it SHOULD delete the existing security associations with the 240 old gateway. The gateway MAY also decide to delete the security 241 associations without any signaling from the client. However, it 242 should allow sufficient time for the client to setup the required 243 security associations with the new security gateway. This time 244 period should be configurable on the gateway. 246 6. Redirect Messages 248 6.1. REDIRECT_SUPPORTED 250 The REDIRECT_SUPPORTED payload is included in the initial IKE_SA_INIT 251 request by the initiator to indicate support for the IKEv2 re-direct 252 mechanism described in this document. 254 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Next Payload |C| RESERVED | Payload Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Protocol ID | SPI Size (=0) | Notify Message Type | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 263 the 'Notify Message Type' fields are the same as described in Section 264 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that 265 the SPI is not present in this message. 267 The 'Payload Length' field MUST be set to '8'. The 'Notify Message 268 Type' field is set to indicate the REDIRECT_SUPPORTED payload . 271 6.2. REDIRECT 273 The REDIRECT payload is included in an IKE_SA_INIT response from the 274 responder when the responder wants to re-direct the initiator to 275 another VPN gateway. The message includes the new responder's IP 276 address. 278 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Next Payload |C| RESERVED | Payload Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Protocol ID | SPI Size (=0) | Notify Message Type | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | GW Ident Type | | 286 +---------------+ ~ 287 ~ New Responder GW Identity ~ 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 292 the 'Notify Message Type' fields are the same as described in Section 293 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that 294 the SPI is not present in this message. 296 If the IP address of the new VPN gateway is sent, the 'Payload 297 Length' field MUST be set to either '13' or '25' depending on whether 298 an IPv4 or IPv6 address is sent in the message. If the FQDN of the 299 new VPN gateway is sent, the 'Payload Length' field is set to the 300 length of the FQDN plus the fixed fields in the message. The 'Notify 301 Message Type' field is set to indicate the REDIRECT payload . The 'GW Identity Type' field indicates the 303 type of information that is sent to identify the new VPN gateway. 304 The following values are reserved by this document. 306 1 - IPv4 address of the new VPN gateway 307 2 - IPv6 address of the new VPN gateway 308 3 - FQDN of the new VPN gateway 310 All other values for this field are reserved and MUST NOT be used. 311 The identity of the new VPN gateway is carried in the 'New Responder 312 GW Identity' field. 314 6.3. REDIRECTED_FROM 316 The REDIRECTED_FROM message type is included in the IKE_SA_INIT 317 request from the initiator to the new VPN gateway to indicate the IP 318 address of the original VPN gateway that re-directed the initiator. 319 The original VPN gateway's IP address is included in the message. 321 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Next Payload |C| RESERVED | Payload Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Protocol ID | SPI Size (=0) | Notify Message Type | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | GW Ident Type | | 329 +---------------+ ~ 330 ~ Original Responder GW Identity ~ 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 335 the 'Notify Message Type' fields are the same as described in Section 336 3.10 of [2] The 'SPI Size' field MUST be set to 0 to indicate that 337 the SPI is not present in this message. 339 The 'Payload Length' field MUST be set to either '13' or '25' 340 depending on whether an IPv4 or IPv6 address of the original VPN 341 gateway is sent in the message. The 'Notify Message Type' field is 342 set to indicate the REDIRECTED_FROM payload . The 'GW Identity Type' field indicates the type of 344 information that is sent to identify the new VPN gateway. The 345 following values are reserved by this document. 347 1 - IPv4 address of the original VPN gateway 348 2 - IPv6 address of the original VPN gateway 350 All other values for this field are reserved and MUST NOT be used. 351 The identity of the original VPN gateway is carried in the 'Original 352 Responder GW Identity' field. 354 6.4. REDIRECT_ACK 356 The REDIRECT_ACK payload is included in the INFORMATIONAL message 357 sent by the VPN client to the gateway in response to a gateway 358 initiated redirect message as described in Section 5. 360 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Next Payload |C| RESERVED | Payload Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Protocol ID | SPI Size (=0) | Notify Message Type | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 369 the 'Notify Message Type' fields are the same as described in Section 370 3.10 of [2]. The 'SPI Size' field MUST be set to 0 to indicate that 371 the SPI is not present in this message. 373 The 'Payload Length' field MUST be set to '8'. The 'Notify Message 374 Type' field is set to indicate the REDIRECT_ACK payload . 377 7. Security Considerations 379 An eavesdropper on the path between VPN client and server may send a 380 redirect to the client upon receiving an IKE_SA_INIT message from 381 this client. This is no problem regarding DoS attacks for the VPN 382 connection, since an on-path-attacker can as well drop the 383 IKE_SA_INIT requests to prevent VPN access for the client. But an 384 eavesdropper on the path between VPN client and server can redirect a 385 large number of clients to a victim, which is then flooded with 386 IKE_SA_INIT requests. Flooding only happens if many clients initiate 387 IKEv2 exchange at almost the same time, which is considered a rare 388 event. However, this may happen if a Home Agent/VPN server is 389 shutdown for maintenance and all clients need to re-establish VPN 390 connections with another Home Agent/VPN server or if the on-path 391 attacker forces all IPsec security associations to expire by dropping 392 all received IKEv2 messages. 394 The use of REDIRECTED_FROM payload is intended to discourage a rogue 395 VPN gateway from re-directing a large number of VPN clients to a 396 particular VPN gateway. It does not prevent such a DoS attack. 398 8. IANA Considerations 400 This document defines four new IKEv2 Notification Message types as 401 described in Section 6. The four Notify Message Types must be 402 assigned values between 16396 and 40959. 404 o REDIRECT_SUPPORTED 405 o REDIRECT 406 o REDIRECTED_FROM 407 o REDIRECT_ACK 409 9. Acknowledgements 411 The use of anycast address with IKEv2 was first described in [6]. It 412 was then added to an early draft version of RFC 5026 and later 413 removed before the RFC was published. Therefore the authors of [6] 414 and RFC 5026 are acknowledged. 416 Thanks to Pasi Eronen, with whom the solution described in this 417 document was extensively discussed. Thanks to Tero Kivinen for 418 suggesting the use of REDIRECTED_FROM payload. The authors would 419 also like to thank Yaron Sheffer, Sunil Kumar, Fan Zhao, Yoav Nir and 420 Arnaud Ebalard for their reviews and comments. 422 10. References 424 10.1. Normative References 426 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 427 Levels", BCP 14, RFC 2119, March 1997. 429 [2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, 430 December 2005. 432 10.2. Informative References 434 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 435 IPv6", RFC 3775, June 2004. 437 [4] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 438 Bootstrapping in Split Scenario", RFC 5026, October 2007. 440 [5] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility 441 Header Home Agent Switch Message", RFC 5142, January 2008. 443 [6] Weniger, K. and F. Dupont, "IKEv2-based Home Agent Assignment in 444 Mobile IPv6/NEMO Bootstrapping", draft-dupont-ikev2-haassign-02 445 (work in progress), January 2007. 447 Authors' Addresses 449 Vijay Devarapalli 450 WiChorus 451 3590 North First St 452 San Jose, CA 95134 453 USA 455 Email: vijay@wichorus.com 456 Killian Weniger 457 Panasonic R&D Center Germany 458 Monzastr. 4c 459 Langen 63225 460 Germany 462 Email: kilian.weniger@eu.panasonic.com 464 Full Copyright Statement 466 Copyright (C) The IETF Trust (2008). 468 This document is subject to the rights, licenses and restrictions 469 contained in BCP 78, and except as set forth therein, the authors 470 retain all their rights. 472 This document and the information contained herein are provided on an 473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 475 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 476 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 477 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 Intellectual Property 482 The IETF takes no position regarding the validity or scope of any 483 Intellectual Property Rights or other rights that might be claimed to 484 pertain to the implementation or use of the technology described in 485 this document or the extent to which any license under such rights 486 might or might not be available; nor does it represent that it has 487 made any independent effort to identify any such rights. Information 488 on the procedures with respect to rights in RFC documents can be 489 found in BCP 78 and BCP 79. 491 Copies of IPR disclosures made to the IETF Secretariat and any 492 assurances of licenses to be made available, or the result of an 493 attempt made to obtain a general license or permission for the use of 494 such proprietary rights by implementers or users of this 495 specification can be obtained from the IETF on-line IPR repository at 496 http://www.ietf.org/ipr. 498 The IETF invites any interested party to bring to its attention any 499 copyrights, patents or patent applications, or other proprietary 500 rights that may cover technology that may be required to implement 501 this standard. Please address the information to the IETF at 502 ietf-ipr@ietf.org.