idnits 2.17.1 draft-ertekin-rohc-ipsec-extensions-hcoipsec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 339. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1, 2007) is 6171 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ROHCOIPSEC' ** Obsolete normative reference: RFC 4306 (ref. 'IKEV2') (Obsoleted by RFC 5996) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2EXT' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ertekin 3 Internet-Draft M. Casey 4 Expires: December 3, 2007 J. Pezeshki 5 C. Christou 6 Booz Allen Hamilton 7 June 1, 2007 9 IPsec Extensions to Support Robust Header Compression over IPsec 10 (RoHCoIPsec) 11 draft-ertekin-rohc-ipsec-extensions-hcoipsec-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 3, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 Integrating RoHC with IPsec (RoHCoIPsec) offers the combined benefits 45 of IP security services and efficient bandwidth utilization. Before 46 this can be realized, however, several extensions to the Security 47 Policy Database (SPD), the Security Association Database (SAD), and 48 the IPsec process are required. This document describes the IPsec 49 extensions required to support RoHCoIPsec. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Extensions to IPsec Databases . . . . . . . . . . . . . . . . . 3 55 2.1. Security Policy Database (SPD) . . . . . . . . . . . . . . 3 56 2.2. Security Association Database (SAD) . . . . . . . . . . . . 4 57 3. Extensions to IPsec Processing . . . . . . . . . . . . . . . . 5 58 3.1. Addition to the IANA Protocol Numbers Registry . . . . . . 5 59 3.2. Nested IPComp and RoHCoIPsec Processing . . . . . . . . . . 5 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . . . 9 69 1. Introduction 71 Using IPsec ([IPSEC]) protection offers various security services for 72 IP traffic. However, for tunnel-mode security associations, these 73 benefits come at the cost of additional packet headers, which 74 increase packet overhead. As described in [ROHCOIPSEC], Robust 75 Header Compression (RoHC [ROHC]) can be used with IPsec to reduce the 76 overhead associated with IPsec-protected packets. 78 IPsec-protected traffic is carried between peers by Security 79 Associations (SAs), whose parameters are negotiated on a case-by-case 80 basis. The Security Policy Database (SPD) specifies the services 81 that are to be offered to IP datagrams, and the parameters associated 82 with SAs that have been established are stored in the Security 83 Association Database (SAD). To fully integrate RoHC and IPsec, 84 various extensions to the SPD and SAD that incorporate RoHC-relevant 85 parameters are required. 87 In addition, two extensions to the IPsec processing methodology are 88 required. First, a mechanism for identifying RoHC packets must be 89 defined. Second, the order of the inbound and outbound processing 90 must be enumerated when nesting IP Compression (IPComp [IPCOMP]), 91 RoHC, and IPsec processing. 93 2. Extensions to IPsec Databases 95 The following subsections specify extensions to the SPD and the SAD 96 to support RoHCoIPsec. 98 2.1. Security Policy Database (SPD) 100 In general, the SPD is responsible for specifying the security 101 services that are offered to IP datagrams. Entries in the SPD 102 specify how to derive the corresponding values for SAD entries. To 103 support RoHC, the SPD must be extended to include per-channel RoHC 104 parameters. Together, the existing IPsec SPD parameters and the RoHC 105 parameters will dictate packet disposition for traffic that is to be 106 compressed, and subsequently protected by IPsec. 108 The fields contained within each SPD entry are defined in [IPSEC], 109 Section 4.4.1.2. To support RoHC, several processing info fields 110 must be added to the SPD; these fields contain information regarding 111 the RoHC profiles and channel parameters supported by the local RoHC 112 instance. The per-channel configuration parameters required for RoHC 113 in the SPD are as follows (note that this information must only be 114 included in the SPD if the processing info field is set to PROTECT, 115 and if the IPsec mode is set to tunnel mode): 117 MAX_CID: The highest context ID number to be used by the 118 compressor. MAX_CID must be at least 0 and at most 16383 (The 119 value 0 implies having one context). The suggested value for 120 MAX_CID is 15. 122 PROFILES: This indicates the RoHC profiles supported by the 123 decompressor. The list of possible values this field may assume 124 is defined in the [ROHCPROF] registry. 126 MRRU: The size of the largest reconstructed unit that the 127 decompressor is expected to reassemble from segments. In general, 128 is not anticipated that a RoHC over IPsec instance will use RoHC 129 segmentation features. Consequently, the suggested value for MRRU 130 is 0. 132 MAX_HEADER: The largest header size (in octets) that can be 133 compressed. Note that the four RoHC profiles defined in RFC 3095 134 do not provide for a MAX_HEADER parameter. The parameter 135 MAX_HEADER is therefore without consequence in these profiles. 136 Other profiles (e.g., ones based on RFC 2507) can make use of the 137 parameter by explicitly referencing it. 139 Note: The RoHC LARGE_CIDS channel parameter is set implicitly, based 140 on the value of MAX_CID. Furthermore, the RoHC FEEDBACK_FOR channel 141 parameter is set implicitly to the RoHC channel associated with the 142 SA in the reverse direction. Because both of these RoHC channel 143 parameters are set implicitly, they are not stored in the SPD or SAD. 145 2.2. Security Association Database (SAD) 147 Each entry within the SAD defines the parameters associated with each 148 established SA. Unless if the "populate from packet" (PFP) flag is 149 asserted for a particular field, SAD entries are determined by the 150 corresponding SPD entries during the creation of the SA. 152 The data items contained within the SAD are defined in [IPSEC], 153 Section 4.4.2.1. To support RoHC, this list of data items is 154 augmented to include a "RoHC Data Item" field that defines the RoHC 155 parameters. These parameters (i.e., MAX_CID, PROFILES, MRRU, and 156 MAX_HEADER) are enumerated above in Section 2.1. The RoHC parameters 157 used for a given SA may be initialized manually (i.e., 158 administratively configured for manual SAs), or initialized via a key 159 exchange protocol (e.g. IKEv2 [IKEV2]) that has been extended to 160 support the negotiation of RoHC parameters [IKEV2EXT]. 162 3. Extensions to IPsec Processing 164 3.1. Addition to the IANA Protocol Numbers Registry 166 In order to demultiplex header-compressed from uncompressed traffic 167 on a RoHC-enabled SA, a "RoHC" value must be reserved in the IANA 168 Protocol Numbers registry. If an outbound packet has a compressed 169 header, the Next Header field of the security protocol header (e.g., 170 AH [AH], ESP [ESP]) must be set to the "RoHC" protocol identifer. If 171 the packet header has not been compressed, the Next Header field 172 remains unaltered. Conversely, for an inbound packet, the value of 173 the security protocol Next Header field is checked to determine if 174 the packet maintains a RoHC header. 176 3.2. Nested IPComp and RoHCoIPsec Processing 178 IPComp ([IPCOMP]) is another mechanism that can be implemented to 179 reduce the size of an IP datagram. If IPComp and RoHCoIPsec are 180 implemented in a nested fashion, the order of the outbound and 181 inbound processing steps must be carefully enumerated. 183 For outbound packets that are to be processed by IPcomp and RoHC: 184 o IPComp is applied, and the packet is sent to RoHC module 185 o The appropriate RoHC compression profile (e.g., RoHC IP-only) is 186 applied to the packet 187 o The security protocol is applied to the packet 189 Conversely, for inbound packets that are to be both RoHC- and IPcomp- 190 decompressed: 191 o A packet received on a RoHC-enabled SA is IPsec-processed 192 o Subsequently, the packet is sent to the RoHC module for header 193 decompression 194 o The datagram is decompressed based on the appropriate IPComp 195 algorithm 197 4. Security Considerations 199 A malfunctioning RoHC compressor (i.e., the compressor located at the 200 ingress of the IPsec tunnel) has the ability to send packets to the 201 decompressor (i.e., the decompressor located at the egress of the 202 IPsec tunnel) that do not match the original packets emitted from the 203 end-hosts. Such a scenario will result in a decreased efficiency 204 between compressor and decompressor. Furthermore, this may result in 205 Denial of Service, as the decompression of a significant number of 206 invalid packets may drain the resources of an IPsec device. 208 5. IANA Considerations 210 IANA is requested to allocate one value within the "Protocol Numbers" 211 registry [PROTOCOL] for "RoHC". This value will be used to indicate 212 that the next level protocol header is a RoHC header. 214 6. Acknowledgments 216 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 217 Ms. Linda Noone of the Department of Defense, and Mr. A. Rich Espy of 218 OPnet for their contributions and support for developing this 219 document. In addition, the authors would like to thank Mr. Rohan 220 Jasani for his valuable assistance. 222 7. References 224 7.1. Normative References 226 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 227 Internet Protocol", RFC 4301, December 2005. 229 [ROHCOIPSEC] 230 Ertekin, E. and C. Christou, "Integration of Header 231 Compression over IPsec Security Associations", work in 232 progress , February 2007. 234 [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 235 Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., 236 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 237 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 238 Compression (ROHC): Framework and four profiles: RTP, UDP, 239 ESP, and uncompressed", RFC 3095, July 2001. 241 [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload 242 Compression Protocol (IPComp)", RFC 3173, September 2001. 244 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 245 RFC 4306, December 2005. 247 [IKEV2EXT] 248 Pezeshki, J., Ertekin, E., and C. Christou, "Extensions to 249 IKEv2 to Support Robust Header Compression over IPsec 250 (RoHCoIPsec)", work in progress , February 2007. 252 [AH] Kent, S., "IP Authentication Header", RFC 4302, 253 December 2005. 255 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 256 RFC 4303, December 2005. 258 7.2. Informative References 260 [ROHCPROF] 261 "RObust Header Compression (ROHC) Profile Identifiers", 262 www.iana.org/assignments/rohc-pro-ids , October 2005. 264 [PROTOCOL] 265 IANA, ""Assigned Internet Protocol Numbers", IANA registry 266 at: http://www.iana.org/assignments/protocol-numbers". 268 Authors' Addresses 270 Emre Ertekin 271 Booz Allen Hamilton 272 13200 Woodland Park Dr. 273 Herndon, VA 20171 274 US 276 Email: ertekin_emre@bah.com 278 Michele Casey 279 Booz Allen Hamilton 280 13200 Woodland Park Dr. 281 Herndon, VA 20171 282 US 284 Email: casey_michele@bah.com 286 Jonah Pezeshki 287 Booz Allen Hamilton 288 13200 Woodland Park Dr. 289 Herndon, VA 20171 290 US 292 Email: pezeshki_jonah@bah.com 293 Chris Christou 294 Booz Allen Hamilton 295 13200 Woodland Park Dr. 296 Herndon, VA 20171 297 US 299 Email: christou_chris@bah.com 301 Full Copyright Statement 303 Copyright (C) The IETF Trust (2007). 305 This document is subject to the rights, licenses and restrictions 306 contained in BCP 78, and except as set forth therein, the authors 307 retain all their rights. 309 This document and the information contained herein are provided on an 310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 312 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 313 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 314 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 317 Intellectual Property 319 The IETF takes no position regarding the validity or scope of any 320 Intellectual Property Rights or other rights that might be claimed to 321 pertain to the implementation or use of the technology described in 322 this document or the extent to which any license under such rights 323 might or might not be available; nor does it represent that it has 324 made any independent effort to identify any such rights. Information 325 on the procedures with respect to rights in RFC documents can be 326 found in BCP 78 and BCP 79. 328 Copies of IPR disclosures made to the IETF Secretariat and any 329 assurances of licenses to be made available, or the result of an 330 attempt made to obtain a general license or permission for the use of 331 such proprietary rights by implementers or users of this 332 specification can be obtained from the IETF on-line IPR repository at 333 http://www.ietf.org/ipr. 335 The IETF invites any interested party to bring to its attention any 336 copyrights, patents or patent applications, or other proprietary 337 rights that may cover technology that may be required to implement 338 this standard. Please address the information to the IETF at 339 ietf-ipr@ietf.org. 341 Acknowledgment 343 Funding for the RFC Editor function is provided by the IETF 344 Administrative Support Activity (IASA).