draft-ietf-rohc-hcoipsec-13.txt   rfc5856.txt 
Network Working Group E. Ertekin Internet Engineering Task Force (IETF) E. Ertekin
Internet-Draft R. Jasani Request for Comments: 5856 R. Jasani
Intended status: Informational C. Christou Category: Informational C. Christou
Expires: August 6, 2010 Booz Allen Hamilton ISSN: 2070-1721 Booz Allen Hamilton
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
February 2, 2010 May 2010
Integration of Robust Header Compression over IPsec Security Integration of Robust Header Compression over
Associations IPsec Security Associations
draft-ietf-rohc-hcoipsec-13
Abstract Abstract
IP Security (IPsec) provides various security services for IP IP Security (IPsec) provides various security services for IP
traffic. However, the benefits of IPsec come at the cost of traffic. However, the benefits of IPsec come at the cost of
increased overhead. This document outlines a framework for increased overhead. This document outlines a framework for
integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).
By compressing the inner headers of IP packets, ROHCoIPsec proposes By compressing the inner headers of IP packets, ROHCoIPsec proposes
to reduce the amount of overhead associated with the transmission of to reduce the amount of overhead associated with the transmission of
traffic over IPsec Security Associations (SAs). traffic over IPsec Security Associations (SAs).
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It has been approved for publication by the Internet
Engineering Steering Group (IESG). Not all documents approved by the
IESG are a candidate for any level of Internet Standard; see Section
2 of RFC 5741.
This Internet-Draft will expire on August 6, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5856.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 6
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Audience ........................................................3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology .....................................................3
4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 5 4. Problem Statement: IPsec Packet Overhead ........................4
5. Overview of the ROHCoIPsec Framework . . . . . . . . . . . 6 5. Overview of the ROHCoIPsec Framework ............................5
5.1. ROHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 6 5.1. ROHCoIPsec Assumptions .....................................5
5.2. Summary of the ROHCoIPsec Framework . . . . . . . . . . . 6 5.2. Summary of the ROHCoIPsec Framework ........................5
6. Details of the ROHCoIPsec Framework . . . . . . . . . . . 8 6. Details of the ROHCoIPsec Framework .............................7
6.1. ROHC and IPsec Integration . . . . . . . . . . . . . . . . 8 6.1. ROHC and IPsec Integration .................................7
6.1.1. Header Compression Protocol Considerations . . . . . . . . 10 6.1.1. Header Compression Protocol Considerations ..........9
6.1.2. Initialization and Negotiation of the ROHC Channel . . . . 10 6.1.2. Initialization and Negotiation of the ROHC Channel ..9
6.1.3. Encapsulation and Identification of Header Compressed 6.1.3. Encapsulation and Identification of Header
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 11 Compressed Packets .................................10
6.1.4. Motivation for the ROHC ICV . . . . . . . . . . . . . . . 12 6.1.4. Motivation for the ROHC ICV ........................11
6.1.5. Path MTU Considerations . . . . . . . . . . . . . . . . . 12 6.1.5. Path MTU Considerations ............................11
6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 13 6.2. ROHCoIPsec Framework Summary ..............................12
7. Security Considerations . . . . . . . . . . . . . . . . . 13 7. Security Considerations ........................................12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations ............................................12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments ................................................13
10. Informative References . . . . . . . . . . . . . . . . . . 14 10. Informative References ........................................14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document outlines a framework for integrating ROHC [ROHC] over This document outlines a framework for integrating ROHC [ROHC] over
IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the
protocol overhead associated with packets traversing between IPsec SA protocol overhead associated with packets traversing between IPsec SA
endpoints. This can be achieved by compressing the transport layer endpoints. This can be achieved by compressing the transport layer
header (e.g., UDP, TCP, etc.) and inner IP header of packets at the header (e.g., UDP, TCP, etc.) and inner IP header of packets at the
ingress of the IPsec tunnel, and decompressing these headers at the ingress of the IPsec tunnel, and decompressing these headers at the
egress. egress.
For ROHCoIPsec, this document assumes that ROHC will be used to For ROHCoIPsec, this document assumes that ROHC will be used to
compress the inner headers of IP packets traversing an IPsec tunnel. compress the inner headers of IP packets traversing an IPsec tunnel.
However, since current specifications for ROHC detail its operation However, since current specifications for ROHC detail its operation
on a hop-by-hop basis, it requires extensions to enable its operation on a hop-by-hop basis, it requires extensions to enable its operation
over IPsec SAs. This document outlines a framework for extending the over IPsec SAs. This document outlines a framework for extending the
usage of ROHC to operate at IPsec SA endpoints. usage of ROHC to operate at IPsec SA endpoints.
ROHCoIPsec targets the application of ROHC to tunnel mode SAs. ROHCoIPsec targets the application of ROHC to tunnel mode SAs.
Transport mode SAs only encrypt/authenticate the payload of an IP Transport mode SAs only protect the payload of an IP packet, leaving
packet, leaving the IP header untouched. Intermediate routers the IP header untouched. Intermediate routers subsequently use this
subsequently use this IP header to route the packet to a decryption IP header to route the packet to a decryption device. Therefore, if
device. Therefore, if ROHC is to operate over IPsec transport-mode ROHC is to operate over IPsec transport-mode SAs, (de)compression
SAs, (de)compression functionality can only be applied to the functionality can only be applied to the transport layer headers, and
transport layer headers, and not to the IP header. Because current not to the IP header. Because current ROHC specifications do not
ROHC specifications do not include support for the compression of include support for the compression of transport layer headers alone,
transport layer headers alone, the ROHCoIPsec framework outlined by the ROHCoIPsec framework outlined by this document describes the
this document describes the application of ROHC to tunnel mode SAs. application of ROHC to tunnel mode SAs.
2. Audience 2. Audience
The authors target members of both the ROHC and IPsec communities who The authors target members of both the ROHC and IPsec communities who
may consider extending the ROHC and IPsec protocols to meet the may consider extending the ROHC and IPsec protocols to meet the
requirements put forth in this document. In addition, this document requirements put forth in this document. In addition, this document
is directed towards vendors developing IPsec devices that will be is directed towards vendors developing IPsec devices that will be
deployed in bandwidth-constrained IP networks. deployed in bandwidth-constrained IP networks.
3. Terminology 3. Terminology
ROHC Process ROHC Process
Generic reference to a ROHC instance (as defined in RFC 3759 Generic reference to a ROHC instance (as defined in RFC 3759
[ROHC-TERM]), or any supporting ROHC components. [ROHC-TERM]) or any supporting ROHC components.
Compressed Traffic Compressed Traffic
Traffic that is processed through the ROHC compressor and Traffic that is processed through the ROHC compressor and
decompressor instances. Packet headers are compressed and decompressor instances. Packet headers are compressed and
decompressed using a specific header compression profile. decompressed using a specific header compression profile.
Uncompressed Traffic Uncompressed Traffic
Traffic that is not processed by the ROHC compressor instance. Traffic that is not processed by the ROHC compressor instance.
Instead, this type of traffic bypasses the ROHC process. Instead, this type of traffic bypasses the ROHC process.
IPsec Process IPsec Process
skipping to change at page 5, line 36 skipping to change at page 4, line 33
4. Problem Statement: IPsec Packet Overhead 4. Problem Statement: IPsec Packet Overhead
IPsec mechanisms provide various security services for IP networks. IPsec mechanisms provide various security services for IP networks.
However, the benefits of IPsec come at the cost of increased per- However, the benefits of IPsec come at the cost of increased per-
packet overhead. For example, traffic flow confidentiality packet overhead. For example, traffic flow confidentiality
(generally leveraged at security gateways) requires the tunneling of (generally leveraged at security gateways) requires the tunneling of
IP packets between IPsec implementations. Although these IPsec IP packets between IPsec implementations. Although these IPsec
tunnels will effectively mask the source-destination patterns that an tunnels will effectively mask the source-destination patterns that an
intruder can ascertain, tunneling comes at the cost of increased intruder can ascertain, tunneling comes at the cost of increased
packet overhead. Specifically, an ESP tunnel mode SA applied to an packet overhead. Specifically, an Encapsulating Security Payload
IPv6 flow results in at least 50 bytes of additional overhead per (ESP) tunnel mode SA applied to an IPv6 flow results in at least 50
packet. This additional overhead may be undesirable for many bytes of additional overhead per packet. This additional overhead
bandwidth-constrained wireless and/or satellite communications may be undesirable for many bandwidth-constrained wireless and/or
networks, as these types of infrastructure are not overprovisioned. satellite communications networks, as these types of infrastructure
ROHC applied on a per-hop basis over bandwidth-constrained links will are not overprovisioned. ROHC applied on a per-hop basis over
also suffer from reduced performance when encryption is used on the bandwidth-constrained links will also suffer from reduced performance
tunneled header, since encrypted headers cannot be compressed. when encryption is used on the tunneled header, since encrypted
Consequently, the additional overhead incurred by an IPsec tunnel may headers cannot be compressed. Consequently, the additional overhead
result in the inefficient utilization of bandwidth. incurred by an IPsec tunnel may result in the inefficient utilization
of bandwidth.
Packet overhead is particularly significant for traffic profiles Packet overhead is particularly significant for traffic profiles
characterized by small packet payloads (e.g. various voice codecs). characterized by small packet payloads (e.g., various voice codecs).
If these small packets are afforded the security services of an IPsec If these small packets are afforded the security services of an IPsec
tunnel mode SA, the amount of per-packet overhead is increased. tunnel mode SA, the amount of per-packet overhead is increased.
Thus, a mechanism is needed to reduce the overhead associated with Thus, a mechanism is needed to reduce the overhead associated with
such flows. such flows.
5. Overview of the ROHCoIPsec Framework 5. Overview of the ROHCoIPsec Framework
5.1. ROHCoIPsec Assumptions 5.1. ROHCoIPsec Assumptions
The goal of ROHCoIPsec is to provide efficient transport of IP The goal of ROHCoIPsec is to provide efficient transport of IP
packets between IPsec devices without compromising the security packets between IPsec devices without compromising the security
services offered by IPsec. The ROHCoIPsec framework has been services offered by IPsec. The ROHCoIPsec framework has been
skipping to change at page 6, line 16 skipping to change at page 5, line 13
such flows. such flows.
5. Overview of the ROHCoIPsec Framework 5. Overview of the ROHCoIPsec Framework
5.1. ROHCoIPsec Assumptions 5.1. ROHCoIPsec Assumptions
The goal of ROHCoIPsec is to provide efficient transport of IP The goal of ROHCoIPsec is to provide efficient transport of IP
packets between IPsec devices without compromising the security packets between IPsec devices without compromising the security
services offered by IPsec. The ROHCoIPsec framework has been services offered by IPsec. The ROHCoIPsec framework has been
developed based on the following assumptions: developed based on the following assumptions:
o ROHC will be leveraged to reduce the amount of overhead associated o ROHC will be leveraged to reduce the amount of overhead associated
with unicast IP packets traversing an IPsec SA with unicast IP packets traversing an IPsec SA.
o ROHC will be instantiated at the IPsec SA endpoints, and will be
applied on a per-SA basis o ROHC will be instantiated at the IPsec SA endpoints, and it will
be applied on a per-SA basis.
o Once the decompression operation completes, decompressed packet o Once the decompression operation completes, decompressed packet
headers will be identical to the original packet headers before headers will be identical to the original packet headers before
compression compression.
5.2. Summary of the ROHCoIPsec Framework 5.2. Summary of the ROHCoIPsec Framework
ROHC reduces packet overhead in a network by exploiting intra- and ROHC reduces packet overhead in a network by exploiting intra- and
inter-packet redundancies of network and transport-layer header inter-packet redundancies of network and transport-layer header
fields of a flow. fields of a flow.
Current ROHC protocol specifications compress packet headers on a Current ROHC protocol specifications compress packet headers on a
hop-by-hop basis. However, IPsec SAs are instantiated between two hop-by-hop basis. However, IPsec SAs are instantiated between two
IPsec endpoints. Therefore, various extensions to both ROHC and IPsec endpoints. Therefore, various extensions to both ROHC and
IPsec need to be defined to ensure the successful operation of the IPsec need to be defined to ensure the successful operation of the
ROHC protocol at IPsec SA endpoints. ROHC protocol at IPsec SA endpoints.
The specification of ROHC over IPsec SAs is straightforward, since SA The specification of ROHC over IPsec SAs is straightforward, since SA
endpoints provide source/destination pairs where (de)compression endpoints provide source/destination pairs where (de)compression
operations can take place. Compression of the inner IP and upper operations can take place. Compression of the inner IP and upper
layer protocol headers in such a manner offers a reduction of packet layer protocol headers in such a manner offers a reduction of packet
overhead between the two SA endpoints. Since ROHC will now operate overhead between the two SA endpoints. Since ROHC will now operate
between IPsec endpoints (over multiple intermediate nodes which are between IPsec endpoints (over multiple intermediate nodes that are
transparent to an IPsec SA), it is imperative to ensure that its transparent to an IPsec SA), it is imperative to ensure that its
performance will not be severely impacted due to increased packet performance will not be severely impacted due to increased packet
reordering and/or packet loss between the compressor and reordering and/or packet loss between the compressor and
decompressor. decompressor.
In addition, ROHC can no longer rely on the underlying link layer for In addition, ROHC can no longer rely on the underlying link layer for
ROHC channel parameter configuration and packet identification. The ROHC channel parameter configuration and packet identification. The
ROHCoIPsec framework proposes that ROHC channel parameter ROHCoIPsec framework proposes that ROHC channel parameter
configuration is accomplished by an SA management protocol (e.g., configuration is accomplished by an SA management protocol (e.g.,
IKEv2 [IKEV2]), while identification of compressed header packets is Internet Key Exchange Protocol version 2 (IKEv2) [IKEV2]), while
achieved through the Next Header field of the security protocol identification of compressed header packets is achieved through the
(e.g., AH [AH], ESP [ESP]) header. Next Header field of the security protocol (e.g., Authentication
Header (AH) [AH], ESP [ESP]) header.
Using the ROHCoIPsec framework proposed below, outbound and inbound Using the ROHCoIPsec framework proposed below, outbound and inbound
IP traffic processing at an IPsec device needs to be modified. For IP traffic processing at an IPsec device needs to be modified. For
an outbound packet, a ROHCoIPsec implementation will compress an outbound packet, a ROHCoIPsec implementation will compress
appropriate packet headers, and subsequently encrypt and/or appropriate packet headers, and subsequently encrypt and/or integrity
integrity-protect the packet. For tunnel mode SAs, compression may protect the packet. For tunnel mode SAs, compression may be applied
be applied to the transport layer and the inner IP headers. For to the transport layer and the inner IP headers. For inbound
inbound packets, an IPsec device must first decrypt and/or integrity- packets, an IPsec device must first decrypt and/or integrity check
check the packet. Then decompression of the inner packet headers is the packet. Then, decompression of the inner packet headers is
performed. After decompression, the packet is checked against the performed. After decompression, the packet is checked against the
access controls imposed on all inbound traffic associated with the SA access controls imposed on all inbound traffic associated with the SA
(as specified in RFC 4301 [IPSEC]). (as specified in RFC 4301 [IPSEC]).
Note: Compression of inner headers is independent from compression Note: Compression of inner headers is independent from compression
of the security protocol (e.g., ESP) and outer IP headers. ROHC of the security protocol (e.g., ESP) and outer IP headers. ROHC
profiles have been defined to allow for the compression of the profiles have been defined to allow for the compression of the
security protocol and the outer IP header on a hop-by-hop basis. security protocol and the outer IP header on a hop-by-hop basis.
The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4 The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4
ESP-processed packet [ESP] is shown below in Figure 1. ESP-processed packet [ESP] is shown below in Figure 1.
----------------------------------------------------------- -----------------------------------------------------------
IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP| IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
----------------------------------------------------------- -----------------------------------------------------------
|<-------(1)------->|<------(2)-------->| |<-------(1)------->|<------(2)-------->|
(1) Compressed hop-by-hop by the ROHC [ROHC] ESP/IP profile (1) Compressed hop-by-hop by the ROHC [ROHC]
ESP/IP profile
(2) Compressed end-to-end by the ROHCoIPsec [IPSEC-ROHC] (2) Compressed end-to-end by the ROHCoIPsec [IPSEC-ROHC]
TCP/IP profile TCP/IP profile
Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an
IPv4 ESP-processed packet. IPv4 ESP-processed packet.
If IPsec NULL encryption is applied to packets, ROHC may still be If IPsec NULL encryption is applied to packets, ROHC may still be
used to compress the inner headers at IPsec SA endpoints. However, used to compress the inner headers at IPsec SA endpoints. However,
compression of these inner headers may pose challenges for compression of these inner headers may pose challenges for
intermediary devices (e.g., traffic monitors, sampling/management intermediary devices (e.g., traffic monitors, sampling/management
tools) that are inspecting the contents of ESP-NULL packets. For tools) that are inspecting the contents of ESP-NULL packets. For
example, policies on these devices may need to be updated to ensure example, policies on these devices may need to be updated to ensure
that packets that contain the ROHC protocol identifier are not that packets that contain the "ROHC" protocol identifier are not
dropped. In addition, intermediary devices may require additional dropped. In addition, intermediary devices may require additional
functionality to determine the content of the header compressed functionality to determine the content of the header compressed
packets. packets.
In certain scenarios, a ROHCoIPsec implementation may encounter UDP- In certain scenarios, a ROHCoIPsec implementation may encounter UDP-
encapsulated ESP or IKE packets (i.e., packets that are traversing encapsulated ESP or IKE packets (i.e., packets that are traversing
NATs). For example, a ROHCoIPsec implementation may receive a UDP- NATs). For example, a ROHCoIPsec implementation may receive a UDP-
encapsulated ESP packet that contains an ESP/UDP/IP header chain. encapsulated ESP packet that contains an ESP/UDP/IP header chain.
Currently, ROHC profiles do not support compression of the entire Currently, ROHC profiles do not support compression of the entire
header chain associated with this packet; only the UDP/IP headers can header chain associated with this packet; only the UDP/IP headers can
skipping to change at page 8, line 40 skipping to change at page 7, line 40
| | |-------------------------> Path 2 | | |-------------------------> Path 2
| | | (ROHC-enabled SA, | | | (ROHC-enabled SA,
| +-------------------------------+ but no compression) | +-------------------------------+ but no compression)
| |
| |
| |
| |
+-----------------------------------------> Path 3 +-----------------------------------------> Path 3
(ROHC-disabled SA) (ROHC-disabled SA)
Figure 2. Integration of ROHC with IPsec. Figure 2. Integration of ROHC with IPsec
The process illustrated in Figure 2 augments the IPsec processing The process illustrated in Figure 2 augments the IPsec processing
model for outbound IP traffic (protected-to-unprotected). Initial model for outbound IP traffic (protected-to-unprotected). Initial
IPsec processing is consistent with RFC 4301 [IPSEC] (Steps 1-2, IPsec processing is consistent with RFC 4301 [IPSEC] (Section 5.1,
Section 5.1). Steps 1-2).
Block A: The ROHC data item (part of the SA state information) Block A: The ROHC data item (part of the SA state information)
retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1, retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1,
Step3a) determines if the traffic traversing the SA is handed to the Step3a) determines if the traffic traversing the SA is handed to the
ROHC module. Packets selected to a ROHC-disabled SA MUST follow ROHC module. Packets selected to a ROHC-disabled SA MUST follow
normal IPsec processing and MUST NOT be sent to the ROHC module normal IPsec processing and MUST NOT be sent to the ROHC module
(Figure 2, Path 3). Conversely, packets selected to a ROHC-enabled (Figure 2, Path 3). Conversely, packets selected to a ROHC-enabled
SA MUST be sent to the ROHC module. SA MUST be sent to the ROHC module.
Block B: This step determines if the packet can be compressed. If Block B: This step determines if the packet can be compressed. If
the packet is compressed, an Integrity Algorithm MAY be used to the packet is compressed, an integrity algorithm MAY be used to
compute an Integrity Check Value (ICV) for the uncompressed packet compute an Integrity Check Value (ICV) for the uncompressed packet
([IPSEC-ROHC], Section 4.2; [IKE-ROHC], Section 3.1). The Next ([IPSEC-ROHC], Section 4.2; [IKE-ROHC], Section 3.1). The Next
Header field of the security protocol header (e.g., ESP, AH) MUST be Header field of the security protocol header (e.g., ESP, AH) MUST be
populated with a "ROHC" protocol number [PROTOCOL], inner packet populated with a "ROHC" protocol identifier [PROTOCOL], inner packet
headers MUST be compressed, and the computed ICV MAY be appended to headers MUST be compressed, and the computed ICV MAY be appended to
the packet (Figure 2, Path 1). However, if it is determined that the the packet (Figure 2, Path 1). However, if it is determined that the
packet will not be compressed (e.g., due to one the reasons described packet will not be compressed (e.g., due to one of the reasons
in Section 6.1.3), the Next Header field MUST be populated with the described in Section 6.1.3), the Next Header field MUST be populated
appropriate value indicating the next level protocol (Figure 2, Path with the appropriate value indicating the next-level protocol (Figure
2), and ROHC processing MUST NOT be applied to the packet. 2, Path 2), and ROHC processing MUST NOT be applied to the packet.
After the ROHC process completes, IPsec processing resumes, as After the ROHC process completes, IPsec processing resumes, as
described in Section 5.1, Step3a, of RFC 4301 [IPSEC]. described in Section 5.1, Step3a, of RFC 4301 [IPSEC].
The process illustrated in Figure 2 also augments the IPsec The process illustrated in Figure 2 also augments the IPsec
processing model for inbound IP traffic (unprotected-to-protected). processing model for inbound IP traffic (unprotected-to-protected).
For inbound packets, IPsec processing is performed ([IPSEC], Section For inbound packets, IPsec processing is performed ([IPSEC], Section
5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section
5.2, Step 4). 5.2, Step 4).
Block A: After AH or ESP processing, the ROHC data item retrieved Block A: After AH or ESP processing, the ROHC data item retrieved
from the SAD entry will indicate if traffic traversing the SA is from the SAD entry will indicate if traffic traversing the SA is
processed by the ROHC module ([IPSEC], Section 5.2, Step 3a). processed by the ROHC module ([IPSEC], Section 5.2, Step 3a).
Packets traversing a ROHC-disabled SA MUST follow normal IPsec Packets traversing a ROHC-disabled SA MUST follow normal IPsec
processing and MUST NOT be sent to the ROHC module. Conversely, processing and MUST NOT be sent to the ROHC module. Conversely,
packets traversing a ROHC-enabled SA MUST be sent to the ROHC module. packets traversing a ROHC-enabled SA MUST be sent to the ROHC module.
Block B: The decision at Block B is determined by the value of the Block B: The decision at Block B is made using the value of the Next
Next Header field of the security protocol header. If the Next Header field of the security protocol header. If the Next Header
Header field does not indicate a ROHC header, the decompressor MUST field does not indicate a ROHC header, the decompressor MUST NOT
NOT attempt decompression (Figure 2, Path 2). If the Next Header attempt decompression (Figure 2, Path 2). If the Next Header field
field indicates a ROHC header, decompression is applied. After indicates a ROHC header, decompression is applied. After
decompression, the signaled ROHCoIPsec Integrity Algorithm, MAY be decompression, the signaled ROHCoIPsec integrity algorithm MAY be
used to compute an ICV value for the decompressed packet. This ICV, used to compute an ICV value for the decompressed packet. This ICV,
if present, is compared to the ICV that was calculated at the if present, is compared to the ICV that was calculated at the
compressor: if the ICVs match, the packet is forwarded by the ROHC compressor. If the ICVs match, the packet is forwarded by the ROHC
module (Figure 2, Path 1); otherwise, the packet MUST be dropped. module (Figure 2, Path 1); otherwise, the packet MUST be dropped.
Once the ROHC module completes processing, IPsec processing resumes, Once the ROHC module completes processing, IPsec processing resumes,
as described in Section 5.2, Step 4 of RFC 4301 [IPSEC]. as described in Section 5.2, Step 4, of RFC 4301 [IPSEC].
When there is a single SA between a compressor and decompressor, ROHC When there is a single SA between a compressor and decompressor, ROHC
MUST operate in unidirectional mode, as described in Section 5 of RFC MUST operate in unidirectional mode, as described in Section 5 of RFC
3759 [ROHC-TERM]. When there is a pair of SAs instantiated between 3759 [ROHC-TERM]. When there is a pair of SAs instantiated between
ROHCoIPsec implementations, ROHC MAY operate in bidirectional mode, ROHCoIPsec implementations, ROHC MAY operate in bi-directional mode,
where an SA pair represents a bidirectional ROHC channel (as where an SA pair represents a bi-directional ROHC channel (as
described in Section 6.1 and 6.2 of RFC 3759[ROHC-TERM]). described in Sections 6.1 and 6.2 of RFC 3759 [ROHC-TERM]).
Note that to further reduce the size of an IPsec-protected packet, Note that to further reduce the size of an IPsec-protected packet,
ROHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested ROHCoIPsec and IPComp [IPCOMP] can be implemented in a nested
fashion. This process is detailed in [IPSEC-ROHC], Section 4.4. fashion. This process is detailed in [IPSEC-ROHC], Section 4.4.
6.1.1. Header Compression Protocol Considerations 6.1.1. Header Compression Protocol Considerations
ROHCv2 [ROHCV2] profiles include various mechanisms that provide ROHCv2 [ROHCV2] profiles include various mechanisms that provide
increased robustness over reordering channels. These mechanisms increased robustness over reordering channels. These mechanisms
SHOULD be adopted for ROHC to operate efficiently over IPsec SAs. SHOULD be adopted for ROHC to operate efficiently over IPsec SAs.
A ROHC decompressor implemented within IPsec architecture MAY A ROHC decompressor implemented within IPsec architecture MAY
leverage additional mechanisms to improve performance over reordering leverage additional mechanisms to improve performance over reordering
channels (either due to random events, or to an attacker channels (either due to random events or to an attacker intentionally
intentionally reordering packets). Specifically, IPsec's sequence reordering packets). Specifically, IPsec's sequence number MAY be
number MAY be used by the decompressor to identify a packet as used by the decompressor to identify a packet as "sequentially late".
"sequentially late". This knowledge will increase the likelihood of This knowledge will increase the likelihood of successful
successful decompression of a reordered packet. decompression of a reordered packet.
Additionally, ROHCoIPsec implementations SHOULD minimize the amount Additionally, ROHCoIPsec implementations SHOULD minimize the amount
of feedback sent from the decompressor to the compressor. If a ROHC of feedback sent from the decompressor to the compressor. If a ROHC
feedback channel is not used sparingly, the overall gains from feedback channel is not used sparingly, the overall gains from
ROHCoIPsec can be significantly reduced. More specifically, any ROHCoIPsec can be significantly reduced. More specifically, any
feedback sent from the decompressor to the compressor MUST be feedback sent from the decompressor to the compressor MUST be
processed by IPsec, and tunneled back to the compressor (as processed by IPsec and tunneled back to the compressor (as designated
designated by the SA associated with FEEDBACK_FOR). As such, some by the SA associated with FEEDBACK_FOR). As such, some
implementation alternatives can be considered, including the implementation alternatives can be considered, including the
following: following:
o Eliminate feedback traffic altogether by operating only in ROHC o Eliminate feedback traffic altogether by operating only in ROHC
Unidirectional mode (U-mode) Unidirectional mode (U-mode).
o Piggyback ROHC feedback messages within the feedback element o Piggyback ROHC feedback messages within the feedback element
(i.e., on ROHC traffic that normally traverses the SA designated (i.e., on ROHC traffic that normally traverses the SA designated
by FEEDBACK_FOR). by FEEDBACK_FOR).
6.1.2. Initialization and Negotiation of the ROHC Channel 6.1.2. Initialization and Negotiation of the ROHC Channel
Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP)
to negotiate ROHC channel parameters. In the case of ROHCoIPsec, to negotiate ROHC channel parameters. In the case of ROHCoIPsec,
channel parameters can be set manually (i.e., administratively channel parameters can be set manually (i.e., administratively
configured for manual SAs), or negotiated by IKEv2. The extensions configured for manual SAs) or negotiated by IKEv2. The extensions
required for IKEv2 to support ROHC channel parameter negotiation are required for IKEv2 to support ROHC channel parameter negotiation are
detailed in [IKE-ROHC]. detailed in [IKE-ROHC].
If the ROHC protocol requires bidirectional communications, two SAs If the ROHC protocol requires bi-directional communications, two SAs
MUST be instantiated between the IPsec implementations. One of the MUST be instantiated between the IPsec implementations. One of the
two SAs is used for carrying ROHC-traffic from the compressor to the two SAs is used for carrying ROHC-traffic from the compressor to the
decompressor, while the other is used to communicate ROHC-feedback decompressor, while the other is used to communicate ROHC-feedback
from the decompressor to the compressor. Note that the requirement from the decompressor to the compressor. Note that the requirement
for two SAs aligns with the operation of IKE, which creates SAs in for two SAs aligns with the operation of IKE, which creates SAs in
pairs by default. However, IPsec implementations will dictate how pairs by default. However, IPsec implementations will dictate how
decompressor feedback received on one SA is associated with a decompressor feedback received on one SA is associated with a
compressor on the other SA. An IPsec implementation MUST relay the compressor on the other SA. An IPsec implementation MUST relay the
feedback received by the decompressor on an inbound SA to the feedback received by the decompressor on an inbound SA to the
compressor associated with the corresponding outbound SA. compressor associated with the corresponding outbound SA.
6.1.3. Encapsulation and Identification of Header Compressed Packets 6.1.3. Encapsulation and Identification of Header Compressed Packets
As indicated in Section 6.1, new state information (i.e., a new ROHC As indicated in Section 6.1, new state information (i.e., a new ROHC
data item) is defined for each SA. The ROHC data item MUST be used data item) is defined for each SA. The ROHC data item MUST be used
by the IPsec process to determine whether it sends all traffic by the IPsec process to determine whether it sends all traffic
traversing a given SA to the ROHC module (ROHC-enabled) or bypasses traversing a given SA to the ROHC module (ROHC-enabled) or bypasses
the ROHC module and sends the traffic through regular IPsec the ROHC module and sends the traffic through regular IPsec
processing (ROHC- disabled). processing (ROHC-disabled).
The Next Header field of the IPsec security protocol (e.g., AH or The Next Header field of the IPsec security protocol (e.g., AH or
ESP) header MUST be used to demultiplex header-compressed traffic ESP) header MUST be used to demultiplex header-compressed traffic
from uncompressed traffic traversing an ROHC-enabled SA. This from uncompressed traffic traversing a ROHC-enabled SA. This
functionality is needed in situations where packets traversing a functionality is needed in situations where packets traversing a
ROHC-enabled SA contain uncompressed headers. Such situations may ROHC-enabled SA contain uncompressed headers. Such situations may
occur when, for example, a compressor supports strictly n compressed occur when, for example, a compressor only supports up to n
flows and cannot compress the n+1 flow that arrives. Another example compressed flows and cannot compress a flow number n+1 that arrives.
is when traffic is selected to a ROHC-enabled SA, but cannot be Another example is when traffic is selected to a ROHC-enabled SA, but
compressed by the ROHC process because the appropriate ROHC Profile cannot be compressed by the ROHC process because the appropriate ROHC
has not been signaled for use. As a result, the decompressor MUST be Profile has not been signaled for use. As a result, the decompressor
able to identify packets with uncompressed headers and MUST NOT MUST be able to identify packets with uncompressed headers and MUST
attempt to decompress them. The Next Header field is used to NOT attempt to decompress them. The Next Header field is used to
demultiplex these header-compressed and uncompressed packets where demultiplex these header-compressed and uncompressed packets where
the ROHC protocol number will indicate that the packet contains the "ROHC" protocol identifier will indicate that the packet contains
compressed headers. To accomplish this, an official IANA allocation compressed headers. To accomplish this, IANA has allocated value 142
from the Protocol ID registry [PROTOCOL] is required. to "ROHC" from the Protocol ID registry [PROTOCOL].
It is noted that the use of the ROHC protocol identifier for purposes It is noted that the use of the "ROHC" protocol identifier for
other than ROHCoIPsec is currently not defined. In other words, the purposes other than ROHCoIPsec is currently not defined. In other
ROHC protocol identifier is only defined for use in the next header words, the "ROHC" protocol identifier is only defined for use in the
field of security protocol headers (e.g., ESP, AH). Next Header field of security protocol headers (e.g., ESP, AH).
The ROHC Data Item, IANA Protocol ID allocation, and other IPsec The ROHC Data Item, IANA Protocol ID allocation, and other IPsec
extensions to support ROHCoIPsec, are specified in [IPSEC-ROHC]. extensions to support ROHCoIPsec are specified in [IPSEC-ROHC].
6.1.4. Motivation for the ROHC ICV 6.1.4. Motivation for the ROHC ICV
Although ROHC was designed to tolerate packet loss and reordering, Although ROHC was designed to tolerate packet loss and reordering,
the algorithm does not guarantee that packets reconstructed at the the algorithm does not guarantee that packets reconstructed at the
decompressor are identical to the original packet. As stated in decompressor are identical to the original packet. As stated in
Section 5.2 of RFC 4224 [REORDR], the consequences of packet Section 5.2 of RFC 4224 [REORDR], the consequences of packet
reordering between ROHC peers may include undetected decompression reordering between ROHC peers may include undetected decompression
failures, where erroneous packets are constructed and forwarded to failures, where erroneous packets are constructed and forwarded to
upper layers. Significant packet loss can have similar consequences. upper layers. Significant packet loss can have similar consequences.
When using IPsec integrity protection, a packet received at the When using IPsec integrity protection, a packet received at the
egress of an IPsec tunnel is identical to the packet that was egress of an IPsec tunnel is identical to the packet that was
processed at the ingress (given that the key is not compromised, processed at the ingress (given that the key is not compromised,
etc.). etc.).
When ROHC is integrated into the IPsec processing framework, the ROHC When ROHC is integrated into the IPsec processing framework, the ROHC
processed packet is protected by the AH/ESP ICV. However, bits in processed packet is protected by the AH/ESP ICV. However, bits in
the original IP header are not protected by this ICV, only by ROHC's the original IP header are not protected by this ICV; they are
integrity mechanisms (which are designed for random packet loss/ protected only by ROHC's integrity mechanisms (which are designed for
reordering, not malicious packet loss/reordering introduced by an random packet loss/reordering, not malicious packet loss/reordering
attacker). Therefore, under certain circumstances, erroneous packets introduced by an attacker). Therefore, under certain circumstances,
may be constructed and forwarded into the protected domain. erroneous packets may be constructed and forwarded into the protected
domain.
To ensure the integrity of the original IP header within the To ensure the integrity of the original IP header within the
ROHCoIPsec-processing model, an additional integrity check MAY be ROHCoIPsec-processing model, an additional integrity check MAY be
applied before the packet is compressed. This integrity check will applied before the packet is compressed. This integrity check will
ensure that erroneous packets are not forwarded into the protected ensure that erroneous packets are not forwarded into the protected
domain. The specifics of this integrity check are documented in domain. The specifics of this integrity check are documented in
Section 4.2 of [IPSEC-ROHC]. Section 4.2 of [IPSEC-ROHC].
6.1.5. Path MTU Considerations 6.1.5. Path MTU Considerations
By encapsulating IP packets with AH/ESP and tunneling IP headers, By encapsulating IP packets with AH/ESP and tunneling IP headers,
IPsec increases the size of IP packets. This increase may result in IPsec increases the size of IP packets. This increase may result in
Path MTU issues in the unprotected domain. Several approaches to Path MTU issues in the unprotected domain. Several approaches to
resolving these path MTU issues are documented in Section 8 of RFC resolving these path MTU issues are documented in Section 8 of RFC
4301[IPSEC]; approaches include fragmenting the packet before or 4301 [IPSEC]; approaches include fragmenting the packet before or
after IPsec processing (if the packet's DF bit is clear), or possibly after IPsec processing (if the packet's Don't Fragment (DF) bit is
discarding packets (if the packet's DF bit is set). clear), or possibly discarding packets (if the packet's DF bit is
set).
The addition of ROHC within the IPsec processing model may result in The addition of ROHC within the IPsec processing model may result in
a similar path MTU challenges. For example, under certain similar path MTU challenges. For example, under certain
circumstances, ROHC headers are larger than the original uncompressed circumstances, ROHC headers are larger than the original uncompressed
headers. In addition, if an integrity algorithm is used to validate headers. In addition, if an integrity algorithm is used to validate
packet headers, the resulting ICV will increase the size of packets. packet headers, the resulting ICV will increase the size of packets.
Both of these properties of ROHCoIPsec increase the size of packets, Both of these properties of ROHCoIPsec increase the size of packets,
and therefore may result in additional challenges associated with and therefore may result in additional challenges associated with
path MTU. path MTU.
Approaches to addressing these path MTU issues are specified in Approaches to addressing these path MTU issues are specified in
Section 4.3 of [IPSEC-ROHC]. Section 4.3 of [IPSEC-ROHC].
skipping to change at page 13, line 11 skipping to change at page 12, line 13
Both of these properties of ROHCoIPsec increase the size of packets, Both of these properties of ROHCoIPsec increase the size of packets,
and therefore may result in additional challenges associated with and therefore may result in additional challenges associated with
path MTU. path MTU.
Approaches to addressing these path MTU issues are specified in Approaches to addressing these path MTU issues are specified in
Section 4.3 of [IPSEC-ROHC]. Section 4.3 of [IPSEC-ROHC].
6.2. ROHCoIPsec Framework Summary 6.2. ROHCoIPsec Framework Summary
To summarize, the following items are needed to achieve ROHCoIPsec: To summarize, the following items are needed to achieve ROHCoIPsec:
o IKEv2 Extensions to Support ROHCoIPsec o IKEv2 Extensions to Support ROHCoIPsec
o IPsec Extensions to Support ROHCoIPsec o IPsec Extensions to Support ROHCoIPsec
7. Security Considerations 7. Security Considerations
Several security considerations associated with the use of ROHCoIPsec Several security considerations associated with the use of ROHCoIPsec
are covered in Section 6.1.4. These considerations can be mitigated are covered in Section 6.1.4. These considerations can be mitigated
by using strong a integrity check algorithm to ensure the valid by using a strong integrity-check algorithm to ensure the valid
decompression of packet headers. decompression of packet headers.
A malfunctioning or malicious ROHCoIPsec compressor (i.e., the A malfunctioning or malicious ROHCoIPsec compressor (i.e., the
compressor located at the ingress of the IPsec tunnel) has the compressor located at the ingress of the IPsec tunnel) has the
ability to send erroneous packets to the decompressor (i.e., the ability to send erroneous packets to the decompressor (i.e., the
decompressor located at the egress of the IPsec tunnel) that do not decompressor located at the egress of the IPsec tunnel) that do not
match the original packets emitted from the end-hosts. Such a match the original packets emitted from the end-hosts. Such a
scenario may result in decreased efficiency between compressor and scenario may result in decreased efficiency between compressor and
decompressor, or may cause the decompressor to forward erroneous decompressor, or may cause the decompressor to forward erroneous
packets into the protected domain. A malicious compressor could also packets into the protected domain. A malicious compressor could also
skipping to change at page 13, line 46 skipping to change at page 12, line 50
simply discard a subset of (or all) the packets that are received, simply discard a subset of (or all) the packets that are received,
even if packet headers were validly decompressed. Ultimately, this even if packet headers were validly decompressed. Ultimately, this
could result in denial of service. A malicious decompressor could could result in denial of service. A malicious decompressor could
also intentionally indicate that its context is not synchronized with also intentionally indicate that its context is not synchronized with
the compressor's context, forcing the compressor to transition to a the compressor's context, forcing the compressor to transition to a
lower compression state. This will reduce the overall efficiency lower compression state. This will reduce the overall efficiency
gain offered by ROHCoIPsec. gain offered by ROHCoIPsec.
8. IANA Considerations 8. IANA Considerations
This draft has no IANA considerations. All IANA considerations for All IANA considerations for ROHCoIPsec are documented in [IKE-ROHC]
ROHCoIPsec are documented in [IKE-ROHC] and [IPSEC-ROHC]. and [IPSEC-ROHC].
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, The authors would like to thank Sean O'Keeffe, James Kohler, and
and Ms. Linda Noone of the Department of Defense, and well as Mr. Linda Noone of the Department of Defense, as well as Rich Espy of
Rich Espy of OPnet for their contributions and support in the OPnet for their contributions and support in the development of this
development of this document. document.
The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A The authors would also like to thank Yoav Nir and Robert A Stangarone
Stangarone Jr.: both served as committed document reviewers for this Jr.: both served as committed document reviewers for this
specification. specification.
In addition, the authors would like to thank the following for their In addition, the authors would like to thank the following for their
numerous reviews and comments to this document: numerous reviews and comments to this document:
o Mr. Magnus Westerlund o Magnus Westerlund
o Dr. Stephen Kent
o Mr. Pasi Eronen
o Dr. Joseph Touch
o Mr. Tero Kivinen
o Dr. Jonah Pezeshki
o Mr. Lars-Erik Jonsson
o Mr. Jan Vilhuber
o Mr. Dan Wing
o Mr. Kristopher Sandlund
o Mr. Ghyslain Pelletier
o Mr. David Black
o Mr. Tim Polk
o Mr. Brian Carpenter
Finally, the authors would also like to thank Mr. Tom Conkle, Ms. o Stephen Kent
Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen
Hamilton for their assistance in completing this work. o Pasi Eronen
o Joseph Touch
o Tero Kivinen
o Jonah Pezeshki
o Lars-Erik Jonsson
o Jan Vilhuber
o Dan Wing
o Kristopher Sandlund
o Ghyslain Pelletier
o David Black
o Tim Polk
o Brian Carpenter
Finally, the authors would also like to thank Tom Conkle, Renee
Esposito, Etzel Brower, and Michele Casey of Booz Allen Hamilton for
their assistance in completing this work.
10. Informative References 10. Informative References
[ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust [ROHC] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The
Header Compression (ROHC) Framework", RFC 4995, July 2007. RObust Header Compression (ROHC) Framework", RFC 5795,
March 2010.
[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.
[ROHC-TERM] [ROHC-TERM] Jonsson, L-E., "Robust Header Compression (ROHC):
Jonsson, L-E., "Robust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759,
Terminology and Channel Mapping Examples", RFC 3759, April 2004.
April 2004.
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate [BRA97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[AH] Kent, S., "IP Authentication Header", RFC 4302, [AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[IPSEC-ROHC] [IPSEC-ROHC] Ertekin, E., Christou, C., and C. Bormann, "IPsec
Ertekin, E., Christou, C., and C. Bormann, "IPsec Extensions to Support Robust Header Compression over
Extensions to Support ROHCoIPsec", work in progress , IPsec", RFC 5858, May 2010.
February 2010.
[IKE-ROHC] [IKE-ROHC] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and
Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. C. Bormann, "IKEv2 Extensions to Support Robust Header
Bormann, "IKEv2 Extensions to Support ROHCoIPsec", work in Compression over IPsec", RFC 5857, May 2010.
progress , February 2010.
[PROTOCOL] [PROTOCOL] IANA, "Assigned Internet Protocol Numbers",
IANA, "Assigned Internet Protocol Numbers, IANA registry <http://www.iana.org>.
at: http://www.iana.org/assignments/protocol-numbers",
June 2009.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
Compression Protocol (IPComp)", RFC 3173, September 2001. "IP Payload Compression Protocol (IPComp)", RFC 3173,
September 2001.
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Compression Version 2 (ROHCv2): Profiles for RTP, UDP,
Lite", RFC 5225, April 2008. IP, ESP and UDP-Lite", RFC 5225, April 2008.
[REORDR] Pelletier, G., Jonsson, L-E., and K. Sandlund, "Robust [REORDR] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
Header Compression (ROHC): ROHC over Channels That Can Header Compression (ROHC): ROHC over Channels That Can
Reorder Packets", RFC 4224, January 2006. Reorder Packets", RFC 4224, January 2006.
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
5220 Pacific Concourse Drive, Suite 200 5220 Pacific Concourse Drive, Suite 200
Los Angeles, CA 90045 Los Angeles, CA 90045
US US
Email: ertekin_emre@bah.com EMail: ertekin_emre@bah.com
Rohan Jasani Rohan Jasani
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: ro@breakcheck.com EMail: ro@breakcheck.com
Chris Christou Chris Christou
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: christou_chris@bah.com EMail: christou_chris@bah.com
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28334 Bremen D-28334
Germany Germany
Email: cabo@tzi.org EMail: cabo@tzi.org
 End of changes. 74 change blocks. 
208 lines changed or deleted 222 lines changed or added

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