draft-ietf-rohc-hcoipsec-01.txt   draft-ietf-rohc-hcoipsec-02.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Expires: August 28, 2006 R. Jasani Expires: December 28, 2006 R. Jasani
Booz Allen Hamilton Booz Allen Hamilton
February 24, 2006 June 26, 2006
Integration of Header Compression over IPsec Security Associations Integration of Header Compression over IPsec Security Associations
draft-ietf-rohc-hcoipsec-01 draft-ietf-rohc-hcoipsec-02
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 August 28, 2006. This Internet-Draft will expire on December 28, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Internet Protocol security mechanisms, such as IP Security (IPsec) Internet Protocol security mechanisms, such as IP Security (IPsec)
[IPSEC], provides various security services for IP traffic. However, [IPSEC], provide various security services for IP traffic. However,
the benefits offered by IPsec come at the cost of increased overhead. the benefits of IPsec come at the cost of increased overhead. This
This document identifies a set of work items that need to be document defines a framework for integrating Header Compression (HC)
completed to achieve the integration of header compression (HC) over over IPsec (HCoIPsec). By compressing the inner headers of IP
IPsec (HCoIPsec). HCoIPsec proposes to reduce the amount of packet packets, HCoIPsec proposes to reduce the amount of overhead
overhead associated with the transmission of traffic over tunnel mode associated with the transmission of traffic over IPsec security
security associations. associations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement: Packet Overhead Associated with IPsec 4. Problem Statement: Packet Overhead Associated with
Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . . . . . . 4 IPsec Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . 4
5. The Header Compression Solution . . . . . . . . . . . . . . . 5 5. Overview of the HCoIPsec Framework . . . . . . . . . . . . 5
6. Integration Methodology . . . . . . . . . . . . . . . . . . . 6 5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5
6.1. Work Assumptions . . . . . . . . . . . . . . . . . . . . . 6 5.2. HCoIPsec Description . . . . . . . . . . . . . . . . . . . 5
6.2. Work Items . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6
6.2.1. Header Compression Scheme-Specific Extensions . . . . 8 6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 6
6.2.2. Initialization and Negotiation of Header 6.1.1. Header Compression Scheme Considerations . . . . . . . . . 8
Compression Channel . . . . . . . . . . . . . . . . . 8 6.1.2. Initialization and Negotiation of HC Channel . . . . . . . 9
6.2.3. Encapsulation and Identification of Header 6.1.3. Encapsulation and Identification of Header Compressed
Compressed Packets . . . . . . . . . . . . . . . . . . 9 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Candidate Compression Schemes . . . . . . . . . . . . . . . . 9 6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10
8. Example Operation . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . 10
9. Future Work Items . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
9.1. HCoIPsec Transport Mode SAs . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
This document identifies a set of work items that need to be This document identifies a framework for integrating HC over IPsec
completed in order to achieve the integration of header compression Security Associations (SAs). The goal of integrating HC with IPsec
(HC) over IPsec Security Associations (SAs) operating in tunnel mode. is to reduce the protocol overhead associated with packets traversing
The goal of integrating HC with IPsec is to reduce the protocol between IPsec SA endpoints. This can be achieved by compressing the
overhead associated with packets traversing between IPsec SA transport layer header (e.g., UDP, TCP, etc.) and inner IP header of
endpoints. This goal can be achieved by compressing the upper layer packets at the ingress of the IPsec tunnel, and decompressing these
protocols (e.g., RTP/UDP and TCP) and the inner IP header of packets, headers 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 realize 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 an IPsec tunnel. Since these traditional HC
schemes operate on a hop-by-hop basis, several extensions need to be schemes operate on a hop-by-hop basis, several extensions must be
defined. This document details a technique which will enable these defined to enable their operation over IPsec SAs. This document
traditional hop-by-hop HC schemes to be extended, and operate between details a framework which will allow these traditional hop-by-hop HC
IPsec SA endpoints. schemes to be extended to operate at IPsec SA endpoints.
Currently, HCoIPsec primarily targets the application of HC to tunnel HCoIPsec currently targets the application of HC to tunnel mode SAs.
mode SAs as opposed to transport mode SAs. Transport mode SAs However, future work may extend the framework to operate over
encrypt/authenticate only the payload of an IP packet, leaving the transport mode SAs as well. Transport mode SAs only encrypt/
original IP header untouched. Intermediate routers subsequently use authenticate the payload of an IP packet, leaving the IP header
the original IP header to route the packet to a decryption device. untouched. Intermediate routers subsequently use the outer IP header
Therefore, if HC were extended to operate between IPsec transport- to route the packet to a decryption device. Therefore, if HC
mode SA endpoints, (de)compression functionality can be applied only mechanisms are extended to operate between IPsec transport-mode SA
to the transport layer headers and not the IP header. Since endpoints, (de)compression functionality can only be applied to the
compression of transport layer headers alone does not provide transport layer headers, and not to the IP header. Since compression
substantial efficiency gains, it is not integrated into HCoIPsec. of transport layer headers alone does not provide substantial
efficiency gains, extending the HCoIPsec framework to support
transport mode SAs is left for future work.
2. Audience 2. Audience
The target audience includes those who are involved with the design The target audience includes those who are involved with the
and development of HC schemes, and IPsec mechanisms. Since development of HC schemes, and IPsec implementations. 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 requirements 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. Terminology 3. Terminology
Terminology specific to discussion of HCoIPsec is introduced in this Terminology specific to discussion of HCoIPsec is introduced in this
section. section.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
Compressed Traffic Compressed Traffic
Traffic that is processed by the compressor (compressed) using one Traffic that is processed by the compressor. Packet headers are
of the existing profiles. Note: This includes packets that might compressed using a compression profile.
be compressed using an "uncompressed" profile.
Uncompressed Traffic Uncompressed Traffic
Traffic that is not processed by the compressor. Instead, this Traffic that is not processed by the compressor. Instead, this
type of traffic is bypassed by the HC process. type of traffic bypasses the HC process.
HC Process HC Process
Generic reference to either the compressor, decompressor, and 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 Internet Protocol Security (IPsec) process Generic reference to the Internet Protocol Security (IPsec)
[IPSEC]. process [IPSEC].
4. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode 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 networks.
networks. For example, ESP offers data origin authentication, The benefits of IPsec come at the cost of increased per-packet
connectionless integrity, anti-replay service, and limited traffic overhead. For example, traffic flow confidentiality (generally
flow confidentiality [ESP]. leveraged at security gateways) requires the tunneling of IP packets
between IPsec implementations. Although these IPsec tunnels will
effectively mask the source-destination patterns that an intruder can
ascertain, IPsec tunnels come at the cost of increased per-packet
overhead. Specifically, an ESP tunnel mode SA applied to an IPv6
flow results in at least 50 bytes of additional overhead per packet.
This additional overhead may be undesirable for many bandwidth-
constrained wireless and/or satellite communications networks, as
these types of infrastructure are not overprovisioned. Consequently,
the additional overhead incurred in an encryption-based environment
may result in the inefficient utilization of bandwidth.
The benefits of IPsec mechanisms come at the cost of increased per- Packet overhead is particularly significant for traffic profiles
packet overhead in the network. For example, traffic flow characterized by small packet payloads. Some applications that
confidentiality, which is generally implemented at security gateways, emanate small packet payloads include various voice codecs (e.g.,
requires the tunneling of IP packets between the IPsec devices. G.729). In addition, if these small packets are afforded the
IPsec tunnels may mask the source-destination patterns that an security services of an IPsec tunnel mode SA, the amount of per-
intruder may ascertain, but the benefit comes at the cost of extra packet overhead is magnified. Thus, a mechanism is needed to reduce
per-packet overhead. An ESP tunnel mode SA applied to an IPv6 flow the overhead associated with such flows.
results in at least 50 bytes of additional overhead per packet. This
additional overhead may be undesirable for many bandwidth-constrained
wireless and/or Satellite Communications (SATCOM) networks, as these
types of infrastructure are not overprovisioned. Consequently, the
additional overhead incurred in an encryption-based environment may
hinder the efficient utilization of bandwidth.
In bandwidth-constrained, high bit error rate (BER) networks, IP 5. Overview of the HCoIPsec Framework
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
payloads. This is due to the fact that large packets traversing high
BER links result in high IP Packet Loss Ratio (IPLR). To reduce
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.
Reducing the size of packet payloads, however, increases the amount
of overhead transmitted between the two end hosts. Moreover, if
these packets traverse over an IPsec tunnel mode SA, the amount of
overhead is further magnified. A mechanism is needed to reduce the
overhead associated with such flows.
5. The Header Compression Solution 5.1. HCoIPsec Assumptions
IP HC schemes provide one mechanism to reduce packet overhead in an The goal for HCoIPsec is to provide more efficient transport of IP
IP network. Schemes such as IPHC, CRTP, ECRTP and ROHC exploit packets between source and destination IPsec devices, without
inter-packet redundancies of network and transport-layer header compromising the security services offered by IPsec. As such, the
fields of a flow to reduce the amount of redundant header data HCoIPsec framework was developed based on the following assumptions:
transmitted between two nodes. o Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) will be
leveraged to reduce the amount of overhead associated with packets
traversing an IPsec SA
o HC algorithms will be instantiated at the IPsec SA endpoints, and
HC is applied on a per-SA basis
To apply HC schemes over IPsec SAs, several extensions to the 5.2. HCoIPsec Description
existing schemes need to be developed. Existing HC schemes such as
IPHC, CRTP, ECRTP and ROHC are designed to compress headers on a hop- HC schemes reduce packet overhead in a network by exploiting inter-
by-hop basis. IPsec SAs, however, may be instantiated between IPsec packet redundancies of network and transport-layer header fields of a
devices functioning as gateways, with multiple intermediary nodes flow to reduce the amount of redundant header data transmitted
between the IPsec gateways. Therefore, to fully integrate HC with between two nodes.
IPsec SAs, traditional hop-by-hop schemes need to be extended to
operate between IPsec SA endpoints. To apply traditional HC schemes over IPsec SAs, several extensions
need to be defined. Existing HC schemes compress packet headers on a
hop-by-hop basis. However, IPsec SAs are instantiated between two
IPsec implementations, with multiple hops between the IPsec
implementations. Therefore, to fully integrate HC with IPsec SAs,
traditional hop-by-hop schemes need to be extended to operate at
IPsec SA endpoints.
The migration of traditional hop-by-hop HC schemes over IPsec SAs is The migration of traditional hop-by-hop HC schemes over IPsec SAs is
simple, as SA endpoints provide source/destination pairs where straightforward, since SA endpoints provide source/destination pairs
(de)compression operations can take place. Compression in such a where (de)compression operations can take place. Compression in such
manner offers both 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 network nodes between the decompression cycles at the intermediate hops between IPsec
IPsec devices. Since HC schemes will now essentially operate over implementations. Since HC schemes will now essentially operate over
multiple hops, it is imperative that the performance of the HC multiple hops, it is imperative that the performance of the HC
schemes is not severely impacted due to increased packet reordering schemes is not severely impacted due to increased packet reordering
and/or IPLR events between the compressor and decompressor. It and/or packet loss between the compressor and decompressor.
should be noted that the notion of extending hop-by-hop HC schemes to
operate over multiple hops is not new, as the HCoIPsec effort
parallels other efforts such as ECRTP over MPLS [HCOMPLS].
Using the proposed architecture, outbound IP traffic processing at an In addition, since HC schemes will operate at IPsec SA endpoints, HC
IPsec device is augmented to compress appropriate packet headers, and schemes can no longer rely on the underlying link layer for HC
subsequently encrypt and/or integrity-protect the packet. For tunnel parameter configuration and packet identification. Traditionally, HC
mode SAs, compression may be applied to the transport layer protocol schemes use the underlying link layer to establish a set of
and the inner IP header. configuration parameters at each end of the link, and for identifying
different types of header-compressed packets. The HCoIPsec framework
proposes that HC session parameter configuration and header-
compressed packet identification is accomplished by the SA management
protocol (e.g., IKEv2) and the security protocol next header field,
respectively.
Using the HCoIPsec framework proposed below, outbound IP traffic
processing at an IPsec device is augmented to compress appropriate
packet headers, and subsequently encrypt and/or integrity-protect the
packet. For tunnel mode SAs, compression may be applied to the
transport layer protocol and the inner IP header.
Inbound IP traffic processing at an IPsec device is modified in a 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
implicitly determines whether the packet was received on a HC-enabled determines if the packet was received on an HC-enabled SA(see section
SA. If the packet was received over a HC-enabled SA, the 6.1), and if the packet maintains compressed headers. If both of
decompression function takes place. these conditions are met, decompression of the inner packet headers
is performed. After decompression, the packet is checked against the
Note: Compression of inner headers is completely independent from access controls imposed on all inbound traffic associated with the SA
compression of the outer (e.g., ESP/IP) headers. Intermediate (as specified in RFC 4301).
network nodes between IPsec endpoints may also compress the outer
ESP/IP headers. Current HC schemes such as ROHC and IPHC contain
the ability to compress these ESP/IP headers. Further discussion
of hop-by-hop compression of the outer ESP/IP headers is out of
the scope of this document.
If IPsec NULL encryption is applied on packets, HC schemes may still
be applied on the inner headers at the IPsec SA endpoints. Inbound
and outbound packets are processed as described previously. In
scenarios where NULL-encrypted packets traverse intermediate nodes
between the IPsec SA endpoints, the intermediary nodes must not
attempt to (de)compress the inner IP and/or transport layer headers
on a hop-by-hop basis.
6. Integration Methodology
The goal for HCoIPsec is to provide more efficient transport of IP
packets between source and destination IPsec devices, via tunnel mode
SAs, without compromising security services offered by IPsec.
With this general goal in mind, Section 5.1 defines a set of work
assumptions to guide the direction of the HCoIPsec solution. Based
on these work assumptions, Section 5.2 defines work items which need
to be addressed to achieve the HCoIPsec solution.
6.1. Work Assumptions
a. HCoIPsec must use existing HC protocols (e.g., IPHC, CRTP, ECRTP,
ROHC) to reduce the amount of overhead associated with packets
traversing an IPsec tunnel-mode SA.
b. HCoIPsec must execute (de)compression operations at IPsec SA
endpoints, and must not perform (de)compression cycles at
intermediate nodes between IPsec devices.
c. HCoIPsec must be independent of the underlying link layer framing
protocol (e.g., PPP).
d. HCoIPsec must allow each SA to constitute a HC channel, enabling
each SA to have its own CID space.
e. An SA with HC enabled should not deliver a larger number of
erroneous packets than the same SA with HC disabled.
The motivation behind (c) comes from the realization that an SA may
traverse multiple links, employing various framing protocols, and
that the set of links (and thus framing protocols) may change during
the lifetime of an SA. Therefore, link layer dependencies exhibited
by traditional hop-by-hop HC schemes cannot be used in the HCoIPsec
solution.
6.2. Work Items
This section identifies several work items that need to be addressed
to achieve HCoIPsec. The first work item encompasses the HC scheme-
specific extensions needed to ensure that traditional hop-by-hop HC
schemes will operate efficiently over IPsec SA endpoints:
a. Header Compression Scheme-Specific Extensions: Any modifications
needed to be made to existing HC schemes, which will facilitate
their operation over IPsec SAs. (Section 5.2.1)
Hop-by-hop HC schemes use the underlying link layer (e.g., PPP) to
negotiate the HC channel parameters and to indicate the type of
compressed packet the data-link layer frame is encapsulating. To
remove HC scheme dependencies on the underlying link layer, two
additional work items are proposed:
b. Initialization and Negotiation of the Header Compression Channel:
Mechanisms needed to initialize a HC channel and negotiate HC
scheme parameters prior to operation. (Section 5.2.2)
c. Encapsulation and Identification of Header Compressed Packets:
Mechanisms that encapsulate and identify compressed header
packets, as well as how these mechanisms will operate. (Section
5.2.3)
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
increased delays, packet loss, jitter, and reordering events
between compressor and decompressor.
b. HCoIPsec should minimize the amount of HC signaling between
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 decompressor to the compressor is not used sparingly, then the
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-
directional reliable mode is instantiated over an IPsec tunnel mode
SA. Any feedback sent from the decompressor to the compressor may be
tunneled, and therefore, the additional overhead incurred by
tunneling the feedback will reduce the overall benefits of HC.
Note that if a HCoIPsec session requires bidirectional communication
between the compressor and the decompressor (e.g., a ROHC session
operating in bidirectional-reliable mode, or bidirectional-optimistic
mode, or ECRTP and CONTEXT_STATE packets), this may pose an issue,
given that SAs are unidirectional, and that HCoIPsec defines a HC
context to be specific to a given SA. Any feedback packet
communicated from the HCoIPsec decompressor to the HCoIPsec
compressor is over a separate SA back to the original IPsec device.
To identify the stale context, the feedback packet must contain the
context ID as well as an indication of the SA that the decompressor
is associated to. This poses a problem for current HC algorithm
feedback packets, which are not structured to carry the additional SA
indication information. For example, current ECRTP feedback
mechanisms (e.g., CONTEXT_STATE) only list the CIDs for which
synchronization has been lost. If a bidirectional HC algorithm is to
be integrated with IPsec, additional HC scheme-specific extensions
must be defined to resolve this issue.
6.2.2. Initialization and Negotiation of Header Compression Channel
Initialization of the HC channel will be achieved manually (i.e.,
administratively configured for manual SAs), or will be performed by
IPsec SA establishment protocols, e.g. IKE. During SA
initialization, the type of HC scheme configured for the SA, as well
as the HC scheme's channel parameters will be identified.
a. HCoIPsec may leverage IKE, IKEv2 to negotiate HC channel
parameters (e.g., for ROHC, IKE(v2) shall initialize PROFILES,
MAX_CID, MAX_HEADER, MRRU).
b. HCoIPsec must allow packets with uncompressed headers and packets
with compressed headers to traverse a single SA. "Packets with
compressed headers" refer to packets which are selected to an HC-
enabled SA, are passed to the compressor, and are actually
compressed; "packets with uncompressed headers" refer to packets
which are selected to an HC-enabled SA, are passed to the
compressor, and are not "compressed" (e.g., ROHC compressor
processes a packet with the uncompressed profile).
Note: (b) is necessary in situations where a compressor--can not
compress a flow (e.g., a compressor supports strictly n compressed
flows, and can not compress the n+1 flow that arrives).
Note: (b) is still being discussed within the community and is Note: Compression of inner headers is independent from compression
subject to change. More information about (b) can be found in the of the security protocol (e.g., ESP) and outer IP headers. HC
"Alternatives to Achieving HCoIPsec" internet-draft, a document being schemes such as ROHC and IPHC are capable of compressing these
used to help resolve HCoIPsec discussions and issues in order to outer headers on a hop-by-hop basis. Further discussion on the
stabilize the HCoIPsec draft. compression of outer headers is outside the scope of this
document.
6.2.3. Encapsulation and Identification of Header Compressed Packets If IPsec NULL encryption is applied to packets, HC schemes may still
be applied to the inner headers at the IPsec SA endpoints. Inbound
and outbound packets are still processed as was previously described.
For scenarios where NULL-encrypted packets traverse intermediate
nodes between the IPsec SA endpoints, the intermediary nodes must not
attempt to (de)compress the inner IP and/or transport layer headers.
For indication purposes, a one-byte header may be added to the 6. Details of the HCoIPsec Framework
compressed packet; this field will help the decompressor identify how
to process the compressed packet. This one-byte header is only
relevant to the HC compression and decompression processes, and is
not used by IPsec..
a. HCoIPsec must indicate the type of compressed packet (e.g., for 6.1. HC and IPsec Integration
ECRTP, COMPRESSED_RTP_8, COMPRESSED_RTP_16, CONTEXT_STATE, etc.)
on a per packet basis.
Note that ROHC indicates its own packet type within the protocol, and Based on these assumptions, Figure 1 illustrates the components
does not require a new one-byte header to indicate the type of required to integrate HC with the IPsec process, i.e., HCoIPsec.
compressed packet.
Note: Alternatives to using a "one-byte header" are still being +-------------------------------+
discussed within the community, thus this section may change. More | HC Module |
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. +-----+ | +-----+ +---------+ |
| | HC-enabled | | | | HC | |
--| A |--------------------| B |-----| Process |------> Path 1
| | | | | | | |
+-----+ | +-----+ +---------+ |
| | | |
| | |-------------------------> Path 2
| | |
| +-------------------------------+
|
| HC-disabled
+----------------------------------------------------> Path 3
7. Candidate Compression Schemes Figure 1: Integration of HC with IPsec.
IPHC can be used to compress TCP/IP headers for tunnel mode SAs. The process illustrated in Figure 1 augments the IPsec processing
model for outbound IP traffic(protected-to-unprotected). Initial
IPsec processing is consistent with RFC 4301 (Steps 1-2, Section
5.1). The HC data item (part of the SA state information) retrieved
from the "relevant SAD entry" (RFC4301, Section 5.1, Step3a)
determines if the traffic traversing the SA is handed to the HC
module (Figure 1, decision block A). Packets selected to an HC-
disabled SA must follow normal IPsec processing and must not be sent
to the HC module (Figure 1, Path 3). Conversely, packets selected to
an HC-enabled SA must be sent to the HC module. The decision at
block B then determines if the packet can be compressed. If it is
determined that the packet will be compressed, the Next Header field
of the security protocol header (e.g., ESP, AH) is populated with the
"compressed headers" value, and packet headers are compressed based
on the appropriate compression profile (Figure 1, Path 1). However,
if it is determined that the packet will not be compressed, the Next
Header field is populated with the appropriate value indicating the
next level protocol (Figure 1, Path 2). After the HC process
completes, IPsec processing resumes, as described in Section 5.1,
Step3a, of RFC4301 (specifically, "IPsec processing is as previously
defined...").
IPHC, however, has been identified as a HC scheme that performs The process illustrated in Figure 1 also augments the IPsec
poorly over long round trip time (RTT), high BER links [ROHC]. processing model for inbound IP traffic (unprotected-to-protected).
Extensions to IPHC to compress TCP/IP headers over an IPsec SA need For inbound packets, processing is performed (RFC4301, Section 5.2,
to take into consideration longer RTTs, increased potential for Steps 1-3) followed by AH or ESP processing (RFC4301, Section 5.2,
packet reordering and IPLR between the compressor and decompressor. Step 4) . After AH or ESP processing, the HC data item retrieved
from the SAD entry will indicate if traffic traversing the SA is
handed to the HC module (RFC4301, Section 5.2, Step 3a). Packets
traversing an HC-disabled SA must follow normal IPsec processing and
must not be sent to the HC module. Conversely, packets traversing an
HC-enabled SA must be sent to the HC module. The decision at block B
then determines if the "Next Header" field contains the "compressed
header" value, which indicates that the packet's payload contains
compressed headers. If "compressed headers" is indicated, the
appropriate decompression profile is applied (Figure 1, Path 1).
However, if the packet's "Next Header" field does not contain the
"compressed headers" value, the decompressor must not attempt
decompression (Figure 1, Path 2). IPsec processing resumes once the
HC module completes processing, as described in Section 5.2, Step 4
of RFC 4301(specifically "Then match the packet against the inbound
selectors identified by the SAD ...").
CRTP can be used to compress RTP/UDP/IP headers for tunnel mode SAs. 6.1.1. Header Compression Scheme Considerations
CRTP, however, has also been identified as a HC scheme that performs
poorly over long RTT, high BER links [CRTPE]. Recent modifications
to the CRTP scheme, such as ECRTP, enables the CRTP HC scheme to
tolerate long RTTs, packet loss, between compressor and decompressor.
The reordering tolerance of ECRTP, however, needs to be evaluated, as
detailed in [ECRTPE]. Such implementation aspects should be taken
into consideration when extending ECRTP to operate between IPsec SA
endpoints.
ROHC, as defined in RFC 3095, provides a robust HC scheme that is Traditional hop-by-hop HC schemes must be extended to operate
designed for high BER, long RTT links. This makes ROHC another efficiently over IPsec SAs. Implementation considerations for this
candidate header scheme to operate over IPsec tunnels. ROHC can be includes increasing tolerance to packet reordering and packet loss
used to compress not only RTP/UDP/IP headers, but also TCP/IP between the compressor and decompressor, and minimizing the amount of
headers, as defined in [ROHCTCP]. Similar to CRTP and IPHC, ROHC has feedback sent from the decompressor to the compressor.
been identified as vulnerable to packet reordering events between the
compressor and decompressor[ROHCE]. Recent work [ROHCWEXT] suggests
that the implementation aspects of ROHC can be modified to achieve
tolerance to packet reordering events. Such implementation aspects
should be taken into consideration when extending ROHC to operate
between IPsec SA endpoints.
The ability to tolerate these network characteristics is a necessity The ability to tolerate increased packet reordering between the
for any HCoIPsec scheme, and will be a factor in determining how compressor and decompressor is a necessity for any HC scheme that is
efficiently the HC scheme operates over the IPsec tunnel-mode SAs. extended to operate over an IPsec SA. The following provides a
summary of the candidate HC solutions, and their tolerance to packet
loss and reordering between the compressor and decompressor:
o IPHC has been identified as a HC scheme that performs poorly over
long round trip time (RTT), high BER links [ROHC]. Extensions to
IPHC to compress TCP/IP headers over an IPsec SA should take into
consideration longer RTTs, increased potential for packet
reordering and IPLR between the compressor and decompressor.
o CRTP has also been identified as a HC scheme that performs poorly
over long RTT, high BER links [CRTPE]. Recent modifications to
the CRTP scheme, such as ECRTP, enable the CRTP HC scheme to
tolerate long RTTs and packet loss between the compressor and
decompressor. However, the reordering tolerance of ECRTP still
needs to be evaluated, as detailed in [ECRTPE]. Such
implementation aspects should be taken into consideration when
extending ECRTP to operate over IPsec SAs.
o ROHC is a robust HC scheme that is designed for high BER, long RTT
links. ROHC can be used to compress not only RTP/UDP/IP headers,
but also other traffic profiles such as TCP/IP, as defined in
[ROHCTCP]. Similar to CRTP and IPHC, ROHC has been identified as
vulnerable to packet reordering events between the compressor and
decompressor[ROHCE]. Recent work [ROHCWEXT] suggests that the
implementation aspects of ROHC can be modified to achieve
tolerance to packet reordering events. Such implementation
aspects should be taken into consideration when extending ROHC to
operate over IPsec SAs.
8. Example Operation In addition, HC schemes should minimize the amount of feedback
between decompressor and compressor. If a feedback channel from the
decompressor to the compressor is not used sparingly, the overall
gains from HCoIPsec can be significantly reduced. For example,
assume that ROHC is operating in bi-directional reliable mode, and is
instantiated over an IPsec tunnel mode SA. In this scenario, any
feedback sent from the decompressor to the compressor must be
tunneled. As such, the additional overhead incurred by tunneling
feedback will reduce the overall benefits of HC.
The basic operation of the HCoIPsec protocol is detailed in the 6.1.2. Initialization and Negotiation of HC Channel
following example. Assume there are two IPsec devices operating as
security gateways. HCoIPsec leverages an SA establishment protocol
(e.g., IKE, IKEv2) to negotiate the HC scheme, and channel
parameters. For example, the MAX_CID, MRRU, MAX_HEADER, and PROFILES
parameters will be negotiated for each IPsec SA which is capable of
ROHC. For an IPsec SA that is ECRTP-enabled, channel parameters
including F_MAX_PERIOD, F_MAX_TIME, and the ECRTP Compression
Suboption will be initialized. For the following example, assume
that a SA has been established.
Outbound packet processing is as follows. The packet is initially Hop-by-hop HC schemes use the underlying link layer (e.g., PPP) to
processed as described in Steps 1-2, Section 5.1 of RFC 4301. The negotiate HC channel parameters. To remove HC scheme dependencies on
SPD cache entry then maps the packet to a given SAD entry, which the underlying link layer, an additional mechanism is needed to
indicates the HC protocol enabled on the SA (in addition to mode, initialize a HC channel and its associated parameters prior to HC
cryptographic algorithms, keys, etc.). If the SAD entry indicates scheme operation.
that compression is disabled, then standard IPsec processing ensues,
as described in Steps 3-4, Section 5.1 of RFC 4301. If the SAD entry
indicates that compression is enabled, the packet must be handed to
the appropriate compressor, which executes the compression process.
After the packet's header is compressed, the packet resumes IPsec
processing as described in Step 3a, where standard IPsec ESP
processing ensues (including packet encryption according to the SAD
entry parameters, packet encapsulation with the outer ESP/IP header)
and is subsequently passed to the outbound forwarding function, as
described in Step 4 of RFC 4301.
Inbound packet processing is as follows. The packet is initially Initialization of the HC channel will either be achieved manually
processed as described in Steps 1-3, Section 5.2 of RFC 4301; (i.e., administratively configured for manual SAs), or be performed
subsequently (using the SAD entry selected in Step 3a), ESP by IPsec SA establishment protocols, e.g. IKEv2. During SA
processing is applied. Based on information retrieved from the SAD initialization, the SA establishment protocol will be extended to
entry, it can also be determined whether traffic traversing the SA is negotiate the HC scheme's channel parameters. The specifics for this
compressed or not compressed. If the SAD entry indicates that proposal are detailed in a separate spectification, "IKEv2/IPsec
compression is not enabled on the SA, then standard IPsec processing Extensions to Support HCoIPsec".
of the packet ensues, as described in Step 4, Section 5.2 of RFC
4301. If compression is enabled on the SA, the packet is handed to
the decompressor for "decompression". Once the packet is
decompressed, the processing as described in Step 4, Section 5.2 of
RFC 4301 resumes (specifically "Then match the packet against the
inbound selectors identified by the SAD...").
Figure 1 depicts the basic function of HCoIPsec: If the HC scheme requires bi-directional communications, two SAs must
be instantiated between the IPsec implementations. One of the two
SAs is used for carrying traffic from the compressor to the
decompressor, while the other is used to communicate feedback from
the decompressor to the compressor. IPsec implementations will
dictate how decompressor feedback received on one SA is associated
with a compressor on the other SA.
-- -- -- -- -- -- -- -- -- -- 6.1.3. Encapsulation and Identification of Header Compressed Packets
|ESP Tunnel Mode Security Association|
| |
| |
V V
+--------------+ +--------------+
| IPsec Device | +--+ +--+ | IPsec Device |
| | | | | | | |
+---| Compressor |-->|R1|-->|R2|-->| Decompressor |---+
| | | | | | | | | |
| +--------------+ +--+ +--+ +--------------+ |
| | | |
| |-----------------| |
| | |
| | |
V V V
+-----------------+ +-----------------------+ +-----------------+
| | | | | | | | | | | |
| | UDP | | | | E | ------------- | | | UDP | |
|IP | / |Payload| |IP | S | |CID|Payload| | |IP | / |Payload|
| | RTP | | | | P | ------------- | | | RTP | |
| | | | | | | | | | | |
+-----------------+ +-----------------------+ +-----------------+
| |
|---ENCRYPTED---|
| |
Figure 1: Example operation of HCoIPsec. 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
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
sends the traffic through regular IPsec processing (HC-disabled).
In the example scenario, note that the inbound and outbound packets In addition, the "Next Header" field of the IPsec security protocol
are first mapped to an SA, and then subsequently mapped to a CID. (e.g., AH or ESP) header is used to demultiplex header-compressed
This implies that the scope of each CID is contained within each SA. traffic from uncompressed traffic traversing an HC-enabled SA. This
A CID value of 1 can be associated with multiple SAs; however, the functionality is needed in situations where packets traversing an HC-
context state information for CID 1 cannot be shared over multiple enabled SA are not compressed by the compressor. Such situations may
SAs. occur when, for example, a compressor supports strictly n compressed
flows and can not compress the n+1 flow that arrives. Another
example is when traffic (e.g., TCP/IP) is selected to an HC-enabled
SA, but cannot be compressed by the HC process (e.g., because the
compressor does not support TCP/IP compression). In these
situations, the compressor must be able to indicate that the packet
contains uncompressed headers. Similarly, the decompressor must be
able to identify packets with uncompressed headers and not attempt to
decompress them. Therefore, an allocation for "compressed headers"
will need to be reserved from the IANA "Protocol Numbers" registry,
which will be defined in a separate specification. The "compressed
headers" value will indicate that the next layer protocol header is
composed of compressed headers.
9. Future Work Items 6.2. HCoIPsec Framework Summary
9.1. HCoIPsec Transport Mode SAs [Note to RFC Editor: this section may be removed on publication as an
RFC.]
Many of the current HC profiles look to simultaneously compress To summarize, the following items are needed to achieve HCoIPsec:
network and transport layer headers of IP packets. This makes the o Extensions to traditional HC schemes which enable their operation
extension of traditional HC schemes over transport-mode SAs more at IPsec SA enpoints
difficult. For the application of HC over transport mode SAs, o Extensions to IKE/IPsec to support HC parameter configuration
traditional HC schemes may need to be extended to operate strictly on o Allocation of one value for "compressed headers" from the IANA
layer 4 (e.g., TCP, and/or RTP/UDP) headers. The specification for "Protocol Numbers" registry
HCoIPsec transport mode SAs is left for further study.
10. 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; used during outbound processing) has the ingress of the IPsec tunnel) has the ability to send packets to
the ability to send packets to the decompressor (i.e., the the decompressor (i.e., the decompressor located at the egress of the
decompressor located at the egress of the IPsec tunnel; used during IPsec tunnel) that do not match the original packets emitted from the
inbound processing) that do not match the original packets emitted end-hosts. Such a scenario will result in a decreased efficiency
from the end-hosts. In such a scenario, the invalid packets will between compressor and decompressor. Furthermore, this may result in
pass through inbound IPsec processing, and will subsequently be Denial of Service, as the decompression of a significant number of
validly decompressed. invalid packets may drain the resources of an IPsec device.
Furthermore, an intruder who has the ability to arbitrarily inject
packets between SA endpoints, and addresses these malicious packets
to the encryption/decryption devices, has the ability to cause
context corruption between the compressor and decompressor processes
instantiated within the IPsec device (if the malicious packet passes
through the decryption process). Such a scenario will result in a
decreased efficiency between compressor and decompressor, and
furthermore, may result in Denial of Service, as the decompression of
a significant number of invalid packets may drain the resources of an
IPsec device.
Note: It should be noted, however, that these security issues are
a direct result of IPsec vulnerabilities.
11. IANA Considerations 8. IANA Considerations
None. None.
12. Acknowledgments 9. Acknowledgments
The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler,
of the Department of Defense, and Mr. A. Rich Espy of OPnet for their and Ms. Linda Noone of the Department of Defense, and well as Mr.
contributions and support for developing this document. The authors Rich Espy of OPnet for their contributions and support in the
would also like to thank Mr. Jan Vilhuber, Mr. Dan Wing, of Cisco development of this document. In addition, the authors would like to
Systems, Mr. Lars-Erik Jonsson and Mr. Kristopher Sandlund of thank the following for their numerous reviews and comments to this
Ericsson for their valuable contributions to this document. The document:
authors would also like to thank Ms. Renee Esposito, Mr. Etzel
Brower, Mr. Jigar Amroliwala, and Mr. Dwayne Corbin of Booz Allen
Hamilton for their assistance in completing this work.
13. References o Dr. Stephen Kent
o Dr. Carsten Bormann
o Mr. Lars-Erik Jonnson
o Mr. Jan Vilhuber
o Mr. Dan Wing
o Mr. Kristopher Sandlund
13.1. Normative References Finally, the authors would also like to thank Mr. Tom Conkle, Ms.
Renee Esposito, Mr. Etzel Brower, and Mr. Jonah Pezeshki of Booz
Allen Hamilton for their assistance in completing this work.
10. References
10.1. Normative References
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the [IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header [IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999. Compression", RFC 2507, February 1999.
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
February 1999. February 1999.
skipping to change at page 14, line 41 skipping to change at page 12, line 11
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 ,
January 2006. 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", RFC 4224, January 2006. Reorder Packets", RFC 4224, January 2006.
13.2. Informative References 10.2. Informative References
[ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303,
December 2005. December 2005.
[HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header [HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header
Compression over MPLS", April 2005. Compression over MPLS", April 2005.
[CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, [CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro,
"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",
RFC 4247, November 2005. RFC 4247, November 2005.
[AAL2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2
AAL", I.363.2 , September 1997.
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: ertekin_emre@bah.com Email: ertekin_emre@bah.com
 End of changes. 58 change blocks. 
449 lines changed or deleted 342 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/