draft-ietf-rohc-hcoipsec-07.txt   draft-ietf-rohc-hcoipsec-08.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft R. Jasani
Intended status: Informational R. Jasani Intended status: Informational C. Christou
Expires: July 3, 2008 J. Pezeshki Expires: February 15, 2009 J. Pezeshki
Booz Allen Hamilton Booz Allen Hamilton
December 31, 2007 C. Bormann
Universitaet Bremen TZI
August 14, 2008
Integration of Robust Header Compression (RoHC) over IPsec Security Integration of Robust Header Compression (RoHC) over IPsec Security
Associations Associations
draft-ietf-rohc-hcoipsec-07 draft-ietf-rohc-hcoipsec-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 38
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 July 3, 2008. This Internet-Draft will expire on February 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 3, line 47 skipping to change at page 3, line 47
requirements put forth in this document. In addition, this document requirements put forth in this document. In addition, this document
is directed towards vendors developing IPsec devices that will be is directed towards vendors developing IPsec devices that will be
deployed in bandwidth-constrained IP networks. deployed in bandwidth-constrained IP networks.
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 RFC 3759), or Generic reference to a RoHC instance (as defined in [ROHC-TERM]),
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 by the RoHC compressor instance. Packet
headers are compressed using a specific header compression headers are compressed using a specific header compression
protocol. protocol.
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.
Next Header Next Header
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) Refers to the Protocol (IPv4) or Next Header (IPv6, Extension)
skipping to change at page 4, line 45 skipping to change at page 4, line 45
bandwidth-constrained wireless and/or satellite communications bandwidth-constrained wireless and/or satellite communications
networks, as these types of infrastructure are not overprovisioned. networks, as these types of infrastructure are not overprovisioned.
RoHC applied on a per-hop basis over bandwidth-constrained links will RoHC applied on a per-hop basis over bandwidth-constrained links will
also suffer from reduced performance when encryption is used on the also suffer from reduced performance when encryption is used on the
tunneled header, since encrypted headers can not be compressed. tunneled header, since encrypted headers can not be compressed.
Consequently, the additional overhead incurred by an IPsec tunnel may Consequently, the additional overhead incurred by an IPsec tunnel may
result in the inefficient utilization of bandwidth. result in the inefficient utilization of bandwidth.
Packet overhead is particularly significant for traffic profiles Packet overhead is particularly significant for traffic profiles
characterized by small packet payloads (e.g. various voice codecs). characterized by small packet payloads (e.g. various voice codecs).
In addition, if these small packets are afforded the security If these small packets are afforded the security services of an IPsec
services of an IPsec tunnel mode SA, the amount of per-packet tunnel mode SA, the amount of per-packet overhead is increased.
overhead is increased. Thus, a mechanism is needed to reduce the Thus, a mechanism is needed to reduce the overhead associated with
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. As such, the RoHCoIPsec framework has services offered by IPsec. The RoHCoIPsec framework has been
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
5.2. Summary of the RoHCoIPsec Framework 5.2. Summary of the RoHCoIPsec Framework
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 implementations, with multiple hops between the IPsec IPsec endpoints. Therefore, various extensions to both RoHC and
implementations. Therefore, various extensions to both RoHC and IPsec need to be defined to ensure the successful operation of the
IPsec may need to be defined to ensure its successful operation at RoHC protocol at IPsec SA endpoints.
IPsec SA endpoints.
The migration of RoHC over IPsec SAs is straightforward, since SA The migration 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 in such a manner offers a operations can take place. Compression of the inner IP and upper
reduction of per-packet protocol overhead between the two SA layer protocol headers in such a manner offers a reduction of per-
endpoints, and does not require compression and decompression cycles packet protocol overhead between the two SA endpoints. Since RoHC
at the intermediate hops between IPsec implementations. Since RoHC will now operate between IPsec endpoints (over multiple intermediate
will now essentially operate over multiple hops, 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 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 IP traffic Using the RoHCoIPsec framework proposed below, outbound and inbound
processing at an IPsec device is augmented to compress appropriate IP traffic processing at an IPsec device needs to be modified. For
packet headers, and subsequently encrypt and/or integrity-protect the an outbound packet, a RoHCoIPsec implementation will compress
packet. For tunnel mode SAs, compression may be applied to the appropriate packet headers, and subsequently encrypt and/or
transport layer protocol and the inner IP header. integrity-protect the packet. For tunnel mode SAs, compression may
be applied to the transport layer protocol and the inner IP header.
Inbound IP traffic processing at an IPsec device is modified in a For inbound packets, an IPsec device must first decrypt and/or
similar fashion. For inbound packets, an IPsec device must first integrity-check the packet. Then decompression of the inner packet
decrypt and/or integrity-check the packet. Then, the IPsec device
determines if the packet was received on an RoHC-enabled SA (see
Section 6.1) and if the packet maintains compressed headers. If both
of these conditions are met, decompression of the inner packet
headers is performed. After decompression, the packet is checked headers is performed. After decompression, the packet is checked
against the access controls imposed on all inbound traffic associated against the access controls imposed on all inbound traffic associated
with the SA (as specified in [IPSEC]). with the SA (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 is capable of compressing the security protocol and the outer IP
header on a hop-by-hop basis. header on a hop-by-hop basis. The applicability of RoHCoIPsec and
hop-by-hop RoHC on an IPv4 ESP-processed packet [ESP] is shown
below in Figure 1.
-----------------------------------------------------------
IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<-------(1)------->|<------(2)-------->|
(1) Compressed by RoHC ESP/IP profile
(2) Compressed by RoHCoIPsec TCP/IP profile
Figure 1. Applicability of RoHC and RoHCoIPsec on an 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. Inbound and applied to the inner headers at the IPsec SA endpoints. Inbound and
outbound packets are still processed as was previously described. outbound packets are still processed as was previously described.
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 1 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 |
| | | |
| | | |
+-----+ | +-----+ +---------+ | +-----+ | +-----+ +---------+ |
| | | | | | RoHC | | | | | | | | RoHC | |
--| A |---------| B |-----| Process |------> Path 1 --| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (RoHC-enabled SA) | | | | | | | | (RoHC-enabled SA)
skipping to change at page 7, line 25 skipping to change at page 7, line 25
| | |-------------------------> Path 2 | | |-------------------------> Path 2
| | | (RoHC-enabled SA) | | | (RoHC-enabled SA)
| +-------------------------------+ | +-------------------------------+
| |
| |
| |
| |
+-----------------------------------------> Path 3 +-----------------------------------------> Path 3
(ROHC-disabled SA) (ROHC-disabled SA)
Figure 1: Integration of RoHC with IPsec. Figure 2. Integration of RoHC with IPsec.
The process illustrated in Figure 1 augments the IPsec processing The process illustrated in Figure 2 augments the IPsec processing
model for outbound IP traffic (protected-to-unprotected). Initial model for outbound IP traffic (protected-to-unprotected). Initial
IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1). IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1).
The RoHC data item (part of the SA state information) retrieved from
the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if
the traffic traversing the SA is handed to the RoHC module (Figure 1,
decision block A). Packets selected to a RoHC-disabled SA must
follow normal IPsec processing and must not be sent to the RoHC
module (Figure 1, Path 3). Conversely, packets selected to a RoHC-
enabled SA must be sent to the RoHC module. The decision at block B
then determines if the packet can be compressed. If it is determined
that the packet will be compressed, an Integrity Algorithm is used to
compute an Integrity Check Value (ICV) for the uncompressed packet
([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section 2.1). After this, the
Next Header field of the security protocol header (e.g., ESP, AH) is
populated with a "RoHC" identifier, the packet headers are
compressed, and the computed ICV is prepended to the packet, in front
of the compressed header (Figure 1, Path 1). However, if it is
determined that the packet will not be compressed (e.g., due to one
the reasons described in Section 6.1.3), the Next Header field is
populated with the appropriate value indicating the next level
protocol (Figure 1, Path 2). After the RoHC process completes, IPsec
processing resumes, as described in Section 5.1, Step3a, of [IPSEC]
(specifically, "IPsec processing is as previously defined...").
The process illustrated in Figure 1 also augments the IPsec Block A: The RoHC data item (part of the SA state information)
retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1,
Step3a) determines if the traffic traversing the SA is handed to the
RoHC module. Packets selected to a RoHC-disabled SA must follow
normal IPsec processing and must not be sent to the RoHC module
(Figure 1, Path 3). Conversely, packets selected to a RoHC-enabled
SA must be sent to the RoHC module.
Block B: This step determines if the packet can be compressed. If it
is determined that the packet will be compressed, an Integrity
Algorithm is used to compute an Integrity Check Value (ICV) for the
uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section
2.1). The Next Header field of the security protocol header (e.g.,
ESP, AH) is populated with a "RoHC" identifier, the packet headers
are compressed, and the computed ICV is appended to the packet
(Figure 1, Path 1). However, if it is determined that the packet
will not be compressed (e.g., due to one the reasons described in
Section 6.1.3), the Next Header field is populated with the
appropriate value indicating the next level protocol (Figure 1, Path
2).
After the RoHC process completes, IPsec processing resumes, as
described in Section 5.1, Step3a, of [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
5.2, Step 4) . After AH or ESP processing, the RoHC data item 5.2, Step 4).
retrieved from the SAD entry will indicate if traffic traversing the
SA is handed to the RoHC module ([IPSEC], Section 5.2, Step 3a). Block A: After AH or ESP processing, the RoHC data item retrieved
from the SAD entry will indicate if traffic traversing the SA is
processed by the RoHC module ([IPSEC], Section 5.2, Step 3a).
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. The decision at block B is determined by the value of the module.
Next Header field of the security protocol header. If a RoHC header
is indicated, decompression is applied, and the decompressed packet Block B: The decision at Block B is determined by the value of the
is used with the RoHCoIPsec Integrity Algorithm to compute a value Next Header field of the security protocol header. If the Next
that is compared to the ICV that was calculated at the compressor. Header field does not indicate a RoHC header, the decompressor must
If this computed value equals the ICV, the packet leaves the RoHC not attempt decompression (Figure 1, Path 2). If the Next Header
module (Figure 1, Path 1); otherwise, the packet is dropped. If the field indicates a RoHC header, decompression is applied. After
Next Header field does not indicate a RoHC header, the decompressor decompression, the RoHCoIPsec Integrity Algorithm is used to compute
must not attempt decompression (Figure 1, Path 2). Once the RoHC an ICV value for the decompressed packet. This ICV is compared to
module completes processing, IPsec processing resumes, as described the ICV that was calculated at the compressor: if the ICVs match, the
in Section 5.2, Step 4 of [IPSEC] (specifically "Then match the packet is forwarded by the RoHC module (Figure 1, Path 1); otherwise,
packet against the inbound selectors identified by the SAD ..."). the packet is dropped. Once the RoHC module completes processing,
IPsec processing resumes, as described in Section 5.2, Step 4 of
[IPSEC].
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
The initial specification of RoHC [ROHC] may need to be extended to RoHCv2 [ROHCV2] profiles include various mechanisms that provide
operate efficiently over IPsec SAs. Specifically, compressor and increased robustness over reordering channels. These mechanisms must
decompressor implementations must account for increased tolerance to be adopted for RoHC to operate efficiently over IPsec SAs.
packet reordering and packet loss, and should minimize the amount of
feedback sent from the decompressor to the compressor. To address A RoHC decompressor implemented within IPsec architecture may
this need, [ROHC-RODR] provides guidelines on how to implement leverage additional mechanisms to improve performance over reordering
existing profiles over reordering channels, and RoHCv2 [ROHCV2] channels (either due to random events, or to an attacker
profiles include various mechanisms that provide increased robustness intentionally reordering packets). Specifically, IPsec's sequence
over reordering channels. Furthermore, a RoHC decompressor number may be used by the decompressor to identify a packet as
implemented within IPsec architecture may leverage additional "sequentially late". This knowledge will increase the likelihood of
mechanisms to improve performance over reordering channels (either successful decompression of a reordered packet.
due to random events, or to an attacker intentionally reordering
packets). Specifically, IPsec's sequence number may be used by the
decompressor to identify a packet as "sequentially late". This
knowledge will increase the likelihood of 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, several
implementation considerations are offered: implementation considerations are offered:
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
RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC RoHC can use the underlying link layer (e.g., PPP) to automatically
channel parameters. In the case of RoHCoIPsec, channel parameters RoHC channel parameters. In the case of RoHCoIPsec, channel
are negotiated by another mechanism. Specifically, initialization of parameters can be achieved manually (i.e., administratively
the RoHC channel is either achieved manually (i.e., administratively configured for manual SAs), or by IKEv2. The extensions required for
configured for manual SAs), or is performed by IPsec SA establishment IKEv2 to support RoHC parameter negotiation are detailed in [IKE-
protocols. The extensions required for IKEv2 to support RoHC ROHC].
parameter negotiation are detailed in [IKE-ROHC].
If the RoHC protocol requires bi-directional communications, two SAs If the RoHC protocol requires bi-directional 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. However, IPsec implementations will dictate how decompressor pairs by default. However, IPsec implementations will dictate how
feedback received on one SA is associated with a compressor on the decompressor feedback received on one SA is associated with a
other SA. compressor on the other SA.
6.1.3. Encapsulation and Identification of Header Compressed Packets 6.1.3. Encapsulation and Identification of Header Compressed Packets
As indicated in Section 6.1, new state information (i.e., a new RoHC As indicated in Section 6.1, new state information (i.e., a new RoHC
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 do not contain compressed headers. Such situations
may occur when, for example, a compressor supports strictly n may occur when, for example, a compressor supports strictly n
compressed flows and can not compress the n+1 flow that arrives. compressed flows and can not compress the n+1 flow that arrives.
Another example is when traffic (e.g., TCP/IP) is selected (by IPsec) Another example is when traffic (e.g., TCP/IP) is selected (by IPsec)
to a RoHC-enabled SA, but cannot be compressed by the RoHC process to a RoHC-enabled SA, but cannot be compressed by the RoHC process
(e.g., because the compressor does not support TCP/IP compression). (e.g., because the compressor does not support TCP/IP compression).
In these situations, the compressor must indicate that the packet Similarly, the decompressor must be able to identify packets with
contains uncompressed headers. Similarly, the decompressor must be uncompressed headers and not attempt to decompress them. The Next
able to identify packets with uncompressed headers and not attempt to Header field is used to demultiplex these header-compressed versus
decompress them. The Next Header field is used to demultiplex these uncompressed packets, as a RoHC protocol identifier will indicate the
header-compressed versus uncompressed packets, as a RoHC protocol packet contains compressed headers. To accomplish this, an official
identifier will indicate the packet contains compressed headers. To IANA allocation from the Protocol ID registry [PROTOCOL] is required.
accomplish this, an official IANA allocation from the ProtocolID
registry [PROTOCOL] is required.
The RoHC Data Item, IANA ProtocolID allocation, and other IPsec The RoHC Data Item, IANA ProtocolID 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 10, line 34 skipping to change at page 10, line 33
A malfunctioning RoHC compressor (i.e., the compressor located at the A malfunctioning RoHC compressor (i.e., the compressor located at the
ingress of the IPsec tunnel) has the ability to send packets to the ingress of the IPsec tunnel) has the ability to send packets to the
decompressor (i.e., the decompressor located at the egress of the decompressor (i.e., the decompressor located at the egress of the
IPsec tunnel) that do not match the original packets emitted from the IPsec tunnel) that do not match the original packets emitted from the
end-hosts. Such a scenario will result in a decreased efficiency end-hosts. Such a scenario will result in a decreased efficiency
between compressor and decompressor. Furthermore, this may result in between compressor and decompressor. Furthermore, this may result in
Denial of Service, as the decompression of a significant number of Denial of Service, as the decompression of a significant number of
invalid packets may drain the resources of an IPsec device. invalid packets may drain the resources of an IPsec device.
In addition, some RoHCoIPsec implementations may allow an attacker to
identify new traffic flows by monitoring the relative size of the
encrypted packets (i.e. a group of "long" packets, followed by a long
series of "short" packets may indicate a new flow for some RoHCoIPsec
implementations). To mitigate this concern, RoHC padding mechanisms
may be used to arbitrarily add padding to transmitted packets to
randomize packet sizes.
8. IANA Considerations 8. IANA Considerations
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. In addition, the authors would like to development of this document.
thank the following for their numerous reviews and comments to this
document: In addition, the authors would like to thank the following for their
numerous reviews and comments to this document:
o Dr. Stephen Kent o Dr. Stephen Kent
o Dr. Carsten Bormann o Dr. Carsten Bormann
o Mr. Pasi Eronen
o Dr. Joseph Touch
o Mr. Tero Kivinen o Mr. Tero Kivinen
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
o Mr. Pasi Eronen
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] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. 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]
Jonsson, L-E., "Robust Header Compression (ROHC):
Terminology and Channel Mapping Examples", RFC 4301,
April 2004.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, 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.
[AH] Kent, S., "IP Authentication Header", RFC 4302, [AH] Kent, S., "IP Authentication Header", RFC 4302,
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.
[ROHC2] 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", work in progress , December 2007. Lite", RFC 5225, April 2008.
[IKE-ROHC] [IKE-ROHC]
Pezeshki, et al., "IKEv2 Extensions to Support Pezeshki, et al., "IKEv2 Extensions to Support
RoHCoIPsec", work in progress , February 2007. RoHCoIPsec", work in progress , August 2008.
[ROHC-RODR]
Pelletier, et al., "RObust Header Compression (ROHC): ROHC
over Channels That Can Reorder Packets", RFC 4224,
January 2006.
[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, et al., "IPsec Extensions to Support RoHCoIPsec",
work in progress , February 2007. work in progress , August 2008.
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
Chris Christou Rohan Jasani
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: jasani_rohan@bah.com
Rohan Jasani 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: jasani_rohan@bah.com Email: christou_chris@bah.com
Jonah Pezeshki Jonah Pezeshki
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: pezeshki_jonah@bah.com Email: pezeshki_jonah@bah.com
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28334
Germany
Email: cabo@tzi.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 14, line 44 skipping to change at line 580
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 42 change blocks. 
144 lines changed or deleted 151 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/