Internet Engineering Task Force S. Blake Internet-Draft Extreme Networks Intended status: Standards Track October 27, 2008 Expires: April 30, 2009 Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks draft-blake-ipv6-flow-label-nonce-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 30, 2009. Abstract TCP and other transport-layer protocols are vulnerable to spoofing attacks from off-path hosts. These attacks can be prevented through the use of cryptographic authentication. However, it is difficult to use cryptographic authentication in all circumstances. A variety of obfuscation techniques -- such as initial sequence number randomization and source port randomization -- increase the effort required of an attacker to successfully spoof the packet header fields which uniquely identify a transport connection. This memo proposes the use of the IPv6 Flow Label field as a random, per- connection nonce value, to add entropy to the set of packet header fields used to identify a transport connection. This mechanism is Blake Expires April 30, 2009 [Page 1] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 easily implementable, allows for incremental deployment, and is fully compliant with the rules for Flow Label use defined in RFC 3697. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Additional Requirements on Flow Label Value Generation and Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. TCP Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. UDP Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. DCCP Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Blake Expires April 30, 2009 [Page 2] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 1. Introduction Recent effort has been directed towards identifying and reducing the vulnerability of TCP [RFC0793] to a variety of "blind" spoofed packet injection attacks from hosts that are off-path (i.e., not able to intercept communications between a pair of hosts) [RFC4953][RFC5082] [I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-tcpsecure] [I-D.ietf-tsvwg-port-randomization]. Off-path spoofing attacks against TCP require an attacker to correctly guess the 4-tuple of header fields uniquely identifying a TCP connection, along with a valid (in-receive window) value for the 32-bit TCP sequence number. By correctly guessing values for these fields, an attacker is then able to inject ACK, DATA, RST, of SYN segments into a TCP connection, enabling throughput reduction, data corruption, or connection termination. Similarly, by correctly guessing values for these fields, an attacker is able to forge ICMP messages to a sender, with similar negative consequences [I-D.ietf-tcpm-icmp-attacks]. Increased use of long-duration connections by applications, as well as faster access link speeds, increase the ability of attackers to transmit a sufficient number of spoof packets to successfully attack a connection, especially when either the destination or source ports are easily guessable. Cryptographic authentication mechanisms such as the TCP MD5 Authentication Option [RFC2385], TCP Authentication Option [I-D.ietf-tcpm-tcp-auth-opt], and IPsec [RFC4301] can secure against these attacks, as well as some on-path (man-in-the-middle) attacks. However, key management and computational overhead makes the deployment of cryptographic authentication prohibitively expensive in some environments and applications. Obfuscation techniques can be employed to increase the effort required of an attacker. Initial sequence number randomization [RFC1948] [I-D.ietf-tcpm-tcpsecure] can be implemented by both the client (the host initiating a connection) and server. For typical window sizes of approximately 32 Kbytes, this technique forces an attacker to send approximately 57000 RST packets on average to reset a connection [RFC4953]. Source port randomization [I-D.ietf-tsvwg-port-randomization] can also be implemented by a client to increase the number of guesses an attacker must make to successfully attack a connection. This mechanism can provide an additional ~15 bits of entropy (depending on implementation). Source port randomization can also be used with other transport protocols. Both obfuscation schemes are compliant with [RFC0793], and are incrementally deployable. Both schemes used in combination introduce somewhat less than 32 bits of entropy (~16 + ~15). However, as access link speeds (and consequently, receive windows) increase in Blake Expires April 30, 2009 [Page 3] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 size, the amount of entropy declines just as the number of spoof packets an attacker can generate in a given interval increases. [I-D.weaver-dnsext-comprehensive-resolver] argues that 40 bits of entropy is desirable to make off-path spoofing attacks impractical. IPv6 [RFC2460] includes a 20-bit Flow Label field, which can be used by hosts to uniquely label a sequence of packets from a host to a particular unicast, anycast, or multicast destination. The tuple of uniquely identify a particular flow during its lifetime plus a subsequent quarantine period. Rules for the generation and usage of Flow Label values are defined in [RFC3697]. Because transport-layer port fields may be located at a variable offset within a packet due to IPv6 extension headers, or may be obscured due to encryption, the Flow Label provides a common field in the IPv6 header to facilitate flow classification in routers. While originally intended to facilitate flow-specific packet handling in routers (e.g., QoS, fast switching), the Flow Label can also be used by hosts to uniquely label one or more transport connections. An originating host can select a random Flow Label value at the beginning of a connection, and continue to use it for the connection's duration. The host (or hosts for multicast) at the other end of the connection can record this Flow Label value, and use it as part of the connection demultiplexing key, while also labeling response packets with the same or different Flow Label value. The originating host can similarly record the Flow Label value in response packets, and use it as part of its connection demultiplexing key. In this way an additional 20 bits of entropy is added to the set of header fields used to identify a transport connection. When used in addition to source port randomization, the total amount of entropy is approximately 34-35 bits. When initial sequence number randomization is also used (i.e., in TCP), the entropy is increased to > 40 bits, making off-path snooping attacks impractical. The concept of labeling transport connections to prevent off-path spoofing attacks was proposed in [McGann05], in the context of stateful firewalls. This scheme may be useful for other transport protocols such as SCTP [RFC4960], UDP [RFC0768], UDP-Lite [RFC3828], DCCP [RFC4340], and RTP [RFC3550]. Host implementations in compliance with [RFC3697] which do not allocate multiple flows to a single transport connection, will either label all packets in the connection with a Flow Label value of 0, or some other constant. Therefore, this scheme is incrementally deployable by either peer in a connection. Section 3 talks about additional requirements on Flow Label generation. Section 4 talks about the use of this scheme with TCP. Blake Expires April 30, 2009 [Page 4] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 Section 6 talks about the use of this scheme with SCTP. Section 5 talks about the use of this scheme with UDP and UDP-Lite. Section 7 talks about the use of this scheme with DCCP. Section 8 talks about the use of this scheme with RTP over UDP or DCCP. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Additional Requirements on Flow Label Value Generation and Use [RFC3697] specifies the rules governing use of the IPv6 Flow Label. The primary requirements relevant to our purpose are as follows (quoting directly): o The Flow Label value set by the source MUST be delivered unchanged to the destination node(s). o To enable Flow Label based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow. o The source node SHOULD be able to select unused Flow Label values for flows not requesting a specific value to be used. o A source node MUST ensure that it does not unintentionally reuse Flow Label values it is currently using or has recently used when creating new flows. o Flow Label values previously used with a specific pair of source and destination addresses MUST NOT be assigned to new flows with the same address pair within 120 seconds of the termination of the previous flow. o The source node SHOULD provide the means for the applications and transport protocols to specify quarantine periods longer than the default 120 seconds for individual flows. o To avoid accidental Flow Label value reuse, the source node SHOULD select the new Flow Label value in a well-defined sequence, (e.g., sequential or pseudo-random) and use an initial value that avoids reuse of recently used Flow Label values each time the system restarts. The initial value SHOULD be derived from a previous value stored in non-volatile memory, or in the absence of such Blake Expires April 30, 2009 [Page 5] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 history, a randomly generated initial value using techniques that produce good randomness properties SHOULD be used. We wish to use the Flow Label value as an unguessable nonce. Hence, the following additional requirements are implied: o Source hosts MUST assign each unrelated transport connection and application data stream to a new flow. o Source hosts MUST be able to select unused Flow Label values for flows not requesting a specific value to be used. The selected Flow Label value must remain constant for the duration of the flow. o The Flow Label value MUST be practically unguessable, in a manner similar to the TCP source port or initial sequence number when they are randomized. A random number generator with good randomness properties (i.e., uniformly distributed) as specified in [RFC4086] MUST be used to generate Flow Label values not explicitly requested by an application. o Flow Label state for a transport connection or application data stream must be cleaned-up by the destination host(s) as part of the transport connection/application data stream state clean-up. o Flow Label values previously used with a specific pair of source and destination addresses MUST NOT be assigned to new flows with the same address pair within X seconds of the termination of the previous flow, where X is the maximum of either 120 seconds, or the duration for which transport connection state might linger at a destination host after traffic flow has ceased (e.g., TIME-WAIT state in TCP). For this application of the Flow Label field, it would not pose a problem if multiple flows from a source host in unrelated transport connections/application data streams coincidentally shared the same Flow Label value, as long as the other previous requirements are adhered to. However, the prohibition in [RFC3697] against simultaneous reuse of Flow Label values MUST be observed. Transport-specific requirements on Flow Label use are provided in the subsequent sections. However, as a general requirement, if a packet is received on a transport connection/application data stream with an unexpected Flow Label value, the packet MUST be silently discarded. If excessive Flow Label errors are received, the event SHOULD be logged. ICMPv6 error messages contain the IPv6 header of the packet Blake Expires April 30, 2009 [Page 6] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 triggering the error [RFC4443]. A host receiving an ICMPv6 error message can validate the Flow Label value in the message payload to protect against ICMPv6 spoofing attacks [I-D.ietf-tcpm-icmp-attacks]. Use of the Flow Label value as an unguessable nonce is incrementally deployable, whether a source host fails to support setting the Flow Label to a non-zero value, or a destination host fails to check its value. However, a Flow Label value of 0 is easily guessable, so resistance to spoofing attacks is not improved. Hosts SHOULD NOT rely on the mechanisms defined in this document when operating in high-threat environments. The additional requirements given here for Flow Label generation and use are not in conflict with the requirements in [RFC3697]. Therefore, additional applications of the Flow Label field (e.g., special QoS handling) can be applied simultaneously with the use of the Flow Label field as a transport-layer nonce. 4. TCP Considerations Unidirectional traffic in a TCP connection is assumed to constitute a single flow, and hence MUST be assigned a unique Flow Label value by the source host. A single TCP connection MUST NOT be treated by a source host as consisting of multiple flows. Given the Flow Label value's additional use as a packet classification field in routers (for QoS or other purposes), there is no compelling reason to sub- divide traffic within a TCP connection for classification purposes. For this application of the Flow Label field, it would not pose a problem if multiple TCP connections from a source host to a particular destination host reused the same Flow Label value. However, because of the additional uses of the Flow Label field, a host MUST NOT assign the same Flow Label value to multiple TCP connections. It is not assumed that both directions of traffic flow in a TCP connection must share the same Flow Label value, nor it is prohibited. A host originating a TCP connection (client) selects a unique Flow Label value for the connection, which it stores as the OUTGOING_FLOW_ID in its Transport Control Block (TCB) for this connection. This Flow Label value is included in the first (and subsequent) SYN packet(s) sent to the destination host (server). The server receiving the first SYN packet records the Flow Label value in its TCB for this connection as the INCOMING_FLOW_ID. The server then selects a unique Flow Label value for the connection, which it stores as the OUTGOING_FLOW_ID in the connection's TCB. It includes this Flow Label value in the first (and subsequent) SYN-ACK packet(s) sent Blake Expires April 30, 2009 [Page 7] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 to the client. The client receiving the SYN-ACK packet from the server records the Flow Label value in its TCB for this connection as the INCOMING_FLOW_ID. It sends all additional packets of the connection to the server using OUTGOING_FLOW_ID, and checks all incoming packets of the connection from the server to ensure that they include INCOMING_FLOW_ID. The server performs identical processing. Any packets received with a Flow Label value that does not match INCOMING_FLOW_ID MUST be silently discarded. If a significant number of such packets are received, the event SHOULD be logged. When a server implements a SYN cache and/or SYN cookies, the Flow Label value used in the SYN-ACK packet MUST be consistent with the Flow Label value used in subsequent packets [RFC4987]. For the SYN cache case, this can be handled easily by including INCOMING_FLOW_ID and OUTGOING_FLOW_ID as part of each cache entry. For SYN cookies, one approach to satisfying the requirement without storing state is to use the Flow Label value received in the SYN (INCOMING_FLOW_ID) as the Flow Label value in the SYN-ACK (OUTGOING_FLOW_ID). This approach leaves a window of vulnerability to spoofing before the connection is established. [RFC0793] specifies that a connection should remain in TIME_WAIT state for 2 * MSL (Maximum Segment Lifetime) seconds. [RFC0793] specifies MSL as 120 seconds, although many implementations default to a lower value. The Flow Label value quarantine period MUST be no less than the maximum of either 2 * MSL for the connection, or 120 seconds. The specified behavior at the client and server will work even if either the client or server fails to set a non-zero outgoing Flow Label value, or check the incoming Flow Label value. However, resistance to spoofing attacks is not improved. Further, no mechanism for detecting whether a peer is supporting the Flow Label nonce is defined. Therefore, some cryptographic authentication mechanism SHOULD BE used when operating in a high-threat environment [RFC2385][I-D.ietf-tcpm-tcp-auth-opt] [RFC4301]. 5. UDP Considerations UDP is a connectionless protocol, which is also vulnerable to spoofing attacks. Source port randomization can be utilized with UDP, but UDP does not have sequence numbers, so it is arguably more vulnerable than TCP with source port and initial sequence number randomization. With the exception of connected sockets, UDP/IP stacks (usually) do not maintain sufficient state to maintain INCOMING_FLOW_ID or OUTGOING_FLOW_ID values for each application data Blake Expires April 30, 2009 [Page 8] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 stream between a source host and a destination host or multicast group. Therefore, Flow Label generation and validation must happen at the application layer. For purposes of discussion, we define a UDP connection as a flow of traffic matching the tuple . Note that a UDP connection consists of unidirectional traffic flow between a pair of hosts, or between a host and the receivers of a multicast group. UDP applications SHOULD assign each connection to a unique flow, and hence SHOULD assign each connection a unique Flow Label value. One exception is where multiple application data streams are multiplexed onto the same address/port pairs. In this case UDP applications MUST assign application data streams to unique flows (as appropriate for the intended QoS or other handling), and MUST use application-layer demultiplexing to associate incoming data streams with flows. Maintenance of INCOMING_FLOW_ID and OUTGOING_FLOW_ID values for each flow MUST be provided by the application. Note that an alternative to multiplexing multiple application data streams onto the same address/port pair is to utilize different source and/or destination port values for each data stream. There is no standard sockets API for either setting the Flow Label value in outgoing packets, nor retrieving it in incoming packets [RFC3493][RFC3542]. There is also no standard sockets API for specifying that a non-zero Flow Label value be used in outgoing packets. Therefore the requirements above cannot be satisfied, except where a non-standard API is available, or the functionality is provided automatically within the UDP/IP stack. It would be worthwhile to define a standard sockets API for Flow Label management. One application where the use of the Flow Label as a nonce might be beneficial is in protection against DNS cache poisoning attacks [I-D.weaver-dnsext-comprehensive-resolver]. If DNS clients assign each DNS transaction to a unique flow, and if DNS servers sends responses with an outgoing Flow Label value equal to the incoming Flow Label value received in the request, then the client can validate with high-probability that the request was generated by the targeted server, since the UDP source port, DNS transaction ID, and Flow Label provide approximately 51 bits of entropy. Use of the Flow Label with UDP-Lite will be discussed in a subsequent revision of this document. Blake Expires April 30, 2009 [Page 9] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 6. SCTP Considerations Use of the Flow Label with SCTP will be discussed in a subsequent revision of this document. 7. DCCP Considerations Use of the Flow Label with DCCP will be discussed in a subsequent revision of this document. 8. RTP Considerations Use of the Flow Label with RTP applications will be discussed in a subsequent revision of this document. 9. Acknowledgements [McGann05] proves that the concept of using the Flow Label as a transport-layer nonce pre-dates this document (although the author only discovered this paper after the writing of this document commenced). If others are aware of when and where this concept might have been discussed previously, please contact the author. This document was produced using the xml2rfc tool [RFC2629]. 10. IANA Considerations This memo includes no request to IANA. 11. Security Considerations All drafts are required to have a security considerations section. 12. References 12.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. Blake Expires April 30, 2009 [Page 10] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. 12.2. Informative References [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003. Blake Expires April 30, 2009 [Page 11] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007. [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [I-D.ietf-tcpm-icmp-attacks] Gont, F., "ICMP attacks against TCP", draft-ietf-tcpm-icmp-attacks-03 (work in progress), March 2008. [I-D.ietf-tcpm-tcpsecure] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", draft-ietf-tcpm-tcpsecure-10 (work in progress), July 2008. [I-D.ietf-tsvwg-port-randomization] Larsen, M. and F. Gont, "Port Randomization", draft-ietf-tsvwg-port-randomization-02 (work in progress), August 2008. [I-D.ietf-tcpm-tcp-auth-opt] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", draft-ietf-tcpm-tcp-auth-opt-01 (work in progress), July 2008. [I-D.weaver-dnsext-comprehensive-resolver] Weaver, N., "Comprehensive DNS Resolver Defenses Against Cache Poisoning", draft-weaver-dnsext-comprehensive-resolver-00 (work in progress), September 2008. [McGann05] McGann, O. and D. Malone, "Flow Label Filtering Feasibility", European Conference on Computer Network Defence, December 2005. Blake Expires April 30, 2009 [Page 12] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 Author's Address Steven Blake Extreme Networks Pamlico Building One, Suite 100 3306/08 E. NC Hwy 54 RTP, NC 27709 USA Phone: +1 919 884 3211 Email: sblake@extremenetworks.com Blake Expires April 30, 2009 [Page 13] Internet-Draft Flow Label as Transport-Layer Nonce October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Blake Expires April 30, 2009 [Page 14]