draft-ietf-rohc-hcoipsec-09.txt   draft-ietf-rohc-hcoipsec-10.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft R. Jasani Internet-Draft R. Jasani
Intended status: Informational C. Christou Intended status: Informational C. Christou
Expires: April 17, 2009 J. Pezeshki Expires: August 6, 2009 Booz Allen Hamilton
Booz Allen Hamilton
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
October 14, 2008 February 2, 2009
Integration of Robust Header Compression (ROHC) over IPsec Security Integration of Robust Header Compression (ROHC) over IPsec Security
Associations Associations
draft-ietf-rohc-hcoipsec-09 draft-ietf-rohc-hcoipsec-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering 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 April 17, 2009. This Internet-Draft will expire on August 6, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
IP Security (IPsec) provides various security services for IP IP Security (IPsec) provides various security services for IP
traffic. However, the benefits of IPsec come at the cost of traffic. However, the benefits of IPsec come at the cost of
increased overhead. This document outlines a framework for increased overhead. This document outlines a framework for
integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).
By compressing the inner headers of IP packets, ROHCoIPsec proposes By compressing the inner headers of IP packets, ROHCoIPsec proposes
to reduce the amount of overhead associated with the transmission of to reduce the amount of overhead associated with the transmission of
traffic over IPsec Security Associations (SAs). traffic over IPsec Security Associations (SAs).
skipping to change at page 2, line 16 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4
5. Overview of the ROHCoIPsec Framework . . . . . . . . . . . 5 5. Overview of the ROHCoIPsec Framework . . . . . . . . . . . 5
5.1. ROHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5 5.1. ROHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5
5.2. Summary of the ROHCoIPsec Framework . . . . . . . . . . . 5 5.2. Summary of the ROHCoIPsec Framework . . . . . . . . . . . 5
6. Details of the ROHCoIPsec Framework . . . . . . . . . . . 6 6. Details of the ROHCoIPsec Framework . . . . . . . . . . . 6
6.1. ROHC and IPsec Integration . . . . . . . . . . . . . . . . 7 6.1. ROHC and IPsec Integration . . . . . . . . . . . . . . . . 7
6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 6.1.1. Header Compression Protocol Considerations . . . . . . . . 9
6.1.2. Initialization and Negotiation of the ROHC Channel . . . . 9 6.1.2. Initialization and Negotiation of the ROHC Channel . . . . 9
6.1.3. Encapsulation and Identification of Header Compressed 6.1.3. Encapsulation and Identification of Header Compressed
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
10. Informative References . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . 14
1. Introduction 1. Introduction
This document outlines a framework for integrating ROHC [ROHC] over This document outlines a framework for integrating ROHC [ROHC] over
IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the
protocol overhead associated with packets traversing between IPsec SA protocol overhead associated with packets traversing between IPsec SA
endpoints. This can be achieved by compressing the transport layer endpoints. This can be achieved by compressing the transport layer
header (e.g., UDP, TCP, etc.) and inner IP header of packets at the header (e.g., UDP, TCP, etc.) and inner IP header of packets at the
ingress of the IPsec tunnel, and decompressing these headers at the ingress of the IPsec tunnel, and decompressing these headers at the
egress. egress.
For ROHCoIPsec, this document assumes that ROHC will be used to For ROHCoIPsec, this document assumes that ROHC will be used to
compress the inner headers of IP packets traversing an IPsec tunnel. compress the inner headers of IP packets traversing an IPsec tunnel.
However, since current specifications for ROHC detail its operation However, since current specifications for ROHC detail its operation
on a hop-by-hop basis, it may require extensions to enable its on a hop-by-hop basis, it requires extensions to enable its operation
operation over IPsec SAs. These extensions need to account for over IPsec SAs. These extensions need to account for increased
increased packet reordering and packet loss that may occur in the packet reordering and packet loss that may occur in the unprotected
unprotected domain. This document outlines a framework for extending domain. This document outlines a framework for extending the usage
the usage of ROHC to operate at IPsec SA endpoints. of ROHC to operate at IPsec SA endpoints.
ROHCoIPsec targets the application of ROHC to tunnel mode SAs. ROHCoIPsec targets the application of ROHC to tunnel mode SAs.
Transport mode SAs only encrypt/authenticate the payload of an IP Transport mode SAs only encrypt/authenticate the payload of an IP
packet, leaving the IP header untouched. Intermediate routers packet, leaving the IP header untouched. Intermediate routers
subsequently use this IP header to route the packet to a decryption subsequently use this IP header to route the packet to a decryption
device. Therefore, if ROHC is to operate over IPsec transport-mode device. Therefore, if ROHC is to operate over IPsec transport-mode
SAs, (de)compression functionality can only be applied to the SAs, (de)compression functionality can only be applied to the
transport layer headers, and not to the IP header. Because current transport layer headers, and not to the IP header. Because current
ROHC specifications do not include support for the compression of ROHC specifications do not include support for the compression of
transport layer headers alone, the ROHCoIPsec framework outlined by transport layer headers alone, the ROHCoIPsec framework outlined by
skipping to change at page 4, line 9 skipping to change at page 4, line 9
3. Terminology 3. Terminology
Terminology specific to ROHCoIPsec is introduced in this section. Terminology specific to ROHCoIPsec is introduced in this section.
ROHC Process ROHC Process
Generic reference to a ROHC instance (as defined in [ROHC-TERM]), Generic reference to a ROHC instance (as defined in [ROHC-TERM]),
or any supporting ROHC components. or any supporting ROHC components.
Compressed Traffic Compressed Traffic
Traffic that is processed by the ROHC compressor instance. Packet Traffic that is processed through the ROHC compressor and
headers are compressed using a specific header compression decompressor instances. Packet headers are compressed and
protocol. decompressed using a specific header compression profile.
Uncompressed Traffic Uncompressed Traffic
Traffic that is not processed by the ROHC compressor instance. Traffic that is not processed by the ROHC compressor instance.
Instead, this type of traffic bypasses the ROHC process. Instead, this type of traffic bypasses the ROHC process.
IPsec Process IPsec Process
Generic reference to the Internet Protocol Security (IPsec) Generic reference to the Internet Protocol Security (IPsec)
process. process.
skipping to change at page 5, line 13 skipping to change at page 5, line 13
If these small packets are afforded the security services of an IPsec If these small packets are afforded the security services of an IPsec
tunnel mode SA, the amount of per-packet overhead is increased. tunnel mode SA, the amount of per-packet overhead is increased.
Thus, a mechanism is needed to reduce the overhead associated with Thus, a mechanism is needed to reduce the overhead associated with
such flows. such flows.
5. Overview of the ROHCoIPsec Framework 5. Overview of the ROHCoIPsec Framework
5.1. ROHCoIPsec Assumptions 5.1. ROHCoIPsec Assumptions
The goal of ROHCoIPsec is to provide efficient transport of IP The goal of ROHCoIPsec is to provide efficient transport of IP
packets between IPsec devices, without compromising the security packets between IPsec devices without compromising the security
services offered by IPsec. The ROHCoIPsec framework has been services offered by IPsec. The ROHCoIPsec framework has been
developed based on the following assumptions: developed based on the following assumptions:
o ROHC will be leveraged to reduce the amount of overhead associated o ROHC will be leveraged to reduce the amount of overhead associated
with packets traversing an IPsec SA with packets traversing an IPsec SA
o ROHC will be instantiated at the IPsec SA endpoints, and will be o ROHC will be instantiated at the IPsec SA endpoints, and will be
applied on a per-SA basis applied on a per-SA basis
o Once the decompression operation completes, decompressed packet o Once the decompression operation completes, decompressed packet
headers will be identical to the original packet headers before headers will be identical to the original packet headers before
compression compression
skipping to change at page 5, line 36 skipping to change at page 5, line 36
ROHC reduces packet overhead in a network by exploiting intra- and ROHC reduces packet overhead in a network by exploiting intra- and
inter-packet redundancies of network and transport-layer header inter-packet redundancies of network and transport-layer header
fields of a flow. fields of a flow.
Current ROHC protocol specifications compress packet headers on a Current ROHC protocol specifications compress packet headers on a
hop-by-hop basis. However, IPsec SAs are instantiated between two hop-by-hop basis. However, IPsec SAs are instantiated between two
IPsec endpoints. Therefore, various extensions to both ROHC and IPsec endpoints. Therefore, various extensions to both ROHC and
IPsec need to be defined to ensure the successful operation of the IPsec need to be defined to ensure the successful operation of the
ROHC protocol at IPsec SA endpoints. ROHC protocol at IPsec SA endpoints.
The migration of ROHC over IPsec SAs is straightforward, since SA The specification of ROHC over IPsec SAs is straightforward, since SA
endpoints provide source/destination pairs where (de)compression endpoints provide source/destination pairs where (de)compression
operations can take place. Compression of the inner IP and upper operations can take place. Compression of the inner IP and upper
layer protocol headers in such a manner offers a reduction of per- layer protocol headers in such a manner offers a reduction of per-
packet protocol overhead between the two SA endpoints. Since ROHC packet protocol overhead between the two SA endpoints. Since ROHC
will now operate between IPsec endpoints (over multiple intermediate will now operate between IPsec endpoints (over multiple intermediate
nodes which are transparent to an IPsec SA), it is imperative to nodes which are transparent to an IPsec SA), it is imperative to
ensure that its performance will not be severely impacted due to ensure that its performance will not be severely impacted due to
increased packet reordering and/or packet loss between the compressor increased packet reordering and/or packet loss between the compressor
and decompressor. and decompressor.
In addition, ROHC can no longer rely on the underlying link layer for In addition, ROHC can no longer rely on the underlying link layer for
ROHC parameter configuration and packet identification. The ROHC channel parameter configuration and packet identification. The
ROHCoIPsec framework proposes that ROHC channel parameter ROHCoIPsec framework proposes that ROHC channel parameter
configuration is accomplished by an SA management protocol (e.g., configuration is accomplished by an SA management protocol (e.g.,
IKEv2 [IKEV2]), while identification of compressed header packets is IKEv2 [IKEV2]), while identification of compressed header packets is
achieved through the Next Header field of the security protocol achieved through the Next Header field of the security protocol
(e.g., AH [AH], ESP [ESP]) header. (e.g., AH [AH], ESP [ESP]) header.
Using the ROHCoIPsec framework proposed below, outbound and inbound Using the ROHCoIPsec framework proposed below, outbound and inbound
IP traffic processing at an IPsec device needs to be modified. For IP traffic processing at an IPsec device needs to be modified. For
an outbound packet, a ROHCoIPsec implementation will compress an outbound packet, a ROHCoIPsec implementation will compress
appropriate packet headers, and subsequently encrypt and/or appropriate packet headers, and subsequently encrypt and/or
integrity-protect the packet. For tunnel mode SAs, compression may integrity-protect the packet. For tunnel mode SAs, compression may
be applied to the transport layer protocol and the inner IP header. be applied to the transport layer and the inner IP headers. For
For inbound packets, an IPsec device must first decrypt and/or inbound packets, an IPsec device must first decrypt and/or integrity-
integrity-check the packet. Then decompression of the inner packet check the packet. Then decompression of the inner packet headers is
headers is performed. After decompression, the packet is checked performed. After decompression, the packet is checked against the
against the access controls imposed on all inbound traffic associated access controls imposed on all inbound traffic associated with the SA
with the SA (as specified in [IPSEC]). (as specified in [IPSEC]).
Note: Compression of inner headers is independent from compression Note: Compression of inner headers is independent from compression
of the security protocol (e.g., ESP) and outer IP headers. ROHC of the security protocol (e.g., ESP) and outer IP headers. ROHC
is capable of compressing the security protocol and the outer IP profiles have been defined to allow for the compression of the
header on a hop-by-hop basis. The applicability of ROHCoIPsec and security protocol and the outer IP header on a hop-by-hop basis.
hop-by-hop ROHC on an IPv4 ESP-processed packet [ESP] is shown The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4
below in Figure 1. ESP-processed packet [ESP] is shown below in Figure 1.
----------------------------------------------------------- -----------------------------------------------------------
IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP| IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
----------------------------------------------------------- -----------------------------------------------------------
|<-------(1)------->|<------(2)-------->| |<-------(1)------->|<------(2)-------->|
(1) Compressed by ROHC ESP/IP profile (1) Compressed by ROHC ESP/IP profile
(2) Compressed by ROHCoIPsec TCP/IP profile (2) Compressed by ROHCoIPsec TCP/IP profile
Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an
IPv4 ESP-processed packet. IPv4 ESP-processed packet.
If IPsec NULL encryption is applied to packets, ROHC may still be If IPsec NULL encryption is applied to packets, ROHC may still be
applied to the inner headers at the IPsec SA endpoints. However, in applied to the inner headers at the IPsec SA endpoints. However,
these scenarios, intermediary devices (within the unprotected domain) this poses challenges for intermediary devices (within the
inspecting ESP-NULL encrypted packets will be unable to determine the unprotected domain) inspecting ESP-NULL encrypted packets, since
content of these packets since they are unable to parse ROHC- these intermediary devices will require additional functionality to
compressed headers. determine the content of the ROHC packets.
6. Details of the ROHCoIPsec Framework 6. Details of the ROHCoIPsec Framework
6.1. ROHC and IPsec Integration 6.1. ROHC and IPsec Integration
Figure 2 illustrates the components required to integrate ROHC with Figure 2 illustrates the components required to integrate ROHC with
the IPsec process, i.e., ROHCoIPsec. the IPsec process, i.e., ROHCoIPsec.
+-------------------------------+ +-------------------------------+
| ROHC Module | | ROHC Module |
skipping to change at page 7, line 46 skipping to change at page 7, line 46
Block A: The ROHC data item (part of the SA state information) Block A: The ROHC data item (part of the SA state information)
retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1, retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1,
Step3a) determines if the traffic traversing the SA is handed to the Step3a) determines if the traffic traversing the SA is handed to the
ROHC module. Packets selected to a ROHC-disabled SA must follow ROHC module. Packets selected to a ROHC-disabled SA must follow
normal IPsec processing and must not be sent to the ROHC module normal IPsec processing and must not be sent to the ROHC module
(Figure 1, Path 3). Conversely, packets selected to a ROHC-enabled (Figure 1, Path 3). Conversely, packets selected to a ROHC-enabled
SA must be sent to the ROHC module. SA must be sent to the ROHC module.
Block B: This step determines if the packet can be compressed. If it Block B: This step determines if the packet can be compressed. If it
is determined that the packet will be compressed, an Integrity is determined that the packet will be compressed, an Integrity
Algorithm is used to compute an Integrity Check Value (ICV) for the Algorithm may be used to compute an Integrity Check Value (ICV) for
uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section the uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC],
2.1). The Next Header field of the security protocol header (e.g., Section 2.1). The Next Header field of the security protocol header
ESP, AH) is populated with a "ROHC" identifier, the packet headers (e.g., ESP, AH) is populated with a "ROHC" identifier, inner packet
are compressed, and the computed ICV is appended to the packet headers are compressed, and the computed ICV is appended to the
(Figure 1, Path 1). However, if it is determined that the packet packet (Figure 1, Path 1). However, if it is determined that the
will not be compressed (e.g., due to one the reasons described in packet will not be compressed (e.g., due to one the reasons described
Section 6.1.3), the Next Header field is populated with the in Section 6.1.3), the Next Header field is populated with the
appropriate value indicating the next level protocol (Figure 1, Path appropriate value indicating the next level protocol (Figure 1, Path
2). 2).
After the ROHC process completes, IPsec processing resumes, as After the ROHC process completes, IPsec processing resumes, as
described in Section 5.1, Step3a, of [IPSEC]. described in Section 5.1, Step3a, of [IPSEC].
The process illustrated in Figure 2 also augments the IPsec The process illustrated in Figure 2 also augments the IPsec
processing model for inbound IP traffic (unprotected-to-protected). processing model for inbound IP traffic (unprotected-to-protected).
For inbound packets, IPsec processing is performed ([IPSEC], Section For inbound packets, IPsec processing is performed ([IPSEC], Section
5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section
skipping to change at page 8, line 31 skipping to change at page 8, line 31
Packets traversing an ROHC-disabled SA must follow normal IPsec Packets traversing an ROHC-disabled SA must follow normal IPsec
processing and must not be sent to the ROHC module. Conversely, processing and must not be sent to the ROHC module. Conversely,
packets traversing an ROHC-enabled SA must be sent to the ROHC packets traversing an ROHC-enabled SA must be sent to the ROHC
module. module.
Block B: The decision at Block B is determined by the value of the Block B: The decision at Block B is determined by the value of the
Next Header field of the security protocol header. If the Next Next Header field of the security protocol header. If the Next
Header field does not indicate a ROHC header, the decompressor must Header field does not indicate a ROHC header, the decompressor must
not attempt decompression (Figure 1, Path 2). If the Next Header not attempt decompression (Figure 1, Path 2). If the Next Header
field indicates a ROHC header, decompression is applied. After field indicates a ROHC header, decompression is applied. After
decompression, the ROHCoIPsec Integrity Algorithm is used to compute decompression, the signaled ROHCoIPsec Integrity Algorithm is used to
an ICV value for the decompressed packet. This ICV is compared to compute an ICV value for the decompressed packet. This ICV is
the ICV that was calculated at the compressor: if the ICVs match, the compared to the ICV that was calculated at the compressor: if the
packet is forwarded by the ROHC module (Figure 1, Path 1); otherwise, ICVs match, the packet is forwarded by the ROHC module (Figure 1,
the packet is dropped. Once the ROHC module completes processing, Path 1); otherwise, the packet is dropped. Once the ROHC module
IPsec processing resumes, as described in Section 5.2, Step 4 of completes processing, IPsec processing resumes, as described in
[IPSEC]. Section 5.2, Step 4 of [IPSEC].
When there is a single SA between a compressor and decompressor, ROHC
operates in unidirectional mode, as described in Section 5 of [ROHC-
TERM]. When there is pair of SAs instantiated between ROHCoIPsec
implementations, ROHC may operate in bidirectional mode, where an SA
pair represents a bidirectional ROHC channel (as described in Section
6.1 and 6.2 of [ROHC-TERM]).
Note that to further reduce the size of an IPsec-protected packet, Note that to further reduce the size of an IPsec-protected packet,
ROHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested ROHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested
fashion. This process is detailed in [IPSEC-ROHC], Section 3.2. fashion. This process is detailed in [IPSEC-ROHC], Section 3.2.
6.1.1. Header Compression Protocol Considerations 6.1.1. Header Compression Protocol Considerations
ROHCv2 [ROHCV2] profiles include various mechanisms that provide ROHCv2 [ROHCV2] profiles include various mechanisms that provide
increased robustness over reordering channels. These mechanisms must increased robustness over reordering channels. These mechanisms must
be adopted for ROHC to operate efficiently over IPsec SAs. be adopted for ROHC to operate efficiently over IPsec SAs.
skipping to change at page 9, line 15 skipping to change at page 9, line 25
number may be used by the decompressor to identify a packet as number may be used by the decompressor to identify a packet as
"sequentially late". This knowledge will increase the likelihood of "sequentially late". This knowledge will increase the likelihood of
successful decompression of a reordered packet. successful decompression of a reordered packet.
Additionally, ROHCoIPsec implementations should minimize the amount Additionally, ROHCoIPsec implementations should minimize the amount
of feedback sent from the decompressor to the compressor. If a ROHC of feedback sent from the decompressor to the compressor. If a ROHC
feedback channel is not used sparingly, the overall gains from feedback channel is not used sparingly, the overall gains from
ROHCoIPsec can be significantly reduced. More specifically, any ROHCoIPsec can be significantly reduced. More specifically, any
feedback sent from the decompressor to the compressor must be feedback sent from the decompressor to the compressor must be
processed by IPsec, and tunneled back to the compressor (as processed by IPsec, and tunneled back to the compressor (as
designated by the SA associated with FEEDBACK_FOR). As such, several designated by the SA associated with FEEDBACK_FOR). As such, some
implementation considerations are offered: implementation alternatives can be considered, including the
following:
o Eliminate feedback traffic altogether by operating only in ROHC o Eliminate feedback traffic altogether by operating only in ROHC
Unidirectional mode (U-mode) Unidirectional mode (U-mode)
o Piggyback ROHC feedback messages on traffic that normally o Piggyback ROHC feedback messages on traffic that normally
traverses the SA designated by FEEDBACK_FOR. traverses the SA designated by FEEDBACK_FOR.
6.1.2. Initialization and Negotiation of the ROHC Channel 6.1.2. Initialization and Negotiation of the ROHC Channel
Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP)
to negotiate ROHC channel parameters. In the case of ROHCoIPsec, to negotiate ROHC channel parameters. In the case of ROHCoIPsec,
channel parameters can be set manually (i.e., administratively channel parameters can be set manually (i.e., administratively
configured for manual SAs), or negotiated by IKEv2. The extensions configured for manual SAs), or negotiated by IKEv2. The extensions
required for IKEv2 to support ROHC parameter negotiation are detailed required for IKEv2 to support ROHC channel parameter negotiation are
in [IKE-ROHC]. detailed in [IKE-ROHC].
If the ROHC protocol requires bi-directional communications, two SAs If the ROHC protocol requires bidirectional communications, two SAs
must be instantiated between the IPsec implementations. One of the must be instantiated between the IPsec implementations. One of the
two SAs is used for carrying ROHC-traffic from the compressor to the two SAs is used for carrying ROHC-traffic from the compressor to the
decompressor, while the other is used to communicate ROHC-feedback decompressor, while the other is used to communicate ROHC-feedback
from the decompressor to the compressor. Note that the requirement from the decompressor to the compressor. Note that the requirement
for two SAs aligns with the operation of IKE, which creates SAs in for two SAs aligns with the operation of IKE, which creates SAs in
pairs by default. However, IPsec implementations will dictate how pairs by default. However, IPsec implementations will dictate how
decompressor feedback received on one SA is associated with a decompressor feedback received on one SA is associated with a
compressor on the other SA. An IPsec implementation must relay the compressor on the other SA. An IPsec implementation must relay the
feedback received by the decompressor on an inbound SA to the feedback received by the decompressor on an inbound SA to the
compressor associated with the corresponding outbound SA. compressor associated with the corresponding outbound SA.
skipping to change at page 10, line 9 skipping to change at page 10, line 18
data item) is defined for each SA. The ROHC data item is used by the data item) is defined for each SA. The ROHC data item is used by the
IPsec process to determine whether it sends all traffic traversing a IPsec process to determine whether it sends all traffic traversing a
given SA to the ROHC module (ROHC-enabled) or bypasses the ROHC given SA to the ROHC module (ROHC-enabled) or bypasses the ROHC
module and sends the traffic through regular IPsec processing (ROHC- module and sends the traffic through regular IPsec processing (ROHC-
disabled). disabled).
The Next Header field of the IPsec security protocol (e.g., AH or The Next Header field of the IPsec security protocol (e.g., AH or
ESP) header is used to demultiplex header-compressed traffic from ESP) header is used to demultiplex header-compressed traffic from
uncompressed traffic traversing an ROHC-enabled SA. This uncompressed traffic traversing an ROHC-enabled SA. This
functionality is needed in situations where packets traversing a functionality is needed in situations where packets traversing a
ROHC-enabled SA do not contain compressed headers. Such situations ROHC-enabled SA contain uncompressed headers. Such situations may
may occur when, for example, a compressor supports strictly n occur when, for example, a compressor supports strictly n compressed
compressed flows and can not compress the n+1 flow that arrives. flows and cannot compress the n+1 flow that arrives. Another example
Another example is when traffic (e.g., TCP/IP) is selected (by IPsec) is when traffic is selected to a ROHC-enabled SA, but cannot be
to a ROHC-enabled SA, but cannot be compressed by the ROHC process compressed by the ROHC process because the appropriate ROHC Profile
(e.g., because the compressor does not support TCP/IP compression). has not been signaled for use. As a result, the decompressor must be
Similarly, the decompressor must be able to identify packets with able to identify packets with uncompressed headers and not attempt to
uncompressed headers and not attempt to decompress them. The Next decompress them. The Next Header field is used to demultiplex these
Header field is used to demultiplex these header-compressed versus header-compressed and uncompressed packets where the ROHC protocol
uncompressed packets, as a ROHC protocol identifier will indicate identifier will indicate that the packet contains compressed headers.
that the packet contains compressed headers. To accomplish this, an To accomplish this, an official IANA allocation from the Protocol ID
official IANA allocation from the Protocol ID registry [PROTOCOL] is registry [PROTOCOL] is required.
required.
The ROHC Data Item, IANA Protocol ID allocation, and other IPsec The ROHC Data Item, IANA Protocol ID allocation, and other IPsec
extensions to support ROHCoIPsec, are specified in [IPSEC-ROHC]. extensions to support ROHCoIPsec, are specified in [IPSEC-ROHC].
6.2. ROHCoIPsec Framework Summary 6.2. ROHCoIPsec Framework Summary
To summarize, the following items are needed to achieve ROHCoIPsec: To summarize, the following items are needed to achieve ROHCoIPsec:
o IKEv2 Extensions to Support ROHCoIPsec o IKEv2 Extensions to Support ROHCoIPsec
o IPsec Extensions to Support ROHCoIPsec o IPsec Extensions to Support ROHCoIPsec
skipping to change at page 11, line 8 skipping to change at page 11, line 16
None. None.
9. Acknowledgments 9. 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,
and Ms. Linda Noone of the Department of Defense, and well as Mr. and Ms. Linda Noone of the Department of Defense, and well as Mr.
Rich Espy of OPnet for their contributions and support in the Rich Espy of OPnet for their contributions and support in the
development of this document. development of 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.
In addition, the authors would like to thank the following for their In addition, 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 Dr. Stephen Kent o Dr. Stephen Kent
o Mr. Pasi Eronen o Mr. Pasi Eronen
o Dr. Joseph Touch o Dr. Joseph Touch
o Mr. Tero Kivinen o Mr. Tero Kivinen
o Mr. Yoav Nir o Dr. Jonah Pezeshki
o Mr. Lars-Erik Jonsson o Mr. Lars-Erik Jonsson
o Mr. Jan Vilhuber o Mr. Jan Vilhuber
o Mr. Dan Wing o Mr. Dan Wing
o Mr. Kristopher Sandlund o Mr. Kristopher Sandlund
o Mr. Ghyslain Pelletier o Mr. Ghyslain Pelletier
Finally, the authors would also like to thank Mr. Tom Conkle, Ms. Finally, the authors would also like to thank Mr. Tom Conkle, Ms.
Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen
Hamilton for their assistance in completing this work. Hamilton for their assistance in completing this work.
10. Informative References 10. Informative References
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Header Compression (ROHC) Framework", RFC 4995, July 2007.
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001.
[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-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.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
skipping to change at page 12, line 13 skipping to change at page 12, line 22
December 2005. December 2005.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 3173, September 2001. Compression Protocol (IPComp)", RFC 3173, September 2001.
[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 UDP Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP
Lite", RFC 5225, April 2008. Lite", RFC 5225, April 2008.
[IKE-ROHC] [IKE-ROHC]
Pezeshki, et al., "IKEv2 Extensions to Support Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
ROHCoIPsec", work in progress , October 2008. Bormann, "IKEv2 Extensions to Support ROHCoIPsec", work in
progress , February 2009.
[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".
[IPSEC-ROHC] [IPSEC-ROHC]
Ertekin, et al., "IPsec Extensions to Support ROHCoIPsec", Ertekin, E., Christou, C., and C. Bormann, "IPsec
work in progress , October 2008. Extensions to Support ROHCoIPsec", work in progress ,
February 2009.
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: ertekin_emre@bah.com Email: ertekin_emre@bah.com
skipping to change at page 13, line 4 skipping to change at page 13, line 19
Email: jasani_rohan@bah.com Email: jasani_rohan@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
Jonah Pezeshki
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
Email: pezeshki_jonah@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
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 30 change blocks. 
91 lines changed or deleted 101 lines changed or added

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