Network Working Group E. Ertekin Internet-Draft
J. PezeshkiC. Christou Expires: FebruaryApril 16, 2009 J. Pezeshki M. Casey C. ChristouBooz Allen Hamilton C. Bormann Universitaet Bremen TZI August 15,October 13, 2008 IPsec Extensions to Support Robust Header Compression over IPsec (RoHCoIPsec) draft-ietf-rohc-ipsec-extensions-hcoipsec-02(ROHCoIPsec) draft-ietf-rohc-ipsec-extensions-hcoipsec-03 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 FebruaryApril 16, 2009. Abstract Integrating RoHCROHC with IPsec (RoHCoIPsec)(ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, extensions to the SPD and SAD are required in order to integrate RoHCROHC with IPsec. This document describes the IPsec extensions required to support RoHCoIPsec.ROHCoIPsec. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Extensions to IPsec Databases . . . . . . . . . . . . . . . . 3 2.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 3 2.2. Security Association Database (SAD) . . . . . . . . . . . 4 3. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 5 3.1. Addition to the IANA Protocol Numbers Registry . . . . . . 5 3.2. Verifying the Integrity of Decompressed Packet Headers . . 5 3.2.1. ICV Computation and Integrity Verification . . . . . . 6 3.3. Nested IPComp and RoHCoIPsecROHCoIPsec Processing . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 1. Introduction Using IPsec ([IPSEC]) protection offers various security services for IP traffic. However, these benefits come at the cost of additional packet headers, which increase packet overhead. As described in [ROHCOIPSEC], Robust Header Compression (RoHC(ROHC [ROHC]) can be used with IPsec to reduce the overhead associated with IPsec-protected packets. IPsec-protected traffic is carried over Security Associations (SAs), whose parameters are negotiated on a case-by-case basis. The Security Policy Database (SPD) specifies the services that are to be offered to IP datagrams, and the parameters associated with SAs that have been established are stored in the Security Association Database (SAD). To integrate RoHCROHC and IPsec, various extensions to the SPD and SAD that incorporate RoHC-relevantROHC-relevant parameters are required. In addition, three extensions to IPsec processing are required. First, a mechanism for identifying RoHCROHC packets must be defined. Second, a mechanism is required to ensure the integrity of the decompressed packet. Finally, the order of the inbound and outbound processing must be enumerated when nesting IP Compression (IPComp [IPCOMP]), RoHC,ROHC, and IPsec processing. 2. Extensions to IPsec Databases The following subsections specify extensions to the SPD and the SAD to support RoHCoIPsec.ROHCoIPsec. 2.1. Security Policy Database (SPD) In general, the SPD is responsible for specifying the security services that are offered to IP datagrams. Entries in the SPD specify how to derive the corresponding values for SAD entries. To support RoHC,ROHC, the SPD must be extended to include per-channel RoHCROHC parameters. Together, the existing IPsec SPD parameters and the RoHCROHC parameters will dictate the services that are provided to packets protected by IPsec. The fields contained within each SPD entry are defined in [IPSEC], Section 18.104.22.168. To support RoHC,ROHC, several processing info fields must be added to the SPD; these fields contain information regarding the RoHCROHC profiles and channel parameters supported by the local RoHCROHC instance. The SPD specifies what services are to be offered to IP datagrams, and in what fashion. To offer IP datagrams compression services, thetwo per-channel configuration parameters, defined in [ROHC],parameters are added to the SPD. Specifically, the following two parameters must be included if the processing info field in the SPD is set to PROTECT (suggested values for these parameters are consistent with [ROHCPPP]): MAX_CID: The highest context ID number to be used by the compressor. MAX_CID must be at least 0 and at most 16383 (The value 0 implies having one context). The suggested value for MAX_CID is 15. PROFILES: This indicates the RoHCROHC profiles supported by the decompressor. The list of possible values this field may assume is defined in the [ROHCPROF] registry. MRRU: The size of the largest reconstructed unit that the decompressor is expected to reassemble from segments.In general, it is not anticipated thataddition to these ROHC channel parameters, a RoHCoIPsec instance will use RoHC segmentation. Consequently,field within the suggested value for MRRUSPD is 0. MAX_HEADER: The largest header size (in octets) that can be compressed. Note thatrequired to store a list of integrity algorithms supported by the four RoHC profiles defined in RFC 3095 do not provide forROHCoIPsec instance: INTEGRITY ALGORITHM: a MAX_HEADER parameter. The parameter MAX_HEADER is therefore without consequence in these profiles. Other profiles (e.g., ones based on RFC 2507) can make uselist of integrity algorithms supported by the parameterROHCoIPsec instance. This will be used by explicitly referencing it. Note:the ROHC process to ensure that packet headers are properly decompressed (see Section 3.2). Several other ROHC channel parameters are omitted from the SPD, because they are set implicitly. The ROHC channel parameters are LARGE_CIDS, MRRU, and FEEDBACK_FOR. The RoHCLARGE_CIDS channel parameter is set implicitly, based on the value of MAX_CID. Furthermore,MAX_CID (e.g. if a SA inMAX_CID is <= 15, LARGE_CIDS is assumed to be 0). Furthermore, the reverse direction exists,MRRU parameter must be set to 0; since packets may be reordered across a ROHCoIPsec channel, a compression session must not use segmentation. Finally, the RoHCROHC FEEDBACK_FOR channel parameter is set implicitly to the RoHCROHC channel associated with the SA in the reverse direction. If aan SA in the reverse direction does not exist, RoHCROHC must operate in the Unidirectional Mode. Because both of these RoHC channel parameters are set implicitly, they are not stored in the SPD. In addition to these RoHC channel parameters, a field within the SPD entry is required to store a list of integrity algorithms supported by the RoHCoIPsec instance. This integrity algorithm will be used by the RoHC process to ensure that packet headers are properly decompressed (see Section 3.2).2.2. Security Association Database (SAD) Each entry within the SAD defines the parameters associated with each established SA. Unless if the "populate from packet" (PFP) flag is asserted for a particular field, SAD entries are determined by the corresponding SPD entries during the creation of the SA. The data items contained within the SAD are defined in [IPSEC], Section 22.214.171.124. To support RoHC,ROHC, this list of data items is augmented to include a "RoHC"ROHC Data Item" field that defines the RoHCROHC parameters. These parameters (i.e., MAX_CID, PROFILES, MRRU, and MAX_HEADER)PROFILES) are enumerated above in Section 2.1. In addition, the FEEDBACK_FOR parameter is also included, which is associated with the SA in the reverse direction (this data item does not need to be included in the SPD, since its value is implicitly derived). Finally, two additional data itemsparameters are required to store the Integrity Algorithm and respective key that is to be used to ensure that packets are properly decompressed (see Section 3.2). These "RoHC"ROHC Data Item" values may be initialized manually (i.e., administratively configured for manual SAs), or initialized via a key exchange protocol (e.g. IKEv2 [IKEV2]) that has been extended to support the negotiation of RoHCROHC parameters [IKEV2EXT]. 3. Extensions to IPsec Processing 3.1. Addition to the IANA Protocol Numbers Registry In order to demultiplex header-compressed from uncompressed traffic on a RoHC-enabledROHC-enabled SA, a "RoHC""ROHC" value must be reserved in the IANA Protocol Numbers registry. If an outbound packet has a compressed header, the Next Header field of the security protocol header (e.g., AH [AH], ESP [ESP]) must be set to the "RoHC""ROHC" protocol identifer.identifier. If the packet header has not been compressed, the Next Header field remains unaltered. Conversely, for an inbound packet, the value of the security protocol Next Header field is checked to determine if the packet includes a RoHCROHC header. 3.2. Verifying the Integrity of Decompressed Packet Headers Since RoHCROHC is inherently a lossy algorithm, RoHCoIPsec willROHCoIPsec may use an additional Integrity Algorithm (and respective key) to compute a second Integrity Check Value (ICV) for the uncompressed packet. Specifically, thisThis ICV will beis computed forover the uncompressed IP header, as well at the higher-layer headers and the packet payload. This ICV will bepayload, and is appended to the RoHC-compressedROHC-compressed packet. At the decompressor, the decompressed packet (including the uncompressed IP header, higher-layer headers, and packet payload; but not including the authentication data) will be used with the Integrity Algorithm (and its respective key) to compute a value that will be compared to the ICV. If these values are not identical, the decompressed packet must be dropped by the decompressor. Figure 1 illustrates the composition of a RoHCoIPsec-processedROHCoIPsec-processed IPv4 packet. In the example, TCP/IP compression is applied, and the packet is processed with tunnel mode ESP. BEFORE COMPRESSION AND APPLICATION OF ESP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER ROHCOIPSEC COMPRESSION AND APPLICATION OF ESP ------------------------------------------------------ IPv4 | new IP hdr | | CmprCmpr. | | RoHCROHC | ESP | ESP| |(any options)| ESP | Hdr. |Data| ICV |Trailer| ICV| ------------------------------------------------------ Figure 1. Example of a RoHCoIPsec-processedROHCoIPsec-processed packet. Note: The authentication data should never be included in the calculation of the ICV. 3.2.1. ICV Computation and Integrity Verification In order to correctly verify the integrity of the decompressed packets, the processing steps for RoHCoIPsecROHCoIPsec must be implemented in a specific order, as given below. For outbound packets that are to be processed by RoHC:ROHC: o An ICV is computed for the uncompressed packet via RoHCoIPsec'sROHCoIPsec's Integrity Algorithm (and respective key) o The packet isheader(s) is(are) compressed by the RoHCROHC process o The ICV is appended to the end of the compressed packet o The security protocol is applied to the packet For inbound packets that are to be decompressed by RoHC:ROHC: o A packet received on a RoHC-enabledROHC-enabled SA is IPsec-processed o The packet isheader(s) is(are) decompressed by the RoHCROHC process o The decompressed packet is used with the Integrity Algorithm (and its respective key) to compute a value that is compared to the ICV (if these two values differ, the packet is dropped) 3.3. Nested IPComp and RoHCoIPsecROHCoIPsec Processing IPComp ([IPCOMP]) is another mechanism that can be implemented to reduce the size of an IP datagram. If IPComp and RoHCoIPsecROHCoIPsec are implemented in a nested fashion, the order of the outbound and inbound processing steps must be carefully enumerated. For outbound packets that are to be processed by IPcomp and RoHC:ROHC: o The ICV is computed for the uncompressed packet, and the appropriate RoHCROHC compression profile is applied to the packet o IPComp is applied, and the packet is sent to the IPsec process o The security protocol is applied to the packet Conversely, for inbound packets that are to be both RoHC-ROHC- and IPcomp- decompressed: o A packet received on a RoHC-enabledROHC-enabled SA is IPsec-processed o The datagram is decompressed based on the appropriate IPComp algorithm o The packet is sent to the RoHCROHC module for header decompression and integrity verification 4. Security Considerations A RoHCoIPsecROHCoIPsec implementer should consider the strength of protection provided by the integrity check algorithm used to verify the valid decompression of RoHC-compressedROHC-compressed packets. Failure to implement a strong integrity check algorithm increases the probability of an invalidly decompressed packet to be forwarded by a RoHCoIPsecROHCoIPsec device into a protected domain. In general, if an integrity check algorithm is used with IPsec, it is recommended that the integrity check algorithm used by RoHCROHC is at least the same strength. The implementation of RoHCoIPsecROHCoIPsec may increase the susceptibility for traffic flow analysis, where an attacker can 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 RoHCoIPsecROHCoIPsec implementations). To mitigate this concern, RoHCROHC padding mechanisms may be used to arbitrarily add padding to transmitted packets to randomize packet sizes. 5. IANA Considerations IANA is requested to allocate one value within the "Protocol Numbers" registry [PROTOCOL] for "RoHC"."ROHC". This value will be used to indicate that the next level protocol header is a RoHCROHC header. 6. Acknowledgments The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, Ms. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of OPnet for their contributions and support for developing this document. In addition, the authors would like to thank Mr. Rohan Jasani for his valuable assistance. Finally, the authors would like to thank the following for their numerous reviews and comments to this document: o Dr. Stephen Kent o Dr. Carsten Bormann oMr. Lars-Erik Jonnson o Mr. Pasi Eronen o Mr. Tero Kivinen o Dr. Joseph Touch 7. References 7.1. Normative References [IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [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. [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. [ROHCPPP] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002. [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [IKEV2EXT] Pezeshki, J., Ertekin, E., and C. Christou, "Extensions to IKEv2 to Support Robust Header Compression over IPsec (RoHCoIPsec)",(ROHCoIPsec)", work in progress , AugustOctober 2008. [AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 7.2. Informative References [ROHCOIPSEC] Ertekin, E. and C. Christou, "Integration of Header Compression over IPsec Security Associations", work in progress , AugustOctober 2008. [ROHCPROF] "RObust Header Compression (ROHC) Profile Identifiers", www.iana.org/assignments/rohc-pro-ids , October 2005. [PROTOCOL] IANA, ""Assigned Internet Protocol Numbers", IANA registry at: http://www.iana.org/assignments/protocol-numbers". Authors' Addresses Emre Ertekin Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: firstname.lastname@example.org Jonah PezeshkiChris Christou Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: email@example.com Michele Caseychristou_chris@bah.com Jonah Pezeshki Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: firstname.lastname@example.org Chris Christoupezeshki_jonah@bah.com Michele Casey Booz Allen Hamilton 13200 Woodland Park Dr. Herndon, VA 20171 US Email: email@example.com_michele@bah.com Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. Intellectual Property 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 email@example.com.