draft-ietf-rohc-hcoipsec-10.txt   draft-ietf-rohc-hcoipsec-11.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: August 6, 2009 Booz Allen Hamilton Expires: February 13, 2010 Booz Allen Hamilton
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
February 2, 2009 August 12, 2009
Integration of Robust Header Compression (ROHC) over IPsec Security Integration of Robust Header Compression (ROHC) over IPsec Security
Associations Associations
draft-ietf-rohc-hcoipsec-10 draft-ietf-rohc-hcoipsec-11
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 6, 2009. This Internet-Draft will expire on February 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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).
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 . . . . . . . . . . . 7
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.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 6.1.4. Path MTU Considerations . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . 10 6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 12
10. Informative References . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 10. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14
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 49 skipping to change at page 8, line 49
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 1, Path 3). Conversely, packets selected to a ROHC-enabled (Figure 1, 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 it Block B: This step determines if the packet can be compressed. If it
is determined that the packet will be compressed, an Integrity is determined that the packet will be compressed, an Integrity
Algorithm may be used to compute an Integrity Check Value (ICV) for Algorithm may be used to compute an Integrity Check Value (ICV) for
the uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], the uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC],
Section 2.1). The Next Header field of the security protocol header Section 2.1). The Next Header field of the security protocol header
(e.g., ESP, AH) is populated with a "ROHC" identifier, inner packet (e.g., ESP, AH) is populated with a "ROHC" protocol number
headers are compressed, and the computed ICV is appended to the [PROTOCOL], inner packet headers are compressed, and the computed
packet (Figure 1, Path 1). However, if it is determined that the ICV, if present, is appended to the packet (Figure 1, Path 1).
packet will not be compressed (e.g., due to one the reasons described
in Section 6.1.3), the Next Header field is populated with the However, if it is determined that the packet will not be compressed
appropriate value indicating the next level protocol (Figure 1, Path (e.g., due to one the reasons described in Section 6.1.3), the Next
2). Header field is populated with the appropriate value indicating the
next level protocol (Figure 1, Path 2), and no ROHC processing is
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 [IPSEC]. described in Section 5.1, Step3a, of [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).
skipping to change at page 8, line 31 skipping to change at page 9, line 33
Packets traversing an ROHC-disabled SA must follow normal IPsec Packets traversing an 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 an ROHC-enabled SA must be sent to the ROHC packets traversing an ROHC-enabled SA must be sent to the ROHC
module. module.
Block B: The decision at Block B is determined by the value of the Block B: The decision at Block B is determined by the value of the
Next Header field of the security protocol header. If the Next Next Header field of the security protocol header. If the Next
Header field does not indicate a ROHC header, the decompressor must Header field does not indicate a ROHC header, the decompressor must
not attempt decompression (Figure 1, Path 2). If the Next Header not attempt decompression (Figure 1, Path 2). If the Next Header
field indicates a ROHC header, decompression is applied. After field indicates a ROHC header, decompression is applied. After
decompression, the signaled ROHCoIPsec Integrity Algorithm is used to decompression, the signaled ROHCoIPsec Integrity Algorithm, if
compute an ICV value for the decompressed packet. This ICV is present, is used to compute an ICV value for the decompressed packet.
compared to the ICV that was calculated at the compressor: if the This ICV, if present, is compared to the ICV that was calculated at
ICVs match, the packet is forwarded by the ROHC module (Figure 1, the compressor: if the ICVs match, the packet is forwarded by the
Path 1); otherwise, the packet is dropped. Once the ROHC module ROHC module (Figure 1, Path 1); otherwise, the packet is dropped.
completes processing, IPsec processing resumes, as described in Once the ROHC module completes processing, IPsec processing resumes,
Section 5.2, Step 4 of [IPSEC]. as described in Section 5.2, Step 4 of [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
operates in unidirectional mode, as described in Section 5 of [ROHC- operates in unidirectional mode, as described in Section 5 of [ROHC-
TERM]. When there is pair of SAs instantiated between ROHCoIPsec TERM]. When there is pair of SAs instantiated between ROHCoIPsec
implementations, ROHC may operate in bidirectional mode, where an SA implementations, ROHC may operate in bidirectional mode, where an SA
pair represents a bidirectional ROHC channel (as described in Section pair represents a bidirectional ROHC channel (as described in Section
6.1 and 6.2 of [ROHC-TERM]). 6.1 and 6.2 of [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
skipping to change at page 9, line 30 skipping to change at page 10, line 30
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 by the SA associated with FEEDBACK_FOR). As such, some designated 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 on traffic that normally o Piggyback ROHC feedback messages within the feedback element
traverses the SA designated by FEEDBACK_FOR. (i.e., on ROHC traffic that normally traverses the SA designated
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].
skipping to change at page 10, line 27 skipping to change at page 11, line 28
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 supports strictly n compressed
flows and cannot compress the n+1 flow that arrives. Another example flows and cannot compress the n+1 flow that arrives. Another example
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 not attempt to able to identify packets with uncompressed headers and not attempt to
decompress them. The Next Header field is used to demultiplex these decompress them. The Next Header field is used to demultiplex these
header-compressed and uncompressed packets where the ROHC protocol header-compressed and uncompressed packets where the ROHC protocol
identifier will indicate that the packet contains compressed headers. number will indicate that the packet contains compressed headers. To
To accomplish this, an official IANA allocation from the Protocol ID accomplish this, an official IANA allocation from the Protocol ID
registry [PROTOCOL] is required. registry [PROTOCOL] is required.
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. Path MTU Considerations
By encapsulating IP packets with AH/ESP and tunneling IP headers,
IPsec increases the size of IP packets. This increase may result in
Path MTU issues in the unprotected domain. Several approaches to
resolving these path MTU issues are documented in Section 8 of
[IPSEC]; approaches include fragmenting the packet before or after
IPsec processing (if the packet's DF bit is 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
a similar path MTU challenges. For example, under certain
circumstances, ROHC headers are larger than the original uncompressed
headers. In addition, if an integrity algorithm is used to validate
packet headers post-decompression, this integrity algorithm will
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 path MTU.
Approaches to addressing these ROHCoIPsec path MTU issues are
specified in Section 3.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 A malfunctioning ROHC compressor (i.e., the compressor located at the
ingress of the IPsec tunnel) has the ability to send packets to the ingress of the IPsec tunnel) has the ability to send packets to the
skipping to change at page 11, line 23 skipping to change at page 12, line 44
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
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 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
skipping to change at page 12, line 24 skipping to change at page 13, line 49
[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
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP
Lite", RFC 5225, April 2008. Lite", RFC 5225, April 2008.
[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 , February 2009. progress , August 2009.
[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".
[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 ,
February 2009. August 2009.
Authors' Addresses Authors' Addresses
Emre Ertekin Emre Ertekin
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: ertekin_emre@bah.com Email: ertekin_emre@bah.com
skipping to change at page 13, line 4 skipping to change at page 14, line 23
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
Rohan Jasani Rohan Jasani
Booz Allen Hamilton Booz Allen Hamilton
13200 Woodland Park Dr. 13200 Woodland Park Dr.
Herndon, VA 20171 Herndon, VA 20171
US US
Email: jasani_rohan@bah.com Email: 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
 End of changes. 19 change blocks. 
50 lines changed or deleted 86 lines changed or added

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