Network Working Group R. Jasani Internet-Draft E. Ertekin Expires: August 28, 2006 C. Christou E. Brower Booz Allen Hamilton February 24, 2006 Alternatives to Achieving HCoIPsec draft-jasani-rohc-hcoipsec-alternatives-00.txt 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 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 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 August 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Header Compression over IPsec [HCOIPSEC], documents the work items needed to integrate hop-by-hop header compression algorithms with IPsec security associations. However, as a result of various discussions within the IETF, two alternative approaches to achieving HCoIPsec have emerged. This draft is intended to document the two alternatives, and help those involved with HCoIPsec development Jasani, et al. Expires August 28, 2006 [Page 1] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 converge on one common approach for realizing HCoIPsec. Table of Contents 1. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. HCoIPsec Alternatives . . . . . . . . . . . . . . . . . . . . 4 5.1. Functionality Shared between the Two Approaches . . . . . 5 5.2. HCoIPsec Alternative 1: Use of an Uncompressed Profile to Identify Uncompressed Packets . . . . . . . . . . . . . 6 5.2.1. Documents Needed . . . . . . . . . . . . . . . . . . . 7 5.3. HCoIPSec Alternative 2: Use of Next Header Field to Identify Uncompressed Packets . . . . . . . . . . . . . . 8 5.3.1. Documents Needed . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Jasani, et al. Expires August 28, 2006 [Page 2] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 1. Audience The target audience of this document includes those who are involved with the design and development of Header Compression (HC) schemes, IPsec mechanisms, and the IETF HCoIPsec participants. In addition, this document is intended for vendors developing IPsec encryption/ decryption devices that may be deployed in bandwidth-constrained, IP networking environments. 2. Purpose The purpose of this document is to detail two alternative approaches to integrating Header Compression over IPsec Security Associations (HCoIPsec). The document is intended to guide discussions for HCoIPsec, enabling those interested in the development of HCoIPsec to evaluate and converge on one of the two alternatives. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Compressed Traffic Traffic that is processed by the compressor (compressed) using one of the existing profiles. Note that this includes packets that might be processed using an "uncompressed" profile. Uncompressed Traffic Traffic that is not processed by the compressor. Instead, this type of traffic bypasses the HC process. HC Process Generic reference to either the compressor and/or decompressor. IPsec Process Generic reference to the Internet Protocol Security (IPsec) process, as specified in [RFC 4301]. Data Item Jasani, et al. Expires August 28, 2006 [Page 3] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 Generic reference to a parameter associated to an SA (i.e. Security Parameter Index, IPsec Protocol Mode, etc...), as specified in [RFC 4301]. 4. Overview In an effort to reduce the overhead associated with packets traversing IPsec tunnel mode SAs, [HCoIPsec] includes one possible approach to integrating HC schemes with the IPsec architecture. However, after multiple versions of the HCoIPsec internet-draft were published, discussions within the IETF revealed an alternate approach to achieving HCoIPsec. Although the two HCoIPsec approaches share several commonalities, they diverge on the mechanism used to identify uncompressed packets. This mechanism is used in situations where packets traversing an HC- enabled SA can not be compressed by the compressor. These situations can occur when, for example, a compressor supports strictly n compressed flows, and can not compress the n+1 flow that arrives. Another example is when traffic is selected to an HC-enabled SA (e.g. TCP/IP), but can not be compressed by the HC process(e.g., because the compressor does not support TCP/IP compression). In these situations, the compressor needs to be able to indicate that the packet contains uncompressed headers; the decompressor, on the other hand, must be able to identify packets with uncompressed headers, and must not attempt to decompress these headers. In this document, the approach proposed in [HCoIPsec] is referred to as "HCoIPsec Alternative 1". The approach identifies compressed traffic solely through SA state information. In addition, the approach uses an "uncompressed profile" to carry packets with uncompressed headers over the HC-enabled SA. The second approach is documented as "HCoIPsec Alternative 2". Similar to the first approach, "HCoIPsec Alternative 2" identifies compressed traffic using SA state information. However, the approach proposes an alternative mechanism for carrying uncompressed packets over the HC-enabled SA. This mechanism identifies uncompressed traffic traversing an HC-enabled SA by the Next Header field of the IPsec security protocol (e.g., AH or ESP) header. 5. HCoIPsec Alternatives There are two approaches for Integrating Header Compression over IPsec Security Associations: Jasani, et al. Expires August 28, 2006 [Page 4] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 a. HCoIPSec Alternative 1: Use of Uncompressed Profile to Identify Uncompressed Packets b. HCoIPsec Alternative 2: Use of Next Header Field to Identify Uncompressed Packets 5.1. Functionality Shared between the Two Approaches Despite their differences, the two HCoIPsec alternatives share common functionality. Specifically, new state information (i.e., a new HC data item) will be defined within each SA. This data item indicates whether the SA is "HC-enabled" or "HC-disabled". An HC-enabled SA allows header compression to be applied to the traffic it carries, while an HC-disabled SA does not allow header compression to be applied to the traffic it carries. In other words, the HC data item is used by the IPsec process to determine whether it sends all traffic traversing a given SA to the HC module (HC-enabled) or to bypass the HC module and send traffic through regular IPsec processing (HC-disabled). This decision is illustrated by block A of Figure 1 below. +-------------------------------+ | HC Module | | | | | +-----+ | +---------+ | | | HC-enabled | | HC | | --| A |-----------------> | Process | | | | | | | | +-----+ | +---------+ | | | | | | | | | | | +-------------------------------+ | | HC-disabled +----------------------------------------------------> Figure 1: Decision process common to both alternatives. For outbound IP traffic processing (protected-to-unprotected), the decision at block A of Figure 1 determines whether or not the packet will be sent to the HC module. Based on the SA state information (HC data item) retrieved from the "relevant SAD entry" (i.e., Step3a, Page 52, [RFC4301]), it is determined whether or not traffic traversing the SA is handed to the HC module. Packets selected to an HC-disabled SA must not be sent to the HC module, and will follow normal IPsec processing. Packets traversing an HC-enabled SA must be sent to the HC module. Once the HC module completes processing, Jasani, et al. Expires August 28, 2006 [Page 5] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 IPsec processing resumes, as described in Step3a, Page 52 of [RFC4301] (specifically "IPsec processing is as previously defined ..."). For inbound IP traffic processing (unprotected-to-protected), the decision at block A of Figure 1 determines whether the packet will be sent to the HC module. For inbound packets, IPsec processing is as defined in Steps 1-3, pp. 60-61 in [RFC4301], and AH or ESP processing is applied to the packet, as specified in step 4. However, after AH or ESP processing is applied, based on the SA state information (HC data item) retrieved from the SAD entry (i.e., Step 3a, Page 59 of [RFC4301]), it is determined whether or not traffic traversing the SA is handed to the HC module. Packets traversing an HC-disabled SA must not be sent to the HC module; packets traversing an HC-enabled SA must be sent to the HC module. Once the HC module completes processing, IPsec processing resumes, as described in Step 4 on Page 60 of RFC 4301 (specifically "Then match the packet against the inbound selectors identified by the SAD ..."). 5.2. HCoIPsec Alternative 1: Use of an Uncompressed Profile to Identify Uncompressed Packets In addition to the common functionality described in Section 5.1, "HCoIPsec Alternative 1" uses an "uncompressed profile" to identify packets that can not be compressed over an HC-enabled SA. A packet processed with the "uncompressed profile" maintains uncompressed headers, in addition to HC control information (Note: HC control information is used by the decompressor to process the packet appropriately). In other words, the packet appears to be a compressed packet since it contains HC control information; however, in reality the packet consists of uncompressed headers. When a packet that is processed by the "uncompressed profile" arrives at the decompressor, the HC control information enables the decompressor to identify that the packet must be processed using the "uncompressed profile". The decompressor subsequently decompresses the packet (i.e., removes the HC control information) and the packet resumes IPsec processing. The decision tree for this alternative is described below in Figure 2. Jasani, et al. Expires August 28, 2006 [Page 6] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 +-------------------------------+ | HC Module | | | | | +-----+ | +---------+ | | | HC-enabled | | HC |------> Path 1 --| A |--------------------------------| Process | | | | | | |------> Path 2 +-----+ | +---------+ | | | | | | | | | | | +-------------------------------+ | | HC-disabled +----------------------------------------------------> Path 3 Figure 2: Decision process for HCoIPsec Alternative 1. For outbound processing on an HC-enabled SA, if the HC process determines that a packet can be compressed using a compression profile (e.g., UDP/IP), the packet headers are processed based on the compression profile (Path 1 in Figure 2.). Otherwise, the packet is processed using a "uncompressed profile" (Path 2 in Figure 2.). After the HC process completes, the compressed packet resumes IPsec processing. For inbound processing on an HC-enabled SA, if the HC process determines that a packet is composed of compressed headers, the packet headers are decompressed using the appropriate decompression profile (e.g., UDP/IP) (Path 1 in Figure 2.). However, if the packet was processed using an "uncompressed profile", the HC control information is removed (Path 2 in Figure 2.). After the HC process completes, the packet resumes IPsec processing. 5.2.1. Documents Needed As detailed in the HCoIPsec internet-draft, the following documents are needed to realize a HCoIPsec solution based on "HCoIPsec Alternative 1": 1. Header Compression over IPsec (HCoIPsec): This document details the chosen alternative to achieving HCoIPsec, and discusses the general operation of HCoIPsec, independent of any HC algorithms (e.g. ROHC, ECRTP, etc.). 2. IKE/IPsec extensions required to achieve HCoIPsec: This document discusses the extensions for IKE and IPsec, required to achieve HCoIPsec. Jasani, et al. Expires August 28, 2006 [Page 7] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 3. XXXX over IPsec: This (These) documents describe the operation of an HC algorithm over IPsec. Such documents may include "ROHC over IPsec", "ECRTP over IPsec", etc. 5.3. HCoIPSec Alternative 2: Use of Next Header Field to Identify Uncompressed Packets In addition to the common functionality described previously, this alternative uses the security protocol "Next Header" field to identify packets that can not be compressed over an HC-enabled SA. A single allocation for "compressed headers" will need to be reserved from IANA in the "Protocol Numbers" registry. The "compressed headers" value will indicate that the next layer protocol header is composed of compressed headers. In comparison to HCoIPsec Approach 1, this alternative eliminates the need for the "uncompressed profile", and does not require packets with uncompressed headers to contain HC control information. The decision tree for this alternative is described in Figure 3, below. +-------------------------------+ | HC Module | | | | | +-----+ | +-----+ +---------+ | | | HC-enabled | | | | HC | | --| A |--------------------| B |-----| Process |------> Path 1 | | | | | | | | +-----+ | +-----+ +---------+ | | | | | | | |-------------------------> Path 2 | | | | +-------------------------------+ | | HC-disabled +----------------------------------------------------> Path 3 Figure 3: Decision process for HCoIPsec Alternative 2. For outbound processing on an HC-enabled SA, the decision at block B of Figure 3 determines whether the packet can be compressed. If the packet can be compressed, then the "Next Header" field in the security protocol header is populated with the "compressed headers" value, and packet headers are compressed based on the appropriate compression profile (e.g., UDP/IP) (Path 1 in Figure 3.). However, if the packet cannot be compressed, the security protocol "Next Jasani, et al. Expires August 28, 2006 [Page 8] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 Header" field is left as is (Path 2 in Figure 3.). After the HC process completes, the packet resumes IPsec processing. For inbound processing on a HC-enabled SA, the decision at block B of Figure 3 determines whether the packet was compressed. If the security protocol "Next Header" field contains the "compressed headers" value, this indicates that the packet's headers are compressed, and the appropriate decompression profile is applied (Path 1 in Figure 3.). However, if the packet's Next Header field does not contain the "compressed headers" value, the decompressor does not process the packet (Path 2 in Figure 3.). After the HC process completes, the packet resumes IPsec processing. 5.3.1. Documents Needed The following documents need to be specified to realize an HCoIPsec solution based on "HCoIPsec Alternative 2": 1. Header Compression over IPsec (HCoIPsec): This document details the chosen alternative to achieving HCoIPsec, and discusses the general operation of HCoIPsec, independent of any HC algorithms (e.g. ROHC, ECRTP, etc.). 2. IKE/IPsec extensions required to achieve HCoIPsec: This document discusses the extensions for IKE and IPsec, required to achieve HCoIPsec. 3. XXXX over IPsec: This (These) documents describe the operation of an HC algorithm over IPsec. Such documents may include "ROHC over IPsec", "ECRTP over IPsec", etc. 6. Security Considerations [HCoIPsec] documents several security considerations associated with HCoIPsec (independent of either HCoIPsec alternative). There are no additional security considerations associated with either HCoIPsec alternative. 7. IANA Considerations If "HCoIPsec Alternative 2" is the chosen approach, IANA may be requested to allocate one value within the "Protocol Numbers" registry, named "Compressed Headers". This value will be used to indicate that the next level protocol header is a compressed header. 8. Acknowledgments Jasani, et al. Expires August 28, 2006 [Page 9] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, Mrs. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of OPnet for their contributions and support for developing this document. The authors would also like to thank Ms. Renee Esposito and Ms. Latonya Jefferies of Booz Allen Hamilton for her assistance in completing this work. 9. References 9.1. Normative References [IPSECARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999. [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [ECRTP] Koren, T. and et. al., "Compressing IP/UDP/RTP Headers on Links with High Delay, Packet Loss, and Reordering", RFC 3545, July 2003. [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. [ROHCWEXT] Pelletier, G. and et. al, "ROHC over Channels That Can Reorder Packets", work in progress , February 2005. 9.2. Informative References [CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communication Magazine , Volume 7, number 4, pp. 20-25, August 2000. [ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS", work in progress , December 2004. Jasani, et al. Expires August 28, 2006 [Page 10] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 Authors' Addresses Rohan Jasani Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: jasani_rohan@bah.com Emre Ertekin Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: ertekin_emre@bah.com Chris Christou Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: christou_chris@bah.com Etzel Brower Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: brower_etzel@bah.com Jasani, et al. Expires August 28, 2006 [Page 11] Internet-Draft Alternatives to Achieving HCoIPsec February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jasani, et al. Expires August 28, 2006 [Page 12]