draft-ietf-rohc-hcoipsec-04.txt   draft-ietf-rohc-hcoipsec-05.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Intended status: Informational R. Jasani Intended status: Informational R. Jasani
Expires: August 28, 2007 Booz Allen Hamilton Expires: December 3, 2007 Booz Allen Hamilton
February 24, 2007 June 1, 2007
Integration of Header Compression over IPsec Security Associations Integration of Robust Header Compression (RoHC) over IPsec Security
draft-ietf-rohc-hcoipsec-04 Associations
draft-ietf-rohc-hcoipsec-05
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 35 skipping to change at page 1, line 36
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 August 28, 2007. This Internet-Draft will expire on December 3, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
IP Security (IPsec) [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 Header Compression (HC) over IPsec (HCoIPsec). By integrating Robust Header Compression (RoHC) over IPsec (RoHCoIPsec).
compressing the inner headers of IP packets, HCoIPsec proposes to By compressing the inner headers of IP packets, RoHCoIPsec proposes
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).
Table of Contents Table of Contents
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 HCoIPsec Framework . . . . . . . . . . . . 5 5. Overview of the RoHCoIPsec Framework . . . . . . . . . . . 4
5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5 5.1. RoHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5
5.2. Summary of the HCoIPsec Framework . . . . . . . . . . . . 5 5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5
6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6 6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6
6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 6 6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6
6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8
6.1.2. Initialization and Negotiation of HC 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10 6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . 14
1. Introduction 1. Introduction
This document outlines a framework for integrating HC over IPsec This document outlines a framework for integrating RoHC [ROHC] over
(HCoIPsec). The goal of HCoIPsec is to reduce the protocol overhead IPsec [IPSEC] (RoHCoIPsec). The goal of RoHCoIPsec is to reduce the
associated with packets traversing between IPsec SA endpoints. This protocol overhead associated with packets traversing between IPsec SA
can be achieved by compressing the transport layer header (e.g., UDP, endpoints. This can be achieved by compressing the transport layer
TCP, etc.) and inner IP header of packets at the ingress of the IPsec header (e.g., UDP, TCP, etc.) and inner IP header of packets at the
tunnel, and decompressing these headers at the egress. ingress of the IPsec tunnel, and decompressing these headers at the
egress.
For HCoIPsec, this document assumes that existing HC protocols, such For RoHCoIPsec, this document assumes that RoHC will be used to
as Internet Protocol Header Compression [IPHC], Compressed Real Time compress the inner headers of IP packets traversing an IPsec tunnel.
Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and However, since current specifications for RoHC detail its operation
Robust Header Compression [ROHC], will be used to compress the inner on a hop-by-hop basis, it may require extensions to enable its
headers of IP packets traversing an IPsec tunnel. Since these HC operation over IPsec SAs. This document outlines a framework for
protocols are designed to operate on a hop-by-hop basis, they may extending the usage of RoHC to operate at IPsec SA endpoints.
require extensions to enable their operation over IPsec SAs. This
document outlines a framework for extending the usage of these hop-
by-hop HC protocols to operate at IPsec SA endpoints.
HCoIPsec targets the application of HC to tunnel mode SAs. Transport RoHCoIPsec targets the application of RoHC to tunnel mode SAs.
mode SAs only encrypt/authenticate the payload of an IP packet, Transport mode SAs only encrypt/authenticate the payload of an IP
leaving the IP header untouched. Intermediate routers subsequently packet, leaving the IP header untouched. Intermediate routers
use this IP header to route the packet to a decryption device. subsequently use this IP header to route the packet to a decryption
Therefore, if traditional HC protocols were to operate over IPsec device. Therefore, if RoHC is to operate over IPsec transport-mode
transport-mode SAs, (de)compression functionality can only be applied SAs, (de)compression functionality can only be applied to the
to the transport layer headers, and not to the IP header. Because transport layer headers, and not to the IP header. Because current
current specifications for HC protocols do not include support for RoHC specifications do not include support for the compression of
the compression of transport layer headers alone, the HCoIPsec transport layer headers alone, the RoHCoIPsec framework outlined by
framework outlined by this document describes the application of HC this document describes the application of RoHC to tunnel mode SAs.
to tunnel mode SAs.
2. Audience 2. Audience
The target audience includes those who are involved with the The authors target members of both the RoHC and IPsec communities who
development of HC protocols, and IPsec implementations. Since may consider extending the RoHC and IPsec protocols to meet the
traditional HC protocols have been designed to operate on a hop-by- requirements put forth in this document. In addition, this document
hop basis, they may need to be modified or extended to be operational is directed towards vendors developing IPsec devices that will be
over IPsec SAs. Therefore, the authors target various HC and IPsec deployed in bandwidth-constrained IP networks.
communities who may consider extending existing HC and IPsec
protocols to meet the requirements put forth in this document.
Finally, this document is directed towards vendors developing IPsec
devices that will be deployed in bandwidth-constrained IP networks.
3. Terminology 3. Terminology
Terminology specific to HCoIPsec is introduced in this section. Terminology specific to RoHCoIPsec is introduced in this section.
Compressed Traffic Compressed Traffic
Traffic that is processed by the compressor. Packet headers are Traffic that is processed by a RoHC compressor. Packet headers
compressed using a specific header compression protocol. are compressed using a RoHC profile.
Uncompressed Traffic Uncompressed Traffic
Traffic that is not processed by the RoHC compressor. Instead,
this type of traffic bypasses the RoHC process.
Traffic that is not processed by the compressor. Instead, this RoHC Process
type of traffic bypasses the HC process.
HC Process
Generic reference to either the compressor, decompressor, or any Generic reference to either the ROHC compressor or decompressor.
supporting header compression (HC) components.
IPsec Process IPsec Process
Generic reference to the Internet Protocol Security (IPsec) Generic reference to the IPsec process defined in [IPSEC].
process, as defined in [IPSEC].
Next Header Next Header
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) Refers to the Protocol (IPv4) or Next Header (IPv6, Extension)
field [PROTOCOL]. field.
4. Problem Statement: IPsec Packet Overhead 4. Problem Statement: IPsec Packet Overhead
IPsec mechanisms provide various security services for IP networks. IPsec mechanisms provide various security services for IP networks.
However, the benefits of IPsec come at the cost of increased per- However, the benefits of IPsec come at the cost of increased per-
packet overhead. For example, traffic flow confidentiality packet overhead. For example, traffic flow confidentiality
(generally leveraged at security gateways) requires the tunneling of (generally leveraged at security gateways) requires the tunneling of
IP packets between IPsec implementations. Although these IPsec IP packets between IPsec implementations. Although these IPsec
tunnels will effectively mask the source-destination patterns that an tunnels will effectively mask the source-destination patterns that an
intruder can ascertain, tunneling comes at the cost of increased per- intruder can ascertain, tunneling comes at the cost of increased per-
packet overhead. Specifically, an ESP ([ESP]) tunnel mode SA applied packet overhead. Specifically, an ESP tunnel mode SA applied to an
to an IPv6 flow results in at least 50 bytes of additional overhead IPv6 flow results in at least 50 bytes of additional overhead per
per packet. This additional overhead may be undesirable for many packet. This additional overhead may be undesirable for many
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.
HC applied on a per-hop basis over bandwidth-constrained link RoHC applied on a per-hop basis over bandwidth-constrained links will
technologies will also suffer from reduced performance when also suffer from reduced performance when encryption is used on the
encryption is used on the tunneled header, since encrypted headers tunneled header, since encrypted headers can not be compressed.
can not be compressed. Consequently, the additional overhead Consequently, the additional overhead incurred by an IPsec tunnel may
incurred by an IPsec tunnel may result in the inefficient utilization result in the inefficient utilization of bandwidth.
of bandwidth.
Packet overhead is particularly significant for traffic profiles Packet overhead is particularly significant for traffic profiles
characterized by small packet payloads. Some applications that characterized by small packet payloads (e.g. various voice codecs).
generate small packet payloads include various voice codecs. In In addition, if these small packets are afforded the security
addition, if these small packets are afforded the security services services of an IPsec tunnel mode SA, the amount of per-packet
of an IPsec tunnel mode SA, the amount of per-packet overhead is overhead is increased. Thus, a mechanism is needed to reduce the
increased. Thus, a mechanism is needed to reduce the overhead overhead associated with such flows.
associated with such flows.
5. Overview of the HCoIPsec Framework 5. Overview of the RoHCoIPsec Framework
5.1. HCoIPsec Assumptions 5.1. RoHCoIPsec Assumptions
The goal of HCoIPsec is to provide efficient transport of IP packets The goal of RoHCoIPsec is to provide efficient transport of IP
between source and destination IPsec devices, without compromising packets between IPsec devices, without compromising the security
the security services offered by IPsec. As such, the HCoIPsec services offered by IPsec. As such, the RoHCoIPsec framework has
framework was developed based on the following assumptions: been developed based on the following assumptions:
o Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) will be o RoHC will be leveraged to reduce the amount of overhead associated
leveraged to reduce the amount of overhead associated with packets with packets traversing an IPsec SA
traversing an IPsec SA * Support for legacy HC algorithms (e.g. IPHC, CRTP, ECRTP) over
o HC algorithms will be instantiated at the IPsec SA endpoints, and IPsec may be provided through the specification of new RoHC
HC is applied on a per-SA basis profiles (e.g. [ROHC-CRTP])
o RoHC will be instantiated at the IPsec SA endpoints, and will be
applied on a per-SA basis
5.2. Summary of the HCoIPsec Framework 5.2. Summary of the RoHCoIPsec Framework
HC protocols reduce packet overhead in a network by exploiting intra- RoHC reduces packet overhead in a network by exploiting intra- and
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.
Existing HC protocols compress packet headers on a hop-by-hop basis. Current RoHC protocol specifications compress packet headers on a
However, IPsec SAs are instantiated between two IPsec hop-by-hop basis. However, IPsec SAs are instantiated between two
implementations, with multiple hops between the IPsec IPsec implementations, with multiple hops between the IPsec
implementations. Therefore, to fully integrate HC with IPsec SAs, implementations. Therefore, various extensions to both RoHC and
traditional hop-by-hop protocols may need to be extended to operate IPsec may need to be defined to ensure its successful operation at
at IPsec SA endpoints. IPsec SA endpoints.
The migration of hop-by-hop HC protocols over IPsec SAs is The migration of RoHC over IPsec SAs is straightforward, since SA
straightforward, since SA endpoints provide source/destination pairs endpoints provide source/destination pairs where (de)compression
where (de)compression operations can take place. Compression in such operations can take place. Compression in such a manner offers a
a manner offers a reduction of per-packet protocol overhead between reduction of per-packet protocol overhead between the two SA
the two SA endpoints, and does not require compression and endpoints, and does not require compression and decompression cycles
decompression cycles at the intermediate hops between IPsec at the intermediate hops between IPsec implementations. Since RoHC
implementations. Since existing HC protocols will now essentially will now essentially operate over multiple hops, it is imperative to
operate over multiple hops, it is imperative that their performance ensure that its performance will not be severely impacted due to
is not severely impacted due to increased packet reordering and/or increased packet reordering and/or packet loss between the compressor
packet loss between the compressor and decompressor. and decompressor.
In addition, since HC protocols will operate at IPsec SA endpoints, In addition, RoHC can no longer rely on the underlying link layer for
HC protocols can no longer rely on the underlying link layer for HC RoHC parameter configuration and packet identification. The
parameter configuration and packet identification. Existing HC RoHCoIPsec framework proposes that RoHC channel parameter
protocols use the underlying link layer to establish a set of configuration is accomplished by an SA management protocol (e.g.,
configuration parameters at each end of the link, and some HC IKEv2 [IKEV2]), while identification of compressed header packets is
protocols (e.g., IPHC, CRTP, ECRTP) are also dependent on the link achieved through the Next Header field of the security protocol
layer framing for identifying different types of header-compressed (e.g., AH [AH], ESP [ESP]) header.
packets. The HCoIPsec framework proposes that HC channel parameter
configuration is accomplished by the SA management protocol (e.g.,
IKEv2), while identification of compressed header packets (in
contrast to uncompressed packets) is provided through the Next Header
field of the security protocol (e.g., AH [AH], ESP). In addition, HC
protocols that require the identification of different types of
header-compressed packets will have to be extended with such a
mechanism.
Using the HCoIPsec framework proposed below, outbound IP traffic Using the RoHCoIPsec framework proposed below, outbound IP traffic
processing at an IPsec device is augmented to compress appropriate processing at an IPsec device is augmented to compress appropriate
packet headers, and subsequently encrypt and/or integrity-protect the packet headers, and subsequently encrypt and/or integrity-protect the
packet. For tunnel mode SAs, compression may be applied to the packet. For tunnel mode SAs, compression may be applied to the
transport layer protocol and the inner IP header. transport layer protocol and the inner IP header.
Inbound IP traffic processing at an IPsec device is modified in a Inbound IP traffic processing at an IPsec device is modified in a
similar fashion. For inbound packets, an IPsec device must first similar fashion. For inbound packets, an IPsec device must first
decrypt and/or integrity-check the packet. Then, the IPsec device decrypt and/or integrity-check the packet. Then, the IPsec device
determines if the packet was received on an HC-enabled SA (see determines if the packet was received on an RoHC-enabled SA (see
section 6.1) and if the packet maintains compressed headers. If both Section 6.1) and if the packet maintains compressed headers. If both
of these conditions are met, decompression of the inner packet 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. HC of the security protocol (e.g., ESP) and outer IP headers. RoHC
protocols such as ROHC are capable of compressing the security is capable of compressing the security protocol and the outer IP
protocol and the outer IP header on a hop-by-hop basis. header on a hop-by-hop basis.
If IPsec NULL encryption is applied to packets, HC protocols may If IPsec NULL encryption is applied to packets, RoHC may still be
still be applied to the inner headers at the IPsec SA endpoints. applied to the inner headers at the IPsec SA endpoints. Inbound and
Inbound and outbound packets are still processed as was previously outbound packets are still processed as was previously described.
described.
6. Details of the HCoIPsec Framework 6. Details of the RoHCoIPsec Framework
6.1. HC and IPsec Integration 6.1. RoHC and IPsec Integration
Figure 1 illustrates the components required to integrate HC with the Figure 1 illustrates the components required to integrate RoHC with
IPsec process, i.e., HCoIPsec. the IPsec process, i.e., RoHCoIPsec.
+-------------------------------+ +-------------------------------+
| HC Module | | RoHC Module |
| | | |
| | | |
+-----+ | +-----+ +---------+ | +-----+ | +-----+ +---------+ |
| | | | | | HC | | | | | | | | RoHC | |
--| A |---------| B |-----| Process |------> Path 1 --| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (HC-enabled SA) | | | | | | | | (RoHC-enabled SA)
+-----+ | +-----+ +---------+ | +-----+ | +-----+ +---------+ |
| | | | | | | |
| | |-------------------------> Path 2 | | |-------------------------> Path 2
| | | (HC-enabled SA) | | | (RoHC-enabled SA)
| +-------------------------------+ | +-------------------------------+
| |
| |
| |
| |
+-----------------------------------------> Path 3 +-----------------------------------------> Path 3
(HC-disabled SA) (RoHC-disabled SA)
Figure 1: Integration of HC with IPsec. Figure 1: Integration of RoHC with IPsec.
The process illustrated in Figure 1 augments the IPsec processing The process illustrated in Figure 1 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 HC data item (part of the SA state information) retrieved from The RoHC data item (part of the SA state information) retrieved from
the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if
the traffic traversing the SA is handed to the HC module (Figure 1, the traffic traversing the SA is handed to the RoHC module (Figure 1,
decision block A). Packets selected to an HC-disabled SA must follow decision block A). Packets selected to a RoHC-disabled SA must
normal IPsec processing and must not be sent to the HC module (Figure follow normal IPsec processing and must not be sent to the RoHC
1, Path 3). Conversely, packets selected to an HC-enabled SA must be module (Figure 1, Path 3). Conversely, packets selected to a RoHC-
sent to the HC module. The decision at block B then determines if enabled SA must be sent to the RoHC module. The decision at block B
the packet can be compressed. If it is determined that the packet then determines if the packet can be compressed. If it is determined
will be compressed, the Next Header field of the security protocol that the packet will be compressed, the Next Header field of the
header (e.g., ESP, AH) is populated with a "compressed headers" security protocol header (e.g., ESP, AH) is populated with a "RoHC"
value, and packet headers are compressed based on the compression identifier, and packet headers are compressed (Figure 1, Path 1).
protocol (Figure 1, Path 1). However, if it is determined that the However, if it is determined that the packet will not be compressed
packet will not be compressed (e.g., due to one the reasons described (e.g., due to one the reasons described in Section 6.1.3), the Next
in Section 6.1.3), the Next Header field is populated with the Header field is populated with the appropriate value indicating the
appropriate value indicating the next level protocol (Figure 1, Path next level protocol (Figure 1, Path 2). After the RoHC process
2). After the HC process completes, IPsec processing resumes, as completes, IPsec processing resumes, as described in Section 5.1,
described in Section 5.1, Step3a, of [IPSEC] (specifically, "IPsec Step3a, of [IPSEC] (specifically, "IPsec processing is as previously
processing is as previously defined..."). defined...").
The process illustrated in Figure 1 also augments the IPsec The process illustrated in Figure 1 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 HC data item 5.2, Step 4) . After AH or ESP processing, the RoHC data item
retrieved from the SAD entry will indicate if traffic traversing the retrieved from the SAD entry will indicate if traffic traversing the
SA is handed to the HC module ([IPSEC], Section 5.2, Step 3a). SA is handed to the RoHC module ([IPSEC], Section 5.2, Step 3a).
Packets traversing an HC-disabled SA must follow normal IPsec Packets traversing an RoHC-disabled SA must follow normal IPsec
processing and must not be sent to the HC module. Conversely, processing and must not be sent to the RoHC module. Conversely,
packets traversing an HC-enabled SA must be sent to the HC module. packets traversing an RoHC-enabled SA must be sent to the RoHC
The decision at block B is determined by the value of the Next Header module. The decision at block B is determined by the value of the
field. If "compressed headers" is indicated, decompression is Next Header field of the security protocol header. If a RoHC header
applied using the appropriate HC protocol (Figure 1, Path 1). is indicated, decompression is applied (Figure 1, Path 1). However,
However, if the Next Header field does not contain the "compressed if the Next Header field does not indicate a RoHC header, the
headers" value, the decompressor must not attempt decompression decompressor must not attempt decompression (Figure 1, Path 2). Once
(Figure 1, Path 2). Once the HC module completes processing, IPsec the RoHC module completes processing, IPsec processing resumes, as
processing resumes, as described in Section 5.2, Step 4 of [IPSEC] described in Section 5.2, Step 4 of [IPSEC] (specifically "Then match
(specifically "Then match the packet against the inbound selectors the packet against the inbound selectors identified by the SAD ...").
identified by the SAD ...").
Note that to further reduce the size of an IPsec-protected packet, Note that to further reduce the size of an IPsec-protected packet,
HCoIPsec and IPcomp [IPCOMP] can be implemented in a nested fashion. RoHCoIPsec and IPcomp can be implemented in a nested fashion. For an
For an outbound packet, IPcomp is initially applied. Following the outbound packet, IPcomp is initially applied. Following the
application of IPcomp, the packet is sent to the HC module. Then, application of IPcomp, the packet is sent to the RoHC module. Then,
the HC module may compress the headers (e.g., the IP header) of the the RoHC module may compress the headers (e.g., the IP header) of the
IPcomp-processed packet. After the HC process completes, IPsec IPcomp-processed packet. After the RoHC process completes, IPsec
processing resumes. For inbound packets, these steps are reversed: processing resumes. For inbound packets, these steps are reversed:
first, the packet is IPsec-processed; then, headers are decompressed; first, the packet is IPsec-processed; then, headers are decompressed;
last, the payload of the packet is decompressed based on the last, the payload of the packet is decompressed based on the
appropriate IPcomp algorithm. appropriate IPcomp algorithm.
6.1.1. Header Compression Protocol Considerations 6.1.1. Header Compression Protocol Considerations
Traditional hop-by-hop HC protocols must be extended to operate The initial specification of RoHC [ROHC] may need to be extended to
efficiently over IPsec SAs. Compressor and decompressor operate efficiently over IPsec SAs. Specifically, compressor and
implementation considerations therefore must account for increased decompressor implementations must account for increased tolerance to
tolerance to packet reordering and packet loss between the compressor packet reordering and packet loss, and should minimize the amount of
and decompressor, and must minimize the amount of feedback sent from feedback sent from the decompressor to the compressor. To address
the decompressor to the compressor. this need, RoHCv2 [ROHCV2] defines various mechanisms that provide
increased robustness during these scenarios. Furthermore, within the
The ability to tolerate increased packet reordering between the context of IPsec, a RoHCv2 implementation can leverage additional
compressor and decompressor is a necessity for any HC protocol that mechanisms to improve performance over channels characterized by
is extended to operate over an IPsec SA. The following provides a packet reordering/loss. For example, various security protocols are
summary of the candidate HC solutions, and their tolerance to packet equipped with a sequence number that may be used by the decompressor
loss and reordering between the compressor and decompressor: to identify a packet as "sequentially late". This knowledge can be
o IPHC has been identified as a HC protocol that performs poorly utilized to increase the likelihood of successful decompression of a
over long round trip time (RTT), high BER links [ROHC]. reordered packet.
Extensions to IPHC to compress TCP/IP headers over an IPsec SA
should take into consideration longer RTTs, increased potential
for packet reordering and packet loss between the compressor and
decompressor.
o CRTP has also been identified as a HC protocol that performs
poorly over long RTT, high BER links [CRTPE]. Recent
modifications to the CRTP protocol, such as ECRTP, enable the CRTP
HC protocol to tolerate long RTTs and packet loss between the
compressor and decompressor. However, the reordering tolerance of
ECRTP still needs to be evaluated, as detailed in [ECRTPE]. Such
implementation aspects should be taken into consideration when
extending ECRTP to operate over IPsec SAs.
o ROHC is a protocol that is designed for high BER, long RTT links.
ROHC can be used to compress not only RTP/UDP/IP headers, but also
other traffic profiles such as TCP/IP, as defined in [ROHCTCP].
Similar to CRTP and IPHC, ROHC has been identified as vulnerable
to packet reordering events between the compressor and
decompressor[ROHCE]. Recent work [ROHCWEXT] suggests that the
implementation aspects of ROHC can be modified to achieve
tolerance to packet reordering events. Such implementation
aspects should be taken into consideration when extending ROHC to
operate over IPsec SAs.
Note that additional techniques may be used to augment a traditional
HC protocol's tolerance to packet reordering. For example, various
security protocols are equipped with a sequence number; this value
may be used by the decompressor to identify a packet as "sequentially
late". This knowledge can increase the likelihood of successful
decompression of a reordered packet.
In addition, HC protocols should minimize the amount of feedback
between decompressor and compressor. If a feedback channel from the
decompressor to the compressor is not used sparingly, the overall
gains from HCoIPsec can be significantly reduced. For example,
assume that ROHC is operating in bi-directional reliable mode, and is
instantiated over an IPsec tunnel mode SA. In this scenario, any
feedback sent from the decompressor to the compressor must be
tunneled. As such, the additional overhead incurred by tunneling
feedback will reduce the overall benefits of HC.
6.1.2. Initialization and Negotiation of HC Channel Additionally, RoHC implementations should minimize the amount of
feedback between decompressor and compressor. If a feedback channel
from the decompressor to the compressor is not used sparingly, the
overall gains from RoHCoIPsec can be significantly reduced. For
example, assume that RoHC is operating in bi-directional reliable
mode, and is instantiated over an IPsec tunnel mode SA. In this
scenario, any feedback sent from the decompressor to the compressor
must be tunneled. As such, the additional overhead incurred by
tunneling feedback will reduce the overall benefits of RoHC.
Hop-by-hop HC protocols use the underlying link layer (e.g., PPP) to 6.1.2. Initialization and Negotiation of the RoHC Channel
negotiate HC channel parameters. To remove HC protocol dependencies
on the underlying link layer, an additional mechanism is needed to
initialize a HC channel and its associated parameters prior to
HCoIPsec operation.
Initialization of the HC channel will either be achieved manually RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC
(i.e., administratively configured for manual SAs), or be performed channel parameters. In the case of RoHCoIPsec, channel parameters
by IPsec SA establishment protocols. The extensions required for are negotiated by another mechanism. Specifically, initialization of
IKEv2 to support HC parameter negotiation are detailed in [IKE-HC]. the RoHC channel is either achieved manually (i.e., administratively
configured for manual SAs), or is performed by IPsec SA establishment
protocols. The extensions required for IKEv2 to support RoHC
parameter negotiation are detailed in [IKE-ROHC].
If the HC 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 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 feedback from decompressor, while the other is used to communicate RoHC-feedback
the decompressor to the compressor. Note that the requirement for from the decompressor to the compressor. Note that the requirement
two SAs aligns with the operation of IKE, which creates SAs in pairs. for two SAs aligns with the operation of IKE, which creates SAs in
However, IPsec implementations will dictate how decompressor feedback pairs. However, IPsec implementations will dictate how decompressor
received on one SA is associated with a compressor on the other SA. feedback received on one SA is associated with a 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 HC As indicated in Section 6.1, new state information (i.e., a new RoHC
data item) is defined for each SA. The HC 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 HC module (HC-enabled) or bypasses the HC module and given SA to the RoHC module (RoHC-enabled) or bypasses the RoHC
sends the traffic through regular IPsec processing (HC-disabled). module and sends the traffic through regular IPsec processing (RoHC-
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 HC-enabled SA. This functionality uncompressed traffic traversing an RoHC-enabled SA. This
is needed in situations where packets traversing an HC-enabled SA do functionality is needed in situations where packets traversing a
not contain compressed headers. Such situations may occur when, for RoHC-enabled SA do not contain compressed headers. Such situations
example, a compressor supports strictly n compressed flows and can may occur when, for example, a compressor supports strictly n
not compress the n+1 flow that arrives. Another example is when compressed flows and can not compress the n+1 flow that arrives.
traffic (e.g., TCP/IP) is selected (by IPsec) to an HC-enabled SA, Another example is when traffic (e.g., TCP/IP) is selected (by IPsec)
but cannot be compressed by the HC process (e.g., because the to a RoHC-enabled SA, but cannot be compressed by the RoHC process
compressor does not support TCP/IP compression). In these (e.g., because the compressor does not support TCP/IP compression).
situations, the compressor must indicate that the packet contains In these situations, the compressor must indicate that the packet
uncompressed headers. Similarly, the decompressor must be able to contains uncompressed headers. Similarly, the decompressor must be
identify packets with uncompressed headers and not attempt to able to identify packets with uncompressed headers and not attempt to
decompress them. The Next Header field is used to demultiplex these decompress them. The Next Header field is used to demultiplex these
header-compressed versus uncompressed packets, as a "compressed header-compressed versus uncompressed packets, as a RoHC protocol
header" value will indicate the packet contains compressed headers. identifier will indicate the packet contains compressed headers. To
Therefore, an official IANA allocation from the ProtocolID registry accomplish this, an official IANA allocation from the ProtocolID
is required. The request for a ProtocolID allocation, in addition to registry [PROTOCOL] is required.
IPsec extensions to support HCoIPsec, are specified in [IPSEC-HC].
6.2. HCoIPsec Framework Summary The RoHC Data Item, IANA ProtocolID allocation, and other IPsec
extensions to support RoHCoIPsec, are specified in [IPSEC-ROHC].
To summarize, the following items are needed to achieve HCoIPsec: 6.2. RoHCoIPsec Framework Summary
o IKEv2 Extensions to Support HCoIPsec
o IPsec Extensions to Support HCoIPsec To summarize, the following items are needed to achieve RoHCoIPsec:
o IKEv2 Extensions to Support RoHCoIPsec
o IPsec Extensions to Support RoHCoIPsec
7. Security Considerations 7. Security Considerations
A malfunctioning header compressor (i.e., the compressor located at A malfunctioning RoHC compressor (i.e., the compressor located at the
the ingress of the IPsec tunnel) has the ability to send packets to ingress of the IPsec tunnel) has the ability to send packets to the
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.
8. IANA Considerations 8. IANA Considerations
None. None.
skipping to change at page 11, line 34 skipping to change at page 11, line 9
o Dr. Stephen Kent o Dr. Stephen Kent
o Dr. Carsten Bormann o Dr. Carsten Bormann
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
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 Mr. Jonah Pezeshki of Booz Renee Esposito, Mr. Etzel Brower, Dr. Jonah Pezeshki, and Ms. Michele
Allen Hamilton for their assistance in completing this work. Casey of Booz Allen Hamilton for their assistance in completing this
work.
10. References
10.1. Normative References
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508,
February 1999.
[ECRTP] Koren, et al., "Compressing IP/UDP/RTP Headers on Links 10. Informative References
with High Delay, Packet Loss, and Reordering", RFC 3545,
July 2003.
[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.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Compression Protocol (IPComp)", RFC 3173, September 2001. Internet Protocol", RFC 4301, December 2005.
[ROHCTCP] Pelletier, et al., "Robust Header Compression: A Profile
For TCP/IP (ROHC-TCP)", work in progress , February 2007.
[IKE-HC] Pezeshki, et al., "IKEv2 Extensions to Support HCoIPsec",
work in progress , February 2007.
[IPSEC-HC] [ROHC-CRTP]
Ertekin, et al., "IPsec Extensions to Support HCoIPsec", Bormann, et al., "A RoHC Profile for CRTP (RoHC-CRTP)",
work in progress , February 2007. work in progress , February 2007.
10.2. Informative References [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[PROTOCOL]
IANA, ""Assigned Internet Protocol Numbers", IANA registry
at: http://www.iana.org/assignments/protocol-numbers".
[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.
[CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
"Evaluation of CRTP Performance over Cellular Radio Compression Protocol (IPComp)", RFC 3173, September 2001.
Networks", IEEE Personal Communication Magazine , Volume
7, number 4, pp. 20-25, August 2000.
[ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression
Compression Algorithm ECRTP", November 2004. Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP, and
UDP-Lite", work in progress , May 2007.
[ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS", [IKE-ROHC]
RFC 4247, November 2005. Pezeshki, et al., "IKEv2 Extensions to Support
RoHCoIPsec", work in progress , February 2007.
[ROHCWEXT] [PROTOCOL]
Pelletier, et al., "ROHC over Channels That Can Reorder IANA, ""Assigned Internet Protocol Numbers", IANA registry
Packets", RFC 4224, January 2006. at: http://www.iana.org/assignments/protocol-numbers".
[IPSEC-ROHC]
Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec",
work in progress , February 2007.
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
 End of changes. 72 change blocks. 
331 lines changed or deleted 261 lines changed or added

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