draft-ietf-rohc-ipsec-extensions-hcoipsec-08.txt   rfc5858.txt 
Network Working Group E. Ertekin Internet Engineering Task Force (IETF) E. Ertekin
Internet-Draft C. Christou Request for Comments: 5858 C. Christou
Intended status: Standards Track Booz Allen Hamilton Category: Standards Track Booz Allen Hamilton
Expires: August 19, 2010 C. Bormann ISSN: 2070-1721 C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
February 15, 2010 May 2010
IPsec Extensions to Support Robust Header Compression over IPsec IPsec Extensions to Support Robust Header Compression over IPsec
draft-ietf-rohc-ipsec-extensions-hcoipsec-08
Abstract Abstract
Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec)
offers the combined benefits of IP security services and efficient offers the combined benefits of IP security services and efficient
bandwidth utilization. However, in order to integrate ROHC with bandwidth utilization. However, in order to integrate ROHC with
IPsec, extensions to the SPD and SAD are required. This document IPsec, extensions to the Security Policy Database (SPD) and Security
describes the IPsec extensions required to support ROHCoIPsec. Association Database (SAD) are required. This document describes the
IPsec extensions required to support ROHCoIPsec.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 Status of This Memo
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 This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 19, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5858.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................3
3. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 3 3. Extensions to IPsec Databases ...................................3
3.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 4 3.1. Security Policy Database (SPD) .............................4
3.2. Security Association Database (SAD) . . . . . . . . . . . 5 3.2. Security Association Database (SAD) ........................5
4. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 6 4. Extensions to IPsec Processing ..................................6
4.1. Identification of Header-Compressed Traffic . . . . . . . 6 4.1. Identification of Header-Compressed Traffic ................6
4.2. Verifying the Integrity of Decompressed Packet Headers . . 6 4.2. Verifying the Integrity of Decompressed Packet Headers .....6
4.2.1. ICV Computation and Integrity Verification . . . . . . 7 4.2.1. ICV Computation and Integrity Verification ..........7
4.3. ROHC Segmentation and IPsec Tunnel MTU . . . . . . . . . . 8 4.3. ROHC Segmentation and IPsec Tunnel MTU .....................8
4.4. Nested IPComp and ROHCoIPsec Processing . . . . . . . . . 9 4.4. Nested IPComp and ROHCoIPsec Processing ....................9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations ........................................10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations ............................................10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments ................................................11
Appendix A. ASN.1 representation for ROHCoIPsec . . . . . . . . . 11 Appendix A. ASN.1 Representation for ROHCoIPsec ...................12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References .....................................................14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References ......................................14
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References ....................................14
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. By compressing the packet headers, which increase packet overhead. By compressing the
inner headers of these packets, the integration of Robust Header inner headers of these packets, the integration of Robust Header
Compresion (ROHC, [ROHC]) with IPsec (ROHCoIPsec, [ROHCOIPSEC]) can Compression (ROHC, [ROHC]) with IPsec (ROHCoIPsec, [ROHCOIPSEC]) can
reduce the packet overhead associated with IPsec-protected flows. reduce the packet overhead associated with IPsec-protected flows.
IPsec-protected traffic is carried over Security Associations (SAs), IPsec-protected traffic is carried over Security Associations (SAs),
whose parameters are negotiated on a case-by-case basis. The whose parameters are negotiated on a case-by-case basis. The
Security Policy Database (SPD) specifies the services that are to be Security Policy Database (SPD) specifies the services that are to be
offered to IP datagrams, and the parameters associated with SAs that offered to IP datagrams, and the parameters associated with SAs that
have been established are stored in the Security Association Database have been established are stored in the Security Association Database
(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.
skipping to change at page 4, line 47 skipping to change at page 3, line 47
The following subsections specify extensions to the SPD and the SAD The following subsections specify extensions to the SPD and the SAD
that MUST be supported for ROHCoIPsec. The ROHCoIPsec fields in the that MUST be supported for ROHCoIPsec. The ROHCoIPsec fields in the
SPD are used to populate the ROHCoIPsec parameters in the SAD during SPD are used to populate the ROHCoIPsec parameters in the SAD during
the initialization or rekey of a child SA. the initialization or rekey of a child SA.
It is noted that these extensions do not have any implications on It is noted that these extensions do not have any implications on
existing SPD fields or SAD parameters. Therefore, a ROHCoIPsec existing SPD fields or SAD parameters. Therefore, a ROHCoIPsec
implementation is backwards-compatible with an IPsec implementation implementation is backwards-compatible with an IPsec implementation
that does not support header compression. that does not support header compression.
Appendix A provides an example ASN.1 representation of a SPD that is Appendix A provides an example ASN.1 representation of an SPD that is
extended to support ROHC. extended to support ROHC.
3.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 is 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
skipping to change at page 5, line 25 skipping to change at page 4, line 25
The fields contained within each SPD entry are defined in RFC 4301 The fields contained within each SPD entry are defined in RFC 4301
[IPSEC], Section 4.4.1.2. To support ROHC, several processing info [IPSEC], Section 4.4.1.2. To support ROHC, several processing info
fields are added to the SPD; these fields contain information fields are added to the SPD; these fields contain information
regarding the ROHC profiles and channel parameters supported by the regarding the ROHC profiles and channel parameters supported by the
local ROHC instance. local ROHC instance.
If the processing action associated with the selector sets is If the processing action associated with the selector sets is
PROTECT, then the processing info must be extended with the following PROTECT, then the processing info must be extended with the following
ROHC channel parameters: ROHC channel parameters:
MAX_CID: The field indicates the highest context ID that will be MAX_CID: This 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 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 Cyclic Redundancy Check (CRC) and the ROHC Integrity Check Value
packets cannot be guaranteed, the MRRU parameter SHOULD be set to (ICV). NOTE: Since in-order delivery of ROHC packets cannot be
0 (as stated in Section 5.2.5.1 of RFC 4995 [ROHC] and Section 6.1 guaranteed, the MRRU parameter SHOULD be set to 0 (as stated in
of RFC 5225 [ROHCV2]), which indicates that no segment headers are Section 5.2.5.1 of RFC 5795 [ROHC] and Section 6.1 of RFC 5225
allowed on the ROHCoIPsec channel. [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 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 ROHC Profile Identifiers registry [ROHCPROF]. in the "RObust Header Compression (ROHC) Profile Identifiers"
registry [ROHCPROF].
In addition to these ROHC channel parameters, a ROHC Integrity In addition to these ROHC channel parameters, a ROHC integrity
Algorithm and a ROHC ICV Length field MUST be included within the algorithm and a ROHC ICV Length field MUST be included within the
SPD: SPD:
ROHC INTEGRITY ALGORITHM: This field is a list of integrity ROHC INTEGRITY ALGORITHM: This field is a list of integrity
algorithms supported by the ROHCoIPsec instance. This will be algorithms supported by the ROHCoIPsec instance. This will be
used by the ROHC process to ensure that packet headers are used by the ROHC process to ensure that packet headers are
properly decompressed (see Section 4.2). Authentication properly decompressed (see Section 4.2). Authentication
algorithms that MUST be supported are specified in the algorithms that MUST be supported are specified in the
"Authentication Algorithms" table in section 3.1.1 ("ESP "Authentication Algorithms" table in Section 3.1.1 ("ESP
Encryption and Authentication Algorithms") of RFC 4835 [CRYPTO- Encryption and Authentication Algorithms") of RFC 4835
ALG] (or its successor). [CRYPTO-ALG] (or its successor).
ROHC ICV LENGTH: This field specifies the length of the ICV that ROHC ICV LENGTH: This field specifies the length of the ICV that
is used in conjunction with the ROHC Integrity Algorithm. is used in conjunction with the ROHC integrity algorithm.
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 MUST LARGE_CIDS and FEEDBACK_FOR. The LARGE_CIDS channel parameter MUST
be set based on the value of MAX_CID (e.g. if MAX_CID is <= 15, be set based on the value of MAX_CID (i.e., 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 MUST be set to the ROHC channel associated with the channel parameter MUST be set to the ROHC channel associated with the
SA in the reverse direction. If an SA in the reverse direction does 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 not exist, the FEEDBACK_FOR channel parameter is not set, and ROHC
MUST NOT operate in bidirectional Mode. MUST NOT operate in bi-directional Mode.
3.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 RFC 4301 The data items contained within the SAD are defined in RFC 4301
[IPSEC], Section 4.4.2.1. To support ROHC, the SAD must include a [IPSEC], Section 4.4.2.1. To support ROHC, the SAD must include a
skipping to change at page 7, line 6 skipping to change at page 6, line 10
used by the ROHC process (see Section 3.2). The integrity algorithm used by the ROHC process (see Section 3.2). The integrity algorithm
and its associated key are used to calculate a ROHC ICV of the 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- specified length; this ICV is used to verify the packet headers post-
decompression. decompression.
Finally, for inbound SAs, the ROHC Data Item MUST include a Finally, for inbound SAs, the ROHC Data Item MUST include a
FEEDBACK_FOR parameter. The parameter is a reference to a ROHC FEEDBACK_FOR parameter. The parameter is a reference to a ROHC
channel in the opposite direction (i.e., the outbound SA) between the channel in the opposite direction (i.e., the outbound SA) between the
same compression endpoints. A ROHC channel associated with an same compression endpoints. A ROHC channel associated with an
inbound SA and a ROHC channel associated with an outbound SA MAY be 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 coupled to form a bi-directional ROHC channel as defined in Sections
6.1 and Section 6.2 in RFC 3759 [ROHC-TERM]. 6.1 and 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 [IKE-ROHC].
4. Extensions to IPsec Processing 4. Extensions to IPsec Processing
4.1. Identification of Header-Compressed Traffic 4.1. Identification of Header-Compressed Traffic
A "ROHC" protocol identifier is used to identify header-compressed A "ROHC" protocol identifier is used to identify header-compressed
traffic on a ROHC-enabled SA. If an outbound packet has a compressed traffic on a ROHC-enabled SA. 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. Authentication Header (AH) [AH], Encapsulating Security Payload (ESP)
If the packet header has not been compressed by ROHC, the Next Header [ESP]) MUST be set to the "ROHC" protocol identifier. If the packet
field does not contain the "ROHC" protocol identifier. Conversely, header has not been compressed by ROHC, the Next Header field does
for an inbound packet, the value of the security protocol Next Header not contain the "ROHC" protocol identifier. Conversely, for an
field MUST be checked to determine if the packet includes a ROHC inbound packet, the value of the security protocol Next Header field
header, in order to determine if it requires ROHC decompression. MUST be 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 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.
4.2. Verifying the Integrity of Decompressed Packet Headers 4.2. Verifying the Integrity of Decompressed Packet Headers
As documented in Section 6.1.4 of [ROHCOIPSEC], ROHC is inherently a As documented in Section 6.1.4 of [ROHCOIPSEC], ROHC is inherently a
lossy compression algorithm: the consequences of significant packet lossy compression algorithm: the consequences of significant packet
reordering or loss between ROHC peers may include undetected reordering or loss between ROHC peers may include undetected
decompression failures, where erroneous packets are forwarded into decompression failures, where erroneous packets are forwarded into
the protected domain. the protected domain.
To ensure that a decompressed header is identical to the original To ensure that a decompressed header is identical to the original
header, ROHCoIPsec MAY use an additional Integrity Algorithm (and header, ROHCoIPsec MAY use an additional integrity algorithm (and
respective key) to compute a second Integrity Check Value (ICV). respective key) to compute a second Integrity Check Value (ICV).
This ROHC ICV MUST be computed over the uncompressed IP header, as This ROHC ICV MUST be computed over the uncompressed IP header, as
well at the higher-layer headers and the packet payload. When well at the higher-layer headers and the packet payload. When
computed, the ICV is appended to the ROHC-compressed packet. At the computed, the ICV is appended to the ROHC-compressed packet. At the
decompressor, the decompressed packet (including the uncompressed IP decompressor, the decompressed packet (including the uncompressed IP
header, higher-layer headers, and packet payload; but not including header, higher-layer headers, and packet payload; but not including
the authentication data) will be used with the integrity algorithm the authentication data) will be used with the integrity algorithm
(and its respective key) to compute a value that will be compared to (and its respective key) to compute a value that will be compared to
the appended ICV. If these values are not identical, the the appended ICV. If these values are not identical, the
decompressed packet MUST be dropped. decompressed packet MUST be dropped.
skipping to change at page 8, line 28 skipping to change at page 7, line 34
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: At the decompressor, the ROHC ICV field is not included in the Note: At the decompressor, the ROHC ICV field is not included in the
calculation of the ROHC ICV. calculation of the ROHC ICV.
4.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 are 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 Append the ICV to the compressed packet o Compress the packet headers (as specified by the ROHC process).
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 Decompress the packet header(s) o Remove the ICV from the packet.
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.
4.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. RFC 4301 [IPSEC] currently stipulates size of the IPsec tunnel MTU. RFC 4301 [IPSEC] currently stipulates
the following for outbound traffic that exceeds the SA PMTU: the following for outbound traffic that exceeds the SA Path MTU
(PMTU):
Case 1: Original (cleartext) packet is IPv4 and has the DF Case 1: Original (cleartext) packet is IPv4 and has the Don't
bit set. The implementation should discard the packet Fragment (DF) bit set. The implementation should
and send a PMTU ICMP message. discard the packet 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 the ROHCoIPsec processing model, there is one minor change to the For the ROHCoIPsec processing model, there is one minor change to the
skipping to change at page 10, line 13 skipping to change at page 9, line 28
instantiated on the ROHC-enabled SA. Since ROHC segments are instantiated on the ROHC-enabled SA. Since ROHC segments are
processed consecutively, the associated AH/ESP sequence number MUST processed consecutively, the associated AH/ESP sequence number MUST
be incremented by one for each segment transmitted over the ROHC be incremented by one for each segment transmitted over the ROHC
channel. As such, after all ROHC segments receive AH/ESP processing, channel. As such, after all ROHC segments receive AH/ESP processing,
these segments can be identified (at the remote IPsec implementation) these segments can be identified (at the remote IPsec implementation)
by a range of contiguous AH/ESP sequence numbers. 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 RFC 4995 [ROHC]), and attempt reconstruction in Section 5.2 of RFC 5795 [ROHC]), and attempt reconstruction using
using the ROHC segmentation protocol (Section 5.2.5 of RFC 4995 the ROHC segmentation protocol (Section 5.2.5 of RFC 5795 [ROHC]).
[ROHC]). To assist the reconstruction process, the AH/ESP sequence To assist the reconstruction process, the AH/ESP sequence number
number SHOULD be used to identify segments that may have been subject SHOULD be used to identify segments that may have been subject to
to reordering. If reconstruction fails, the packet MUST be reordering. If reconstruction fails, the packet MUST be discarded.
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.
Under certain circumstances, IPsec implementations will not process Under certain circumstances, IPsec implementations will not process
(or receive) unprotected ICMP messages, or they will not have a Path (or receive) unprotected ICMP messages, or they will not have a Path
MTU estimate value. In these cases, the IPsec implementation SHOULD MTU estimated value. In these cases, the IPsec implementation SHOULD
NOT attempt to segment the ROHC-compressed packet, as it does not NOT attempt to segment the ROHC-compressed packet, as it does not
have full insight into the path MTU in the unprotected domain. have full insight into the path MTU in the unprotected domain.
4.4. Nested IPComp and ROHCoIPsec Processing 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 The security protocol is applied to the packet
Conversely, for inbound packets that are to be both ROHC- and IPcomp- o IPComp is applied, and the packet is sent to the IPsec process.
o The security protocol is applied to the packet.
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.
5. 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 decompressed provided by the integrity check algorithm used to verify decompressed
headers. Failure to implement a strong integrity check algorithm headers. Failure to implement a strong integrity check algorithm
increases the probability for an invalidly decompressed packet to be increases the probability for an invalidly decompressed packet to be
forwarded by a ROHCoIPsec device into a protected domain. forwarded by a ROHCoIPsec device 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.
6. IANA Considerations 6. IANA Considerations
IANA is requested to allocate one value within the "Protocol Numbers" IANA has allocated the value 142 to "ROHC" within the "Protocol
registry [PROTOCOL] for "ROHC". This value will be used to indicate Numbers" registry [PROTOCOL]. 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.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, The authors would like to thank Sean O'Keeffe, James Kohler, Linda
Ms. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of Noone of the Department of Defense, and Rich Espy of OPnet for their
OPnet for their contributions and support for developing this 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 Yoav Nir and Robert A Stangarone
Stangarone Jr.: both served as committed document reviewers for this Jr.: both served as committed document reviewers for this
specification. specification.
Finally, the authors would like to thank the following for their Finally, the authors would like to thank the following for their
numerous reviews and comments to this document: numerous reviews and comments to this document:
o Mr. Magnus Westerlund o Magnus Westerlund
o Dr. Stephen Kent
o Mr. Lars-Erik Jonsson
o Mr. Carl Knutsson
o Mr. Pasi Eronen
o Dr. Jonah Pezeshki
o Mr. Tero Kivinen
o Dr. Joseph Touch
o Mr. Rohan Jasani
o Mr. Elwyn Davies
o Mr. Bert Wijnen
Appendix A. ASN.1 representation for ROHCoIPsec o Stephen Kent
o Lars-Erik Jonsson
o Carl Knutsson
o Pasi Eronen
o Jonah Pezeshki
o Tero Kivinen
o Joseph Touch
o Rohan Jasani
o Elwyn Davies
o Bert Wijnen
Appendix A. ASN.1 Representation for ROHCoIPsec
This appendix is included as an additional way to describe the This appendix is included as an additional way to describe the
ROHCoIPsec parameters that are included in the IPsec SPD. It uses ROHCoIPsec parameters that are included in the IPsec SPD. It uses
portions of the ASN.1 syntax provided in Appendix C of RFC 4301 portions of the ASN.1 syntax provided in Appendix C of RFC 4301
[IPSEC]. In addition, several new structures are defined. [IPSEC]. In addition, several new structures are defined.
This syntax has been successfully compiled. However, it is merely This syntax has been successfully compiled. However, it is merely
illustrative and need not be employed in an implementation to achieve illustrative and need not be employed in an implementation to achieve
compliance. compliance.
skipping to change at page 14, line 4 skipping to change at page 13, line 47
auth-HMAC-MD5-128 (6), auth-HMAC-MD5-128 (6),
auth-HMAC-SHA1-160 (7), auth-HMAC-SHA1-160 (7),
auth-AES-CMAC-96 (8), auth-AES-CMAC-96 (8),
auth-AES-128-GMAC (9), auth-AES-128-GMAC (9),
auth-AES-192-GMAC (10), auth-AES-192-GMAC (10),
auth-AES-256-GMAC (11), auth-AES-256-GMAC (11),
auth-HMAC-SHA2-256-128 (12), auth-HMAC-SHA2-256-128 (12),
auth-HMAC-SHA2-384-192 (13), auth-HMAC-SHA2-384-192 (13),
auth-HMAC-SHA2-512-256 (14) auth-HMAC-SHA2-512-256 (14)
-- tbd (15..65535) -- tbd (15..65535)
-- values taken from "Transform Type 3 - Integrity -- values taken from "Transform Type 3 - Integrity
-- Algorithm Transform IDs" at [IKEV2-PARA] -- Algorithm Transform IDs" at [IKEV2-PARA]
} }
8. References 8. References
8.1. Normative 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] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The
Header Compression (ROHC) Framework", RFC 4995, July 2007. RObust Header Compression (ROHC) Framework", RFC 5795,
March 2010.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
Compression Protocol (IPComp)", RFC 3173, September 2001. "IP Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate [BRA97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and Compression Version 2 (ROHCv2): Profiles for RTP, UDP,
UDP-Lite", RFC 5225. IP, ESP and UDP-Lite", RFC 5225, April 2008.
[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] [IKE-ROHC] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and
Ertekin, et al., "IKEv2 Extensions to Support Robust C. Bormann, "IKEv2 Extensions to Support Robust Header
Header Compression over IPsec (ROHCoIPsec)", work in Compression over IPsec", RFC 5857, May 2010.
progress , February 2010.
[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.
8.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", RFC 5856, May 2010.
Associations", work in progress , February 2010.
[ROHCPROF] [ROHCPROF] IANA, "RObust Header Compression (ROHC) Profile
"RObust Header Compression (ROHC) Profile Identifiers", Identifiers", <http://www.iana.org>.
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)
Requirements for Encapsulating Security Payload (ESP) and 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, ""Assigned Internet Protocol Numbers", IANA registry <http://www.iana.org>.
at: http://www.iana.org/assignments/protocol-numbers".
[IKEV2-PARA] [IKEV2-PARA] IANA, "Internet Key Exchange Version 2 (IKEv2)
IANA, "IKEv2 Parameters, Parameters", <http://www.iana.org>.
http://www.iana.org/assignments/ikev2-parameters",
November 2009.
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
5220 Pacific Concourse Drive, Suite 200 5220 Pacific Concourse Drive, Suite 200
Los Angeles, CA 90045 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
Postfach 330440 Postfach 330440
Bremen D-28334 Bremen D-28334
Germany Germany
Email: cabo@tzi.org EMail: cabo@tzi.org
 End of changes. 68 change blocks. 
174 lines changed or deleted 186 lines changed or added

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