draft-ietf-rohc-hcoipsec-00.txt   draft-ietf-rohc-hcoipsec-01.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Expires: May 6, 2006 R. Jasani Expires: August 28, 2006 R. Jasani
Booz Allen Hamilton Booz Allen Hamilton
November 2, 2005 February 24, 2006
Integration of Header Compression over IPsec Security Associations Integration of Header Compression over IPsec Security Associations
draft-ietf-rohc-hcoipsec-00 draft-ietf-rohc-hcoipsec-01
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 May 6, 2006. This Internet-Draft will expire on August 28, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
Internet Protocol security mechanisms, such as IP Security (IPsec) Internet Protocol security mechanisms, such as IP Security (IPsec)
[IPSEC], provides various security services for IP traffic. However, [IPSEC], provides various security services for IP traffic. However,
the benefits offered by IPsec come at the cost of increased overhead. the benefits offered by IPsec come at the cost of increased overhead.
This document identifies a methodology for integrating header This document identifies a set of work items that need to be
compression (HC) over IPsec (HCoIPsec). HCoIPsec proposes to reduce completed to achieve the integration of header compression (HC) over
the amount of packet overhead associated with the transmission of IPsec (HCoIPsec). HCoIPsec proposes to reduce the amount of packet
traffic over tunnel mode security associations. overhead associated with the transmission of traffic over tunnel mode
security associations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement: Packet Overhead Associated with IPsec 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . . . . . . 3 4. Problem Statement: Packet Overhead Associated with IPsec
4. The Header Compression Solution . . . . . . . . . . . . . . . 4 Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . . . . . . 4
5. Integration Methodology . . . . . . . . . . . . . . . . . . . 5 5. The Header Compression Solution . . . . . . . . . . . . . . . 5
5.1 Work Assumptions . . . . . . . . . . . . . . . . . . . . . 6 6. Integration Methodology . . . . . . . . . . . . . . . . . . . 6
5.2 Work Items . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Work Assumptions . . . . . . . . . . . . . . . . . . . . . 6
5.2.1 Header Compression Scheme-Specific Extensions . . . . 7 6.2. Work Items . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.2 Initialization and Negotiation of Header 6.2.1. Header Compression Scheme-Specific Extensions . . . . 8
Compression Channel . . . . . . . . . . . . . . . . . 7 6.2.2. Initialization and Negotiation of Header
5.2.3 Encapsulation and Identification of Header Compression Channel . . . . . . . . . . . . . . . . . 8
Compressed Packets . . . . . . . . . . . . . . . . . . 8 6.2.3. Encapsulation and Identification of Header
6. Candidate Compression Schemes . . . . . . . . . . . . . . . . 8 Compressed Packets . . . . . . . . . . . . . . . . . . 9
7. Example Operation . . . . . . . . . . . . . . . . . . . . . . 9 7. Candidate Compression Schemes . . . . . . . . . . . . . . . . 9
8. Future Work Items . . . . . . . . . . . . . . . . . . . . . . 11 8. Example Operation . . . . . . . . . . . . . . . . . . . . . . 10
8.1 HCoIPsec Transport Mode SAs . . . . . . . . . . . . . . . 11 9. Future Work Items . . . . . . . . . . . . . . . . . . . . . . 12
8.2 Multiplexing of Compressed Packets in IPsec Tunnels . . . 12 9.1. HCoIPsec Transport Mode SAs . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1 Normative References . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2 Informative References . . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
This document identifies a methodology for the integration of header This document identifies a set of work items that need to be
compression (HC) over IPsec Security Associations (SAs) operating in completed in order to achieve the integration of header compression
tunnel mode. The goal of integrating HC with IPsec is to reduce the (HC) over IPsec Security Associations (SAs) operating in tunnel mode.
protocol overhead associated with packets traversing between IPsec SA The goal of integrating HC with IPsec is to reduce the protocol
overhead associated with packets traversing between IPsec SA
endpoints. This goal can be achieved by compressing the upper layer endpoints. This goal can be achieved by compressing the upper layer
protocols (e.g., RTP/UDP and TCP) and the inner IP header of packets, protocols (e.g., RTP/UDP and TCP) and the inner IP header of packets,
at the ingress of the IPsec tunnel, and decompression at the egress. at the ingress of the IPsec tunnel, and decompression at the egress.
To accomplish HCoIPsec, this document proposes the use of Internet To accomplish HCoIPsec, this document proposes the use of Internet
Protocol Header Compression [IPHC], Compressed Real Time Protocol Protocol Header Compression [IPHC], Compressed Real Time Protocol
[CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust
Header Compression [ROHC], to compress the inner headers of IP Header Compression [ROHC], to compress the inner headers of IP
packets traversing within an IPsec tunnel. However, since these HC packets traversing within an IPsec tunnel. However, since these HC
schemes operate on a hop-by-hop basis, several extensions need to be schemes operate on a hop-by-hop basis, several extensions need to be
defined. This document details a methodology which will enable these defined. This document details a technique which will enable these
traditional hop-by-hop HC schemes to be extended, and operate between traditional hop-by-hop HC schemes to be extended, and operate between
IPsec SA endpoints. IPsec SA endpoints.
Currently, HCoIPsec primarily targets the application of HC to tunnel Currently, HCoIPsec primarily targets the application of HC to tunnel
mode SAs as opposed to transport mode SAs. Transport mode SAs mode SAs as opposed to transport mode SAs. Transport mode SAs
encrypt/authenticate only the payload of an IP packet, leaving the encrypt/authenticate only the payload of an IP packet, leaving the
original IP header untouched. Intermediate routers subsequently use original IP header untouched. Intermediate routers subsequently use
the original IP header to route the packet to a decryption device. the original IP header to route the packet to a decryption device.
Therefore, if HC were extended to operate between IPsec transport- Therefore, if HC were extended to operate between IPsec transport-
mode SA endpoints, (de)compression functionality can be applied only mode SA endpoints, (de)compression functionality can be applied only
to the transport layer headers and not the IP header. Since to the transport layer headers and not the IP header. Since
compression of transport layer headers alone does not provide compression of transport layer headers alone does not provide
substantial efficiency gains, it is not fully integrated into the substantial efficiency gains, it is not integrated into HCoIPsec.
HCoIPsec methodology.
2. Audience 2. Audience
The target audience includes those who are involved with the design The target audience includes those who are involved with the design
and development of HC schemes, and IPsec mechanisms. Since and development of HC schemes, and IPsec mechanisms. Since
traditional IETF HC schemes are designed to operate on a hop-by-hop traditional IETF HC schemes are designed to operate on a hop-by-hop
basis, they need to be modified to operate over IPsec SAs. basis, they need to be modified to operate over IPsec SAs.
Therefore, the authors target various HC and IPsec communities who Therefore, the authors target various HC and IPsec communities who
may consider extending hop-by-hop HC schemes and IPsec protocols to may consider extending hop-by-hop HC schemes and IPsec protocols to
meet the methodology put forward in this document. Finally, this meet the requirements put forward in this document. Finally, this
document is directed towards vendors developing IPsec devices which document is directed towards vendors developing IPsec devices which
will be deployed in bandwidth-constrained, IP networks. will be deployed in bandwidth-constrained, IP networks.
3. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode 3. Terminology
Terminology specific to discussion of HCoIPsec is introduced in this
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
Traffic that is processed by the compressor (compressed) using one
of the existing profiles. Note: This includes packets that might
be compressed using an "uncompressed" profile.
Uncompressed Traffic
Traffic that is not processed by the compressor. Instead, this
type of traffic is bypassed by the HC process.
HC Process
Generic reference to either the compressor, decompressor, and any
supporting header compression (HC) components.
IPsec Process
Generic reference to Internet Protocol Security (IPsec) process
[IPSEC].
4. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode
SAs SAs
IPsec mechanisms provide various security services for IP-based IPsec mechanisms provide various security services for IP-based
networks. For example, ESP offers data origin authentication, networks. For example, ESP offers data origin authentication,
connectionless integrity, anti-replay service, and limited traffic connectionless integrity, anti-replay service, and limited traffic
flow confidentiality [ESP]. flow confidentiality [ESP].
The benefits of IPsec mechanisms come at the cost of increased per- The benefits of IPsec mechanisms come at the cost of increased per-
packet overhead in the network. For example, traffic flow packet overhead in the network. For example, traffic flow
confidentiality, which is generally implemented at security gateways, confidentiality, which is generally implemented at security gateways,
skipping to change at page 4, line 22 skipping to change at page 5, line 7
IPsec tunnels may mask the source-destination patterns that an IPsec tunnels may mask the source-destination patterns that an
intruder may ascertain, but the benefit comes at the cost of extra intruder may ascertain, but the benefit comes at the cost of extra
per-packet overhead. An ESP tunnel mode SA applied to an IPv6 flow per-packet overhead. An ESP tunnel mode SA applied to an IPv6 flow
results in at least 50 bytes of additional overhead per packet. This results in at least 50 bytes of additional overhead per packet. This
additional overhead may be undesirable for many bandwidth-constrained additional overhead may be undesirable for many bandwidth-constrained
wireless and/or Satellite Communications (SATCOM) networks, as these wireless and/or Satellite Communications (SATCOM) networks, as these
types of infrastructure are not overprovisioned. Consequently, the types of infrastructure are not overprovisioned. Consequently, the
additional overhead incurred in an encryption-based environment may additional overhead incurred in an encryption-based environment may
hinder the efficient utilization of bandwidth. hinder the efficient utilization of bandwidth.
In bandwidth-constrained high bit error rate (BER) networks, end-host In bandwidth-constrained, high bit error rate (BER) networks, IP
Packet Loss Ratio (IPLR) can severely degrade end-host application
performance. The traditional means for combating IPLR on high BER
links has been Error Correction Codes (ECC). In addition, end-host
applications may not have the luxury of sending packets with large applications may not have the luxury of sending packets with large
payloads. This is due to the fact that large packets traversing high payloads. This is due to the fact that large packets traversing high
BER links result in high IP Packet Loss Ratio (IPLR). To reduce BER links result in high IP Packet Loss Ratio (IPLR). To reduce
IPLR, end-host devices may reduce the size of packet payloads, which IPLR, end-host devices may reduce the size of packet payloads, which
decreases the probability that a packet is lost due to a bit error. decreases the probability that a packet is lost due to a bit error.
Reducing the size of packet payloads, however, increases the amount Reducing the size of packet payloads, however, increases the amount
of overhead transmitted between the two end hosts. Moreover, if of overhead transmitted between the two end hosts. Moreover, if
these packets traverse over an IPsec tunnel mode SA, the amount of these packets traverse over an IPsec tunnel mode SA, the amount of
overhead is further magnified. A mechanism is needed to reduce the overhead is further magnified. A mechanism is needed to reduce the
overhead associated with such flows. overhead associated with such flows.
4. The Header Compression Solution 5. The Header Compression Solution
IP HC schemes provide one mechanism to reduce packet overhead in an IP HC schemes provide one mechanism to reduce packet overhead in an
IP network. Schemes such as IPHC, CRTP, ECRTP and ROHC exploit IP network. Schemes such as IPHC, CRTP, ECRTP and ROHC exploit
inter-packet redundancies of network and transport-layer header inter-packet redundancies of network and transport-layer header
fields of a flow to reduce the amount of redundant header data fields of a flow to reduce the amount of redundant header data
transmitted between two nodes. transmitted between two nodes.
To apply HC schemes over IPsec SAs, several extensions to the To apply HC schemes over IPsec SAs, several extensions to the
existing schemes need to be developed. Existing HC schemes such as existing schemes need to be developed. Existing HC schemes such as
IPHC, CRTP, ECRTP and ROHC are designed to compress headers on a hop- IPHC, CRTP, ECRTP and ROHC are designed to compress headers on a hop-
skipping to change at page 5, line 46 skipping to change at page 6, line 35
the scope of this document. the scope of this document.
If IPsec NULL encryption is applied on packets, HC schemes may still If IPsec NULL encryption is applied on packets, HC schemes may still
be applied on the inner headers at the IPsec SA endpoints. Inbound be applied on the inner headers at the IPsec SA endpoints. Inbound
and outbound packets are processed as described previously. In and outbound packets are processed as described previously. In
scenarios where NULL-encrypted packets traverse intermediate nodes scenarios where NULL-encrypted packets traverse intermediate nodes
between the IPsec SA endpoints, the intermediary nodes must not between the IPsec SA endpoints, the intermediary nodes must not
attempt to (de)compress the inner IP and/or transport layer headers attempt to (de)compress the inner IP and/or transport layer headers
on a hop-by-hop basis. on a hop-by-hop basis.
5. Integration Methodology 6. Integration Methodology
The goal for HCoIPsec is to provide more efficient transport of IP The goal for HCoIPsec is to provide more efficient transport of IP
packets between source and destination IPsec devices without packets between source and destination IPsec devices, via tunnel mode
compromising security services offered by IPsec. SAs, without compromising security services offered by IPsec.
With this general goal in mind, Section 5.1 defines a set of work With this general goal in mind, Section 5.1 defines a set of work
assumptions to guide the direction of the HCoIPsec solution. Based assumptions to guide the direction of the HCoIPsec solution. Based
on these work assumptions, Section 5.2 defines work items which need on these work assumptions, Section 5.2 defines work items which need
to be addressed to achieve the HCoIPsec solution. to be addressed to achieve the HCoIPsec solution.
5.1 Work Assumptions 6.1. Work Assumptions
a. HCoIPsec must use existing HC protocols (e.g., IPHC, CRTP, ECRTP, a. HCoIPsec must use existing HC protocols (e.g., IPHC, CRTP, ECRTP,
ROHC) to reduce the amount of overhead associated with packets ROHC) to reduce the amount of overhead associated with packets
traversing an IPsec tunnel-mode SA. traversing an IPsec tunnel-mode SA.
b. HCoIPsec must execute (de)compression operations at IPsec SA b. HCoIPsec must execute (de)compression operations at IPsec SA
endpoints, and must not perform (de)compression cycles at endpoints, and must not perform (de)compression cycles at
intermediate nodes between IPsec devices. intermediate nodes between IPsec devices.
c. HCoIPsec must be independent of the underlying link layer framing c. HCoIPsec must be independent of the underlying link layer framing
protocol (e.g., PPP). protocol (e.g., PPP).
d. HCoIPsec must allow each SA to constitute a HC channel, enabling d. HCoIPsec must allow each SA to constitute a HC channel, enabling
each SA to have its own CID space. each SA to have its own CID space.
e. An SA with HC enabled should not deliver a larger number of e. An SA with HC enabled should not deliver a larger number of
erroneous packets than the same SA with HC disabled. erroneous packets than the same SA with HC disabled.
skipping to change at page 6, line 32 skipping to change at page 7, line 22
e. An SA with HC enabled should not deliver a larger number of e. An SA with HC enabled should not deliver a larger number of
erroneous packets than the same SA with HC disabled. erroneous packets than the same SA with HC disabled.
The motivation behind (c) comes from the realization that an SA may The motivation behind (c) comes from the realization that an SA may
traverse multiple links, employing various framing protocols, and traverse multiple links, employing various framing protocols, and
that the set of links (and thus framing protocols) may change during that the set of links (and thus framing protocols) may change during
the lifetime of an SA. Therefore, link layer dependencies exhibited the lifetime of an SA. Therefore, link layer dependencies exhibited
by traditional hop-by-hop HC schemes cannot be used in the HCoIPsec by traditional hop-by-hop HC schemes cannot be used in the HCoIPsec
solution. solution.
5.2 Work Items 6.2. Work Items
This section identifies several work items that need to be addressed This section identifies several work items that need to be addressed
to achieve HCoIPsec. The first work item encompasses the HC scheme- to achieve HCoIPsec. The first work item encompasses the HC scheme-
specific extensions needed to ensure that traditional hop-by-hop HC specific extensions needed to ensure that traditional hop-by-hop HC
schemes will operate efficiently over IPsec SA endpoints: schemes will operate efficiently over IPsec SA endpoints:
a. Header Compression Scheme-Specific Extensions: Any modifications a. Header Compression Scheme-Specific Extensions: Any modifications
needed to be made to existing HC schemes, which will facilitate needed to be made to existing HC schemes, which will facilitate
their operation over IPsec SAs. (Section 5.2.1) their operation over IPsec SAs. (Section 5.2.1)
skipping to change at page 7, line 13 skipping to change at page 7, line 47
additional work items are proposed: additional work items are proposed:
b. Initialization and Negotiation of the Header Compression Channel: b. Initialization and Negotiation of the Header Compression Channel:
Mechanisms needed to initialize a HC channel and negotiate HC Mechanisms needed to initialize a HC channel and negotiate HC
scheme parameters prior to operation. (Section 5.2.2) scheme parameters prior to operation. (Section 5.2.2)
c. Encapsulation and Identification of Header Compressed Packets: c. Encapsulation and Identification of Header Compressed Packets:
Mechanisms that encapsulate and identify compressed header Mechanisms that encapsulate and identify compressed header
packets, as well as how these mechanisms will operate. (Section packets, as well as how these mechanisms will operate. (Section
5.2.3) 5.2.3)
5.2.1 Header Compression Scheme-Specific Extensions Note: (c) is still being discussed within the community and is
subject to change. More information about (c) can be found in the
"Alternatives to Achieving HCoIPsec" internet-draft, a document being
used to help resolve HCoIPsec discussions and issues in order to
stabilize the HCoIPsec draft.
6.2.1. Header Compression Scheme-Specific Extensions
a. HCoIPsec should minimize HC scheme performance degradation due to a. HCoIPsec should minimize HC scheme performance degradation due to
increased delays, packet loss, jitter, and reordering events increased delays, packet loss, jitter, and reordering events
between compressor and decompressor. between compressor and decompressor.
b. HCoIPsec should minimize the amount of HC signaling between b. HCoIPsec should minimize the amount of HC signaling between
compressor and decompressor. compressor and decompressor.
c. HCoIPsec should support bi-directional communications
functionality, used by certain HC schemes (e.g. ROHC bi-
directional mode).
The intention of (b) is to indicate that if a feedback channel from The intention of (b) is to indicate that if a feedback channel from
the decompressor to the compressor is not used sparingly, then the the decompressor to the compressor is not used sparingly, then the
overall gains from HCoIPsec can be significantly reduced (even more overall gains from HCoIPsec can be significantly reduced (even more
so than hop-by-hop HC). For example, take the case where ROHC in bi- so than hop-by-hop HC). For example, take the case where ROHC in bi-
directional reliable mode is instantiated over an IPsec tunnel mode directional reliable mode is instantiated over an IPsec tunnel mode
SA. Any feedback sent from the decompressor to the compressor may be SA. Any feedback sent from the decompressor to the compressor may be
tunneled, and therefore, the additional overhead incurred by tunneled, and therefore, the additional overhead incurred by
tunneling the feedback will reduce the overall benefits of HC. tunneling the feedback will reduce the overall benefits of HC.
skipping to change at page 7, line 48 skipping to change at page 8, line 43
To identify the stale context, the feedback packet must contain the To identify the stale context, the feedback packet must contain the
context ID as well as an indication of the SA that the decompressor context ID as well as an indication of the SA that the decompressor
is associated to. This poses a problem for current HC algorithm is associated to. This poses a problem for current HC algorithm
feedback packets, which are not structured to carry the additional SA feedback packets, which are not structured to carry the additional SA
indication information. For example, current ECRTP feedback indication information. For example, current ECRTP feedback
mechanisms (e.g., CONTEXT_STATE) only list the CIDs for which mechanisms (e.g., CONTEXT_STATE) only list the CIDs for which
synchronization has been lost. If a bidirectional HC algorithm is to synchronization has been lost. If a bidirectional HC algorithm is to
be integrated with IPsec, additional HC scheme-specific extensions be integrated with IPsec, additional HC scheme-specific extensions
must be defined to resolve this issue. must be defined to resolve this issue.
5.2.2 Initialization and Negotiation of Header Compression Channel 6.2.2. Initialization and Negotiation of Header Compression Channel
Initialization of the HC channel parameters may achieved manually Initialization of the HC channel will be achieved manually (i.e.,
(i.e., administratively configured for manual SAs), or may be administratively configured for manual SAs), or will be performed by
performed by IPsec SA establishment protocols, e.g. IKE. During SA IPsec SA establishment protocols, e.g. IKE. During SA
initialization, the IPsec SA establishment protocols will identify initialization, the type of HC scheme configured for the SA, as well
the type of HC scheme configured for the SA, as well as the HC as the HC scheme's channel parameters will be identified.
scheme's channel parameters.
a. HCoIPsec may leverage IKE, IKEv2 to negotiate HC channel a. HCoIPsec may leverage IKE, IKEv2 to negotiate HC channel
parameters (e.g., for ROHC, IKE(v2) shall initialize PROFILES, parameters (e.g., for ROHC, IKE(v2) shall initialize PROFILES,
MAX_CID, MAX_HEADER, MRRU). MAX_CID, MAX_HEADER, MRRU).
b. HCoIPsec must allow packets with uncompressed headers and packets b. HCoIPsec must allow packets with uncompressed headers and packets
with compressed headers to traverse a single SA. "Packets with with compressed headers to traverse a single SA. "Packets with
compressed headers" refer to packets which are selected to an HC- compressed headers" refer to packets which are selected to an HC-
enabled SA, are passed to the compressor, and are actually enabled SA, are passed to the compressor, and are actually
compressed; "packets with uncompressed headers" refer to packets compressed; "packets with uncompressed headers" refer to packets
which are selected to an HC-enabled SA, are passed to the which are selected to an HC-enabled SA, are passed to the
compressor, and are not "compressed" (e.g., ROHC compressor compressor, and are not "compressed" (e.g., ROHC compressor
processes a packet with the uncompressed profile). processes a packet with the uncompressed profile).
(b) is necessary in situations where a compressor--for one reason or Note: (b) is necessary in situations where a compressor--can not
another--cannot compress a flow (e.g., a compressor supports strictly compress a flow (e.g., a compressor supports strictly n compressed
n compressed flows, and cannot compress the n+1 flow that arrives). flows, and can not compress the n+1 flow that arrives).
5.2.3 Encapsulation and Identification of Header Compressed Packets Note: (b) is still being discussed within the community and is
subject to change. More information about (b) can be found in the
"Alternatives to Achieving HCoIPsec" internet-draft, a document being
used to help resolve HCoIPsec discussions and issues in order to
stabilize the HCoIPsec draft.
6.2.3. Encapsulation and Identification of Header Compressed Packets
For indication purposes, a one-byte header may be added to the For indication purposes, a one-byte header may be added to the
compressed packet; this field will help the decompressor identify how compressed packet; this field will help the decompressor identify how
to process the compressed packet. This one-byte header is only to process the compressed packet. This one-byte header is only
relevant to the HC compression and decompression processes, and is relevant to the HC compression and decompression processes, and is
not used by IPsec.. not used by IPsec..
a. HCoIPsec may introduce a new one-byte header to indicate the type a. HCoIPsec must indicate the type of compressed packet (e.g., for
of compressed packet (e.g., for ECRTP, COMPRESSED_RTP_8, ECRTP, COMPRESSED_RTP_8, COMPRESSED_RTP_16, CONTEXT_STATE, etc.)
COMPRESSED_RTP_16, CONTEXT_STATE, etc.) on a per packet basis.
Note that ROHC indicates its own packet type within the protocol, and Note that ROHC indicates its own packet type within the protocol, and
does not require a new one-byte header to indicate the type of does not require a new one-byte header to indicate the type of
compressed packet. compressed packet.
6. Candidate Compression Schemes Note: Alternatives to using a "one-byte header" are still being
discussed within the community, thus this section may change. More
information can be found in the "Alternatives to Achieving HCoIPsec"
internet-draft, a document being used to help resolve HCoIPsec
discussions and issues in order to stabilize the HCoIPsec draft.
7. Candidate Compression Schemes
IPHC can be used to compress TCP/IP headers for tunnel mode SAs. IPHC can be used to compress TCP/IP headers for tunnel mode SAs.
IPHC, however, has been identified as a HC scheme that performs IPHC, however, has been identified as a HC scheme that performs
poorly over long round trip time (RTT), high BER links [ROHC]. poorly over long round trip time (RTT), high BER links [ROHC].
Extensions to IPHC to compress TCP/IP headers over an IPsec SA need Extensions to IPHC to compress TCP/IP headers over an IPsec SA need
to take into consideration longer RTTs, increased potential for to take into consideration longer RTTs, increased potential for
packet reordering and IPLR between the compressor and decompressor. packet reordering and IPLR between the compressor and decompressor.
CRTP can be used to compress RTP/UDP/IP headers for tunnel mode SAs. CRTP can be used to compress RTP/UDP/IP headers for tunnel mode SAs.
CRTP, however, has also been identified as a HC scheme that performs CRTP, however, has also been identified as a HC scheme that performs
poorly over long RTT, high BER links [CRTPE]. Recent modifications poorly over long RTT, high BER links [CRTPE]. Recent modifications
to the CRTP scheme, such as ECRTP, enables the CRTP HC scheme to to the CRTP scheme, such as ECRTP, enables the CRTP HC scheme to
skipping to change at page 9, line 27 skipping to change at page 10, line 37
compressor and decompressor[ROHCE]. Recent work [ROHCWEXT] suggests compressor and decompressor[ROHCE]. Recent work [ROHCWEXT] suggests
that the implementation aspects of ROHC can be modified to achieve that the implementation aspects of ROHC can be modified to achieve
tolerance to packet reordering events. Such implementation aspects tolerance to packet reordering events. Such implementation aspects
should be taken into consideration when extending ROHC to operate should be taken into consideration when extending ROHC to operate
between IPsec SA endpoints. between IPsec SA endpoints.
The ability to tolerate these network characteristics is a necessity The ability to tolerate these network characteristics is a necessity
for any HCoIPsec scheme, and will be a factor in determining how for any HCoIPsec scheme, and will be a factor in determining how
efficiently the HC scheme operates over the IPsec tunnel-mode SAs. efficiently the HC scheme operates over the IPsec tunnel-mode SAs.
7. Example Operation 8. Example Operation
The basic operation of the HCoIPsec protocol is detailed in the The basic operation of the HCoIPsec protocol is detailed in the
following example. Assume there are two IPsec devices operating as following example. Assume there are two IPsec devices operating as
security gateways. HCoIPsec leverages an SA establishment protocol security gateways. HCoIPsec leverages an SA establishment protocol
(e.g., IKE, IKEv2) to negotiate the HC scheme, and channel (e.g., IKE, IKEv2) to negotiate the HC scheme, and channel
parameters. For example, the MAX_CID, MRRU, MAX_HEADER, and PROFILES parameters. For example, the MAX_CID, MRRU, MAX_HEADER, and PROFILES
parameters will be negotiated for each IPsec SA which is capable of parameters will be negotiated for each IPsec SA which is capable of
ROHC. For an IPsec SA that is ECRTP-enabled, channel parameters ROHC. For an IPsec SA that is ECRTP-enabled, channel parameters
including F_MAX_PERIOD, F_MAX_TIME, and the ECRTP Compression including F_MAX_PERIOD, F_MAX_TIME, and the ECRTP Compression
Suboption will be initialized. For the following example, assume Suboption will be initialized. For the following example, assume
that a HC-enabled SA has been established. that a SA has been established.
Outbound packet processing is as follows. The packet is initially Outbound packet processing is as follows. The packet is initially
processed as described in Steps 1-2, Section 5.1 of RFC 2401bis. The processed as described in Steps 1-2, Section 5.1 of RFC 4301. The
SPD cache entry then maps the packet to a given SAD entry, which SPD cache entry then maps the packet to a given SAD entry, which
indicates the HC protocol enabled on the SA (in addition to mode, indicates the HC protocol enabled on the SA (in addition to mode,
cryptographic algorithms, keys, etc.). If the SAD entry indicates cryptographic algorithms, keys, etc.). If the SAD entry indicates
that compression is disabled, then standard IPsec processing ensues, that compression is disabled, then standard IPsec processing ensues,
as described in Steps 3-4, Section 5.1 of RFC 2401bis. If the SAD as described in Steps 3-4, Section 5.1 of RFC 4301. If the SAD entry
entry indicates that compression is enabled, the packet must be indicates that compression is enabled, the packet must be handed to
handed to the appropriate compressor, which executes the compression the appropriate compressor, which executes the compression process.
process. After the packet's header is compressed, the packet resumes After the packet's header is compressed, the packet resumes IPsec
IPsec processing as described in Step 3a, where standard IPsec ESP processing as described in Step 3a, where standard IPsec ESP
processing ensues (including packet encryption according to the SAD processing ensues (including packet encryption according to the SAD
entry parameters, packet encapsulation with the outer ESP/IP header) entry parameters, packet encapsulation with the outer ESP/IP header)
and is subsequently passed to the outbound forwarding function, as and is subsequently passed to the outbound forwarding function, as
described in Step 4 of RFC 2401bis. described in Step 4 of RFC 4301.
Inbound packet processing is as follows. The packet is initially Inbound packet processing is as follows. The packet is initially
processed as described in Steps 1-3, Section 5.2 of RFC 2401bis; processed as described in Steps 1-3, Section 5.2 of RFC 4301;
subsequently (using the SAD entry selected in Step 3a), ESP subsequently (using the SAD entry selected in Step 3a), ESP
processing is applied. Based on information retrieved from the SAD processing is applied. Based on information retrieved from the SAD
entry, it can also be determined whether traffic traversing the SA is entry, it can also be determined whether traffic traversing the SA is
compressed or not compressed. If the SAD entry indicates that compressed or not compressed. If the SAD entry indicates that
compression is not enabled on the SA, then standard IPsec processing compression is not enabled on the SA, then standard IPsec processing
of the packet ensues, as described in Step 4, Section 5.2 of RFC of the packet ensues, as described in Step 4, Section 5.2 of RFC
2401bis. If compression is enabled on the SA, the packet is handed 4301. If compression is enabled on the SA, the packet is handed to
to the decompressor for "decompression". Once the packet is the decompressor for "decompression". Once the packet is
decompressed, the processing as described in Step 4, Section 5.2 of decompressed, the processing as described in Step 4, Section 5.2 of
2401bis resumes (specifically "Then match the packet against the RFC 4301 resumes (specifically "Then match the packet against the
inbound selectors identified by the SAD..."). inbound selectors identified by the SAD...").
Figure 1 depicts the basic function of HCoIPsec: Figure 1 depicts the basic function of HCoIPsec:
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|ESP Tunnel Mode Security Association| |ESP Tunnel Mode Security Association|
| | | |
| | | |
V V V V
+--------------+ +--------------+ +--------------+ +--------------+
skipping to change at page 11, line 43 skipping to change at page 12, line 43
Figure 1: Example operation of HCoIPsec. Figure 1: Example operation of HCoIPsec.
In the example scenario, note that the inbound and outbound packets In the example scenario, note that the inbound and outbound packets
are first mapped to an SA, and then subsequently mapped to a CID. are first mapped to an SA, and then subsequently mapped to a CID.
This implies that the scope of each CID is contained within each SA. This implies that the scope of each CID is contained within each SA.
A CID value of 1 can be associated with multiple SAs; however, the A CID value of 1 can be associated with multiple SAs; however, the
context state information for CID 1 cannot be shared over multiple context state information for CID 1 cannot be shared over multiple
SAs. SAs.
8. Future Work Items 9. Future Work Items
8.1 HCoIPsec Transport Mode SAs 9.1. HCoIPsec Transport Mode SAs
Many of the current HC profiles look to simultaneously compress Many of the current HC profiles look to simultaneously compress
network and transport layer headers of IP packets. This makes the network and transport layer headers of IP packets. This makes the
extension of traditional HC schemes over transport-mode SAs more extension of traditional HC schemes over transport-mode SAs more
difficult. For the application of HC over transport mode SAs, difficult. For the application of HC over transport mode SAs,
traditional HC schemes may need to be extended to operate strictly on traditional HC schemes may need to be extended to operate strictly on
layer 4 (e.g., TCP, and/or RTP/UDP) headers. The methodology and layer 4 (e.g., TCP, and/or RTP/UDP) headers. The specification for
specification for HCoIPsec transport mode SAs is left for further HCoIPsec transport mode SAs is left for further study.
study.
8.2 Multiplexing of Compressed Packets in IPsec Tunnels
It should also be noted that a packet concatenation (or multiplexing)
scheme may be added in conjunction to HCoIPsec to further reduce the
overall overhead of packets traversing between IPsec devices. This
type of functionality is similar to AAL2 voice trunking, where voice
packets from different sources are placed into one cell [AAL2]. As
described in [AAL2], a multiplexer concatenates cells until one of
following two events occur:
o the first event indicates that the maximum size of multiplexed
cell is reached;
o the second event indicates that a timer has expired: this timer
provides an upper bound on the amount of delay a cell may exhibit.
When either of these events are triggered, the multiplexer transmits
the multiplexed cells.
[TCRTP] is one proposal to reduce the packet overhead used between
call gateways in an unencrypted network. In a similar fashion, if
multiple compressed flows are mapped to one SA between two IPsec
devices, then compressed packets MAY be concatenated with one
another, encrypted, and subsequently tunneled to the destination
IPsec device with one ESP/IP header. It should be noted, however,
that a multiplexing functionality may be undesirable for the high BER
networks, as multiplexing scheme may increase average packet sizes,
which may result in a greater IPLR. The specification of such a
protocol is left for further study.
9. Security Considerations 10. 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; used during outbound processing) has
the decompressor (i.e., the decompressor located at the egress of the the ability to send packets to the decompressor (i.e., the
IPsec tunnel) that do not match the original ones emitted from the decompressor located at the egress of the IPsec tunnel; used during
end-hosts. In such a scenario, the invalid packets will pass the inbound processing) that do not match the original packets emitted
inbound IPsec process, and will subsequently be validly decompressed. from the end-hosts. In such a scenario, the invalid packets will
pass through inbound IPsec processing, and will subsequently be
validly decompressed.
Furthermore, an intruder who has the ability to arbitrarily inject Furthermore, an intruder who has the ability to arbitrarily inject
packets between SA endpoints, and addresses these malicious packets packets between SA endpoints, and addresses these malicious packets
to the encryption/decryption devices, has the ability to cause to the encryption/decryption devices, has the ability to cause
context corruption between the compressor and decompressor processes context corruption between the compressor and decompressor processes
instantiated within the IPsec device (if the malicious packet passes instantiated within the IPsec device (if the malicious packet passes
through the decryption process). Such a scenario will result in a through the decryption process). Such a scenario will result in a
decreased efficiency between compressor and decompressor, and decreased efficiency between compressor and decompressor, and
furthermore, may result in Denial of Service, as the decompression of furthermore, may result in Denial of Service, as the decompression of
a significant number of invalid packets may drain the resources of an a significant number of invalid packets may drain the resources of an
IPsec device. IPsec device.
Note: It should be noted, however, that these security issues are Note: It should be noted, however, that these security issues are
a direct offset of IPsec vulnerabilities. a direct result of IPsec vulnerabilities.
10. IANA Considerations 11. IANA Considerations
None. None.
11. Acknowledgments 12. 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,
of the Department of Defense, and Mr. A. Rich Espy of OPnet for their of the Department of Defense, and Mr. A. Rich Espy of OPnet for their
contributions and support for developing this document. The authors contributions and support for developing this document. The authors
would also like to thank Mr. Jan Vilhuber, Mr. Dan Wing, of Cisco would also like to thank Mr. Jan Vilhuber, Mr. Dan Wing, of Cisco
Systems, Mr. Lars-Erik Jonsson and Mr. Kristopher Sandlund of Systems, Mr. Lars-Erik Jonsson and Mr. Kristopher Sandlund of
Ericsson for their valuable contributions to this document. The Ericsson for their valuable contributions to this document. The
authors would also like to thank Ms. Renee Esposito, Mr. Etzel authors would also like to thank Ms. Renee Esposito, Mr. Etzel
Brower, Mr. Jigar Amroliwala, and Mr. Dwayne Corbin of Booz Allen Brower, Mr. Jigar Amroliwala, and Mr. Dwayne Corbin of Booz Allen
Hamilton for their assistance in completing this work. Hamilton for their assistance in completing this work.
12. References 13. References
12.1 Normative References 13.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", work in progress , March 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, T. and et. al., "Compressing IP/UDP/RTP Headers on
Links with High Delay, Packet Loss, and Reordering", Links with High Delay, Packet Loss, and Reordering",
skipping to change at page 14, line 7 skipping to change at page 14, line 35
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, G. and et. al, "Robust Header Compression: A
Profile For TCP/IP (ROHC-TCP)", work in progress , Profile For TCP/IP (ROHC-TCP)", work in progress ,
February 2005. January 2006.
[ROHCWEXT] [ROHCWEXT]
Pelletier, G. and et. al, "ROHC over Channels That Can Pelletier, G. and et. al, "ROHC over Channels That Can
Reorder Packets", work in progress , February 2005. Reorder Packets", RFC 4224, January 2006.
12.2 Informative References 13.2. Informative References
[ESP] Kent, S., "IP Encapsulating Security Payload", work in [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303,
progress , March 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,
"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.
[ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS", [ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS",
work in progress , December 2004. RFC 4247, November 2005.
[AAL2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 [AAL2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2
AAL", I.363.2 , September 1997. AAL", I.363.2 , September 1997.
[TCRTP] Thompson, B., "Tunneling of Multiplexed Compressed RTP",
work in progress , September 2004.
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
8283 Greensboro Drive 13200 Woodland Park Dr.
McLean, VA 22102 Herndon, VA 20171
US US
Email: ertekin_emre@bah.com Email: ertekin_emre@bah.com
Chris Christou Chris Christou
Booz Allen Hamilton Booz Allen Hamilton
8283 Greensboro Drive 13200 Woodland Park Dr.
McLean, VA 22102 Herndon, VA 20171
US US
Email: christou_chris@bah.com Email: christou_chris@bah.com
Rohan Jasani Rohan Jasani
Booz Allen Hamilton Booz Allen Hamilton
8283 Greensboro Drive 13200 Woodland Park Dr.
McLean, VA 22102 Herndon, VA 20171
US US
Email: jasani_rohan@bah.com Email: jasani_rohan@bah.com
Intellectual Property Statement Intellectual Property Statement
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
skipping to change at page 16, line 41 skipping to change at page 17, line 41
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 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.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. 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 currently provided by the
Internet Society. Internet Society.
 End of changes. 58 change blocks. 
138 lines changed or deleted 165 lines changed or added

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