IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)
draft-ietf-rohc-ipsec-extensions-hcoipsec-05

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

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 February 13, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC with IPsec, extensions to the SPD and SAD are required. This document describes the IPsec extensions required to support ROHCoIPsec.

Table of Contents

1.  Introduction
2.  Extensions to IPsec Databases
    2.1.  Security Policy Database (SPD)
    2.2.  Security Association Database (SAD)
3.  Extensions to IPsec Processing
    3.1.  Addition to the IANA Protocol Numbers Registry
    3.2.  Verifying the Integrity of Decompressed Packet Headers
        3.2.1.  ICV Computation and Integrity Verification
    3.3.  ROHC Segmentation and IPsec Tunnel MTU
    3.4.  Nested IPComp and ROHCoIPsec Processing
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgments
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  Introduction

Using IPsec ([IPSEC]) protection offers various security services for IP traffic. However, these benefits come at the cost of additional packet headers, which increase packet overhead. As described in [ROHCOIPSEC], Robust Header Compression (ROHC [ROHC]) can be used with IPsec to reduce the overhead associated with IPsec-protected packets.

IPsec-protected traffic is carried over Security Associations (SAs), whose parameters are negotiated on a case-by-case basis. The Security Policy Database (SPD) specifies the services that are to be offered to IP datagrams, and the parameters associated with SAs that have been established are stored in the Security Association Database (SAD). For ROHCoIPsec, various extensions to the SPD and SAD that incorporate ROHC-relevant parameters are required.

In addition, three extensions to IPsec processing are required. First, a mechanism for identifying ROHC packets must be defined. Second, a mechanism to ensure the integrity of the decompressed packet is needed. Finally, the order of the inbound and outbound processing must be enumerated when nesting IP Compression (IPComp [IPCOMP]), ROHC, and IPsec processing.

2.  Extensions to IPsec Databases

The following subsections specify extensions to the SPD and the SAD to support ROHCoIPsec.

2.1.  Security Policy Database (SPD)

In general, the SPD is responsible for specifying the security services that are offered to IP datagrams. Entries in the SPD specify how to derive the corresponding values for SAD entries. To support ROHC, the SPD must be extended to include per-channel ROHC parameters. Together, the existing IPsec SPD parameters and the ROHC parameters will dictate the security and header compression services that are provided to packets.

The fields contained within each SPD entry are defined in [IPSEC], Section 4.4.1.2. To support ROHC, several processing info fields must be added to the SPD; these fields contain information regarding the ROHC profiles and channel parameters supported by the local ROHC instance.

The following ROHC channel parameters must be included if the processing info field in the SPD is set to PROTECT:

MAX_CID: The field indicates the highest context ID that will be decompressed by the local decompressor. MAX_CID must be at least 0 and at most 16383 (The value 0 implies having one context).

MRRU: The MRRU parameter indicates the the size of the largest reconstructed unit (in octets) that the local decompressor is expected to reassemble from ROHC segments. This size includes the CRC and the ROHC ICV. NOTE: Since in-order delivery of ROHC packets cannot be guaranteed, the MRRU parameter is recommended to be set to 0 (as stated in Section 5.2.5.1 of [ROHC] and Section 6.1 of [ROHCV2]), which indicates that no segment headers are allowed on the ROHCoIPsec channel.

PROFILES: This field is a list of ROHC profiles supported by the local decompressor. Possible values for this list are contained in the [ROHCPROF] registry.

In addition to these ROHC channel parameters, a field within the SPD is required to store a list of integrity algorithms supported by the ROHCoIPsec instance:

INTEGRITY ALGORITHM: This field is a list of integrity algorithms supported by the ROHCoIPsec instance. This will be used by the ROHC process to ensure that packet headers are properly decompressed (see Section 3.2). Algorithms that must be supported are specified in Section 3.2 of [CRYPTO-ALG]. More explicitly, the implementation conformance requirements for authentication algorithms are as follows:

   Requirement    Algorithm
   -----------    ----------------
   Must           AUTH_HMAC_SHA1_96
   Should+        AUTH_AES_XCBC_MAC_96
   May            AUTH_HMAC_MD5_96

Several other ROHC channel parameters are omitted from the SPD, because they are set implicitly. The omitted channel parameters are LARGE_CIDS and FEEDBACK_FOR. The LARGE_CIDS channel parameter is set implicitly, based on the value of MAX_CID (e.g. if MAX_CID is <= 15, LARGE_CIDS is assumed to be 0). Finally, the ROHC FEEDBACK_FOR channel parameter is set implicitly to the ROHC channel associated with the SA in the reverse direction. If an SA in the reverse direction does not exist, the FEEDBACK_FOR channel parameter is not set, and ROHC must not operate in bidirectional Mode.

2.2.  Security Association Database (SAD)

Each entry within the SAD defines the parameters associated with each established SA. Unless the "populate from packet" (PFP) flag is asserted for a particular field, SAD entries are determined by the corresponding SPD entries during the creation of the SA.

