Network Working Group E. Ertekin Internet-Draft C. Christou Expires: September 17, 2005 R. Jasani Booz Allen Hamilton March 16, 2005 Requirements for Integrating Header Compression over IPsec Security Associations draft-ertekin-rqts-hcoipsec-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 September 17, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Internet Protocol security mechanisms, such as IP Security (IPsec) [IPSECARCH], provides various security services for IP traffic. However, the benefits offered by IPsec may come at the cost of increased overhead. This document identifies requirements for IP Ertekin, et al. Expires September 17, 2005 [Page 1] Internet-Draft Requirements for HC over IPsec SAs March 2005 header compression over IPsec (HCoIPsec). HCoIPsec proposes to reduce the amount of packet overhead associated with the transmission of traffic over tunnel/transport mode security associations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Header Compression Solution . . . . . . . . . . . . . . . . . 4 5. Goals and Requirements . . . . . . . . . . . . . . . . . . . . 6 6. Candidate Compression Algorithms and Needs . . . . . . . . . . 7 7. Example Operation . . . . . . . . . . . . . . . . . . . . . . 8 8. A Note on Multiplexing of Compressed Packets . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Ertekin, et al. Expires September 17, 2005 [Page 2] Internet-Draft Requirements for HC over IPsec SAs March 2005 1. Introduction This document identifies requirements for IP header compression over IPsec Security Associations (SAs) which are operating in tunnel or transport modes. The goal of integrating header compression with IPsec mechanisms is to reduce the protocol overhead associated with packets traversing between IPsec SA endpoints. This document enumerates requirements to achieve compression of the upper layer protocols (e.g., RTP/UDP and TCP) for transport mode SAs, along with the compression of the upper layer protocols and the inner IP header for tunnel mode SAs. This document proposes the use of Internet Protocol Header Compression [IPHC], Compressed Real Time Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust Header Compression [ROHC], to compress the inner headers of IP packets traversing IPsec SAs. However, these traditional header compression algorithms operate on a hop-by-hop basis. Therefore, this document details the requirements which will enable these traditional hop-by-hop header compression algorithms to operate end-to-end, between IPsec SA endpoints. To offer an example of the amount of overhead associated with IPsec protocols, consider the following. When operating in tunnel mode, IPv6 packets coupled with Encapsulating Security Payload [ESP] can incur at least 50 bytes of additional overhead per packet. However, one can take advantage of the fact that once IP packets are encrypted, the inner packet headers are not interpreted by intermediate routers. Therefore, header compression can be applied to the inner IP and upper layer protocol headers prior to encrypting traffic at the ingress of the IPsec tunnel, and subsequently decrypted/decompressed at the egress of the IPsec tunnel. This document also introduces requirements for compressing traffic traversing IPsec SAs operating in transport mode. These requirements apply only to transport mode SAs instantiated between two hosts; in such scenarios, header compression is applied only on the transport layer protocols. 2. Audience The target audience of this document includes those who are involved with the design and development of IP header compression schemes, and IPsec mechanisms. Since traditional IETF header compression algorithms (which are designed to operate over links) will need to be modified to operate over IPsec SAs, the authors target various header compression and IPsec communities who may consider extending hop-by-hop header compression algorithms and IPsec protocols to meet Ertekin, et al. Expires September 17, 2005 [Page 3] Internet-Draft Requirements for HC over IPsec SAs March 2005 the requirements put forward in this document. Finally, this document is directed towards vendors developing IPsec encryption/decryption devices which will be deployed in bandwidth-constrained, IP networking environments. 3. Problem Statement IPsec mechanisms provide various security services for IP-based networks. For example, ESP offers confidentiality, data origin authentication, connectionless integrity, anti-replay service, and limited traffic flow confidentiality [ESP]. The benefits of IPsec mechanisms may come at the cost of increased overhead emanated into the network. For example, Traffic flow confidentiality, which is generally implemented at security gateways, requires the tunneling of IP packets between the encryption/decryption devices. Tunnels mask the source-destination patterns that an intruder may ascertain, at the cost of extra per-packet overhead. An ESP tunnel mode SA applied to an IPv6 flow results in at least 50 bytes of additional overhead per packet. This additional overhead may be undesirable for many bandwidth-constrained wireless and/or Satellite Communications (SATCOM) networks, as these types of infrastructure can not be overprovisioned. Consequently, the additional overhead incurred in an encryption-based environment may hinder the efficient utilization of bandwidth. In addition, in these bandwidth-constrained high bit error rate (BER) networks, end-host applications may not have the luxury of sending packets with large payloads. This is due to the fact that large packets traversing high BER links result in high IP Packet Loss Ratio (IPLR). To reduce IPLR, end-host devices may reduce the size of packet payloads, which decreases the probability that a packet is lost due to a bit error. Reducing the size of packet payloads, however, increases the amount of overhead transmitted between the two end hosts. Moreover, if these packets traverse over an IPsec tunnel mode SA, the amount of overhead is further magnified. A mechanism is needed to reduce the overhead associated with such flows. 4. Header Compression Solution IP header compression schemes provide one such mechanism to reduce the per packet overhead in an IP network. Algorithms such as IPHC, CRTP, ECRTP and ROHC, exploit inter-packet redundancies of network and transport-layer header fields of a traffic flow to reduce the amount of overhead transmitted between two nodes. To apply header compression algorithms over IPsec SAs, several extensions to the existing algorithms need to be developed. Existing Ertekin, et al. Expires September 17, 2005 [Page 4] Internet-Draft Requirements for HC over IPsec SAs March 2005 header compression algorithms such as IPHC, CRTP, ECRTP and ROHC are designed to compress headers on a hop-by-hop basis. IPsec SAs, however, may be instantiated between two end hosts (i.e., transport mode), or between IPsec devices functioning as gateways. Therefore, to fully integrate header compression with IPsec SAs, traditional hop-by-hop algorithms need to be extended to operate between IPsec SA endpoints. The migration of traditional hop-by-hop header compression schemes over IPsec SAs is simple, as SA endpoints provide source/destination pairs where (de)compression operations can take place. Compression in such a manner offers both a reduction of per-packet protocol overhead between the two SA endpoints, and does not require compression and decompression cycles at the intermediate network nodes between the IPsec devices. Compression takes place at one end of the SA, the packet traverses through the intermediate network, and decompression takes place at the other end of the SA. It is imperative that the performance of the header compression algorithms is not severely impacted due to increased packet reordering and/or IPLR events between the compressor and decompressor. Using the proposed architecture, the order of processing for outbound packets at an IPsec device is to compress the appropriate packet headers, and subsequently encrypt and/or authenticate the packet. For tunnel mode SAs, compression occurs at the ingress of the IPsec tunnel, and may be applied to not only the transport layer protocol, but also the inner IP header for increased reduction of overhead. For SAs operating in transport mode, header compression algorithms may be applied only to the transport layer headers. The order of processing inbound packets at an IPsec device is similar. For inbound packets, an IPsec device must first decrypt the packet. Then, the IPsec device must identify whether the packet includes a compressed header. If the IPsec device has identified the packet as a packet with a compressed header, the decompression function takes place. Decompression at the egress of a tunnel-mode SA includes the decompression of IP and transport layer headers; for inbound packets of a transport SA, decompression of only the transport layer header will be executed. Note: For tunnel/transport mode SAs, compression of inner headers is completely independent from compression of the outer (e.g., ESP/IP) headers. Intermediate network nodes between IPsec endpoints may also compress the outer ESP/IP headers. Current header compression algorithms such as ROHC and IPHC contain the ability to compress these ESP/IP headers; no extension to these algorithms is required. Further discussion of hop-by-hop compression of the outer ESP/IP headers is out of scope of this draft. Ertekin, et al. Expires September 17, 2005 [Page 5] Internet-Draft Requirements for HC over IPsec SAs March 2005 If IPsec NULL encryption is applied on packets, the header compression schemes may still be applied on the inner headers at the IPsec SA endpoints. After IPsec processes the compressed packet (and NULL encryption is applied on the packet), the compressed header will be sent in the clear. In scenarios where NULL encrypted packets traverse intermediate nodes between the IPsec SA endpoints, the intermediary nodes should not attempt to compress the inner IP and transport layer headers. 5. Goals and Requirements The goal for HCoIPsec is to provide more efficient transport of IP packets between source and destination IPsec devices without compromising security services offered by IPsec. Based on this, requirements for HCoIPsec on tunnel and/or transport SAs are as follows: a. HCoIPsec MUST reduce the amount of overhead sent from one IPsec device to another, by extending existing header compression protocols (e.g., IPHC, CRTP, ECRTP, ROHC) to operate over IPsec SAs b. HCoIPsec MUST execute (de)compression operations at IPsec SA endpoints, and MUST NOT perform (de)compression cycles at intermediate nodes between IPsec devices c. HCoIPsec MUST minimize header compression algorithm performance degradation due to increased delays, packet loss, jitter, and reordering events between compressor and decompressor. d. HCoIPsec MUST NOT allow incorrectly decompressed packets to be forwarded from the decompressor (i.e., decryptor) e. HCoIPsec MUST minimize the amount of header compression signaling between compressor and decompressor f. HCoIPsec MUST be independent of the underlying link layer framing protocol (e.g., PPP) 1. HCoIPsec MAY leverage IKE, IKEv2 to negotiate header compression session parameters (e.g., for ROHC, IKE(v2) shall initialize MAX_CID, MAX_HEADER, MRRU) 2. HCoIPsec MAY introduce a new one-byte header to indicate the type of compressed packet (e.g., for ECRTP, COMPRESSED_RTP_8, COMPRESSED_RTP_16, CONTEXT_STATE, etc.) g. HCoIPsec MUST allow each SA to have its own CID space - this will enable reuse of CID values between SAs h. HCoIPsec MUST allow compressed headers and uncompressed headers to traverse a single SA The reasoning behind requirement (e) is to reduce the amount of header compression signaling between compressor and decompressor. Traditional header compression signaling between two hops may not Ertekin, et al. Expires September 17, 2005 [Page 6] Internet-Draft Requirements for HC over IPsec SAs March 2005 have an insignificant impact on the overall performance (i.e., bandwidth gains) of header compression algorithms. However, in the case of HCoIPsec, additional signaling between the compressor and decompressor will also need to be encrypted (and possibly tunneled), which will reduce the overall efficiency gains of the HCoIPsec solution. The motivation behind requirement (f) comes from the realization that the link layer frame will be changing between the IPsec endpoints. Therefore, link layer dependencies exhibited by traditional hop-by-hop header compression algorithms cannot be used in a HCoIPsec solution. Hop-by-hop header compression algorithms use the underlying link layer (e.g., Point to Point Protocol) for two purposes: 1) to negotiate the HC session parameters, 2) to indicate the type of compressed packet the data-link layer frame is encapsulating. To remove HC algorithm dependencies on the underlying link layer the following is proposed: o For initialization of the HC session parameters, we propose that this process is handed off to the IPsec SA establishment protocols. During SA initialization, the IPsec SA establishment protocols will identify the type of HC algorithm configured for the SA, and the HC algorithm's session parameters o For indication of compression packet types, a one-byte header may be added to the compressed packet; this field will help the decompressor identify how to handle the compressed packet. Finally, requirement (h) is desirable, as IPsec devices may have limitations on the number of IPsec SAs which may be instantiated. This requirement enables both uncompressed and compressed packets to operate over one SA. Therefore, HCoIPsec must include a mechanism which allows the IPsec device to identify that an inbound packet contains a compressed header. This can be achieved with the allocation of an integer value in the "next header" field of the ESP or AH header, which will indicate that the encrypted payload is a packet with a compressed header. Please see sections 7.0 and 8.0 for more details. 6. Candidate Compression Algorithms and Needs CRTP can be used to compress RTP/UDP/IP headers for tunnel mode SAs. CRTP, however, has been identified as a header compression algorithm which performs poorly over long RTT, high BER links [CRTPE]. Recent modifications to the CRTP algorithm, such as ECRTP, enables the CRTP header compression scheme to tolerate long round trip times, packet loss, and packet reordering events between compressor and decompressor. These characteristics are necessities when extending Ertekin, et al. Expires September 17, 2005 [Page 7] Internet-Draft Requirements for HC over IPsec SAs March 2005 traditional header compression schemes (which are optimized to operate over a link), over multiple hops. IPHC can be used to compress TCP/IP headers for tunnel mode SAs. IPHC, however, has also been identified as a header compression algorithm which performs poorly over long round trip time, high BER links [ROHC]. Extensions to IPHC to compress TCP/IP headers over an IPsec SA need to take into consideration longer RTTs, increased packet reordering and IPLR between the compressor and decompressor. ROHC, as defined in RFC 3095, provides a robust header compression scheme which is designed for high BER, long round trip time links. This makes ROHC is another candidate header scheme to extend over IPsec tunnels. ROHC can be used to compress not only RTP/UDP/IP headers, but also TCP/IP headers, as defined in [ROHCTCP]. Similar to CRTP and IPHC, ROHC has been identified as vulnerable to packet reordering events between the compressor and decompressor[ROHCE]. Recent work [ROHCWEXT] contends that the implementation aspects of ROHC can be modified to achieve tolerance to packet reordering events. Such implementation aspects should be taken into consideration when extending ROHC between IPsec SA endpoints. Current header compression schemes look to simultaneously compress network and transport layer headers. For the application of HC to transport mode SAs, the HC schemes MAY optionally be extended to operate strictly on layer 4 (e.g., TCP, and/or RTP/UDP headers), header compression can be applied. The aforementioned requirements which detail HCoIPsec apply to not only tunneled mode SAs, but also to transport mode SAs. 7. Example Operation The basic operation of the HCoIPsec protocol is detailed in the following example. Assume there are two IPsec devices operating in gateway mode. The initial step of the HCoIPsec process is to leverage the SA establishment protocol (e.g., IKE, IKEv2) to negotiate the header compression algorithm, and session parameters. For example, the MAX_CID, MRRU, MAX_HEADER, and PROFILES parameters will be negotiated for each IPsec SA which is capable of ROHC. For an IPsec SA that is ECRTP-enabled, session parameters including F_MAX_PERIOD, F_MAX_TIME, and the ECRTP Compression Suboption will be initialized. After the SA has been established, header compression can take place for packets which belong to that SA. Upon reception of an outbound packet, the IPsec device will consult the security policy database, to associate the packet with an SA. If the SA indicates that compression may take place, the IPsec device will decide whether to Ertekin, et al. Expires September 17, 2005 [Page 8] Internet-Draft Requirements for HC over IPsec SAs March 2005 compress the packet: if it is determined that the packet will not be compressed, then normal IPsec processing of the packet ensues; if it is determined that the packet's header will be compressed, the header compression algorithm is executed on the packet. After the packet's header is compressed, the device must indicate what type of compressed packet it is. This is done by adding a one-byte field which indicates the type of compressed packet (e.g., for ECRTP, this field will indicate-for example-an 8-bit compressed RTP header). The compressed packet is encrypted according to the SA configuration, the outer ESP/IP header is appended, and finally, the packet is transmitted. Upon reception of an inbound packet, an IPsec device associates the packet with an SA, and decrypts the packet based on the SA parameters. The IPsec device will then identify whether or not the packet is composed of a compressed header by inspecting the Next Header field of the ESP (or AH) header. If the next header field indicates a packet does not contain a compressed header, normal IPsec processing ensues; if the next header field indicates that the packet includes a compressed header, then the IPsec device hands the packet to the decompressor process. The decompressor then inspects the one-byte compressed packet type header field, and uses this information along with the HC session parameters to decompress the packet. When the packet decompression process completes, the packet is handed back to the IPsec process, as the packet is then placed through the security policy database, and is subsequently transmitted Ertekin, et al. Expires September 17, 2005 [Page 9] Internet-Draft Requirements for HC over IPsec SAs March 2005 Figure 1 depicts the basic function of HCoIPsec: -- -- -- -- -- -- -- -- -- -- | Tunnel Mode Security Association | | | | | V V +--------------+ +--------------+ |IPsec Endpoint| +--+ +--+ |IPsec Endpoint| | | | | | | | | +---| Compressor |-->|R1|-->|R2|-->| Decryptor |---+ | | Encryptor | | | | | | Decompressor | | | +--------------+ +--+ +--+ +--------------+ | | | | | | |-----------------| | | | | | | | V V V ------------------- ------------------------- ------------------- | | | | | | | | | | | | | | UDP | | | | E | ------------- | | | UDP | | |IP | / |Payload| |IP | S | |CID|Payload| | |IP | / |Payload| | | RTP | | | | P | ------------- | | | RTP | | | | | | | | | | | | | | ------------------- ------------------------- ------------------- | | |---ENCRYPTED---| | | Figure 1: Example operation of HCoIPsec. In the example scenario, note that the inbound and outbound packets are first mapped to an SA, and then subsequently mapped to a CID. This implies that the scope of each CID is contained within each SA. A CID value of 1 can be associated with multiple SAs; however, the context state information for CID 1 cannot be shared over multiple SAs. 8. A Note on Multiplexing of Compressed Packets It should also be noted that a packet concatenation (or multiplexing) scheme MAY be added in conjunction to HCoIPsec to further reduce the overall overhead of packets traversing between IPsec devices. This type of functionality is similar to AAL2 voice trunking, where voice packets from different sources are placed into one cell [AAL2]. As described in [AAL2], a multiplexor concatinates cells until one of Ertekin, et al. Expires September 17, 2005 [Page 10] Internet-Draft Requirements for HC over IPsec SAs March 2005 following two events occur: o the first event indicates that the maximum size of multiplexed cell is reached; o the second event indicates that a timer has expired--this timer provides an upper bound on the amount of delay a cell may exhibit. When either of these events are triggered, the multiplexor transmits the multiplexed cells. [TCRTP] is one proposal to reduce the packet overhead used between call gateways in an unencrypted network. In a similar fashion, if multiple compressed flows are mapped to one SA between two IPsec devices, then compressed packets MAY be concatenated with one another, encrypted, and subsequently tunneled to the destination IPsec device with one ESP/IP header. It should be noted, however, that a multiplexing functionality may be undesirable for the high BER networks, as multiplexing scheme may increase average packet sizes, which may result in a greater IPLR. The specification of such a protocol is left for further study. 9. Security Considerations The extension of header compression over IPsec security associations does not raise any additional security concerns beyond the issues related to existing IPsec protocols. A malfunctioning header compressor (i.e., in the case of this document, the encryption device) has the ability to send packets to the decompressor (i.e., decryptor) which do not match the original ones emanated from the end-hosts. In such a scenario, the invalid packets will pass the decryption process, and will subsequently be validly decompressed. Furthermore, an intruder who has the ability to arbitrarily inject packets between SA endpoints, and destines these malicious packets to the encryption/decryption devices, has the ability to cause context corruption between the compressor and decompressor processes instantiated within the IPsec device (if the malicious packet passes through the decryption process). Such a scenario will result in a decreased efficiency between compressor and decompressor, and furthermore, may result in Denial of Service, as the decompression of a significant number of invalid packets may drain the resources of an IPsec device. Note: It should be noted that these security issues are a direct offset of IPsec vulnerabilities. Ertekin, et al. Expires September 17, 2005 [Page 11] Internet-Draft Requirements for HC over IPsec SAs March 2005 10. Acknowledgments The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, of the Department of Defense, and Mr. A. Rich Espy of OPnet for their contributions and support for developing this document. The authors would also like to thank Mr. Jan Vilhuber, Mr. Dan Wing, of Cisco Systems, Mr. Lars-Erik Jonsson of Ericsson, and Mr. Kristopher Sandlund of Effnet for their valuable contributions to this document. The authors would also like to thank Ms. Renee Esposito, Mr. Etzel Brower, Mr. Jigar Amroliwala, and Mr. Dwayne Corbin of Booz Allen Hamilton for their assistance in completing this work. 11. References [IPSECARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [IPHC] Nordgren, M., Pink, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999. [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [ECRTP] Koren, T. and et. al., "Compressing IP/UDP/RTP Headers on Links with High Delay, Packet Loss, and Reordering", RFC 3545, July 2003. [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [CRTPE] Degermark, M., Hannu, H., Jonsson, L. and K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communication Magazine , Volume 7, number 4, pp. 20-25, August 2000. [ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS", work in progress , December 2004. [ROHCWEXT] Pelletier, G. and et. al, "ROHC over Channels That Can Reorder Packets", work in progress , February 2005. Ertekin, et al. Expires September 17, 2005 [Page 12] Internet-Draft Requirements for HC over IPsec SAs March 2005 [AAL2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 AAL", I.363.2 , September 1997. [TCRTP] Thompson, B., "Tunneling of Multiplexed Compressed RTP", work in progress , September 2004. Authors' Addresses Emre Ertekin Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 US Email: ertekin_emre@bah.com Chris Christou Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 US Email: christou_chris@bah.com Rohan Jasani Booz Allen Hamilton 8283 Greensboro Drive McLean, VA 22102 US Email: jasani_rohan@bah.com Ertekin, et al. Expires September 17, 2005 [Page 13] Internet-Draft Requirements for HC over IPsec SAs March 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ertekin, et al. Expires September 17, 2005 [Page 14]