idnits 2.17.1 draft-ietf-rohc-hcoipsec-02.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 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 571. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 26, 2006) is 6513 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ESP' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'HCOMPLS' is defined on line 512, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ECRTPE' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROHCTCP' ** Downref: Normative reference to an Informational RFC: RFC 4224 (ref. 'ROHCWEXT') Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 9 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 Expires: December 28, 2006 R. Jasani 5 Booz Allen Hamilton 6 June 26, 2006 8 Integration of Header Compression over IPsec Security Associations 9 draft-ietf-rohc-hcoipsec-02 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 December 28, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Internet Protocol security mechanisms, such as IP Security (IPsec) 43 [IPSEC], provide various security services for IP traffic. However, 44 the benefits of IPsec come at the cost of increased overhead. This 45 document defines a framework for integrating Header Compression (HC) 46 over IPsec (HCoIPsec). By compressing the inner headers of IP 47 packets, HCoIPsec proposes to reduce the amount of overhead 48 associated with the transmission of traffic over IPsec security 49 associations. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Problem Statement: Packet Overhead Associated with 57 IPsec Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . 4 58 5. Overview of the HCoIPsec Framework . . . . . . . . . . . . 5 59 5.1. HCoIPsec Assumptions . . . . . . . . . . . . . . . . . . . 5 60 5.2. HCoIPsec Description . . . . . . . . . . . . . . . . . . . 5 61 6. Details of the HCoIPsec Framework . . . . . . . . . . . . 6 62 6.1. HC and IPsec Integration . . . . . . . . . . . . . . . . . 6 63 6.1.1. Header Compression Scheme Considerations . . . . . . . . . 8 64 6.1.2. Initialization and Negotiation of HC Channel . . . . . . . 9 65 6.1.3. Encapsulation and Identification of Header Compressed 66 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.2. HCoIPsec Framework Summary . . . . . . . . . . . . . . . . 10 68 7. Security Considerations . . . . . . . . . . . . . . . . . 10 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . 11 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 13 75 Intellectual Property and Copyright Statements . . . . . . 14 77 1. Introduction 79 This document identifies a framework for integrating HC over IPsec 80 Security Associations (SAs). The goal of integrating HC with IPsec 81 is to reduce the protocol overhead associated with packets traversing 82 between IPsec SA endpoints. This can be achieved by compressing the 83 transport layer header (e.g., UDP, TCP, etc.) and inner IP header of 84 packets at the ingress of the IPsec tunnel, and decompressing these 85 headers at the egress. 87 To realize HCoIPsec, this document proposes the use of Internet 88 Protocol Header Compression [IPHC], Compressed Real Time Protocol 89 [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust 90 Header Compression [ROHC], to compress the inner headers of IP 91 packets traversing an IPsec tunnel. Since these traditional HC 92 schemes operate on a hop-by-hop basis, several extensions must be 93 defined to enable their operation over IPsec SAs. This document 94 details a framework which will allow these traditional hop-by-hop HC 95 schemes to be extended to operate at IPsec SA endpoints. 97 HCoIPsec currently targets the application of HC to tunnel mode SAs. 98 However, future work may extend the framework to operate over 99 transport mode SAs as well. Transport mode SAs only encrypt/ 100 authenticate the payload of an IP packet, leaving the IP header 101 untouched. Intermediate routers subsequently use the outer IP header 102 to route the packet to a decryption device. Therefore, if HC 103 mechanisms are extended to operate between IPsec transport-mode SA 104 endpoints, (de)compression functionality can only be applied to the 105 transport layer headers, and not to the IP header. Since compression 106 of transport layer headers alone does not provide substantial 107 efficiency gains, extending the HCoIPsec framework to support 108 transport mode SAs is left for future work. 110 2. Audience 112 The target audience includes those who are involved with the 113 development of HC schemes, and IPsec implementations. Since 114 traditional IETF HC schemes are designed to operate on a hop-by-hop 115 basis, they need to be modified to operate over IPsec SAs. 116 Therefore, the authors target various HC and IPsec communities who 117 may consider extending hop-by-hop HC schemes and IPsec protocols to 118 meet the requirements put forward in this document. Finally, this 119 document is directed towards vendors developing IPsec devices which 120 will be deployed in bandwidth-constrained, IP networks. 122 3. Terminology 124 Terminology specific to discussion of HCoIPsec is introduced in this 125 section. 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119. 131 Compressed Traffic 133 Traffic that is processed by the compressor. Packet headers are 134 compressed using a compression profile. 136 Uncompressed Traffic 138 Traffic that is not processed by the compressor. Instead, this 139 type of traffic bypasses the HC process. 141 HC Process 143 Generic reference to either the compressor, decompressor, or any 144 supporting header compression (HC) components. 146 IPsec Process 148 Generic reference to the Internet Protocol Security (IPsec) 149 process [IPSEC]. 151 4. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode 152 SAs 154 IPsec mechanisms provide various security services for IP networks. 155 The benefits of IPsec come at the cost of increased per-packet 156 overhead. For example, traffic flow confidentiality (generally 157 leveraged at security gateways) requires the tunneling of IP packets 158 between IPsec implementations. Although these IPsec tunnels will 159 effectively mask the source-destination patterns that an intruder can 160 ascertain, IPsec tunnels come at the cost of increased per-packet 161 overhead. Specifically, an ESP tunnel mode SA applied to an IPv6 162 flow results in at least 50 bytes of additional overhead per packet. 163 This additional overhead may be undesirable for many bandwidth- 164 constrained wireless and/or satellite communications networks, as 165 these types of infrastructure are not overprovisioned. Consequently, 166 the additional overhead incurred in an encryption-based environment 167 may result in the inefficient utilization 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 (e.g., 172 G.729). In addition, if these small packets are afforded the 173 security services of an IPsec tunnel mode SA, the amount of per- 174 packet overhead is magnified. Thus, a mechanism is needed to reduce 175 the overhead associated with such flows. 177 5. Overview of the HCoIPsec Framework 179 5.1. HCoIPsec Assumptions 181 The goal for HCoIPsec is to provide more efficient transport of IP 182 packets between source and destination IPsec devices, without 183 compromising the security services offered by IPsec. As such, the 184 HCoIPsec 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 Description 193 HC schemes reduce packet overhead in a network by exploiting inter- 194 packet redundancies of network and transport-layer header fields of a 195 flow to reduce the amount of redundant header data transmitted 196 between two nodes. 198 To apply traditional HC schemes over IPsec SAs, several extensions 199 need to be defined. Existing HC schemes compress packet headers on a 200 hop-by-hop basis. However, IPsec SAs are instantiated between two 201 IPsec implementations, with multiple hops between the IPsec 202 implementations. Therefore, to fully integrate HC with IPsec SAs, 203 traditional hop-by-hop schemes need to be extended to operate at 204 IPsec SA endpoints. 206 The migration of traditional hop-by-hop HC schemes over IPsec SAs is 207 straightforward, since SA endpoints provide source/destination pairs 208 where (de)compression operations can take place. Compression in such 209 a manner offers a reduction of per-packet protocol overhead between 210 the two SA endpoints, and does not require compression and 211 decompression cycles at the intermediate hops between IPsec 212 implementations. Since HC schemes will now essentially operate over 213 multiple hops, it is imperative that the performance of the HC 214 schemes is not severely impacted due to increased packet reordering 215 and/or packet loss between the compressor and decompressor. 217 In addition, since HC schemes will operate at IPsec SA endpoints, HC 218 schemes can no longer rely on the underlying link layer for HC 219 parameter configuration and packet identification. Traditionally, HC 220 schemes use the underlying link layer to establish a set of 221 configuration parameters at each end of the link, and for identifying 222 different types of header-compressed packets. The HCoIPsec framework 223 proposes that HC session parameter configuration and header- 224 compressed packet identification is accomplished by the SA management 225 protocol (e.g., IKEv2) and the security protocol next header field, 226 respectively. 228 Using the HCoIPsec framework proposed below, outbound IP traffic 229 processing at an IPsec device is augmented to compress appropriate 230 packet headers, and subsequently encrypt and/or integrity-protect the 231 packet. For tunnel mode SAs, compression may be applied to the 232 transport layer protocol and the inner IP header. 234 Inbound IP traffic processing at an IPsec device is modified in a 235 similar fashion. For inbound packets, an IPsec device must first 236 decrypt and/or integrity-check the packet. Then, the IPsec device 237 determines if the packet was received on an HC-enabled SA(see section 238 6.1), and if the packet maintains compressed headers. If both of 239 these conditions are met, decompression of the inner packet headers 240 is performed. After decompression, the packet is checked against the 241 access controls imposed on all inbound traffic associated with the SA 242 (as specified in RFC 4301). 244 Note: Compression of inner headers is independent from compression 245 of the security protocol (e.g., ESP) and outer IP headers. HC 246 schemes such as ROHC and IPHC are capable of compressing these 247 outer headers on a hop-by-hop basis. Further discussion on the 248 compression of outer headers is outside the scope of this 249 document. 251 If IPsec NULL encryption is applied to packets, HC schemes may still 252 be applied to the inner headers at the IPsec SA endpoints. Inbound 253 and outbound packets are still processed as was previously described. 254 For scenarios where NULL-encrypted packets traverse intermediate 255 nodes between the IPsec SA endpoints, the intermediary nodes must not 256 attempt to (de)compress the inner IP and/or transport layer headers. 258 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-enabled | | | | HC | | 271 --| A |--------------------| B |-----| Process |------> Path 1 272 | | | | | | | | 273 +-----+ | +-----+ +---------+ | 274 | | | | 275 | | |-------------------------> Path 2 276 | | | 277 | +-------------------------------+ 278 | 279 | HC-disabled 280 +----------------------------------------------------> Path 3 282 Figure 1: Integration of HC with IPsec. 284 The process illustrated in Figure 1 augments the IPsec processing 285 model for outbound IP traffic(protected-to-unprotected). Initial 286 IPsec processing is consistent with RFC 4301 (Steps 1-2, Section 287 5.1). The HC data item (part of the SA state information) retrieved 288 from the "relevant SAD entry" (RFC4301, Section 5.1, Step3a) 289 determines if the traffic traversing the SA is handed to the HC 290 module (Figure 1, decision block A). Packets selected to an HC- 291 disabled SA must follow normal IPsec processing and must not be sent 292 to the HC module (Figure 1, Path 3). Conversely, packets selected to 293 an HC-enabled SA must be sent to the HC module. The decision at 294 block B then determines if the packet can be compressed. If it is 295 determined that the packet will be compressed, the Next Header field 296 of the security protocol header (e.g., ESP, AH) is populated with the 297 "compressed headers" value, and packet headers are compressed based 298 on the appropriate compression profile (Figure 1, Path 1). However, 299 if it is determined that the packet will not be compressed, the Next 300 Header field is populated with the appropriate value indicating the 301 next level protocol (Figure 1, Path 2). After the HC process 302 completes, IPsec processing resumes, as described in Section 5.1, 303 Step3a, of RFC4301 (specifically, "IPsec processing is as previously 304 defined..."). 306 The process illustrated in Figure 1 also augments the IPsec 307 processing model for inbound IP traffic (unprotected-to-protected). 308 For inbound packets, processing is performed (RFC4301, Section 5.2, 309 Steps 1-3) followed by AH or ESP processing (RFC4301, Section 5.2, 310 Step 4) . After AH or ESP processing, the HC data item retrieved 311 from the SAD entry will indicate if traffic traversing the SA is 312 handed to the HC module (RFC4301, Section 5.2, Step 3a). Packets 313 traversing an HC-disabled SA must follow normal IPsec processing and 314 must not be sent to the HC module. Conversely, packets traversing an 315 HC-enabled SA must be sent to the HC module. The decision at block B 316 then determines if the "Next Header" field contains the "compressed 317 header" value, which indicates that the packet's payload contains 318 compressed headers. If "compressed headers" is indicated, the 319 appropriate decompression profile is applied (Figure 1, Path 1). 320 However, if the packet's "Next Header" field does not contain the 321 "compressed headers" value, the decompressor must not attempt 322 decompression (Figure 1, Path 2). IPsec processing resumes once the 323 HC module completes processing, as described in Section 5.2, Step 4 324 of RFC 4301(specifically "Then match the packet against the inbound 325 selectors identified by the SAD ..."). 327 6.1.1. Header Compression Scheme Considerations 329 Traditional hop-by-hop HC schemes must be extended to operate 330 efficiently over IPsec SAs. Implementation considerations for this 331 includes increasing tolerance to packet reordering and packet loss 332 between the compressor and decompressor, and minimizing the amount of 333 feedback sent from the decompressor to the compressor. 335 The ability to tolerate increased packet reordering between the 336 compressor and decompressor is a necessity for any HC scheme that is 337 extended to operate over an IPsec SA. The following provides a 338 summary of the candidate HC solutions, and their tolerance to packet 339 loss and reordering between the compressor and decompressor: 340 o IPHC has been identified as a HC scheme that performs poorly over 341 long round trip time (RTT), high BER links [ROHC]. Extensions to 342 IPHC to compress TCP/IP headers over an IPsec SA should take into 343 consideration longer RTTs, increased potential for packet 344 reordering and IPLR between the compressor and decompressor. 345 o CRTP has also been identified as a HC scheme that performs poorly 346 over long RTT, high BER links [CRTPE]. Recent modifications to 347 the CRTP scheme, such as ECRTP, enable the CRTP HC scheme to 348 tolerate long RTTs and packet loss between the compressor and 349 decompressor. However, the reordering tolerance of ECRTP still 350 needs to be evaluated, as detailed in [ECRTPE]. Such 351 implementation aspects should be taken into consideration when 352 extending ECRTP to operate over IPsec SAs. 353 o ROHC is a robust HC scheme that is designed for high BER, long RTT 354 links. ROHC can be used to compress not only RTP/UDP/IP headers, 355 but also other traffic profiles such as TCP/IP, as defined in 356 [ROHCTCP]. Similar to CRTP and IPHC, ROHC has been identified as 357 vulnerable to packet reordering events between the compressor and 358 decompressor[ROHCE]. Recent work [ROHCWEXT] suggests that the 359 implementation aspects of ROHC can be modified to achieve 360 tolerance to packet reordering events. Such implementation 361 aspects should be taken into consideration when extending ROHC to 362 operate over IPsec SAs. 364 In addition, HC schemes should minimize the amount of feedback 365 between decompressor and compressor. If a feedback channel from the 366 decompressor to the compressor is not used sparingly, the overall 367 gains from HCoIPsec can be significantly reduced. For example, 368 assume that ROHC is operating in bi-directional reliable mode, and is 369 instantiated over an IPsec tunnel mode SA. In this scenario, any 370 feedback sent from the decompressor to the compressor must be 371 tunneled. As such, the additional overhead incurred by tunneling 372 feedback will reduce the overall benefits of HC. 374 6.1.2. Initialization and Negotiation of HC Channel 376 Hop-by-hop HC schemes use the underlying link layer (e.g., PPP) to 377 negotiate HC channel parameters. To remove HC scheme dependencies on 378 the underlying link layer, an additional mechanism is needed to 379 initialize a HC channel and its associated parameters prior to HC 380 scheme operation. 382 Initialization of the HC channel will either be achieved manually 383 (i.e., administratively configured for manual SAs), or be performed 384 by IPsec SA establishment protocols, e.g. IKEv2. During SA 385 initialization, the SA establishment protocol will be extended to 386 negotiate the HC scheme's channel parameters. The specifics for this 387 proposal are detailed in a separate spectification, "IKEv2/IPsec 388 Extensions to Support HCoIPsec". 390 If the HC scheme requires bi-directional communications, two SAs must 391 be instantiated between the IPsec implementations. One of the two 392 SAs is used for carrying traffic from the compressor to the 393 decompressor, while the other is used to communicate feedback from 394 the decompressor to the compressor. IPsec implementations will 395 dictate how decompressor feedback received on one SA is associated 396 with a compressor on the other SA. 398 6.1.3. Encapsulation and Identification of Header Compressed Packets 400 As indicated in section 6.1, new state information (i.e., a new HC 401 data item) is defined for each SA. The HC data item is used by the 402 IPsec process to determine whether it sends all traffic traversing a 403 given SA to the HC module (HC-enabled) or bypasses the HC module and 404 sends the traffic through regular IPsec processing (HC-disabled). 406 In addition, the "Next Header" field of the IPsec security protocol 407 (e.g., AH or ESP) header is used to demultiplex header-compressed 408 traffic from uncompressed traffic traversing an HC-enabled SA. This 409 functionality is needed in situations where packets traversing an HC- 410 enabled SA are not compressed by the compressor. Such situations may 411 occur when, for example, a compressor supports strictly n compressed 412 flows and can not compress the n+1 flow that arrives. Another 413 example is when traffic (e.g., TCP/IP) is selected to an HC-enabled 414 SA, but cannot be compressed by the HC process (e.g., because the 415 compressor does not support TCP/IP compression). In these 416 situations, the compressor must be able to indicate that the packet 417 contains uncompressed headers. Similarly, the decompressor must be 418 able to identify packets with uncompressed headers and not attempt to 419 decompress them. Therefore, an allocation for "compressed headers" 420 will need to be reserved from the IANA "Protocol Numbers" registry, 421 which will be defined in a separate specification. The "compressed 422 headers" value will indicate that the next layer protocol header is 423 composed of compressed headers. 425 6.2. HCoIPsec Framework Summary 427 [Note to RFC Editor: this section may be removed on publication as an 428 RFC.] 430 To summarize, the following items are needed to achieve HCoIPsec: 431 o Extensions to traditional HC schemes which enable their operation 432 at IPsec SA enpoints 433 o Extensions to IKE/IPsec to support HC parameter configuration 434 o Allocation of one value for "compressed headers" from the IANA 435 "Protocol Numbers" registry 437 7. Security Considerations 439 A malfunctioning header compressor (i.e., the compressor located at 440 the ingress of the IPsec tunnel) has the ability to send packets to 441 the decompressor (i.e., the decompressor located at the egress of the 442 IPsec tunnel) that do not match the original packets emitted from the 443 end-hosts. Such a scenario will result in a decreased efficiency 444 between compressor and decompressor. Furthermore, this may result in 445 Denial of Service, as the decompression of a significant number of 446 invalid packets may drain the resources of an IPsec device. 448 8. IANA Considerations 450 None. 452 9. Acknowledgments 453 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 454 and Ms. Linda Noone of the Department of Defense, and well as Mr. 455 Rich Espy of OPnet for their contributions and support in the 456 development of this document. In addition, the authors would like to 457 thank the following for their numerous reviews and comments to this 458 document: 460 o Dr. Stephen Kent 461 o Dr. Carsten Bormann 462 o Mr. Lars-Erik Jonnson 463 o Mr. Jan Vilhuber 464 o Mr. Dan Wing 465 o Mr. Kristopher Sandlund 467 Finally, the authors would also like to thank Mr. Tom Conkle, Ms. 468 Renee Esposito, Mr. Etzel Brower, and Mr. Jonah Pezeshki of Booz 469 Allen Hamilton for their assistance in completing this work. 471 10. References 473 10.1. Normative References 475 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 476 Internet Protocol", RFC 4301, December 2005. 478 [IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header 479 Compression", RFC 2507, February 1999. 481 [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 482 Headers for Low-Speed Serial Links", RFC 2508, 483 February 1999. 485 [ECRTP] Koren, T. and et. al., "Compressing IP/UDP/RTP Headers on 486 Links with High Delay, Packet Loss, and Reordering", 487 RFC 3545, July 2003. 489 [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 490 Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., 491 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 492 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 493 Compression (ROHC): Framework and four profiles: RTP, UDP, 494 ESP, and uncompressed", RFC 3095, July 2001. 496 [ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header 497 Compression Algorithm ECRTP", November 2004. 499 [ROHCTCP] Pelletier, G. and et. al, "Robust Header Compression: A 500 Profile For TCP/IP (ROHC-TCP)", work in progress , 501 January 2006. 503 [ROHCWEXT] 504 Pelletier, G. and et. al, "ROHC over Channels That Can 505 Reorder Packets", RFC 4224, January 2006. 507 10.2. Informative References 509 [ESP] Kent, S., "IP Encapsulating Security Payload", RFC 4303, 510 December 2005. 512 [HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header 513 Compression over MPLS", April 2005. 515 [CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, 516 "Evaluation of CRTP Performance over Cellular Radio 517 Networks", IEEE Personal Communication Magazine , Volume 518 7, number 4, pp. 20-25, August 2000. 520 [ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS", 521 RFC 4247, November 2005. 523 Authors' Addresses 525 Emre Ertekin 526 Booz Allen Hamilton 527 13200 Woodland Park Dr. 528 Herndon, VA 20171 529 US 531 Email: ertekin_emre@bah.com 533 Chris Christou 534 Booz Allen Hamilton 535 13200 Woodland Park Dr. 536 Herndon, VA 20171 537 US 539 Email: christou_chris@bah.com 541 Rohan Jasani 542 Booz Allen Hamilton 543 13200 Woodland Park Dr. 544 Herndon, VA 20171 545 US 547 Email: jasani_rohan@bah.com 549 Intellectual Property Statement 551 The IETF takes no position regarding the validity or scope of any 552 Intellectual Property Rights or other rights that might be claimed to 553 pertain to the implementation or use of the technology described in 554 this document or the extent to which any license under such rights 555 might or might not be available; nor does it represent that it has 556 made any independent effort to identify any such rights. Information 557 on the procedures with respect to rights in RFC documents can be 558 found in BCP 78 and BCP 79. 560 Copies of IPR disclosures made to the IETF Secretariat and any 561 assurances of licenses to be made available, or the result of an 562 attempt made to obtain a general license or permission for the use of 563 such proprietary rights by implementers or users of this 564 specification can be obtained from the IETF on-line IPR repository at 565 http://www.ietf.org/ipr. 567 The IETF invites any interested party to bring to its attention any 568 copyrights, patents or patent applications, or other proprietary 569 rights that may cover technology that may be required to implement 570 this standard. Please address the information to the IETF at 571 ietf-ipr@ietf.org. 573 Disclaimer of Validity 575 This document and the information contained herein are provided on an 576 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 577 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 578 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 579 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 580 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 581 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 583 Copyright Statement 585 Copyright (C) The Internet Society (2006). This document is subject 586 to the rights, licenses and restrictions contained in BCP 78, and 587 except as set forth therein, the authors retain all their rights. 589 Acknowledgment 591 Funding for the RFC Editor function is currently provided by the 592 Internet Society.