draft-ietf-rohc-hcoipsec-02.txt   draft-ietf-rohc-hcoipsec-03.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Expires: December 28, 2006 R. Jasani Intended status: Informational R. Jasani
Booz Allen Hamilton Expires: April 25, 2007 Booz Allen Hamilton
June 26, 2006 October 22, 2006
Integration of Header Compression over IPsec Security Associations Integration of Header Compression over IPsec Security Associations
draft-ietf-rohc-hcoipsec-02 draft-ietf-rohc-hcoipsec-03
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 35
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 December 28, 2006. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Internet Protocol security mechanisms, such as IP Security (IPsec) IP Security (IPsec) [IPSEC] provides various security services for IP
[IPSEC], provide various security services for IP traffic. However, traffic. However, the benefits of IPsec come at the cost of
the benefits of IPsec come at the cost of increased overhead. This increased overhead. This document outlines a framework for
document defines a framework for integrating Header Compression (HC) integrating Header Compression (HC) over IPsec (HCoIPsec). By
over IPsec (HCoIPsec). By compressing the inner headers of IP compressing the inner headers of IP packets, HCoIPsec proposes to
packets, HCoIPsec proposes to reduce the amount of overhead reduce the amount of overhead associated with the transmission of
associated with the transmission of traffic over IPsec security traffic over IPsec Security Associations (SAs).
associations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement: Packet Overhead Associated with 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4
IPsec Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . 4
5. Overview of the HCoIPsec Framework . . . . . . . . . . . . 5 5. Overview of the HCoIPsec Framework . . . . . . . . . . . . 5
5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5 5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5
5.2. HCoIPsec Description . . . . . . . . . . . . . . . . . . . 5 5.2. HCoIPsec Summary . . . . . . . . . . . . . . . . . . . . . 5
6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6 6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6
6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 6 6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 7
6.1.1. Header Compression Scheme 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 HC 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. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10 6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . 14
1. Introduction 1. Introduction
This document identifies a framework for integrating HC over IPsec This document outlines a framework for integrating HC over IPsec
Security Associations (SAs). The goal of integrating HC with IPsec (HCoIPsec). The goal of HCoIPsec is to reduce the protocol overhead
is to reduce the protocol overhead associated with packets traversing associated with packets traversing between IPsec SA endpoints. This
between IPsec SA endpoints. This can be achieved by compressing the can be achieved by compressing the transport layer header (e.g., UDP,
transport layer header (e.g., UDP, TCP, etc.) and inner IP header of TCP, etc.) and inner IP header of packets at the ingress of the IPsec
packets at the ingress of the IPsec tunnel, and decompressing these tunnel, and decompressing these headers at the egress.
headers at the egress.
To realize HCoIPsec, this document proposes the use of Internet For HCoIPsec, this document assumes traditional HC protocols,
Protocol Header Compression [IPHC], Compressed Real Time Protocol Internet Protocol Header Compression [IPHC], Compressed Real Time
[CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and
Header Compression [ROHC], to compress the inner headers of IP Robust Header Compression [ROHC], will be used to compress the inner
packets traversing an IPsec tunnel. Since these traditional HC headers of IP packets traversing an IPsec tunnel. Since these
schemes operate on a hop-by-hop basis, several extensions must be traditional HC protocols are designed to operate on a hop-by-hop
defined to enable their operation over IPsec SAs. This document basis, they may require extensions to enable their operation over
details a framework which will allow these traditional hop-by-hop HC IPsec SAs. This document outlines a framework for extending the
schemes to be extended to operate at IPsec SA endpoints. usage of these traditional hop-by-hop HC protocols to operate at
IPsec SA endpoints.
HCoIPsec currently targets the application of HC to tunnel mode SAs. HCoIPsec targets the application of HC to tunnel mode SAs. Transport
However, future work may extend the framework to operate over mode SAs only encrypt/authenticate the payload of an IP packet,
transport mode SAs as well. Transport mode SAs only encrypt/ leaving the IP header untouched. Intermediate routers subsequently
authenticate the payload of an IP packet, leaving the IP header use the IP header to route the packet to a decryption device.
untouched. Intermediate routers subsequently use the outer IP header Therefore, if traditional HC protocols were to operate over IPsec
to route the packet to a decryption device. Therefore, if HC transport-mode SAs, (de)compression functionality can only be applied
mechanisms are extended to operate between IPsec transport-mode SA to the transport layer headers, and not to the IP header. Since
endpoints, (de)compression functionality can only be applied to the compression of transport layer headers alone does not provide
transport layer headers, and not to the IP header. Since compression substantial efficiency gains, the HCoIPsec framework outlined by this
of transport layer headers alone does not provide substantial document only concerns the application of HC to tunnel mode SAs.
efficiency gains, extending the HCoIPsec framework to support
transport mode SAs is left for future work.
2. Audience 2. Audience
The target audience includes those who are involved with the The target audience includes those who are involved with the
development of HC schemes, and IPsec implementations. Since development of HC protocols, and IPsec implementations. Since
traditional IETF HC schemes are designed to operate on a hop-by-hop traditional HC protocols have been designed to operate on a hop-by-
basis, they need to be modified to operate over IPsec SAs. hop basis, they may need to be modified or extended to be operational
Therefore, the authors target various HC and IPsec communities who over IPsec SAs. Therefore, the authors target various HC and IPsec
may consider extending hop-by-hop HC schemes and IPsec protocols to communities who may consider extending existing HC and IPsec
meet the requirements put forward in this document. Finally, this protocols to meet the requirements put forth in this document.
document is directed towards vendors developing IPsec devices which Finally, this document is directed towards vendors developing IPsec
will be deployed in bandwidth-constrained, IP networks. devices that will be deployed in bandwidth-constrained IP networks.
3. Terminology 3. Terminology
Terminology specific to discussion of HCoIPsec is introduced in this Terminology specific to HCoIPsec is introduced in this section.
section.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Compressed Traffic Compressed Traffic
Traffic that is processed by the compressor. Packet headers are Traffic that is processed by the compressor. Packet headers are
compressed using a compression profile. compressed using a specific header compression protocol.
Uncompressed Traffic Uncompressed Traffic
Traffic that is not processed by the compressor. Instead, this Traffic that is not processed by the compressor. Instead, this
type of traffic bypasses the HC process. type of traffic bypasses the HC process.
HC Process HC Process
Generic reference to either the compressor, decompressor, or any Generic reference to either the compressor, decompressor, or any
supporting header compression (HC) components. supporting header compression (HC) components.
IPsec Process IPsec Process
Generic reference to the Internet Protocol Security (IPsec) Generic reference to the Internet Protocol Security (IPsec)
process [IPSEC]. process [IPSEC].
4. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode Next Header
SAs
Refers to the Protocol (IPv4) or Next Header (IPv6, Extension)
field (see IANA web page at
http://www.iana.org/assignments/protocol-numbers).
4. Problem Statement: IPsec Packet Overhead
IPsec mechanisms provide various security services for IP networks. IPsec mechanisms provide various security services for IP networks.
The benefits of IPsec come at the cost of increased per-packet However, the benefits of IPsec come at the cost of increased per-
overhead. For example, traffic flow confidentiality (generally packet overhead. For example, traffic flow confidentiality
leveraged at security gateways) requires the tunneling of IP packets (generally leveraged at security gateways) requires the tunneling of
between IPsec implementations. Although these IPsec tunnels will IP packets between IPsec implementations. Although these IPsec
effectively mask the source-destination patterns that an intruder can tunnels will effectively mask the source-destination patterns that an
ascertain, IPsec tunnels come at the cost of increased per-packet intruder can ascertain, IPsec tunnels come at the cost of increased
overhead. Specifically, an ESP tunnel mode SA applied to an IPv6 per-packet overhead. Specifically, an ESP tunnel mode SA applied to
flow results in at least 50 bytes of additional overhead per packet. an IPv6 flow results in at least 50 bytes of additional overhead per
This additional overhead may be undesirable for many bandwidth- packet. This additional overhead may be undesirable for many
constrained wireless and/or satellite communications networks, as bandwidth-constrained wireless and/or satellite communications
these types of infrastructure are not overprovisioned. Consequently, networks, as these types of infrastructure are not overprovisioned.
the additional overhead incurred in an encryption-based environment HC applied on a per-hop basis over bandwidth-constrained link
may result in the inefficient utilization of bandwidth. technologies will also suffer from reduced performance when
encryption is used on the tunneled header, since encrypted headers
can not be compressed. Consequently, the additional overhead
incurred by an IPsec tunnel may 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. Some applications that characterized by small packet payloads. Some applications that
emanate small packet payloads include various voice codecs (e.g., emanate small packet payloads include various voice codecs. In
G.729). In addition, if these small packets are afforded the addition, if these small packets are afforded the security services
security services of an IPsec tunnel mode SA, the amount of per- of an IPsec tunnel mode SA, the amount of per-packet overhead is
packet overhead is magnified. Thus, a mechanism is needed to reduce magnified. Thus, a mechanism is needed to reduce the overhead
the overhead associated with such flows. associated with such flows.
5. Overview of the HCoIPsec Framework 5. Overview of the HCoIPsec Framework
5.1. HCoIPsec Assumptions 5.1. HCoIPsec Assumptions
The goal for HCoIPsec is to provide more efficient transport of IP The goal for HCoIPsec is to provide efficient transport of IP packets
packets between source and destination IPsec devices, without between source and destination IPsec devices, without compromising
compromising the security services offered by IPsec. As such, the the security services offered by IPsec. As such, the HCoIPsec
HCoIPsec framework was developed based on the following assumptions: framework was developed based on the following assumptions:
o Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) will be o Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) will be
leveraged to reduce the amount of overhead associated with packets leveraged to reduce the amount of overhead associated with packets
traversing an IPsec SA traversing an IPsec SA
o HC algorithms will be instantiated at the IPsec SA endpoints, and o HC algorithms will be instantiated at the IPsec SA endpoints, and
HC is applied on a per-SA basis HC is applied on a per-SA basis
5.2. HCoIPsec Description 5.2. HCoIPsec Summary
HC schemes reduce packet overhead in a network by exploiting inter- HC protocols reduce packet overhead in a network by exploiting intra-
packet redundancies of network and transport-layer header fields of a and inter-packet redundancies of network and transport-layer header
flow to reduce the amount of redundant header data transmitted fields of a flow.
between two nodes.
To apply traditional HC schemes over IPsec SAs, several extensions Existing HC protocols compress packet headers on a hop-by-hop basis.
need to be defined. Existing HC schemes 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, to fully integrate HC with IPsec SAs,
traditional hop-by-hop schemes need to be extended to operate at traditional hop-by-hop protocols may need to be extended to operate
IPsec SA endpoints. at IPsec SA endpoints.
The migration of traditional hop-by-hop HC schemes over IPsec SAs is The migration of traditional hop-by-hop HC protocols over IPsec SAs
straightforward, since SA endpoints provide source/destination pairs is straightforward, since SA endpoints provide source/destination
where (de)compression operations can take place. Compression in such pairs where (de)compression operations can take place. Compression
a manner offers a reduction of per-packet protocol overhead between in such a manner offers a reduction of per-packet protocol overhead
the two SA endpoints, and does not require compression and between the two SA endpoints, and does not require compression and
decompression cycles at the intermediate hops between IPsec decompression cycles at the intermediate hops between IPsec
implementations. Since HC schemes will now essentially operate over implementations. Since traditional HC protocols will now essentially
multiple hops, it is imperative that the performance of the HC operate over multiple hops, it is imperative that their performance
schemes is not severely impacted due to increased packet reordering is not severely impacted due to increased packet reordering and/or
and/or packet loss between the compressor and decompressor. packet loss between the compressor and decompressor.
In addition, since HC schemes will operate at IPsec SA endpoints, HC In addition, since HC protocols will operate at IPsec SA endpoints,
schemes can no longer rely on the underlying link layer for HC HC protocols can no longer rely on the underlying link layer for HC
parameter configuration and packet identification. Traditionally, HC parameter configuration and packet identification. Traditional HC
schemes use the underlying link layer to establish a set of protocols use the underlying link layer to establish a set of
configuration parameters at each end of the link, and for identifying configuration parameters at each end of the link, and some HC
different types of header-compressed packets. The HCoIPsec framework protocols (e.g., IPHC, CRTP, ECRTP) are also dependent on the link
proposes that HC session parameter configuration and header- layer framing for identifying different types of header-compressed
compressed packet identification is accomplished by the SA management packets. The HCoIPsec framework proposes that HC channel parameter
protocol (e.g., IKEv2) and the security protocol next header field, configuration is accomplished by the SA management protocol (e.g.,
respectively. 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, 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 HCoIPsec 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 section determines if the packet was received on an HC-enabled SA (see
6.1), and if the packet maintains compressed headers. If both of section 6.1) and if the packet maintains compressed headers. If both
these conditions are met, decompression of the inner packet headers of these conditions are met, decompression of the inner packet
is performed. After decompression, the packet is checked against the headers is performed. After decompression, the packet is checked
access controls imposed on all inbound traffic associated with the SA against the access controls imposed on all inbound traffic associated
(as specified in RFC 4301). with the SA (as specified in RFC 4301).
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. HC
schemes such as ROHC and IPHC are capable of compressing these protocols such as ROHC are capable of compressing the security
outer headers on a hop-by-hop basis. Further discussion on the protocol and outer IP headers on a hop-by-hop basis. Further
compression of outer headers is outside the scope of this discussion on the compression of outer headers is outside the
document. scope of this document.
If IPsec NULL encryption is applied to packets, HC schemes may still If IPsec NULL encryption is applied to packets, HC protocols may
be applied to the inner headers at the IPsec SA endpoints. Inbound still be applied to the inner headers at the IPsec SA endpoints.
and outbound packets are still processed as was previously described. Inbound and outbound packets are still processed as was previously
For scenarios where NULL-encrypted packets traverse intermediate described.
nodes between the IPsec SA endpoints, the intermediary nodes must not
attempt to (de)compress the inner IP and/or transport layer headers.
6. Details of the HCoIPsec Framework 6. Details of the HCoIPsec Framework
6.1. HC and IPsec Integration 6.1. HC and IPsec Integration
Based on these assumptions, Figure 1 illustrates the components Based on these assumptions, Figure 1 illustrates the components
required to integrate HC with the IPsec process, i.e., HCoIPsec. required to integrate HC with the IPsec process, i.e., HCoIPsec.
+-------------------------------+ +-------------------------------+
| HC Module | | HC Module |
| | | |
| | | |
+-----+ | +-----+ +---------+ | +-----+ | +-----+ +---------+ |
| | HC-enabled | | | | HC | | | | | | | | HC | |
--| A |--------------------| B |-----| Process |------> Path 1 --| A |---------| B |-----| Process |------> Path 1
| | | | | | | | | | | | | | | | (HC-enabled SA)
+-----+ | +-----+ +---------+ | +-----+ | +-----+ +---------+ |
| | | | | | | |
| | |-------------------------> Path 2 | | |-------------------------> Path 2
| | | | | | (HC-enabled SA)
| +-------------------------------+ | +-------------------------------+
| |
| HC-disabled |
+----------------------------------------------------> Path 3 |
|
+-----------------------------------------> Path 3
(HC-disabled SA)
Figure 1: Integration of HC with IPsec. Figure 1: Integration of HC 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 RFC 4301 (Steps 1-2, Section IPsec processing is consistent with RFC 4301 (Steps 1-2, Section
5.1). The HC data item (part of the SA state information) retrieved 5.1). The HC data item (part of the SA state information) retrieved
from the "relevant SAD entry" (RFC4301, Section 5.1, Step3a) from the "relevant SAD entry" (RFC4301, Section 5.1, Step3a)
determines if the traffic traversing the SA is handed to the HC determines if the traffic traversing the SA is handed to the HC
module (Figure 1, decision block A). Packets selected to an HC- module (Figure 1, decision block A). Packets selected to an HC-
disabled SA must follow normal IPsec processing and must not be sent disabled SA must follow normal IPsec processing and must not be sent
to the HC module (Figure 1, Path 3). Conversely, packets selected to to the HC module (Figure 1, Path 3). Conversely, packets selected to
an HC-enabled SA must be sent to the HC module. The decision at an HC-enabled SA must be sent to the HC module. The decision at
block B then determines if the packet can be compressed. If it is block B then determines if the packet can be compressed. If it is
determined that the packet will be compressed, the Next Header field determined that the packet will be compressed, the Next Header field
of the security protocol header (e.g., ESP, AH) is populated with the of the security protocol header (e.g., ESP, AH) is populated with a
"compressed headers" value, and packet headers are compressed based "compressed headers" value, and packet headers are compressed based
on the appropriate compression profile (Figure 1, Path 1). However, on the compression protocol (Figure 1, Path 1). However, if it is
if it is determined that the packet will not be compressed, the Next determined that the packet will not be compressed (e.g., due to one
Header field is populated with the appropriate value indicating the the reasons described in Section 6.1.3), the Next Header field is
next level protocol (Figure 1, Path 2). After the HC process populated with the appropriate value indicating the next level
completes, IPsec processing resumes, as described in Section 5.1, protocol (Figure 1, Path 2). After the HC process completes, IPsec
Step3a, of RFC4301 (specifically, "IPsec processing is as previously processing resumes, as described in Section 5.1, Step3a, of RFC4301
defined..."). (specifically, "IPsec processing is as previously 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, processing is performed (RFC4301, Section 5.2, For inbound packets, IPsec processing is performed (RFC4301, Section
Steps 1-3) followed by AH or ESP processing (RFC4301, Section 5.2, 5.2, Steps 1-3) followed by AH or ESP processing (RFC4301, Section
Step 4) . After AH or ESP processing, the HC data item retrieved 5.2, Step 4) . After AH or ESP processing, the HC data item
from the SAD entry will indicate if traffic traversing the SA is retrieved from the SAD entry will indicate if traffic traversing the
handed to the HC module (RFC4301, Section 5.2, Step 3a). Packets SA is handed to the HC module (RFC4301, Section 5.2, Step 3a).
traversing an HC-disabled SA must follow normal IPsec processing and Packets traversing an HC-disabled SA must follow normal IPsec
must not be sent to the HC module. Conversely, packets traversing an processing and must not be sent to the HC module. Conversely,
HC-enabled SA must be sent to the HC module. The decision at block B packets traversing an HC-enabled SA must be sent to the HC module.
then determines if the "Next Header" field contains the "compressed The decision at block B is determined by the value of the Next Header
header" value, which indicates that the packet's payload contains field. If "compressed headers" is indicated, decompression is
compressed headers. If "compressed headers" is indicated, the applied using the appropriate HC protocol (Figure 1, Path 1).
appropriate decompression profile is applied (Figure 1, Path 1). However, if the Next Header field does not contain the "compressed
However, if the packet's "Next Header" field does not contain the headers" value, the decompressor must not attempt decompression
"compressed headers" value, the decompressor must not attempt (Figure 1, Path 2). IPsec processing resumes once the HC module
decompression (Figure 1, Path 2). IPsec processing resumes once the completes processing, as described in Section 5.2, Step 4 of RFC
HC module completes processing, as described in Section 5.2, Step 4 4301(specifically "Then match the packet against the inbound
of RFC 4301(specifically "Then match the packet against the inbound
selectors identified by the SAD ..."). selectors identified by the SAD ...").
6.1.1. Header Compression Scheme Considerations 6.1.1. Header Compression Protocol Considerations
Traditional hop-by-hop HC schemes must be extended to operate Traditional hop-by-hop HC protocols must be extended to operate
efficiently over IPsec SAs. Implementation considerations for this efficiently over IPsec SAs. Compressor and decompressor
includes increasing tolerance to packet reordering and packet loss implementation considerations therefore must account for increased
between the compressor and decompressor, and minimizing the amount of tolerance to packet reordering and packet loss between the compressor
feedback sent from the decompressor to the compressor. and decompressor, and minimizing the amount of feedback sent from the
decompressor to the compressor.
The ability to tolerate increased packet reordering between the The ability to tolerate increased packet reordering between the
compressor and decompressor is a necessity for any HC scheme that is compressor and decompressor is a necessity for any HC protocol that
extended to operate over an IPsec SA. The following provides a is extended to operate over an IPsec SA. The following provides a
summary of the candidate HC solutions, and their tolerance to packet summary of the candidate HC solutions, and their tolerance to packet
loss and reordering between the compressor and decompressor: loss and reordering between the compressor and decompressor:
o IPHC has been identified as a HC scheme that performs poorly over o IPHC has been identified as a HC protocol that performs poorly
long round trip time (RTT), high BER links [ROHC]. Extensions to over long round trip time (RTT), high BER links [ROHC].
IPHC to compress TCP/IP headers over an IPsec SA should take into Extensions to IPHC to compress TCP/IP headers over an IPsec SA
consideration longer RTTs, increased potential for packet should take into consideration longer RTTs, increased potential
reordering and IPLR between the compressor and decompressor. for packet reordering and packet loss between the compressor and
o CRTP has also been identified as a HC scheme that performs poorly decompressor.
over long RTT, high BER links [CRTPE]. Recent modifications to o CRTP has also been identified as a HC protocol that performs
the CRTP scheme, such as ECRTP, enable the CRTP HC scheme to poorly over long RTT, high BER links [CRTPE]. Recent
tolerate long RTTs and packet loss between the compressor and modifications to the CRTP protocol, such as ECRTP, enable the CRTP
decompressor. However, the reordering tolerance of ECRTP still HC protocol to tolerate long RTTs and packet loss between the
needs to be evaluated, as detailed in [ECRTPE]. Such 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 implementation aspects should be taken into consideration when
extending ECRTP to operate over IPsec SAs. extending ECRTP to operate over IPsec SAs.
o ROHC is a robust HC scheme that is designed for high BER, long RTT o ROHC is a protocol that is designed for high BER, long RTT links.
links. ROHC can be used to compress not only RTP/UDP/IP headers, ROHC can be used to compress not only RTP/UDP/IP headers, but also
but also other traffic profiles such as TCP/IP, as defined in other traffic profiles such as TCP/IP, as defined in [ROHCTCP].
[ROHCTCP]. Similar to CRTP and IPHC, ROHC has been identified as Similar to CRTP and IPHC, ROHC has been identified as vulnerable
vulnerable to packet reordering events between the compressor and to packet reordering events between the compressor and
decompressor[ROHCE]. Recent work [ROHCWEXT] suggests that the decompressor[ROHCE]. Recent work [ROHCWEXT] suggests that the
implementation aspects of ROHC can be modified to achieve implementation aspects of ROHC can be modified to achieve
tolerance to packet reordering events. Such implementation tolerance to packet reordering events. Such implementation
aspects should be taken into consideration when extending ROHC to aspects should be taken into consideration when extending ROHC to
operate over IPsec SAs. operate over IPsec SAs.
In addition, HC schemes should minimize the amount of feedback 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 between decompressor and compressor. If a feedback channel from the
decompressor to the compressor is not used sparingly, the overall decompressor to the compressor is not used sparingly, the overall
gains from HCoIPsec can be significantly reduced. For example, gains from HCoIPsec can be significantly reduced. For example,
assume that ROHC is operating in bi-directional reliable mode, and is assume that ROHC is operating in bi-directional reliable mode, and is
instantiated over an IPsec tunnel mode SA. In this scenario, any instantiated over an IPsec tunnel mode SA. In this scenario, any
feedback sent from the decompressor to the compressor must be feedback sent from the decompressor to the compressor must be
tunneled. As such, the additional overhead incurred by tunneling tunneled. As such, the additional overhead incurred by tunneling
feedback will reduce the overall benefits of HC. feedback will reduce the overall benefits of HC.
6.1.2. Initialization and Negotiation of HC Channel 6.1.2. Initialization and Negotiation of HC Channel
Hop-by-hop HC schemes use the underlying link layer (e.g., PPP) to Hop-by-hop HC protocols use the underlying link layer (e.g., PPP) to
negotiate HC channel parameters. To remove HC scheme dependencies on negotiate HC channel parameters. To remove HC protocol dependencies
the underlying link layer, an additional mechanism is needed to on the underlying link layer, an additional mechanism is needed to
initialize a HC channel and its associated parameters prior to HC initialize a HC channel and its associated parameters prior to HC
scheme operation. protocol operation.
Initialization of the HC channel will either be achieved manually Initialization of the HC channel will either be achieved manually
(i.e., administratively configured for manual SAs), or be performed (i.e., administratively configured for manual SAs), or be performed
by IPsec SA establishment protocols, e.g. IKEv2. During SA by IPsec SA establishment protocols, e.g. IKEv2. During SA
initialization, the SA establishment protocol will be extended to initialization, the SA establishment protocol will be extended to
negotiate the HC scheme's channel parameters. The specifics for this negotiate the HC protocol's channel parameters. The specifics for
proposal are detailed in a separate spectification, "IKEv2/IPsec this proposal are detailed in [IKE-HC].
Extensions to Support HCoIPsec".
If the HC scheme requires bi-directional communications, two SAs must If the HC protocol requires bi-directional communications, two SAs
be instantiated between the IPsec implementations. One of the two must be instantiated between the IPsec implementations. One of the
SAs is used for carrying traffic from the compressor to the two SAs is used for carrying traffic from the compressor to the
decompressor, while the other is used to communicate feedback from decompressor, while the other is used to communicate feedback from
the decompressor to the compressor. IPsec implementations will the decompressor to the compressor. Note that this requirement for
dictate how decompressor feedback received on one SA is associated two SAs aligns with the operation of IKE, which is capable of
with a compressor on the other SA. creating SA pairs. However, IPsec implementations will dictate how
decompressor 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 HC
data item) is defined for each SA. The HC data item is used by the data item) is defined for each SA. The HC 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 HC module (HC-enabled) or bypasses the HC module and
sends the traffic through regular IPsec processing (HC-disabled). sends the traffic through regular IPsec processing (HC-disabled).
In addition, the "Next Header" field of the IPsec security protocol In addition, the Next Header field of the IPsec security protocol
(e.g., AH or ESP) header is used to demultiplex header-compressed (e.g., AH or ESP) header is used to demultiplex header-compressed
traffic from uncompressed traffic traversing an HC-enabled SA. This traffic from uncompressed traffic traversing an HC-enabled SA. This
functionality is needed in situations where packets traversing an HC- functionality is needed in situations where packets traversing an HC-
enabled SA are not compressed by the compressor. Such situations may enabled SA are not compressed by the compressor. Such situations may
occur when, for example, a compressor supports strictly n compressed occur when, for example, a compressor supports strictly n compressed
flows and can not compress the n+1 flow that arrives. Another flows and can not compress the n+1 flow that arrives. Another
example is when traffic (e.g., TCP/IP) is selected to an HC-enabled example is when traffic (e.g., TCP/IP) is selected (by IPsec) to an
SA, but cannot be compressed by the HC process (e.g., because the HC-enabled SA, but cannot be compressed by the HC process (e.g.,
compressor does not support TCP/IP compression). In these because the compressor does not support TCP/IP compression). In
situations, the compressor must be able to indicate that the packet these situations, the compressor must indicate that the packet
contains uncompressed headers. Similarly, the decompressor must be contains uncompressed headers. Similarly, the decompressor must be
able to identify packets with uncompressed headers and not attempt to able to identify packets with uncompressed headers and not attempt to
decompress them. Therefore, an allocation for "compressed headers" decompress them. As such, the Next Header field is used to
will need to be reserved from the IANA "Protocol Numbers" registry, demultiplex these header-compressed versus uncompressed packets, as a
which will be defined in a separate specification. The "compressed "compressed header" value will indicate the packet contains
headers" value will indicate that the next layer protocol header is compressed headers.
composed of compressed headers. Note: As indicated in the description of HCoIPsec inbound and
outbound processing, the Next Header field is used to identify
compressed packets on an HC-enabled SA. Because the Next Header
field value is only leveraged at the IPsec implementations, an
official IANA allocation from the ProtocolID registry may not be
required. Future discussions of HCoIPsec will determine the
appropriate path forward.
6.2. HCoIPsec Framework Summary 6.2. HCoIPsec Framework Summary
[Note to RFC Editor: this section may be removed on publication as an
RFC.]
To summarize, the following items are needed to achieve HCoIPsec: To summarize, the following items are needed to achieve HCoIPsec:
o Extensions to traditional HC schemes which enable their operation o Extensions to traditional HC protocols which enable their
at IPsec SA enpoints operation at IPsec SA enpoints
o Extensions to IKE/IPsec to support HC parameter configuration o Extensions to IKEv2 to Support Header Compression over IPsec
(HCoIPsec)
o Allocation of one value for "compressed headers" from the IANA o Allocation of one value for "compressed headers" from the IANA
"Protocol Numbers" registry "Protocol Numbers" registry (This specification may not be
necessary, as indicated in Section 6.1.3)
7. Security Considerations 7. Security Considerations
A malfunctioning header compressor (i.e., the compressor located at A malfunctioning header 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 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
skipping to change at page 11, line 4 skipping to change at page 11, line 24
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.
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. In addition, the authors would like to
thank the following for their numerous reviews and comments to this thank the following for their numerous reviews and comments to this
document: document:
o Dr. Stephen Kent o Dr. Stephen Kent
o Dr. Carsten Bormann o Dr. Carsten Bormann
o Mr. Lars-Erik Jonnson o Mr. Tero Kivinen
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
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, and Mr. Jonah Pezeshki of Booz
Allen Hamilton for their assistance in completing this work. Allen Hamilton for their assistance in completing this work.
10. References 10. References
10.1. Normative References 10.1. Normative References
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header [IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999. Compression", RFC 2507, February 1999.
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
February 1999. February 1999.
[ECRTP] Koren, T. and et. al., "Compressing IP/UDP/RTP Headers on [ECRTP] Koren, et al., "Compressing IP/UDP/RTP Headers on Links
Links with High Delay, Packet Loss, and Reordering", with High Delay, Packet Loss, and Reordering", RFC 3545,
RFC 3545, July 2003. 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.
[ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header [ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header
Compression Algorithm ECRTP", November 2004. Compression Algorithm ECRTP", November 2004.
[ROHCTCP] Pelletier, G. and et. al, "Robust Header Compression: A [ROHCTCP] Pelletier, et al., "Robust Header Compression: A Profile
Profile For TCP/IP (ROHC-TCP)", work in progress , For TCP/IP (ROHC-TCP)", work in progress , January 2006.
January 2006.
[ROHCWEXT] [ROHCWEXT]
Pelletier, G. and et. al, "ROHC over Channels That Can Pelletier, et al., "ROHC over Channels That Can Reorder
Reorder Packets", RFC 4224, January 2006. Packets", RFC 4224, January 2006.
[IKE-HC] Jasani, et al., "Extensions to IKEv2 to Support HCoIPsec",
work in progress , September 2006.
10.2. Informative References 10.2. Informative References
[ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303,
December 2005. December 2005.
[HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header [HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header
Compression over MPLS", April 2005. Compression over MPLS", April 2005.
[CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, [CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro,
skipping to change at page 14, line 5 skipping to change at page 14, line 5
Email: christou_chris@bah.com Email: christou_chris@bah.com
Rohan Jasani 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: jasani_rohan@bah.com Email: jasani_rohan@bah.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 14, line 29 skipping to change at page 14, line 45
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 61 change blocks. 
250 lines changed or deleted 273 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/