idnits 2.17.00 (12 Aug 2021) /tmp/idnits14729/draft-tschofenig-mip6-bootstrapping-pana-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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 468. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 18, 2004) is 6417 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) == Missing Reference: 'AVPs' is mentioned on line 205, but not defined == Missing Reference: 'Cookie' is mentioned on line 214, but not defined == Missing Reference: 'Device-Id' is mentioned on line 230, but not defined == Missing Reference: 'Data-Protection' is mentioned on line 230, but not defined == Missing Reference: 'MAC' is mentioned on line 242, but not defined == Outdated reference: draft-ietf-pana-pana has been published as RFC 5191 == Outdated reference: draft-ietf-mip6-auth-protocol has been published as RFC 4285 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-auth-protocol (ref. 'I-D.ietf-mip6-auth-protocol') == Outdated reference: draft-ietf-mip6-bootstrap-ps has been published as RFC 4640 == Outdated reference: draft-ietf-seamoby-mobility-terminology has been published as RFC 3753 -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-pana-requirements has been published as RFC 4058 == Outdated reference: A later version (-07) exists of draft-eronen-ipsec-ikev2-eap-auth-01 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-mip4-rfc3344bis has been published as RFC 5944 == Outdated reference: draft-arkko-pppext-eap-aka has been published as RFC 4187 == Outdated reference: draft-ietf-ipsec-nat-t-ike has been published as RFC 3947 == Outdated reference: draft-blanchet-v6ops-tunnelbroker-tsp has been published as RFC 5572 Summary: 7 errors (**), 0 flaws (~~), 19 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPv6 H. Tschofenig 3 Internet-Draft S. Thiruvengadam 4 Expires: April 18, 2005 Siemens 5 October 18, 2004 7 Bootstrapping Mobile IPv6 using PANA 8 draft-tschofenig-mip6-bootstrapping-pana-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 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 months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 18, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 Recently the MIP6 working group has expressed a fair amount of 44 interest in developing another Mobile Node <--> Home Agent Binding 45 Update security solution. The currently proposed solution heavily 46 focuses on one specific authentication and key exchange protocol. 47 Obviously, this approach suffers from some limitations. This 48 document investigates the usage of an EAP based bootstrapping 49 approach using PANA. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Introduction to PANA . . . . . . . . . . . . . . . . . . . . . 6 58 3.1 PANA message flow . . . . . . . . . . . . . . . . . . . . 6 59 3.2 Relaxing PANA Assumptions . . . . . . . . . . . . . . . . 8 61 4. Bootstrapping Issues . . . . . . . . . . . . . . . . . . . . . 9 62 4.1 Home Agent Discovery . . . . . . . . . . . . . . . . . . . 9 63 4.2 Obtaingin HoA . . . . . . . . . . . . . . . . . . . . . . 9 64 4.3 MN-HA security association . . . . . . . . . . . . . . . . 9 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 72 7.2 Informative References . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 76 Intellectual Property and Copyright Statements . . . . . . . . 15 78 1. Introduction 80 Recently the MIP6 working group has expressed a fair amount of 81 interest in developing another Mobile Node <--> Home Agent Binding 82 Update security solution. The currently proposed solution 83 [I-D.ietf-mip6-auth-protocol] (referred as MIP6-Auth-Protocol) 84 heavily focuses on one specific authentication and key exchange 85 protocol. This protocol requires that the entire message exchange is 86 finished in a single roundtrip with the mobile node initiating the 87 exchange. Obviously, this approach suffers from some limitations. 88 This document investigates the usage of an Extensible Authentication 89 Protocol (EAP) [RFC3748] based approach which offers more 90 flexibility. As in other areas there is the 'one size does not fit 91 all' problem. 93 IKEv2 [I-D.ietf-ipsec-ikev2] supports the Extensible Authentication 94 Protocol. Unfortuntately, IKEv2 only creates IPsec SAs since the 95 concept of Domain of Interpretations (DoIs) was removed due to the 96 limited usage in IKEv1. The authors think that most arguments 97 against the IPsec protection of MIPv6 MN<->HA Binding Updates address 98 problems caused by IPsec rather than IKEv2. It might be worth 99 mentioning that IKEv2 is far more complex than 100 [I-D.ietf-mip6-auth-protocol] . The extension proposed by 101 [I-D.eronen-ipsec-ikev2-eap-auth], which tried to address some 102 deployment aspects in certain environments, has not been considered 103 by the IPsec working group. 105 Following the typical separation between 107 (a) Authentication and security association establishment and 109 (b) "Data" traffic protection 111 which is exercised by a number of protocols today (such as TLS, 112 IKEv1, IKEv2) it seems to be reasonable to re-use the MIPv6 113 bootstrapping procedure for the former task whereas a simple 114 integrity and replay protection mechanism is used to protect the 115 Binding Update in a fashion similar to Mobile IPv4 116 [I-D.ietf-mip4-rfc3344bis] (or also similar to a modified version of 117 the MIPv6-Auth-Protocol [I-D.ietf-mip6-auth-protocol]). Note that 118 the "data" is, in our case, the signaling traffic. 120 The MIPv6 bootstrapping problem as described in 121 [I-D.ietf-mip6-bootstrap-ps] involves bootstrapping of the following 122 parameters: 124 o MN finding HA's address 125 o MN obtaining HoA 127 o Setting an IPsec security association (SA) between the MN and the 128 HA 130 With the most recent developments in the MIP6 working group with a 131 possible usage of the bootstrapping protocol for authentication and 132 security association establishment it seems to be resonable to modify 133 the goal of the MIPv6 bootstrapping in the sense that a security 134 association has to be established between the mobile node and the 135 home agent for protection of the MN <--> HA Binding Update. 137 Protocol for Carrying Authentication for Network Access (PANA) is a 138 lightweight protocol exchanging EAP payloads over UDP. This document 139 suggests to consider the usage of PANA for bootstrapping of a 140 security association between the MN and the HA. 142 Note that this document does not aim to replace the 143 MIPv6-Auth-Protocol [I-D.ietf-mip6-auth-protocol]. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 Furthermore, we use the same terminology as in [RFC3775], 152 [I-D.ietf-seamoby-mobility-terminology], 153 [I-D.ietf-pana-requirements]. 155 3. Introduction to PANA 157 PANA is a link layer agnostic transport for Extensible Authentication 158 Protocol (EAP) to enable network access authentication between 159 clients and access networks. PANA is currently being standardised at 160 the IETF PANA working group. PANA can carry any EAP method and 161 thereby allows user authentication and the establishment of a PANA 162 security association between the PANA client (PaC) and PANA 163 authentication agent (PAA) at the end of successful protocol run. 164 The PAA indicates the results of the authentication using the 165 PANA-Bind-Answer message. 167 3.1 PANA message flow 169 The protocol has four phases, which are explained briefly below. For 170 detailed explanation and message formats, the reader should see 171 [I-D.ietf-pana-pana]. 173 Discovery phase: This is the initial handshake phase. The PaC 174 discovers the PAA in this phase. The PaC sends a multicast 175 discovery packet and the PAA responds to it with a 176 PANA-start-request (PSR) message. The PaC responds with a 177 PANA-start-answer (PSA) message. The PaC is also allowed to send 178 a unicast discovery message if it knows the PAA in advance. 180 Authentication phase: A PANA-authentication-request is sent by the 181 PAA and the PaC replies with PANA-authentication-answer. This 182 message-pair may be repeated many times according to the EAP 183 method in use. But finally PANA-bind-request message and 184 PANA-bind-answer message pairs are exchanged. The 185 PANA-bind-request would convey whether PaC is successfully 186 authenticated or not. After the exchange of this message pair, 187 the PAA would enforce the policy rules at the EP. 189 Termination phase: Either the PaC or the PAA could request 190 termination of the PANA session. The PANA-termination-request 191 message would initiate session termination and 192 PANA-termination-answer would acknowledge the teardown of session. 194 Re-authentication phase: The PaC may have to re-authenticate 195 periodically. For the reauthentication phase, the PAA sends the 196 PANA-reauthentication-request message to PaC. It is acknowledged 197 with PANA-reauthentication-answer and the PAA sends 198 PANA-start-request message to trigger the authentication phase 199 again. 201 An example message flow using the EAP-AKA [I-D.arkko-pppext-eap-aka] 202 is shown in Figure 1. The re-authentication and the termination 203 phase are optional. 205 PaC PAA Message[AVPs] 206 ----------------------------------------------------- 208 ~~~ Discovery and initial handshake phase ~~~ 210 -----> PANA-PAA-Discover 212 <----- PANA-Start-Request[Cookie] 214 -----> PANA-Start-Request-Answer[Cookie] 216 Figure 1: PANA message flow 218 ~~~ Authentication phase ~~~ 220 <----- PANA-Auth-Request 221 [EAP(EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC))] 223 -----> PANA-Auth-Answer 224 [EAP(EAP-Response/AKA-Challenge(AT_RES, AT_MAC))] 226 <----- PANA-Bind-Request // F-flag set 227 [EAP(EAP-Success), Device-Id, Data-Protection, MAC] 229 -----> PANA-Bind-Answer // F-flag set 230 [Device-Id, Data-Protection, MAC] 232 ~~~ Re-authentication ~~~ 234 <----- PANA-Reauth-Request[MAC] 236 -----> PANA-Reauth-Answer[MAC] 238 ~~~ Termination phase ~~~ 240 -----> PANA-Termination-Request[MAC] 242 <----- PANA-Termination-Answer[MAC] 244 3.2 Relaxing PANA Assumptions 246 PANA was designed with a focus on network access authentication. 247 This fact is reflected in the discovery mechanism whereby a multicast 248 address is used (see Section 8.2 of [I-D.ietf-pana-pana]) whereby it 249 is assumed that the PAA is only one IP hop away from the PaC. 251 This assumption is not applicable to this environment. The PaC might 252 address the PAA directly via a unicast message or a new discovery 253 message needs to be added. In the former case the PAA would be 254 co-located with the home agent. 256 4. Bootstrapping Issues 258 We assume that the MN will act as a PaC and some agent in the network 259 will act as the PAA, most likely the home agent itself. After mutual 260 authentication, a security association will be established between 261 PaC and the HA, which is comparable to an enforcement point (EP). 262 Note, the PAA and the EP may be co-located as well. 264 4.1 Home Agent Discovery 266 Finding the address of the HA will be regarded as out of scope of 267 this document. The MN could learn about the HA either by manual 268 configuration, DNS or some other mechanism (such as the MIPv6 anycast 269 mechanism). Even a discovery mechanism incorporated into the PANA 270 discovery mechanism is possible and for further investigation. 272 4.2 Obtaingin HoA 274 The payload of any PANA message consists of zero or more Attribute 275 Value Pairs (AVP). [I-D.ietf-pana-pana] describes a number of AVPs 276 for different purposes. This draft proposes a new AVP for carrying 277 the HoA of the MN. 279 HoA AVP: Contains the MIPv6 home address of the mobile node that 280 wishes to setup a security association with the corresponding home 281 agent. The HoA AVP is integrity protected by PANA and either 282 randomly selected or selected based on user authentication. 284 To deal with UDP encapsulation in case of NAT traversal or even with 285 IPv4/IPv6 transition the same procedure as suggested with an 286 extension for IKEv1 [I-D.ietf-ipsec-nat-t-ike] and in IKEv2 287 [I-D.ietf-ipsec-ikev2] can be applied. Support for this 288 functionality requires the introduction of a new AVP in PANA. In 289 context of IPv4/IPv6 transition scenario this proposal provides an 290 alternative solution for a tunnel broker (see also 291 [I-D.blanchet-v6ops-tunnelbroker-tsp] for a different approach using 292 SASL). 294 4.3 MN-HA security association 296 As motivated in Section 1 a security association is required for 297 subsequent protection of Mobile IPv6 Binding Update messages sent 298 between the MN and the HA. We refer to this security association as 299 the MIPv6 SA. Since the details of the MIPv6-Auth-Protocol 300 [I-D.ietf-mip6-auth-protocol] are subject to change we assume that 301 the following parameters have to be established as part of the 302 bootstrapping procedure: 304 o Security Parameter Index (SPI) - possibly for both directions 306 o Replay Protection Parameter (such as a timestamp or a sequence 307 number) 309 o Algorithms (if a negotiation procedure is desired) 311 Finally, a session key needs to be derived. Since a PANA SA needs to 312 be established based on the EAP method provided session key it is 313 also useful to apply the same procedure for deriving a session key 314 for the MIPv6 SA. Section 4.1.5 of [I-D.ietf-pana-pana] describes 315 the session key derivation for the PANA SA. 317 It might be worth noting that the PANA protocol also allows rekeying 318 of the security association (both the PANA SA and the MIPv6 SA). 319 Section 4.4 of [I-D.ietf-pana-pana] discusses this aspect in the 320 context of re-authentication. 322 The lifetime of the MIPv6 SA can either be negotiated or indicated by 323 the MN's home network. As another alternative the periodic 324 retransmission of "refresh" messages is benefial to deal with NATs, 325 stateful packet filtering firewalls and orphan state at the HA. PANA 326 provides such a refresh message as described in Section 4.5 of 327 [I-D.ietf-pana-pana]. Furthermore, a Session-Lifetime AVP is offered 328 by PANA as described in Section 4.10 of [I-D.ietf-pana-pana]. 330 5. Security Considerations 332 This document tries to raise some additional aspects for the MIPv6 MN 333 <-> HA Binding Update security discussions in context of Mobile IPv6 334 Bootstrapping. 336 The security considerations of the following documents are directly 337 applicable to this draft: PANA [I-D.ietf-pana-pana], 338 MIPv6-Auth-Protocol [I-D.ietf-mip6-auth-protocol], MIPv4 339 [I-D.ietf-mip4-rfc3344bis], MIPv6 [RFC3775] and MIPv6 Boostrapping 340 [I-D.ietf-mip6-bootstrap-ps] 342 A future version of this document will extract the relevant security 343 issues from these documents in order to present them in more details 344 once further steps have been taken within the MIPv6 working group. 346 6. Contributors 348 Many parts of this documents are the result of some discussions 349 within the PANA WG team. In particular the authors would like to 350 thank D. Forsberg, Y. Ohba, B. Patil and A. Yegin. 352 Furthermore, we would like to thank Udo Schilcher and Thomas 353 Hambrusch for their contributions to this document. 355 7. References 357 7.1 Normative References 359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 360 Requirement Levels", March 1997. 362 [I-D.ietf-pana-pana] 363 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 364 Yegin, "Protocol for Carrying Authentication for Network 365 Access (PANA)", draft-ietf-pana-pana-05 (work in 366 progress), July 2004. 368 [I-D.ietf-mip6-auth-protocol] 369 "Authentication Protocol for Mobile IPv6", 370 draft-ietf-mip6-auth-protocol-00 (work in progress), July 371 2004. 373 7.2 Informative References 375 [I-D.ietf-mip6-bootstrap-ps] 376 Patel, A., "Problem Statement for bootstrapping Mobile 377 IPv6", draft-ietf-mip6-bootstrap-ps-00 (work in progress), 378 July 2004. 380 [I-D.ietf-seamoby-mobility-terminology] 381 Manner, J. and M. Kojo, "Mobility Related Terminology", 382 draft-ietf-seamoby-mobility-terminology-06 (work in 383 progress), February 2004. 385 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 386 in IPv6", RFC 3775, June 2004. 388 [I-D.ietf-pana-requirements] 389 Yegin, A. and Y. Ohba, "Protocol for Carrying 390 Authentication for Network Access (PANA)Requirements", 391 draft-ietf-pana-requirements-08 (work in progress), June 392 2004. 394 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 395 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 396 3748, June 2004. 398 [I-D.eronen-ipsec-ikev2-eap-auth] 399 Eronen, P., "Extension for EAP Authentication in IKEv2", 400 draft-eronen-ipsec-ikev2-eap-auth-01 (work in progress), 401 May 2004. 403 [I-D.ietf-ipsec-ikev2] 404 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 405 draft-ietf-ipsec-ikev2-16 (work in progress), September 406 2004. 408 [I-D.ietf-mip4-rfc3344bis] 409 "IP Mobility Support for IPv4, revised", 410 draft-ietf-mip4-rfc3344bis-00 (work in progress), July 411 2004. 413 [I-D.arkko-pppext-eap-aka] 414 Arkko, J. and H. Haverinen, "EAP AKA Authentication", 415 draft-arkko-pppext-eap-aka-12 (work in progress), April 416 2004. 418 [I-D.ietf-ipsec-nat-t-ike] 419 Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 420 draft-ietf-ipsec-nat-t-ike-08 (work in progress), February 421 2004. 423 [I-D.blanchet-v6ops-tunnelbroker-tsp] 424 Blanchet, M., "IPv6 Tunnel Broker with the Tunnel Setup 425 Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-00 426 (work in progress), February 2004. 428 Authors' Addresses 430 Hannes Tschofenig 431 Siemens 432 Otto-Hahn-Ring 6 433 Munich, Bayern 81739 434 Germany 436 EMail: Hannes.Tschofenig@siemens.com 438 Srinath Thiruvengadam 439 Siemens 440 Otto-Hahn-Ring 6 441 Munich, Bayern 81739 442 Germany 444 EMail: srinath@mytum.de 446 Intellectual Property Statement 448 The IETF takes no position regarding the validity or scope of any 449 Intellectual Property Rights or other rights that might be claimed to 450 pertain to the implementation or use of the technology described in 451 this document or the extent to which any license under such rights 452 might or might not be available; nor does it represent that it has 453 made any independent effort to identify any such rights. Information 454 on the procedures with respect to rights in RFC documents can be 455 found in BCP 78 and BCP 79. 457 Copies of IPR disclosures made to the IETF Secretariat and any 458 assurances of licenses to be made available, or the result of an 459 attempt made to obtain a general license or permission for the use of 460 such proprietary rights by implementers or users of this 461 specification can be obtained from the IETF on-line IPR repository at 462 http://www.ietf.org/ipr. 464 The IETF invites any interested party to bring to its attention any 465 copyrights, patents or patent applications, or other proprietary 466 rights that may cover technology that may be required to implement 467 this standard. Please address the information to the IETF at 468 ietf-ipr@ietf.org. 470 Disclaimer of Validity 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 AND THE INTERNET 475 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 476 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 477 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 Copyright Statement 482 Copyright (C) The Internet Society (2004). This document is subject 483 to the rights, licenses and restrictions contained in BCP 78, and 484 except as set forth therein, the authors retain all their rights. 486 Acknowledgment 488 Funding for the RFC Editor function is currently provided by the 489 Internet Society.