RFC 3931
Layer Two Tunneling Protocol - Version 3 (L2TPv3)
8. Security Considerations
This section addresses some of the security issues that L2TP encounters in its operation.8.1. Control Connection Endpoint and Message Security
If a shared secret (password) exists between two LCCEs, it may be used to perform a mutual authentication between the two LCCEs, and construct an authentication and integrity check of arriving L2TP control messages. The mechanism provided by L2TPv3 is described in Section 4.3 and in the definition of the Message Digest and Control Message Authentication Nonce AVPs in Section 5.4.1. This control message security mechanism provides for (1) mutual endpoint authentication, and (2) individual control message integrity and authenticity checking. Mutual endpoint authentication ensures that an L2TPv3 control connection is only established between two endpoints that are configured with the proper password. The individual control message and integrity check guards against accidental or intentional packet corruption (i.e., those caused by a control message spoofing or man-in-the-middle attack). The shared secret that is used for all control connection, control message, and AVP security features defined in this document never needs to be sent in the clear between L2TP tunnel endpoints.8.2. Data Packet Spoofing
Packet spoofing for any type of Virtual Private Network (VPN) protocol is of particular concern as insertion of carefully constructed rogue packets into the VPN transit network could result in a violation of VPN traffic separation, leaking data into a customer VPN. This is complicated by the fact that it may be particularly difficult for the operator of the VPN to even be aware that it has become a point of transit into or between customer VPNs. L2TPv3 provides traffic separation for its VPNs via a 32-bit Session ID in the L2TPv3 data header. When present, the L2TPv3 Cookie (described in Section 4.1), provides an additional check to ensure that an arriving packet is intended for the identified session. Thus, use of a Cookie with the Session ID provides an extra guarantee that the Session ID lookup was performed properly and that the Session ID itself was not corrupted in transit.
In the presence of a blind packet spoofing attack, the Cookie may also provide security against inadvertent leaking of frames into a customer VPN. To illustrate the type of security that it is provided in this case, consider comparing the validation of a 64-bit Cookie in the L2TPv3 header to the admission of packets that match a given source and destination IP address pair. Both the source and destination IP address pair validation and Cookie validation consist of a fast check on cleartext header information on all arriving packets. However, since L2TPv3 uses its own value, it removes the requirement for one to maintain a list of (potentially several) permitted or denied IP addresses, and moreover, to guard knowledge of the permitted IP addresses from hackers who may obtain and spoof them. Further, it is far easier to change a compromised L2TPv3 Cookie than a compromised IP address," and a cryptographically random [RFC1750] value is far less likely to be discovered by brute-force attacks compared to an IP address. For protection against brute-force, blind, insertion attacks, a 64- bit Cookie MUST be used with all sessions. A 32-bit Cookie is vulnerable to brute-force guessing at high packet rates, and as such, should not be considered an effective barrier to blind insertion attacks (though it is still useful as an additional verification of a successful Session ID lookup). The Cookie provides no protection against a sophisticated man-in-the-middle attacker who can sniff and correlate captured data between nodes for use in a coordinated attack. The Assigned Cookie AVP is used to signal the value and size of the Cookie that must be present in all data packets for a given session. Each Assigned Cookie MUST be selected in a cryptographically random manner [RFC1750] such that a series of Assigned Cookies does not provide any indication of what a future Cookie will be. The L2TPv3 Cookie must not be regarded as a substitute for security such as that provided by IPsec when operating over an open or untrusted network where packets may be sniffed, decoded, and correlated for use in a coordinated attack. See Section 4.1.3 for more information on running L2TP over IPsec.9. Internationalization Considerations
The Host Name and Vendor Name AVPs are not internationalized. The Vendor Name AVP, although intended to be human-readable, would seem to fit in the category of "globally visible names" [RFC2277] and so is represented in US-ASCII. If (1) an LCCE does not signify a language preference by the inclusion of a Preferred Language AVP (see Section 5.4.3) in the
SCCRQ or SCCRP, (2) the Preferred Language AVP is unrecognized, or (3) the requested language is not supported by the peer LCCE, the default language [RFC2277] MUST be used for all internationalized strings sent by the peer.10. IANA Considerations
This document defines a number of "magic" numbers to be maintained by the IANA. This section explains the criteria used by the IANA to assign additional numbers in each of these lists. The following subsections describe the assignment policy for the namespaces defined elsewhere in this document. Sections 10.1 through 10.3 are requests for new values already managed by IANA according to [RFC3438]. The remaining sections are for new registries that have been added to the existing L2TP registry and are maintained by IANA accordingly.10.1. Control Message Attribute Value Pairs (AVPs)
This number space is managed by IANA as per [RFC3438]. A summary of the new AVPs follows: Control Message Attribute Value Pairs Attribute Type Description --------- ------------------ 58 Extended Vendor ID AVP 59 Message Digest 60 Router ID 61 Assigned Control Connection ID 62 Pseudowire Capabilities List 63 Local Session ID 64 Remote Session ID 65 Assigned Cookie 66 Remote End ID 68 Pseudowire Type 69 L2-Specific Sublayer 70 Data Sequencing 71 Circuit Status 72 Preferred Language 73 Control Message Authentication Nonce 74 Tx Connect Speed 75 Rx Connect Speed
10.2. Message Type AVP Values
This number space is managed by IANA as per [RFC3438]. There is one new message type, defined in Section 3.1, that was allocated for this specification: Message Type AVP (Attribute Type 0) Values ------------------------------------------ Control Connection Management 20 (ACK) Explicit Acknowledgement10.3. Result Code AVP Values
This number space is managed by IANA as per [RFC3438]. New Result Code values for the CDN message are defined in Section 5.4. The following is a summary: Result Code AVP (Attribute Type 1) Values ----------------------------------------- General Error Codes 13 - Session not established due to losing tie breaker (L2TPv3). 14 - Session not established due to unsupported PW type (L2TPv3). 15 - Session not established, sequencing required without valid L2-Specific Sublayer (L2TPv3). 16 - Finite state machine error or timeout.
10.4. AVP Header Bits
This is a new registry for IANA to maintain. Leading Bits of the L2TP AVP Header ----------------------------------- There six bits at the beginning of the L2TP AVP header. New bits are assigned via Standards Action [RFC2434]. Bit 0 - Mandatory (M bit) Bit 1 - Hidden (H bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved10.5. L2TP Control Message Header Bits
This is a new registry for IANA to maintain. Leading Bits of the L2TP Control Message Header ----------------------------------------------- There are 12 bits at the beginning of the L2TP Control Message Header. Reserved bits should only be defined by Standard Action [RFC2434]. Bit 0 - Message Type (T bit) Bit 1 - Length Field is Present (L bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Sequence Numbers Present (S bit) Bit 5 - Reserved Bit 6 - Offset Field is Present [RFC2661] Bit 7 - Priority Bit (P bit) [RFC2661] Bit 8 - Reserved Bit 9 - Reserved Bit 10 - Reserved Bit 11 - Reserved
10.6. Pseudowire Types
This is a new registry for IANA to maintain, there are no values assigned within this document to maintain. L2TPv3 Pseudowire Types ----------------------- The Pseudowire Type (PW Type, see Section 5.4) is a 2-octet value used in the Pseudowire Type AVP and Pseudowire Capabilities List AVP defined in Section 5.4.3. 0 to 32767 are assignable by Expert Review [RFC2434], while 32768 to 65535 are assigned by a First Come First Served policy [RFC2434]. There are no specific pseudowire types assigned within this document. Each pseudowire-specific document must allocate its own PW types from IANA as necessary.10.7. Circuit Status Bits
This is a new registry for IANA to maintain. Circuit Status Bits ------------------- The Circuit Status field is a 16-bit mask, with the two low order bits assigned. Additional bits may be assigned by IETF Consensus [RFC2434]. Bit 14 - New (N bit) Bit 15 - Active (A bit)
10.8. Default L2-Specific Sublayer bits
This is a new registry for IANA to maintain. Default L2-Specific Sublayer Bits --------------------------------- The Default L2-Specific Sublayer contains 8 bits in the low-order portion of the header. Reserved bits may be assigned by IETF Consensus [RFC2434]. Bit 0 - Reserved Bit 1 - Sequence (S bit) Bit 2 - Reserved Bit 3 - Reserved Bit 4 - Reserved Bit 5 - Reserved Bit 6 - Reserved Bit 7 - Reserved10.9. L2-Specific Sublayer Type
This is a new registry for IANA to maintain. L2-Specific Sublayer Type ------------------------- The L2-Specific Sublayer Type is a 2-octet unsigned integer. Additional values may be assigned by Expert Review [RFC2434]. 0 - No L2-Specific Sublayer 1 - Default L2-Specific Sublayer present10.10. Data Sequencing Level
This is a new registry for IANA to maintain. Data Sequencing Level --------------------- The Data Sequencing Level is a 2-octet unsigned integer Additional values may be assigned by Expert Review [RFC2434]. 0 - No incoming data packets require sequencing. 1 - Only non-IP data packets require sequencing. 2 - All incoming data packets require sequencing.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and Palter, B., "Layer Two Tunneling Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and Booth, S., "Securing L2TP using IPsec", RFC 3193, November 2001. [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.11.2. Informative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC 1700, October 1994. [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC1981] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997. [RFC2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2341] Valencia, A., Littlewood, M., and Kolar, T., "Cisco Layer Two Forwarding (Protocol) L2F", RFC 2341, May 1998. [RFC2401] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2581] Allman, M., Paxson, V., and Stevens, W., "TCP Congestion Control", RFC 2581, April 1999. [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999. [RFC2732] Hinden, R., Carpenter, B., and Masinter, L., "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. [RFC2809] Aboba, B. and Zorn, G., "Implementation of L2TP Compulsory Tunneling via RADIUS", RFC 2809, April 2000. [RFC3070] Rawat, V., Tio, R., Nanji, S., and Verma, R., "Layer Two Tunneling Protocol (L2TP) over Frame Relay", RFC 3070, February 2001.
[RFC3355] Singh, A., Turner, R., Tio, R., and Nanji, S., "Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)", RFC 3355, August 2002. [KPS] Kaufman, C., Perlman, R., and Speciner, M., "Network Security: Private Communications in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1. [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I: The Protocols", Addison-Wesley Publishing Company, Inc., March 1996, ISBN 0-201-63346-9.12. Acknowledgments
Many of the protocol constructs were originally defined in, and the text of this document began with, RFC 2661, "L2TPv2". RFC 2661 authors are W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn and B. Palter. The basic concept for L2TP and many of its protocol constructs were adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of these versions are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. Danny Mcpherson and Suhail Nanji published the first "L2TP Service Type" version, which defined the use of L2TP for tunneling of various L2 payload types (initially, Ethernet and Frame Relay). The team for splitting RFC 2661 into this base document and the companion PPP document consisted of Ignacio Goyret, Jed Lau, Bill Palter, Mark Townsley, and Madhvi Verma. Skip Booth also provided very helpful review and comment. Some constructs of L2TPv3 were based in part on UTI (Universal Transport Interface), which was originally conceived by Peter Lothberg and Tony Bates. Stewart Bryant and Simon Barber provided valuable input for the L2TPv3 over IP header. Juha Heinanen provided helpful review in the early stages of this effort. Jan Vilhuber, Scott Fluhrer, David McGrew, Scott Wainner, Skip Booth and Maria Dos Santos contributed to the Control Message Authentication Mechanism as well as general discussions of security.
James Carlson, Thomas Narten, Maria Dos Santos, Steven Bellovin, Ted Hardie, and Pekka Savola provided very helpful review of the final versions of text. Russ Housley provided valuable review and comment on security, particularly with respect to the Control Message Authentication mechanism. Pekka Savola contributed to proper alignment with IPv6 and inspired much of Section 4.1.4 on fragmentation. Aside of his original influence and co-authorship of RFC 2661, Glen Zorn helped get all of the language and character references straight in this document. A number of people provided valuable input and effort for RFC 2661, on which this document was based: John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and review at the 43rd IETF in Orlando, FL, which led to improvement of the overall readability and clarity of RFC 2661. Thomas Narten provided a great deal of critical review and formatting. He wrote the first version of the IANA Considerations section. Dory Leifer made valuable refinements to the protocol definition of L2TP and contributed to the editing of early versions leading to RFC 2661. Steve Cobb and Evan Caves redesigned the state machine tables. Barney Wolff provided a great deal of design input on the original endpoint authentication mechanism.
Appendix A: Control Slow Start and Congestion Avoidance
Although each side has indicated the maximum size of its receive window, it is recommended that a slow start and congestion avoidance method be used to transmit control packets. The methods described here are based upon the TCP congestion avoidance algorithm as described in Section 21.6 of TCP/IP Illustrated, Volume I, by W. Richard Stevens [STEVENS] (this algorithm is also described in [RFC2581]). Slow start and congestion avoidance make use of several variables. The congestion window (CWND) defines the number of packets a sender may send before waiting for an acknowledgment. The size of CWND expands and contracts as described below. Note, however, that CWND is never allowed to exceed the size of the advertised window obtained from the Receive Window AVP. (In the text below, it is assumed any increase will be limited by the Receive Window Size.) The variable SSTHRESH determines when the sender switches from slow start to congestion avoidance. Slow start is used while CWND is less than SSHTRESH. A sender starts out in the slow start phase. CWND is initialized to one packet, and SSHTRESH is initialized to the advertised window (obtained from the Receive Window AVP). The sender then transmits one packet and waits for its acknowledgment (either explicit or piggybacked). When the acknowledgment is received, the congestion window is incremented from one to two. During slow start, CWND is increased by one packet each time an ACK (explicit ACK message or piggybacked) is received. Increasing CWND by one on each ACK has the effect of doubling CWND with each round trip, resulting in an exponential increase. When the value of CWND reaches SSHTRESH, the slow start phase ends and the congestion avoidance phase begins. During congestion avoidance, CWND expands more slowly. Specifically, it increases by 1/CWND for every new ACK received. That is, CWND is increased by one packet after CWND new ACKs have been received. Window expansion during the congestion avoidance phase is effectively linear, with CWND increasing by one packet each round trip. When congestion occurs (indicated by the triggering of a retransmission) one-half of the CWND is saved in SSTHRESH, and CWND is set to one. The sender then reenters the slow start phase.
Appendix B: Control Message Examples
B.1: Lock-Step Control Connection Establishment
In this example, an LCCE establishes a control connection, with the exchange involving each side alternating in sending messages. This example shows the final acknowledgment explicitly sent within an ACK message. An alternative would be to piggyback the acknowledgment within a message sent as a reply to the ICRQ or OCRQ that will likely follow from the side that initiated the control connection. LCCE A LCCE B ------ ------ SCCRQ -> Nr: 0, Ns: 0 <- SCCRP Nr: 1, Ns: 0 SCCCN -> Nr: 1, Ns: 1 <- ACK Nr: 2, Ns: 1B.2: Lost Packet with Retransmission
An existing control connection has a new session requested by LCCE A. The ICRP is lost and must be retransmitted by LCCE B. Note that loss of the ICRP has two effects: It not only keeps the upper level state machine from progressing, but also keeps LCCE A from seeing a timely lower level acknowledgment of its ICRQ. LCCE A LCCE B ------ ------ ICRQ -> Nr: 1, Ns: 2 (packet lost) <- ICRP Nr: 3, Ns: 1 (pause; LCCE A's timer started first, so fires first) ICRQ -> Nr: 1, Ns: 2 (Realizing that it has already seen this packet, LCCE B discards the packet and sends an ACK message) <- ACK Nr: 3, Ns: 2
(LCCE B's retransmit timer fires)
<- ICRP
Nr: 3, Ns: 1
ICCN ->
Nr: 2, Ns: 3
<- ACK
Nr: 4, Ns: 2
Appendix C: Processing Sequence Numbers
The Default L2-Specific Sublayer, defined in Section 4.6, provides a
24-bit field for sequencing of data packets within an L2TP session.
L2TP data packets are never retransmitted, so this sequence is used
only to detect packet order, duplicate packets, or lost packets.
The 24-bit Sequence Number field of the Default L2-Specific Sublayer
contains a packet sequence number for the associated session. Each
sequenced data packet that is sent must contain the sequence number,
incremented by one, of the previous sequenced packet sent on a given
L2TP session. Upon receipt, any packet with a sequence number equal
to or greater than the current expected packet (the last received
in-order packet plus one) should be considered "new" and accepted.
All other packets are considered "old" or "duplicate" and discarded.
Note that the 24-bit sequence number space includes zero as a valid
sequence number (as such, it may be implemented with a masked 32-bit
counter if desired). All new sessions MUST begin sending sequence
numbers at zero.
Larger or smaller sequence number fields are possible with L2TP if an
alternative format to the Default L2-Specific Sublayer defined in
this document is used. While 24 bits may be adequate in a number of
circumstances, a larger sequence number space will be less
susceptible to sequence number wrapping problems for very high
session data rates across long dropout periods. The sequence number
processing recommendations below should hold for any size sequence
number field.
When detecting whether a packet sequence number is "greater" or
"less" than a given sequence number value, wrapping of the sequence
number must be considered. This is typically accomplished by keeping
a window of sequence numbers beyond the current expected sequence
number for determination of whether a packet is "new" or not. The
window may be sized based on the link speed and sequence number space
and SHOULD be configurable with a default equal to one half the size
of the available number space (e.g., 2^(n-1), where n is the number
of bits available in the sequence number).
Upon receipt, packets that exactly match the expected sequence number are processed immediately and the next expected sequence number incremented. Packets that fall within the window for new packets may either be processed immediately and the next expected sequence number updated to one plus that received in the new packet, or held for a very short period of time in hopes of receiving the missing packet(s). This "very short period" should be configurable, with a default corresponding to a time lapse that is at least an order of magnitude less than the retransmission timeout periods of higher layer protocols such as TCP. For typical transient packet mis-orderings, dropping out-of-order packets alone should suffice and generally requires far less resources than actively reordering packets within L2TP. An exception is a case in which a pair of packet fragments are persistently retransmitted and sent out-of-order. For example, if an IP packet has been fragmented into a very small packet followed by a very large packet before being tunneled by L2TP, it is possible (though admittedly wrong) that the two resulting L2TP packets may be consistently mis-ordered by the PSN in transit between L2TP nodes. If sequence numbers were being enforced at the receiving node without any buffering of out-of-order packets, then the fragmented IP packet may never reach its destination. It may be worth noting here that this condition is true for any tunneling mechanism of IP packets that includes sequence number checking on receipt (i.e., GRE [RFC2890]). Utilization of a Data Sequencing Level (see Section 5.4.3) of 1 (only non-IP data packets require sequencing) allows IP data packets being tunneled by L2TP to not utilize sequence numbers, while utilizing sequence numbers and enforcing packet order for any remaining non-IP data packets. Depending on the requirements of the link layer being tunneled and the network data traversing the data link, this is sufficient in many cases to enforce packet order on frames that require it (such as end-to-end data link control messages), while not on IP packets that are known to be resilient to packet reordering. If a large number of packets (i.e., more than one new packet window) are dropped due to an extended outage or loss of sequence number state on one side of the connection (perhaps as part of a forwarding plane reset or failover to a standby node), it is possible that a large number of packets will be sent in-order, but be wrongly detected by the peer as out-of-order. This can be generally characterized for a window size, w, sequence number space, s, and number of packets lost in transit between L2TP endpoints, p, as follows:
If s > p > w, then an additional (s - p) packets that were otherwise received in-order, will be incorrectly classified as out-of-order and dropped. Thus, for a sequence number space, s = 128, window size, w = 64, and number of lost packets, p = 70; 128 - 70 = 58 additional packets would be dropped after the outage until the sequence number wrapped back to the current expected next sequence number. To mitigate this additional packet loss, one MUST inspect the sequence numbers of packets dropped due to being classified as "old" and reset the expected sequence number accordingly. This may be accomplished by counting the number of "old" packets dropped that were in sequence among themselves and, upon reaching a threshold, resetting the next expected sequence number to that seen in the arriving data packets. Packet timestamps may also be used as an indicator to reset the expected sequence number by detecting a period of time over which "old" packets have been received in-sequence. The ideal thresholds will vary depending on link speed, sequence number space, and link tolerance to out-of-order packets, and MUST be configurable.Editors' Addresses
Jed Lau cisco Systems 170 W. Tasman Drive San Jose, CA 95134 EMail: jedlau@cisco.com W. Mark Townsley cisco Systems EMail: mark@townsley.net Ignacio Goyret Lucent Technologies EMail: igoyret@lucent.com
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.