idnits 2.17.00 (12 Aug 2021) /tmp/idnits28048/draft-aboba-nat-ipsec-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 182 has weird spacing: '....4) and a dif...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 May 2001) is 7654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '8' is defined on line 412, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 415, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 418, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 422, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2402 (ref. '3') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '4') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '5') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. '6') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '7') (Obsoleted by RFC 4306) == Outdated reference: draft-ietf-nat-rsip-framework has been published as RFC 3102 == Outdated reference: draft-ietf-nat-rsip-protocol has been published as RFC 3103 -- No information found for draft-ietf-nat-rsip-IPsec - is the name correct? == Outdated reference: draft-ietf-ipsec-dhcp has been published as RFC 3456 Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsec Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Informational 5 6 30 May 2001 8 IPsec-NAT Compatibility Requirements 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 36 Perhaps the most common use of IPsec is in providing virtual private 37 networking capabilities. One very popular use of VPNs is to provide 38 tele-commuter access to the corporate Intranet. Today NATs are widely 39 deployed in home gateways, as well as in other locations likely to be 40 used by tele-commuters, such as hotels. The result is that IPsec-NAT 41 incompatibilities have become a major barrier to deployment of IPsec in 42 one of its principal uses. This draft describes known incompatibilities 43 between NAT and IPsec, and describes the requirements for addressing 44 them. 46 1. Introduction 48 Perhaps the most common use of IPsec [6] is in providing virtual private 49 networking capabilities. One very popular use of VPNs is to provide 50 tele-commuter access to the corporate Intranet. Today NATs [8]-[9] are 51 widely deployed in home gateways, as well as in other locations likely 52 to be used by tele-commuters, such as hotels. The result is that IPsec- 53 NAT incompatibilities have become a major barrier to deployment of IPsec 54 in one of its principal uses. This draft describes known 55 incompatibilities between NAT and IPsec, and describes the requirements 56 for addressing them. 58 1.1. Requirements language 60 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 61 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 62 described in [2]. 64 Please note that the requirements specified in this document are to be 65 used in evaluating protocol submissions. As such, the requirements 66 language refers to capabilities of these protocols; the protocol 67 documents will specify whether these features are required, recommended, 68 or optional. For example, requiring that a protocol support 69 confidentiality is NOT the same thing as requiring that all protocol 70 traffic be encrypted. 72 A protocol submission is not compliant if it fails to satisfy one or 73 more of the MUST or MUST NOT requirements for the capabilities that it 74 implements. A protocol submission that satisfies all the MUST, MUST 75 NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to 76 be "unconditionally compliant"; one that satisfies all the MUST and MUST 77 NOT requirements but not all the SHOULD or SHOULD NOT requirements for 78 its protocols is said to be "conditionally compliant." 80 2. Known incompatibilities between NAT and IPsec 82 The incompatibilities between NAT and IPsec are numerous, ranging from 83 the obvious to the subtle. Some of the known incompatibilities include: 85 a) Incompatibility between IPsec AH [3] and NAT. Since the AH header 86 incorporates the IP source and destination addresses in the 87 keyed message integrity check, NAT or reverse NAT devices making changes 88 to address fields will invalidate the message integrity check. 89 Since IPsec ESP [4] does not incorporate the IP source and 90 destination addresses in its keyed message integrity check, 91 this issue does not arise for ESP. 93 b) Incompatibility between checksums and NAT. TCP/UDP/SCTP 94 checksums have a dependency on the IP source and destination 95 addresses through inclusion of the "pseudo-header" in the 96 calculation. As a result, where checksums are calculated and 97 checked on receipt, they will be invalidated by passage through 98 a NAT or reverse NAT device. 100 As a result, IPsec ESP will only pass unimpeded through a NAT if 101 TCP/UDP/SCTP protocols are not involved (as in IPsec tunnel 102 mode or IPsec/GRE), or checksums are not calculated (as is 103 possible with IPv4 UDP). As described in [13], TCP checksum 104 calculation and verification is required in IPv4. UDP/TCP 105 checksum calculation and verification is required in IPv6. 107 Note that since transport mode IPsec traffic is integrity protected 108 and authenticated using strong cryptography, modifications 109 to the packet can be detected prior to checking UDP/TCP/SCTP 110 checksums. Thus, checksum verification only provides assurance 111 against errors made in internal processing. 113 c) Incompatibility between IKE address identifiers and NAT. 114 Where IP addresses are used as identifiers in IKE MM [7] 115 or QM, modification of the IP source or destination 116 addresses by NATs or reverse NATs will result in a 117 mismatch between the identifiers and the addresses in the 118 IP header. As described in [7], IKE implementations are 119 required to discard such packets. 121 In order to avoid use of IP addresses as IKE MM and QM identifiers, 122 userIDs and FQDNs can be used instead. Where user authentication 123 is desired, an ID type of ID_USER_FQDN can be used, as described in 124 [5]. Where machine authentication is desired, an ID type of ID_FQDN 125 can be used. In either case it is necessary to verify that the 126 proposed identity matches that enclosed in the certificate. 127 However, while use of USER_FQDN or FQDN identity types is possible 128 within IKE, there are usage scenarios (e.g. SPD entries 129 describing subnets) that cannot be accommodated this way. 131 d) Incompatibility between fixed IKE destination ports and NAPT. 132 Where multiple hosts behind the NAPT initiate 133 IKE SAs to the same responder, a mechanism is needed 134 to allow the NAPT to demultiplex the incoming IKE 135 packets. This is typically accomplished by translating 136 the IKE UDP source port. While it is permissible to float 137 the IKE UDP source port, this can result in unpredictable 138 behavior during re-keys. Unless the floated source port is 139 used as the destination port for the re key, the NAT may 140 not be able to send the re-key packets to the correct 141 destination. 143 e) Incompatibilities between IKE cookie usage and NAT. 144 Today some NAT implementations attempt to use IKE cookies 145 to de-multiplex incoming IKE traffic. As with source-port 146 de-multiplexing, IKE cookie de-multiplexing also results 147 in problems with re-keying, since re-keys typically will 148 not use the same cookies as the earlier traffic. 150 f) Incompatibilities between overlapping SPD entries and NAT. 151 Where hosts behind a NAT negotiate overlapping SPD entries 152 with the same destination in IKE QM, packets may be sent 153 down the wrong IPsec SA. This occurs because to the 154 sender, the IPsec SAs appear to be equivalent, since they 155 exist between the same endpoints and can be used to pass 156 the same traffic. 158 g) Incompatibilities between IPsec SPI selection and NAT. 159 Since IPsec ESP traffic is encrypted and thus opaque to the NAT, 160 the NAT must use elements of the IP and IPsec header to 161 demultiplex incoming IPsec traffic. The combination of the 162 destination IP address, security protocol (AH/ESP) and IPsec SPI 163 is typically used for this purpose. 165 However, since the outgoing and incoming SPIs are chosen 166 independently, there is no way for the NAT to determine 167 what incoming SPI corresponds to what destination host 168 merely by inspecting outgoing traffic. Thus, were two 169 hosts behind the NAT to attempt to bring up IPsec SAs to 170 the same destination simultaneously, it is possible that 171 the NAT will send the incoming IPsec packets to the 172 wrong destination. 174 Note that this is not an incompatibility with IPsec per 175 se, but rather with the way it is typically implemented. 176 With both AH and ESP, the receiving host specifies the 177 SPI to use for a given SA. At present, the combination of 178 Destination IP, SPI, and Security Protocol (AH, ESP) uniquely 179 identifies a Security Association. This means that the 180 receiving host can select SPIs such that 181 it has one Security Association (SA) with (SPI=470, 182 Dest IP=1.2.3.4) and a different Security Association with 183 (SPI=470, Dest IP=2.3.4.5). 185 It is also possible for the receiving host to allocate 186 a unique SPI to each unicast Security Association. In 187 this case, the Destination IP Address need only be checked 188 to see if it is "any valid unicast IP for this host", not 189 checked to see if it is the specific Destination IP address 190 used by the sending host. This approach is completely backwards 191 compatible and only requires the particular receiving host to 192 make a change to its SPI allocation and IPsec_esp_input() code. 194 h) Incompatibilities between embedded IP addresses and NAT. 195 Since the payload is integrity protected, any IP addresses 196 enclosed within IPsec packets will not be translatable by a 197 NAT. Protocols that utilize embedded IP addresses include 198 FTP, IRC, SNMP, LDAP, H.323, SIP and many games. 200 2.1. What works 202 Given the incompatibilities described above, it might seem unlikely that 203 any IPsec/IKE conversation could survive passage through a NAT. However, 204 IPsec tunnel mode clients [15] are capable of traversing NATs under 205 limited conditions: 207 [1] IPsec ESP. IPsec ESP tunnels do not cover the outer IP header 208 within the authentication hash, and so will not suffer hash 209 invalidation due to address translation. IPsec tunnels also need 210 not be concerned about checksum invalidation (unlike L2TP). 212 [2] Address validation. Most current IPSEC tunnel mode implementations 213 do not perform source address validation so that incompatibilities 214 between IKE identifiers and source addresses will not be detected. 215 This introduces security vulnerabilities as described in the 216 security considerations section. 218 [3] SPD entries. Most IPsec tunnel mode clients negotiate "any to any" 219 SPDs, which are not invalidated by address translation. This 220 effectively precludes use of SPDs for filtering of allowed tunnel 221 traffic. 223 [4] Single client operation. With only a single client behind a NAT, 224 there is no risk of overlapping SPDs. Since the NAT will not need 225 to arbitrate between competing clients, there is also no risk of 226 re-key mis-translation, or improper incoming SPI or cookie de- 227 multiplexing. 229 3. Requirements for IPsec-NAT compatibility 231 The goal of an IPsec-NAT compatibility solution is to expand the range 232 of usable IPsec functionality beyond that available in an NAT-compatible 233 IPsec tunnel mode solution described above. 235 In evaluating a solution to IPsec-NAT incompatibility, the following 236 criteria should be kept in mind: 238 Deployability 239 Since IPv6 will address the address scarcity issues that 240 frequently lead to use of NATs with IPv4, the IPsec-NAT 241 compability issue is a transitional problem that needs to be 242 solved in the timeframe prior to widespread deployment of 243 IPv6. Therefore, to be useful an IPsec-NAT compatibility 244 solution MUST be deployable on a shorter time scale than IPv6. 246 Since IPv6 deployment requires changes to routers as well as 247 hosts, a IPsec-NAT compatibility solution which requires 248 changes to both routers and hosts will be deployable on 249 approximately the same time scale as IPv6. Thus, an IPsec-NAT 250 compatibility solution SHOULD require changes only to hosts, 251 and not to routers. 253 Among other things, this implies that communication between 254 the host and the NAT MUST NOT be required by an IPsec-NAT 255 compatibility solution, since existing NATs cannot meet such a 256 requirement. 258 Telecommuter scenario 259 Since a typical telecommuter is only interested in obtaining 260 access to the corporate Intranet for itself, an IPsec-NAT 261 compatibility solution need not enable gateway-gateway 262 connectivity. Thus, it can be assumed that negotiated SPD 263 entries will only refer to the communication endpoints, and 264 there is no need to support negotiation of SPD entries 265 involving subnets. to 267 Scaling An IPsec-NAT compatibility solution should be capable of being 268 deployed within an installation consisting of thousands of 269 telecommuters. In this situation, it is not possible to 270 assume that only a single host is communicating with a given 271 destination at a time. Thus, an IPsec-NAT compatibility 272 solution MUST address the issue of overlapping SPD entries and 273 de-multiplexing of incoming packets. 275 Mode support 276 At a minimum, an IPsec-NAT compatibility solution MUST support 277 passage of IPsec ESP tunnel mode through a NAT. Since IPsec 278 transport mode is used for tunneling protocols such as L2TP 279 [1], an IPsec-NAT compatibility solution SHOULD support IPsec 280 transport mode using ESP, at least for protection of UDP 281 traffic where no embedded IP addresses are present. Since 282 passage of AH through a NAT is not possible in any mode, there 283 is no need for an IPsec-NAT compatibility solution to attempt 284 to address this. 286 Interoperability 287 An IPsec-NAT compatibility solution MUST be interoperable with 288 existing IPsec implementations. Thus, existing IPsec 289 implementations MUST be able to communicate with an IPsec-NAT 290 compatible implementation in the case where no NAT is present. 291 This implies that an IPsec-NAT compatibility solution MUST be 292 backwards-compatible with IPsec as defined in [3]-[7], and 293 SHOULD be able to detect the presence of a NAT so that the 294 required changes for NAT compatibility will only be used when 295 necessary. 297 For example, it may be possible to enable ISAKMP to pass 298 information about each host's perception of its own IP 299 address, in order to make key management aware of the presence 300 of the NAT and facilitate the use of standard key management 301 methods through a NAT to support ESP/AH. 303 Security An IPsec-NAT compatibility solution MUST NOT introduce 304 additional security vulnerabilities into IKE. For example, an 305 acceptable solution must demonstrate that it introduces no new 306 denial of service or spoofing vulnerabilities. 308 4. Existing solutions 310 4.1. RSIP 312 RSIP, described in [10]-[11], includes mechanisms for IPsec traversal, 313 as described in [12]. By enabling host-gateway communication, RSIP 314 addresses issues of IPsec SPI de-multiplexing as well as SPD overlap. It 315 is thus suitable for use in enterprise as well as home networking 316 scenarios. By enabling hosts behind a NAT to share the external IP 317 address of the gateway, this approach is compatible with protocols 318 including embedded IP addresses. 320 By tunneling IKE and IPsec packets, RSIP avoids changes to the IKE and 321 IPsec protocols, although major changes are required to host IKE and 322 IPsec implementations to retrofit them for RSIP-compatibility. It is 323 thus compatible with all existing protocols (AH/ESP) and modes 324 (transport and tunnel). 326 In order to handle de-multiplexing of IKE re-keys, RSIP requires 327 floating of the IKE source port, as well as re-keying to the floated 328 port. As a result, inter-operability with existing IPsec implementations 329 is not assured. 331 RSIP does not satisfy the deployability requirements for a IPsec-NAT 332 compatibility solution because an RSIP-enabled host requires a 333 corresponding RSIP-enabled gateway in order to establish an IPsec SA 334 with another host. Since RSIP requires changes only to clients and 335 routers and not to servers, it is less difficult to deploy than IPv6. 336 However, for vendors, implementation of RSIP requires a substantial 337 fraction of the resources required for IPv6 support. Thus, RSIP solves a 338 "transitional" problem on a long-term time scale, which is not useful. 340 5. Security considerations 342 By definition, IPsec-NAT compatibility requires that hosts and routers 343 implementing IPsec be capable of securely processing packets whose IP 344 headers are not cryptographically protected. A number of issues arise 345 from this that are worth discussing. 347 Since IPsec AH cannot pass through a NAT, one of the side effects of 348 providing an IPsec-NAT compatibility solution may be for IPsec ESP with 349 null encryption to be used in place of AH where a NAT exists between the 350 source and destination. However, it should be noted that ESP with null 351 encryption does not provide the same security properties as AH. For 352 example, there are security risks relating to IP source routing that are 353 precluded by AH, but not by ESP with null encryption. 355 In addition, since ESP with any transform does not protect against 356 source address spoofing, some sort of source IP address sanity checking 357 needs to be performed. The importance of the anti-spoofing check is not 358 widely understood. There is normally an anti-spoofing check on the 359 Source IP Address as part of IPsec_{esp,ah}_input(). This ensures that 360 the packet originates from the same address as that was claimed within 361 the original IKE MM and QM security associations. When a receiving host 362 is behind a NAT, this check might not strictly be meaningful for unicast 363 sessions, whereas in the Global Internet this check is important for 364 tunnel-mode unicast sessions to prevent a spoofing attack described in 365 [14]. 367 Let us consider two hosts, A and C, both behind (different) NATs, who 368 negotiate IPsec tunnel mode SAs to router B. Hosts A and C may have 369 different privileges; for example, host A might belong to an employee 370 trusted to access much of the corporate Intranet, while C might be a 371 contractor only authorized to access a specific web site. 373 If host C sends a tunnel mode packet spoofing A's IP address, as the 374 source, it is important that this packet not be accorded the privileges 375 corresponding to A. If authentication and integrity checking is 376 performed, but no anti-spoofing check (verifying that the originating IP 377 address corresponds to the SPI) then host C may be allowed to reach 378 parts of the network that are off-limits. As a result, an IPsec-NAT 379 compatibility scheme MUST provide some degree of anti-spoofing 380 protection. 382 6. Acknowledgments 384 Thanks to Steve Bellovin of AT&T Research, William Dixon of Microsoft, 385 Ran Atkinson of Extreme Networks and Daniel Senie for useful discussions 386 of this problem space. 388 7. References 390 [1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and 391 Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 392 1999. 394 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 395 Levels", BCP 14, RFC 2119, March 1997. 397 [3] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, 398 November 1998. 400 [4] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", 401 RFC 2406, November 1998. 403 [5] Piper, D., "The Internet IP Security Domain of Interpretation of 404 ISAKMP", RFC 2407, November 1998. 406 [6] Atkinson, R., Kent, S., "Security Architecture for the Internet 407 Protocol", RFC 2401, November 1998. 409 [7] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 410 2409, November 1998. 412 [8] Srisuresh, P., and Egevang, K., "Traditional IP Network Address 413 Translator (Traditional NAT)", RFC 3022, January 2001. 415 [9] Srisuresh, P. and Holdredge, M., "IP Network Address Translator 416 (NAT) Terminology and Considerations," RFC 2663, August 1999. 418 [10] Borella, M., Lo, J., Grabelsky, D., Montenegro, G., "Realm Specific 419 IP: A Framework", Internet draft (work in progress), draft-ietf- 420 nat-rsip-framework-05.txt, July 2000. 422 [11] Borella, M., Grabelsky, D., Lo, J., Taniguchi, K., "Realm Specific 423 IP: Protocol Specification", Internet draft (work in progress), 424 draft-ietf-nat-rsip-protocol-07.txt, July 2000. 426 [12] Montenegro, G., Borella, M., "RSIP Support for End-to-End IPsec", 427 Internet draft (work in progress), draft-ietf-nat-rsip- 428 IPsec-04.txt, July 2000. 430 [13] Information Sciences Institute, "Transmission Control Protocol", 431 RFC 793, September 1981. 433 [14] Kent, S., "Authenticated Source Addresses", IPsec WG Archive ( 434 ftp://ftp.ans.net/pub/archive/IPsec ), Message-Id: 435 , January 5, 1996. 437 [15] Patel, B., Aboba, B., Kelly, S., Gupta, V., "DHCPv4 Configuration 438 of IPsec Tunnel Mode", Internet draft (work in progress), draft- 439 ietf-ipsec-dhcp-12.txt, May 2001. 441 8. Authors' Addresses 443 Bernard Aboba 444 Microsoft Corporation 445 One Microsoft Way 446 Redmond, WA 98052 448 Phone: +1 425 936 6605 449 EMail: bernarda@microsoft.com 451 9. Intellectual Property Statement 453 The IETF takes no position regarding the validity or scope of any 454 intellectual property or other rights that might be claimed to pertain 455 to the implementation or use of the technology described in this 456 document or the extent to which any license under such rights might or 457 might not be available; neither does it represent that it has made any 458 effort to identify any such rights. Information on the IETF's 459 procedures with respect to rights in standards-track and standards- 460 related documentation can be found in BCP-11. Copies of claims of 461 rights made available for publication and any assurances of licenses to 462 be made available, or the result of an attempt made to obtain a general 463 license or permission for the use of such proprietary rights by 464 implementors or users of this specification can be obtained from the 465 IETF Secretariat. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary rights 469 which may cover technology that may be required to practice this 470 standard. Please address the information to the IETF Executive 471 Director. 473 10. Full Copyright Statement 475 Copyright (C) The Internet Society (2000). All Rights Reserved. 477 This document and translations of it may be copied and furnished to 478 others, and derivative works that comment on or otherwise explain it or 479 assist in its implementation may be prepared, copied, published and 480 distributed, in whole or in part, without restriction of any kind, 481 provided that the above copyright notice and this paragraph are included 482 on all such copies and derivative works. However, this document itself 483 may not be modified in any way, such as by removing the copyright notice 484 or references to the Internet Society or other Internet organizations, 485 except as needed for the purpose of developing Internet standards in 486 which case the procedures for copyrights defined in the Internet 487 Standards process must be followed, or as required to translate it into 488 languages other than English. The limited permissions granted above are 489 perpetual and will not be revoked by the Internet Society or its 490 successors or assigns. This document and the information contained 491 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 492 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 493 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 494 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 495 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 497 11. Expiration Date 499 This memo is filed as , and expires 500 December 1, 2001.