Network Working Group E. Ertekin Internet-Draft C. Christou Expires: October 3, 2005 R. Jasani Booz Allen Hamilton April 2005 Integration of Header Compression over IPsec Security Associations draft-ertekin-rqts-hcoipsec-01 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 October 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Internet Protocol security mechanisms, such as IP Security (IPsec) [IPSEC], provides various security services for IP traffic. However, the benefits offered by IPsec may come at the cost of increased overhead. This document identifies a methodology for integrating header compression (HC) over IPsec (HCoIPsec). HCoIPsec proposes to reduce the amount of packet overhead associated with the transmission of traffic over tunnel mode security associations. Ertekin, et al. Expires October 3, 2005 [Page 1] Internet-Draft Integration of HC over IPsec SAs April 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . . . . . . 3 4. The Header Compression Solution . . . . . . . . . . . . . . . 4 5. Integration Methodology . . . . . . . . . . . . . . . . . . . 6 5.1 Work Assumptions . . . . . . . . . . . . . . . . . . . . . 6 5.2 Work Items . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2.1 Header Compression Scheme Specific Extensions . . . . 7 5.2.2 Initialization and Negotiation of Header Compression Channel . . . . . . . . . . . . . . . . . 7 5.2.3 Encapsulation and Identification of Header Compressed Packets . . . . . . . . . . . . . . . . . . 7 6. Candidate Compression Schemes . . . . . . . . . . . . . . . . 8 7. Example Operation . . . . . . . . . . . . . . . . . . . . . . 8 8. Future Work Items . . . . . . . . . . . . . . . . . . . . . . 10 8.1 HCoIPsec Transport Mode SAs . . . . . . . . . . . . . . . 10 8.2 Multiplexing of Compressed Packets in IPsec Tunnels . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1 Normative References . . . . . . . . . . . . . . . . . . . 12 12.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 15 Ertekin, et al. Expires October 3, 2005 [Page 2] Internet-Draft Integration of HC over IPsec SAs April 2005 1. Introduction This document identifies a methodology for the integration of header compression (HC) over IPsec Security Associations (SAs) which are operating in tunnel mode. The goal of integrating HC with IPsec mechanisms is to reduce the protocol overhead associated with packets traversing between IPsec SA endpoints. This goal can be achieved by compressing the upper layer protocols (e.g., RTP/UDP and TCP) and the inner IP header of packets traversing tunnel mode SAs, before packet encryption takes place. To accomplish HCoIPsec, 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 within an IPsec tunnel. However, since these HC schemes operate on a hop-by-hop basis, several extensions to need to be defined. This document details a methodology which will enable these traditional hop-by-hop HC schemes to be extended, and operate end-to-end between IPsec SA endpoints. Currently, HCoIPsec primarily targets the application of HC to tunnel mode SAs as opposed to transport mode SAs. Transport mode SAs only encrypt/authenticate the payload of an IP packet, and leave the original IP header unencrypted/unauthenticated. Since intermediary routers use the original IP header to route the packet to a decryption device, end-to-end header (de)compression functionality at the transport-mode SA endpoints can only be applied on the transport layer headers and not the IP header. Since compression of transport layer headers alone does not provide substantial efficiency gains, it is not fully integrated into the HCoIPsec methodology. 2. Audience The target audience includes those who are involved with the design and development of HC schemes, and IPsec mechanisms. Since traditional IETF HC schemes are designed to operate on a hop-by-hop basis, they will need to be modified to operate over IPsec SAs. Therefore, the authors target various HC and IPsec communities who may consider extending hop-by-hop HC schemes and IPsec protocols to meet the methodology 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: Packet Overhead Associated with IPsec Tunnel-Mode SAs Ertekin, et al. Expires October 3, 2005 [Page 3] Internet-Draft Integration of HC over IPsec SAs April 2005 IPsec mechanisms provide various security services for IP-based networks. For example, ESP offers 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, but the benefit comes 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 are not overprovisioned. Consequently, the additional overhead incurred in an encryption-based environment may hinder the efficient utilization of bandwidth. 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. The Header Compression Solution IP HC schemes provide one such mechanism to reduce the per packet overhead in an IP network. Schemes such as IPHC, CRTP, ECRTP and ROHC exploit inter-packet redundancies of network and transport-layer header fields of a flow to reduce the amount of overhead transmitted between two nodes. To apply HC schemes over IPsec SAs, several extensions to the existing schemes need to be developed. Existing HC schemes 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 IPsec devices functioning as gateways, with multiple intermediary nodes between the IPsec gateways. Therefore, to fully integrate HC with IPsec SAs, traditional hop-by-hop schemes need to be extended to operate between IPsec SA endpoints. Ertekin, et al. Expires October 3, 2005 [Page 4] Internet-Draft Integration of HC over IPsec SAs April 2005 The migration of traditional hop-by-hop HC 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. Since HC schemes will now essentially be operating over multiple hops, it is imperative that the performance of the HC schemes is not severely impacted due to increased packet reordering and/or IPLR events between the compressor and decompressor. It should be noted that the notion of extending hop-by-hop HC schemes to operate over multiple hops is not new, as the HCoIPsec effort parallels other efforts such as ECRTP over MPLS [HCOMPLS]. 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 is applied to the transport layer protocol and the inner IP header. The order of processing for 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 an IPsec tunnel includes the decompression of IP and transport layer headers. Note: 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 HC schemes such as ROHC and IPHC contain the ability to compress these ESP/IP headers. Further discussion of hop-by-hop compression of the outer ESP/IP headers is out of scope of this document. If IPsec NULL encryption is applied on packets, HC 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 (de)compress the inner IP and transport layer headers on a hop-by-hop basis. Ertekin, et al. Expires October 3, 2005 [Page 5] Internet-Draft Integration of HC over IPsec SAs April 2005 5. Integration Methodology 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. With this general goal in mind, Section 5.1 defines a set of work assumptions to guide the direction of the HCoIPsec solution. Based on these work assumptions, Section 5.2 defines work items which need to be addressed to complete the HCoIPsec solution. 5.1 Work Assumptions a. HCoIPsec must use existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) to reduce the amount of overhead associated with packets traversing an IPsec tunnel-mode SA. 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 be independent of the underlying link layer framing protocol (e.g., PPP). d. HCoIPsec must allow each SA to constitute a HC channel, enabling each SA to have its own CID space. e. An SA with HC enabled should not deliver a larger amount of incorrect packets than the same SA with HC disabled. The motivation behind (c) 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 HC schemes cannot be used in a HCoIPsec solution. 5.2 Work Items This section identifies several work items that need to be addressed to achieve HCoIPsec. The first work item encompasses the HC scheme specific extensions needed to ensure that traditional hop-by-hop HC schemes will operate efficiently over SA endpoints: a. Header Compression Scheme Specific Extensions: Any modifications needed to be made to existing HC schemes, which will facilitate their operation over IPsec SAs. (Section 5.2.1) Hop-by-hop HC schemes use the underlying link layer (e.g., Point to Point Protocol) to negotiate the HC channel parameters and to indicate the type of compressed packet the data-link layer frame is encapsulating. To remove HC scheme dependencies on the underlying link layer and to achieve a complete HCoIPsec solution, two additional work items are proposed: Ertekin, et al. Expires October 3, 2005 [Page 6] Internet-Draft Integration of HC over IPsec SAs April 2005 b. Initialization and Negotiation of the Header Compression Channel: Mechanisms needed to initialize a HC channel and negotiate HC scheme parameters prior to operation. (Section 5.2.2) c. Encapsulation and Identification of Header Compressed Packets: Mechanisms which encapsulate and identify compressed header packets, as well as how these mechanisms will operate. (Section 5.2.3) 5.2.1 Header Compression Scheme Specific Extensions a. HCoIPsec should minimize HC scheme performance degradation due to increased delays, packet loss, jitter, and reordering events between compressor and decompressor. b. HCoIPsec should minimize the amount of HC signaling between compressor and decompressor. The intention of (b) is to indicate that if a feedback channel from the decompressor to the compressor is not used sparingly, then the overall gains from HCoIPsec can be significantly reduced (even more so than hop-by-hop HC). For example, take the case where ROHC in bi- directional reliable mode is instantiated over an IPsec tunnel mode SA. Any feedback sent from the decompressor to the compressor must be tunneled, and therefore, the additional overhead incurred by tunneling the feedback will reduce the overall benefits of HC. 5.2.2 Initialization and Negotiation of Header Compression Channel Initialization of the HC channel is handed off to the IPsec SA establishment protocols. During SA initialization, the IPsec SA establishment protocols will identify the type of HC scheme configured for the SA, as well as the HC scheme's channel parameters. a. HCoIPsec may leverage IKE, IKEv2 to negotiate HC channel parameters (e.g., for ROHC, IKE(v2) shall initialize MAX_CID, MAX_HEADER, MRRU) b. HCoIPsec should allow compressed headers and uncompressed headers to traverse a single SA (b) is desirable, as IPsec devices may have limitations on the number of IPsec SAs which may be instantiated. Therefore, (b) indirectly implies that both uncompressed and compressed packets should be able to be classified under the same SA. Therefore, HCoIPsec should include a mechanism which will aid an IPsec device in identifying whether or not an inbound packet contains a compressed header. 5.2.3 Encapsulation and Identification of Header Compressed Packets For indication purposes, a one-byte header may be added to the Ertekin, et al. Expires October 3, 2005 [Page 7] Internet-Draft Integration of HC over IPsec SAs April 2005 compressed packet; this field will help the decompressor identify how to process the compressed packet. a. 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.) 6. Candidate Compression Schemes IPHC can be used to compress TCP/IP headers for tunnel mode SAs. IPHC, however, has been identified as a HC scheme which performs poorly over long round trip time (RTT), 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. CRTP can be used to compress RTP/UDP/IP headers for tunnel mode SAs. CRTP, however, has also been identified as a HC scheme which performs poorly over long RTT, high BER links [CRTPE]. Recent modifications to the CRTP scheme, such as ECRTP, enables the CRTP HC scheme to tolerate long RTTs, packet loss, and packet reordering events between compressor and decompressor. The ability to tolerate these network characteristics is a necessity for any HC scheme, and will be a factor in determining how efficiently the HC scheme operates over the IPsec tunnel-mode SA. ROHC, as defined in RFC 3095, provides a robust HC scheme which is designed for high BER, long RTT links. This makes ROHC 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 to operate between IPsec SA endpoints. 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 HC scheme, and channel 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, channel parameters including F_MAX_PERIOD, F_MAX_TIME, Ertekin, et al. Expires October 3, 2005 [Page 8] Internet-Draft Integration of HC over IPsec SAs April 2005 and the ECRTP Compression Suboption will be initialized. After the SA has been established, HC 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, and associate the packet with an SA. If the SA indicates that compression may take place, the IPsec device will decide whether or not to 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 HC scheme is executed on the packet. After the packet's header is compressed, the device must indicate what type of compressed packet it is. This may be achieved 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. If a packet does not contain a compressed header, normal IPsec processing ensues; if the packet includes a compressed header, then the IPsec device hands the packet to the decompressor process. The decompressor may inspect the one-byte compressed packet type header field, and use this information along with the HC channel 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 October 3, 2005 [Page 9] Internet-Draft Integration of HC over IPsec SAs April 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. Future Work Items 8.1 HCoIPsec Transport Mode SAs Many of the current HC profiles look to simultaneously compress network and transport layer headers of IP packets. This makes the extension of traditional HC schemes over transport-mode SAs more difficult. For the application of HC over transport mode SAs, traditional HC schemes may need to be extended to operate strictly on layer 4 (e.g., TCP, and/or RTP/UDP) headers. The methodology and Ertekin, et al. Expires October 3, 2005 [Page 10] Internet-Draft Integration of HC over IPsec SAs April 2005 specification for HCoIPsec transport mode SAs is left for further study. 8.2 Multiplexing of Compressed Packets in IPsec Tunnels 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 multiplexer concatenates cells until one of 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 multiplexer 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 HC 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 Ertekin, et al. Expires October 3, 2005 [Page 11] Internet-Draft Integration of HC over IPsec SAs April 2005 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. 10. IANA Considerations None. 11. 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 and Mr. Kristopher Sandlund of Ericsson 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. 12. References 12.1 Normative References [IPSEC] 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, Ertekin, et al. Expires October 3, 2005 [Page 12] Internet-Draft Integration of HC over IPsec SAs April 2005 ESP, and uncompressed", RFC 3095, July 2001. [ROHCTCP] Pelletier, G. and et. al, "Robust Header Compression: A Profile For TCP/IP (ROHC-TCP)", work in progress , February 2005. [ROHCWEXT] Pelletier, G. and et. al, "ROHC over Channels That Can Reorder Packets", work in progress , February 2005. 12.2 Informative References [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998. [HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header Compression over MPLS", April 2005. [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. [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 Ertekin, et al. Expires October 3, 2005 [Page 13] Internet-Draft Integration of HC over IPsec SAs April 2005 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 October 3, 2005 [Page 14] Internet-Draft Integration of HC over IPsec SAs April 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 October 3, 2005 [Page 15]