The data items contained within the SAD are defined in [IPSEC], Section 4.4.2.1. To support ROHC, this list of data items is augmented to include a "ROHC Data Item" that contains the parameters used by ROHC instance. The ROHC Data Item exists for both inbound and outbound SAs.

The ROHC Data Item includes the ROHC channel parameters for the SA. These channel parameters (i.e., MAX_CID, PROFILES, MRRU) are enumerated above in Section 2.1. For inbound SAs, the ROHC Data Item includes ROHC channel parameters that are used by the local decompressor instance; conversely, for outbound SAs, the ROHC Data Item includes ROHC channel parameters that are used by local compressor instance.

In addition to these ROHC channel parameters, the ROHC Data Item for both inbound and outbound SAs includes two additional parameters. Specifically, these parameters store the integrity algorithm and respective key used by ROHC (see Section 3.2). The integrity algorithm and its associated key are used to calculate a ROHC ICV; this ICV is used to verify the packet headers post-decompression.

Finally, for inbound SAs, the ROHC Data Item includes a FEEDBACK_FOR parameter. The parameter is a reference to a ROHC channel in the opposite direction (i.e., the outbound SA) between the same compression endpoints. A ROHC channel associated with an inbound SA and a ROHC channel associated with an outbound SA may be coupled to form a Bi-directional ROHC channel as defined in Section 6.1 and Section 6.2 in [ROHC-TERM].

"ROHC Data Item" values may be initialized manually (i.e., administratively configured for manual SAs), or initialized via a key exchange protocol (e.g. IKEv2 [IKEV2]) that has been extended to support the signaling of ROHC parameters [IKEV2EXT].

3.  Extensions to IPsec Processing

3.1.  Addition to the IANA Protocol Numbers Registry

In order to demultiplex header-compressed from uncompressed traffic on a ROHC-enabled SA, a "ROHC" value must be reserved in the IANA Protocol Numbers registry. If an outbound packet has a compressed header, the Next Header field of the security protocol header (e.g., AH [AH], ESP [ESP]) must be set to the "ROHC" protocol identifier. If the packet header has not been compressed by ROHC, the Next Header field does not contain the "ROHC" protocol identifier. Conversely, for an inbound packet, the value of the security protocol Next Header field is checked to determine if the packet includes a ROHC header, in order to determine if it requires ROHC decompression.

Use of the "ROHC" protocol identifier for purposes other than ROHCOIPsec is currently not defined. Future protocols that make use of the allocation (e.g., other applications of ROHC in multi-hop environments) require specification of the logical compression channel between the ROHC compressor and decompressor. In addition, these specifications will require the investigation of the security considerations associated with use of the "ROHC" protocol identifier outside the context of the next-header field of security protocol headers.

3.2.  Verifying the Integrity of Decompressed Packet Headers

Since ROHC is inherently a lossy compression algorithm, ROHCoIPsec may use an additional Integrity Algorithm (and respective key) to compute a second Integrity Check Value (ICV) for the uncompressed packet. This ICV is computed over the uncompressed IP header, as well at the higher-layer headers and the packet payload, and is appended to the ROHC-compressed packet. At the decompressor, the decompressed packet (including the uncompressed IP header, higher-layer headers, and packet payload; but not including the authentication data) will be used with the integrity algorithm (and its respective key) to compute a value that will be compared to the appended ICV. If these values are not identical, the decompressed packet must be dropped by the decompressor.

Figure 1 illustrates the composition of a ROHCoIPsec-processed IPv4 packet. In the example, TCP/IP compression is applied, and the packet is processed with tunnel mode ESP.

             BEFORE COMPRESSION AND APPLICATION OF ESP
             ----------------------------
       IPv4  |orig IP hdr  |     |      |
             |(any options)| TCP | Data |
             ----------------------------

	      AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP
            ------------------------------------------------------
      IPv4  | new IP hdr  |     | Cmpr. |    | ROHC | ESP   | ESP|
            |(any options)| ESP | Hdr.  |Data| ICV  |Trailer| ICV|
            ------------------------------------------------------

Figure 1. Example of a ROHCoIPsec-processed packet.

Note: The authentication data must not be included in the calculation of the ICV.

3.2.1.  ICV Computation and Integrity Verification

In order to correctly verify the integrity of the decompressed packets, the processing steps for ROHCoIPsec must be implemented in a specific order, as given below.

For outbound packets that are processed by ROHC and IPsec-protected:

• Compute an ICV for the uncompressed packet with the negotiated (ROHC) integrity algorithm and its respective key
• Compress the packet headers (as specified by the ROHC process)
• Append the ICV to the compressed packet
• Apply AH or ESP processing to the packet, as specified in the appropriate SAD entry

For inbound packets that are to be decompressed by ROHC:

• Apply AH or ESP processing, as specified in the appropriate SAD entry
• Remove the ICV from the packet
• Decompress the packet header(s)
• Compute an ICV for the decompressed packet with the negotiated (ROHC) integrity algorithm and its respective key
• Compare the computed ICV to the original ICV calculated at the compressor: if these two values differ, the packet must be dropped; otherwise resume IPsec processing

