idnits 2.17.1 draft-ietf-rohc-hcoipsec-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 609. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IPSEC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 22, 2006) is 6396 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ESP' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'HCOMPLS' is defined on line 534, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: April 25, 2007 Booz Allen Hamilton 6 October 22, 2006 8 Integration of Header Compression over IPsec Security Associations 9 draft-ietf-rohc-hcoipsec-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 25, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 IP Security (IPsec) [IPSEC] provides various security services for IP 43 traffic. However, the benefits of IPsec come at the cost of 44 increased overhead. This document outlines a framework for 45 integrating Header Compression (HC) over IPsec (HCoIPsec). By 46 compressing the inner headers of IP packets, HCoIPsec proposes to 47 reduce the amount of overhead associated with the transmission of 48 traffic over IPsec Security Associations (SAs). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Problem Statement: IPsec Packet Overhead . . . . . . . . . 4 56 5. Overview of the HCoIPsec Framework . . . . . . . . . . . . 5 57 5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5 58 5.2. HCoIPsec Summary . . . . . . . . . . . . . . . . . . . . . 5 59 6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6 60 6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 7 61 6.1.1. Header Compression Protocol Considerations . . . . . . . . 8 62 6.1.2. Initialization and Negotiation of HC Channel . . . . . . . 9 63 6.1.3. Encapsulation and Identification of Header Compressed 64 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10 66 7. Security Considerations . . . . . . . . . . . . . . . . . 11 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 11 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . 12 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13 73 Intellectual Property and Copyright Statements . . . . . . 14 75 1. Introduction 77 This document outlines a framework for integrating HC over IPsec 78 (HCoIPsec). The goal of HCoIPsec is to reduce the protocol overhead 79 associated with packets traversing between IPsec SA endpoints. This 80 can be achieved by compressing the transport layer header (e.g., UDP, 81 TCP, etc.) and inner IP header of packets at the ingress of the IPsec 82 tunnel, and decompressing these headers at the egress. 84 For HCoIPsec, this document assumes traditional HC protocols, 85 Internet Protocol Header Compression [IPHC], Compressed Real Time 86 Protocol [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and 87 Robust Header Compression [ROHC], will be used to compress the inner 88 headers of IP packets traversing an IPsec tunnel. Since these 89 traditional HC protocols are designed to operate on a hop-by-hop 90 basis, they may require extensions to enable their operation over 91 IPsec SAs. This document outlines a framework for extending the 92 usage of these traditional hop-by-hop HC protocols to operate at 93 IPsec SA endpoints. 95 HCoIPsec targets the application of HC to tunnel mode SAs. Transport 96 mode SAs only encrypt/authenticate the payload of an IP packet, 97 leaving the IP header untouched. Intermediate routers subsequently 98 use the IP header to route the packet to a decryption device. 99 Therefore, if traditional HC protocols were to operate over IPsec 100 transport-mode SAs, (de)compression functionality can only be applied 101 to the transport layer headers, and not to the IP header. Since 102 compression of transport layer headers alone does not provide 103 substantial efficiency gains, the HCoIPsec framework outlined by this 104 document only concerns the application of HC to tunnel mode SAs. 106 2. Audience 108 The target audience includes those who are involved with the 109 development of HC protocols, and IPsec implementations. Since 110 traditional HC protocols have been designed to operate on a hop-by- 111 hop basis, they may need to be modified or extended to be operational 112 over IPsec SAs. Therefore, the authors target various HC and IPsec 113 communities who may consider extending existing HC and IPsec 114 protocols to meet the requirements put forth in this document. 115 Finally, this document is directed towards vendors developing IPsec 116 devices that will be deployed in bandwidth-constrained IP networks. 118 3. Terminology 120 Terminology specific to HCoIPsec is introduced in this section. 122 Compressed Traffic 124 Traffic that is processed by the compressor. Packet headers are 125 compressed using a specific header compression protocol. 127 Uncompressed Traffic 129 Traffic that is not processed by the compressor. Instead, this 130 type of traffic bypasses the HC process. 132 HC Process 134 Generic reference to either the compressor, decompressor, or any 135 supporting header compression (HC) components. 137 IPsec Process 139 Generic reference to the Internet Protocol Security (IPsec) 140 process [IPSEC]. 142 Next Header 144 Refers to the Protocol (IPv4) or Next Header (IPv6, Extension) 145 field (see IANA web page at 146 http://www.iana.org/assignments/protocol-numbers). 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, IPsec tunnels come at the cost of increased 157 per-packet overhead. Specifically, an ESP tunnel mode SA applied to 158 an 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 HC applied on a per-hop basis over bandwidth-constrained link 163 technologies will also suffer from reduced performance when 164 encryption is used on the tunneled header, since encrypted headers 165 can not be compressed. Consequently, the additional overhead 166 incurred by an IPsec tunnel may result in the inefficient utilization 167 of bandwidth. 169 Packet overhead is particularly significant for traffic profiles 170 characterized by small packet payloads. Some applications that 171 emanate small packet payloads include various voice codecs. In 172 addition, if these small packets are afforded the security services 173 of an IPsec tunnel mode SA, the amount of per-packet overhead is 174 magnified. Thus, a mechanism is needed to reduce the overhead 175 associated with such flows. 177 5. Overview of the HCoIPsec Framework 179 5.1. HCoIPsec Assumptions 181 The goal for HCoIPsec is to provide efficient transport of IP packets 182 between source and destination IPsec devices, without compromising 183 the security services offered by IPsec. As such, the HCoIPsec 184 framework was developed based on the following assumptions: 185 o Existing HC protocols (e.g., IPHC, CRTP, ECRTP, ROHC) will be 186 leveraged to reduce the amount of overhead associated with packets 187 traversing an IPsec SA 188 o HC algorithms will be instantiated at the IPsec SA endpoints, and 189 HC is applied on a per-SA basis 191 5.2. HCoIPsec Summary 193 HC protocols reduce packet overhead in a network by exploiting intra- 194 and inter-packet redundancies of network and transport-layer header 195 fields of a flow. 197 Existing HC protocols compress packet headers on a hop-by-hop basis. 198 However, IPsec SAs are instantiated between two IPsec 199 implementations, with multiple hops between the IPsec 200 implementations. Therefore, to fully integrate HC with IPsec SAs, 201 traditional hop-by-hop protocols may need to be extended to operate 202 at IPsec SA endpoints. 204 The migration of traditional hop-by-hop HC protocols over IPsec SAs 205 is straightforward, since SA endpoints provide source/destination 206 pairs where (de)compression operations can take place. Compression 207 in such a manner offers a reduction of per-packet protocol overhead 208 between the two SA endpoints, and does not require compression and 209 decompression cycles at the intermediate hops between IPsec 210 implementations. Since traditional HC protocols will now essentially 211 operate over multiple hops, it is imperative that their performance 212 is not severely impacted due to increased packet reordering and/or 213 packet loss between the compressor and decompressor. 215 In addition, since HC protocols will operate at IPsec SA endpoints, 216 HC protocols can no longer rely on the underlying link layer for HC 217 parameter configuration and packet identification. Traditional HC 218 protocols use the underlying link layer to establish a set of 219 configuration parameters at each end of the link, and some HC 220 protocols (e.g., IPHC, CRTP, ECRTP) are also dependent on the link 221 layer framing for identifying different types of header-compressed 222 packets. The HCoIPsec framework proposes that HC channel parameter 223 configuration is accomplished by the SA management protocol (e.g., 224 IKEv2), while identification of compressed header packets (in 225 contrast to uncompressed packets) is provided through the Next Header 226 field of the security protocol (e.g., AH, ESP). In addition, HC 227 protocols that require the identification of different types of 228 header-compressed packets will have to be extended with such a 229 mechanism. 231 Using the HCoIPsec framework proposed below, outbound IP traffic 232 processing at an IPsec device is augmented to compress appropriate 233 packet headers, and subsequently encrypt and/or integrity-protect the 234 packet. For tunnel mode SAs, compression may be applied to the 235 transport layer protocol and the inner IP header. 237 Inbound IP traffic processing at an IPsec device is modified in a 238 similar fashion. For inbound packets, an IPsec device must first 239 decrypt and/or integrity-check the packet. Then, the IPsec device 240 determines if the packet was received on an HC-enabled SA (see 241 section 6.1) and if the packet maintains compressed headers. If both 242 of these conditions are met, decompression of the inner packet 243 headers is performed. After decompression, the packet is checked 244 against the access controls imposed on all inbound traffic associated 245 with the SA (as specified in RFC 4301). 247 Note: Compression of inner headers is independent from compression 248 of the security protocol (e.g., ESP) and outer IP headers. HC 249 protocols such as ROHC are capable of compressing the security 250 protocol and outer IP headers on a hop-by-hop basis. Further 251 discussion on the compression of outer headers is outside the 252 scope of this document. 254 If IPsec NULL encryption is applied to packets, HC protocols may 255 still be applied to the inner headers at the IPsec SA endpoints. 256 Inbound and outbound packets are still processed as was previously 257 described. 259 6. Details of the HCoIPsec Framework 260 6.1. HC and IPsec Integration 262 Based on these assumptions, Figure 1 illustrates the components 263 required to integrate HC with the IPsec process, i.e., HCoIPsec. 265 +-------------------------------+ 266 | HC Module | 267 | | 268 | | 269 +-----+ | +-----+ +---------+ | 270 | | | | | | HC | | 271 --| A |---------| B |-----| Process |------> Path 1 272 | | | | | | | | (HC-enabled SA) 273 +-----+ | +-----+ +---------+ | 274 | | | | 275 | | |-------------------------> Path 2 276 | | | (HC-enabled SA) 277 | +-------------------------------+ 278 | 279 | 280 | 281 | 282 +-----------------------------------------> Path 3 283 (HC-disabled SA) 285 Figure 1: Integration of HC with IPsec. 287 The process illustrated in Figure 1 augments the IPsec processing 288 model for outbound IP traffic(protected-to-unprotected). Initial 289 IPsec processing is consistent with RFC 4301 (Steps 1-2, Section 290 5.1). The HC data item (part of the SA state information) retrieved 291 from the "relevant SAD entry" (RFC4301, Section 5.1, Step3a) 292 determines if the traffic traversing the SA is handed to the HC 293 module (Figure 1, decision block A). Packets selected to an HC- 294 disabled SA must follow normal IPsec processing and must not be sent 295 to the HC module (Figure 1, Path 3). Conversely, packets selected to 296 an HC-enabled SA must be sent to the HC module. The decision at 297 block B then determines if the packet can be compressed. If it is 298 determined that the packet will be compressed, the Next Header field 299 of the security protocol header (e.g., ESP, AH) is populated with a 300 "compressed headers" value, and packet headers are compressed based 301 on the compression protocol (Figure 1, Path 1). However, if it is 302 determined that the packet will not be compressed (e.g., due to one 303 the reasons described in Section 6.1.3), the Next Header field is 304 populated with the appropriate value indicating the next level 305 protocol (Figure 1, Path 2). After the HC process completes, IPsec 306 processing resumes, as described in Section 5.1, Step3a, of RFC4301 307 (specifically, "IPsec processing is as previously defined..."). 309 The process illustrated in Figure 1 also augments the IPsec 310 processing model for inbound IP traffic (unprotected-to-protected). 311 For inbound packets, IPsec processing is performed (RFC4301, Section 312 5.2, Steps 1-3) followed by AH or ESP processing (RFC4301, Section 313 5.2, Step 4) . After AH or ESP processing, the HC data item 314 retrieved from the SAD entry will indicate if traffic traversing the 315 SA is handed to the HC module (RFC4301, Section 5.2, Step 3a). 316 Packets traversing an HC-disabled SA must follow normal IPsec 317 processing and must not be sent to the HC module. Conversely, 318 packets traversing an HC-enabled SA must be sent to the HC module. 319 The decision at block B is determined by the value of the Next Header 320 field. If "compressed headers" is indicated, decompression is 321 applied using the appropriate HC protocol (Figure 1, Path 1). 322 However, if the Next Header field does not contain the "compressed 323 headers" value, the decompressor must not attempt decompression 324 (Figure 1, Path 2). IPsec processing resumes once the HC module 325 completes processing, as described in Section 5.2, Step 4 of RFC 326 4301(specifically "Then match the packet against the inbound 327 selectors identified by the SAD ..."). 329 6.1.1. Header Compression Protocol Considerations 331 Traditional hop-by-hop HC protocols must be extended to operate 332 efficiently over IPsec SAs. Compressor and decompressor 333 implementation considerations therefore must account for increased 334 tolerance to packet reordering and packet loss between the compressor 335 and decompressor, and minimizing the amount of feedback sent from the 336 decompressor to the compressor. 338 The ability to tolerate increased packet reordering between the 339 compressor and decompressor is a necessity for any HC protocol that 340 is extended to operate over an IPsec SA. The following provides a 341 summary of the candidate HC solutions, and their tolerance to packet 342 loss and reordering between the compressor and decompressor: 343 o IPHC has been identified as a HC protocol that performs poorly 344 over long round trip time (RTT), high BER links [ROHC]. 345 Extensions to IPHC to compress TCP/IP headers over an IPsec SA 346 should take into consideration longer RTTs, increased potential 347 for packet reordering and packet loss between the compressor and 348 decompressor. 349 o CRTP has also been identified as a HC protocol that performs 350 poorly over long RTT, high BER links [CRTPE]. Recent 351 modifications to the CRTP protocol, such as ECRTP, enable the CRTP 352 HC protocol to tolerate long RTTs and packet loss between the 353 compressor and decompressor. However, the reordering tolerance of 354 ECRTP still needs to be evaluated, as detailed in [ECRTPE]. Such 355 implementation aspects should be taken into consideration when 356 extending ECRTP to operate over IPsec SAs. 357 o ROHC is a protocol that is designed for high BER, long RTT links. 358 ROHC can be used to compress not only RTP/UDP/IP headers, but also 359 other traffic profiles such as TCP/IP, as defined in [ROHCTCP]. 360 Similar to CRTP and IPHC, ROHC has been identified as vulnerable 361 to packet reordering events between the compressor and 362 decompressor[ROHCE]. Recent work [ROHCWEXT] suggests that the 363 implementation aspects of ROHC can be modified to achieve 364 tolerance to packet reordering events. Such implementation 365 aspects should be taken into consideration when extending ROHC to 366 operate over IPsec SAs. 368 Note that additional techniques may be used to augment a traditional 369 HC protocol's tolerance to packet reordering. For example, various 370 security protocols are equipped with a sequence number; this value 371 may be used by the decompressor to identify a packet as "sequentially 372 late". This knowledge can increase the likelihood of successful 373 decompression of a reordered packet. 375 In addition, HC protocols should minimize the amount of feedback 376 between decompressor and compressor. If a feedback channel from the 377 decompressor to the compressor is not used sparingly, the overall 378 gains from HCoIPsec can be significantly reduced. For example, 379 assume that ROHC is operating in bi-directional reliable mode, and is 380 instantiated over an IPsec tunnel mode SA. In this scenario, any 381 feedback sent from the decompressor to the compressor must be 382 tunneled. As such, the additional overhead incurred by tunneling 383 feedback will reduce the overall benefits of HC. 385 6.1.2. Initialization and Negotiation of HC Channel 387 Hop-by-hop HC protocols use the underlying link layer (e.g., PPP) to 388 negotiate HC channel parameters. To remove HC protocol dependencies 389 on the underlying link layer, an additional mechanism is needed to 390 initialize a HC channel and its associated parameters prior to HC 391 protocol operation. 393 Initialization of the HC channel will either be achieved manually 394 (i.e., administratively configured for manual SAs), or be performed 395 by IPsec SA establishment protocols, e.g. IKEv2. During SA 396 initialization, the SA establishment protocol will be extended to 397 negotiate the HC protocol's channel parameters. The specifics for 398 this proposal are detailed in [IKE-HC]. 400 If the HC protocol requires bi-directional communications, two SAs 401 must be instantiated between the IPsec implementations. One of the 402 two SAs is used for carrying traffic from the compressor to the 403 decompressor, while the other is used to communicate feedback from 404 the decompressor to the compressor. Note that this requirement for 405 two SAs aligns with the operation of IKE, which is capable of 406 creating SA pairs. However, IPsec implementations will dictate how 407 decompressor feedback received on one SA is associated with a 408 compressor on the other SA. 410 6.1.3. Encapsulation and Identification of Header Compressed Packets 412 As indicated in section 6.1, new state information (i.e., a new HC 413 data item) is defined for each SA. The HC data item is used by the 414 IPsec process to determine whether it sends all traffic traversing a 415 given SA to the HC module (HC-enabled) or bypasses the HC module and 416 sends the traffic through regular IPsec processing (HC-disabled). 418 In addition, the Next Header field of the IPsec security protocol 419 (e.g., AH or ESP) header is used to demultiplex header-compressed 420 traffic from uncompressed traffic traversing an HC-enabled SA. This 421 functionality is needed in situations where packets traversing an HC- 422 enabled SA are not compressed by the compressor. Such situations may 423 occur when, for example, a compressor supports strictly n compressed 424 flows and can not compress the n+1 flow that arrives. Another 425 example is when traffic (e.g., TCP/IP) is selected (by IPsec) to an 426 HC-enabled SA, but cannot be compressed by the HC process (e.g., 427 because the compressor does not support TCP/IP compression). In 428 these situations, the compressor must indicate that the packet 429 contains uncompressed headers. Similarly, the decompressor must be 430 able to identify packets with uncompressed headers and not attempt to 431 decompress them. As such, the Next Header field is used to 432 demultiplex these header-compressed versus uncompressed packets, as a 433 "compressed header" value will indicate the packet contains 434 compressed headers. 435 Note: As indicated in the description of HCoIPsec inbound and 436 outbound processing, the Next Header field is used to identify 437 compressed packets on an HC-enabled SA. Because the Next Header 438 field value is only leveraged at the IPsec implementations, an 439 official IANA allocation from the ProtocolID registry may not be 440 required. Future discussions of HCoIPsec will determine the 441 appropriate path forward. 443 6.2. HCoIPsec Framework Summary 445 To summarize, the following items are needed to achieve HCoIPsec: 446 o Extensions to traditional HC protocols which enable their 447 operation at IPsec SA enpoints 448 o Extensions to IKEv2 to Support Header Compression over IPsec 449 (HCoIPsec) 451 o Allocation of one value for "compressed headers" from the IANA 452 "Protocol Numbers" registry (This specification may not be 453 necessary, as indicated in Section 6.1.3) 455 7. Security Considerations 457 A malfunctioning header compressor (i.e., the compressor located at 458 the ingress of the IPsec tunnel) has the ability to send packets to 459 the decompressor (i.e., the decompressor located at the egress of the 460 IPsec tunnel) that do not match the original packets emitted from the 461 end-hosts. Such a scenario will result in a decreased efficiency 462 between compressor and decompressor. Furthermore, this may result in 463 Denial of Service, as the decompression of a significant number of 464 invalid packets may drain the resources of an IPsec device. 466 8. IANA Considerations 468 None. 470 9. Acknowledgments 472 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 473 and Ms. Linda Noone of the Department of Defense, and well as Mr. 474 Rich Espy of OPnet for their contributions and support in the 475 development of this document. In addition, the authors would like to 476 thank the following for their numerous reviews and comments to this 477 document: 479 o Dr. Stephen Kent 480 o Dr. Carsten Bormann 481 o Mr. Tero Kivinen 482 o Mr. Lars-Erik Jonsson 483 o Mr. Jan Vilhuber 484 o Mr. Dan Wing 485 o Mr. Kristopher Sandlund 486 o Mr. Ghyslain Pelletier 488 Finally, the authors would also like to thank Mr. Tom Conkle, Ms. 489 Renee Esposito, Mr. Etzel Brower, and Mr. Jonah Pezeshki of Booz 490 Allen Hamilton for their assistance in completing this work. 492 10. References 493 10.1. Normative References 495 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 496 Internet Protocol", RFC 4301, December 2005. 498 [IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header 499 Compression", RFC 2507, February 1999. 501 [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 502 Headers for Low-Speed Serial Links", RFC 2508, 503 February 1999. 505 [ECRTP] Koren, et al., "Compressing IP/UDP/RTP Headers on Links 506 with High Delay, Packet Loss, and Reordering", RFC 3545, 507 July 2003. 509 [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 510 Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., 511 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 512 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 513 Compression (ROHC): Framework and four profiles: RTP, UDP, 514 ESP, and uncompressed", RFC 3095, July 2001. 516 [ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header 517 Compression Algorithm ECRTP", November 2004. 519 [ROHCTCP] Pelletier, et al., "Robust Header Compression: A Profile 520 For TCP/IP (ROHC-TCP)", work in progress , January 2006. 522 [ROHCWEXT] 523 Pelletier, et al., "ROHC over Channels That Can Reorder 524 Packets", RFC 4224, January 2006. 526 [IKE-HC] Jasani, et al., "Extensions to IKEv2 to Support HCoIPsec", 527 work in progress , September 2006. 529 10.2. Informative References 531 [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, 532 December 2005. 534 [HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header 535 Compression over MPLS", April 2005. 537 [CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, 538 "Evaluation of CRTP Performance over Cellular Radio 539 Networks", IEEE Personal Communication Magazine , Volume 540 7, number 4, pp. 20-25, August 2000. 542 [ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS", 543 RFC 4247, November 2005. 545 Authors' Addresses 547 Emre Ertekin 548 Booz Allen Hamilton 549 13200 Woodland Park Dr. 550 Herndon, VA 20171 551 US 553 Email: ertekin_emre@bah.com 555 Chris Christou 556 Booz Allen Hamilton 557 13200 Woodland Park Dr. 558 Herndon, VA 20171 559 US 561 Email: christou_chris@bah.com 563 Rohan Jasani 564 Booz Allen Hamilton 565 13200 Woodland Park Dr. 566 Herndon, VA 20171 567 US 569 Email: jasani_rohan@bah.com 571 Full Copyright Statement 573 Copyright (C) The Internet Society (2006). 575 This document is subject to the rights, licenses and restrictions 576 contained in BCP 78, and except as set forth therein, the authors 577 retain all their rights. 579 This document and the information contained herein are provided on an 580 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 581 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 582 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 583 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 584 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 585 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 587 Intellectual Property 589 The IETF takes no position regarding the validity or scope of any 590 Intellectual Property Rights or other rights that might be claimed to 591 pertain to the implementation or use of the technology described in 592 this document or the extent to which any license under such rights 593 might or might not be available; nor does it represent that it has 594 made any independent effort to identify any such rights. Information 595 on the procedures with respect to rights in RFC documents can be 596 found in BCP 78 and BCP 79. 598 Copies of IPR disclosures made to the IETF Secretariat and any 599 assurances of licenses to be made available, or the result of an 600 attempt made to obtain a general license or permission for the use of 601 such proprietary rights by implementers or users of this 602 specification can be obtained from the IETF on-line IPR repository at 603 http://www.ietf.org/ipr. 605 The IETF invites any interested party to bring to its attention any 606 copyrights, patents or patent applications, or other proprietary 607 rights that may cover technology that may be required to implement 608 this standard. Please address the information to the IETF at 609 ietf-ipr@ietf.org. 611 Acknowledgment 613 Funding for the RFC Editor function is provided by the IETF 614 Administrative Support Activity (IASA).