Network Working Group B. Patel Request for Comments: 3193 Intel Category: Standards Track B. Aboba W. Dixon Microsoft G. Zorn S. Booth Cisco Systems November 2001 Securing L2TP using IPsec Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThis document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed.
1. Introduction .................................................. 2 1.1 Terminology .................................................. 3 1.2 Requirements language ........................................ 3 2. L2TP security requirements ................................... 4 2.1 L2TP security protocol ....................................... 5 2.2 Stateless compression and encryption ......................... 5 3. L2TP/IPsec inter-operability guidelines ....................... 6 3.1. L2TP tunnel and Phase 1 and 2 SA teardown ................... 6 3.2. Fragmentation Issues ........................................ 6 3.3. Per-packet security checks .................................. 7 4. IPsec Filtering details when protecting L2TP .................. 7 4.1. IKE Phase 1 Negotiations .................................... 8 4.2. IKE Phase 2 Negotiations .................................... 8 5. Security Considerations ....................................... 15 5.1 Authentication issues ........................................ 15 5.2 IPsec and PPP interactions ................................... 18 6. References .................................................... 21 Acknowledgments .................................................. 22 Authors' Addresses ............................................... 23 Appendix A: Example IPsec Filter sets ............................ 24 Intellectual Property Statement .................................. 27 Full Copyright Statement ......................................... 28 1] is a protocol that tunnels PPP traffic over variety of networks (e.g., IP, SONET, ATM). Since the protocol encapsulates PPP, L2TP inherits PPP authentication, as well as the PPP Encryption Control Protocol (ECP) (described in ), and the Compression Control Protocol (CCP) (described in ). L2TP also includes support for tunnel authentication, which can be used to mutually authenticate the tunnel endpoints. However, L2TP does not define tunnel protection mechanisms. IPsec is a protocol suite which is used to secure communication at the network layer between two peers. This protocol is comprised of IP Security Architecture document , IKE, described in , IPsec AH, described in  and IPsec ESP, described in . IKE is the key management protocol while AH and ESP are used to protect IP traffic. This document proposes use of the IPsec protocol suite for protecting L2TP traffic over IP networks, and discusses how IPsec and L2TP should be used together. This document does not attempt to
standardize end-to-end security. When end-to-end security is required, it is recommended that additional security mechanisms (such as IPsec or TLS ) be used inside the tunnel, in addition to L2TP tunnel security. Although L2TP does not mandate the use of IP/UDP for its transport mechanism, the scope of this document is limited to L2TP over IP networks. The exact mechanisms for enabling security for non-IP networks must be addressed in appropriate standards for L2TP over specific non-IP networks. 2].
1] An adversary may try to discover user identities by snooping data packets.  An adversary may try to modify packets (both control and data).  An adversary may try to hijack the L2TP tunnel or the PPP connection inside the tunnel.  An adversary can launch denial of service attacks by terminating PPP connections, or L2TP tunnels.  An adversary may attempt to disrupt the PPP ECP negotiation in order to weaken or remove confidentiality protection. Alternatively, an adversary may wish to disrupt the PPP LCP authentication negotiation so as to weaken the PPP authentication process or gain access to user passwords. To address these threats, the L2TP security protocol MUST be able to provide authentication, integrity and replay protection for control packets. In addition, it SHOULD be able to protect confidentiality for control packets. It MUST be able to provide integrity and replay protection of data packets, and MAY be able to protect confidentiality of data packets. An L2TP security protocol MUST also provide a scalable approach to key management. The L2TP protocol, and PPP authentication and encryption do not meet the security requirements for L2TP. L2TP tunnel authentication provides mutual authentication between the LAC and the LNS at tunnel origination. Therefore, it does not protect control and data traffic on a per packet basis. Thus, L2TP tunnel authentication leaves the L2TP tunnel vulnerable to attacks. PPP authenticates the client to the LNS, but also does not provide per-packet authentication, integrity, or replay protection. PPP encryption meets confidentiality requirements for PPP traffic but does not address authentication, integrity, replay protection and key management requirements. In addition, PPP ECP negotiation, outlined in  does not provide for a protected ciphersuite negotiation. Therefore, PPP encryption provides a weak security solution, and in addition does not assist in securing L2TP control channel.
Key management facilities are not provided by the L2TP protocol. However, where L2TP tunnel authentication is desired, it is necessary to distribute tunnel passwords. Note that several of the attacks outlined above can be carried out on PPP packets sent over the link between the client and the NAS/LAC, prior to encapsulation of the packets within an L2TP tunnel. While strictly speaking these attacks are outside the scope of L2TP security, in order to protect against them, the client SHOULD provide for confidentiality, authentication, replay and integrity protection for PPP packets sent over the dial-up link. Authentication, replay and integrity protection are not currently supported by PPP encryption methods, described in -. RFC 2406  and RFC 2402 ), including NULL encryption MUST be supported. Note that although an implementation MUST support all IPsec ciphersuites, it is an operator choice which ones will be used. If confidentiality is not required (e.g., L2TP data traffic), ESP with NULL encryption may be used. The implementations MUST implement replay protection mechanisms of IPsec. L2TP security MUST meet the key management requirements of the IPsec protocol suite. IKE SHOULD be supported for authentication, security association negotiation, and key management using the IPsec DOI . 1] is connection oriented, packet ordering is not mandatory,
which can create difficulties in implementation of stateful compression/encryption schemes. These considerations are not as important when L2TP is run over non-IP media such as IEEE 802, ATM, X.25, or Frame Relay, since these media guarantee ordering, and packet losses are typically low. 1] must be used. Once the L2TP tunnel is deleted by either peer, any phase 1 and phase 2 SA's which still exist as a result of the L2TP tunnel between the peers SHOULD be deleted. Phase 1 and phase 2 delete messages SHOULD be sent when this occurs. When IKE receives a phase 1 or phase 2 delete message, IKE should notify L2TP this event has occurred. If the L2TP state is such that a ZLB ack has been sent in response to a STOPCCN, this can be assumed to be positive acknowledgment that the peer received the ZLB ack and has performed a teardown of any L2TP tunnel state associated with the peer. The L2TP tunnel state and any associated filters can now be safely removed.
If an ICMP PMTU is received by IPsec, this value should be stored in the SA as proposed in . IPsec should also provide notification of this event to L2TP so that the new MTU value can be reflected into the PPP interface. Any new PTMU discoveries seen at the PPP interface should be checked against this new value and processed accordingly. 1] Check to ensure that the packet was decrypted and/or authenticated by IPsec. Since IPsec already verifies that the packet arrived in the correct SA, L2TP can be assured that the packet was indeed sent by a trusted peer and that it did not arrive in the clear.  Verify that the IP addresses and UDP port values in the packet match the socket information which was used to setup the L2TP tunnel. This step prevents malicious peers from spoofing packets into other tunnels. 1] states that implementations MAY use a dynamically assigned UDP source port. This port change is reflected in the SCCRP sent from the responder to the initiator. Although the current L2TP specification allows the responder to use a new IP address when sending the SCCRP, implementations requiring protection of L2TP via IPsec SHOULD NOT do this. To allow for this behavior when using L2TP and IPsec, when the responder chooses a new IP address it MUST send a StopCCN to the initiator, with the Result and Error Code AVP present. The Result Code MUST be set to 2 (General Error) and the Error Code SHOULD be set to 7 (Try Another). If the Error Code is set to 7, then the optional error message MUST be present and the contents MUST contain the IP address (ASCII encoded) that the Responder desires to use for subsequent communications. Only the ASCII encoded IP address should be present in the error message. The IP address is encoded in dotted decimal format for IPv4 or in RFC 2373  format for IPv6. The initiator MUST parse the result and error code information and send a new SCCRQ
to the new IP address contained in the error message. This approach reduces complexity since now the initiator always knows precisely the IP address of its peer. This also allows a controlled mechanism for L2TP to tie IPsec filters and policy to the same peer. The filtering details required to accommodate this behavior as well as other mechanisms needed to protect L2TP with IPsec are discussed in the following sections. 7], when using pre-shared key authentication, a key must be present for each peer to which secure communication is required. When using Main Mode (which provides identity protection), this key must correspond to the IP address for the peer. When using Aggressive Mode (which does not provide identity protection), the pre-shared key must map to one of the valid id types defined in the IPsec DOI . If the initiator receives a StopCCN with the result and error code AVP set to "try another" and a valid IP address is present in the message, it MAY bind the original pre-shared key used by IKE to the new IP address contained in the error-message. One may may wish to consider the implications for scalability of using pre-shared keys as the authentication method for phase 1. As the number of LAC and LNS endpoints grow, pre-shared keys become increasingly difficult to manage. Whenever possible, authentication with certificates is preferred.
Cases: +--------------------------------------------------+ | Initiator Port | Responder Addr | Responder Port | +--------------------------------------------------+ | 1701 | Fixed | 1701 | +--------------------------------------------------+ | 1701 | Fixed | Dynamic | +--------------------------------------------------+ | 1701 | Dynamic | 1701 | +--------------------------------------------------+ | 1701 | Dynamic | Dynamic | +--------------------------------------------------+ | Dynamic | Fixed | 1701 | +--------------------------------------------------+ | Dynamic | Fixed | Dynamic | +--------------------------------------------------+ | Dynamic | Dynamic | 1701 | +--------------------------------------------------+ | Dynamic | Dynamic | Dynamic | +--------------------------------------------------+ By solving the most general case of the above permutations, all cases are covered. The most general case is the last one in the list. This scenario is when the initiator chooses a new port number and the responder chooses a new address and port number. The L2TP message flow which occurs to setup this sequence is as follows: -> IKE Phase 1 and Phase 2 to protect Initial SCCRQ SCCRQ -> (Fixed IP address, Dynamic Initiator Port) <- STOPCCN (Responder chooses new IP address) -> New IKE Phase 1 and Phase 2 to protect new SCCRQ SCCRQ -> (SCCRQ to Responder's new IP address) <- New IKE Phase 2 to for port number change by the responder <- SCCRP (Responder chooses new port number) SCCCN -> (L2TP Tunnel Establishment completes) Although the Initiator and Responder typically do not dynamically change ports, L2TP security must accommodate emerging applications such as load balancing and QoS. This may require that the port and IP address float during L2TP tunnel establishment.
To support the general case, mechanisms must be designed into L2TP and IPsec which allow L2TP to inject filters into the IPsec filter database. This technique may be used by any application which floats ports and requires security via IPsec, and is described in the following sections. The responder is not required to support the ability to float its IP address and port. However, the initiator MUST allow the responder to float its port and SHOULD allow the responder to choose a new IP address (see section 4.2.3, below). Appendix A provides examples of these cases using the process described below.
IP Single address, an IP Netmask address with the Netmask set to 255.255.255.255, and IP address Range with the range being 1, or a hostname which can be resolved to one address. Refer to  for more information on the format for quick mode IDs. Any-Port The presence of Any-Port defines that IKE should accept a value of 0 or a specific port value for the port value in the port value in the quick mode IDs negotiated during IKE phase 2. The filters defined in the following sections are listed from highest priority to lowest priority.
If a phase 2 SA bundle is not already present to protect the SCCRQ, the sending of a SCCRQ by the initiator SHOULD cause IKE to setup the necessary SAs to protect this packet. Alternatively, L2TP may also request IKE to setup the SA bundle. If the SA cannot be setup for some reason, the packet MUST be dropped. The port numbers in the Quick Mode IDs sent by the initiator MUST contain the specific port numbers used to identify the UDP socket. The port numbers would be either I-Port/1701 or 1701/1701 for the initial SCCRQ. The quick mode IDs sent by the initiator will be a subset of the Inbound-1 filter at the responder. As a result, the quick mode exchange will finish and IKE should inject a specific filter set into the IPsec filter database and associate this filter set with the phase 2 SA established between the peers. These filters should persist as long as the L2TP tunnel exists. The new filter set at the responder will be: Responder Filters: Outbound-1: From R-IPAddr1, to I-IPAddr, UDP, src 1701, dst I-Port Inbound-1: From I-IPAddr, to R-IPAddr1, UDP, src I-Port, dst 1701 Inbound-2: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701 Mechanisms SHOULD exist between L2TP and IPsec such that L2TP is not retransmitting the SCCRQ while the SA is being established. L2TP's control channel retransmit mechanisms should start once the SA has been established. This will help avoid timeouts which may occur as the result of slow SA establishment. Once the phase 2 SA has been established between the peers, the SCCRQ should be sent from the initiator to the responder. If the responder does not choose a new IP address or a new port number, the L2TP tunnel can now proceed to establish.
Another). The optional error message MUST be present and the contents MUST contain the IP address (ASCII encoded) the Responder desires to use for subsequent communications. Only the ASCII encoded IP address should be present in the error message. The IP address is encoded in dotted decimal format for IPv4 or in RFC 2373  format for IPv6. The STOPCCN Message MUST be sent using the same address and UDP port information which the initiator used to send the SCCRQ. This message will be protecting using the initial SA bundle setup to protect the SCCRQ. Upon receiving the STOPCCN, the initiator MUST parse the IP address from the Result and Error Code AVP and perform the necessary sanity checks to verify this is a correctly formatted address. If no errors are found L2TP should inject a new set of filters into the IPsec filter database. If using pre-shared key authentication, L2TP MAY request IKE to bind the new IP address to the pre-shared key which was used for the original IP address. Since the IP address of the responder changed, a new phase 1 and phase 2 SA must be established between the peers before the new SCCRQ is sent. Assuming the initial tunnel has been torn down and the filters needed to create the tunnel removed, the new filters for the initiator and responder will be: Initiator Filters: Outbound-1: From I-IPAddr, to R-IPAddr2, UDP, src I-Port, dst 1701 Inbound-1: From R-IPAddr2, to I-IPAddr, UDP, src 1701, dst I-Port Inbound-2: From R-IPAddr2, to I-IPAddr, UDP, src Any-Port, dst I-Port Once IKE phase 2 completes, the new filter set at the responder will be: Responder Filters: Outbound-1: From R-IPAddr2, to I-IPAddr, UDP, src 1701, dst I-Port Inbound-1: From I-IPAddr, to R-IPAddr2, UDP, src I-Port, dst 1701 Inbound-2: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701
If the responder chooses not to move to a new port number, the L2TP tunnel setup can now complete.
If the IPsec implementation supports user authentication, this problem can be averted. In this case, the user identity asserted within IKE will be verified on a per-packet basis. In order to provide segregation of traffic between users when user authentication is used, the client MUST ensure that only traffic from that particular user is sent down the L2TP tunnel.
within PPP (keeping in mind the weaknesses described earlier), support for machine authentication in IPsec makes it is possible to authenticate both the machine as well as the user. In circumstances in which this dual assurance is considered valuable, enabling movement of the machine certificate from one machine to another, as would be possible if the machine certificate were stored on a smart card, may be undesirable. Similarly, when user certificate are deployed, it is advisable for the user enrollment process to be strictly controlled. If for example, a user password can be readily used to obtain a certificate (either a temporary or a longer term one), then that certificate has no more security value than the password. To limit the ability of an attacker to obtain a user certificate from a stolen password, the enrollment period can be limited, after which password access will be turned off. Such a policy will prevent an attacker obtaining the password of an unused account from obtaining a user certificate once the enrollment period has expired.
to successfully masquerade as the LNS and mount a dictionary attack on legacy authentication methods such as CHAP . Such an attack could potentially compromise many passwords at a time. This vulnerability is present in some existing IPsec tunnel mode implementations. To avoid this problem, L2TP/IPsec implementations SHOULD NOT use a group pre-shared key for IKE authentication to the LNS. IKE pre- shared authentication key values SHOULD be protected in a manner similar to the user's account password used by L2TP. 10] and CCP  negotiation. Let us assume that LNS confidentiality policy can be described by one of the following terms: "Require Encryption," "Allow Encryption" or "Prohibit Encryption." If IPsec confidentiality services are in place, then an LNS implementing a "Prohibit Encryption" policy will
act as though the policy had been violated. Similarly, an LNS implementing a "Require Encryption" or "Allow Encryption" policy will act as though these policies were satisfied, and would not mandate use of PPP encryption or compression. This is not the same as insisting that PPP encryption and compression be turned off, since this decision will depend on client policy. Since the client has no knowledge of the security services in place between the LAC and the LNS, and since it may not trust the LAC or the wire between itself and the LAC, the client will typically want to ensure sufficient security through use of end-to-end IPsec or PPP encryption/compression between itself and the LNS. A client wishing to ensure security services over the entire travel path would not modify this behavior even if it had knowledge of the security services in place between the LAC and the LNS. The client negotiates confidentiality services between itself and the LNS in order to provide privacy on the wire between itself and the LAC. The client negotiates end-to-end security between itself and the end- station in order to ensure confidentiality on the portion of the path between the LNS and the end-station. The client will typically not trust the LAC and will negotiate confidentiality and compression services on its own. As a result, the LAC may only wish to negotiate IPsec ESP with null encryption with the LNS, and the LNS will request replay protection. This will ensure that confidentiality and compression services will not be duplicated over the path between the LAC and the LNS. This results in better scalability for the LAC, since encryption will be handled by the client and the LNS. The client can satisfy its desire for confidentiality services in one of two ways. If it knows that all end-stations that it will communicate with are IPsec-capable (or if it refuses to talk to non- IPsec capable end-stations), then it can refuse to negotiate PPP encryption/compression and negotiate IPsec ESP with the end-stations instead. If the client does not know that all end-stations it will contact are IPsec capable (the most likely case), then it will negotiate PPP encryption/compression. This may result in duplicate compression/encryption which can only be eliminated if PPP compression/encryption can be turned off on a per-packet basis. Note that since the LNS knows that the client's packets are being tunneled but the client does not, the LNS can ensure that stateless compression/encryption is used by offering stateless compression/encryption methods if available in the ECP and CCP negotiations.
Security Associations with the LNS, one with ESP with null encryption, and one with confidentiality/compression. Packets going to an IPsec- capable end-station would run over the ESP with null encryption security association, and packets to a non-IPsec capable end-station would run over the other security association. Note that many IPsec implementations cannot support this without allowing L2TP packets on the same tunnel to be originated from multiple UDP ports. This requires modifications to the L2TP specification. Also note that the client may wish to put confidentiality services in place for non-tunneled packets traveling between itself and the NAS. This will protect the client against eavesdropping on the wire between itself and the NAS. As a result, it may wish to negotiate PPP encryption and compression with the NAS. As in compulsory tunneling, this will result in duplicate encryption and possibly compression unless PPP compression/encryption can be turned off on a per-packet basis.  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.  Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.  Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.  Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.  Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.  Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
 Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.  Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol (DESE)", RFC 1969, June 1996.  Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.  Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998.  Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996.  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)," RFC 2284, March 1998.  Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. Acknowledgments Thanks to Gurdeep Singh Pall, David Eitelbach, Peter Ford, and Sanjay Anand of Microsoft, John Richardson of Intel and Rob Adams of Cisco for useful discussions of this problem space.
