idnits 2.17.1 draft-ietf-rohc-hcoipsec-10.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 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 (February 2, 2009) is 5561 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 (==), 5 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, 2009 Booz Allen Hamilton 6 C. Bormann 7 Universitaet Bremen TZI 8 February 2, 2009 10 Integration of Robust Header Compression (ROHC) over IPsec Security 11 Associations 12 draft-ietf-rohc-hcoipsec-10 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. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 6, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 IP Security (IPsec) provides various security services for IP 52 traffic. However, the benefits of IPsec come at the cost of 53 increased overhead. This document outlines a framework for 54 integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec). 55 By compressing the inner headers of IP packets, ROHCoIPsec proposes 56 to reduce the amount of overhead associated with the transmission of 57 traffic over IPsec Security Associations (SAs). 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 65 5. Overview of the ROHCoIPsec Framework . . . . . . . . . . . 5 66 5.1. ROHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5 67 5.2. Summary of the ROHCoIPsec Framework . . . . . . . . . . . 5 68 6. Details of the ROHCoIPsec Framework . . . . . . . . . . . 6 69 6.1. ROHC and IPsec Integration . . . . . . . . . . . . . . . . 7 70 6.1.1. Header Compression Protocol Considerations . . . . . . . . 9 71 6.1.2. Initialization and Negotiation of the ROHC Channel . . . . 9 72 6.1.3. Encapsulation and Identification of Header Compressed 73 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.2. ROHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 75 7. Security Considerations . . . . . . . . . . . . . . . . . 10 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 78 10. Informative References . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 This document outlines a framework for integrating ROHC [ROHC] over 84 IPsec [IPSEC] (ROHCoIPsec). The goal of ROHCoIPsec is to reduce the 85 protocol overhead associated with packets traversing between IPsec SA 86 endpoints. This can be achieved by compressing the transport layer 87 header (e.g., UDP, TCP, etc.) and inner IP header of packets at the 88 ingress of the IPsec tunnel, and decompressing these headers at the 89 egress. 91 For ROHCoIPsec, this document assumes that ROHC will be used to 92 compress the inner headers of IP packets traversing an IPsec tunnel. 93 However, since current specifications for ROHC detail its operation 94 on a hop-by-hop basis, it requires extensions to enable its operation 95 over IPsec SAs. These extensions need to account for increased 96 packet reordering and packet loss that may occur in the unprotected 97 domain. This document outlines a framework for extending the usage 98 of ROHC to operate at IPsec SA endpoints. 100 ROHCoIPsec targets the application of ROHC to tunnel mode SAs. 101 Transport mode SAs only encrypt/authenticate the payload of an IP 102 packet, leaving the IP header untouched. Intermediate routers 103 subsequently use this IP header to route the packet to a decryption 104 device. Therefore, if ROHC is to operate over IPsec transport-mode 105 SAs, (de)compression functionality can only be applied to the 106 transport layer headers, and not to the IP header. Because current 107 ROHC specifications do not include support for the compression of 108 transport layer headers alone, the ROHCoIPsec framework outlined by 109 this document describes the application of ROHC to tunnel mode SAs. 111 2. Audience 113 The authors target members of both the ROHC and IPsec communities who 114 may consider extending the ROHC and IPsec protocols to meet the 115 requirements put forth in this document. In addition, this document 116 is directed towards vendors developing IPsec devices that will be 117 deployed in bandwidth-constrained IP networks. 119 3. Terminology 121 Terminology specific to ROHCoIPsec is introduced in this section. 123 ROHC Process 124 Generic reference to a ROHC instance (as defined in [ROHC-TERM]), 125 or any supporting ROHC components. 127 Compressed Traffic 129 Traffic that is processed through the ROHC compressor and 130 decompressor instances. Packet headers are compressed and 131 decompressed using a specific header compression profile. 133 Uncompressed Traffic 135 Traffic that is not processed by the ROHC compressor instance. 136 Instead, this type of traffic bypasses the ROHC process. 138 IPsec Process 140 Generic reference to the Internet Protocol Security (IPsec) 141 process. 143 Next Header 145 Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) 146 field. 148 4. Problem Statement: IPsec Packet Overhead 150 IPsec mechanisms provide various security services for IP networks. 151 However, the benefits of IPsec come at the cost of increased per- 152 packet overhead. For example, traffic flow confidentiality 153 (generally leveraged at security gateways) requires the tunneling of 154 IP packets between IPsec implementations. Although these IPsec 155 tunnels will effectively mask the source-destination patterns that an 156 intruder can ascertain, tunneling comes at the cost of increased per- 157 packet overhead. Specifically, an ESP tunnel mode SA applied to an 158 IPv6 flow results in at least 50 bytes of additional overhead per 159 packet. This additional overhead may be undesirable for many 160 bandwidth-constrained wireless and/or satellite communications 161 networks, as these types of infrastructure are not overprovisioned. 162 ROHC applied on a per-hop basis over bandwidth-constrained links will 163 also suffer from reduced performance when encryption is used on the 164 tunneled header, since encrypted headers cannot be compressed. 165 Consequently, the additional overhead incurred by an IPsec tunnel may 166 result in the inefficient utilization of bandwidth. 168 Packet overhead is particularly significant for traffic profiles 169 characterized by small packet payloads (e.g. various voice codecs). 170 If these small packets are afforded the security services of an IPsec 171 tunnel mode SA, the amount of per-packet overhead is increased. 172 Thus, a mechanism is needed to reduce the overhead associated with 173 such flows. 175 5. Overview of the ROHCoIPsec Framework 177 5.1. ROHCoIPsec Assumptions 179 The goal of ROHCoIPsec is to provide efficient transport of IP 180 packets between IPsec devices without compromising the security 181 services offered by IPsec. The ROHCoIPsec framework has been 182 developed based on the following assumptions: 183 o ROHC will be leveraged to reduce the amount of overhead associated 184 with packets traversing an IPsec SA 185 o ROHC will be instantiated at the IPsec SA endpoints, and will be 186 applied on a per-SA basis 187 o Once the decompression operation completes, decompressed packet 188 headers will be identical to the original packet headers before 189 compression 191 5.2. Summary of the ROHCoIPsec Framework 193 ROHC reduces packet overhead in a network by exploiting intra- and 194 inter-packet redundancies of network and transport-layer header 195 fields of a flow. 197 Current ROHC protocol specifications compress packet headers on a 198 hop-by-hop basis. However, IPsec SAs are instantiated between two 199 IPsec endpoints. Therefore, various extensions to both ROHC and 200 IPsec need to be defined to ensure the successful operation of the 201 ROHC protocol at IPsec SA endpoints. 203 The specification of ROHC over IPsec SAs is straightforward, since SA 204 endpoints provide source/destination pairs where (de)compression 205 operations can take place. Compression of the inner IP and upper 206 layer protocol headers in such a manner offers a reduction of per- 207 packet protocol overhead between the two SA endpoints. Since ROHC 208 will now operate between IPsec endpoints (over multiple intermediate 209 nodes which are transparent to an IPsec SA), it is imperative to 210 ensure that its performance will not be severely impacted due to 211 increased packet reordering and/or packet loss between the compressor 212 and decompressor. 214 In addition, ROHC can no longer rely on the underlying link layer for 215 ROHC channel parameter configuration and packet identification. The 216 ROHCoIPsec framework proposes that ROHC channel parameter 217 configuration is accomplished by an SA management protocol (e.g., 218 IKEv2 [IKEV2]), while identification of compressed header packets is 219 achieved through the Next Header field of the security protocol 220 (e.g., AH [AH], ESP [ESP]) header. 222 Using the ROHCoIPsec framework proposed below, outbound and inbound 223 IP traffic processing at an IPsec device needs to be modified. For 224 an outbound packet, a ROHCoIPsec implementation will compress 225 appropriate packet headers, and subsequently encrypt and/or 226 integrity-protect the packet. For tunnel mode SAs, compression may 227 be applied to the transport layer and the inner IP headers. For 228 inbound packets, an IPsec device must first decrypt and/or integrity- 229 check the packet. Then decompression of the inner packet headers is 230 performed. After decompression, the packet is checked against the 231 access controls imposed on all inbound traffic associated with the SA 232 (as specified in [IPSEC]). 234 Note: Compression of inner headers is independent from compression 235 of the security protocol (e.g., ESP) and outer IP headers. ROHC 236 profiles have been defined to allow for the compression of the 237 security protocol and the outer IP header on a hop-by-hop basis. 238 The applicability of ROHCoIPsec and hop-by-hop ROHC on an IPv4 239 ESP-processed packet [ESP] is shown below in Figure 1. 241 ----------------------------------------------------------- 242 IPv4 | new IP hdr | | orig IP hdr | | | ESP | ESP| 243 |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| 244 ----------------------------------------------------------- 245 |<-------(1)------->|<------(2)-------->| 247 (1) Compressed by ROHC ESP/IP profile 248 (2) Compressed by ROHCoIPsec TCP/IP profile 250 Figure 1. Applicability of hop-by-hop ROHC and ROHCoIPsec on an 251 IPv4 ESP-processed packet. 253 If IPsec NULL encryption is applied to packets, ROHC may still be 254 applied to the inner headers at the IPsec SA endpoints. However, 255 this poses challenges for intermediary devices (within the 256 unprotected domain) inspecting ESP-NULL encrypted packets, since 257 these intermediary devices will require additional functionality to 258 determine the content of the ROHC packets. 260 6. Details of the ROHCoIPsec Framework 261 6.1. ROHC and IPsec Integration 263 Figure 2 illustrates the components required to integrate ROHC with 264 the IPsec process, i.e., ROHCoIPsec. 266 +-------------------------------+ 267 | ROHC Module | 268 | | 269 | | 270 +-----+ | +-----+ +---------+ | 271 | | | | | | ROHC | | 272 --| A |---------| B |-----| Process |------> Path 1 273 | | | | | | | | (ROHC-enabled SA) 274 +-----+ | +-----+ +---------+ | 275 | | | | 276 | | |-------------------------> Path 2 277 | | | (ROHC-enabled SA) 278 | +-------------------------------+ 279 | 280 | 281 | 282 | 283 +-----------------------------------------> Path 3 284 (ROHC-disabled SA) 286 Figure 2. Integration of ROHC with IPsec. 288 The process illustrated in Figure 2 augments the IPsec processing 289 model for outbound IP traffic (protected-to-unprotected). Initial 290 IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1). 292 Block A: The ROHC data item (part of the SA state information) 293 retrieved from the "relevant SAD entry" ([IPSEC], Section 5.1, 294 Step3a) determines if the traffic traversing the SA is handed to the 295 ROHC module. Packets selected to a ROHC-disabled SA must follow 296 normal IPsec processing and must not be sent to the ROHC module 297 (Figure 1, Path 3). Conversely, packets selected to a ROHC-enabled 298 SA must be sent to the ROHC module. 300 Block B: This step determines if the packet can be compressed. If it 301 is determined that the packet will be compressed, an Integrity 302 Algorithm may be used to compute an Integrity Check Value (ICV) for 303 the uncompressed packet ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], 304 Section 2.1). The Next Header field of the security protocol header 305 (e.g., ESP, AH) is populated with a "ROHC" identifier, inner packet 306 headers are compressed, and the computed ICV is appended to the 307 packet (Figure 1, Path 1). However, if it is determined that the 308 packet will not be compressed (e.g., due to one the reasons described 309 in Section 6.1.3), the Next Header field is populated with the 310 appropriate value indicating the next level protocol (Figure 1, Path 311 2). 313 After the ROHC process completes, IPsec processing resumes, as 314 described in Section 5.1, Step3a, of [IPSEC]. 316 The process illustrated in Figure 2 also augments the IPsec 317 processing model for inbound IP traffic (unprotected-to-protected). 318 For inbound packets, IPsec processing is performed ([IPSEC], Section 319 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 320 5.2, Step 4). 322 Block A: After AH or ESP processing, the ROHC data item retrieved 323 from the SAD entry will indicate if traffic traversing the SA is 324 processed by the ROHC module ([IPSEC], Section 5.2, Step 3a). 325 Packets traversing an ROHC-disabled SA must follow normal IPsec 326 processing and must not be sent to the ROHC module. Conversely, 327 packets traversing an ROHC-enabled SA must be sent to the ROHC 328 module. 330 Block B: The decision at Block B is determined by the value of the 331 Next Header field of the security protocol header. If the Next 332 Header field does not indicate a ROHC header, the decompressor must 333 not attempt decompression (Figure 1, Path 2). If the Next Header 334 field indicates a ROHC header, decompression is applied. After 335 decompression, the signaled ROHCoIPsec Integrity Algorithm is used to 336 compute an ICV value for the decompressed packet. This ICV is 337 compared to the ICV that was calculated at the compressor: if the 338 ICVs match, the packet is forwarded by the ROHC module (Figure 1, 339 Path 1); otherwise, the packet is dropped. Once the ROHC module 340 completes processing, IPsec processing resumes, as described in 341 Section 5.2, Step 4 of [IPSEC]. 343 When there is a single SA between a compressor and decompressor, ROHC 344 operates in unidirectional mode, as described in Section 5 of [ROHC- 345 TERM]. When there is pair of SAs instantiated between ROHCoIPsec 346 implementations, ROHC may operate in bidirectional mode, where an SA 347 pair represents a bidirectional ROHC channel (as described in Section 348 6.1 and 6.2 of [ROHC-TERM]). 350 Note that to further reduce the size of an IPsec-protected packet, 351 ROHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested 352 fashion. This process is detailed in [IPSEC-ROHC], Section 3.2. 354 6.1.1. Header Compression Protocol Considerations 356 ROHCv2 [ROHCV2] profiles include various mechanisms that provide 357 increased robustness over reordering channels. These mechanisms must 358 be adopted for ROHC to operate efficiently over IPsec SAs. 360 A ROHC decompressor implemented within IPsec architecture may 361 leverage additional mechanisms to improve performance over reordering 362 channels (either due to random events, or to an attacker 363 intentionally reordering packets). Specifically, IPsec's sequence 364 number may be used by the decompressor to identify a packet as 365 "sequentially late". This knowledge will increase the likelihood of 366 successful decompression of a reordered packet. 368 Additionally, ROHCoIPsec implementations should minimize the amount 369 of feedback sent from the decompressor to the compressor. If a ROHC 370 feedback channel is not used sparingly, the overall gains from 371 ROHCoIPsec can be significantly reduced. More specifically, any 372 feedback sent from the decompressor to the compressor must be 373 processed by IPsec, and tunneled back to the compressor (as 374 designated by the SA associated with FEEDBACK_FOR). As such, some 375 implementation alternatives can be considered, including the 376 following: 377 o Eliminate feedback traffic altogether by operating only in ROHC 378 Unidirectional mode (U-mode) 379 o Piggyback ROHC feedback messages on traffic that normally 380 traverses the SA designated by FEEDBACK_FOR. 382 6.1.2. Initialization and Negotiation of the ROHC Channel 384 Hop-by-hop ROHC typically uses the underlying link layer (e.g., PPP) 385 to negotiate ROHC channel parameters. In the case of ROHCoIPsec, 386 channel parameters can be set manually (i.e., administratively 387 configured for manual SAs), or negotiated by IKEv2. The extensions 388 required for IKEv2 to support ROHC channel parameter negotiation are 389 detailed in [IKE-ROHC]. 391 If the ROHC protocol requires bidirectional communications, two SAs 392 must be instantiated between the IPsec implementations. One of the 393 two SAs is used for carrying ROHC-traffic from the compressor to the 394 decompressor, while the other is used to communicate ROHC-feedback 395 from the decompressor to the compressor. Note that the requirement 396 for two SAs aligns with the operation of IKE, which creates SAs in 397 pairs by default. However, IPsec implementations will dictate how 398 decompressor feedback received on one SA is associated with a 399 compressor on the other SA. An IPsec implementation must relay the 400 feedback received by the decompressor on an inbound SA to the 401 compressor associated with the corresponding outbound SA. 403 6.1.3. Encapsulation and Identification of Header Compressed Packets 405 As indicated in Section 6.1, new state information (i.e., a new ROHC 406 data item) is defined for each SA. The ROHC data item is used by the 407 IPsec process to determine whether it sends all traffic traversing a 408 given SA to the ROHC module (ROHC-enabled) or bypasses the ROHC 409 module and sends the traffic through regular IPsec processing (ROHC- 410 disabled). 412 The Next Header field of the IPsec security protocol (e.g., AH or 413 ESP) header is used to demultiplex header-compressed traffic from 414 uncompressed traffic traversing an ROHC-enabled SA. This 415 functionality is needed in situations where packets traversing a 416 ROHC-enabled SA contain uncompressed headers. Such situations may 417 occur when, for example, a compressor supports strictly n compressed 418 flows and cannot compress the n+1 flow that arrives. Another example 419 is when traffic is selected to a ROHC-enabled SA, but cannot be 420 compressed by the ROHC process because the appropriate ROHC Profile 421 has not been signaled for use. As a result, the decompressor must be 422 able to identify packets with uncompressed headers and not attempt to 423 decompress them. The Next Header field is used to demultiplex these 424 header-compressed and uncompressed packets where the ROHC protocol 425 identifier will indicate that the packet contains compressed headers. 426 To accomplish this, an official IANA allocation from the Protocol ID 427 registry [PROTOCOL] is required. 429 The ROHC Data Item, IANA Protocol ID allocation, and other IPsec 430 extensions to support ROHCoIPsec, are specified in [IPSEC-ROHC]. 432 6.2. ROHCoIPsec Framework Summary 434 To summarize, the following items are needed to achieve ROHCoIPsec: 435 o IKEv2 Extensions to Support ROHCoIPsec 436 o IPsec Extensions to Support ROHCoIPsec 438 7. Security Considerations 440 A malfunctioning ROHC compressor (i.e., the compressor located at the 441 ingress of the IPsec tunnel) has the ability to send packets to the 442 decompressor (i.e., the decompressor located at the egress of the 443 IPsec tunnel) that do not match the original packets emitted from the 444 end-hosts. Such a scenario will result in a decreased efficiency 445 between compressor and decompressor. Furthermore, this may result in 446 Denial of Service, as the decompression of a significant number of 447 invalid packets may drain the resources of an IPsec device. 449 8. IANA Considerations 451 None. 453 9. Acknowledgments 455 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 456 and Ms. Linda Noone of the Department of Defense, and well as Mr. 457 Rich Espy of OPnet for their contributions and support in the 458 development of this document. 460 The authors would also like to thank Mr. Yoav Nir, and Mr. Robert A 461 Stangarone Jr.: both served as committed document reviewers for this 462 specification. 464 In addition, the authors would like to thank the following for their 465 numerous reviews and comments to this document: 467 o Dr. Stephen Kent 468 o Mr. Pasi Eronen 469 o Dr. Joseph Touch 470 o Mr. Tero Kivinen 471 o Dr. Jonah Pezeshki 472 o Mr. Lars-Erik Jonsson 473 o Mr. Jan Vilhuber 474 o Mr. Dan Wing 475 o Mr. Kristopher Sandlund 476 o Mr. Ghyslain Pelletier 478 Finally, the authors would also like to thank Mr. Tom Conkle, Ms. 479 Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen 480 Hamilton for their assistance in completing this work. 482 10. Informative References 484 [ROHC] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust 485 Header Compression (ROHC) Framework", RFC 4995, July 2007. 487 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 488 Internet Protocol", RFC 4301, December 2005. 490 [ROHC-TERM] 491 Jonsson, L-E., "Robust Header Compression (ROHC): 492 Terminology and Channel Mapping Examples", RFC 3759, 493 April 2004. 495 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 496 RFC 4306, December 2005. 498 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 499 RFC 4303, December 2005. 501 [AH] Kent, S., "IP Authentication Header", RFC 4302, 502 December 2005. 504 [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload 505 Compression Protocol (IPComp)", RFC 3173, September 2001. 507 [ROHCV2] Pelletier, G. and K. Sandlund, "RObust Header Compression 508 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP 509 Lite", RFC 5225, April 2008. 511 [IKE-ROHC] 512 Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. 513 Bormann, "IKEv2 Extensions to Support ROHCoIPsec", work in 514 progress , February 2009. 516 [PROTOCOL] 517 IANA, "Assigned Internet Protocol Numbers, IANA registry 518 at: http://www.iana.org/assignments/protocol-numbers". 520 [IPSEC-ROHC] 521 Ertekin, E., Christou, C., and C. Bormann, "IPsec 522 Extensions to Support ROHCoIPsec", work in progress , 523 February 2009. 525 Authors' Addresses 527 Emre Ertekin 528 Booz Allen Hamilton 529 13200 Woodland Park Dr. 530 Herndon, VA 20171 531 US 533 Email: ertekin_emre@bah.com 534 Rohan Jasani 535 Booz Allen Hamilton 536 13200 Woodland Park Dr. 537 Herndon, VA 20171 538 US 540 Email: jasani_rohan@bah.com 542 Chris Christou 543 Booz Allen Hamilton 544 13200 Woodland Park Dr. 545 Herndon, VA 20171 546 US 548 Email: christou_chris@bah.com 550 Carsten Bormann 551 Universitaet Bremen TZI 552 Postfach 330440 553 Bremen D-28334 554 Germany 556 Email: cabo@tzi.org