--- 1/draft-ietf-rohc-hcoipsec-02.txt 2006-10-26 09:12:23.000000000 +0200 +++ 2/draft-ietf-rohc-hcoipsec-03.txt 2006-10-26 09:12:23.000000000 +0200 @@ -1,19 +1,19 @@ Network Working Group E. Ertekin Internet-Draft C. Christou -Expires: December 28, 2006 R. Jasani - Booz Allen Hamilton - June 26, 2006 +Intended status: Informational R. Jasani +Expires: April 25, 2007 Booz Allen Hamilton + October 22, 2006 Integration of Header Compression over IPsec Security Associations - draft-ietf-rohc-hcoipsec-02 + draft-ietf-rohc-hcoipsec-03 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 @@ -24,422 +24,440 @@ 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 December 28, 2006. + This Internet-Draft will expire on April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract - Internet Protocol security mechanisms, such as IP Security (IPsec) - [IPSEC], provide various security services for IP traffic. However, - the benefits of IPsec come at the cost of increased overhead. This - document defines a framework for integrating Header Compression (HC) - over IPsec (HCoIPsec). By compressing the inner headers of IP - packets, HCoIPsec proposes to reduce the amount of overhead - associated with the transmission of traffic over IPsec security - associations. + 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 Header Compression (HC) over IPsec (HCoIPsec). By + compressing the inner headers of IP packets, HCoIPsec 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 . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Problem Statement: Packet Overhead Associated with - IPsec Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . 4 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 5. Overview of the HCoIPsec Framework . . . . . . . . . . . . 5 5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5 - 5.2. HCoIPsec Description . . . . . . . . . . . . . . . . . . . 5 + 5.2. HCoIPsec Summary . . . . . . . . . . . . . . . . . . . . . 5 6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6 - 6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 6 - 6.1.1. Header Compression Scheme Considerations . . . . . . . . . 8 + 6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 7 + 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 6.1.2. Initialization and Negotiation of HC Channel . . . . . . . 9 6.1.3. Encapsulation and Identification of Header Compressed - Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 + Packets . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . 10 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . 11 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 7. Security Considerations . . . . . . . . . . . . . . . . . 11 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . 12 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . 14 1. Introduction - This document identifies a framework for integrating HC over IPsec - Security Associations (SAs). The goal of integrating HC with IPsec - 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. + This document outlines a framework for integrating HC over IPsec + (HCoIPsec). The goal of HCoIPsec 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. - To realize 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 an IPsec tunnel. Since these traditional HC - schemes operate on a hop-by-hop basis, several extensions must be - defined to enable their operation over IPsec SAs. This document - details a framework which will allow these traditional hop-by-hop HC - schemes to be extended to operate at IPsec SA endpoints. + For HCoIPsec, this document assumes traditional HC protocols, + Internet Protocol Header Compression [IPHC], Compressed Real Time + Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and + Robust Header Compression [ROHC], will be used to compress the inner + headers of IP packets traversing an IPsec tunnel. Since these + traditional HC protocols are designed to operate on a hop-by-hop + basis, they may require extensions to enable their operation over + IPsec SAs. This document outlines a framework for extending the + usage of these traditional hop-by-hop HC protocols to operate at + IPsec SA endpoints. - HCoIPsec currently targets the application of HC to tunnel mode SAs. - However, future work may extend the framework to operate over - transport mode SAs as well. Transport mode SAs only encrypt/ - authenticate the payload of an IP packet, leaving the IP header - untouched. Intermediate routers subsequently use the outer IP header - to route the packet to a decryption device. Therefore, if HC - mechanisms are extended to operate between IPsec transport-mode SA - endpoints, (de)compression functionality can only be applied to the - transport layer headers, and not to the IP header. Since compression - of transport layer headers alone does not provide substantial - efficiency gains, extending the HCoIPsec framework to support - transport mode SAs is left for future work. + HCoIPsec targets the application of HC 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 the IP header to route the packet to a decryption device. + Therefore, if traditional HC protocols were 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. Since + compression of transport layer headers alone does not provide + substantial efficiency gains, the HCoIPsec framework outlined by this + document only concerns the application of HC to tunnel mode SAs. 2. Audience The target audience includes those who are involved with the - development of HC schemes, and IPsec implementations. Since - traditional IETF HC schemes are designed to operate on a hop-by-hop - basis, they 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 requirements put forward in this document. Finally, this - document is directed towards vendors developing IPsec devices which - will be deployed in bandwidth-constrained, IP networks. + development 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, the authors target various HC and IPsec + communities who may consider extending existing HC and IPsec + protocols to meet the requirements put forth in this document. + Finally, this document is directed towards vendors developing IPsec + devices that will be deployed in bandwidth-constrained IP networks. 3. Terminology - Terminology specific to discussion of HCoIPsec is introduced in this - section. - - 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 RFC 2119. + Terminology specific to HCoIPsec is introduced in this section. Compressed Traffic Traffic that is processed by the compressor. Packet headers are - compressed using a compression profile. + compressed using a specific header compression protocol. Uncompressed Traffic Traffic that is not processed by the compressor. Instead, this type of traffic bypasses the HC process. HC Process Generic reference to either the compressor, decompressor, or any supporting header compression (HC) components. IPsec Process Generic reference to the Internet Protocol Security (IPsec) process [IPSEC]. -4. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode - SAs + Next Header + + Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) + field (see IANA web page at + http://www.iana.org/assignments/protocol-numbers). + +4. Problem Statement: IPsec Packet Overhead IPsec mechanisms provide various security services for IP networks. - 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, IPsec tunnels come at the cost of increased per-packet - overhead. Specifically, 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 networks, as - these types of infrastructure are not overprovisioned. Consequently, - the additional overhead incurred in an encryption-based environment - may result in the inefficient utilization of bandwidth. + 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, IPsec tunnels come at the cost of increased + per-packet overhead. Specifically, 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 + networks, as these types of infrastructure are not overprovisioned. + HC applied on a per-hop basis over bandwidth-constrained link + technologies 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 - emanate small packet payloads include various voice codecs (e.g., - G.729). In addition, if these small packets are afforded the - security services of an IPsec tunnel mode SA, the amount of per- - packet overhead is magnified. Thus, a mechanism is needed to reduce - the overhead associated with such flows. + emanate small packet payloads include various voice 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 + magnified. Thus, a mechanism is needed to reduce the overhead + associated with such flows. 5. Overview of the HCoIPsec Framework 5.1. HCoIPsec Assumptions - The goal for HCoIPsec is to provide more efficient transport of IP - packets between source and destination IPsec devices, without - compromising the security services offered by IPsec. As such, the - HCoIPsec framework was developed based on the following assumptions: + The goal for HCoIPsec is to provide efficient transport of IP packets + between source and destination IPsec devices, without compromising + the security services offered by IPsec. As such, the HCoIPsec + framework was developed based on the following assumptions: o Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) will be leveraged to reduce the amount of overhead associated with packets traversing an IPsec SA o HC algorithms will be instantiated at the IPsec SA endpoints, and HC is applied on a per-SA basis -5.2. HCoIPsec Description +5.2. HCoIPsec Summary - HC schemes reduce packet overhead in a network by exploiting inter- - packet redundancies of network and transport-layer header fields of a - flow to reduce the amount of redundant header data transmitted - between two nodes. + HC protocols reduce packet overhead in a network by exploiting intra- + and inter-packet redundancies of network and transport-layer header + fields of a flow. - To apply traditional HC schemes over IPsec SAs, several extensions - need to be defined. Existing HC schemes compress packet headers on a - hop-by-hop basis. However, IPsec SAs are instantiated between two - IPsec implementations, with multiple hops between the IPsec + Existing HC protocols 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, to fully integrate HC with IPsec SAs, - traditional hop-by-hop schemes need to be extended to operate at - IPsec SA endpoints. + traditional hop-by-hop protocols may need to be extended to operate + at IPsec SA endpoints. - The migration of traditional hop-by-hop HC schemes 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 + The migration of traditional hop-by-hop HC protocols 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 HC schemes will now essentially operate over - multiple hops, it is imperative that the performance of the HC - schemes is not severely impacted due to increased packet reordering - and/or packet loss between the compressor and decompressor. + implementations. Since traditional HC protocols will now essentially + operate over multiple hops, it is imperative that their performance + is not severely impacted due to increased packet reordering and/or + packet loss between the compressor and decompressor. - In addition, since HC schemes will operate at IPsec SA endpoints, HC - schemes can no longer rely on the underlying link layer for HC - parameter configuration and packet identification. Traditionally, HC - schemes use the underlying link layer to establish a set of - configuration parameters at each end of the link, and for identifying - different types of header-compressed packets. The HCoIPsec framework - proposes that HC session parameter configuration and header- - compressed packet identification is accomplished by the SA management - protocol (e.g., IKEv2) and the security protocol next header field, - respectively. + In addition, since HC protocols will operate at IPsec SA endpoints, + HC protocols can no longer rely on the underlying link layer for HC + parameter configuration and packet identification. Traditional 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 HCoIPsec framework proposes that HC channel parameter + configuration is accomplished by the SA management protocol (e.g., + IKEv2), while identification of compressed header packets (in + contrast to uncompressed packets) is provided through the Next Header + field of the security protocol (e.g., 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. Using the HCoIPsec 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-enabled SA(see section - 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 RFC 4301). + determines if the packet was received on an HC-enabled SA (see + section 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 RFC 4301). Note: Compression of inner headers is independent from compression of the security protocol (e.g., ESP) and outer IP headers. HC - schemes such as ROHC and IPHC are capable of compressing these - outer headers on a hop-by-hop basis. Further discussion on the - compression of outer headers is outside the scope of this - document. + protocols such as ROHC are capable of compressing the security + protocol and outer IP headers on a hop-by-hop basis. Further + discussion on the compression of outer headers is outside the + scope of this document. - If IPsec NULL encryption is applied to packets, HC schemes may still - be applied to the inner headers at the IPsec SA endpoints. Inbound - and outbound packets are still processed as was previously described. - For scenarios where NULL-encrypted packets traverse intermediate - nodes between the IPsec SA endpoints, the intermediary nodes must not - attempt to (de)compress the inner IP and/or transport layer headers. + If IPsec NULL encryption is applied to packets, HC protocols 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 HCoIPsec Framework 6.1. HC and IPsec Integration Based on these assumptions, Figure 1 illustrates the components required to integrate HC with the IPsec process, i.e., HCoIPsec. +-------------------------------+ | HC Module | | | | | +-----+ | +-----+ +---------+ | - | | HC-enabled | | | | HC | | - --| A |--------------------| B |-----| Process |------> Path 1 - | | | | | | | | + | | | | | | HC | | + --| A |---------| B |-----| Process |------> Path 1 + | | | | | | | | (HC-enabled SA) +-----+ | +-----+ +---------+ | | | | | | | |-------------------------> Path 2 - | | | + | | | (HC-enabled SA) | +-------------------------------+ | - | HC-disabled - +----------------------------------------------------> Path 3 + | + | + | + +-----------------------------------------> Path 3 + (HC-disabled SA) Figure 1: Integration of HC with IPsec. The process illustrated in Figure 1 augments the IPsec processing model for outbound IP traffic(protected-to-unprotected). Initial IPsec processing is consistent with RFC 4301 (Steps 1-2, Section 5.1). The HC data item (part of the SA state information) retrieved from the "relevant SAD entry" (RFC4301, Section 5.1, Step3a) determines if the traffic traversing the SA is handed to the HC module (Figure 1, decision block A). Packets selected to an HC- disabled SA must follow normal IPsec processing and must not be sent to the HC module (Figure 1, Path 3). Conversely, packets selected to an HC-enabled SA must be sent to the HC 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 the + of the security protocol header (e.g., ESP, AH) is populated with a "compressed headers" value, and packet headers are compressed based - on the appropriate compression profile (Figure 1, Path 1). However, - if it is determined that the packet will not be compressed, the Next - Header field is populated with the appropriate value indicating the - next level protocol (Figure 1, Path 2). After the HC process - completes, IPsec processing resumes, as described in Section 5.1, - Step3a, of RFC4301 (specifically, "IPsec processing is as previously - defined..."). + 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 HC process completes, IPsec + processing resumes, as described in Section 5.1, Step3a, of RFC4301 + (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, processing is performed (RFC4301, Section 5.2, - Steps 1-3) followed by AH or ESP processing (RFC4301, Section 5.2, - Step 4) . After AH or ESP processing, the HC data item retrieved - from the SAD entry will indicate if traffic traversing the SA is - handed to the HC module (RFC4301, Section 5.2, Step 3a). Packets - traversing an HC-disabled SA must follow normal IPsec processing and - must not be sent to the HC module. Conversely, packets traversing an - HC-enabled SA must be sent to the HC module. The decision at block B - then determines if the "Next Header" field contains the "compressed - header" value, which indicates that the packet's payload contains - compressed headers. If "compressed headers" is indicated, the - appropriate decompression profile is applied (Figure 1, Path 1). - However, if the packet's "Next Header" field does not contain the - "compressed headers" value, the decompressor must not attempt - decompression (Figure 1, Path 2). IPsec processing resumes once the - HC module completes processing, as described in Section 5.2, Step 4 - of RFC 4301(specifically "Then match the packet against the inbound + For inbound packets, IPsec processing is performed (RFC4301, Section + 5.2, Steps 1-3) followed by AH or ESP processing (RFC4301, Section + 5.2, Step 4) . After AH or ESP processing, the HC data item + retrieved from the SAD entry will indicate if traffic traversing the + SA is handed to the HC module (RFC4301, Section 5.2, Step 3a). + Packets traversing an HC-disabled SA must follow normal IPsec + processing and must not be sent to the HC module. Conversely, + packets traversing an HC-enabled SA must be sent to the HC module. + The decision at block B is determined by the value of the Next Header + field. If "compressed headers" 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, the decompressor must not attempt decompression + (Figure 1, Path 2). IPsec processing resumes once the HC module + completes processing, as described in Section 5.2, Step 4 of RFC + 4301(specifically "Then match the packet against the inbound selectors identified by the SAD ..."). -6.1.1. Header Compression Scheme Considerations +6.1.1. Header Compression Protocol Considerations - Traditional hop-by-hop HC schemes must be extended to operate - efficiently over IPsec SAs. Implementation considerations for this - includes increasing tolerance to packet reordering and packet loss - between the compressor and decompressor, and minimizing the amount of - feedback sent from the decompressor to the compressor. + Traditional hop-by-hop HC protocols must be extended to operate + efficiently over IPsec SAs. Compressor and decompressor + implementation considerations therefore must account for increased + tolerance to packet reordering and packet loss between the compressor + and decompressor, and minimizing the amount of feedback sent from the + decompressor to the compressor. The ability to tolerate increased packet reordering between the - compressor and decompressor is a necessity for any HC scheme that is - extended to operate over an IPsec SA. The following provides a + compressor and decompressor is a necessity for any HC protocol that + is extended to operate over an IPsec SA. The following provides a summary of the candidate HC solutions, and their tolerance to packet loss and reordering between the compressor and decompressor: - o IPHC has been identified as a HC scheme that performs poorly over - long round trip time (RTT), high BER links [ROHC]. Extensions to - IPHC to compress TCP/IP headers over an IPsec SA should take into - consideration longer RTTs, increased potential for packet - reordering and IPLR between the compressor and decompressor. - o CRTP has also been identified as a HC scheme that performs poorly - over long RTT, high BER links [CRTPE]. Recent modifications to - the CRTP scheme, such as ECRTP, enable the CRTP HC scheme 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 + o IPHC has been identified as a HC protocol that performs poorly + over long round trip time (RTT), high BER links [ROHC]. + Extensions 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 robust HC scheme 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 + 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. - In addition, HC schemes should minimize the amount of feedback + 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 can increase the likelihood of successful + decompression of a reordered packet. + + In addition, HC protocols 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 HCoIPsec can be significantly reduced. For example, assume that ROHC 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. 6.1.2. Initialization and Negotiation of HC Channel - Hop-by-hop HC schemes use the underlying link layer (e.g., PPP) to - negotiate HC channel parameters. To remove HC scheme dependencies on - the underlying link layer, an additional mechanism is needed to + Hop-by-hop HC protocols use the underlying link layer (e.g., PPP) to + negotiate HC channel parameters. To remove HC protocol dependencies + on the underlying link layer, an additional mechanism is needed to initialize a HC channel and its associated parameters prior to HC - scheme operation. + protocol operation. Initialization of the HC channel will either be achieved manually (i.e., administratively configured for manual SAs), or be performed by IPsec SA establishment protocols, e.g. IKEv2. During SA initialization, the SA establishment protocol will be extended to - negotiate the HC scheme's channel parameters. The specifics for this - proposal are detailed in a separate spectification, "IKEv2/IPsec - Extensions to Support HCoIPsec". + negotiate the HC protocol's channel parameters. The specifics for + this proposal are detailed in [IKE-HC]. - If the HC scheme requires bi-directional communications, two SAs must - be instantiated between the IPsec implementations. One of the two - SAs is used for carrying traffic from the compressor to the + If the HC protocol requires bi-directional communications, two SAs + must be instantiated between the IPsec implementations. One of the + two SAs is used for carrying traffic from the compressor to the decompressor, while the other is used to communicate feedback from - the decompressor to the compressor. IPsec implementations will - dictate how decompressor feedback received on one SA is associated - with a compressor on the other SA. + the decompressor to the compressor. Note that this requirement for + two SAs aligns with the operation of IKE, which is capable of + creating SA 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 HC data item) is defined for each SA. The HC data item is used by the IPsec process to determine whether it sends all traffic traversing a given SA to the HC module (HC-enabled) or bypasses the HC module and sends the traffic through regular IPsec processing (HC-disabled). - In addition, the "Next Header" field of the IPsec security protocol + In addition, 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-enabled SA. This functionality is needed in situations where packets traversing an HC- enabled SA are not compressed by the compressor. 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 to an HC-enabled - SA, but cannot be compressed by the HC process (e.g., because the - compressor does not support TCP/IP compression). In these - situations, the compressor must be able to indicate that the packet + example is when traffic (e.g., TCP/IP) is selected (by IPsec) to an + HC-enabled SA, but cannot be compressed by the HC 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. Therefore, an allocation for "compressed headers" - will need to be reserved from the IANA "Protocol Numbers" registry, - which will be defined in a separate specification. The "compressed - headers" value will indicate that the next layer protocol header is - composed of compressed headers. + decompress them. As such, the Next Header field is used to + demultiplex these header-compressed versus uncompressed packets, as a + "compressed header" value will indicate the packet contains + compressed headers. + Note: As indicated in the description of HCoIPsec inbound and + outbound processing, the Next Header field is used to identify + compressed packets on an HC-enabled SA. Because the Next Header + field value is only leveraged at the IPsec implementations, an + official IANA allocation from the ProtocolID registry may not be + required. Future discussions of HCoIPsec will determine the + appropriate path forward. 6.2. HCoIPsec Framework Summary - [Note to RFC Editor: this section may be removed on publication as an - RFC.] - To summarize, the following items are needed to achieve HCoIPsec: - o Extensions to traditional HC schemes which enable their operation - at IPsec SA enpoints - o Extensions to IKE/IPsec to support HC parameter configuration + o Extensions to traditional HC protocols which enable their + operation at IPsec SA enpoints + o Extensions to IKEv2 to Support Header Compression over IPsec + (HCoIPsec) o Allocation of one value for "compressed headers" from the IANA - "Protocol Numbers" registry + "Protocol Numbers" registry (This specification may not be + necessary, as indicated in Section 6.1.3) 7. Security Considerations A malfunctioning header 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 @@ -443,73 +461,78 @@ 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. Lars-Erik Jonnson + 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. Jonah Pezeshki of Booz Allen Hamilton for their assistance in completing this work. 10. 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, T. and et. al., "Compressing IP/UDP/RTP Headers on - Links with High Delay, Packet Loss, and Reordering", - RFC 3545, July 2003. + [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): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header Compression Algorithm ECRTP", November 2004. - [ROHCTCP] Pelletier, G. and et. al, "Robust Header Compression: A - Profile For TCP/IP (ROHC-TCP)", work in progress , - January 2006. + [ROHCTCP] Pelletier, et al., "Robust Header Compression: A Profile + For TCP/IP (ROHC-TCP)", work in progress , January 2006. [ROHCWEXT] - Pelletier, G. and et. al, "ROHC over Channels That Can - Reorder Packets", RFC 4224, January 2006. + Pelletier, et al., "ROHC over Channels That Can Reorder + Packets", RFC 4224, January 2006. + + [IKE-HC] Jasani, et al., "Extensions to IKEv2 to Support HCoIPsec", + work in progress , September 2006. 10.2. Informative References [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, December 2005. [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, @@ -539,21 +562,37 @@ Email: christou_chris@bah.com Rohan Jasani Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: jasani_rohan@bah.com -Intellectual Property Statement +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. @@ -563,30 +602,14 @@ 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 (2006). 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. + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA).