Integration of Robust Header Compression (ROHC) over IPsec Security Associations
draft-ietf-rohc-hcoipsec-09

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 April 17, 2009.

Abstract

IP Security (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 (ROHC) over IPsec (ROHCoIPsec). By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs).

Table of Contents

1.  Introduction
2.  Audience
3.  Terminology
4.  Problem Statement: IPsec Packet Overhead
5.  Overview of the ROHCoIPsec Framework
5.1.  ROHCoIPsec Assumptions
5.2.  Summary of the ROHCoIPsec Framework
6.  Details of the ROHCoIPsec Framework
6.1.  ROHC and IPsec Integration
6.1.1.  Header Compression Protocol Considerations
6.1.2.  Initialization and Negotiation of the ROHC Channel
6.1.3.  Encapsulation and Identification of Header Compressed Packets
6.2.  ROHCoIPsec Framework Summary
7.  Security Considerations
8.  IANA Considerations
9.  Acknowledgments
10.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

This document outlines a framework for integrating ROHC [ROHC] over IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec 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 ROHCoIPsec, this document assumes that ROHC will be used to compress the inner headers of IP packets traversing an IPsec tunnel. However, since current specifications for ROHC detail its operation on a hop-by-hop basis, it may require extensions to enable its operation over IPsec SAs. These extensions need to account for increased packet reordering and packet loss that may occur in the unprotected domain. This document outlines a framework for extending the usage of ROHC to operate at IPsec SA endpoints.

ROHCoIPsec targets the application of ROHC 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 ROHC 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 do not include support for the compression of transport layer headers alone, the ROHCoIPsec framework outlined by this document describes the application of ROHC to tunnel mode SAs.

2.  Audience

The authors target members of both the ROHC and IPsec communities who may consider extending the ROHC and IPsec protocols to meet the requirements put forth in this document. 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 ROHCoIPsec is introduced in this section.

ROHC Process

Generic reference to a ROHC instance (as defined in [ROHC-TERM]), or any supporting ROHC components.

Compressed Traffic

Traffic that is processed by the ROHC compressor instance. Packet headers are compressed using a specific header compression protocol.

Uncompressed Traffic

Traffic that is not processed by the ROHC compressor instance. Instead, this type of traffic bypasses the ROHC process.

IPsec Process

Generic reference to the Internet Protocol Security (IPsec) process.

Next Header

Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) 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 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. ROHC applied on a per-hop basis over bandwidth-constrained links 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 (e.g. various voice codecs). 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 ROHCoIPsec Framework

5.1.  ROHCoIPsec Assumptions

The goal of ROHCoIPsec is to provide efficient transport of IP packets between IPsec devices, without compromising the security services offered by IPsec. The ROHCoIPsec framework has been developed based on the following assumptions:

• ROHC will be leveraged to reduce the amount of overhead associated with packets traversing an IPsec SA

• ROHC will be instantiated at the IPsec SA endpoints, and will be applied on a per-SA basis

• Once the decompression operation completes, decompressed packet headers will be identical to the original packet headers before compression

5.2.  Summary of the ROHCoIPsec Framework

ROHC reduces packet overhead in a network by exploiting intra- and inter-packet redundancies of network and transport-layer header fields of a flow.

Current ROHC protocol specifications compress packet headers on a hop-by-hop basis. However, IPsec SAs are instantiated between two IPsec endpoints. Therefore, various extensions to both ROHC and IPsec need to be defined to ensure the successful operation of the ROHC protocol at IPsec SA endpoints.

The migration of ROHC over IPsec SAs is straightforward, since SA endpoints provide source/destination pairs where (de)compression operations can take place. Compression of the inner IP and upper layer protocol headers in such a manner offers a reduction of per-packet protocol overhead between the two SA endpoints. Since ROHC will now operate between IPsec endpoints (over multiple intermediate nodes which are transparent to an IPsec SA), it is imperative to ensure that its performance will not be severely impacted due to increased packet reordering and/or packet loss between the compressor and decompressor.