Authors' Addresses Baiju V. Patel Intel Corp 2511 NE 25th Ave Hillsboro, OR 97124 Phone: +1 503 702 2303 EMail: email@example.com Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 706-6605 EMail: firstname.lastname@example.org William Dixon Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 703 8729 EMail: email@example.com Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004 Phone: +1 425 438 8218 Fax: +1 425 438 1848 EMail: firstname.lastname@example.org Skip Booth Cisco Systems 7025 Kit Creek Road RTP, NC 27709 Phone: +1 919 392 6951 EMail: email@example.com
After IKE Phase 2 completes the filters at the initiator and responder will be: Initiator Filters: Outbound-1: From 22.214.171.124, to 126.96.36.199, UDP, src 5000, dst 1701 Inbound-1: From 188.8.131.52, to 184.108.40.206, UDP, src 1701, dst 5000 Inbound-2: From 220.127.116.11, to 18.104.22.168, UDP, src Any-Port, dst 5000 Inbound-3: From Any-Addr, to 22.214.171.124, UDP, src Any-Port, dst 1701 Responder Filters: Outbound-1: From 126.96.36.199, to 188.8.131.52, UDP, src 1701, dst 5000 Inbound-1: From 184.108.40.206, to 220.127.116.11, UDP, src 5000, dst 1701 Inbound-2: From Any-Addr, to 18.104.22.168, UDP, src Any-Port, dst 1701
Responder Filters: Outbound-1: From 22.214.171.124, to 126.96.36.199, UDP, src 6000, dst 5000 Outbound-2: From 188.8.131.52, to 184.108.40.206, UDP, src 1701, dst 5000 Inbound-1: From 220.127.116.11, to 18.104.22.168, UDP, src 5000, dst 6000 Inbound-2: From 22.214.171.124, to 126.96.36.199, UDP, src 5000, dst 1701 Inbound-3: From Any-Addr, to 188.8.131.52, UDP, src Any-Port, dst 1701 Once the L2TP tunnel has been successfully established, the original phase 2 may be deleted. This allows the Inbound-2 and Outbound-2 filter statements to be removed as well. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.