idnits 2.17.1 draft-ietf-rohc-hcoipsec-00.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 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 651. ** 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 499: '...mpressed packets MAY be concatenated w...' 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 (November 2, 2005) is 6744 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPSEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECRTPE' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROHCTCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROHCWEXT' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 11 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: May 6, 2006 R. Jasani 5 Booz Allen Hamilton 6 November 2, 2005 8 Integration of Header Compression over IPsec Security Associations 9 draft-ietf-rohc-hcoipsec-00 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 May 6, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Internet Protocol security mechanisms, such as IP Security (IPsec) 43 [IPSEC], provides various security services for IP traffic. However, 44 the benefits offered by IPsec come at the cost of increased overhead. 45 This document identifies a methodology for integrating header 46 compression (HC) over IPsec (HCoIPsec). HCoIPsec proposes to reduce 47 the amount of packet overhead associated with the transmission of 48 traffic over tunnel mode security associations. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Problem Statement: Packet Overhead Associated with IPsec 55 Tunnel-Mode SAs . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. The Header Compression Solution . . . . . . . . . . . . . . . 4 57 5. Integration Methodology . . . . . . . . . . . . . . . . . . . 5 58 5.1 Work Assumptions . . . . . . . . . . . . . . . . . . . . . 6 59 5.2 Work Items . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.2.1 Header Compression Scheme-Specific Extensions . . . . 7 61 5.2.2 Initialization and Negotiation of Header 62 Compression Channel . . . . . . . . . . . . . . . . . 7 63 5.2.3 Encapsulation and Identification of Header 64 Compressed Packets . . . . . . . . . . . . . . . . . . 8 65 6. Candidate Compression Schemes . . . . . . . . . . . . . . . . 8 66 7. Example Operation . . . . . . . . . . . . . . . . . . . . . . 9 67 8. Future Work Items . . . . . . . . . . . . . . . . . . . . . . 11 68 8.1 HCoIPsec Transport Mode SAs . . . . . . . . . . . . . . . 11 69 8.2 Multiplexing of Compressed Packets in IPsec Tunnels . . . 12 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 12.1 Normative References . . . . . . . . . . . . . . . . . . . 13 75 12.2 Informative References . . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 77 Intellectual Property and Copyright Statements . . . . . . . . 16 79 1. Introduction 81 This document identifies a methodology for the integration of header 82 compression (HC) over IPsec Security Associations (SAs) operating in 83 tunnel mode. The goal of integrating HC with IPsec is to reduce the 84 protocol overhead associated with packets traversing between IPsec SA 85 endpoints. This goal can be achieved by compressing the upper layer 86 protocols (e.g., RTP/UDP and TCP) and the inner IP header of packets, 87 at the ingress of the IPsec tunnel, and decompression at the egress. 89 To accomplish HCoIPsec, this document proposes the use of Internet 90 Protocol Header Compression [IPHC], Compressed Real Time Protocol 91 [CRTP], Enhanced Compressed Real Time Protocol [ECRTP], and Robust 92 Header Compression [ROHC], to compress the inner headers of IP 93 packets traversing within an IPsec tunnel. However, since these HC 94 schemes operate on a hop-by-hop basis, several extensions need to be 95 defined. This document details a methodology which will enable these 96 traditional hop-by-hop HC schemes to be extended, and operate between 97 IPsec SA endpoints. 99 Currently, HCoIPsec primarily targets the application of HC to tunnel 100 mode SAs as opposed to transport mode SAs. Transport mode SAs 101 encrypt/authenticate only the payload of an IP packet, leaving the 102 original IP header untouched. Intermediate routers subsequently use 103 the original IP header to route the packet to a decryption device. 104 Therefore, if HC were extended to operate between IPsec transport- 105 mode SA endpoints, (de)compression functionality can be applied only 106 to the transport layer headers and not the IP header. Since 107 compression of transport layer headers alone does not provide 108 substantial efficiency gains, it is not fully integrated into the 109 HCoIPsec methodology. 111 2. Audience 113 The target audience includes those who are involved with the design 114 and development of HC schemes, and IPsec mechanisms. Since 115 traditional IETF HC schemes are designed to operate on a hop-by-hop 116 basis, they need to be modified to operate over IPsec SAs. 117 Therefore, the authors target various HC and IPsec communities who 118 may consider extending hop-by-hop HC schemes and IPsec protocols to 119 meet the methodology put forward in this document. Finally, this 120 document is directed towards vendors developing IPsec devices which 121 will be deployed in bandwidth-constrained, IP networks. 123 3. Problem Statement: Packet Overhead Associated with IPsec Tunnel-Mode 124 SAs 126 IPsec mechanisms provide various security services for IP-based 127 networks. For example, ESP offers data origin authentication, 128 connectionless integrity, anti-replay service, and limited traffic 129 flow confidentiality [ESP]. 131 The benefits of IPsec mechanisms come at the cost of increased per- 132 packet overhead in the network. For example, traffic flow 133 confidentiality, which is generally implemented at security gateways, 134 requires the tunneling of IP packets between the IPsec devices. 135 IPsec tunnels may mask the source-destination patterns that an 136 intruder may ascertain, but the benefit comes at the cost of extra 137 per-packet overhead. An ESP tunnel mode SA applied to an IPv6 flow 138 results in at least 50 bytes of additional overhead per packet. This 139 additional overhead may be undesirable for many bandwidth-constrained 140 wireless and/or Satellite Communications (SATCOM) networks, as these 141 types of infrastructure are not overprovisioned. Consequently, the 142 additional overhead incurred in an encryption-based environment may 143 hinder the efficient utilization of bandwidth. 145 In bandwidth-constrained high bit error rate (BER) networks, end-host 146 applications may not have the luxury of sending packets with large 147 payloads. This is due to the fact that large packets traversing high 148 BER links result in high IP Packet Loss Ratio (IPLR). To reduce 149 IPLR, end-host devices may reduce the size of packet payloads, which 150 decreases the probability that a packet is lost due to a bit error. 151 Reducing the size of packet payloads, however, increases the amount 152 of overhead transmitted between the two end hosts. Moreover, if 153 these packets traverse over an IPsec tunnel mode SA, the amount of 154 overhead is further magnified. A mechanism is needed to reduce the 155 overhead associated with such flows. 157 4. The Header Compression Solution 159 IP HC schemes provide one mechanism to reduce packet overhead in an 160 IP network. Schemes such as IPHC, CRTP, ECRTP and ROHC exploit 161 inter-packet redundancies of network and transport-layer header 162 fields of a flow to reduce the amount of redundant header data 163 transmitted between two nodes. 165 To apply HC schemes over IPsec SAs, several extensions to the 166 existing schemes need to be developed. Existing HC schemes such as 167 IPHC, CRTP, ECRTP and ROHC are designed to compress headers on a hop- 168 by-hop basis. IPsec SAs, however, may be instantiated between IPsec 169 devices functioning as gateways, with multiple intermediary nodes 170 between the IPsec gateways. Therefore, to fully integrate HC with 171 IPsec SAs, traditional hop-by-hop schemes need to be extended to 172 operate between IPsec SA endpoints. 174 The migration of traditional hop-by-hop HC schemes over IPsec SAs is 175 simple, as SA endpoints provide source/destination pairs where 176 (de)compression operations can take place. Compression in such a 177 manner offers both a reduction of per-packet protocol overhead 178 between the two SA endpoints, and does not require compression and 179 decompression cycles at the intermediate network nodes between the 180 IPsec devices. Since HC schemes will now essentially operate over 181 multiple hops, it is imperative that the performance of the HC 182 schemes is not severely impacted due to increased packet reordering 183 and/or IPLR events between the compressor and decompressor. It 184 should be noted that the notion of extending hop-by-hop HC schemes to 185 operate over multiple hops is not new, as the HCoIPsec effort 186 parallels other efforts such as ECRTP over MPLS [HCOMPLS]. 188 Using the proposed architecture, outbound IP traffic processing at an 189 IPsec device is augmented to compress appropriate packet headers, and 190 subsequently encrypt and/or integrity-protect the packet. For tunnel 191 mode SAs, compression may be applied to the transport layer protocol 192 and the inner IP header. 194 Inbound IP traffic processing at an IPsec device is modified in a 195 similar fashion. For inbound packets, an IPsec device must first 196 decrypt and/or integrity-check the packet. Then, the IPsec device 197 implicitly determines whether the packet was received on a HC-enabled 198 SA. If the packet was received over a HC-enabled SA, the 199 decompression function takes place. 201 Note: Compression of inner headers is completely independent from 202 compression of the outer (e.g., ESP/IP) headers. Intermediate 203 network nodes between IPsec endpoints may also compress the outer 204 ESP/IP headers. Current HC schemes such as ROHC and IPHC contain 205 the ability to compress these ESP/IP headers. Further discussion 206 of hop-by-hop compression of the outer ESP/IP headers is out of 207 the scope of this document. 209 If IPsec NULL encryption is applied on packets, HC schemes may still 210 be applied on the inner headers at the IPsec SA endpoints. Inbound 211 and outbound packets are processed as described previously. In 212 scenarios where NULL-encrypted packets traverse intermediate nodes 213 between the IPsec SA endpoints, the intermediary nodes must not 214 attempt to (de)compress the inner IP and/or transport layer headers 215 on a hop-by-hop basis. 217 5. Integration Methodology 219 The goal for HCoIPsec is to provide more efficient transport of IP 220 packets between source and destination IPsec devices without 221 compromising security services offered by IPsec. 223 With this general goal in mind, Section 5.1 defines a set of work 224 assumptions to guide the direction of the HCoIPsec solution. Based 225 on these work assumptions, Section 5.2 defines work items which need 226 to be addressed to achieve the HCoIPsec solution. 228 5.1 Work Assumptions 230 a. HCoIPsec must use existing HC protocols (e.g., IPHC, CRTP, ECRTP, 231 ROHC) to reduce the amount of overhead associated with packets 232 traversing an IPsec tunnel-mode SA. 233 b. HCoIPsec must execute (de)compression operations at IPsec SA 234 endpoints, and must not perform (de)compression cycles at 235 intermediate nodes between IPsec devices. 236 c. HCoIPsec must be independent of the underlying link layer framing 237 protocol (e.g., PPP). 238 d. HCoIPsec must allow each SA to constitute a HC channel, enabling 239 each SA to have its own CID space. 240 e. An SA with HC enabled should not deliver a larger number of 241 erroneous packets than the same SA with HC disabled. 243 The motivation behind (c) comes from the realization that an SA may 244 traverse multiple links, employing various framing protocols, and 245 that the set of links (and thus framing protocols) may change during 246 the lifetime of an SA. Therefore, link layer dependencies exhibited 247 by traditional hop-by-hop HC schemes cannot be used in the HCoIPsec 248 solution. 250 5.2 Work Items 252 This section identifies several work items that need to be addressed 253 to achieve HCoIPsec. The first work item encompasses the HC scheme- 254 specific extensions needed to ensure that traditional hop-by-hop HC 255 schemes will operate efficiently over IPsec SA endpoints: 257 a. Header Compression Scheme-Specific Extensions: Any modifications 258 needed to be made to existing HC schemes, which will facilitate 259 their operation over IPsec SAs. (Section 5.2.1) 261 Hop-by-hop HC schemes use the underlying link layer (e.g., PPP) to 262 negotiate the HC channel parameters and to indicate the type of 263 compressed packet the data-link layer frame is encapsulating. To 264 remove HC scheme dependencies on the underlying link layer, two 265 additional work items are proposed: 267 b. Initialization and Negotiation of the Header Compression Channel: 268 Mechanisms needed to initialize a HC channel and negotiate HC 269 scheme parameters prior to operation. (Section 5.2.2) 270 c. Encapsulation and Identification of Header Compressed Packets: 271 Mechanisms that encapsulate and identify compressed header 272 packets, as well as how these mechanisms will operate. (Section 273 5.2.3) 275 5.2.1 Header Compression Scheme-Specific Extensions 277 a. HCoIPsec should minimize HC scheme performance degradation due to 278 increased delays, packet loss, jitter, and reordering events 279 between compressor and decompressor. 280 b. HCoIPsec should minimize the amount of HC signaling between 281 compressor and decompressor. 283 The intention of (b) is to indicate that if a feedback channel from 284 the decompressor to the compressor is not used sparingly, then the 285 overall gains from HCoIPsec can be significantly reduced (even more 286 so than hop-by-hop HC). For example, take the case where ROHC in bi- 287 directional reliable mode is instantiated over an IPsec tunnel mode 288 SA. Any feedback sent from the decompressor to the compressor may be 289 tunneled, and therefore, the additional overhead incurred by 290 tunneling the feedback will reduce the overall benefits of HC. 292 Note that if a HCoIPsec session requires bidirectional communication 293 between the compressor and the decompressor (e.g., a ROHC session 294 operating in bidirectional-reliable mode, or bidirectional-optimistic 295 mode, or ECRTP and CONTEXT_STATE packets), this may pose an issue, 296 given that SAs are unidirectional, and that HCoIPsec defines a HC 297 context to be specific to a given SA. Any feedback packet 298 communicated from the HCoIPsec decompressor to the HCoIPsec 299 compressor is over a separate SA back to the original IPsec device. 300 To identify the stale context, the feedback packet must contain the 301 context ID as well as an indication of the SA that the decompressor 302 is associated to. This poses a problem for current HC algorithm 303 feedback packets, which are not structured to carry the additional SA 304 indication information. For example, current ECRTP feedback 305 mechanisms (e.g., CONTEXT_STATE) only list the CIDs for which 306 synchronization has been lost. If a bidirectional HC algorithm is to 307 be integrated with IPsec, additional HC scheme-specific extensions 308 must be defined to resolve this issue. 310 5.2.2 Initialization and Negotiation of Header Compression Channel 312 Initialization of the HC channel parameters may achieved manually 313 (i.e., administratively configured for manual SAs), or may be 314 performed by IPsec SA establishment protocols, e.g. IKE. During SA 315 initialization, the IPsec SA establishment protocols will identify 316 the type of HC scheme configured for the SA, as well as the HC 317 scheme's channel parameters. 319 a. HCoIPsec may leverage IKE, IKEv2 to negotiate HC channel 320 parameters (e.g., for ROHC, IKE(v2) shall initialize PROFILES, 321 MAX_CID, MAX_HEADER, MRRU). 322 b. HCoIPsec must allow packets with uncompressed headers and packets 323 with compressed headers to traverse a single SA. "Packets with 324 compressed headers" refer to packets which are selected to an HC- 325 enabled SA, are passed to the compressor, and are actually 326 compressed; "packets with uncompressed headers" refer to packets 327 which are selected to an HC-enabled SA, are passed to the 328 compressor, and are not "compressed" (e.g., ROHC compressor 329 processes a packet with the uncompressed profile). 331 (b) is necessary in situations where a compressor--for one reason or 332 another--cannot compress a flow (e.g., a compressor supports strictly 333 n compressed flows, and cannot compress the n+1 flow that arrives). 335 5.2.3 Encapsulation and Identification of Header Compressed Packets 337 For indication purposes, a one-byte header may be added to the 338 compressed packet; this field will help the decompressor identify how 339 to process the compressed packet. This one-byte header is only 340 relevant to the HC compression and decompression processes, and is 341 not used by IPsec.. 343 a. HCoIPsec may introduce a new one-byte header to indicate the type 344 of compressed packet (e.g., for ECRTP, COMPRESSED_RTP_8, 345 COMPRESSED_RTP_16, CONTEXT_STATE, etc.) 347 Note that ROHC indicates its own packet type within the protocol, and 348 does not require a new one-byte header to indicate the type of 349 compressed packet. 351 6. Candidate Compression Schemes 353 IPHC can be used to compress TCP/IP headers for tunnel mode SAs. 354 IPHC, however, has been identified as a HC scheme that performs 355 poorly over long round trip time (RTT), high BER links [ROHC]. 356 Extensions to IPHC to compress TCP/IP headers over an IPsec SA need 357 to take into consideration longer RTTs, increased potential for 358 packet reordering and IPLR between the compressor and decompressor. 360 CRTP can be used to compress RTP/UDP/IP headers for tunnel mode SAs. 361 CRTP, however, has also been identified as a HC scheme that performs 362 poorly over long RTT, high BER links [CRTPE]. Recent modifications 363 to the CRTP scheme, such as ECRTP, enables the CRTP HC scheme to 364 tolerate long RTTs, packet loss, between compressor and decompressor. 365 The reordering tolerance of ECRTP, however, needs to be evaluated, as 366 detailed in [ECRTPE]. Such implementation aspects should be taken 367 into consideration when extending ECRTP to operate between IPsec SA 368 endpoints. 370 ROHC, as defined in RFC 3095, provides a robust HC scheme that is 371 designed for high BER, long RTT links. This makes ROHC another 372 candidate header scheme to operate over IPsec tunnels. ROHC can be 373 used to compress not only RTP/UDP/IP headers, but also TCP/IP 374 headers, as defined in [ROHCTCP]. Similar to CRTP and IPHC, ROHC has 375 been identified as vulnerable to packet reordering events between the 376 compressor and decompressor[ROHCE]. Recent work [ROHCWEXT] suggests 377 that the implementation aspects of ROHC can be modified to achieve 378 tolerance to packet reordering events. Such implementation aspects 379 should be taken into consideration when extending ROHC to operate 380 between IPsec SA endpoints. 382 The ability to tolerate these network characteristics is a necessity 383 for any HCoIPsec scheme, and will be a factor in determining how 384 efficiently the HC scheme operates over the IPsec tunnel-mode SAs. 386 7. Example Operation 388 The basic operation of the HCoIPsec protocol is detailed in the 389 following example. Assume there are two IPsec devices operating as 390 security gateways. HCoIPsec leverages an SA establishment protocol 391 (e.g., IKE, IKEv2) to negotiate the HC scheme, and channel 392 parameters. For example, the MAX_CID, MRRU, MAX_HEADER, and PROFILES 393 parameters will be negotiated for each IPsec SA which is capable of 394 ROHC. For an IPsec SA that is ECRTP-enabled, channel parameters 395 including F_MAX_PERIOD, F_MAX_TIME, and the ECRTP Compression 396 Suboption will be initialized. For the following example, assume 397 that a HC-enabled SA has been established. 399 Outbound packet processing is as follows. The packet is initially 400 processed as described in Steps 1-2, Section 5.1 of RFC 2401bis. The 401 SPD cache entry then maps the packet to a given SAD entry, which 402 indicates the HC protocol enabled on the SA (in addition to mode, 403 cryptographic algorithms, keys, etc.). If the SAD entry indicates 404 that compression is disabled, then standard IPsec processing ensues, 405 as described in Steps 3-4, Section 5.1 of RFC 2401bis. If the SAD 406 entry indicates that compression is enabled, the packet must be 407 handed to the appropriate compressor, which executes the compression 408 process. After the packet's header is compressed, the packet resumes 409 IPsec processing as described in Step 3a, where standard IPsec ESP 410 processing ensues (including packet encryption according to the SAD 411 entry parameters, packet encapsulation with the outer ESP/IP header) 412 and is subsequently passed to the outbound forwarding function, as 413 described in Step 4 of RFC 2401bis. 415 Inbound packet processing is as follows. The packet is initially 416 processed as described in Steps 1-3, Section 5.2 of RFC 2401bis; 417 subsequently (using the SAD entry selected in Step 3a), ESP 418 processing is applied. Based on information retrieved from the SAD 419 entry, it can also be determined whether traffic traversing the SA is 420 compressed or not compressed. If the SAD entry indicates that 421 compression is not enabled on the SA, then standard IPsec processing 422 of the packet ensues, as described in Step 4, Section 5.2 of RFC 423 2401bis. If compression is enabled on the SA, the packet is handed 424 to the decompressor for "decompression". Once the packet is 425 decompressed, the processing as described in Step 4, Section 5.2 of 426 2401bis resumes (specifically "Then match the packet against the 427 inbound selectors identified by the SAD..."). 429 Figure 1 depicts the basic function of HCoIPsec: 431 -- -- -- -- -- -- -- -- -- -- 432 |ESP Tunnel Mode Security Association| 433 | | 434 | | 435 V V 436 +--------------+ +--------------+ 437 | IPsec Device | +--+ +--+ | IPsec Device | 438 | | | | | | | | 439 +---| Compressor |-->|R1|-->|R2|-->| Decompressor |---+ 440 | | | | | | | | | | 441 | +--------------+ +--+ +--+ +--------------+ | 442 | | | | 443 | |-----------------| | 444 | | | 445 | | | 446 V V V 447 +-----------------+ +-----------------------+ +-----------------+ 448 | | | | | | | | | | | | 449 | | UDP | | | | E | ------------- | | | UDP | | 450 |IP | / |Payload| |IP | S | |CID|Payload| | |IP | / |Payload| 451 | | RTP | | | | P | ------------- | | | RTP | | 452 | | | | | | | | | | | | 453 +-----------------+ +-----------------------+ +-----------------+ 454 | | 455 |---ENCRYPTED---| 456 | | 458 Figure 1: Example operation of HCoIPsec. 460 In the example scenario, note that the inbound and outbound packets 461 are first mapped to an SA, and then subsequently mapped to a CID. 462 This implies that the scope of each CID is contained within each SA. 463 A CID value of 1 can be associated with multiple SAs; however, the 464 context state information for CID 1 cannot be shared over multiple 465 SAs. 467 8. Future Work Items 469 8.1 HCoIPsec Transport Mode SAs 471 Many of the current HC profiles look to simultaneously compress 472 network and transport layer headers of IP packets. This makes the 473 extension of traditional HC schemes over transport-mode SAs more 474 difficult. For the application of HC over transport mode SAs, 475 traditional HC schemes may need to be extended to operate strictly on 476 layer 4 (e.g., TCP, and/or RTP/UDP) headers. The methodology and 477 specification for HCoIPsec transport mode SAs is left for further 478 study. 480 8.2 Multiplexing of Compressed Packets in IPsec Tunnels 482 It should also be noted that a packet concatenation (or multiplexing) 483 scheme may be added in conjunction to HCoIPsec to further reduce the 484 overall overhead of packets traversing between IPsec devices. This 485 type of functionality is similar to AAL2 voice trunking, where voice 486 packets from different sources are placed into one cell [AAL2]. As 487 described in [AAL2], a multiplexer concatenates cells until one of 488 following two events occur: 489 o the first event indicates that the maximum size of multiplexed 490 cell is reached; 491 o the second event indicates that a timer has expired: this timer 492 provides an upper bound on the amount of delay a cell may exhibit. 493 When either of these events are triggered, the multiplexer transmits 494 the multiplexed cells. 496 [TCRTP] is one proposal to reduce the packet overhead used between 497 call gateways in an unencrypted network. In a similar fashion, if 498 multiple compressed flows are mapped to one SA between two IPsec 499 devices, then compressed packets MAY be concatenated with one 500 another, encrypted, and subsequently tunneled to the destination 501 IPsec device with one ESP/IP header. It should be noted, however, 502 that a multiplexing functionality may be undesirable for the high BER 503 networks, as multiplexing scheme may increase average packet sizes, 504 which may result in a greater IPLR. The specification of such a 505 protocol is left for further study. 507 9. Security Considerations 509 A malfunctioning header compressor (i.e., the compressor located at 510 the ingress of the IPsec tunnel) has the ability to send packets to 511 the decompressor (i.e., the decompressor located at the egress of the 512 IPsec tunnel) that do not match the original ones emitted from the 513 end-hosts. In such a scenario, the invalid packets will pass the 514 inbound IPsec process, and will subsequently be validly decompressed. 516 Furthermore, an intruder who has the ability to arbitrarily inject 517 packets between SA endpoints, and addresses these malicious packets 518 to the encryption/decryption devices, has the ability to cause 519 context corruption between the compressor and decompressor processes 520 instantiated within the IPsec device (if the malicious packet passes 521 through the decryption process). Such a scenario will result in a 522 decreased efficiency between compressor and decompressor, and 523 furthermore, may result in Denial of Service, as the decompression of 524 a significant number of invalid packets may drain the resources of an 525 IPsec device. 527 Note: It should be noted, however, that these security issues are 528 a direct offset of IPsec vulnerabilities. 530 10. IANA Considerations 532 None. 534 11. Acknowledgments 536 The authors would like to thank Mr. Sean O'Keeffe, Mr. James Kohler, 537 of the Department of Defense, and Mr. A. Rich Espy of OPnet for their 538 contributions and support for developing this document. The authors 539 would also like to thank Mr. Jan Vilhuber, Mr. Dan Wing, of Cisco 540 Systems, Mr. Lars-Erik Jonsson and Mr. Kristopher Sandlund of 541 Ericsson for their valuable contributions to this document. The 542 authors would also like to thank Ms. Renee Esposito, Mr. Etzel 543 Brower, Mr. Jigar Amroliwala, and Mr. Dwayne Corbin of Booz Allen 544 Hamilton for their assistance in completing this work. 546 12. References 548 12.1 Normative References 550 [IPSEC] Kent, S. and K. Seo, "Security Architecture for the 551 Internet Protocol", work in progress , March 2005. 553 [IPHC] Nordgren, M., Pink, B., and S. Pink, "IP Header 554 Compression", RFC 2507, February 1999. 556 [CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 557 Headers for Low-Speed Serial Links", RFC 2508, 558 February 1999. 560 [ECRTP] Koren, T. and et. al., "Compressing IP/UDP/RTP Headers on 561 Links with High Delay, Packet Loss, and Reordering", 562 RFC 3545, July 2003. 564 [ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 565 Hannu, H., Jonsson, L., Hakenberg, R., Koren, T., Le, K., 566 Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 567 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 568 Compression (ROHC): Framework and four profiles: RTP, UDP, 569 ESP, and uncompressed", RFC 3095, July 2001. 571 [ECRTPE] Knutsson, C., "Evaluation and Implemenation[sic] of Header 572 Compression Algorithm ECRTP", November 2004. 574 [ROHCTCP] Pelletier, G. and et. al, "Robust Header Compression: A 575 Profile For TCP/IP (ROHC-TCP)", work in progress , 576 February 2005. 578 [ROHCWEXT] 579 Pelletier, G. and et. al, "ROHC over Channels That Can 580 Reorder Packets", work in progress , February 2005. 582 12.2 Informative References 584 [ESP] Kent, S., "IP Encapsulating Security Payload", work in 585 progress , March 2005. 587 [HCOMPLS] Ash, J. and et. al, "Protocol Extensions for Header 588 Compression over MPLS", April 2005. 590 [CRTPE] Degermark, M., Hannu, H., Jonsson, L., and K. Svanbro, 591 "Evaluation of CRTP Performance over Cellular Radio 592 Networks", IEEE Personal Communication Magazine , Volume 593 7, number 4, pp. 20-25, August 2000. 595 [ROHCE] Ash, J. and et. al, "Requirements for ECRTP over MPLS", 596 work in progress , December 2004. 598 [AAL2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 599 AAL", I.363.2 , September 1997. 601 [TCRTP] Thompson, B., "Tunneling of Multiplexed Compressed RTP", 602 work in progress , September 2004. 604 Authors' Addresses 606 Emre Ertekin 607 Booz Allen Hamilton 608 8283 Greensboro Drive 609 McLean, VA 22102 610 US 612 Email: ertekin_emre@bah.com 613 Chris Christou 614 Booz Allen Hamilton 615 8283 Greensboro Drive 616 McLean, VA 22102 617 US 619 Email: christou_chris@bah.com 621 Rohan Jasani 622 Booz Allen Hamilton 623 8283 Greensboro Drive 624 McLean, VA 22102 625 US 627 Email: jasani_rohan@bah.com 629 Intellectual Property Statement 631 The IETF takes no position regarding the validity or scope of any 632 Intellectual Property Rights or other rights that might be claimed to 633 pertain to the implementation or use of the technology described in 634 this document or the extent to which any license under such rights 635 might or might not be available; nor does it represent that it has 636 made any independent effort to identify any such rights. Information 637 on the procedures with respect to rights in RFC documents can be 638 found in BCP 78 and BCP 79. 640 Copies of IPR disclosures made to the IETF Secretariat and any 641 assurances of licenses to be made available, or the result of an 642 attempt made to obtain a general license or permission for the use of 643 such proprietary rights by implementers or users of this 644 specification can be obtained from the IETF on-line IPR repository at 645 http://www.ietf.org/ipr. 647 The IETF invites any interested party to bring to its attention any 648 copyrights, patents or patent applications, or other proprietary 649 rights that may cover technology that may be required to implement 650 this standard. Please address the information to the IETF at 651 ietf-ipr@ietf.org. 653 Disclaimer of Validity 655 This document and the information contained herein are provided on an 656 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 657 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 658 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 659 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 660 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 661 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 663 Copyright Statement 665 Copyright (C) The Internet Society (2005). This document is subject 666 to the rights, licenses and restrictions contained in BCP 78, and 667 except as set forth therein, the authors retain all their rights. 669 Acknowledgment 671 Funding for the RFC Editor function is currently provided by the 672 Internet Society.