In addition, ROHC can no longer rely on the underlying link layer for ROHC parameter configuration and packet identification. The ROHCoIPsec framework proposes that ROHC channel parameter configuration is accomplished by an SA management protocol (e.g., IKEv2 [IKEV2]), while identification of compressed header packets is achieved through the Next Header field of the security protocol (e.g., AH [AH], ESP [ESP]) header.

Using the ROHCoIPsec framework proposed below, outbound and inbound IP traffic processing at an IPsec device needs to be modified. For an outbound packet, a ROHCoIPsec implementation will 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. For inbound packets, an IPsec device must first decrypt and/or integrity-check the packet. Then 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. ROHC is capable of compressing the security protocol and the outer IP header on a hop-by-hop basis. The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4 ESP-processed packet [ESP] is shown below in Figure 1.

            -----------------------------------------------------------
      IPv4  | new IP hdr  |     | orig IP hdr   |   |    | ESP   | ESP|
            |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
            -----------------------------------------------------------
            |<-------(1)------->|<------(2)-------->|

            (1) Compressed by ROHC ESP/IP profile
            (2) Compressed by ROHCoIPsec TCP/IP profile

Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an IPv4 ESP-processed packet.

If IPsec NULL encryption is applied to packets, ROHC may still be applied to the inner headers at the IPsec SA endpoints. However, in these scenarios, intermediary devices (within the unprotected domain) inspecting ESP-NULL encrypted packets will be unable to determine the content of these packets since they are unable to parse ROHC-compressed headers.

6.  Details of the ROHCoIPsec Framework

6.1.  ROHC and IPsec Integration

Figure 2 illustrates the components required to integrate ROHC with the IPsec process, i.e., ROHCoIPsec.

               +-------------------------------+
               | ROHC Module                   |
               |                               |
               |                               |
     +-----+   |     +-----+     +---------+   |
     |     |   |     |     |     |  ROHC   |   |
   --|  A  |---------|  B  |-----| Process |------> Path 1
     |     |   |     |     |     |         |   |   (ROHC-enabled SA)
     +-----+   |     +-----+     +---------+   |
        |      |        |                      |
        |      |        |-------------------------> Path 2
        |      |                               |   (ROHC-enabled SA)
        |      +-------------------------------+
        |
        |
        |
        |
        +-----------------------------------------> Path 3
                                                   (ROHC-disabled SA)

Figure 2. Integration of ROHC with IPsec.

The process illustrated in Figure 2 augments the IPsec processing model for outbound IP traffic (protected-to-unprotected). Initial IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1).

Block A: The ROHC 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 ROHC module. Packets selected to a ROHC-disabled SA must follow normal IPsec processing and must not be sent to the ROHC module (Figure 1, Path 3). Conversely, packets selected to a ROHC-enabled SA must be sent to the ROHC module.

Block B: This step determines if the packet can be compressed. If it is determined that the packet will be compressed, an Integrity Algorithm is used to compute an Integrity Check Value (ICV) for the uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section 2.1). The Next Header field of the security protocol header (e.g., ESP, AH) is populated with a "ROHC" identifier, the packet headers are compressed, and the computed ICV is appended to the packet (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 ROHC process completes, IPsec processing resumes, as described in Section 5.1, Step3a, of [IPSEC].

The process illustrated in Figure 2 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).

Block A: After AH or ESP processing, the ROHC data item retrieved from the SAD entry will indicate if traffic traversing the SA is processed by the ROHC module ([IPSEC], Section 5.2, Step 3a). Packets traversing an ROHC-disabled SA must follow normal IPsec processing and must not be sent to the ROHC module. Conversely, packets traversing an ROHC-enabled SA must be sent to the ROHC module.

Block B: The decision at Block B is determined by the value of the Next Header field of the security protocol header. If the Next Header field does not indicate a ROHC header, the decompressor must not attempt decompression (Figure 1, Path 2). If the Next Header field indicates a ROHC header, decompression is applied. After decompression, the ROHCoIPsec Integrity Algorithm is used to compute an ICV value for the decompressed packet. This ICV is compared to the ICV that was calculated at the compressor: if the ICVs match, the packet is forwarded by the ROHC module (Figure 1, Path 1); otherwise, the packet is dropped. Once the ROHC module completes processing, IPsec processing resumes, as described in Section 5.2, Step 4 of [IPSEC].

