draft-ietf-rohc-hcoipsec-05.txt   draft-ietf-rohc-hcoipsec-06.txt 
Network Working Group E. Ertekin Network Working Group E. Ertekin
Internet-Draft C. Christou Internet-Draft C. Christou
Intended status: Informational R. Jasani Intended status: Informational R. Jasani
Expires: December 3, 2007 Booz Allen Hamilton Expires: February 28, 2008 J. Pezeshki
June 1, 2007 Booz Allen Hamilton
August 27, 2007
Integration of Robust Header Compression (RoHC) over IPsec Security Integration of Robust Header Compression (RoHC) over IPsec Security
Associations Associations
draft-ietf-rohc-hcoipsec-05 draft-ietf-rohc-hcoipsec-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 37
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 December 3, 2007. This Internet-Draft will expire on February 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 2, line 24 skipping to change at page 2, line 25
5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5 5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5
6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6 6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6
6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6 6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6
6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8
6.1.2. Initialization and Negotiation of the RoHC Channel . . . . 9 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 Compressed
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11
10. Informative References . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . 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 8, line 20 skipping to change at page 8, line 20
module. The decision at block B is determined by the value of the module. The decision at block B is determined by the value of the
Next Header field of the security protocol header. If a RoHC header Next Header field of the security protocol header. If a RoHC header
is indicated, decompression is applied (Figure 1, Path 1). However, is indicated, decompression is applied (Figure 1, Path 1). However,
if the Next Header field does not indicate a RoHC header, the if the Next Header field does not indicate a RoHC header, the
decompressor must not attempt decompression (Figure 1, Path 2). Once decompressor must not attempt decompression (Figure 1, Path 2). Once
the RoHC module completes processing, IPsec processing resumes, as the RoHC module completes processing, IPsec processing resumes, as
described in Section 5.2, Step 4 of [IPSEC] (specifically "Then match described in Section 5.2, Step 4 of [IPSEC] (specifically "Then match
the packet against the inbound selectors identified by the SAD ..."). the packet against the inbound selectors identified by the SAD ...").
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 can be implemented in a nested fashion. For an RoHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested
outbound packet, IPcomp is initially applied. Following the fashion. This process is detailed in [IPSEC-ROHC], Section 3.2.
application of IPcomp, the packet is sent to the RoHC module. Then,
the RoHC module may compress the headers (e.g., the IP header) of the
IPcomp-processed packet. After the RoHC process completes, IPsec
processing resumes. For inbound packets, these steps are reversed:
first, the packet is IPsec-processed; then, headers are decompressed;
last, the payload of the packet is decompressed based on the
appropriate IPcomp algorithm.
6.1.1. Header Compression Protocol Considerations 6.1.1. Header Compression Protocol Considerations
The initial specification of RoHC [ROHC] may need to be extended to The initial specification of RoHC [ROHC] may need to be extended to
operate efficiently over IPsec SAs. Specifically, compressor and operate efficiently over IPsec SAs. Specifically, compressor and
decompressor implementations must account for increased tolerance to decompressor implementations must account for increased tolerance to
packet reordering and packet loss, and should minimize the amount of packet reordering and packet loss, and should minimize the amount of
feedback sent from the decompressor to the compressor. To address feedback sent from the decompressor to the compressor. To address
this need, RoHCv2 [ROHCV2] defines various mechanisms that provide this need, [ROHC-RODR] provides guidelines on how to implement
increased robustness during these scenarios. Furthermore, within the existing profiles over reordering channels, and RoHCv2 [ROHCV2]
context of IPsec, a RoHCv2 implementation can leverage additional profiles include various mechanisms that provide increased robustness
mechanisms to improve performance over channels characterized by over reordering channels. Furthermore, a RoHC decompressor
packet reordering/loss. For example, various security protocols are implemented within IPsec architecture may leverage additional
equipped with a sequence number that may be used by the decompressor mechanisms to improve performance over reordering channels (either
to identify a packet as "sequentially late". This knowledge can be due to random events, or to an attacker intentionally reordering
utilized to increase the likelihood of successful decompression of a packets). Specifically, IPsec's sequence number may be used by the
reordered packet. decompressor to identify a packet as "sequentially late". This
knowledge will increase the likelihood of successful decompression of
a reordered packet.
Additionally, RoHC implementations should minimize the amount of Additionally, RoHCoIPsec implementations should minimize the amount
feedback between decompressor and compressor. If a feedback channel of feedback sent from the decompressor to the compressor. If a ROHC
from the decompressor to the compressor is not used sparingly, the feedback channel is not used sparingly, the overall gains from
overall gains from RoHCoIPsec can be significantly reduced. For RoHCoIPsec can be significantly reduced. For example, assume that
example, assume that RoHC is operating in bi-directional reliable RoHC is operating in bi-directional Reliable mode (R-mode), and is
mode, and is instantiated over an IPsec tunnel mode SA. In this instantiated over an IPsec tunnel mode SA. In this scenario, any
scenario, any feedback sent from the decompressor to the compressor feedback sent from the decompressor to the compressor must be
must be tunneled. As such, the additional overhead incurred by processed by IPsec, and tunneled back to the compressor (as
tunneling feedback will reduce the overall benefits of RoHC. designated by the SA associated with FEEDBACK_FOR). To address this
need, several implementation considerations are offered:
o Eliminate feedback traffic altogether by operating only in RoHC
Unidirectional mode (U-mode)
o Piggyback RoHC feedback messages on traffic that normally
traverses the SA designated by FEEDBACK_FOR.
Finally, it should be noted that all RoHCoIPsec implementations that
intend to reuse CIDs (i.e. remap a previously used but now retired
CID value in order to conserve CID space) must support the ROHC-DOWN
profile, as defined in [ROHC-DOWN]. This profile requires that a CID
value is shut-down before it is reused.
6.1.2. Initialization and Negotiation of the RoHC Channel 6.1.2. Initialization and Negotiation of the RoHC Channel
RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC
channel parameters. In the case of RoHCoIPsec, channel parameters channel parameters. In the case of RoHCoIPsec, channel parameters
are negotiated by another mechanism. Specifically, initialization of are negotiated by another mechanism. Specifically, initialization of
the RoHC channel is either achieved manually (i.e., administratively the RoHC channel is either achieved manually (i.e., administratively
configured for manual SAs), or is performed by IPsec SA establishment configured for manual SAs), or is performed by IPsec SA establishment
protocols. The extensions required for IKEv2 to support RoHC protocols. The extensions required for IKEv2 to support RoHC
parameter negotiation are detailed in [IKE-ROHC]. parameter negotiation are detailed in [IKE-ROHC].
skipping to change at page 10, line 29 skipping to change at page 10, line 35
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
decompressor (i.e., the decompressor located at the egress of the decompressor (i.e., the decompressor located at the egress of the
IPsec tunnel) that do not match the original packets emitted from the IPsec tunnel) that do not match the original packets emitted from the
end-hosts. Such a scenario will result in a decreased efficiency end-hosts. Such a scenario will result in a decreased efficiency
between compressor and decompressor. Furthermore, this may result in between compressor and decompressor. Furthermore, this may result in
Denial of Service, as the decompression of a significant number of Denial of Service, as the decompression of a significant number of
invalid packets may drain the resources of an IPsec device. invalid packets may drain the resources of an IPsec device.
In addition, some RoHCoIPsec implementations may allow an attacker to
identify new traffic flows by monitoring the relative size of the
encrypted packets (i.e. a group of "long" packets, followed by a long
series of "short" packets may indicate a new flow for some RoHCoIPsec
implementations). To mitigate this concern, RoHC padding mechanisms
may be used to arbitrarily add padding to transmitted packets to
randomize packet sizes.
8. IANA Considerations 8. IANA Considerations
None. None.
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. In addition, the authors would like to development of this document. In addition, the authors would like to
skipping to change at page 11, line 7 skipping to change at page 11, line 22
document: document:
o Dr. Stephen Kent o Dr. Stephen Kent
o Dr. Carsten Bormann o Dr. Carsten Bormann
o Mr. Tero Kivinen o Mr. Tero Kivinen
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. Pasi Eronen
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, Dr. Jonah Pezeshki, and Ms. Michele Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen
Casey of Booz Allen Hamilton for their assistance in completing this Hamilton for their assistance in completing this work.
work.
10. Informative References 10. Informative References
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (RoHC): Framework and four profiles: RTP, UDP, Compression (RoHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 2001.
skipping to change at page 11, line 47 skipping to change at page 12, line 14
[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 Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP, and
UDP-Lite", work in progress , May 2007. UDP-Lite", work in progress , May 2007.
[IKE-ROHC] [IKE-ROHC]
Pezeshki, et al., "IKEv2 Extensions to Support Pezeshki, et al., "IKEv2 Extensions to Support
RoHCoIPsec", work in progress , February 2007. RoHCoIPsec", work in progress , August 2007.
[ROHC-RODR]
Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust
Header Compression (ROHC): ROHC over Channels That Can
Reorder Packets", RFC 4224, January 2006.
[ROHC-DOWN]
Bormann, C., "A ROHC Profile for CID shutdown (ROHC-
DOWN)", work in progress , July 2007.
[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",
February 2007.
[IPSEC-ROHC] [IPSEC-ROHC]
Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec", Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec",
work in progress , February 2007. work in progress , August 2007.
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 5 skipping to change at page 13, line 20
Email: christou_chris@bah.com Email: christou_chris@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: jasani_rohan@bah.com
Jonah Pezeshki
Booz Allen Hamilton
13200 Woodland Park Dr.
Herndon, VA 20171
US
Email: pezeshki_jonah@bah.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 15 change blocks. 
39 lines changed or deleted 73 lines changed or added

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