draft-ietf-rohc-hcoipsec-12.txt   draft-ietf-rohc-hcoipsec-13.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft R. Jasani Internet-Draft R. Jasani
Intended status: Informational C. Christou Intended status: Informational C. Christou
Expires: June 7, 2010 Booz Allen Hamilton Expires: August 6, 2010 Booz Allen Hamilton
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
December 4, 2009 February 2, 2010
Integration of Robust Header Compression (ROHC) over IPsec Security Integration of Robust Header Compression over IPsec Security
Associations Associations
draft-ietf-rohc-hcoipsec-12 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).
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 June 7, 2010. This Internet-Draft will expire on August 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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 . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 5
5. Overview of the ROHCoIPsec Framework . . . . . . . . . . . 5 5. Overview of the ROHCoIPsec Framework . . . . . . . . . . . 6
5.1. ROHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5 5.1. ROHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 6
5.2. Summary of the ROHCoIPsec Framework . . . . . . . . . . . 5 5.2. Summary of the ROHCoIPsec Framework . . . . . . . . . . . 6
6. Details of the ROHCoIPsec Framework . . . . . . . . . . . 6 6. Details of the ROHCoIPsec Framework . . . . . . . . . . . 8
6.1. ROHC and IPsec Integration . . . . . . . . . . . . . . . . 7 6.1. ROHC and IPsec Integration . . . . . . . . . . . . . . . . 8
6.1.1. Header Compression Protocol Considerations . . . . . . . . 9 6.1.1. Header Compression Protocol Considerations . . . . . . . . 10
6.1.2. Initialization and Negotiation of the ROHC Channel . . . . 9 6.1.2. Initialization and Negotiation of the ROHC Channel . . . . 10
6.1.3. Encapsulation and Identification of Header Compressed 6.1.3. Encapsulation and Identification of Header Compressed
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 10 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1.4. Motivation for the ROHC ICV . . . . . . . . . . . . . . . 10 6.1.4. Motivation for the ROHC ICV . . . . . . . . . . . . . . . 12
6.1.5. Path MTU Considerations . . . . . . . . . . . . . . . . . 11 6.1.5. Path MTU Considerations . . . . . . . . . . . . . . . . . 12
6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 11 6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . 12 10. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13 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.
skipping to change at page 7, line 40 skipping to change at page 7, line 40
|<-------(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
applied to the inner headers at the IPsec SA endpoints. However, used to compress the inner headers at IPsec SA endpoints. However,
this poses challenges for intermediary devices (within the compression of these inner headers may pose challenges for
unprotected domain) inspecting ESP-NULL encrypted packets, since intermediary devices (e.g., traffic monitors, sampling/management
these intermediary devices will require additional functionality to tools) that are inspecting the contents of ESP-NULL packets. For
determine the content of the ROHC packets. example, policies on these devices may need to be updated to ensure
that packets that contain the ROHC protocol identifier are not
dropped. In addition, intermediary devices may require additional
functionality to determine the content of the header compressed
packets.
In certain scenarios, a ROHCoIPsec implementation may encounter UDP-
encapsulated ESP or IKE packets (i.e., packets that are traversing
NATs). For example, a ROHCoIPsec implementation may receive a UDP-
encapsulated ESP packet that contains an ESP/UDP/IP header chain.
Currently, ROHC profiles do not support compression of the entire
header chain associated with this packet; only the UDP/IP headers can
be compressed.
6. Details of the ROHCoIPsec Framework 6. Details of the ROHCoIPsec Framework
6.1. ROHC and IPsec Integration 6.1. ROHC and IPsec Integration
Figure 2 illustrates the components required to integrate ROHC with Figure 2 illustrates the components required to integrate ROHC with
the IPsec process, i.e., ROHCoIPsec. the IPsec process, i.e., ROHCoIPsec.
+-------------------------------+ +-------------------------------+
| ROHC Module | | ROHC Module |
| | | |
| | | |
+-----+ | +-----+ +---------+ | +-----+ | +-----+ +---------+ |
skipping to change at page 11, line 32 skipping to change at page 11, line 41
is when traffic is selected to a ROHC-enabled SA, but cannot be is when traffic is selected to a ROHC-enabled SA, but cannot be
compressed by the ROHC process because the appropriate ROHC Profile compressed by the ROHC process because the appropriate ROHC Profile
has not been signaled for use. As a result, the decompressor MUST be has not been signaled for use. As a result, the decompressor MUST be
able to identify packets with uncompressed headers and MUST NOT able to identify packets with uncompressed headers and MUST NOT
attempt to decompress them. The Next Header field is used to 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 number will indicate that the packet contains
compressed headers. To accomplish this, an official IANA allocation compressed headers. To accomplish this, an official IANA allocation
from the Protocol ID registry [PROTOCOL] is required. from the Protocol ID registry [PROTOCOL] is required.
It is noted that the use of the ROHC protocol identifier for purposes
other than ROHCoIPsec is currently not defined. In other words, the
ROHC protocol identifier is only defined for use in the 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. 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. Therefore, the original IP header are not protected by this ICV, only by ROHC's
under certain circumstances, erroneous packets may be constructed and integrity mechanisms (which are designed for random packet loss/
forwarded into the protected domain. reordering, not malicious packet loss/reordering introduced by an
attacker). Therefore, under certain circumstances, 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
skipping to change at page 12, line 45 skipping to change at page 13, line 16
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
A malfunctioning ROHC compressor (i.e., the compressor located at the Several security considerations associated with the use of ROHCoIPsec
ingress of the IPsec tunnel) has the ability to send packets to the are covered in Section 6.1.4. These considerations can be mitigated
decompressor (i.e., the decompressor located at the egress of the by using strong a integrity check algorithm to ensure the valid
IPsec tunnel) that do not match the original packets emitted from the decompression of packet headers.
end-hosts. Such a scenario will result in decreased efficiency
between compressor and decompressor. Furthermore, this may result in A malfunctioning or malicious ROHCoIPsec compressor (i.e., the
Denial of Service, as the decompression of a significant number of compressor located at the ingress of the IPsec tunnel) has the
invalid packets may drain the resources of an IPsec device. ability to send erroneous packets to the decompressor (i.e., the
decompressor located at the egress of the IPsec tunnel) that do not
match the original packets emitted from the end-hosts. Such a
scenario may result in decreased efficiency between compressor and
decompressor, or may cause the decompressor to forward erroneous
packets into the protected domain. A malicious compressor could also
intentionally generate a significant number of compressed packets,
which may result in denial of service at the decompressor, as the
decompression of a significant number of invalid packets may drain
the resources of an IPsec device.
A malfunctioning or malicious ROHCoIPsec decompressor has the ability
to disrupt communications as well. For example, a decompressor may
simply discard a subset of (or all) the packets that are received,
even if packet headers were validly decompressed. Ultimately, this
could result in denial of service. A malicious decompressor could
also intentionally indicate that its context is not synchronized with
the compressor's context, forcing the compressor to transition to a
lower compression state. This will reduce the overall efficiency
gain offered by ROHCoIPsec.
8. IANA Considerations 8. IANA Considerations
None. This draft has no IANA considerations. All IANA considerations for
ROHCoIPsec are documented in [IKE-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 Mr. Sean O'Keeffe, Mr. James Kohler,
and Ms. Linda Noone of the Department of Defense, and well as Mr. and Ms. Linda Noone of the Department of Defense, and well as Mr.
Rich Espy of OPnet for their contributions and support in the Rich Espy of OPnet for their contributions and support in the
development of this document. development of this document.
The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A
Stangarone Jr.: both served as committed document reviewers for this Stangarone Jr.: both served as committed document reviewers for this
skipping to change at page 13, line 36 skipping to change at page 14, line 30
o Dr. Stephen Kent o Dr. Stephen Kent
o Mr. Pasi Eronen o Mr. Pasi Eronen
o Dr. Joseph Touch o Dr. Joseph Touch
o Mr. Tero Kivinen o Mr. Tero Kivinen
o Dr. Jonah Pezeshki o Dr. Jonah Pezeshki
o Mr. Lars-Erik Jonsson o Mr. Lars-Erik Jonsson
o Mr. Jan Vilhuber o Mr. Jan Vilhuber
o Mr. Dan Wing o Mr. Dan Wing
o Mr. Kristopher Sandlund o Mr. Kristopher Sandlund
o Mr. Ghyslain Pelletier 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. Finally, the authors would also like to thank Mr. Tom Conkle, Ms.
Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen
Hamilton for their assistance in completing this work. 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] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust
Header Compression (ROHC) Framework", RFC 4995, July 2007. Header Compression (ROHC) Framework", RFC 4995, July 2007.
skipping to change at page 14, line 25 skipping to change at page 15, line 18
[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 ROHCoIPsec", work in progress , Extensions to Support ROHCoIPsec", work in progress ,
December 2009. February 2010.
[IKE-ROHC] [IKE-ROHC]
Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
Bormann, "IKEv2 Extensions to Support ROHCoIPsec", work in Bormann, "IKEv2 Extensions to Support ROHCoIPsec", work in
progress , December 2009. progress , February 2010.
[PROTOCOL] [PROTOCOL]
IANA, "Assigned Internet Protocol Numbers, IANA registry IANA, "Assigned Internet Protocol Numbers, IANA registry
at: http://www.iana.org/assignments/protocol-numbers", at: http://www.iana.org/assignments/protocol-numbers",
June 2009. June 2009.
[IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 3173, September 2001. Compression Protocol (IPComp)", RFC 3173, September 2001.
[ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression
 End of changes. 18 change blocks. 
46 lines changed or deleted 89 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/