--- 1/draft-ietf-rohc-hcoipsec-05.txt 2007-08-29 23:12:14.000000000 +0200 +++ 2/draft-ietf-rohc-hcoipsec-06.txt 2007-08-29 23:12:14.000000000 +0200 @@ -1,20 +1,21 @@ Network Working Group E. Ertekin Internet-Draft C. Christou Intended status: Informational R. Jasani -Expires: December 3, 2007 Booz Allen Hamilton - June 1, 2007 +Expires: February 28, 2008 J. Pezeshki + Booz Allen Hamilton + August 27, 2007 Integration of Robust Header Compression (RoHC) over IPsec Security Associations - draft-ietf-rohc-hcoipsec-05 + draft-ietf-rohc-hcoipsec-06 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,21 +26,21 @@ 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (C) The IETF Trust (2007). Abstract IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for @@ -59,24 +60,24 @@ 5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5 6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6 6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 6.1.2. Initialization and Negotiation of the RoHC Channel . . . . 9 6.1.3. Encapsulation and Identification of Header Compressed Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . 13 + Intellectual Property and Copyright Statements . . . . . . 14 1. Introduction This document outlines a framework for integrating RoHC [ROHC] over IPsec [IPSEC] (RoHCoIPsec). The goal of RoHCoIPsec is to reduce the protocol overhead associated with packets traversing between IPsec SA endpoints. This can be achieved by compressing the transport layer 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 egress. @@ -297,56 +298,63 @@ 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 is indicated, decompression is applied (Figure 1, Path 1). However, if the Next Header field does not indicate a RoHC header, the decompressor must not attempt decompression (Figure 1, Path 2). Once the RoHC module completes processing, IPsec processing resumes, as described in Section 5.2, Step 4 of [IPSEC] (specifically "Then match the packet against the inbound selectors identified by the SAD ..."). Note that to further reduce the size of an IPsec-protected packet, - RoHCoIPsec and IPcomp can be implemented in a nested fashion. For an - outbound packet, IPcomp is initially applied. Following the - 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. + RoHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested + fashion. This process is detailed in [IPSEC-ROHC], Section 3.2. 6.1.1. Header Compression Protocol Considerations The initial specification of RoHC [ROHC] may need to be extended to operate efficiently over IPsec SAs. Specifically, compressor and decompressor implementations must account for increased tolerance to packet reordering and packet loss, and should minimize the amount of feedback sent from the decompressor to the compressor. To address - this need, RoHCv2 [ROHCV2] defines various mechanisms that provide - increased robustness during these scenarios. Furthermore, within the - context of IPsec, a RoHCv2 implementation can leverage additional - mechanisms to improve performance over channels characterized by - packet reordering/loss. For example, various security protocols are - equipped with a sequence number that may be used by the decompressor - to identify a packet as "sequentially late". This knowledge can be - utilized to increase the likelihood of successful decompression of a - reordered packet. + this need, [ROHC-RODR] provides guidelines on how to implement + existing profiles over reordering channels, and RoHCv2 [ROHCV2] + profiles include various mechanisms that provide increased robustness + over reordering channels. Furthermore, a RoHC decompressor + implemented within IPsec architecture may leverage additional + mechanisms to improve performance over reordering channels (either + due to random events, or to an attacker intentionally reordering + packets). Specifically, IPsec's sequence number may be used by the + 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 - feedback between decompressor and compressor. If a feedback channel - from the decompressor to the compressor is not used sparingly, the - overall gains from RoHCoIPsec can be significantly reduced. For - example, assume that RoHC is operating in bi-directional reliable - mode, and is instantiated over an IPsec tunnel mode SA. In this - scenario, any feedback sent from the decompressor to the compressor - must be tunneled. As such, the additional overhead incurred by - tunneling feedback will reduce the overall benefits of RoHC. + Additionally, RoHCoIPsec implementations should minimize the amount + of feedback sent from the decompressor to the compressor. If a ROHC + feedback channel is not used sparingly, the overall gains from + RoHCoIPsec can be significantly reduced. For example, assume that + RoHC is operating in bi-directional Reliable mode (R-mode), and is + instantiated over an IPsec tunnel mode SA. In this scenario, any + feedback sent from the decompressor to the compressor must be + processed by IPsec, and tunneled back to the compressor (as + 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 RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC channel parameters. In the case of RoHCoIPsec, channel parameters are negotiated by another mechanism. Specifically, initialization of the RoHC channel is either achieved manually (i.e., administratively configured for manual SAs), or is performed by IPsec SA establishment protocols. The extensions required for IKEv2 to support RoHC parameter negotiation are detailed in [IKE-ROHC]. @@ -402,20 +410,28 @@ A malfunctioning RoHC compressor (i.e., the compressor located at 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 IPsec tunnel) that do not match the original packets emitted from the end-hosts. Such a scenario will result in a decreased efficiency between compressor and decompressor. Furthermore, this may result in Denial of Service, as the decompression of a significant number of 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 None. 9. Acknowledgments 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. Rich Espy of OPnet for their contributions and support in the development of this document. In addition, the authors would like to @@ -423,25 +439,25 @@ document: o Dr. Stephen Kent o Dr. Carsten Bormann o Mr. Tero Kivinen o Mr. Lars-Erik Jonsson o Mr. Jan Vilhuber o Mr. Dan Wing o Mr. Kristopher Sandlund o Mr. Ghyslain Pelletier + o Mr. Pasi Eronen Finally, the authors would also like to thank Mr. Tom Conkle, Ms. - Renee Esposito, Mr. Etzel Brower, Dr. Jonah Pezeshki, and Ms. Michele - Casey of Booz Allen Hamilton for their assistance in completing this - work. + Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen + Hamilton for their assistance in completing this work. 10. Informative References [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (RoHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. @@ -463,29 +479,39 @@ [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (RoHCv2): Profiles for RTP, UDP, IP, ESP, and UDP-Lite", work in progress , May 2007. [IKE-ROHC] 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] 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] Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec", - work in progress , February 2007. + work in progress , August 2007. Authors' Addresses Emre Ertekin Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: ertekin_emre@bah.com @@ -499,20 +524,28 @@ Email: christou_chris@bah.com Rohan Jasani Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US 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 Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS