Network Working Group E. Ertekin Internet-Draft C. Christou Intended status: Informational R. Jasani Expires:
August 28,December 3, 2007 Booz Allen Hamilton February 24,June 1, 2007 Integration of Robust Header Compression (RoHC) over IPsec Security Associations draft-ietf-rohc-hcoipsec-04draft-ietf-rohc-hcoipsec-05 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 August 28,December 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract IP Security (IPsec) [IPSEC]provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (HC)(RoHC) over IPsec (HCoIPsec).(RoHCoIPsec). By compressing the inner headers of IP packets, HCoIPsecRoHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 5. Overview of the HCoIPsecRoHCoIPsec Framework . . . . . . . . . . . . 54 5.1. HCoIPsecRoHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . .5 5.2. Summary of the HCoIPsecRoHCoIPsec Framework . . . . . . . . . . . .5 6. Details of the HCoIPsecRoHCoIPsec Framework . . . . . . . . . . . .6 6.1. HCRoHC and IPsec Integration . . . . . . . . . . . . . . . . .6 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 6.1.2. Initialization and Negotiation of HCthe RoHC Channel . . . . . . .9 6.1.3. Encapsulation and Identification of Header Compressed Packets . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.2. HCoIPsecRoHCoIPsec Framework Summary . . . . . . . . . . . . . . . .10 7. Security Considerations . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 1110 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 1110 10. References . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2.Informative References . . . . . . . . . . . . . . . . . . 1211 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 1312 Intellectual Property and Copyright Statements . . . . . . 1413 1. Introduction This document outlines a framework for integrating HCRoHC [ROHC] over IPsec (HCoIPsec).[IPSEC] (RoHCoIPsec). The goal of HCoIPsecRoHCoIPsec is to reduce the protocol overhead associated with packets traversing between IPsec SA endpoints. This can be achieved by compressing the transport layer header (e.g., UDP, TCP, etc.) and inner IP header of packets at the ingress of the IPsec tunnel, and decompressing these headers at the egress. For HCoIPsec,RoHCoIPsec, this document assumes that existing HC protocols, such as Internet Protocol Header Compression [IPHC], Compressed Real Time Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust Header Compression [ROHC],RoHC will be used to compress the inner headers of IP packets traversing an IPsec tunnel. Since these HC protocols are designed to operateHowever, since current specifications for RoHC detail its operation on a hop-by-hop basis, theyit may require extensions to enable theirits operation over IPsec SAs. This document outlines a framework for extending the usage of these hop- by-hop HC protocolsRoHC to operate at IPsec SA endpoints. HCoIPsecRoHCoIPsec targets the application of HCRoHC to tunnel mode SAs. Transport mode SAs only encrypt/authenticate the payload of an IP packet, leaving the IP header untouched. Intermediate routers subsequently use this IP header to route the packet to a decryption device. Therefore, if traditional HC protocols wereRoHC is to operate over IPsec transport-mode SAs, (de)compression functionality can only be applied to the transport layer headers, and not to the IP header. Because current RoHC specifications for HC protocolsdo not include support for the compression of transport layer headers alone, the HCoIPsecRoHCoIPsec framework outlined by this document describes the application of HCRoHC to tunnel mode SAs. 2. Audience The authors target audience includes those who are involved with the developmentmembers of HC protocols, and IPsec implementations. Since traditional HC protocols have been designed to operate on a hop-by- hop basis, they may need to be modified or extended to be operational over IPsec SAs. Therefore,both the authors target various HCRoHC and IPsec communities who may consider extending existing HCthe RoHC and IPsec protocols to meet the requirements put forth in this document. Finally,In addition, this document is directed towards vendors developing IPsec devices that will be deployed in bandwidth-constrained IP networks. 3. Terminology Terminology specific to HCoIPsecRoHCoIPsec is introduced in this section. Compressed Traffic Traffic that is processed by thea RoHC compressor. Packet headers are compressed using a specific header compression protocol.RoHC profile. Uncompressed Traffic Traffic that is not processed by the RoHC compressor. Instead, this type of traffic bypasses the HCRoHC process. HCRoHC Process Generic reference to either the compressor, decompressor,ROHC compressor or any supporting header compression (HC) components.decompressor. IPsec Process Generic reference to the Internet Protocol Security (IPsec) process, asIPsec process defined in [IPSEC]. Next Header Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) field [PROTOCOL].field. 4. Problem Statement: IPsec Packet Overhead IPsec mechanisms provide various security services for IP networks. However, the benefits of IPsec come at the cost of increased per- packet overhead. For example, traffic flow confidentiality (generally leveraged at security gateways) requires the tunneling of IP packets between IPsec implementations. Although these IPsec tunnels will effectively mask the source-destination patterns that an intruder can ascertain, tunneling comes at the cost of increased per- packet overhead. Specifically, an ESP ([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 networks, as these types of infrastructure are not overprovisioned. HCRoHC applied on a per-hop basis over bandwidth-constrained link technologieslinks will also suffer from reduced performance when encryption is used on the tunneled header, since encrypted headers can not be compressed. Consequently, the additional overhead incurred by an IPsec tunnel may result in the inefficient utilization of bandwidth. Packet overhead is particularly significant for traffic profiles characterized by small packet payloads. Some applications that generate small packetpayloads include(e.g. various voice codecs.codecs). In addition, if these small packets are afforded the security services of an IPsec tunnel mode SA, the amount of per-packet overhead is increased. Thus, a mechanism is needed to reduce the overhead associated with such flows. 5. Overview of the HCoIPsecRoHCoIPsec Framework 5.1. HCoIPsecRoHCoIPsec Assumptions The goal of HCoIPsecRoHCoIPsec is to provide efficient transport of IP packets between source and destinationIPsec devices, without compromising the security services offered by IPsec. As such, the HCoIPsecRoHCoIPsec framework washas been developed based on the following assumptions: o Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC)RoHC will be leveraged to reduce the amount of overhead associated with packets traversing an IPsec SA o* Support for legacy HC algorithms (e.g. IPHC, CRTP, ECRTP) over IPsec may be provided through the specification of new RoHC profiles (e.g. [ROHC-CRTP]) o RoHC will be instantiated at the IPsec SA endpoints, and HC iswill be applied on a per-SA basis 5.2. Summary of the HCoIPsecRoHCoIPsec Framework HC protocols reduceRoHC reduces packet overhead in a network by exploiting intra- and inter-packet redundancies of network and transport-layer header fields of a flow. Existing HC protocolsCurrent RoHC protocol specifications compress packet headers on a hop-by-hop basis. However, IPsec SAs are instantiated between two IPsec implementations, with multiple hops between the IPsec implementations. Therefore, various extensions to fully integrate HC withboth RoHC and IPsec SAs, traditional hop-by-hop protocolsmay need to be extendeddefined to operateensure its successful operation at IPsec SA endpoints. The migration of hop-by-hop HC protocolsRoHC over IPsec SAs is straightforward, since SA endpoints provide source/destination pairs where (de)compression operations can take place. Compression in such a manner offers a reduction of per-packet protocol overhead between the two SA endpoints, and does not require compression and decompression cycles at the intermediate hops between IPsec implementations. Since existing HC protocolsRoHC will now essentially operate over multiple hops, it is imperative to ensure that theirits performance iswill not be severely impacted due to increased packet reordering and/or packet loss between the compressor and decompressor. In addition, since HC protocols will operate at IPsec SA endpoints, HC protocolsRoHC can no longer rely on the underlying link layer for HCRoHC parameter configuration and packet identification. Existing HC protocols use the underlying link layer to establish a set of configuration parameters at each end of the link, and some HC protocols (e.g., IPHC, CRTP, ECRTP) are also dependent on the link layer framing for identifying different types of header-compressed packets.The HCoIPsecRoHCoIPsec framework proposes that HCRoHC channel parameter configuration is accomplished by thean SA management protocol (e.g., IKEv2),IKEv2 [IKEV2]), while identification of compressed header packets (in contrast to uncompressed packets)is providedachieved through the Next Header field of the security protocol (e.g., AH [AH], ESP). In addition, HC protocols that require the identification of different types of header-compressed packets will have to be extended with such a mechanism.ESP [ESP]) header. Using the HCoIPsecRoHCoIPsec framework proposed below, outbound IP traffic processing at an IPsec device is augmented to compress appropriate packet headers, and subsequently encrypt and/or integrity-protect the packet. For tunnel mode SAs, compression may be applied to the transport layer protocol and the inner IP header. Inbound IP traffic processing at an IPsec device is modified in a similar fashion. For inbound packets, an IPsec device must first decrypt and/or integrity-check the packet. Then, the IPsec device determines if the packet was received on an HC-enabledRoHC-enabled SA (see sectionSection 6.1) and if the packet maintains compressed headers. If both of these conditions are met, decompression of the inner packet headers is performed. After decompression, the packet is checked against the access controls imposed on all inbound traffic associated with the SA (as specified in [IPSEC]). Note: Compression of inner headers is independent from compression of the security protocol (e.g., ESP) and outer IP headers. HC protocols such as ROHC areRoHC is capable of compressing the security protocol and the outer IP header on a hop-by-hop basis. If IPsec NULL encryption is applied to packets, HC protocolsRoHC may still be applied to the inner headers at the IPsec SA endpoints. Inbound and outbound packets are still processed as was previously described. 6. Details of the HCoIPsecRoHCoIPsec Framework 6.1. HCRoHC and IPsec Integration Figure 1 illustrates the components required to integrate HCRoHC with the IPsec process, i.e., HCoIPsec.RoHCoIPsec. +-------------------------------+ | HCRoHC Module | | | | | +-----+ | +-----+ +---------+ | | | | | | | HCRoHC | | --| A |---------| B |-----| Process |------> Path 1 | | | | | | | | (HC-enabled(RoHC-enabled SA) +-----+ | +-----+ +---------+ | | | | | | | |-------------------------> Path 2 | | | (HC-enabled(RoHC-enabled SA) | +-------------------------------+ | | | | +-----------------------------------------> Path 3 (HC-disabled(RoHC-disabled SA) Figure 1: Integration of HCRoHC with IPsec. The process illustrated in Figure 1 augments the IPsec processing model for outbound IP traffic(protected-to-unprotected).traffic (protected-to-unprotected). Initial IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1). The HCRoHC data item (part of the SA state information) retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if the traffic traversing the SA is handed to the HCRoHC module (Figure 1, decision block A). Packets selected to an HC-disableda RoHC-disabled SA must follow normal IPsec processing and must not be sent to the HCRoHC module (Figure 1, Path 3). Conversely, packets selected to an HC-enableda RoHC- enabled SA must be sent to the HCRoHC module. The decision at block B then determines if the packet can be compressed. If it is determined that the packet will be compressed, the Next Header field of the security protocol header (e.g., ESP, AH) is populated with a "compressed headers" value,"RoHC" identifier, and packet headers are compressed based on the compression protocol(Figure 1, Path 1). However, if it is determined that the packet will not be compressed (e.g., due to one the reasons described in Section 6.1.3), the Next Header field is populated with the appropriate value indicating the next level protocol (Figure 1, Path 2). After the HCRoHC process completes, IPsec processing resumes, as described in Section 5.1, Step3a, of [IPSEC] (specifically, "IPsec processing is as previously defined..."). The process illustrated in Figure 1 also augments the IPsec processing model for inbound IP traffic (unprotected-to-protected). For inbound packets, IPsec processing is performed ([IPSEC], Section 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 5.2, Step 4) . After AH or ESP processing, the HCRoHC data item retrieved from the SAD entry will indicate if traffic traversing the SA is handed to the HCRoHC module ([IPSEC], Section 5.2, Step 3a). Packets traversing an HC-disabledRoHC-disabled SA must follow normal IPsec processing and must not be sent to the HCRoHC module. Conversely, packets traversing an HC-enabledRoHC-enabled SA must be sent to the HCRoHC module. The decision at block B is determined by the value of the Next Header field.field of the security protocol header. If "compressed headers"a RoHC header is indicated, decompression is applied using the appropriate HC protocol(Figure 1, Path 1). However, if the Next Header field does not contain the "compressed headers" value,indicate a RoHC header, the decompressor must not attempt decompression (Figure 1, Path 2). Once the HCRoHC module completes processing, IPsec processing resumes, as described in Section 5.2, Step 4 of [IPSEC] (specifically "Then match the packet against the inbound selectors identified by the SAD ..."). Note that to further reduce the size of an IPsec-protected packet, HCoIPsecRoHCoIPsec and IPcomp [IPCOMP]can be implemented in a nested fashion. For an outbound packet, IPcomp is initially applied. Following the application of IPcomp, the packet is sent to the HCRoHC module. Then, the HCRoHC module may compress the headers (e.g., the IP header) of the IPcomp-processed packet. After the HCRoHC process completes, IPsec processing resumes. For inbound packets, these steps are reversed: first, the packet is IPsec-processed; then, headers are decompressed; last, the payload of the packet is decompressed based on the appropriate IPcomp algorithm. 6.1.1. Header Compression Protocol Considerations Traditional hop-by-hop HC protocols mustThe initial specification of RoHC [ROHC] may need to be extended to operate efficiently over IPsec SAs. CompressorSpecifically, compressor and decompressor implementation considerations thereforeimplementations must account for increased tolerance to packet reordering and packet loss between the compressor and decompressor,loss, and mustshould minimize the amount of feedback sent from the decompressor to the compressor. The ability to tolerateTo address this need, RoHCv2 [ROHCV2] defines various mechanisms that provide increased packet reordering betweenrobustness during these scenarios. Furthermore, within the compressor and decompressor iscontext of IPsec, a necessity for any HC protocol that is extendedRoHCv2 implementation can leverage additional mechanisms to operateimprove performance over an IPsec SA. The following provideschannels characterized by packet reordering/loss. For example, various security protocols are equipped with a summary ofsequence number that may be used by the candidate HC solutions, and their tolerancedecompressor to identify a packet loss and reordering between the compressor and decompressor: o IPHC has been identifiedas a HC protocol that performs poorly over long round trip time (RTT), high BER links [ROHC]. Extensions"sequentially late". This knowledge can be utilized to IPHC to compress TCP/IP headers over an IPsec SA should take into consideration longer RTTs, increased potential for packet reordering and packet loss between the compressor and decompressor. o CRTP has also been identified as a HC protocol that performs poorly over long RTT, high BER links [CRTPE]. Recent modifications to the CRTP protocol, such as ECRTP, enable the CRTP HC protocol to tolerate long RTTs and packet loss between the compressor and decompressor. However, the reordering tolerance of ECRTP still needs to be evaluated, as detailed in [ECRTPE]. Such implementation aspects should be taken into consideration when extending ECRTP to operate over IPsec SAs. o ROHC is a protocol that is designed for high BER, long RTT links. ROHC can be used to compress not only RTP/UDP/IP headers, but also other traffic profiles such as TCP/IP, 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] suggests 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 over IPsec SAs. Note that additional techniques may be used to augment a traditional HC protocol's tolerance to packet reordering. For example, various security protocols are equipped with a sequence number; this value may be used by the decompressor to identify a packet as "sequentially late". This knowledge canincrease the likelihood of successful decompression of a reordered packet. In addition, HC protocolsAdditionally, RoHC implementations should minimize the amount of feedback between decompressor and compressor. If a feedback channel from the decompressor to the compressor is not used sparingly, the overall gains from HCoIPsecRoHCoIPsec can be significantly reduced. For example, assume that ROHCRoHC is operating in bi-directional reliable mode, and is instantiated over an IPsec tunnel mode SA. In this scenario, any feedback sent from the decompressor to the compressor must be tunneled. As such, the additional overhead incurred by tunneling feedback will reduce the overall benefits of HC.RoHC. 6.1.2. Initialization and Negotiation of HCthe RoHC Channel Hop-by-hop HC protocols useRoHC uses the underlying link layer (e.g., PPP) to negotiate HCRoHC channel parameters. To remove HC protocol dependencies onIn the underlying link layer, an additional mechanism is needed to initialize a HCcase of RoHCoIPsec, channel and its associatedparameters prior to HCoIPsec operation. Initializationare negotiated by another mechanism. Specifically, initialization of the HCRoHC channel willis either beachieved manually (i.e., administratively configured for manual SAs), or beis performed by IPsec SA establishment protocols. The extensions required for IKEv2 to support HCRoHC parameter negotiation are detailed in [IKE-HC].[IKE-ROHC]. If the HCRoHC protocol requires bi-directional communications, two SAs must be instantiated between the IPsec implementations. One of the two SAs is used for carrying trafficRoHC-traffic from the compressor to the decompressor, while the other is used to communicate feedbackRoHC-feedback from the decompressor to the compressor. Note that the requirement for two SAs aligns with the operation of IKE, which creates SAs in pairs. However, IPsec implementations will dictate how decompressor feedback received on one SA is associated with a compressor on the other SA. 6.1.3. Encapsulation and Identification of Header Compressed Packets As indicated in Section 6.1, new state information (i.e., a new HCRoHC data item) is defined for each SA. The HCRoHC data item is used by the IPsec process to determine whether it sends all traffic traversing a given SA to the HCRoHC module (HC-enabled)(RoHC-enabled) or bypasses the HCRoHC module and sends the traffic through regular IPsec processing (HC-disabled).(RoHC- disabled). The Next Header field of the IPsec security protocol (e.g., AH or ESP) header is used to demultiplex header-compressed traffic from uncompressed traffic traversing an HC-enabledRoHC-enabled SA. This functionality is needed in situations where packets traversing an HC-enableda RoHC-enabled SA do not contain compressed headers. Such situations may occur when, for example, a compressor supports strictly n compressed flows and can not compress the n+1 flow that arrives. Another example is when traffic (e.g., TCP/IP) is selected (by IPsec) to an HC-enableda RoHC-enabled SA, but cannot be compressed by the HCRoHC process (e.g., because the compressor does not support TCP/IP compression). In these situations, the compressor must indicate that the packet contains uncompressed headers. Similarly, the decompressor must be able to identify packets with uncompressed headers and not attempt to decompress them. The Next Header field is used to demultiplex these header-compressed versus uncompressed packets, as a "compressed header" valueRoHC protocol identifier will indicate the packet contains compressed headers. Therefore,To accomplish this, an official IANA allocation from the ProtocolID registry [PROTOCOL] is required. The request for aRoHC Data Item, IANA ProtocolID allocation, in addition toand other IPsec extensions to support HCoIPsec,RoHCoIPsec, are specified in [IPSEC-HC].[IPSEC-ROHC]. 6.2. HCoIPsecRoHCoIPsec Framework Summary To summarize, the following items are needed to achieve HCoIPsec:RoHCoIPsec: o IKEv2 Extensions to Support HCoIPsecRoHCoIPsec o IPsec Extensions to Support HCoIPsecRoHCoIPsec 7. Security Considerations A malfunctioning headerRoHC compressor (i.e., the compressor located at the ingress of the IPsec tunnel) has the ability to send packets to the decompressor (i.e., the decompressor located at the egress of the IPsec tunnel) that do not match the original packets emitted from the end-hosts. Such a scenario will result in a decreased efficiency between compressor and decompressor. Furthermore, this may result in Denial of Service, as the decompression of a significant number of invalid packets may drain the resources of an IPsec device. 8. IANA Considerations None. 9. Acknowledgments The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, and Ms. Linda Noone of the Department of Defense, and well as Mr. Rich Espy of OPnet for their contributions and support in the development of this document. In addition, the authors would like to thank the following for their numerous reviews and comments to this document: o Dr. Stephen Kent o Dr. Carsten Bormann o Mr. Tero Kivinen o Mr. Lars-Erik Jonsson o Mr. Jan Vilhuber o Mr. Dan Wing o Mr. Kristopher Sandlund o Mr. Ghyslain Pelletier Finally, the authors would also like to thank Mr. Tom Conkle, Ms. Renee Esposito, Mr. Etzel Brower, and Mr.Dr. Jonah PezeshkiPezeshki, and Ms. Michele Casey of Booz Allen Hamilton for their assistance in completing this work. 10. Informative References 10.1. Normative References [IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [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, 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):(RoHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [ROHC-CRTP] Bormann, et al., "A RoHC Profile for CRTP (RoHC-CRTP)", work in progress , February 2007. [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. [ROHCTCP][ROHCV2] Pelletier, et al., "RobustG. and K. Sandlund, "RObust Header Compression: A Profile For TCP/IP (ROHC-TCP)",Compression Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP, and UDP-Lite", work in progress , FebruaryMay 2007. [IKE-HC][IKE-ROHC] Pezeshki, et al., "IKEv2 Extensions to Support HCoIPsec",RoHCoIPsec", work in progress , February 2007. [IPSEC-HC][PROTOCOL] IANA, ""Assigned Internet Protocol Numbers", IANA registry at: http://www.iana.org/assignments/protocol-numbers". [IPSEC-ROHC] Ertekin, et al., "IPsec Extensions to Support HCoIPsec",RoHCoIPsec", work in progress , February 2007. 10.2. Informative References [PROTOCOL] IANA, ""Assigned Internet Protocol Numbers", IANA registry at: http://www.iana.org/assignments/protocol-numbers". [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [AH] Kent, S., "IP Authentication Header", RFC 4302, December 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. [ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header Compression Algorithm ECRTP", November 2004. [ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS", RFC 4247, November 2005. [ROHCWEXT] Pelletier, et al., "ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.Authors' Addresses Emre Ertekin Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: firstname.lastname@example.org Chris Christou Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: email@example.com Rohan Jasani Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 email@example.com. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).