Network Working Group E. Ertekin Internet-Draft C. Christou Expires:
AugustDecember 28, 2006 R. Jasani Booz Allen Hamilton February 24,June 26, 2006 Integration of Header Compression over IPsec Security Associations draft-ietf-rohc-hcoipsec-01draft-ietf-rohc-hcoipsec-02 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 AugustDecember 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Internet Protocol security mechanisms, such as IP Security (IPsec) [IPSEC], providesprovide various security services for IP traffic. However, the benefits offered byof IPsec come at the cost of increased overhead. This document identifiesdefines a set of work items that need to be completed to achieve the integration of header compressionframework for integrating Header Compression (HC) over IPsec (HCoIPsec). By compressing the inner headers of IP packets, HCoIPsec proposes to reduce the amount of packetoverhead associated with the transmission of traffic over tunnel modeIPsec security associations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . .3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 34 4. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . 4 5. Overview of the HCoIPsec Framework . . . . . 4 5. The Header Compression Solution. . . . . . . 5 5.1. HCoIPsec Assumptions . . . . . . . . 5 6. Integration Methodology. . . . . . . . . . . 5 5.2. HCoIPsec Description . . . . . . . . 6 6.1. Work Assumptions. . . . . . . . . . . 5 6. Details of the HCoIPsec Framework . . . . . . . . . . 6 6.2. Work Items. . 6 6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 6 6.1.1. Header Compression Scheme Considerations . . . . . 7 6.2.1. Header Compression Scheme-Specific Extensions. . . . 8 188.8.131.52.1.2. Initialization and Negotiation of Header CompressionHC Channel . . . . . . . . . . . . . . . . . 8 184.108.40.206 6.1.3. Encapsulation and Identification of Header Compressed Packets . . . . . . . . . . . . . . . . . . 9 7. Candidate Compression Schemes . . . . . . . . .. . . . . . . 9 8. Example Operation . . . . . .6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10 9. Future Work Items . . . . . . . . . . . . . . . . . . . . . . 12 9.1. HCoIPsec Transport Mode SAs . . . . . . . . . . . . . . . 12 10.7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11.10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12.10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 13.10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1.11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 13.2.11 10.2. Informative References . . . . . . . . . . . . . . . . . . 1412 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 1613 Intellectual Property and Copyright Statements . . . . . . . . . . 1714 1. Introduction This document identifies a set of work items that need to be completed in order to achieve the integration of header compression (HC)framework for integrating HC over IPsec Security Associations (SAs) operating in tunnel mode.(SAs). The goal of integrating HC with IPsec is to reduce the protocol overhead associated with packets traversing between IPsec SA endpoints. This goalcan be achieved by compressing the uppertransport layer protocolsheader (e.g., RTP/UDP and TCP)UDP, TCP, etc.) and theinner IP header of packets,packets at the ingress of the IPsec tunnel, and decompressiondecompressing these headers at the egress. To accomplishrealize 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 withinan IPsec tunnel. However, sinceSince these traditional HC schemes operate on a hop-by-hop basis, several extensions need tomust be defined. This document details a technique which willdefined 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, andextended to operate betweenat IPsec SA endpoints. Currently,HCoIPsec primarilycurrently targets the application of HC to tunnel mode SAs as opposedSAs. However, future work may extend the framework to operate over transport mode SAs.SAs as well. Transport mode SAs encrypt/authenticateonly encrypt/ authenticate the payload of an IP packet, leaving the originalIP header untouched. Intermediate routers subsequently use the originalouter IP header to route the packet to a decryption device. Therefore, if HC weremechanisms are extended to operate between IPsec transport- modetransport-mode SA endpoints, (de)compression functionality can only be applied onlyto the transport layer headersheaders, and not to the IP header. Since compression of transport layer headers alone does not provide substantial efficiency gains, itextending the HCoIPsec framework to support transport mode SAs is not integrated into HCoIPsec.left for future work. 2. Audience The target audience includes those who are involved with the design anddevelopment of HC schemes, and IPsec mechanisms.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. 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. Compressed Traffic Traffic that is processed by the compressor (compressed) using one of the existing profiles. Note: This includes packets that might becompressor. Packet headers are compressed using an "uncompressed"a compression profile. Uncompressed Traffic Traffic that is not processed by the compressor. Instead, this type of traffic is bypassed bybypasses the HC process. HC Process Generic reference to either the compressor, decompressor, andor 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 IPsec mechanisms provide various security services for IP-basedIP networks. For example, ESP offers data origin authentication, connectionless integrity, anti-replay service, and limited traffic flow confidentiality [ESP].The benefits of IPsec mechanismscome at the cost of increased per- packet overhead in the network.per-packet overhead. For example, traffic flow confidentiality, which is generally implementedconfidentiality (generally leveraged at security gateways,gateways) requires the tunneling of IP packets between theIPsec devices.implementations. Although these IPsec tunnels maywill effectively mask the source-destination patterns that an intruder maycan ascertain, but the benefit comesIPsec tunnels come at the cost of extraincreased per-packet overhead. AnSpecifically, 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-constrainedbandwidth- constrained wireless and/or Satellite Communications (SATCOM)satellite communications networks, as these types of infrastructure are not overprovisioned. Consequently, the additional overhead incurred in an encryption-based environment may hinderresult in the efficientinefficient utilization of bandwidth. In bandwidth-constrained, high bit error rate (BER) networks, IPPacket Loss Ratio (IPLR) can severely degrade end-host application performance. The traditional means for combating IPLR on high BER links has been Error Correction Codes (ECC). In addition, end-host applications may not have the luxury of sending packets with large payloads. Thisoverhead 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 ofparticularly significant for traffic profiles characterized by small packet payloads, which decreases the probabilitypayloads. Some applications that aemanate small 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,payloads include various voice codecs (e.g., G.729). In addition, if these small packets traverse overare afforded the security services of an IPsec tunnel mode SA, the amount of per- packet overhead is furthermagnified. AThus, a mechanism is needed to reduce the overhead associated with such flows. 5. Overview of the HCoIPsec Framework 5.1. HCoIPsec Assumptions The Header Compression Solution IP HC schemes provide one mechanismgoal for HCoIPsec is to reduce packet overhead in an IP network. Schemes such as IPHC, CRTP, ECRTP and ROHC exploit inter-packet redundanciesprovide more efficient transport of networkIP 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 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. To apply traditional HC schemes over IPsec SAs, several extensions to the existing schemesneed to be developed.defined. Existing HC schemes such as IPHC, CRTP, ECRTP and ROHC are designed tocompress packet headers on a hop- by-hophop-by-hop basis. However, IPsec SAs, however, may beSAs are instantiated between two IPsec devices functioning as gateways,implementations, with multiple intermediary nodeshops between the IPsec gateways.implementations. Therefore, to fully integrate HC with IPsec SAs, traditional hop-by-hop schemes need to be extended to operate betweenat IPsec SA endpoints. The migration of traditional hop-by-hop HC schemes over IPsec SAs is simple, asstraightforward, since SA endpoints provide source/destination pairs where (de)compression operations can take place. Compression in such a manner offers botha reduction of per-packet protocol overhead between the two SA endpoints, and does not require compression and decompression cycles at the intermediate network nodeshops between theIPsec devices.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 IPLR eventspacket loss between the compressor and decompressor. It should be noted thatIn addition, since HC schemes will operate at IPsec SA endpoints, HC schemes can no longer rely on the notion of extending hop-by-hopunderlying link layer for HC parameter configuration and packet identification. Traditionally, HC schemes use the underlying link layer to operate over multiple hops is not new, asestablish a set of configuration parameters at each end of the link, and for identifying different types of header-compressed packets. The HCoIPsec effort parallels other efforts such as ECRTP over MPLS [HCOMPLS].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. Using the HCoIPsec framework proposed architecture,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 implicitlydetermines whetherif the packet was received on aan HC-enabled SA.SA(see section 6.1), and if the packet maintains compressed headers. If both of these conditions are met, decompression of the inner packet was received over a HC-enabled SA,headers is performed. After decompression, the decompression function takes place.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 completelyindependent from compression of the outersecurity protocol (e.g., ESP/IP) headers. Intermediate network nodes between IPsec endpoints may also compress theESP) and outer ESP/IPIP headers. CurrentHC schemes such as ROHC and IPHC contain the ability to compressare capable of compressing these ESP/IP headers.outer headers on a hop-by-hop basis. Further discussion of hop-by-hopon the compression of theouter ESP/IPheaders is out ofoutside the scope of this document. If IPsec NULL encryption is applied onto packets, HC schemes may still be applied onto the inner headers at the IPsec SA endpoints. Inbound and outbound packets are still processed as described previously. Inwas 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 on a hop-by-hop basis.headers. 6. Integration Methodology The goal for HCoIPsec is to provide more efficient transportDetails of IP packets between sourcethe HCoIPsec Framework 6.1. HC and destinationIPsec devices, via tunnel mode SAs, without compromising security services offered byIntegration 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 | | | | | | | | +-----+ | +-----+ +---------+ | | | | | | | |-------------------------> Path 2 | | | | +-------------------------------+ | | HC-disabled +----------------------------------------------------> Path 3 Figure 1: Integration of HC with IPsec. With this general goalThe process illustrated in mind,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 defines a set5.1). The HC data item (part of work assumptions to guidethe direction ofSA state information) retrieved from the HCoIPsec solution. Based on these work assumptions,"relevant SAD entry" (RFC4301, Section 5.2 defines work items which need to be addressed5.1, Step3a) determines if the traffic traversing the SA is handed to achievethe HCoIPsec solution. 6.1. Work Assumptions a. HCoIPsec must use existingHC protocols (e.g., IPHC, CRTP, ECRTP, ROHC)module (Figure 1, decision block A). Packets selected to reduce the amount of overhead associated with packets traversingan IPsec tunnel-mode SA. b. HCoIPsecHC- disabled SA must execute (de)compression operations atfollow normal IPsec SA endpoints,processing and must not perform (de)compression cycles at intermediate nodes between IPsec devices. c. HCoIPsec mustbe independent of the underlying link layer framing protocol (e.g., PPP). d. HCoIPsec must allow each SAsent to constitute athe HC channel, enabling each SAmodule (Figure 1, Path 3). Conversely, packets selected to have its own CID space. e. Anan HC-enabled SA with HC enabled should not deliver a larger number of erroneous packets thanmust be sent to the same SA withHC disabled.module. The motivation behind (c) comes fromdecision at block B then determines if the realization that an SA may traverse multiple links, employing various framing protocols, andpacket can be compressed. If it is determined that the set of links (and thus framing protocols) may change duringpacket will be compressed, the lifetimeNext Header field of an SA. Therefore, link layer dependencies exhibited by traditional hop-by-hop HC schemes cannot be used inthe HCoIPsec solution. 6.2. Work Items This section identifies several work items that need to be addressed to achieve HCoIPsec. The first work item encompassessecurity protocol header (e.g., ESP, AH) is populated with the HC scheme- specific extensions needed to ensure"compressed headers" value, and packet headers are compressed based on the appropriate compression profile (Figure 1, Path 1). However, if it is determined that traditional hop-by-hop HC schemesthe packet will operate efficiently over IPsec SA endpoints: a. Header Compression Scheme-Specific Extensions: Any modifications needed tonot be made to existingcompressed, the Next Header field is populated with the appropriate value indicating the next level protocol (Figure 1, Path 2). After the HC schemes, which will facilitate their operation overprocess completes, IPsec SAs. (Section 5.2.1) Hop-by-hopprocessing 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 schemes usedata item retrieved from the underlying link layer (e.g., PPP)SAD entry will indicate if traffic traversing the SA is handed to negotiatethe HC channel parametersmodule (RFC4301, Section 5.2, Step 3a). Packets traversing an HC-disabled SA must follow normal IPsec processing and must not be sent to indicatethe type of compressed packetHC module. Conversely, packets traversing an HC-enabled SA must be sent to the data-link layer frame is encapsulating. To removeHC scheme dependencies onmodule. The decision at block B then determines if the underlying link layer, two additional work items are proposed: b. Initialization and Negotiation of"Next Header" field contains 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"compressed header" value, which indicates that encapsulate and identifythe packet's payload contains compressed header packets, as well as how these mechanisms will operate. (Section 5.2.3) Note: (c)headers. If "compressed headers" is still being discussed withinindicated, the community andappropriate decompression profile is subject to change. More information about (c) can be found inapplied (Figure 1, Path 1). However, if the "Alternatives to Achieving HCoIPsec" internet-draft, a document being used to help resolve HCoIPsec discussions and issuespacket'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 order to stabilizeSection 5.2, Step 4 of RFC 4301(specifically "Then match the HCoIPsec draft. 6.2.1.packet against the inbound selectors identified by the SAD ..."). 6.1.1. Header Compression Scheme-Specific Extensions a. HCoIPsec should minimizeScheme Considerations Traditional hop-by-hop HC scheme performance degradation dueschemes must be extended to operate efficiently over IPsec SAs. Implementation considerations for this includes increasing tolerance to increased delays,packet loss, jitter, andreordering eventsand packet loss between the compressor and decompressor. b. HCoIPsec should minimizedecompressor, and minimizing the amount of HC signaling between compressor and decompressor. c. HCoIPsec should support bi-directional communications functionality, used by certain HC schemes (e.g. ROHC bi- directional mode). The intention of (b) is to indicate that if afeedback channelsent from the decompressor to the compressor. The ability to tolerate increased packet reordering between the compressor and decompressor 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 modea necessity for any HC scheme that is instantiatedextended to operate over an IPsec tunnel modeSA. Any feedback sent fromThe following provides a summary of the decompressorcandidate HC solutions, and their tolerance to packet loss and reordering between the compressor may be tunneled,and therefore, the additional overhead incurred by tunneling the feedback will reduce the overall benefits of HC. Note that if a HCoIPsec session requires bidirectional communication between the compressor and the decompressor (e.g., a ROHC session operating in bidirectional-reliable mode, or bidirectional-optimistic mode, or ECRTP and CONTEXT_STATE packets), this may pose an issue, given that SAs are unidirectional, and that HCoIPsec definesdecompressor: o IPHC has been identified as a HC contextscheme that performs poorly over long round trip time (RTT), high BER links [ROHC]. Extensions to be specificIPHC to a given SA. Any feedbackcompress TCP/IP headers over an IPsec SA should take into consideration longer RTTs, increased potential for packet communicated from the HCoIPsec decompressor toreordering and IPLR between the HCoIPseccompressor is overand decompressor. o CRTP has also been identified as a separate SA backHC scheme that performs poorly over long RTT, high BER links [CRTPE]. Recent modifications to the original IPsec device. To identify the stale context, the feedback packet must contain the context ID as wellCRTP scheme, such as an indication of the SA thatECRTP, enable the decompressor is associated to. This poses a problem for currentCRTP HC algorithm feedback packets, which are not structuredscheme to carrytolerate long RTTs and packet loss between the additional SA indication information. For example, current ECRTP feedback mechanisms (e.g., CONTEXT_STATE) only listcompressor and decompressor. However, the CIDs for which synchronization has been lost. If a bidirectional HC algorithm isreordering tolerance of ECRTP still needs to be integrated with IPsec, additional HC scheme-specific extensions mustevaluated, as detailed in [ECRTPE]. Such implementation aspects should be definedtaken into consideration when extending ECRTP to resolve this issue. 6.2.2. Initialization and Negotiation of Header Compression Channel Initialization of theoperate over IPsec SAs. o ROHC is a robust HC channel will be achieved manually (i.e., administratively configuredscheme that is designed for manual SAs), or will be performed by IPsec SA establishment protocols, e.g. IKE. During SA initialization, the type of HC scheme configured for the SA, as well as the HC scheme's channel parameters willhigh BER, long RTT links. ROHC can be identified. a. HCoIPsec may leverage IKE, IKEv2 to negotiate HC channel parameters (e.g., for ROHC, IKE(v2) shall initialize PROFILES, MAX_CID, MAX_HEADER, MRRU). b. HCoIPsec must allow packets with uncompressed headers and packets with compressed headers to traverse a single SA. "Packets with compressed headers" refer to packets which are selected to an HC- enabled SA, are passed to the compressor, and are actually compressed; "packets with uncompressed headers" refer to packets which are selectedused to an HC-enabled SA, are passedcompress not only RTP/UDP/IP headers, but also other traffic profiles such as TCP/IP, as defined in [ROHCTCP]. Similar to the compressor,CRTP and are not "compressed" (e.g.,IPHC, ROHC compressor processes ahas been identified as vulnerable to packet withreordering events between the uncompressed profile). Note: (b) is necessary in situations where a compressor--can not compress a flow (e.g., acompressor supports strictly n compressed flows,and can not compress the n+1 flowdecompressor[ROHCE]. Recent work [ROHCWEXT] suggests that arrives). Note: (b) is still being discussed withinthe community and is subject to change. More information about (b)implementation aspects of ROHC can be found in the "Alternativesmodified to Achieving HCoIPsec" internet-draft, a document being usedachieve tolerance to help resolve HCoIPsec discussions and issues in orderpacket reordering events. Such implementation aspects should be taken into consideration when extending ROHC to stabilizeoperate over IPsec SAs. In addition, HC schemes should minimize the HCoIPsec draft. 6.2.3. Encapsulation and Identificationamount of Header Compressed Packets For indication purposes,feedback between decompressor and compressor. If a one-byte header may be added to the compressed packet; this field will helpfeedback channel from the decompressor identify how to process the compressed packet. This one-byte header is only relevantto the HC compression and decompression processes, andcompressor is not used by IPsec.. a. HCoIPsec must indicatesparingly, the type of compressed packet (e.g., for ECRTP, COMPRESSED_RTP_8, COMPRESSED_RTP_16, CONTEXT_STATE, etc.) on a per packet basis. Noteoverall gains from HCoIPsec can be significantly reduced. For example, assume that ROHC indicates its own packet type within the protocol,is operating in bi-directional reliable mode, and does not require a new one-byte header to indicateis instantiated over an IPsec tunnel mode SA. In this scenario, any feedback sent from the type of compressed packet. Note: Alternativesdecompressor to using a "one-byte header" are still being discussed withinthe community, thus this section may change. More information cancompressor must be found intunneled. As such, the "Alternatives to Achieving HCoIPsec" internet-draft, a document being used to help resolve HCoIPsec discussionsadditional overhead incurred by tunneling feedback will reduce the overall benefits of HC. 6.1.2. Initialization and issues in order to stabilizeNegotiation of HC Channel Hop-by-hop HC schemes use the HCoIPsec draft. 7. Candidate Compression Schemes IPHC can be usedunderlying link layer (e.g., PPP) to compress TCP/IP headers for tunnel mode SAs. IPHC, however, has been identified as anegotiate HC channel parameters. To remove 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 need to take into consideration longer RTTs, increased potential for packet reordering and IPLR betweendependencies on the compressor and decompressor. CRTP can be usedunderlying link layer, an additional mechanism is needed to compress RTP/UDP/IP headers for tunnel mode SAs. CRTP, however, has also been identified asinitialize a HC scheme that performs poorly over long RTT, high BER links [CRTPE]. Recent modificationschannel and its associated parameters prior to the CRTP scheme, such as ECRTP, enables the CRTPHC scheme to tolerate long RTTs, packet loss, between compressor and decompressor. The reordering toleranceoperation. Initialization of ECRTP, however, needs tothe HC channel will either be evaluated, as detailed in [ECRTPE]. Such implementation aspects shouldachieved manually (i.e., administratively configured for manual SAs), or be taken into consideration when extending ECRTP to operate betweenperformed by IPsec SA endpoints. ROHC, as defined in RFC 3095, provides a robust HC scheme that is designed for high BER, long RTT links. This makes ROHC another candidate header scheme to operate 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] suggests thatestablishment protocols, e.g. IKEv2. During SA initialization, the implementation aspects of ROHC can be modified to achieve tolerance to packet reordering events. Such implementation aspects shouldSA establishment protocol will be taken into consideration when extending ROHCextended to operate between IPsec SA endpoints.negotiate the HC scheme's channel parameters. The ability to tolerate these network characteristics is a necessityspecifics for any HCoIPsec scheme, and will be a factorthis proposal are detailed in determining how efficientlya separate spectification, "IKEv2/IPsec Extensions to Support HCoIPsec". If the HC scheme operates overrequires bi-directional communications, two SAs must be instantiated between the IPsec tunnel-mode SAs. 8. Example Operation The basic operationimplementations. One of the HCoIPsec protocoltwo SAs is detailed inused for carrying traffic from the following example. Assume there are two IPsec devices operating as security gateways. HCoIPsec leverages an SA establishment protocol (e.g., IKE, IKEv2)compressor to negotiatethe HC scheme, and channel parameters. For example,decompressor, while the MAX_CID, MRRU, MAX_HEADER, and PROFILES parameters will be negotiated for each IPsec SA whichother is capable of ROHC. For anused to communicate feedback from the decompressor to the compressor. IPsec implementations will dictate how decompressor feedback received on one SA thatis ECRTP-enabled, channel parameters including F_MAX_PERIOD, F_MAX_TIME, and the ECRTP Compression Suboption will be initialized. Forassociated with a compressor on the following example, assume thatother SA. 6.1.3. Encapsulation and Identification of Header Compressed Packets As indicated in section 6.1, new state information (i.e., a SA has been established. Outbound packet processingnew HC data item) is as follows.defined for each SA. The packetHC data item is initially processed as described in Steps 1-2, Section 5.1 of RFC 4301. The SPD cache entry then mapsused by the packetIPsec process to determine whether it sends all traffic traversing a given SAD entry, which indicates the HC protocol enabled on theSA (in addition to mode, cryptographic algorithms, keys, etc.). If the SAD entry indicates that compression is disabled, then standard IPsec processing ensues, as described in Steps 3-4, Section 5.1 of RFC 4301. If the SAD entry indicates that compression is enabled, the packet must be handedto the appropriate compressor, which executes the compression process. AfterHC module (HC-enabled) or bypasses the packet's header is compressed,HC module and sends the packet resumes IPsec processing as described in Step 3a, where standardtraffic through regular IPsec ESPprocessing ensues (including packet encryption according to the SAD entry parameters, packet encapsulation with the outer ESP/IP header) and is subsequently passed to(HC-disabled). In addition, the outbound forwarding function, as described in Step 4 of RFC 4301. Inbound packet processing is as follows. The packet is initially processed as described in Steps 1-3, Section 5.2"Next Header" field of RFC 4301; subsequently (usingthe SAD entry selected in Step 3a), ESP processingIPsec security protocol (e.g., AH or ESP) header is applied. Based on information retrievedused to demultiplex header-compressed traffic from the SAD entry, it can also be determined whetheruncompressed traffic traversing the SAan HC-enabled SA. This functionality is compressed orneeded in situations where packets traversing an HC- enabled SA are not compressed. Ifcompressed by the SAD entry indicates that compression iscompressor. Such situations may occur when, for example, a compressor supports strictly n compressed flows and can not enabled on the SA, then standard IPsec processing ofcompress the packet ensues, as described in Step 4, Section 5.2 of RFC 4301. If compressionn+1 flow that arrives. Another example is enabled on the SA, the packetwhen traffic (e.g., TCP/IP) is handedselected to the decompressor for "decompression". Once the packet is decompressed, the processing as described in Step 4, Section 5.2 of RFC 4301 resumes (specifically "Then match the packet against the inbound selectors identifiedan HC-enabled SA, but cannot be compressed by the SAD..."). Figure 1 depictsHC process (e.g., because the basic function of HCoIPsec: -- -- -- -- -- -- -- -- -- -- |ESP Tunnel Mode Security Association| | | | | V V +--------------+ +--------------+ | IPsec Device | +--+ +--+ | IPsec Device | | | | | | | | | +---| Compressor |-->|R1|-->|R2|-->| 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.compressor does not support TCP/IP compression). In these situations, the example scenario, notecompressor must be able to indicate that the inbound and outboundpacket contains uncompressed headers. Similarly, the decompressor must be able to identify packets are first mappedwith uncompressed headers and not attempt to decompress them. Therefore, an SA, and then subsequently mappedallocation for "compressed headers" will need to be reserved from the IANA "Protocol Numbers" registry, which will be defined in a CID. This impliesseparate specification. The "compressed headers" value will indicate that the scope of each CIDnext layer protocol header is contained within each SA. A CID valuecomposed of 1 can be associated with multiple SAs; however, the context state information for CID 1 cannot be shared over multiple SAs. 9. Future Work Items 9.1.compressed headers. 6.2. HCoIPsec Transport Mode SAs Many of the current HC profiles lookFramework Summary [Note 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. ForRFC Editor: this section may be removed on publication as an RFC.] To summarize, the application of HC over transport mode SAs,following items are needed to achieve HCoIPsec: o Extensions to traditional HC schemes may needwhich enable their operation at IPsec SA enpoints o Extensions to be extendedIKE/IPsec to operate strictly on layer 4 (e.g., TCP, and/or RTP/UDP) headers. The specification for HCoIPsec transport mode SAs is leftsupport HC parameter configuration o Allocation of one value for further study. 10."compressed headers" from the IANA "Protocol Numbers" registry 7. Security Considerations A malfunctioning header compressor (i.e., the compressor located at the ingress of the IPsec tunnel; used during outbound processing)tunnel) has the ability to send packets to the decompressor (i.e., the decompressor located at the egress of the IPsec tunnel; used during inbound processing)tunnel) that do not match the original packets emitted from the end-hosts. In such a scenario, the invalid packets will pass through inbound IPsec processing, and will subsequently be validly decompressed. Furthermore, an intruder who has the ability to arbitrarily inject packets between SA endpoints, and addresses these malicious packets to the encryption/decryption devices, has the ability to cause context corruption between the compressor and decompressor processes instantiated within the IPsec device (if the malicious packet passes through the decryption process).Such a scenario will result in a decreased efficiency between compressor and decompressor, and furthermore,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. Note: It should be noted, however, that these security issues are a direct result of IPsec vulnerabilities. 11.8. IANA Considerations None. 12.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. A.Rich Espy of OPnet for their contributions and support for developingin the development of this document. TheIn addition, the authors would alsolike 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. Jan Vilhuber,Vilhuber o Mr. Dan Wing, of Cisco Systems, Mr. Lars-Erik Jonsson andWing o Mr. Kristopher Sandlund of Ericsson for their valuable contributions to this document. TheFinally, the authors would also like to thank Mr. Tom Conkle, Ms. Renee Esposito, Mr. Etzel Brower, Mr. Jigar Amroliwala,and Mr. Dwayne CorbinJonah Pezeshki of Booz Allen Hamilton for their assistance in completing this work. 13.10. References 220.127.116.11. 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. [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. [ROHCWEXT] Pelletier, G. and et. al, "ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006. 18.104.22.168. 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, "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", RFC 4247, November 2005. [AAL2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 AAL", I.363.2 , September 1997.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 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 email@example.com. 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.