3.3.  ROHC Segmentation and IPsec Tunnel MTU

In certain scenarios, a ROHCoIPsec-processed packet may exceed the size of the IPsec tunnel MTU. [IPSEC] currently stipulates the following for outbound traffic that exceeds the SA PMTU:

       Case 1: Original (cleartext) packet is IPv4 and has the DF
               bit set.  The implementation should discard the packet
               and send a PMTU ICMP message.

       Case 2: Original (cleartext) packet is IPv4 and has the DF
               bit clear.  The implementation should fragment (before or
               after encryption per its configuration) and then forward
               the fragments.  It should not send a PMTU ICMP message.

       Case 3: Original (cleartext) packet is IPv6.  The implementation
               should discard the packet and send a PMTU ICMP message.

For ROHCOIPsec, Cases 1 and 3, and the post-encryption fragmentation for Case 2 are employed. However, since current ROHC compression profiles do not support the compression of IP packet fragments, pre-encryption fragmentation is not compatible with the current set of ROHC profiles. In place of pre-encryption fragmentation, ROHC segmentation may be used at the compressor to divide the packet, where each segment conforms to the tunnel MTU. However, because in-order delivery of ROHC segments is not guaranteed, the use of ROHC segmentation is not recommended.

If the compressor determines that the compressed packet exceeds the tunnel MTU, ROHC segmentation may be applied to the compressed packet before AH or ESP processing. This determination can be made by comparing the anticipated ROHCoIPsec packet size to the Path MTU data item specified in the SAD entry. If the MRRU for the channel is non-zero, the compressor applies ROHC segmentation. The segmentation process should account for the additional overhead imposed by IPsec process (e.g., AH or ESP overhead, crypto synchronization data, the additional IP header, etc.) such that the final IPsec-processed segments are less than the tunnel MTU. After segmentation, each ROHC segment receives AH or ESP processing.

For channels where the MRRU is non-zero, the ROHCoIPsec decompressor must re-assemble the ROHC segments that are received. To accomplish this, the decompressor must identify the ROHC segments (as documented in Section 5.2.6 of [ROHC]), and attempt reconstruction using the ROHC segmentation protocol (Section 5.2.5 of [ROHC]). If reconstruction fails, the packet must be discarded.

As stated in Section 3.2.1, if the ROHC integrity algorithm is used to verify the decompression of packet headers, this ICV is appended to the compressed packet. If ROHC segmentation is performed, the segmentation algorithm is executed on the compressed packet and the appended ICV. Note that the ICV is not appended to each ROHC segment.

3.4.  Nested IPComp and ROHCoIPsec Processing

IPComp ([IPCOMP]) is another mechanism that can be implemented to reduce the size of an IP datagram. If IPComp and ROHCoIPsec are implemented in a nested fashion, the following steps must be followed for outbound and inbound packets.

For outbound packets that are to be processed by IPcomp and ROHC:

• The ICV is computed for the uncompressed packet, and the appropriate ROHC compression profile is applied to the packet
• IPComp is applied, and the packet is sent to the IPsec process
• The security protocol is applied to the packet

Conversely, for inbound packets that are to be both ROHC- and IPcomp-decompressed:

• A packet received on a ROHC-enabled SA is IPsec-processed
• The datagram is decompressed based on the appropriate IPComp algorithm
• The packet is sent to the ROHC module for header decompression and integrity verification

4.  Security Considerations

A ROHCoIPsec implementer should consider the strength of protection provided by the integrity check algorithm used to verify the valid decompression of ROHC-compressed packets. Failure to implement a strong integrity check algorithm increases the probability of an invalidly decompressed packet to be forwarded by a ROHCoIPsec device into a protected domain.

The implementation of ROHCoIPsec may increase the susceptibility for traffic flow analysis, where an attacker can identify new traffic flows by monitoring the relative size of the encrypted packets (i.e. a group of "long" packets, followed by a long series of "short" packets may indicate a new flow for some ROHCoIPsec implementations). To mitigate this concern, ROHC padding mechanisms may be used to arbitrarily add padding to transmitted packets to randomize packet sizes. This technique, however, reduces the overall efficiency benefit offered by header compression.

5.  IANA Considerations

IANA is requested to allocate one value within the "Protocol Numbers" registry [PROTOCOL] for "ROHC". This value will be used to indicate that the next level protocol header is a ROHC header.

6.  Acknowledgments

The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, Ms. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of OPnet for their contributions and support for developing this document.

The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A Stangarone Jr.: both served as committed document reviewers for this specification.

Finally, the authors would like to thank the following for their numerous reviews and comments to this document:

• Mr. Magnus Westerlund
• Dr. Stephen Kent
• Mr. Lars-Erik Jonsson
• Mr. Carl Knutsson
• Mr. Pasi Eronen
• Dr. Jonah Pezeshki
• Mr. Tero Kivinen
• Dr. Joseph Touch
• Mr. Rohan Jasani

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses