idnits 2.17.1 draft-ietf-rohc-hcoipsec-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2, 2010) is 5189 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4995 (ref. 'ROHC') (Obsoleted by RFC 5795) -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEV2') (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ertekin 3 Internet-Draft R. Jasani 4 Intended status: Informational C. Christou 5 Expires: August 6, 2010 Booz Allen Hamilton 6 C. Bormann 7 Universitaet Bremen TZI 8 February 2, 2010 10 Integration of Robust Header Compression over IPsec Security 11 Associations 12 draft-ietf-rohc-hcoipsec-13 14 Abstract 16 IP Security (IPsec) provides various security services for IP 17 traffic. However, the benefits of IPsec come at the cost of 18 increased overhead. This document outlines a framework for 19 integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). 20 By compressing the inner headers of IP packets, ROHCoIPsec proposes 21 to reduce the amount of overhead associated with the transmission of 22 traffic over IPsec Security Associations (SAs). 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on August 6, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 78 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 5 79 5. Overview of the ROHCoIPsec Framework . . . . . . . . . . . 6 80 5.1. ROHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 6 81 5.2. Summary of the ROHCoIPsec Framework . . . . . . . . . . . 6 82 6. Details of the ROHCoIPsec Framework . . . . . . . . . . . 8 83 6.1. ROHC and IPsec Integration . . . . . . . . . . . . . . . . 8 84 6.1.1. Header Compression Protocol Considerations . . . . . . . . 10 85 6.1.2. Initialization and Negotiation of the ROHC Channel . . . . 10 86 6.1.3. Encapsulation and Identification of Header Compressed 87 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 6.1.4. Motivation for the ROHC ICV . . . . . . . . . . . . . . . 12 89 6.1.5. Path MTU Considerations . . . . . . . . . . . . . . . . . 12 90 6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 13 91 7. Security Considerations . . . . . . . . . . . . . . . . . 13 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 13 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 14 94 10. Informative References . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 This document outlines a framework for integrating ROHC [ROHC] over 100 IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the 101 protocol overhead associated with packets traversing between IPsec SA 102 endpoints. This can be achieved by compressing the transport layer 103 header (e.g., UDP, TCP, etc.) and inner IP header of packets at the 104 ingress of the IPsec tunnel, and decompressing these headers at the 105 egress. 107 For ROHCoIPsec, this document assumes that ROHC will be used to 108 compress the inner headers of IP packets traversing an IPsec tunnel. 109 However, since current specifications for ROHC detail its operation 110 on a hop-by-hop basis, it requires extensions to enable its operation 111 over IPsec SAs. This document outlines a framework for extending the 112 usage of ROHC to operate at IPsec SA endpoints. 114 ROHCoIPsec targets the application of ROHC to tunnel mode SAs. 115 Transport mode SAs only encrypt/authenticate the payload of an IP 116 packet, leaving the IP header untouched. Intermediate routers 117 subsequently use this IP header to route the packet to a decryption 118 device. Therefore, if ROHC is to operate over IPsec transport-mode 119 SAs, (de)compression functionality can only be applied to the 120 transport layer headers, and not to the IP header. Because current 121 ROHC specifications do not include support for the compression of 122 transport layer headers alone, the ROHCoIPsec framework outlined by 123 this document describes the application of ROHC to tunnel mode SAs. 125 2. Audience 127 The authors target members of both the ROHC and IPsec communities who 128 may consider extending the ROHC and IPsec protocols to meet the 129 requirements put forth in this document. In addition, this document 130 is directed towards vendors developing IPsec devices that will be 131 deployed in bandwidth-constrained IP networks. 133 3. Terminology 135 ROHC Process 137 Generic reference to a ROHC instance (as defined in RFC 3759 138 [ROHC-TERM]), or any supporting ROHC components. 140 Compressed Traffic 141 Traffic that is processed through the ROHC compressor and 142 decompressor instances. Packet headers are compressed and 143 decompressed using a specific header compression profile. 145 Uncompressed Traffic 147 Traffic that is not processed by the ROHC compressor instance. 148 Instead, this type of traffic bypasses the ROHC process. 150 IPsec Process 152 Generic reference to the Internet Protocol Security (IPsec) 153 process. 155 Next Header 157 Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) 158 field. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [BRA97]. 164 4. Problem Statement: IPsec Packet Overhead 166 IPsec mechanisms provide various security services for IP networks. 167 However, the benefits of IPsec come at the cost of increased per- 168 packet overhead. For example, traffic flow confidentiality 169 (generally leveraged at security gateways) requires the tunneling of 170 IP packets between IPsec implementations. Although these IPsec 171 tunnels will effectively mask the source-destination patterns that an 172 intruder can ascertain, tunneling comes at the cost of increased 173 packet overhead. Specifically, an ESP tunnel mode SA applied to an 174 IPv6 flow results in at least 50 bytes of additional overhead per 175 packet. This additional overhead may be undesirable for many 176 bandwidth-constrained wireless and/or satellite communications 177 networks, as these types of infrastructure are not overprovisioned. 178 ROHC applied on a per-hop basis over bandwidth-constrained links will 179 also suffer from reduced performance when encryption is used on the 180 tunneled header, since encrypted headers cannot be compressed. 181 Consequently, the additional overhead incurred by an IPsec tunnel may 182 result in the inefficient utilization of bandwidth. 184 Packet overhead is particularly significant for traffic profiles 185 characterized by small packet payloads (e.g. various voice codecs). 186 If these small packets are afforded the security services of an IPsec 187 tunnel mode SA, the amount of per-packet overhead is increased. 189 Thus, a mechanism is needed to reduce the overhead associated with 190 such flows. 192 5. Overview of the ROHCoIPsec Framework 194 5.1. ROHCoIPsec Assumptions 196 The goal of ROHCoIPsec is to provide efficient transport of IP 197 packets between IPsec devices without compromising the security 198 services offered by IPsec. The ROHCoIPsec framework has been 199 developed based on the following assumptions: 200 o ROHC will be leveraged to reduce the amount of overhead associated 201 with unicast IP packets traversing an IPsec SA 202 o ROHC will be instantiated at the IPsec SA endpoints, and will be 203 applied on a per-SA basis 204 o Once the decompression operation completes, decompressed packet 205 headers will be identical to the original packet headers before 206 compression 208 5.2. Summary of the ROHCoIPsec Framework 210 ROHC reduces packet overhead in a network by exploiting intra- and 211 inter-packet redundancies of network and transport-layer header 212 fields of a flow. 214 Current ROHC protocol specifications compress packet headers on a 215 hop-by-hop basis. However, IPsec SAs are instantiated between two 216 IPsec endpoints. Therefore, various extensions to both ROHC and 217 IPsec need to be defined to ensure the successful operation of the 218 ROHC protocol at IPsec SA endpoints. 220 The specification of ROHC over IPsec SAs is straightforward, since SA 221 endpoints provide source/destination pairs where (de)compression 222 operations can take place. Compression of the inner IP and upper 223 layer protocol headers in such a manner offers a reduction of packet 224 overhead between the two SA endpoints. Since ROHC will now operate 225 between IPsec endpoints (over multiple intermediate nodes which are 226 transparent to an IPsec SA), it is imperative to ensure that its 227 performance will not be severely impacted due to increased packet 228 reordering and/or packet loss between the compressor and 229 decompressor. 231 In addition, ROHC can no longer rely on the underlying link layer for 232 ROHC channel parameter configuration and packet identification. The 233 ROHCoIPsec framework proposes that ROHC channel parameter 234 configuration is accomplished by an SA management protocol (e.g., 235 IKEv2 [IKEV2]), while identification of compressed header packets is 236 achieved through the Next Header field of the security protocol 237 (e.g., AH [AH], ESP [ESP]) header. 239 Using the ROHCoIPsec framework proposed below, outbound and inbound 240 IP traffic processing at an IPsec device needs to be modified. For 241 an outbound packet, a ROHCoIPsec implementation will compress 242 appropriate packet headers, and subsequently encrypt and/or 243 integrity-protect the packet. For tunnel mode SAs, compression may 244 be applied to the transport layer and the inner IP headers. For 245 inbound packets, an IPsec device must first decrypt and/or integrity- 246 check the packet. Then decompression of the inner packet headers is 247 performed. After decompression, the packet is checked against the 248 access controls imposed on all inbound traffic associated with the SA 249 (as specified in RFC 4301 [IPSEC]). 251 Note: Compression of inner headers is independent from compression 252 of the security protocol (e.g., ESP) and outer IP headers. ROHC 253 profiles have been defined to allow for the compression of the 254 security protocol and the outer IP header on a hop-by-hop basis. 255 The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4 256 ESP-processed packet [ESP] is shown below in Figure 1. 258 ----------------------------------------------------------- 259 IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP| 260 |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| 261 ----------------------------------------------------------- 262 |<-------(1)------->|<------(2)-------->| 264 (1) Compressed hop-by-hop by the ROHC [ROHC] ESP/IP profile 265 (2) Compressed end-to-end by the ROHCoIPsec [IPSEC-ROHC] 266 TCP/IP profile 268 Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an 269 IPv4 ESP-processed packet. 271 If IPsec NULL encryption is applied to packets, ROHC may still be 272 used to compress the inner headers at IPsec SA endpoints. However, 273 compression of these inner headers may pose challenges for 274 intermediary devices (e.g., traffic monitors, sampling/management 275 tools) that are inspecting the contents of ESP-NULL packets. For 276 example, policies on these devices may need to be updated to ensure 277 that packets that contain the ROHC protocol identifier are not 278 dropped. In addition, intermediary devices may require additional 279 functionality to determine the content of the header compressed 280 packets. 282 In certain scenarios, a ROHCoIPsec implementation may encounter UDP- 283 encapsulated ESP or IKE packets (i.e., packets that are traversing 284 NATs). For example, a ROHCoIPsec implementation may receive a UDP- 285 encapsulated ESP packet that contains an ESP/UDP/IP header chain. 286 Currently, ROHC profiles do not support compression of the entire 287 header chain associated with this packet; only the UDP/IP headers can 288 be compressed. 290 6. Details of the ROHCoIPsec Framework 292 6.1. ROHC and IPsec Integration 294 Figure 2 illustrates the components required to integrate ROHC with 295 the IPsec process, i.e., ROHCoIPsec. 297 +-------------------------------+ 298 | ROHC Module | 299 | | 300 | | 301 +-----+ | +-----+ +---------+ | 302 | | | | | | ROHC | | 303 --| A |---------| B |-----| Process |------> Path 1 304 | | | | | | | | (ROHC-enabled SA) 305 +-----+ | +-----+ +---------+ | 306 | | | | 307 | | |-------------------------> Path 2 308 | | | (ROHC-enabled SA, 309 | +-------------------------------+ but no compression) 310 | 311 | 312 | 313 | 314 +-----------------------------------------> Path 3 315 (ROHC-disabled SA) 317 Figure 2. Integration of ROHC with IPsec. 319 The process illustrated in Figure 2 augments the IPsec processing 320 model for outbound IP traffic (protected-to-unprotected). Initial 321 IPsec processing is consistent with RFC 4301 [IPSEC] (Steps 1-2, 322 Section 5.1). 324 Block A: The ROHC data item (part of the SA state information) 325 retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1, 326 Step3a) determines if the traffic traversing the SA is handed to the 327 ROHC module. Packets selected to a ROHC-disabled SA MUST follow 328 normal IPsec processing and MUST NOT be sent to the ROHC module 329 (Figure 2, Path 3). Conversely, packets selected to a ROHC-enabled 330 SA MUST be sent to the ROHC module. 332 Block B: This step determines if the packet can be compressed. If 333 the packet is compressed, an Integrity Algorithm MAY be used to 334 compute an Integrity Check Value (ICV) for the uncompressed packet 335 ([IPSEC-ROHC], Section 4.2; [IKE-ROHC], Section 3.1). The Next 336 Header field of the security protocol header (e.g., ESP, AH) MUST be 337 populated with a "ROHC" protocol number [PROTOCOL], inner packet 338 headers MUST be compressed, and the computed ICV MAY be appended to 339 the packet (Figure 2, Path 1). However, if it is determined that the 340 packet will not be compressed (e.g., due to one the reasons described 341 in Section 6.1.3), the Next Header field MUST be populated with the 342 appropriate value indicating the next level protocol (Figure 2, Path 343 2), and ROHC processing MUST NOT be applied to the packet. 345 After the ROHC process completes, IPsec processing resumes, as 346 described in Section 5.1, Step3a, of RFC 4301 [IPSEC]. 348 The process illustrated in Figure 2 also augments the IPsec 349 processing model for inbound IP traffic (unprotected-to-protected). 350 For inbound packets, IPsec processing is performed ([IPSEC], Section 351 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 352 5.2, Step 4). 354 Block A: After AH or ESP processing, the ROHC data item retrieved 355 from the SAD entry will indicate if traffic traversing the SA is 356 processed by the ROHC module ([IPSEC], Section 5.2, Step 3a). 357 Packets traversing a ROHC-disabled SA MUST follow normal IPsec 358 processing and MUST NOT be sent to the ROHC module. Conversely, 359 packets traversing a ROHC-enabled SA MUST be sent to the ROHC module. 361 Block B: The decision at Block B is determined by the value of the 362 Next Header field of the security protocol header. If the Next 363 Header field does not indicate a ROHC header, the decompressor MUST 364 NOT attempt decompression (Figure 2, Path 2). If the Next Header 365 field indicates a ROHC header, decompression is applied. After 366 decompression, the signaled ROHCoIPsec Integrity Algorithm, MAY be 367 used to compute an ICV value for the decompressed packet. This ICV, 368 if present, is compared to the ICV that was calculated at the 369 compressor: if the ICVs match, the packet is forwarded by the ROHC 370 module (Figure 2, Path 1); otherwise, the packet MUST be dropped. 371 Once the ROHC module completes processing, IPsec processing resumes, 372 as described in Section 5.2, Step 4 of RFC 4301 [IPSEC]. 374 When there is a single SA between a compressor and decompressor, ROHC 375 MUST operate in unidirectional mode, as described in Section 5 of RFC 376 3759 [ROHC-TERM]. When there is a pair of SAs instantiated between 377 ROHCoIPsec implementations, ROHC MAY operate in bidirectional mode, 378 where an SA pair represents a bidirectional ROHC channel (as 379 described in Section 6.1 and 6.2 of RFC 3759[ROHC-TERM]). 381 Note that to further reduce the size of an IPsec-protected packet, 382 ROHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested 383 fashion. This process is detailed in [IPSEC-ROHC], Section 4.4. 385 6.1.1. Header Compression Protocol Considerations 387 ROHCv2 [ROHCV2] profiles include various mechanisms that provide 388 increased robustness over reordering channels. These mechanisms 389 SHOULD be adopted for ROHC to operate efficiently over IPsec SAs. 391 A ROHC decompressor implemented within IPsec architecture MAY 392 leverage additional mechanisms to improve performance over reordering 393 channels (either due to random events, or to an attacker 394 intentionally reordering packets). Specifically, IPsec's sequence 395 number MAY be used by the decompressor to identify a packet as 396 "sequentially late". This knowledge will increase the likelihood of 397 successful decompression of a reordered packet. 399 Additionally, ROHCoIPsec implementations SHOULD minimize the amount 400 of feedback sent from the decompressor to the compressor. If a ROHC 401 feedback channel is not used sparingly, the overall gains from 402 ROHCoIPsec can be significantly reduced. More specifically, any 403 feedback sent from the decompressor to the compressor MUST be 404 processed by IPsec, and tunneled back to the compressor (as 405 designated by the SA associated with FEEDBACK_FOR). As such, some 406 implementation alternatives can be considered, including the 407 following: 408 o Eliminate feedback traffic altogether by operating only in ROHC 409 Unidirectional mode (U-mode) 410 o Piggyback ROHC feedback messages within the feedback element 411 (i.e., on ROHC traffic that normally traverses the SA designated 412 by FEEDBACK_FOR). 414 6.1.2. Initialization and Negotiation of the ROHC Channel 416 Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) 417 to negotiate ROHC channel parameters. In the case of ROHCoIPsec, 418 channel parameters can be set manually (i.e., administratively 419 configured for manual SAs), or negotiated by IKEv2. The extensions 420 required for IKEv2 to support ROHC channel parameter negotiation are 421 detailed in [IKE-ROHC]. 423 If the ROHC protocol requires bidirectional communications, two SAs 424 MUST be instantiated between the IPsec implementations. One of the 425 two SAs is used for carrying ROHC-traffic from the compressor to the 426 decompressor, while the other is used to communicate ROHC-feedback 427 from the decompressor to the compressor. Note that the requirement 428 for two SAs aligns with the operation of IKE, which creates SAs in 429 pairs by default. However, IPsec implementations will dictate how 430 decompressor feedback received on one SA is associated with a 431 compressor on the other SA. An IPsec implementation MUST relay the 432 feedback received by the decompressor on an inbound SA to the 433 compressor associated with the corresponding outbound SA. 435 6.1.3. Encapsulation and Identification of Header Compressed Packets 437 As indicated in Section 6.1, new state information (i.e., a new ROHC 438 data item) is defined for each SA. The ROHC data item MUST be used 439 by the IPsec process to determine whether it sends all traffic 440 traversing a given SA to the ROHC module (ROHC-enabled) or bypasses 441 the ROHC module and sends the traffic through regular IPsec 442 processing (ROHC- disabled). 444 The Next Header field of the IPsec security protocol (e.g., AH or 445 ESP) header MUST be used to demultiplex header-compressed traffic 446 from uncompressed traffic traversing an ROHC-enabled SA. This 447 functionality is needed in situations where packets traversing a 448 ROHC-enabled SA contain uncompressed headers. Such situations may 449 occur when, for example, a compressor supports strictly n compressed 450 flows and cannot compress the n+1 flow that arrives. Another example 451 is when traffic is selected to a ROHC-enabled SA, but cannot be 452 compressed by the ROHC process because the appropriate ROHC Profile 453 has not been signaled for use. As a result, the decompressor MUST be 454 able to identify packets with uncompressed headers and MUST NOT 455 attempt to decompress them. The Next Header field is used to 456 demultiplex these header-compressed and uncompressed packets where 457 the ROHC protocol number will indicate that the packet contains 458 compressed headers. To accomplish this, an official IANA allocation 459 from the Protocol ID registry [PROTOCOL] is required. 461 It is noted that the use of the ROHC protocol identifier for purposes 462 other than ROHCoIPsec is currently not defined. In other words, the 463 ROHC protocol identifier is only defined for use in the next header 464 field of security protocol headers (e.g., ESP, AH). 466 The ROHC Data Item, IANA Protocol ID allocation, and other IPsec 467 extensions to support ROHCoIPsec, are specified in [IPSEC-ROHC]. 469 6.1.4. Motivation for the ROHC ICV 471 Although ROHC was designed to tolerate packet loss and reordering, 472 the algorithm does not guarantee that packets reconstructed at the 473 decompressor are identical to the original packet. As stated in 474 Section 5.2 of RFC 4224 [REORDR], the consequences of packet 475 reordering between ROHC peers may include undetected decompression 476 failures, where erroneous packets are constructed and forwarded to 477 upper layers. Significant packet loss can have similar consequences. 479 When using IPsec integrity protection, a packet received at the 480 egress of an IPsec tunnel is identical to the packet that was 481 processed at the ingress (given that the key is not compromised, 482 etc.). 484 When ROHC is integrated into the IPsec processing framework, the ROHC 485 processed packet is protected by the AH/ESP ICV. However, bits in 486 the original IP header are not protected by this ICV, only by ROHC's 487 integrity mechanisms (which are designed for random packet loss/ 488 reordering, not malicious packet loss/reordering introduced by an 489 attacker). Therefore, under certain circumstances, erroneous packets 490 may be constructed and forwarded into the protected domain. 492 To ensure the integrity of the original IP header within the 493 ROHCoIPsec-processing model, an additional integrity check MAY be 494 applied before the packet is compressed. This integrity check will 495 ensure that erroneous packets are not forwarded into the protected 496 domain. The specifics of this integrity check are documented in 497 Section 4.2 of [IPSEC-ROHC]. 499 6.1.5. Path MTU Considerations 501 By encapsulating IP packets with AH/ESP and tunneling IP headers, 502 IPsec increases the size of IP packets. This increase may result in 503 Path MTU issues in the unprotected domain. Several approaches to 504 resolving these path MTU issues are documented in Section 8 of RFC 505 4301[IPSEC]; approaches include fragmenting the packet before or 506 after IPsec processing (if the packet's DF bit is clear), or possibly 507 discarding packets (if the packet's DF bit is set). 509 The addition of ROHC within the IPsec processing model may result in 510 a similar path MTU challenges. For example, under certain 511 circumstances, ROHC headers are larger than the original uncompressed 512 headers. In addition, if an integrity algorithm is used to validate 513 packet headers, the resulting ICV will increase the size of packets. 514 Both of these properties of ROHCoIPsec increase the size of packets, 515 and therefore may result in additional challenges associated with 516 path MTU. 518 Approaches to addressing these path MTU issues are specified in 519 Section 4.3 of [IPSEC-ROHC]. 521 6.2. ROHCoIPsec Framework Summary 523 To summarize, the following items are needed to achieve ROHCoIPsec: 524 o IKEv2 Extensions to Support ROHCoIPsec 525 o IPsec Extensions to Support ROHCoIPsec 527 7. Security Considerations 529 Several security considerations associated with the use of ROHCoIPsec 530 are covered in Section 6.1.4. These considerations can be mitigated 531 by using strong a integrity check algorithm to ensure the valid 532 decompression of packet headers. 534 A malfunctioning or malicious ROHCoIPsec compressor (i.e., the 535 compressor located at the ingress of the IPsec tunnel) has the 536 ability to send erroneous packets to the decompressor (i.e., the 537 decompressor located at the egress of the IPsec tunnel) that do not 538 match the original packets emitted from the end-hosts. Such a 539 scenario may result in decreased efficiency between compressor and 540 decompressor, or may cause the decompressor to forward erroneous 541 packets into the protected domain. A malicious compressor could also 542 intentionally generate a significant number of compressed packets, 543 which may result in denial of service at the decompressor, as the 544 decompression of a significant number of invalid packets may drain 545 the resources of an IPsec device. 547 A malfunctioning or malicious ROHCoIPsec decompressor has the ability 548 to disrupt communications as well. For example, a decompressor may 549 simply discard a subset of (or all) the packets that are received, 550 even if packet headers were validly decompressed. Ultimately, this 551 could result in denial of service. A malicious decompressor could 552 also intentionally indicate that its context is not synchronized with 553 the compressor's context, forcing the compressor to transition to a 554 lower compression state. This will reduce the overall efficiency 555 gain offered by ROHCoIPsec. 557 8. IANA Considerations 559 This draft has no IANA considerations. All IANA considerations for 560 ROHCoIPsec are documented in [IKE-ROHC] and [IPSEC-ROHC]. 562 9. Acknowledgments 564 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 565 and Ms. Linda Noone of the Department of Defense, and well as Mr. 566 Rich Espy of OPnet for their contributions and support in the 567 development of this document. 569 The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A 570 Stangarone Jr.: both served as committed document reviewers for this 571 specification. 573 In addition, the authors would like to thank the following for their 574 numerous reviews and comments to this document: 576 o Mr. Magnus Westerlund 577 o Dr. Stephen Kent 578 o Mr. Pasi Eronen 579 o Dr. Joseph Touch 580 o Mr. Tero Kivinen 581 o Dr. Jonah Pezeshki 582 o Mr. Lars-Erik Jonsson 583 o Mr. Jan Vilhuber 584 o Mr. Dan Wing 585 o Mr. Kristopher Sandlund 586 o Mr. Ghyslain Pelletier 587 o Mr. David Black 588 o Mr. Tim Polk 589 o Mr. Brian Carpenter 591 Finally, the authors would also like to thank Mr. Tom Conkle, Ms. 592 Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen 593 Hamilton for their assistance in completing this work. 595 10. Informative References 597 [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 598 Header Compression (ROHC) Framework", RFC 4995, July 2007. 600 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 601 Internet Protocol", RFC 4301, December 2005. 603 [ROHC-TERM] 604 Jonsson, L-E., "Robust Header Compression (ROHC): 605 Terminology and Channel Mapping Examples", RFC 3759, 606 April 2004. 608 [BRA97] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", RFC 2119, March 1997. 611 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 612 RFC 4306, December 2005. 614 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 615 RFC 4303, December 2005. 617 [AH] Kent, S., "IP Authentication Header", RFC 4302, 618 December 2005. 620 [IPSEC-ROHC] 621 Ertekin, E., Christou, C., and C. Bormann, "IPsec 622 Extensions to Support ROHCoIPsec", work in progress , 623 February 2010. 625 [IKE-ROHC] 626 Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. 627 Bormann, "IKEv2 Extensions to Support ROHCoIPsec", work in 628 progress , February 2010. 630 [PROTOCOL] 631 IANA, "Assigned Internet Protocol Numbers, IANA registry 632 at: http://www.iana.org/assignments/protocol-numbers", 633 June 2009. 635 [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload 636 Compression Protocol (IPComp)", RFC 3173, September 2001. 638 [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression 639 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP 640 Lite", RFC 5225, April 2008. 642 [REORDR] Pelletier, G., Jonsson, L-E., and K. Sandlund, "Robust 643 Header Compression (ROHC): ROHC over Channels That Can 644 Reorder Packets", RFC 4224, January 2006. 646 Authors' Addresses 648 Emre Ertekin 649 Booz Allen Hamilton 650 5220 Pacific Concourse Drive, Suite 200 651 Los Angeles, CA 90045 652 US 654 Email: ertekin_emre@bah.com 655 Rohan Jasani 656 Booz Allen Hamilton 657 13200 Woodland Park Dr. 658 Herndon, VA 20171 659 US 661 Email: ro@breakcheck.com 663 Chris Christou 664 Booz Allen Hamilton 665 13200 Woodland Park Dr. 666 Herndon, VA 20171 667 US 669 Email: christou_chris@bah.com 671 Carsten Bormann 672 Universitaet Bremen TZI 673 Postfach 330440 674 Bremen D-28334 675 Germany 677 Email: cabo@tzi.org