idnits 2.17.1 draft-ietf-rohc-hcoipsec-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (August 12, 2009) is 5363 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: February 13, 2010 Booz Allen Hamilton 6 C. Bormann 7 Universitaet Bremen TZI 8 August 12, 2009 10 Integration of Robust Header Compression (ROHC) over IPsec Security 11 Associations 12 draft-ietf-rohc-hcoipsec-11 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 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 February 13, 2010. 47 Copyright Notice 48 Copyright (c) 2009 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 in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 IP Security (IPsec) provides various security services for IP 60 traffic. However, the benefits of IPsec come at the cost of 61 increased overhead. This document outlines a framework for 62 integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). 63 By compressing the inner headers of IP packets, ROHCoIPsec proposes 64 to reduce the amount of overhead associated with the transmission of 65 traffic over IPsec Security Associations (SAs). 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 5 73 5. Overview of the ROHCoIPsec Framework . . . . . . . . . . . 6 74 5.1. ROHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 6 75 5.2. Summary of the ROHCoIPsec Framework . . . . . . . . . . . 6 76 6. Details of the ROHCoIPsec Framework . . . . . . . . . . . 7 77 6.1. ROHC and IPsec Integration . . . . . . . . . . . . . . . . 8 78 6.1.1. Header Compression Protocol Considerations . . . . . . . . 10 79 6.1.2. Initialization and Negotiation of the ROHC Channel . . . . 10 80 6.1.3. Encapsulation and Identification of Header Compressed 81 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 6.1.4. Path MTU Considerations . . . . . . . . . . . . . . . . . 11 83 6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 12 84 7. Security Considerations . . . . . . . . . . . . . . . . . 12 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 12 87 10. Informative References . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 This document outlines a framework for integrating ROHC [ROHC] over 93 IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the 94 protocol overhead associated with packets traversing between IPsec SA 95 endpoints. This can be achieved by compressing the transport layer 96 header (e.g., UDP, TCP, etc.) and inner IP header of packets at the 97 ingress of the IPsec tunnel, and decompressing these headers at the 98 egress. 100 For ROHCoIPsec, this document assumes that ROHC will be used to 101 compress the inner headers of IP packets traversing an IPsec tunnel. 102 However, since current specifications for ROHC detail its operation 103 on a hop-by-hop basis, it requires extensions to enable its operation 104 over IPsec SAs. These extensions need to account for increased 105 packet reordering and packet loss that may occur in the unprotected 106 domain. This document outlines a framework for extending the usage 107 of ROHC to operate at IPsec SA endpoints. 109 ROHCoIPsec targets the application of ROHC to tunnel mode SAs. 110 Transport mode SAs only encrypt/authenticate the payload of an IP 111 packet, leaving the IP header untouched. Intermediate routers 112 subsequently use this IP header to route the packet to a decryption 113 device. Therefore, if ROHC is to operate over IPsec transport-mode 114 SAs, (de)compression functionality can only be applied to the 115 transport layer headers, and not to the IP header. Because current 116 ROHC specifications do not include support for the compression of 117 transport layer headers alone, the ROHCoIPsec framework outlined by 118 this document describes the application of ROHC to tunnel mode SAs. 120 2. Audience 122 The authors target members of both the ROHC and IPsec communities who 123 may consider extending the ROHC and IPsec protocols to meet the 124 requirements put forth in this document. In addition, this document 125 is directed towards vendors developing IPsec devices that will be 126 deployed in bandwidth-constrained IP networks. 128 3. Terminology 130 Terminology specific to ROHCoIPsec is introduced in this section. 132 ROHC Process 133 Generic reference to a ROHC instance (as defined in [ROHC-TERM]), 134 or any supporting ROHC components. 136 Compressed Traffic 138 Traffic that is processed through the ROHC compressor and 139 decompressor instances. Packet headers are compressed and 140 decompressed using a specific header compression profile. 142 Uncompressed Traffic 144 Traffic that is not processed by the ROHC compressor instance. 145 Instead, this type of traffic bypasses the ROHC process. 147 IPsec Process 149 Generic reference to the Internet Protocol Security (IPsec) 150 process. 152 Next Header 154 Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) 155 field. 157 4. Problem Statement: IPsec Packet Overhead 159 IPsec mechanisms provide various security services for IP networks. 160 However, the benefits of IPsec come at the cost of increased per- 161 packet overhead. For example, traffic flow confidentiality 162 (generally leveraged at security gateways) requires the tunneling of 163 IP packets between IPsec implementations. Although these IPsec 164 tunnels will effectively mask the source-destination patterns that an 165 intruder can ascertain, tunneling comes at the cost of increased per- 166 packet overhead. Specifically, an ESP tunnel mode SA applied to an 167 IPv6 flow results in at least 50 bytes of additional overhead per 168 packet. This additional overhead may be undesirable for many 169 bandwidth-constrained wireless and/or satellite communications 170 networks, as these types of infrastructure are not overprovisioned. 171 ROHC applied on a per-hop basis over bandwidth-constrained links will 172 also suffer from reduced performance when encryption is used on the 173 tunneled header, since encrypted headers cannot be compressed. 174 Consequently, the additional overhead incurred by an IPsec tunnel may 175 result in the inefficient utilization of bandwidth. 177 Packet overhead is particularly significant for traffic profiles 178 characterized by small packet payloads (e.g. various voice codecs). 179 If these small packets are afforded the security services of an IPsec 180 tunnel mode SA, the amount of per-packet overhead is increased. 181 Thus, a mechanism is needed to reduce the overhead associated with 182 such flows. 184 5. Overview of the ROHCoIPsec Framework 186 5.1. ROHCoIPsec Assumptions 188 The goal of ROHCoIPsec is to provide efficient transport of IP 189 packets between IPsec devices without compromising the security 190 services offered by IPsec. The ROHCoIPsec framework has been 191 developed based on the following assumptions: 192 o ROHC will be leveraged to reduce the amount of overhead associated 193 with packets traversing an IPsec SA 194 o ROHC will be instantiated at the IPsec SA endpoints, and will be 195 applied on a per-SA basis 196 o Once the decompression operation completes, decompressed packet 197 headers will be identical to the original packet headers before 198 compression 200 5.2. Summary of the ROHCoIPsec Framework 202 ROHC reduces packet overhead in a network by exploiting intra- and 203 inter-packet redundancies of network and transport-layer header 204 fields of a flow. 206 Current ROHC protocol specifications compress packet headers on a 207 hop-by-hop basis. However, IPsec SAs are instantiated between two 208 IPsec endpoints. Therefore, various extensions to both ROHC and 209 IPsec need to be defined to ensure the successful operation of the 210 ROHC protocol at IPsec SA endpoints. 212 The specification of ROHC over IPsec SAs is straightforward, since SA 213 endpoints provide source/destination pairs where (de)compression 214 operations can take place. Compression of the inner IP and upper 215 layer protocol headers in such a manner offers a reduction of per- 216 packet protocol overhead between the two SA endpoints. Since ROHC 217 will now operate between IPsec endpoints (over multiple intermediate 218 nodes which are transparent to an IPsec SA), it is imperative to 219 ensure that its performance will not be severely impacted due to 220 increased packet reordering and/or packet loss between the compressor 221 and decompressor. 223 In addition, ROHC can no longer rely on the underlying link layer for 224 ROHC channel parameter configuration and packet identification. The 225 ROHCoIPsec framework proposes that ROHC channel parameter 226 configuration is accomplished by an SA management protocol (e.g., 227 IKEv2 [IKEV2]), while identification of compressed header packets is 228 achieved through the Next Header field of the security protocol 229 (e.g., AH [AH], ESP [ESP]) header. 231 Using the ROHCoIPsec framework proposed below, outbound and inbound 232 IP traffic processing at an IPsec device needs to be modified. For 233 an outbound packet, a ROHCoIPsec implementation will compress 234 appropriate packet headers, and subsequently encrypt and/or 235 integrity-protect the packet. For tunnel mode SAs, compression may 236 be applied to the transport layer and the inner IP headers. For 237 inbound packets, an IPsec device must first decrypt and/or integrity- 238 check the packet. Then decompression of the inner packet headers is 239 performed. After decompression, the packet is checked against the 240 access controls imposed on all inbound traffic associated with the SA 241 (as specified in [IPSEC]). 243 Note: Compression of inner headers is independent from compression 244 of the security protocol (e.g., ESP) and outer IP headers. ROHC 245 profiles have been defined to allow for the compression of the 246 security protocol and the outer IP header on a hop-by-hop basis. 247 The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4 248 ESP-processed packet [ESP] is shown below in Figure 1. 250 ----------------------------------------------------------- 251 IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP| 252 |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| 253 ----------------------------------------------------------- 254 |<-------(1)------->|<------(2)-------->| 256 (1) Compressed by ROHC ESP/IP profile 257 (2) Compressed by ROHCoIPsec TCP/IP profile 259 Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an 260 IPv4 ESP-processed packet. 262 If IPsec NULL encryption is applied to packets, ROHC may still be 263 applied to the inner headers at the IPsec SA endpoints. However, 264 this poses challenges for intermediary devices (within the 265 unprotected domain) inspecting ESP-NULL encrypted packets, since 266 these intermediary devices will require additional functionality to 267 determine the content of the ROHC packets. 269 6. Details of the ROHCoIPsec Framework 270 6.1. ROHC and IPsec Integration 272 Figure 2 illustrates the components required to integrate ROHC with 273 the IPsec process, i.e., ROHCoIPsec. 275 +-------------------------------+ 276 | ROHC Module | 277 | | 278 | | 279 +-----+ | +-----+ +---------+ | 280 | | | | | | ROHC | | 281 --| A |---------| B |-----| Process |------> Path 1 282 | | | | | | | | (ROHC-enabled SA) 283 +-----+ | +-----+ +---------+ | 284 | | | | 285 | | |-------------------------> Path 2 286 | | | (ROHC-enabled SA) 287 | +-------------------------------+ 288 | 289 | 290 | 291 | 292 +-----------------------------------------> Path 3 293 (ROHC-disabled SA) 295 Figure 2. Integration of ROHC with IPsec. 297 The process illustrated in Figure 2 augments the IPsec processing 298 model for outbound IP traffic (protected-to-unprotected). Initial 299 IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1). 301 Block A: The ROHC data item (part of the SA state information) 302 retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1, 303 Step3a) determines if the traffic traversing the SA is handed to the 304 ROHC module. Packets selected to a ROHC-disabled SA must follow 305 normal IPsec processing and must not be sent to the ROHC module 306 (Figure 1, Path 3). Conversely, packets selected to a ROHC-enabled 307 SA must be sent to the ROHC module. 309 Block B: This step determines if the packet can be compressed. If it 310 is determined that the packet will be compressed, an Integrity 311 Algorithm may be used to compute an Integrity Check Value (ICV) for 312 the uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], 313 Section 2.1). The Next Header field of the security protocol header 314 (e.g., ESP, AH) is populated with a "ROHC" protocol number 315 [PROTOCOL], inner packet headers are compressed, and the computed 316 ICV, if present, is appended to the packet (Figure 1, Path 1). 318 However, if it is determined that the packet will not be compressed 319 (e.g., due to one the reasons described in Section 6.1.3), the Next 320 Header field is populated with the appropriate value indicating the 321 next level protocol (Figure 1, Path 2), and no ROHC processing is 322 applied to the packet. 324 After the ROHC process completes, IPsec processing resumes, as 325 described in Section 5.1, Step3a, of [IPSEC]. 327 The process illustrated in Figure 2 also augments the IPsec 328 processing model for inbound IP traffic (unprotected-to-protected). 329 For inbound packets, IPsec processing is performed ([IPSEC], Section 330 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 331 5.2, Step 4). 333 Block A: After AH or ESP processing, the ROHC data item retrieved 334 from the SAD entry will indicate if traffic traversing the SA is 335 processed by the ROHC module ([IPSEC], Section 5.2, Step 3a). 336 Packets traversing an ROHC-disabled SA must follow normal IPsec 337 processing and must not be sent to the ROHC module. Conversely, 338 packets traversing an ROHC-enabled SA must be sent to the ROHC 339 module. 341 Block B: The decision at Block B is determined by the value of the 342 Next Header field of the security protocol header. If the Next 343 Header field does not indicate a ROHC header, the decompressor must 344 not attempt decompression (Figure 1, Path 2). If the Next Header 345 field indicates a ROHC header, decompression is applied. After 346 decompression, the signaled ROHCoIPsec Integrity Algorithm, if 347 present, is used to compute an ICV value for the decompressed packet. 348 This ICV, if present, is compared to the ICV that was calculated at 349 the compressor: if the ICVs match, the packet is forwarded by the 350 ROHC module (Figure 1, Path 1); otherwise, the packet is dropped. 351 Once the ROHC module completes processing, IPsec processing resumes, 352 as described in Section 5.2, Step 4 of [IPSEC]. 354 When there is a single SA between a compressor and decompressor, ROHC 355 operates in unidirectional mode, as described in Section 5 of [ROHC- 356 TERM]. When there is pair of SAs instantiated between ROHCoIPsec 357 implementations, ROHC may operate in bidirectional mode, where an SA 358 pair represents a bidirectional ROHC channel (as described in Section 359 6.1 and 6.2 of [ROHC-TERM]). 361 Note that to further reduce the size of an IPsec-protected packet, 362 ROHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested 363 fashion. This process is detailed in [IPSEC-ROHC], Section 3.2. 365 6.1.1. Header Compression Protocol Considerations 367 ROHCv2 [ROHCV2] profiles include various mechanisms that provide 368 increased robustness over reordering channels. These mechanisms must 369 be adopted for ROHC to operate efficiently over IPsec SAs. 371 A ROHC decompressor implemented within IPsec architecture may 372 leverage additional mechanisms to improve performance over reordering 373 channels (either due to random events, or to an attacker 374 intentionally reordering packets). Specifically, IPsec's sequence 375 number may be used by the decompressor to identify a packet as 376 "sequentially late". This knowledge will increase the likelihood of 377 successful decompression of a reordered packet. 379 Additionally, ROHCoIPsec implementations should minimize the amount 380 of feedback sent from the decompressor to the compressor. If a ROHC 381 feedback channel is not used sparingly, the overall gains from 382 ROHCoIPsec can be significantly reduced. More specifically, any 383 feedback sent from the decompressor to the compressor must be 384 processed by IPsec, and tunneled back to the compressor (as 385 designated by the SA associated with FEEDBACK_FOR). As such, some 386 implementation alternatives can be considered, including the 387 following: 388 o Eliminate feedback traffic altogether by operating only in ROHC 389 Unidirectional mode (U-mode) 390 o Piggyback ROHC feedback messages within the feedback element 391 (i.e., on ROHC traffic that normally traverses the SA designated 392 by FEEDBACK_FOR). 394 6.1.2. Initialization and Negotiation of the ROHC Channel 396 Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) 397 to negotiate ROHC channel parameters. In the case of ROHCoIPsec, 398 channel parameters can be set manually (i.e., administratively 399 configured for manual SAs), or negotiated by IKEv2. The extensions 400 required for IKEv2 to support ROHC channel parameter negotiation are 401 detailed in [IKE-ROHC]. 403 If the ROHC protocol requires bidirectional communications, two SAs 404 must be instantiated between the IPsec implementations. One of the 405 two SAs is used for carrying ROHC-traffic from the compressor to the 406 decompressor, while the other is used to communicate ROHC-feedback 407 from the decompressor to the compressor. Note that the requirement 408 for two SAs aligns with the operation of IKE, which creates SAs in 409 pairs by default. However, IPsec implementations will dictate how 410 decompressor feedback received on one SA is associated with a 411 compressor on the other SA. An IPsec implementation must relay the 412 feedback received by the decompressor on an inbound SA to the 413 compressor associated with the corresponding outbound SA. 415 6.1.3. Encapsulation and Identification of Header Compressed Packets 417 As indicated in Section 6.1, new state information (i.e., a new ROHC 418 data item) is defined for each SA. The ROHC data item is used by the 419 IPsec process to determine whether it sends all traffic traversing a 420 given SA to the ROHC module (ROHC-enabled) or bypasses the ROHC 421 module and sends the traffic through regular IPsec processing (ROHC- 422 disabled). 424 The Next Header field of the IPsec security protocol (e.g., AH or 425 ESP) header is used to demultiplex header-compressed traffic from 426 uncompressed traffic traversing an ROHC-enabled SA. This 427 functionality is needed in situations where packets traversing a 428 ROHC-enabled SA contain uncompressed headers. Such situations may 429 occur when, for example, a compressor supports strictly n compressed 430 flows and cannot compress the n+1 flow that arrives. Another example 431 is when traffic is selected to a ROHC-enabled SA, but cannot be 432 compressed by the ROHC process because the appropriate ROHC Profile 433 has not been signaled for use. As a result, the decompressor must be 434 able to identify packets with uncompressed headers and not attempt to 435 decompress them. The Next Header field is used to demultiplex these 436 header-compressed and uncompressed packets where the ROHC protocol 437 number will indicate that the packet contains compressed headers. To 438 accomplish this, an official IANA allocation from the Protocol ID 439 registry [PROTOCOL] is required. 441 The ROHC Data Item, IANA Protocol ID allocation, and other IPsec 442 extensions to support ROHCoIPsec, are specified in [IPSEC-ROHC]. 444 6.1.4. Path MTU Considerations 446 By encapsulating IP packets with AH/ESP and tunneling IP headers, 447 IPsec increases the size of IP packets. This increase may result in 448 Path MTU issues in the unprotected domain. Several approaches to 449 resolving these path MTU issues are documented in Section 8 of 450 [IPSEC]; approaches include fragmenting the packet before or after 451 IPsec processing (if the packet's DF bit is clear), or possibly 452 discarding packets (if the packet's DF bit is set). 454 The addition of ROHC within the IPsec processing model may result in 455 a similar path MTU challenges. For example, under certain 456 circumstances, ROHC headers are larger than the original uncompressed 457 headers. In addition, if an integrity algorithm is used to validate 458 packet headers post-decompression, this integrity algorithm will 459 increase the size of packets. Both of these properties of ROHCoIPsec 460 increase the size of packets, and therefore may result in additional 461 challenges associated with path MTU. 463 Approaches to addressing these ROHCoIPsec path MTU issues are 464 specified in Section 3.3 of [IPSEC-ROHC]. 466 6.2. ROHCoIPsec Framework Summary 468 To summarize, the following items are needed to achieve ROHCoIPsec: 469 o IKEv2 Extensions to Support ROHCoIPsec 470 o IPsec Extensions to Support ROHCoIPsec 472 7. Security Considerations 474 A malfunctioning ROHC compressor (i.e., the compressor located at the 475 ingress of the IPsec tunnel) has the ability to send packets to the 476 decompressor (i.e., the decompressor located at the egress of the 477 IPsec tunnel) that do not match the original packets emitted from the 478 end-hosts. Such a scenario will result in a decreased efficiency 479 between compressor and decompressor. Furthermore, this may result in 480 Denial of Service, as the decompression of a significant number of 481 invalid packets may drain the resources of an IPsec device. 483 8. IANA Considerations 485 None. 487 9. Acknowledgments 489 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 490 and Ms. Linda Noone of the Department of Defense, and well as Mr. 491 Rich Espy of OPnet for their contributions and support in the 492 development of this document. 494 The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A 495 Stangarone Jr.: both served as committed document reviewers for this 496 specification. 498 In addition, the authors would like to thank the following for their 499 numerous reviews and comments to this document: 501 o Mr. Magnus Westerlund 502 o Dr. Stephen Kent 503 o Mr. Pasi Eronen 504 o Dr. Joseph Touch 505 o Mr. Tero Kivinen 506 o Dr. Jonah Pezeshki 507 o Mr. Lars-Erik Jonsson 508 o Mr. Jan Vilhuber 509 o Mr. Dan Wing 510 o Mr. Kristopher Sandlund 511 o Mr. Ghyslain Pelletier 513 Finally, the authors would also like to thank Mr. Tom Conkle, Ms. 514 Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen 515 Hamilton for their assistance in completing this work. 517 10. Informative References 519 [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 520 Header Compression (ROHC) Framework", RFC 4995, July 2007. 522 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 523 Internet Protocol", RFC 4301, December 2005. 525 [ROHC-TERM] 526 Jonsson, L-E., "Robust Header Compression (ROHC): 527 Terminology and Channel Mapping Examples", RFC 3759, 528 April 2004. 530 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 531 RFC 4306, December 2005. 533 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 534 RFC 4303, December 2005. 536 [AH] Kent, S., "IP Authentication Header", RFC 4302, 537 December 2005. 539 [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload 540 Compression Protocol (IPComp)", RFC 3173, September 2001. 542 [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression 543 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP 544 Lite", RFC 5225, April 2008. 546 [IKE-ROHC] 547 Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. 548 Bormann, "IKEv2 Extensions to Support ROHCoIPsec", work in 549 progress , August 2009. 551 [PROTOCOL] 552 IANA, "Assigned Internet Protocol Numbers, IANA registry 553 at: http://www.iana.org/assignments/protocol-numbers". 555 [IPSEC-ROHC] 556 Ertekin, E., Christou, C., and C. Bormann, "IPsec 557 Extensions to Support ROHCoIPsec", work in progress , 558 August 2009. 560 Authors' Addresses 562 Emre Ertekin 563 Booz Allen Hamilton 564 13200 Woodland Park Dr. 565 Herndon, VA 20171 566 US 568 Email: ertekin_emre@bah.com 570 Rohan Jasani 571 Booz Allen Hamilton 572 13200 Woodland Park Dr. 573 Herndon, VA 20171 574 US 576 Email: ro@breakcheck.com 578 Chris Christou 579 Booz Allen Hamilton 580 13200 Woodland Park Dr. 581 Herndon, VA 20171 582 US 584 Email: christou_chris@bah.com 586 Carsten Bormann 587 Universitaet Bremen TZI 588 Postfach 330440 589 Bremen D-28334 590 Germany 592 Email: cabo@tzi.org