IPsec Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)Booz Allen Hamilton13200 Woodland Park Dr.HerndonVA20171USertekin_emre@bah.comBooz Allen Hamilton13200 Woodland Park Dr.HerndonVA20171USchristou_chris@bah.comUniversitaet Bremen TZIPostfach 330440Bremen D-28334Germanycabo@tzi.org
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.
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.
The following subsections specify extensions to the SPD and the SAD
to support ROHCoIPsec.
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
(suggested values for these parameters are consistent with [ROHCPPP]):
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).
The suggested value for MAX_CID is 15.
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).
Several other ROHC channel parameters are omitted from the SPD,
because they are set implicitly. The omitted channel parameters are
LARGE_CIDS, MRRU, 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). Furthermore, since
in-order delivery of ROHC packets cannot be guaranteed, the
MRRU parameter must be set to 0 (as stated in Section 5.2.5.1 of [ROHC]
and Section 6.1 of [ROHCV2]). 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.
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) 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].
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, the Next Header field
remains unaltered. 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.
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.
Note: The authentication data must not be included in the calculation of the ICV.
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 to be processed by ROHC:
An ICV is computed for the uncompressed packet via ROHCoIPsec's Integrity Algorithm (and respective key)
The packet header(s) is(are) compressed by the ROHC process
The ICV is appended to the end of the compressed packet
The security protocol is applied to the packet
For inbound packets that are to be decompressed by ROHC:
A packet received on a ROHC-enabled SA is IPsec-processed
Packet header(s) is(are) decompressed by the ROHC process
The decompressed packet is used with the integrity algorithm (and its respective key) to compute a ROHC ICV that is compared to the appended ICV (if these two values differ, the packet is dropped)
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
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.
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.
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:Dr. Stephen KentMr. Lars-Erik JonssonMr. Carl KnutssonMr. Pasi EronenDr. Jonah PezeshkiMr. Tero KivinenDr. Joseph TouchMr. Rohan JasaniSecurity Architecture for the Internet Protocol The RObust Header Compression (ROHC) FrameworkRObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-LiteIP Payload Compression Protocol (IPComp)Robust Header Compression (ROHC) over PPPInternet Key Exchange (IKEv2) ProtocolExtensions to IKEv2 to Support Robust Header Compression over IPsec (ROHCoIPsec)IP Authentication HeaderIP Encapsulating Security Payload (ESP)Integration of Header Compression over IPsec Security AssociationsRObust Header Compression (ROHC) Profile IdentifiersRobust Header Compression (ROHC): Terminology and Channel Mapping Examples"Assigned Internet Protocol Numbers", IANA registry at: http://www.iana.org/assignments/protocol-numbers