idnits 2.17.1 draft-ietf-rohc-hcoipsec-07.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 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 572. 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 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 (December 31, 2007) is 5954 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ROHCV2' is mentioned on line 329, but not defined == Unused Reference: 'ROHC2' is defined on line 480, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4306 (ref. 'IKEV2') (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ertekin 3 Internet-Draft C. Christou 4 Intended status: Informational R. Jasani 5 Expires: July 3, 2008 J. Pezeshki 6 Booz Allen Hamilton 7 December 31, 2007 9 Integration of Robust Header Compression (RoHC) over IPsec Security 10 Associations 11 draft-ietf-rohc-hcoipsec-07 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 July 3, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 IP Security (IPsec) provides various security services for IP 45 traffic. However, the benefits of IPsec come at the cost of 46 increased overhead. This document outlines a framework for 47 integrating Robust Header Compression (RoHC) over IPsec (RoHCoIPsec). 48 By compressing the inner headers of IP packets, RoHCoIPsec proposes 49 to reduce the amount of overhead associated with the transmission of 50 traffic over IPsec Security Associations (SAs). 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 58 5. Overview of the RoHCoIPsec Framework . . . . . . . . . . . 5 59 5.1. RoHCoIPsec Assumptions . . . . . . . . . . . . . . . . . . 5 60 5.2. Summary of the RoHCoIPsec Framework . . . . . . . . . . . 5 61 6. Details of the RoHCoIPsec Framework . . . . . . . . . . . 6 62 6.1. RoHC and IPsec Integration . . . . . . . . . . . . . . . . 6 63 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 64 6.1.2. Initialization and Negotiation of the RoHC Channel . . . . 9 65 6.1.3. Encapsulation and Identification of Header Compressed 66 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.2. RoHCoIPsec Framework Summary . . . . . . . . . . . . . . . 10 68 7. Security Considerations . . . . . . . . . . . . . . . . . 10 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 71 10. Informative References . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 12 73 Intellectual Property and Copyright Statements . . . . . . 14 75 1. Introduction 77 This document outlines a framework for integrating RoHC [ROHC] over 78 IPsec [IPSEC] (RoHCoIPsec). The goal of RoHCoIPsec is to reduce the 79 protocol overhead associated with packets traversing between IPsec SA 80 endpoints. This can be achieved by compressing the transport layer 81 header (e.g., UDP, TCP, etc.) and inner IP header of packets at the 82 ingress of the IPsec tunnel, and decompressing these headers at the 83 egress. 85 For RoHCoIPsec, this document assumes that RoHC will be used to 86 compress the inner headers of IP packets traversing an IPsec tunnel. 87 However, since current specifications for RoHC detail its operation 88 on a hop-by-hop basis, it may require extensions to enable its 89 operation over IPsec SAs. This document outlines a framework for 90 extending the usage of RoHC to operate at IPsec SA endpoints. 92 RoHCoIPsec targets the application of RoHC to tunnel mode SAs. 93 Transport mode SAs only encrypt/authenticate the payload of an IP 94 packet, leaving the IP header untouched. Intermediate routers 95 subsequently use this IP header to route the packet to a decryption 96 device. Therefore, if RoHC is to operate over IPsec transport-mode 97 SAs, (de)compression functionality can only be applied to the 98 transport layer headers, and not to the IP header. Because current 99 RoHC specifications do not include support for the compression of 100 transport layer headers alone, the RoHCoIPsec framework outlined by 101 this document describes the application of RoHC to tunnel mode SAs. 103 2. Audience 105 The authors target members of both the RoHC and IPsec communities who 106 may consider extending the RoHC and IPsec protocols to meet the 107 requirements put forth in this document. In addition, this document 108 is directed towards vendors developing IPsec devices that will be 109 deployed in bandwidth-constrained IP networks. 111 3. Terminology 113 Terminology specific to RoHCoIPsec is introduced in this section. 115 RoHC Process 117 Generic reference to a RoHC instance (as defined in RFC 3759), or 118 any supporting RoHC components. 120 Compressed Traffic 121 Traffic that is processed by the ROHC compressor instance. Packet 122 headers are compressed using a specific header compression 123 protocol. 125 Uncompressed Traffic 127 Traffic that is not processed by the ROHC compressor instance. 128 Instead, this type of traffic bypasses the RoHC process. 130 IPsec Process 132 Generic reference to the Internet Protocol Security (IPsec) 133 process. 135 Next Header 137 Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) 138 field. 140 4. Problem Statement: IPsec Packet Overhead 142 IPsec mechanisms provide various security services for IP networks. 143 However, the benefits of IPsec come at the cost of increased per- 144 packet overhead. For example, traffic flow confidentiality 145 (generally leveraged at security gateways) requires the tunneling of 146 IP packets between IPsec implementations. Although these IPsec 147 tunnels will effectively mask the source-destination patterns that an 148 intruder can ascertain, tunneling comes at the cost of increased per- 149 packet overhead. Specifically, an ESP tunnel mode SA applied to an 150 IPv6 flow results in at least 50 bytes of additional overhead per 151 packet. This additional overhead may be undesirable for many 152 bandwidth-constrained wireless and/or satellite communications 153 networks, as these types of infrastructure are not overprovisioned. 154 RoHC applied on a per-hop basis over bandwidth-constrained links will 155 also suffer from reduced performance when encryption is used on the 156 tunneled header, since encrypted headers can not be compressed. 157 Consequently, the additional overhead incurred by an IPsec tunnel may 158 result in the inefficient utilization of bandwidth. 160 Packet overhead is particularly significant for traffic profiles 161 characterized by small packet payloads (e.g. various voice codecs). 162 In addition, if these small packets are afforded the security 163 services of an IPsec tunnel mode SA, the amount of per-packet 164 overhead is increased. Thus, a mechanism is needed to reduce the 165 overhead associated with such flows. 167 5. Overview of the RoHCoIPsec Framework 169 5.1. RoHCoIPsec Assumptions 171 The goal of RoHCoIPsec is to provide efficient transport of IP 172 packets between IPsec devices, without compromising the security 173 services offered by IPsec. As such, the RoHCoIPsec framework has 174 been developed based on the following assumptions: 175 o RoHC will be leveraged to reduce the amount of overhead associated 176 with packets traversing an IPsec SA 177 o RoHC will be instantiated at the IPsec SA endpoints, and will be 178 applied on a per-SA basis 179 o Once the decompression operation completes, decompressed packet 180 headers will be identical to the original packet headers before 181 compression 183 5.2. Summary of the RoHCoIPsec Framework 185 RoHC reduces packet overhead in a network by exploiting intra- and 186 inter-packet redundancies of network and transport-layer header 187 fields of a flow. 189 Current RoHC protocol specifications compress packet headers on a 190 hop-by-hop basis. However, IPsec SAs are instantiated between two 191 IPsec implementations, with multiple hops between the IPsec 192 implementations. Therefore, various extensions to both RoHC and 193 IPsec may need to be defined to ensure its successful operation at 194 IPsec SA endpoints. 196 The migration of RoHC over IPsec SAs is straightforward, since SA 197 endpoints provide source/destination pairs where (de)compression 198 operations can take place. Compression in such a manner offers a 199 reduction of per-packet protocol overhead between the two SA 200 endpoints, and does not require compression and decompression cycles 201 at the intermediate hops between IPsec implementations. Since RoHC 202 will now essentially operate over multiple hops, it is imperative to 203 ensure that its performance will not be severely impacted due to 204 increased packet reordering and/or packet loss between the compressor 205 and decompressor. 207 In addition, RoHC can no longer rely on the underlying link layer for 208 RoHC parameter configuration and packet identification. The 209 RoHCoIPsec framework proposes that RoHC channel parameter 210 configuration is accomplished by an SA management protocol (e.g., 211 IKEv2 [IKEV2]), while identification of compressed header packets is 212 achieved through the Next Header field of the security protocol 213 (e.g., AH [AH], ESP [ESP]) header. 215 Using the RoHCoIPsec framework proposed below, outbound IP traffic 216 processing at an IPsec device is augmented to compress appropriate 217 packet headers, and subsequently encrypt and/or integrity-protect the 218 packet. For tunnel mode SAs, compression may be applied to the 219 transport layer protocol and the inner IP header. 221 Inbound IP traffic processing at an IPsec device is modified in a 222 similar fashion. For inbound packets, an IPsec device must first 223 decrypt and/or integrity-check the packet. Then, the IPsec device 224 determines if the packet was received on an RoHC-enabled SA (see 225 Section 6.1) and if the packet maintains compressed headers. If both 226 of these conditions are met, decompression of the inner packet 227 headers is performed. After decompression, the packet is checked 228 against the access controls imposed on all inbound traffic associated 229 with the SA (as specified in [IPSEC]). 231 Note: Compression of inner headers is independent from compression 232 of the security protocol (e.g., ESP) and outer IP headers. RoHC 233 is capable of compressing the security protocol and the outer IP 234 header on a hop-by-hop basis. 236 If IPsec NULL encryption is applied to packets, RoHC may still be 237 applied to the inner headers at the IPsec SA endpoints. Inbound and 238 outbound packets are still processed as was previously described. 240 6. Details of the RoHCoIPsec Framework 242 6.1. RoHC and IPsec Integration 244 Figure 1 illustrates the components required to integrate RoHC with 245 the IPsec process, i.e., RoHCoIPsec. 247 +-------------------------------+ 248 | RoHC Module | 249 | | 250 | | 251 +-----+ | +-----+ +---------+ | 252 | | | | | | RoHC | | 253 --| A |---------| B |-----| Process |------> Path 1 254 | | | | | | | | (RoHC-enabled SA) 255 +-----+ | +-----+ +---------+ | 256 | | | | 257 | | |-------------------------> Path 2 258 | | | (RoHC-enabled SA) 259 | +-------------------------------+ 260 | 261 | 262 | 263 | 264 +-----------------------------------------> Path 3 265 (ROHC-disabled SA) 267 Figure 1: Integration of RoHC with IPsec. 269 The process illustrated in Figure 1 augments the IPsec processing 270 model for outbound IP traffic (protected-to-unprotected). Initial 271 IPsec processing is consistent with [IPSEC] (Steps 1-2, Section 5.1). 272 The RoHC data item (part of the SA state information) retrieved from 273 the "relevant SAD entry" ([IPSEC], Section 5.1, Step3a) determines if 274 the traffic traversing the SA is handed to the RoHC module (Figure 1, 275 decision block A). Packets selected to a RoHC-disabled SA must 276 follow normal IPsec processing and must not be sent to the RoHC 277 module (Figure 1, Path 3). Conversely, packets selected to a RoHC- 278 enabled SA must be sent to the RoHC module. The decision at block B 279 then determines if the packet can be compressed. If it is determined 280 that the packet will be compressed, an Integrity Algorithm is used to 281 compute an Integrity Check Value (ICV) for the uncompressed packet 282 ([IPSEC-ROHC], Section 3.2 [IKE-ROHC], Section 2.1). After this, the 283 Next Header field of the security protocol header (e.g., ESP, AH) is 284 populated with a "RoHC" identifier, the packet headers are 285 compressed, and the computed ICV is prepended to the packet, in front 286 of the compressed header (Figure 1, Path 1). However, if it is 287 determined that the packet will not be compressed (e.g., due to one 288 the reasons described in Section 6.1.3), the Next Header field is 289 populated with the appropriate value indicating the next level 290 protocol (Figure 1, Path 2). After the RoHC process completes, IPsec 291 processing resumes, as described in Section 5.1, Step3a, of [IPSEC] 292 (specifically, "IPsec processing is as previously defined..."). 294 The process illustrated in Figure 1 also augments the IPsec 295 processing model for inbound IP traffic (unprotected-to-protected). 296 For inbound packets, IPsec processing is performed ([IPSEC], Section 297 5.2, Steps 1-3) followed by AH or ESP processing ([IPSEC], Section 298 5.2, Step 4) . After AH or ESP processing, the RoHC data item 299 retrieved from the SAD entry will indicate if traffic traversing the 300 SA is handed to the RoHC module ([IPSEC], Section 5.2, Step 3a). 301 Packets traversing an RoHC-disabled SA must follow normal IPsec 302 processing and must not be sent to the RoHC module. Conversely, 303 packets traversing an RoHC-enabled SA must be sent to the RoHC 304 module. The decision at block B is determined by the value of the 305 Next Header field of the security protocol header. If a RoHC header 306 is indicated, decompression is applied, and the decompressed packet 307 is used with the RoHCoIPsec Integrity Algorithm to compute a value 308 that is compared to the ICV that was calculated at the compressor. 309 If this computed value equals the ICV, the packet leaves the RoHC 310 module (Figure 1, Path 1); otherwise, the packet is dropped. If the 311 Next Header field does not indicate a RoHC header, the decompressor 312 must not attempt decompression (Figure 1, Path 2). Once the RoHC 313 module completes processing, IPsec processing resumes, as described 314 in Section 5.2, Step 4 of [IPSEC] (specifically "Then match the 315 packet against the inbound selectors identified by the SAD ..."). 317 Note that to further reduce the size of an IPsec-protected packet, 318 RoHCoIPsec and IPcomp [IPCOMP] can be implemented in a nested 319 fashion. This process is detailed in [IPSEC-ROHC], Section 3.2. 321 6.1.1. Header Compression Protocol Considerations 323 The initial specification of RoHC [ROHC] may need to be extended to 324 operate efficiently over IPsec SAs. Specifically, compressor and 325 decompressor implementations must account for increased tolerance to 326 packet reordering and packet loss, and should minimize the amount of 327 feedback sent from the decompressor to the compressor. To address 328 this need, [ROHC-RODR] provides guidelines on how to implement 329 existing profiles over reordering channels, and RoHCv2 [ROHCV2] 330 profiles include various mechanisms that provide increased robustness 331 over reordering channels. Furthermore, a RoHC decompressor 332 implemented within IPsec architecture may leverage additional 333 mechanisms to improve performance over reordering channels (either 334 due to random events, or to an attacker intentionally reordering 335 packets). Specifically, IPsec's sequence number may be used by the 336 decompressor to identify a packet as "sequentially late". This 337 knowledge will increase the likelihood of successful decompression of 338 a reordered packet. 340 Additionally, RoHCoIPsec implementations should minimize the amount 341 of feedback sent from the decompressor to the compressor. If a ROHC 342 feedback channel is not used sparingly, the overall gains from 343 RoHCoIPsec can be significantly reduced. More specifically, any 344 feedback sent from the decompressor to the compressor must be 345 processed by IPsec, and tunneled back to the compressor (as 346 designated by the SA associated with FEEDBACK_FOR). As such, several 347 implementation considerations are offered: 348 o Eliminate feedback traffic altogether by operating only in RoHC 349 Unidirectional mode (U-mode) 350 o Piggyback RoHC feedback messages on traffic that normally 351 traverses the SA designated by FEEDBACK_FOR. 353 6.1.2. Initialization and Negotiation of the RoHC Channel 355 RoHC uses the underlying link layer (e.g., PPP) to negotiate RoHC 356 channel parameters. In the case of RoHCoIPsec, channel parameters 357 are negotiated by another mechanism. Specifically, initialization of 358 the RoHC channel is either achieved manually (i.e., administratively 359 configured for manual SAs), or is performed by IPsec SA establishment 360 protocols. The extensions required for IKEv2 to support RoHC 361 parameter negotiation are detailed in [IKE-ROHC]. 363 If the RoHC protocol requires bi-directional communications, two SAs 364 must be instantiated between the IPsec implementations. One of the 365 two SAs is used for carrying RoHC-traffic from the compressor to the 366 decompressor, while the other is used to communicate RoHC-feedback 367 from the decompressor to the compressor. Note that the requirement 368 for two SAs aligns with the operation of IKE, which creates SAs in 369 pairs. However, IPsec implementations will dictate how decompressor 370 feedback received on one SA is associated with a compressor on the 371 other SA. 373 6.1.3. Encapsulation and Identification of Header Compressed Packets 375 As indicated in Section 6.1, new state information (i.e., a new RoHC 376 data item) is defined for each SA. The RoHC data item is used by the 377 IPsec process to determine whether it sends all traffic traversing a 378 given SA to the RoHC module (RoHC-enabled) or bypasses the RoHC 379 module and sends the traffic through regular IPsec processing (RoHC- 380 disabled). 382 The Next Header field of the IPsec security protocol (e.g., AH or 383 ESP) header is used to demultiplex header-compressed traffic from 384 uncompressed traffic traversing an RoHC-enabled SA. This 385 functionality is needed in situations where packets traversing a 386 RoHC-enabled SA do not contain compressed headers. Such situations 387 may occur when, for example, a compressor supports strictly n 388 compressed flows and can not compress the n+1 flow that arrives. 389 Another example is when traffic (e.g., TCP/IP) is selected (by IPsec) 390 to a RoHC-enabled SA, but cannot be compressed by the RoHC process 391 (e.g., because the compressor does not support TCP/IP compression). 392 In these situations, the compressor must indicate that the packet 393 contains uncompressed headers. Similarly, the decompressor must be 394 able to identify packets with uncompressed headers and not attempt to 395 decompress them. The Next Header field is used to demultiplex these 396 header-compressed versus uncompressed packets, as a RoHC protocol 397 identifier will indicate the packet contains compressed headers. To 398 accomplish this, an official IANA allocation from the ProtocolID 399 registry [PROTOCOL] is required. 401 The RoHC Data Item, IANA ProtocolID allocation, and other IPsec 402 extensions to support RoHCoIPsec, are specified in [IPSEC-ROHC]. 404 6.2. RoHCoIPsec Framework Summary 406 To summarize, the following items are needed to achieve RoHCoIPsec: 407 o IKEv2 Extensions to Support RoHCoIPsec 408 o IPsec Extensions to Support RoHCoIPsec 410 7. Security Considerations 412 A malfunctioning RoHC compressor (i.e., the compressor located at the 413 ingress of the IPsec tunnel) has the ability to send packets to the 414 decompressor (i.e., the decompressor located at the egress of the 415 IPsec tunnel) that do not match the original packets emitted from the 416 end-hosts. Such a scenario will result in a decreased efficiency 417 between compressor and decompressor. Furthermore, this may result in 418 Denial of Service, as the decompression of a significant number of 419 invalid packets may drain the resources of an IPsec device. 421 In addition, some RoHCoIPsec implementations may allow an attacker to 422 identify new traffic flows by monitoring the relative size of the 423 encrypted packets (i.e. a group of "long" packets, followed by a long 424 series of "short" packets may indicate a new flow for some RoHCoIPsec 425 implementations). To mitigate this concern, RoHC padding mechanisms 426 may be used to arbitrarily add padding to transmitted packets to 427 randomize packet sizes. 429 8. IANA Considerations 431 None. 433 9. Acknowledgments 435 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 436 and Ms. Linda Noone of the Department of Defense, and well as Mr. 437 Rich Espy of OPnet for their contributions and support in the 438 development of this document. In addition, the authors would like to 439 thank the following for their numerous reviews and comments to this 440 document: 442 o Dr. Stephen Kent 443 o Dr. Carsten Bormann 444 o Mr. Tero Kivinen 445 o Mr. Lars-Erik Jonsson 446 o Mr. Jan Vilhuber 447 o Mr. Dan Wing 448 o Mr. Kristopher Sandlund 449 o Mr. Ghyslain Pelletier 450 o Mr. Pasi Eronen 452 Finally, the authors would also like to thank Mr. Tom Conkle, Ms. 453 Renee Esposito, Mr. Etzel Brower, and Ms. Michele Casey of Booz Allen 454 Hamilton for their assistance in completing this work. 456 10. Informative References 458 [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 459 Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., 460 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 461 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 462 Compression (ROHC): Framework and four profiles: RTP, UDP, 463 ESP, and uncompressed", RFC 3095, July 2001. 465 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 466 Internet Protocol", RFC 4301, December 2005. 468 [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 469 RFC 4306, December 2005. 471 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", 472 RFC 4303, December 2005. 474 [AH] Kent, S., "IP Authentication Header", RFC 4302, 475 December 2005. 477 [IPCOMP] Shacham, A., Monsour, R., Pereira, and Thomas, "IP Payload 478 Compression Protocol (IPComp)", RFC 3173, September 2001. 480 [ROHC2] Pelletier, G. and K. Sandlund, "RObust Header Compression 481 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP 482 Lite", work in progress , December 2007. 484 [IKE-ROHC] 485 Pezeshki, et al., "IKEv2 Extensions to Support 486 RoHCoIPsec", work in progress , February 2007. 488 [ROHC-RODR] 489 Pelletier, et al., "RObust Header Compression (ROHC): ROHC 490 over Channels That Can Reorder Packets", RFC 4224, 491 January 2006. 493 [PROTOCOL] 494 IANA, ""Assigned Internet Protocol Numbers", IANA registry 495 at: http://www.iana.org/assignments/protocol-numbers". 497 [IPSEC-ROHC] 498 Ertekin, et al., "IPsec Extensions to Support RoHCoIPsec", 499 work in progress , February 2007. 501 Authors' Addresses 503 Emre Ertekin 504 Booz Allen Hamilton 505 13200 Woodland Park Dr. 506 Herndon, VA 20171 507 US 509 Email: ertekin_emre@bah.com 511 Chris Christou 512 Booz Allen Hamilton 513 13200 Woodland Park Dr. 514 Herndon, VA 20171 515 US 517 Email: christou_chris@bah.com 519 Rohan Jasani 520 Booz Allen Hamilton 521 13200 Woodland Park Dr. 522 Herndon, VA 20171 523 US 525 Email: jasani_rohan@bah.com 526 Jonah Pezeshki 527 Booz Allen Hamilton 528 13200 Woodland Park Dr. 529 Herndon, VA 20171 530 US 532 Email: pezeshki_jonah@bah.com 534 Full Copyright Statement 536 Copyright (C) The IETF Trust (2007). 538 This document is subject to the rights, licenses and restrictions 539 contained in BCP 78, and except as set forth therein, the authors 540 retain all their rights. 542 This document and the information contained herein are provided on an 543 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 544 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 545 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 546 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 547 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 548 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 550 Intellectual Property 552 The IETF takes no position regarding the validity or scope of any 553 Intellectual Property Rights or other rights that might be claimed to 554 pertain to the implementation or use of the technology described in 555 this document or the extent to which any license under such rights 556 might or might not be available; nor does it represent that it has 557 made any independent effort to identify any such rights. Information 558 on the procedures with respect to rights in RFC documents can be 559 found in BCP 78 and BCP 79. 561 Copies of IPR disclosures made to the IETF Secretariat and any 562 assurances of licenses to be made available, or the result of an 563 attempt made to obtain a general license or permission for the use of 564 such proprietary rights by implementers or users of this 565 specification can be obtained from the IETF on-line IPR repository at 566 http://www.ietf.org/ipr. 568 The IETF invites any interested party to bring to its attention any 569 copyrights, patents or patent applications, or other proprietary 570 rights that may cover technology that may be required to implement 571 this standard. Please address the information to the IETF at 572 ietf-ipr@ietf.org. 574 Acknowledgment 576 Funding for the RFC Editor function is provided by the IETF 577 Administrative Support Activity (IASA).