idnits 2.17.1 draft-ietf-mip6-auth-protocol-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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 527. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 543), 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 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 184: '... the HA. The MN SHOULD use NAI option...' RFC 2119 keyword, line 238: '... MUST be aligned on an 8-octet...' RFC 2119 keyword, line 275: '... The MN SHOULD use NAI option [NAI] to enable the Home Agent to make...' RFC 2119 keyword, line 278: '... The MN MUST use either CHAP_SPI or ...' RFC 2119 keyword, line 296: '... mobility option MUST be verified by t...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 123 has weird spacing: '... This docum...' == Line 260 has weird spacing: '... The first ...' == Line 383 has weird spacing: '... this case,...' -- 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 (July 2, 2004) is 7231 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: 'RFC2486' is defined on line 453, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-mip4-rfc3012bis-01 -- No information found for draft-ietf-mipv6-nai-option - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'NAI' ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Patel 2 Internet-Draft K. Leung 3 Expires: December 31, 2004 Cisco Systems 4 M. Khalil 5 H. Akhtar 6 K. Chowdhury 7 Nortel Networks 8 July 2, 2004 10 Authentication Protocol for Mobile IPv6 11 draft-ietf-mip6-auth-protocol-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 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 31 http://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 31, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document defines new mobility options to enable authentication 45 between mobility entities. These options can be used in addition to 46 or in lieu of IPsec to authenticate mobility messages as defined in 47 the base Mobile IPv6 specification. 49 Table of Contents 51 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. General Terms . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Mobility message authentication option . . . . . . . . . . . . 8 57 6.1 MN-HA authentication mobility option . . . . . . . . . . . 9 58 6.2 MN-AAA authentication mobility option . . . . . . . . . . 9 59 6.2.1 Processing considerations . . . . . . . . . . . . . . 10 60 7. Mobility message identification option . . . . . . . . . . . . 11 61 7.1 Processing considerations . . . . . . . . . . . . . . . . 12 62 7.1.1 Home Agent Considerations . . . . . . . . . . . . . . 12 63 7.1.2 Mobile Node Considerations . . . . . . . . . . . . . . 12 64 7.1.3 AAA server Considerations . . . . . . . . . . . . . . 13 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 68 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 70 Intellectual Property and Copyright Statements . . . . . . . . 18 72 1. Motivation 74 The base specification of Mobile IPv6 [RFC3775] mandates IPsec 75 support between MN and HA for authentication. Also, return 76 routability messages passing via the HA (HoT/HoTi) and mobile prefix 77 discovery messages must be protected using IPsec. 79 While IPsec (ESP) may offer strong protection (depending on the 80 algorithms used), use of IPsec may not be required/feasible in all 81 cases where Mobile IPv6 may be used. For small handheld devices, the 82 use of IPsec may be too taxing on battery and processor performance. 83 Also depending on the model of home agent deployment (HA deployed by 84 enterprise/service provider), MN may have to VPN back into the 85 enterprise (which may impose dual IPsec requirement on MN). 87 Moreover, IPsec/IKE based Mobile IPv6 over public wireless carrier's 88 networks may pose serious capacity and scalability challenge. The 89 multiple round trips to perform ISAKMP/IKE to establish IPsec SA may 90 be too taxing on the wireless link, not to mention increase in setup 91 latency during initial access and during handoffs. The use of manual 92 IPsec SA in these large public network deployments suffer from 93 scalability issue and involve provisioning nightmare. 95 Also, having an authentication mechanism tied to the Mobile's home IP 96 address does not permit the mobility entity to derive or acquire a 97 dynamic home address based on the configured prefix. If the MN's 98 home address is dynamically configured based on a fixed prefix or 99 acquired during network access authentication (PPP, 802.1x etc.), 100 IPsec will most likely not work as the IPsec SAs are tied to the 101 address. The mechanism described in this draft is not tied with 102 mobility entities home IP address and therefore does not mandate SA 103 relationship with an IP address. 105 Another important motivation for this proposed mechanism is to allow 106 the MN to register with a Home Agent on a dynamically discovered Home 107 Link. This sort of Dynamic Home Link assignments will allow the 108 operators to leverage the true benefit of dynamic Home Agent 109 assignment. For example the operator may assign a Home Link or Home 110 Agent for the user that is closest to the subnet of attachment of the 111 user. There may be various other reasons for opportunistic Home 112 Agent assignment. The mechanisms described in the draft allows the 113 MN to register with any Home Agent in the home network as long as the 114 MN user shares security association with an entity in the home 115 network such as a AAA server. 117 2. Overview 119 This document presents a lightweight mechanism to authenticate the MN 120 at the HA or at the Home AAA based on a shared security association 121 between the MN and the respective authenticating entity. 123 This document introduces new mobility options to aid in 124 authentication of the MN to the HA or AAA server. The 125 confidentiality protection of the Mobile Prefix Discovery (MPD) and 126 Return Routability (Home KeyGen token) messages is outside the scope 127 of this document. 129 3. Terminology 131 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 133 this document are to be interpreted as described in RFC 2119. 135 4. General Terms 137 MN Mobile Node 139 HA Home Agent 141 SA Security Association 143 IPsec IP Security protocol 145 ESP Encapsulating security protocol 147 BU Binding Update 149 BA Binding Acknowledgement 151 SPI Security Parameter Index 153 MH Mobility Header 155 HAAA Home Authentication Authorization Accounting server 157 CHAP CHallenge Authentication Protocol 159 HoA Home Address 161 AVP Attribute Value Pair 163 AAA Authentication Authorization Accounting 165 NAI Network Address Identifier 167 5. Operational flow 169 MN HA/HAAA 170 | BU to HA | 171 (a) |---------------------------------------------------->| 172 | (HoA option, NAI[optional], ID option, auth option) | 173 | | 174 | HA/HAAA authenticates MN 175 | | 176 | | 177 | BA to MN | 178 (b) |<----------------------------------------------------| 179 | (HoA option, NAI[optional], ID option, auth option) | 180 | | 181 | | 183 MN may use NAI option as defined in [NAI] to identify itself to the 184 HA while authenticating with the HA. The MN SHOULD use NAI option 185 [NAI] while authenticating with the AAA infrastructure. 187 6. Mobility message authentication option 189 This section defines the message authentication mobility option that 190 may be used to secure Binding Update and Binding Acknowledgement 191 messages. This extension can be used along with IPsec or preferably 192 as an alternate mechanism to authenticate binding update and binding 193 acknowledgement messages in absence of IPsec. This document also 194 defines subtype numbers, which identify the mode of authentication 195 and the peer entity to authenticate the message. Two subtype numbers 196 are specified in this document. It is expected that other subtypes 197 will be defined by other documents in the future. 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Option Type | Option Length | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Subtype | SPI | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | SPI | Authenticator . . . 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Option Type: 211 AUTH-OPTION-TYPE to be defined by IANA. An 8-bit identifier of 212 the type mobility option. 214 Option Length: 216 8-bit unsigned integer, representing the length in octets of 217 the sub-type, SPI and authenticator, not including the Option 218 Type and Option Length fields. 220 Subtype: 222 A number assigned to identify the entity and/or mechanism to be 223 used to authenticate the message. 225 SPI: 227 Used to identify the particular security association to use to 228 authenticate the message. 230 Authenticator: 232 This field has the information to authenticate the relevant 233 mobility entity. This protects the message beginning at the 234 Mobility Header upto and including the SPI field. 236 Alignment requirements : 238 MUST be aligned on an 8-octet boundary. 240 6.1 MN-HA authentication mobility option 242 The format of the MN-HA authentication mobility option is as defined 243 in section 6. This option uses the subtype value of 1. The MN-HA 244 authentication mobility option is used to authenticate the binding 245 update and binding acknowledgement messages based on the shared 246 security association between the MN and the HA. 248 This must be the last option in a message with mobility header. The 249 authenticator is calculated on the message starting from the mobility 250 header till the SPI value of this option. 252 Authenticator = First (96,HMAC_SHA1(MN-HA Shared key, Mobility 253 Data)) 255 Mobility Data = care-of address | home address | MH Data 257 MH Data is the content of the Mobility Header till the SPI field of 258 this extension. 260 The first 96 bits from the MAC result are used as the 261 Authenticator field. 263 6.2 MN-AAA authentication mobility option 265 The format of the MN-AAA authentication mobility option is as defined 266 in section 6. This option uses the subtype value of 2. The MN-AAA 267 authentication mobility option is used to authenticate the binding 268 update and binding acknowledgement messages based on the shared 269 security association between MN and HAAA. 271 This must be the last option in a message with mobility header. The 272 authenticator is calculated on the message starting from the mobility 273 header till the SPI value of this option. 275 The MN SHOULD use NAI option [NAI] to enable the Home Agent to make 276 use of available AAA infrastructure which requires NAI. 278 The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in 279 [3012bis] to indicate CHAP style authentication. The authenticator 280 shall be calculated as follows: 282 Authenticator = First (96, HMAC_SHA1 (MN-AAA Shared key, MAC_Mobility 283 Data))). 285 SPI = CHAP_SPI: 287 MAC_Mobility Data = MD5 (care-of address | home address | MH Data). 289 SPI = HMAC_CHAP_SPI: 291 MAC_Mobility Data = HMAC_MD5 (care-of address | home address | MH 292 Data). 294 6.2.1 Processing considerations 296 The MN-AAA authentication mobility option MUST be verified by the AAA 297 infrastructure that has the shared secret with the MN. The HA relays 298 the authenticating information to the HAAA. The HA relies on the 299 HAAA to admit or reject the home registration request from the MN. 301 6.2.1.1 Home Agent Considerations 303 Upon receiving a BU from the MN the HA SHALL extract the MN-AAA 304 authenticator and the SPI from the MN-AAA authentication mobility 305 option and extract the NAI from the NAI option [NAI]. The HA SHALL 306 include the extracted MN-AAA authenticator, SPI and the NAI in AAA 307 specific AVPs while initiating the authentication procedure via AAA 308 infrastructure. 310 7. Mobility message identification option 312 The identification option is used to prevent replay protection. The 313 Identification field carries timestamp for replay protection. This 314 option can be used in binding update and binding acknowledgement 315 messages. 317 The default method for this purpose is the timestamp method; some 318 other methods may be utilized as well. If the MN uses 'timestamp' as 319 a measure against replay protection, it SHOULD insert the current 320 time of day. When the destination node receives the Binding Update, 321 it will make sure that the 'timestamp' (as included by the sender) is 322 close enough to its own time of the day. A default value of 500 323 milliseconds MAY be used as a reasonable offset (the time difference 324 between the sender and the receiver). 326 The low-order 32 bits of the identification option represents 327 fractional seconds, the rest of the bits SHOULD be generated from a 328 good source of randomness. 330 For the identification field to be valid, the 'timestamp' contained 331 in the Identification field MUST be close enough (as determined by 332 the system implementers) and greater than the HA's and/or HAAA's time 333 of day clock. 335 The style of replay protection in effect between a mobile node and 336 the HA and/or the HAAA is part of the mobile security association. A 337 mobile node and the HA and/or the HAAA MUST agree on which method of 338 replay protection will be used. 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Option Type | Option Length | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Identification ... 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Option Type: 350 IDENT-OPTION-TYPE to be defined by IANA. An 8-bit identifier 351 of the type mobility option. 353 Option Length: 355 8-bit unsigned integer, representing the length in octets of 356 the Identification field. 358 Identification: 360 The Identification field carries timestamp for replay 361 protection. 363 Alignment requirements : 365 MUST be aligned on an 8-octet boundary. 367 7.1 Processing considerations 369 The Identification field is used to let the HA and/or the HAAA verify 370 that a Binding Update message has been generated recently by the MN, 371 and it is not replayed by an attacker from some older registrations. 373 7.1.1 Home Agent Considerations 375 The HA processes this option only when MN-HA authentication mobility 376 option is used in the BU. In this case: 378 After successful authentication of Binding Update, the Home Agent 379 must verify that the Identification field falls within the replay 380 protection window. If Identification field is not within this window 381 but the authentication of the BU succeeds, HA MUST send a Binding 382 Acknowledgement with error code "TBD by IANA" MIPV6-ID-MISMATCH. In 383 this case, HA must include the correct identification field in the 384 Binding Acknowledgement message. 386 MN-HA Timestamp: If timestamp based replay check is successful and 387 the authentication succeeds, the HA MUST include the received 388 Identification value in the corresponding field of the Mobility 389 message identification option in the BA. 391 7.1.2 Mobile Node Considerations 393 The MN MUST process the Mobility message identification option. 395 MN-HA Timestamp and MN-AAA Timestamp: The MN MUST set the 396 Identification value in the Mobility message identification option in 397 the BU message according to its own clock. If the MN receives a 398 Binding Acknowledgement with the code MIPV6-ID-MISMATCH, MN must 399 adjust its timestamp and send subsequent Binding Update using the 400 updated value. 402 7.1.3 AAA server Considerations 404 The HAAA processes this option only when MN-AAA authentication 405 mobility option is used in the BU. In this case: 407 After successful authentication of MN's credentials contained in the 408 AVPs, the Home AAA server MUST verify that the Identification field 409 falls within the replay protection window. If Identification field 410 is not within this window, HAAA MUST reject the authentication and 411 authorization request. Upon receiving the reject message from HAAA 412 server, the HA MUST send a Binding Acknowledgement with error code 413 "TBD by IANA" MIPV6-ID-MISMATCH. In this case, HA must include the 414 correct identification field in the Mobility message identification 415 option in the Binding Acknowledgement message. 417 MN-AAA Timestamp: If timestamp based replay check is successful and 418 the authentication and authorization succeeds, the HAAA does not 419 include any updated Identification value in the accept message. In 420 this case, the HA copies the Identification value from the BU into 421 the corresponding field in the BA. If the replay check fails but 422 authentication succeeds, in the reject message the HAAA MUST include 423 the latest timestamp according to it's own clock. 425 8. Security Considerations 427 This document proposes new authentication options to authenticate the 428 control message between MN, HA and/or HAAA (as an alternative to 429 IPsec). The new options provide for authentication of Binding Update 430 and Binding Acknowledgement messages 432 9. IANA Considerations 434 The option types AUTH-OPTION-TYPE, IDENT-OPTION-TYPE, as defined in 435 section 6 and 7 respectively are new mobility options. The 436 MIPV6-ID-MISMATCH error code also needs to be defined. IANA should 437 record values for these new mobility options and the new error code. 439 10. Acknowledgements 441 TBD. 443 11 Normative References 445 [3012bis] Perkins et. al., C., "Mobile IPv4 Challenge/Response 446 Extensions (revised)", draft-ietf-mip4-rfc3012bis-01 (work 447 in progress), April 2004. 449 [NAI] Patel et. al., A., "Network Access Identifier Option for 450 Mobile IPv6", draft-ietf-mipv6-nai-option-00.txt (work in 451 progress), February 2004. 453 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 454 RFC 2486, January 1999. 456 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 457 in IPv6", RFC 3775, June 2004. 459 Authors' Addresses 461 Alpesh Patel 462 Cisco Systems 463 170 W. Tasman Drive 464 San Jose, CA 95134 465 US 467 Phone: +1 408-853-9580 468 EMail: alpesh@cisco.com 470 Kent Leung 471 Cisco Systems 472 170 W. Tasman Drive 473 San Jose, CA 95134 474 US 476 Phone: +1 408-526-5030 477 EMail: kleung@cisco.com 478 Mohamed Khalil 479 Nortel Networks 480 2221 Lakeside Blvd. 481 Richardson, TX 75082 482 US 484 Phone: +1 972-685-0574 485 EMail: mkhalil@nortelnetworks.com 487 Haseeb Akhtar 488 Nortel Networks 489 2221 Lakeside Blvd. 490 Richardson, TX 75082 491 US 493 Phone: +1 972-684-4732 494 EMail: haseebak@nortelnetworks.com 496 Kuntal Chowdhury 497 Nortel Networks 498 2221 Lakeside Blvd. 499 Richardson, TX 75082 500 US 502 Phone: +1 972 685 7788 503 EMail: chowdury@nortelnetworks.com 505 Intellectual Property Statement 507 The IETF takes no position regarding the validity or scope of any 508 Intellectual Property Rights or other rights that might be claimed to 509 pertain to the implementation or use of the technology described in 510 this document or the extent to which any license under such rights 511 might or might not be available; nor does it represent that it has 512 made any independent effort to identify any such rights. Information 513 on the procedures with respect to rights in RFC documents can be 514 found in BCP 78 and BCP 79. 516 Copies of IPR disclosures made to the IETF Secretariat and any 517 assurances of licenses to be made available, or the result of an 518 attempt made to obtain a general license or permission for the use of 519 such proprietary rights by implementers or users of this 520 specification can be obtained from the IETF on-line IPR repository at 521 http://www.ietf.org/ipr. 523 The IETF invites any interested party to bring to its attention any 524 copyrights, patents or patent applications, or other proprietary 525 rights that may cover technology that may be required to implement 526 this standard. Please address the information to the IETF at 527 ietf-ipr@ietf.org. 529 Disclaimer of Validity 531 This document and the information contained herein are provided on an 532 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 533 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 534 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 535 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 536 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 537 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 539 Copyright Statement 541 Copyright (C) The Internet Society (2004). This document is subject 542 to the rights, licenses and restrictions contained in BCP 78, and 543 except as set forth therein, the authors retain all their rights. 545 Acknowledgment 547 Funding for the RFC Editor function is currently provided by the 548 Internet Society.