draft-ietf-rohc-ipsec-extensions-hcoipsec-05.txt   draft-ietf-rohc-ipsec-extensions-hcoipsec-06.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Expires: February 13, 2010 Booz Allen Hamilton Expires: June 7, 2010 Booz Allen Hamilton
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
August 12, 2009 December 4, 2009
IPsec Extensions to Support Robust Header Compression over IPsec IPsec Extensions to Support Robust Header Compression over IPsec
(ROHCoIPsec) (ROHCoIPsec)
draft-ietf-rohc-ipsec-extensions-hcoipsec-05 draft-ietf-rohc-ipsec-extensions-hcoipsec-06
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 13, 2010. This Internet-Draft will expire on June 7, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Integrating ROHC with IPsec (ROHCoIPsec) offers the combined benefits This document may contain material from IETF Documents or IETF
of IP security services and efficient bandwidth utilization. Contributions published or made publicly available before November
However, in order to integrate ROHC with IPsec, extensions to the SPD 10, 2008. The person(s) controlling the copyright in some of this
and SAD are required. This document describes the IPsec extensions material may not have granted the IETF Trust the right to allow
required to support ROHCoIPsec. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 3 3. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 3
2.2. Security Association Database (SAD) . . . . . . . . . . . 5 3.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 3
3. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 5 3.2. Security Association Database (SAD) . . . . . . . . . . . 5
3.1. Addition to the IANA Protocol Numbers Registry . . . . . . 5 4. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 6
3.2. Verifying the Integrity of Decompressed Packet Headers . . 6 4.1. Addition to the IANA Protocol Numbers Registry . . . . . . 6
3.2.1. ICV Computation and Integrity Verification . . . . . . 7 4.2. Verifying the Integrity of Decompressed Packet Headers . . 6
3.3. ROHC Segmentation and IPsec Tunnel MTU . . . . . . . . . . 7 4.2.1. ICV Computation and Integrity Verification . . . . . . 7
3.4. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . 9 4.3. ROHC Segmentation and IPsec Tunnel MTU . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4.4. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 Appendix A. ASN.1 representation for ROHCoIPsec . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Using IPsec ([IPSEC]) protection offers various security services for Using IPsec ([IPSEC]) protection offers various security services for
IP traffic. However, these benefits come at the cost of additional IP traffic. However, these benefits come at the cost of additional
packet headers, which increase packet overhead. As described in packet headers, which increase packet overhead. As described in
[ROHCOIPSEC], Robust Header Compression (ROHC [ROHC]) can be used [ROHCOIPSEC], Robust Header Compression (ROHC [ROHC]) can be used
with IPsec to reduce the overhead associated with IPsec-protected with IPsec to reduce the overhead associated with IPsec-protected
packets. packets.
skipping to change at page 3, line 29 skipping to change at page 4, line 29
(SAD). For ROHCoIPsec, various extensions to the SPD and SAD that (SAD). For ROHCoIPsec, various extensions to the SPD and SAD that
incorporate ROHC-relevant parameters are required. incorporate ROHC-relevant parameters are required.
In addition, three extensions to IPsec processing are required. In addition, three extensions to IPsec processing are required.
First, a mechanism for identifying ROHC packets must be defined. First, a mechanism for identifying ROHC packets must be defined.
Second, a mechanism to ensure the integrity of the decompressed Second, a mechanism to ensure the integrity of the decompressed
packet is needed. Finally, the order of the inbound and outbound packet is needed. Finally, the order of the inbound and outbound
processing must be enumerated when nesting IP Compression (IPComp processing must be enumerated when nesting IP Compression (IPComp
[IPCOMP]), ROHC, and IPsec processing. [IPCOMP]), ROHC, and IPsec processing.
2. Extensions to IPsec Databases 2. Terminology
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 [BRA97].
3. Extensions to IPsec Databases
The following subsections specify extensions to the SPD and the SAD The following subsections specify extensions to the SPD and the SAD
to support ROHCoIPsec. that MUST be supported for ROHCoIPsec. Appendix A provides an
example ASN.1 representation of the ROHC parameters that are included
in the SPD.
2.1. Security Policy Database (SPD) 3.1. Security Policy Database (SPD)
In general, the SPD is responsible for specifying the security In general, the SPD is responsible for specifying the security
services that are offered to IP datagrams. Entries in the SPD services that are offered to IP datagrams. Entries in the SPD
specify how to derive the corresponding values for SAD entries. To specify how to derive the corresponding values for SAD entries. To
support ROHC, the SPD must be extended to include per-channel ROHC support ROHC, the SPD is extended to include per-channel ROHC
parameters. Together, the existing IPsec SPD parameters and the ROHC parameters. Together, the existing IPsec SPD parameters and the ROHC
parameters will dictate the security and header compression services parameters will dictate the security and header compression services
that are provided to packets. that are provided to packets.
The fields contained within each SPD entry are defined in [IPSEC], The fields contained within each SPD entry are defined in RFC 4301
Section 4.4.1.2. To support ROHC, several processing info fields [IPSEC], Section 4.4.1.2. To support ROHC, several processing info
must be added to the SPD; these fields contain information regarding fields are added to the SPD; these fields contain information
the ROHC profiles and channel parameters supported by the local ROHC regarding the ROHC profiles and channel parameters supported by the
instance. local ROHC instance.
The following ROHC channel parameters must be included if the If the processing action associated with the selector sets is
processing info field in the SPD is set to PROTECT: PROTECT, then the processing info must be extended with the following
ROHC channel parameters:
MAX_CID: The field indicates the highest context ID that will be MAX_CID: The field indicates the highest context ID that will be
decompressed by the local decompressor. MAX_CID must be at least decompressed by the local decompressor. MAX_CID MUST be at least
0 and at most 16383 (The value 0 implies having one context). 0 and at most 16383 (The value 0 implies having one context).
MRRU: The MRRU parameter indicates the the size of the largest MRRU: The MRRU parameter indicates the size of the largest
reconstructed unit (in octets) that the local decompressor is reconstructed unit (in octets) that the local decompressor is
expected to reassemble from ROHC segments. This size includes the expected to reassemble from ROHC segments. This size includes the
CRC and the ROHC ICV. NOTE: Since in-order delivery of ROHC CRC and the ROHC ICV. NOTE: Since in-order delivery of ROHC
packets cannot be guaranteed, the MRRU parameter is recommended to packets cannot be guaranteed, the MRRU parameter SHOULD be set to
be set to 0 (as stated in Section 5.2.5.1 of [ROHC] and Section 0 (as stated in Section 5.2.5.1 of RFC 4995 [ROHC] and Section 6.1
6.1 of [ROHCV2]), which indicates that no segment headers are of RFC 5225 [ROHCV2]), which indicates that no segment headers are
allowed on the ROHCoIPsec channel. allowed on the ROHCoIPsec channel.
PROFILES: This field is a list of ROHC profiles supported by the PROFILES: This field is a list of ROHC profiles supported by the
local decompressor. Possible values for this list are contained local decompressor. Possible values for this list are contained
in the [ROHCPROF] registry. in the ROHC Profile Identifiers registry [ROHCPROF].
In addition to these ROHC channel parameters, a field within the SPD In addition to these ROHC channel parameters, a ROHC Integrity
is required to store a list of integrity algorithms supported by the Algorithm and a ROHC ICV Length field MUST be included within the
ROHCoIPsec instance: SPD:
INTEGRITY ALGORITHM: This field is a list of integrity algorithms ROHC INTEGRITY ALGORITHM: This field is a list of integrity
supported by the ROHCoIPsec instance. This will be used by the algorithms supported by the ROHCoIPsec instance. This will be
ROHC process to ensure that packet headers are properly used by the ROHC process to ensure that packet headers are
decompressed (see Section 3.2). Algorithms that must be supported properly decompressed (see Section 4.2). Authentication
are specified in Section 3.2 of [CRYPTO-ALG]. More explicitly, algorithms that MUST be supported are specified in the
the implementation conformance requirements for authentication "Authentication Algorithms" table in section 3.1.1 ("ESP
algorithms are as follows: Encryption and Authentication Algorithms") of RFC 4835 [CRYPTO-
ALG] (or its successor).
Requirement Algorithm ROHC ICV LENGTH: This field specifies the length of the ICV that
----------- ---------------- is used in conjunction with the ROHC Integrity 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, Several other ROHC channel parameters are omitted from the SPD,
because they are set implicitly. The omitted channel parameters are because they are set implicitly. The omitted channel parameters are
LARGE_CIDS and FEEDBACK_FOR. The LARGE_CIDS channel parameter is set LARGE_CIDS and FEEDBACK_FOR. The LARGE_CIDS channel parameter MUST
implicitly, based on the value of MAX_CID (e.g. if MAX_CID is <= 15, be set 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 LARGE_CIDS is assumed to be 0). Finally, the ROHC FEEDBACK_FOR
channel parameter is set implicitly to the ROHC channel associated channel parameter MUST be set to the ROHC channel associated with the
with the SA in the reverse direction. If an SA in the reverse SA in the reverse direction. If an SA in the reverse direction does
direction does not exist, the FEEDBACK_FOR channel parameter is not not exist, the FEEDBACK_FOR channel parameter is not set, and ROHC
set, and ROHC must not operate in bidirectional Mode. MUST NOT operate in bidirectional Mode.
2.2. Security Association Database (SAD) 3.2. Security Association Database (SAD)
Each entry within the SAD defines the parameters associated with each Each entry within the SAD defines the parameters associated with each
established SA. Unless the "populate from packet" (PFP) flag is established SA. Unless the "populate from packet" (PFP) flag is
asserted for a particular field, SAD entries are determined by the asserted for a particular field, SAD entries are determined by the
corresponding SPD entries during the creation of the SA. corresponding SPD entries during the creation of the SA.
The data items contained within the SAD are defined in [IPSEC], The data items contained within the SAD are defined in RFC 4301
Section 4.4.2.1. To support ROHC, this list of data items is [IPSEC], Section 4.4.2.1. To support ROHC, the SAD must include a
augmented to include a "ROHC Data Item" that contains the parameters "ROHC Data Item"; this data item contains parameters used by ROHC
used by ROHC instance. The ROHC Data Item exists for both inbound instance. The ROHC Data Item exists for both inbound and outbound
and outbound SAs. SAs.
The ROHC Data Item includes the ROHC channel parameters for the SA. The ROHC Data Item includes the ROHC channel parameters for the SA.
These channel parameters (i.e., MAX_CID, PROFILES, MRRU) are These channel parameters (i.e., MAX_CID, PROFILES, MRRU) are
enumerated above in Section 2.1. For inbound SAs, the ROHC Data Item enumerated above in Section 3.1. For inbound SAs, the ROHC Data Item
includes ROHC channel parameters that are used by the local MUST specify the ROHC channel parameters that are used by the local
decompressor instance; conversely, for outbound SAs, the ROHC Data decompressor instance; conversely, for outbound SAs, the ROHC Data
Item includes ROHC channel parameters that are used by local Item MUST specify the ROHC channel parameters that are used by local
compressor instance. compressor instance.
In addition to these ROHC channel parameters, the ROHC Data Item for In addition to these ROHC channel parameters, the ROHC Data Item for
both inbound and outbound SAs includes two additional parameters. both inbound and outbound SAs MUST include three additional
Specifically, these parameters store the integrity algorithm and parameters. Specifically, these parameters store the integrity
respective key used by ROHC (see Section 3.2). The integrity algorithm, the algorithm's respective key, and the ICV length that is
algorithm and its associated key are used to calculate a ROHC ICV; used by the ROHC process (see Section 3.2). The integrity algorithm
this ICV is used to verify the packet headers post-decompression. and its associated key are used to calculate a ROHC ICV of the
specified length; this ICV is used to verify the packet headers post-
decompression.
Finally, for inbound SAs, the ROHC Data Item includes a FEEDBACK_FOR Finally, for inbound SAs, the ROHC Data Item MUST include a
parameter. The parameter is a reference to a ROHC channel in the FEEDBACK_FOR parameter. The parameter is a reference to a ROHC
opposite direction (i.e., the outbound SA) between the same channel in the opposite direction (i.e., the outbound SA) between the
compression endpoints. A ROHC channel associated with an inbound SA same compression endpoints. A ROHC channel associated with an
and a ROHC channel associated with an outbound SA may be coupled to inbound SA and a ROHC channel associated with an outbound SA MAY be
form a Bi-directional ROHC channel as defined in Section 6.1 and coupled to form a Bi-directional ROHC channel as defined in Section
Section 6.2 in [ROHC-TERM]. 6.1 and Section 6.2 in RFC 3759 [ROHC-TERM].
"ROHC Data Item" values may be initialized manually (i.e., "ROHC Data Item" values MAY be initialized manually (i.e.,
administratively configured for manual SAs), or initialized via a key administratively configured for manual SAs), or initialized via a key
exchange protocol (e.g. IKEv2 [IKEV2]) that has been extended to exchange protocol (e.g. IKEv2 [IKEV2]) that has been extended to
support the signaling of ROHC parameters [IKEV2EXT]. support the signaling of ROHC parameters [IKEV2EXT].
3. Extensions to IPsec Processing 4. Extensions to IPsec Processing
3.1. Addition to the IANA Protocol Numbers Registry 4.1. Addition to the IANA Protocol Numbers Registry
In order to demultiplex header-compressed from uncompressed traffic In order to demultiplex header-compressed from uncompressed traffic
on a ROHC-enabled SA, a "ROHC" value must be reserved in the IANA on a ROHC-enabled SA, a "ROHC" value must be reserved in the IANA
Protocol Numbers registry. If an outbound packet has a compressed Protocol Numbers registry. If an outbound packet has a compressed
header, the Next Header field of the security protocol header (e.g., header, the Next Header field of the security protocol header (e.g.,
AH [AH], ESP [ESP]) must be set to the "ROHC" protocol identifier. 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 If the packet header has not been compressed by ROHC, the Next Header
field does not contain the "ROHC" protocol identifier. Conversely, field does not contain the "ROHC" protocol identifier. Conversely,
for an inbound packet, the value of the security protocol Next Header for an inbound packet, the value of the security protocol Next Header
field is checked to determine if the packet includes a ROHC header, field MUST be checked to determine if the packet includes a ROHC
in order to determine if it requires ROHC decompression. header, in order to determine if it requires ROHC decompression.
Use of the "ROHC" protocol identifier for purposes other than Use of the "ROHC" protocol identifier for purposes other than
ROHCOIPsec is currently not defined. Future protocols that make use ROHCOIPsec is currently not defined. Future protocols that make use
of the allocation (e.g., other applications of ROHC in multi-hop of the allocation (e.g., other applications of ROHC in multi-hop
environments) require specification of the logical compression environments) require specification of the logical compression
channel between the ROHC compressor and decompressor. In addition, channel between the ROHC compressor and decompressor. In addition,
these specifications will require the investigation of the security these specifications will require the investigation of the security
considerations associated with use of the "ROHC" protocol identifier considerations associated with use of the "ROHC" protocol identifier
outside the context of the next-header field of security protocol outside the context of the next-header field of security protocol
headers. headers.
3.2. Verifying the Integrity of Decompressed Packet Headers 4.2. Verifying the Integrity of Decompressed Packet Headers
Since ROHC is inherently a lossy compression algorithm, ROHCoIPsec Since ROHC is inherently a lossy compression algorithm, ROHCoIPsec
may use an additional Integrity Algorithm (and respective key) to MAY use an additional Integrity Algorithm (and respective key) to
compute a second Integrity Check Value (ICV) for the uncompressed compute a second Integrity Check Value (ICV) for the uncompressed
packet. This ICV is computed over the uncompressed IP header, as packet. This ICV MUST be computed over the uncompressed IP header,
well at the higher-layer headers and the packet payload, and is as well at the higher-layer headers and the packet payload. When
appended to the ROHC-compressed packet. At the decompressor, the computed, the ICV is appended to the ROHC-compressed packet. At the
decompressed packet (including the uncompressed IP header, higher- decompressor, the decompressed packet (including the uncompressed IP
layer headers, and packet payload; but not including the header, higher-layer headers, and packet payload; but not including
authentication data) will be used with the integrity algorithm (and the authentication data) will be used with the integrity algorithm
its respective key) to compute a value that will be compared to the (and its respective key) to compute a value that will be compared to
appended ICV. If these values are not identical, the decompressed the appended ICV. If these values are not identical, the
packet must be dropped by the decompressor. decompressed packet MUST be dropped.
Figure 1 illustrates the composition of a ROHCoIPsec-processed IPv4 Figure 1 illustrates the composition of a ROHCoIPsec-processed IPv4
packet. In the example, TCP/IP compression is applied, and the packet. In the example, TCP/IP compression is applied, and the
packet is processed with tunnel mode ESP. packet is processed with tunnel mode ESP.
BEFORE COMPRESSION AND APPLICATION OF ESP BEFORE COMPRESSION AND APPLICATION OF ESP
---------------------------- ----------------------------
IPv4 |orig IP hdr | | | IPv4 |orig IP hdr | | |
|(any options)| TCP | Data | |(any options)| TCP | Data |
---------------------------- ----------------------------
AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP
------------------------------------------------------ ------------------------------------------------------
IPv4 | new IP hdr | | Cmpr. | | ROHC | ESP | ESP| IPv4 | new IP hdr | | Cmpr. | | ROHC | ESP | ESP|
|(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV| |(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV|
------------------------------------------------------ ------------------------------------------------------
Figure 1. Example of a ROHCoIPsec-processed packet. Figure 1. Example of a ROHCoIPsec-processed packet.
Note: The authentication data must not be included in the calculation Note: At the decompressor, the ROHC ICV field is not included in the
of the ICV. calculation of the ROHC ICV.
3.2.1. ICV Computation and Integrity Verification 4.2.1. ICV Computation and Integrity Verification
In order to correctly verify the integrity of the decompressed In order to correctly verify the integrity of the decompressed
packets, the processing steps for ROHCoIPsec must be implemented in a packets, the processing steps for ROHCoIPsec MUST be implemented in a
specific order, as given below. specific order, as given below.
For outbound packets that are processed by ROHC and IPsec-protected: For outbound packets that are processed by ROHC and IPsec-protected:
o Compute an ICV for the uncompressed packet with the negotiated o Compute an ICV for the uncompressed packet with the negotiated
(ROHC) integrity algorithm and its respective key (ROHC) integrity algorithm and its respective key
o Compress the packet headers (as specified by the ROHC process) o Compress the packet headers (as specified by the ROHC process)
o Append the ICV to the compressed packet o Append the ICV to the compressed packet
o Apply AH or ESP processing to the packet, as specified in the o Apply AH or ESP processing to the packet, as specified in the
appropriate SAD entry appropriate SAD entry
For inbound packets that are to be decompressed by ROHC: For inbound packets that are to be decompressed by ROHC:
o Apply AH or ESP processing, as specified in the appropriate SAD o Apply AH or ESP processing, as specified in the appropriate SAD
entry entry
o Remove the ICV from the packet o Remove the ICV from the packet
o Decompress the packet header(s) o Decompress the packet header(s)
o Compute an ICV for the decompressed packet with the negotiated o Compute an ICV for the decompressed packet with the negotiated
(ROHC) integrity algorithm and its respective key (ROHC) integrity algorithm and its respective key
o Compare the computed ICV to the original ICV calculated at the o Compare the computed ICV to the original ICV calculated at the
compressor: if these two values differ, the packet must be compressor: if these two values differ, the packet MUST be
dropped; otherwise resume IPsec processing dropped; otherwise resume IPsec processing
3.3. ROHC Segmentation and IPsec Tunnel MTU 4.3. ROHC Segmentation and IPsec Tunnel MTU
In certain scenarios, a ROHCoIPsec-processed packet may exceed the In certain scenarios, a ROHCoIPsec-processed packet may exceed the
size of the IPsec tunnel MTU. [IPSEC] currently stipulates the size of the IPsec tunnel MTU. RFC 4301 [IPSEC] currently stipulates
following for outbound traffic that exceeds the SA PMTU: the following for outbound traffic that exceeds the SA PMTU:
Case 1: Original (cleartext) packet is IPv4 and has the DF Case 1: Original (cleartext) packet is IPv4 and has the DF
bit set. The implementation should discard the packet bit set. The implementation should discard the packet
and send a PMTU ICMP message. and send a PMTU ICMP message.
Case 2: Original (cleartext) packet is IPv4 and has the DF Case 2: Original (cleartext) packet is IPv4 and has the DF
bit clear. The implementation should fragment (before or bit clear. The implementation should fragment (before or
after encryption per its configuration) and then forward after encryption per its configuration) and then forward
the fragments. It should not send a PMTU ICMP message. the fragments. It should not send a PMTU ICMP message.
Case 3: Original (cleartext) packet is IPv6. The implementation Case 3: Original (cleartext) packet is IPv6. The implementation
should discard the packet and send a PMTU ICMP message. should discard the packet and send a PMTU ICMP message.
For ROHCOIPsec, Cases 1 and 3, and the post-encryption fragmentation For ROHCoIPsec, Cases 1 and 3, and the post-encryption fragmentation
for Case 2 are employed. However, since current ROHC compression for Case 2 are employed. However, since current ROHC compression
profiles do not support the compression of IP packet fragments, pre- profiles do not support the compression of IP packet fragments, pre-
encryption fragmentation is not compatible with the current set of encryption fragmentation is not compatible with the current set of
ROHC profiles. In place of pre-encryption fragmentation, ROHC ROHC profiles. In place of pre-encryption fragmentation, ROHC
segmentation may be used at the compressor to divide the packet, segmentation MAY be used at the compressor to divide the packet,
where each segment conforms to the tunnel MTU. However, because in- where each segment conforms to the tunnel MTU. However, because in-
order delivery of ROHC segments is not guaranteed, the use of ROHC order delivery of ROHC segments is not guaranteed, the use of ROHC
segmentation is not recommended. segmentation is not recommended.
If the compressor determines that the compressed packet exceeds the If the compressor determines that the compressed packet exceeds the
tunnel MTU, ROHC segmentation may be applied to the compressed packet tunnel MTU, ROHC segmentation MAY be applied to the compressed packet
before AH or ESP processing. This determination can be made by before AH or ESP processing. This determination can be made by
comparing the anticipated ROHCoIPsec packet size to the Path MTU data 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- item specified in the SAD entry. If the MRRU for the channel is non-
zero, the compressor applies ROHC segmentation. The segmentation zero, the compressor applies ROHC segmentation. If segmentation is
process should account for the additional overhead imposed by IPsec applied, the process MUST account for the additional overhead imposed
process (e.g., AH or ESP overhead, crypto synchronization data, the by IPsec process (e.g., AH or ESP overhead, crypto synchronization
additional IP header, etc.) such that the final IPsec-processed data, the additional IP header, etc.) such that the final IPsec-
segments are less than the tunnel MTU. After segmentation, each ROHC processed segments are less than the tunnel MTU. After segmentation,
segment receives AH or ESP processing. each ROHC segment is consecutively processed by the appropriate
security protocol (e.g., AH, ESP) instantiated on the ROHC-enabled
SA. Since ROHC segments are processed consecutively, the associated
AH/ESP sequence number MUST be incremented by one for each segment
transmitted over the ROHC channel. As such, after all ROHC segments
receive AH/ESP processing, these segments can be identified (at the
remote IPsec implementation) by a range of contiguous AH/ESP sequence
numbers.
For channels where the MRRU is non-zero, the ROHCoIPsec decompressor For channels where the MRRU is non-zero, the ROHCoIPsec decompressor
must re-assemble the ROHC segments that are received. To accomplish MUST re-assemble the ROHC segments that are received. To accomplish
this, the decompressor must identify the ROHC segments (as documented this, the decompressor MUST identify the ROHC segments (as documented
in Section 5.2.6 of [ROHC]), and attempt reconstruction using the in Section 5.2.6 of RFC 4995 [ROHC]), and attempt reconstruction
ROHC segmentation protocol (Section 5.2.5 of [ROHC]). If using the ROHC segmentation protocol (Section 5.2.5 of RFC 4995
reconstruction fails, the packet must be discarded. [ROHC]). To assist the reconstruction process, the AH/ESP sequence
number SHOULD be used to identify segments that may have been subject
to reordering. If reconstruction fails, the packet MUST be
discarded.
As stated in Section 3.2.1, if the ROHC integrity algorithm is used 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 verify the decompression of packet headers, this ICV is appended
to the compressed packet. If ROHC segmentation is performed, the to the compressed packet. If ROHC segmentation is performed, the
segmentation algorithm is executed on the compressed packet and the segmentation algorithm is executed on the compressed packet and the
appended ICV. Note that the ICV is not appended to each ROHC appended ICV. Note that the ICV is not appended to each ROHC
segment. segment.
3.4. Nested IPComp and ROHCoIPsec Processing Under certain circumstances, IPsec implementations will not process
(or receive) unprotected ICMP messages, or they will not have a Path
MTU estimate value. In these cases, the IPsec implementation SHOULD
NOT attempt to segment the ROHC-compressed packet, as it does not
have full insight into the path MTU in the unprotected domain.
4.4. Nested IPComp and ROHCoIPsec Processing
IPComp ([IPCOMP]) is another mechanism that can be implemented to IPComp ([IPCOMP]) is another mechanism that can be implemented to
reduce the size of an IP datagram. If IPComp and ROHCoIPsec are reduce the size of an IP datagram. If IPComp and ROHCoIPsec are
implemented in a nested fashion, the following steps must be followed implemented in a nested fashion, the following steps MUST be followed
for outbound and inbound packets. for outbound and inbound packets.
For outbound packets that are to be processed by IPcomp and ROHC: For outbound packets that are to be processed by IPcomp and ROHC:
o The ICV is computed for the uncompressed packet, and the o The ICV is computed for the uncompressed packet, and the
appropriate ROHC compression profile is applied to the packet appropriate ROHC compression profile is applied to the packet
o IPComp is applied, and the packet is sent to the IPsec process o IPComp is applied, and the packet is sent to the IPsec process
o The security protocol is applied to the packet o The security protocol is applied to the packet
Conversely, for inbound packets that are to be both ROHC- and IPcomp- Conversely, for inbound packets that are to be both ROHC- and IPcomp-
decompressed: decompressed:
o A packet received on a ROHC-enabled SA is IPsec-processed o A packet received on a ROHC-enabled SA is IPsec-processed
o The datagram is decompressed based on the appropriate IPComp o The datagram is decompressed based on the appropriate IPComp
algorithm algorithm
o The packet is sent to the ROHC module for header decompression and o The packet is sent to the ROHC module for header decompression and
integrity verification integrity verification
4. Security Considerations 5. Security Considerations
A ROHCoIPsec implementer should consider the strength of protection A ROHCoIPsec implementer should consider the strength of protection
provided by the integrity check algorithm used to verify the valid provided by the integrity check algorithm used to verify decompressed
decompression of ROHC-compressed packets. Failure to implement a headers. Failure to implement a strong integrity check algorithm
strong integrity check algorithm increases the probability of an increases the probability for an invalidly decompressed packet to be
invalidly decompressed packet to be forwarded by a ROHCoIPsec device forwarded by a ROHCoIPsec device into a protected domain.
into a protected domain.
The implementation of ROHCoIPsec may increase the susceptibility for The implementation of ROHCoIPsec may increase the susceptibility for
traffic flow analysis, where an attacker can identify new traffic traffic flow analysis, where an attacker can identify new traffic
flows by monitoring the relative size of the encrypted packets (i.e. flows by monitoring the relative size of the encrypted packets (i.e.
a group of "long" packets, followed by a long series of "short" a group of "long" packets, followed by a long series of "short"
packets may indicate a new flow for some ROHCoIPsec implementations). packets may indicate a new flow for some ROHCoIPsec implementations).
To mitigate this concern, ROHC padding mechanisms may be used to To mitigate this concern, ROHC padding mechanisms may be used to
arbitrarily add padding to transmitted packets to randomize packet arbitrarily add padding to transmitted packets to randomize packet
sizes. This technique, however, reduces the overall efficiency sizes. This technique, however, reduces the overall efficiency
benefit offered by header compression. benefit offered by header compression.
5. IANA Considerations 6. IANA Considerations
IANA is requested to allocate one value within the "Protocol Numbers" IANA is requested to allocate one value within the "Protocol Numbers"
registry [PROTOCOL] for "ROHC". This value will be used to indicate registry [PROTOCOL] for "ROHC". This value will be used to indicate
that the next level protocol header is a ROHC header. that the next level protocol header is a ROHC header.
6. Acknowledgments 7. Acknowledgments
The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 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 Ms. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of
OPnet for their contributions and support for developing this OPnet for their contributions and support for developing this
document. document.
The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A
Stangarone Jr.: both served as committed document reviewers for this Stangarone Jr.: both served as committed document reviewers for this
specification. specification.
skipping to change at page 10, line 29 skipping to change at page 11, line 42
o Mr. Magnus Westerlund o Mr. Magnus Westerlund
o Dr. Stephen Kent o Dr. Stephen Kent
o Mr. Lars-Erik Jonsson o Mr. Lars-Erik Jonsson
o Mr. Carl Knutsson o Mr. Carl Knutsson
o Mr. Pasi Eronen o Mr. Pasi Eronen
o Dr. Jonah Pezeshki o Dr. Jonah Pezeshki
o Mr. Tero Kivinen o Mr. Tero Kivinen
o Dr. Joseph Touch o Dr. Joseph Touch
o Mr. Rohan Jasani o Mr. Rohan Jasani
7. References Appendix A. ASN.1 representation for ROHCoIPsec
7.1. Normative References This appendix is included as an additional way to describe the
ROHCoIPsec parameters that are included in the IPsec SPD. It uses
portions of the ASN.1 syntax provided in Appendix C of RFC 4301
[IPSEC]. In addition, several new structures are defined.
This syntax has been successfully compiled. However, it is merely
illustrative and need not be employed in an implementation to achieve
compliance.
The "Processing" data structure, defined in Appendix C of RFC 4301,
is augmented to include a ROHC parameters element as follows:
Processing ::= SEQUENCE {
extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
fragCheck BOOLEAN, -- TRUE stateful fragment checking,
-- FALSE no stateful fragment checking
lifetime SALifetime,
spi ManualSPI,
algorithms ProcessingAlgs,
tunnel TunnelOptions OPTIONAL,
rohc [7] RohcParams OPTIONAL
}
The following data structures describe these ROHC parameters:
RohcParams ::= SEQUENCE {
rohcEnabled BOOLEAN, -- TRUE, hdr compr. is enabled
-- FALSE, hdr compr. is disabled
maxCID INTEGER (0..16383),
mrru INTEGER,
profiles RohcProfiles,
rohcIntegAlg RohcIntegAlgs,
rohcIntegICVLength INTEGER
}
RohcProfiles ::= SET OF RohcProfile
RohcProfile ::= INTEGER {
rohcv1-rtp (1),
rohcv1-udp (2),
rohcv1-esp (3),
rohcv1-ip (4),
rohcv1-tcp (6),
rohcv1-rtp-udpLite (7),
rohcv1-udpLite (8),
rohcv2-rtp (257),
rohcv2-udp (258),
rohcv2-esp (259),
rohcv2-ip (260),
rohcv2-rtp-udpLite (263),
rohcv2-udpLite (264)
-- values taken from [ROHCPROF]
}
RohcIntegAlgs ::= SEQUENCE {
algorithm RohcIntegAlgType,
parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
RohcIntegAlgType ::= INTEGER {
none (0),
auth-HMAC-MD5-96 (1),
auth-HMAC-SHA1-96 (2),
auth-DES-MAC (3),
auth-KPDK-MD5 (4),
auth-AES-XCBC-96 (5),
auth-HMAC-MD5-128 (6),
auth-HMAC-SHA1-160 (7),
auth-AES-CMAC-96 (8),
auth-AES-128-GMAC (9),
auth-AES-192-GMAC (10),
auth-AES-256-GMAC (11),
auth-HMAC-SHA2-256-128 (12),
auth-HMAC-SHA2-384-192 (13),
auth-HMAC-SHA2-512-256 (14)
-- tbd (15..65535)
-- values taken from "Transform Type 3 - Integrity
-- Algorithm Transform IDs" at [IKEV2-PARA]
}
8. References
8.1. Normative References
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
Header Compression (ROHC) Framework", RFC 4995, July 2007. Header Compression (ROHC) Framework", RFC 4995, July 2007.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 3173, September 2001.
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and
UDP-Lite", RFC 5225. UDP-Lite", RFC 5225.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 3173, September 2001.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[IKEV2EXT] [IKEV2EXT]
Ertekin, et al., "Extensions to IKEv2 to Support Robust Ertekin, et al., "Extensions to IKEv2 to Support Robust
Header Compression over IPsec (ROHCoIPsec)", work in Header Compression over IPsec (ROHCoIPsec)", work in
progress , August 2009. progress , December 2009.
[AH] Kent, S., "IP Authentication Header", RFC 4302, [AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
7.2. Informative References 8.2. Informative References
[ROHCOIPSEC] [ROHCOIPSEC]
Ertekin, E., Jasani, R., Christou, C., and C. Bormann, Ertekin, E., Jasani, R., Christou, C., and C. Bormann,
"Integration of Header Compression over IPsec Security "Integration of Header Compression over IPsec Security
Associations", work in progress , August 2009. Associations", work in progress , December 2009.
[ROHCPROF] [ROHCPROF]
"RObust Header Compression (ROHC) Profile Identifiers", "RObust Header Compression (ROHC) Profile Identifiers",
www.iana.org/assignments/rohc-pro-ids , October 2005. www.iana.org/assignments/rohc-pro-ids , May 2008.
[CRYPTO-ALG] [CRYPTO-ALG]
Manral, V., "Cryptographic Algorithm Implementation Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007. Authentication Header (AH)", RFC 4835, April 2007.
[ROHC-TERM] [ROHC-TERM]
Jonsson, L-E., "Robust Header Compression (ROHC): Jonsson, L-E., "Robust Header Compression (ROHC):
Terminology and Channel Mapping Examples", RFC 3759, Terminology and Channel Mapping Examples", RFC 3759,
April 2004. April 2004.
[PROTOCOL] [PROTOCOL]
IANA, ""Assigned Internet Protocol Numbers", IANA registry IANA, ""Assigned Internet Protocol Numbers", IANA registry
at: http://www.iana.org/assignments/protocol-numbers". at: http://www.iana.org/assignments/protocol-numbers".
[IKEV2-PARA]
IANA, "IKEv2 Parameters,
http://www.iana.org/assignments/ikev2-parameters",
November 2009.
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 5220 Pacific Concourse Drive, Suite 200
Herndon, VA 20171 Los Angeles, CA 90045
US US
Email: ertekin_emre@bah.com Email: ertekin_emre@bah.com
Chris Christou Chris Christou
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: christou_chris@bah.com Email: christou_chris@bah.com
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
 End of changes. 65 change blocks. 
161 lines changed or deleted 291 lines changed or added

This html diff was produced by rfcdiff 1.37b. The latest version is available from http://tools.ietf.org/tools/rfcdiff/