Note that to further reduce the size of an IPsec-protected packet, ROHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested fashion. This process is detailed in [IPSEC-ROHC], Section 3.2.

6.1.1.  Header Compression Protocol Considerations

ROHCv2 [ROHCV2] profiles include various mechanisms that provide increased robustness over reordering channels. These mechanisms must be adopted for ROHC to operate efficiently over IPsec SAs.

A ROHC decompressor implemented within IPsec architecture may leverage additional mechanisms to improve performance over reordering channels (either due to random events, or to an attacker intentionally reordering packets). Specifically, IPsec's sequence number may be used by the decompressor to identify a packet as "sequentially late". This knowledge will increase the likelihood of successful decompression of a reordered packet.

Additionally, ROHCoIPsec implementations should minimize the amount of feedback sent from the decompressor to the compressor. If a ROHC feedback channel is not used sparingly, the overall gains from ROHCoIPsec can be significantly reduced. More specifically, any feedback sent from the decompressor to the compressor must be processed by IPsec, and tunneled back to the compressor (as designated by the SA associated with FEEDBACK_FOR). As such, several implementation considerations are offered:

• Eliminate feedback traffic altogether by operating only in ROHC Unidirectional mode (U-mode)

• Piggyback ROHC feedback messages on traffic that normally traverses the SA designated by FEEDBACK_FOR.

6.1.2.  Initialization and Negotiation of the ROHC Channel

Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) to negotiate ROHC channel parameters. In the case of ROHCoIPsec, channel parameters can be set manually (i.e., administratively configured for manual SAs), or negotiated by IKEv2. The extensions required for IKEv2 to support ROHC parameter negotiation are detailed in [IKE-ROHC].

If the ROHC protocol requires bi-directional communications, two SAs must be instantiated between the IPsec implementations. One of the two SAs is used for carrying ROHC-traffic from the compressor to the decompressor, while the other is used to communicate ROHC-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 by default. However, IPsec implementations will dictate how decompressor feedback received on one SA is associated with a compressor on the other SA. An IPsec implementation must relay the feedback received by the decompressor on an inbound SA to the compressor associated with the corresponding outbound SA.

6.1.3.  Encapsulation and Identification of Header Compressed Packets

As indicated in Section 6.1, new state information (i.e., a new ROHC data item) is defined for each SA. The ROHC data item is used by the IPsec process to determine whether it sends all traffic traversing a given SA to the ROHC module (ROHC-enabled) or bypasses the ROHC module and sends the traffic through regular IPsec processing (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 ROHC-enabled SA. This functionality is needed in situations where packets traversing a 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 a ROHC-enabled SA, but cannot be compressed by the ROHC process (e.g., because the compressor does not support TCP/IP compression). 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 ROHC protocol identifier will indicate that the packet contains compressed headers. To accomplish this, an official IANA allocation from the Protocol ID registry [PROTOCOL] is required.

The ROHC Data Item, IANA Protocol ID allocation, and other IPsec extensions to support ROHCoIPsec, are specified in [IPSEC-ROHC].

6.2.  ROHCoIPsec Framework Summary

To summarize, the following items are needed to achieve ROHCoIPsec:

• IKEv2 Extensions to Support ROHCoIPsec
• IPsec Extensions to Support ROHCoIPsec

7.  Security Considerations

A malfunctioning ROHC 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:

• Dr. Stephen Kent
• Mr. Pasi Eronen
• Dr. Joseph Touch
• Mr. Tero Kivinen
• Mr. Yoav Nir
• Mr. Lars-Erik Jonsson
• Mr. Jan Vilhuber
• Mr. Dan Wing
• Mr. Kristopher Sandlund
• Mr. Ghyslain Pelletier

Finally, the authors would also like to thank Mr. Tom Conkle, Ms. Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen Hamilton for their assistance in completing this work.

10. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2008).

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 ietf-ipr@ietf.org.