draft-ietf-rohc-hcoipsec-03.txt   draft-ietf-rohc-hcoipsec-04.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: April 25, 2007 Booz Allen Hamilton Expires: August 28, 2007 Booz Allen Hamilton
October 22, 2006 February 24, 2007
Integration of Header Compression over IPsec Security Associations Integration of Header Compression over IPsec Security Associations
draft-ietf-rohc-hcoipsec-03 draft-ietf-rohc-hcoipsec-04
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 April 25, 2007. This Internet-Draft will expire on August 28, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
IP Security (IPsec) [IPSEC] provides various security services for IP IP Security (IPsec) [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 Header Compression (HC) over IPsec (HCoIPsec). By
compressing the inner headers of IP packets, HCoIPsec proposes to compressing the inner headers of IP packets, HCoIPsec proposes to
reduce the amount of overhead associated with the transmission of 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 HCoIPsec Framework . . . . . . . . . . . . 5
5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5 5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5
5.2. HCoIPsec Summary . . . . . . . . . . . . . . . . . . . . . 5 5.2. Summary of the HCoIPsec Framework . . . . . . . . . . . . 5
6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6 6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6
6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 7 6.1. HC 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 HC Channel . . . . . . . 9
6.1.3. Encapsulation and Identification of Header Compressed 6.1.3. Encapsulation and Identification of Header Compressed
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 10 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10 6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
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 outlines a framework for integrating HC over IPsec This document outlines a framework for integrating HC over IPsec
(HCoIPsec). The goal of HCoIPsec is to reduce the protocol overhead (HCoIPsec). The goal of HCoIPsec is to reduce the protocol overhead
associated with packets traversing between IPsec SA endpoints. This associated with packets traversing between IPsec SA endpoints. This
can be achieved by compressing the transport layer header (e.g., UDP, can be achieved by compressing the transport layer header (e.g., UDP,
TCP, etc.) and inner IP header of packets at the ingress of the IPsec TCP, etc.) and inner IP header of packets at the ingress of the IPsec
tunnel, and decompressing these headers at the egress. tunnel, and decompressing these headers at the egress.
For HCoIPsec, this document assumes traditional HC protocols, For HCoIPsec, this document assumes that existing HC protocols, such
Internet Protocol Header Compression [IPHC], Compressed Real Time as Internet Protocol Header Compression [IPHC], Compressed Real Time
Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and
Robust Header Compression [ROHC], will be used to compress the inner Robust Header Compression [ROHC], will be used to compress the inner
headers of IP packets traversing an IPsec tunnel. Since these headers of IP packets traversing an IPsec tunnel. Since these HC
traditional HC protocols are designed to operate on a hop-by-hop protocols are designed to operate on a hop-by-hop basis, they may
basis, they may require extensions to enable their operation over require extensions to enable their operation over IPsec SAs. This
IPsec SAs. This document outlines a framework for extending the document outlines a framework for extending the usage of these hop-
usage of these traditional hop-by-hop HC protocols to operate at by-hop HC protocols to operate at IPsec SA endpoints.
IPsec SA endpoints.
HCoIPsec targets the application of HC to tunnel mode SAs. Transport HCoIPsec targets the application of HC to tunnel mode SAs. Transport
mode SAs only encrypt/authenticate the payload of an IP packet, mode SAs only encrypt/authenticate the payload of an IP packet,
leaving the IP header untouched. Intermediate routers subsequently leaving the IP header untouched. Intermediate routers subsequently
use the IP header to route the packet to a decryption device. use this IP header to route the packet to a decryption device.
Therefore, if traditional HC protocols were to operate over IPsec Therefore, if traditional HC protocols were to operate over IPsec
transport-mode SAs, (de)compression functionality can only be applied transport-mode SAs, (de)compression functionality can only be applied
to the transport layer headers, and not to the IP header. Since to the transport layer headers, and not to the IP header. Because
compression of transport layer headers alone does not provide current specifications for HC protocols do not include support for
substantial efficiency gains, the HCoIPsec framework outlined by this the compression of transport layer headers alone, the HCoIPsec
document only concerns the application of HC to tunnel mode SAs. framework outlined by this document describes the application of HC
to tunnel mode SAs.
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 protocols, and IPsec implementations. Since development of HC protocols, and IPsec implementations. Since
traditional HC protocols have been designed to operate on a hop-by- traditional HC protocols have been designed to operate on a hop-by-
hop basis, they may need to be modified or extended to be operational hop basis, they may need to be modified or extended to be operational
over IPsec SAs. Therefore, the authors target various HC and IPsec over IPsec SAs. Therefore, the authors target various HC and IPsec
communities who may consider extending existing HC and IPsec communities who may consider extending existing HC and IPsec
protocols to meet the requirements put forth in this document. protocols to meet the requirements put forth in this document.
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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, 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 (see IANA web page at field [PROTOCOL].
http://www.iana.org/assignments/protocol-numbers).
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, IPsec tunnels come at the cost of increased intruder can ascertain, tunneling comes at the cost of increased per-
per-packet overhead. Specifically, an ESP tunnel mode SA applied to packet overhead. Specifically, an ESP ([ESP]) tunnel mode SA applied
an IPv6 flow results in at least 50 bytes of additional overhead per to an IPv6 flow results in at least 50 bytes of additional overhead
packet. This additional overhead may be undesirable for many per 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 HC applied on a per-hop basis over bandwidth-constrained link
technologies will also suffer from reduced performance when technologies will also suffer from reduced performance when
encryption is used on the tunneled header, since encrypted headers encryption is used on the tunneled header, since encrypted headers
can not be compressed. Consequently, the additional overhead can not be compressed. Consequently, the additional overhead
incurred by an IPsec tunnel may result in the inefficient utilization incurred by an IPsec tunnel may 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. Some applications that
emanate small packet payloads include various voice codecs. In generate small packet payloads include various voice codecs. In
addition, if these small packets are afforded the security services addition, if these small packets are afforded the security services
of an IPsec tunnel mode SA, the amount of per-packet overhead is of an IPsec tunnel mode SA, the amount of per-packet overhead is
magnified. Thus, a mechanism is needed to reduce the overhead increased. Thus, a mechanism is needed to reduce 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 efficient transport of IP packets The goal of HCoIPsec is to provide efficient transport of IP packets
between source and destination IPsec devices, without compromising between source and destination IPsec devices, without compromising
the security services offered by IPsec. As such, the HCoIPsec the security services offered by IPsec. As such, the 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 Summary 5.2. Summary of the HCoIPsec Framework
HC protocols reduce packet overhead in a network by exploiting intra- HC protocols reduce packet overhead in a network by exploiting intra-
and inter-packet redundancies of network and transport-layer header and 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. Existing HC protocols compress packet headers on a hop-by-hop basis.
However, IPsec SAs are instantiated between two IPsec However, IPsec SAs are instantiated between two IPsec
implementations, with multiple hops between the 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 protocols may need to be extended to operate traditional hop-by-hop protocols may need to be extended to operate
at IPsec SA endpoints. at IPsec SA endpoints.
The migration of traditional hop-by-hop HC protocols over IPsec SAs The migration of hop-by-hop HC protocols over IPsec SAs is
is straightforward, since SA endpoints provide source/destination straightforward, since SA endpoints provide source/destination pairs
pairs where (de)compression operations can take place. Compression where (de)compression operations can take place. Compression in such
in such a manner offers a reduction of per-packet protocol overhead a manner offers a reduction of per-packet protocol overhead between
between the two SA endpoints, and does not require compression and 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 traditional HC protocols will now essentially implementations. Since existing HC protocols will now essentially
operate over multiple hops, it is imperative that their performance operate over multiple hops, it is imperative that their performance
is not severely impacted due to increased packet reordering and/or is not severely impacted due to increased packet reordering and/or
packet loss between the compressor and decompressor. packet loss between the compressor and decompressor.
In addition, since HC protocols will operate at IPsec SA endpoints, In addition, since HC protocols will operate at IPsec SA endpoints,
HC protocols 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. Traditional HC parameter configuration and packet identification. Existing HC
protocols 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 some HC configuration parameters at each end of the link, and some HC
protocols (e.g., IPHC, CRTP, ECRTP) are also dependent on the link protocols (e.g., IPHC, CRTP, ECRTP) are also dependent on the link
layer framing for identifying different types of header-compressed layer framing for identifying different types of header-compressed
packets. The HCoIPsec framework proposes that HC channel parameter packets. The HCoIPsec framework proposes that HC channel parameter
configuration is accomplished by the SA management protocol (e.g., configuration is accomplished by the SA management protocol (e.g.,
IKEv2), while identification of compressed header packets (in IKEv2), while identification of compressed header packets (in
contrast to uncompressed packets) is provided through the Next Header contrast to uncompressed packets) is provided through the Next Header
field of the security protocol (e.g., AH, ESP). In addition, HC field of the security protocol (e.g., AH [AH], ESP). In addition, HC
protocols that require the identification of different types of protocols that require the identification of different types of
header-compressed packets will have to be extended with such a header-compressed packets will have to be extended with such a
mechanism. 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 determines if the packet was received on an HC-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 RFC 4301). 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. HC
protocols such as ROHC are capable of compressing the security protocols such as ROHC are capable of compressing the security
protocol and outer IP headers on a hop-by-hop basis. Further protocol and the outer IP header on a hop-by-hop basis.
discussion on the compression of outer headers is outside the
scope of this document.
If IPsec NULL encryption is applied to packets, HC protocols may If IPsec NULL encryption is applied to packets, HC protocols may
still be applied to the inner headers at the IPsec SA endpoints. still be applied to the inner headers at the IPsec SA endpoints.
Inbound and outbound packets are still processed as was previously Inbound and outbound packets are still processed as was previously
described. described.
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 Figure 1 illustrates the components required to integrate HC with the
required to integrate HC with the IPsec process, i.e., HCoIPsec. IPsec process, i.e., HCoIPsec.
+-------------------------------+ +-------------------------------+
| HC Module | | HC Module |
| | | |
| | | |
+-----+ | +-----+ +---------+ | +-----+ | +-----+ +---------+ |
| | | | | | HC | | | | | | | | HC | |
--| A |---------| B |-----| Process |------> Path 1 --| A |---------| B |-----| Process |------> Path 1
| | | | | | | | (HC-enabled SA) | | | | | | | | (HC-enabled SA)
+-----+ | +-----+ +---------+ | +-----+ | +-----+ +---------+ |
skipping to change at page 7, line 34 skipping to change at page 7, line 29
| |
| |
| |
+-----------------------------------------> Path 3 +-----------------------------------------> Path 3
(HC-disabled SA) (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 [IPSEC] (Steps 1-2, Section 5.1).
5.1). The HC data item (part of the SA state information) retrieved The HC data item (part of the SA state information) retrieved from
from the "relevant SAD entry" (RFC4301, Section 5.1, Step3a) the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if
determines if the traffic traversing the SA is handed to the HC the traffic traversing the SA is handed to the HC module (Figure 1,
module (Figure 1, decision block A). Packets selected to an HC- decision block A). Packets selected to an HC-disabled SA must follow
disabled SA must follow normal IPsec processing and must not be sent normal IPsec processing and must not be sent to the HC module (Figure
to the HC module (Figure 1, Path 3). Conversely, packets selected to 1, Path 3). Conversely, packets selected to an HC-enabled SA must be
an HC-enabled SA must be sent to the HC module. The decision at sent to the HC module. The decision at block B then determines if
block B then determines if the packet can be compressed. If it is the packet can be compressed. If it is determined that the packet
determined that the packet will be compressed, the Next Header field will be compressed, the Next Header field of the security protocol
of the security protocol header (e.g., ESP, AH) is populated with a header (e.g., ESP, AH) is populated with a "compressed headers"
"compressed headers" value, and packet headers are compressed based value, and packet headers are compressed based on the compression
on the compression protocol (Figure 1, Path 1). However, if it is protocol (Figure 1, Path 1). However, if it is determined that the
determined that the packet will not be compressed (e.g., due to one packet will not be compressed (e.g., due to one the reasons described
the reasons described in Section 6.1.3), the Next Header field is in Section 6.1.3), the Next Header field is populated with the
populated with the appropriate value indicating the next level appropriate value indicating the next level protocol (Figure 1, Path
protocol (Figure 1, Path 2). After the HC process completes, IPsec 2). After the HC process completes, IPsec processing resumes, as
processing resumes, as described in Section 5.1, Step3a, of RFC4301 described in Section 5.1, Step3a, of [IPSEC] (specifically, "IPsec
(specifically, "IPsec processing is as previously defined..."). 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, IPsec processing is performed (RFC4301, Section For inbound packets, IPsec processing is performed ([IPSEC], Section
5.2, Steps 1-3) followed by AH or ESP processing (RFC4301, 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 HC 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 (RFC4301, Section 5.2, Step 3a). SA is handed to the HC module ([IPSEC], Section 5.2, Step 3a).
Packets traversing an HC-disabled SA must follow normal IPsec Packets traversing an HC-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 HC module. Conversely,
packets traversing an HC-enabled SA must be sent to the HC module. packets traversing an HC-enabled SA must be sent to the HC module.
The decision at block B is determined by the value of the Next Header The decision at block B is determined by the value of the Next Header
field. If "compressed headers" is indicated, decompression is field. If "compressed headers" is indicated, decompression is
applied using the appropriate HC protocol (Figure 1, Path 1). applied using the appropriate HC protocol (Figure 1, Path 1).
However, if the Next Header field does not contain the "compressed However, if the Next Header field does not contain the "compressed
headers" value, the decompressor must not attempt decompression headers" value, the decompressor must not attempt decompression
(Figure 1, Path 2). IPsec processing resumes once the HC module (Figure 1, Path 2). Once the HC module completes processing, IPsec
completes processing, as described in Section 5.2, Step 4 of RFC processing resumes, as described in Section 5.2, Step 4 of [IPSEC]
4301(specifically "Then match the packet against the inbound (specifically "Then match the packet against the inbound selectors
selectors identified by the SAD ..."). identified by the SAD ...").
Note that to further reduce the size of an IPsec-protected packet,
HCoIPsec and IPcomp [IPCOMP] can be implemented in a nested fashion.
For an outbound packet, IPcomp is initially applied. Following the
application of IPcomp, the packet is sent to the HC module. Then,
the HC module may compress the headers (e.g., the IP header) of the
IPcomp-processed packet. After the HC process completes, IPsec
processing resumes. For inbound packets, these steps are reversed:
first, the packet is IPsec-processed; then, headers are decompressed;
last, the payload of the packet is decompressed based on the
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 Traditional hop-by-hop HC protocols must be extended to operate
efficiently over IPsec SAs. Compressor and decompressor efficiently over IPsec SAs. Compressor and decompressor
implementation considerations therefore must account for increased implementation considerations therefore must account for increased
tolerance to packet reordering and packet loss between the compressor tolerance to packet reordering and packet loss between the compressor
and decompressor, and minimizing the amount of feedback sent from the and decompressor, and must minimize the amount of feedback sent from
decompressor to the compressor. 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 protocol that compressor and decompressor is a necessity for any HC protocol that
is 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 protocol that performs poorly o IPHC has been identified as a HC protocol that performs poorly
over long round trip time (RTT), high BER links [ROHC]. over long round trip time (RTT), high BER links [ROHC].
Extensions to IPHC to compress TCP/IP headers over an IPsec SA Extensions to IPHC to compress TCP/IP headers over an IPsec SA
should take into consideration longer RTTs, increased potential should take into consideration longer RTTs, increased potential
skipping to change at page 9, line 39 skipping to change at page 9, line 46
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 protocols 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 protocol dependencies negotiate HC channel parameters. To remove HC protocol dependencies
on 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
protocol operation. HCoIPsec 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. The extensions required for
initialization, the SA establishment protocol will be extended to IKEv2 to support HC parameter negotiation are detailed in [IKE-HC].
negotiate the HC protocol's channel parameters. The specifics for
this proposal are detailed in [IKE-HC].
If the HC protocol requires bi-directional communications, two SAs If the HC 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 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. Note that this requirement for the decompressor to the compressor. Note that the requirement for
two SAs aligns with the operation of IKE, which is capable of two SAs aligns with the operation of IKE, which creates SAs in pairs.
creating SA pairs. However, IPsec implementations will dictate how However, IPsec implementations will dictate how decompressor feedback
decompressor feedback received on one SA is associated with a received on one SA is associated with a compressor on the other SA.
compressor on the other SA.
6.1.3. Encapsulation and Identification of Header Compressed Packets 6.1.3. Encapsulation and Identification of Header Compressed Packets
As indicated in section 6.1, new state information (i.e., a new 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 The Next Header field of the IPsec security protocol (e.g., AH or
(e.g., AH or ESP) header is used to demultiplex header-compressed ESP) header is used to demultiplex header-compressed traffic from
traffic from uncompressed traffic traversing an HC-enabled SA. This uncompressed traffic traversing an HC-enabled SA. This functionality
functionality is needed in situations where packets traversing an HC- is needed in situations where packets traversing an HC-enabled SA do
enabled SA are not compressed by the compressor. Such situations may not contain compressed headers. Such situations may occur when, for
occur when, for example, a compressor supports strictly n compressed example, a compressor supports strictly n compressed flows and can
flows and can not compress the n+1 flow that arrives. Another not compress the n+1 flow that arrives. Another example is when
example is when traffic (e.g., TCP/IP) is selected (by IPsec) to an traffic (e.g., TCP/IP) is selected (by IPsec) to an HC-enabled SA,
HC-enabled SA, but cannot be compressed by the HC process (e.g., but cannot be compressed by the HC process (e.g., because the
because the compressor does not support TCP/IP compression). In compressor does not support TCP/IP compression). In these
these situations, the compressor must indicate that the packet situations, the compressor must indicate that the packet contains
contains uncompressed headers. Similarly, the decompressor must be uncompressed headers. Similarly, the decompressor must be able to
able to identify packets with uncompressed headers and not attempt to identify packets with uncompressed headers and not attempt to
decompress them. As such, the Next Header field is used to decompress them. The Next Header field is used to demultiplex these
demultiplex these header-compressed versus uncompressed packets, as a header-compressed versus uncompressed packets, as a "compressed
"compressed header" value will indicate the packet contains header" value will indicate the packet contains compressed headers.
compressed headers. Therefore, an official IANA allocation from the ProtocolID registry
Note: As indicated in the description of HCoIPsec inbound and is required. The request for a ProtocolID allocation, in addition to
outbound processing, the Next Header field is used to identify IPsec extensions to support HCoIPsec, are specified in [IPSEC-HC].
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
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 protocols which enable their o IKEv2 Extensions to Support HCoIPsec
operation at IPsec SA enpoints o IPsec Extensions to Support HCoIPsec
o Extensions to IKEv2 to Support Header Compression over IPsec
(HCoIPsec)
o Allocation of one value for "compressed headers" from the IANA
"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 12, line 28 skipping to change at page 12, line 17
with High Delay, Packet Loss, and Reordering", RFC 3545, with High Delay, Packet Loss, and Reordering", 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 [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
Compression Algorithm ECRTP", November 2004. Compression Protocol (IPComp)", RFC 3173, September 2001.
[ROHCTCP] Pelletier, et al., "Robust Header Compression: A Profile [ROHCTCP] Pelletier, et al., "Robust Header Compression: A Profile
For TCP/IP (ROHC-TCP)", work in progress , January 2006. For TCP/IP (ROHC-TCP)", work in progress , February 2007.
[ROHCWEXT] [IKE-HC] Pezeshki, et al., "IKEv2 Extensions to Support HCoIPsec",
Pelletier, et al., "ROHC over Channels That Can Reorder work in progress , February 2007.
Packets", RFC 4224, January 2006.
[IKE-HC] Jasani, et al., "Extensions to IKEv2 to Support HCoIPsec", [IPSEC-HC]
work in progress , September 2006. Ertekin, et al., "IPsec Extensions to Support HCoIPsec",
work in progress , February 2007.
10.2. Informative References 10.2. Informative References
[ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, [PROTOCOL]
December 2005. IANA, ""Assigned Internet Protocol Numbers", IANA registry
at: http://www.iana.org/assignments/protocol-numbers".
[HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
Compression over MPLS", April 2005. RFC 4303, December 2005.
[AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, [CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro,
"Evaluation of CRTP Performance over Cellular Radio "Evaluation of CRTP Performance over Cellular Radio
Networks", IEEE Personal Communication Magazine , Volume Networks", IEEE Personal Communication Magazine , Volume
7, number 4, pp. 20-25, August 2000. 7, number 4, pp. 20-25, August 2000.
[ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header
Compression Algorithm ECRTP", November 2004.
[ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS", [ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS",
RFC 4247, November 2005. RFC 4247, November 2005.
[ROHCWEXT]
Pelletier, et al., "ROHC over Channels That Can Reorder
Packets", RFC 4224, January 2006.
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: ertekin_emre@bah.com Email: ertekin_emre@bah.com
skipping to change at page 14, line 7 skipping to change at page 14, line 7
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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 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
 End of changes. 47 change blocks. 
136 lines changed or deleted 142 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/