idnits 2.17.1 draft-mglt-ipsecme-diet-esp-payload-compression-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 2, 2014) is 3586 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) == Outdated reference: A later version (-12) exists of draft-mglt-ipsecme-diet-esp-00 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME D. Migault, Ed. 3 Internet-Draft Orange 4 Intended status: Standards Track T. Guggemos, Ed. 5 Expires: January 3, 2015 Orange / LMU Munich 6 July 2, 2014 8 Diet-IPsec: ESP Payload Compression of IPv6 / UDP / TCP / UDP-Lite 9 draft-mglt-ipsecme-diet-esp-payload-compression-00.txt 11 Abstract 13 ESP is a IPsec protocol that takes as input a Clear Text Data and 14 outputs an encrypted ESP packet according to IPsec rules and 15 parameters stored in different IPsec databases. 17 Diet-ESP compresses the ESP fields. However, Diet-ESP does not 18 consider compression of the Clear Text Data. Instead, if compression 19 of the Clear Text Data is expected protocols like ROHCoverIPsec can 20 be used. 22 ROHCoverIPsec remains complex to implement in IoT devices, as states, 23 and negotiations are involved between the compressors and 24 decompressors of the two IoT devices. Most of this complexity can be 25 avoided by considering the parameters that have been negotiated by 26 IPsec. 28 This document describes an extension of the Diet-ESP Context that 29 enables the compression of the Clear Text Data, without implementing 30 the complex ROHCoverIPsec framework. As opposed to ROHCoverIPsec the 31 compression is not generic and as such all communication will not 32 benefit from this compression. However, we believe this extension 33 addresses most of IoT communications. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 3, 2015. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Diet-ESP Context Extension . . . . . . . . . . . . . . . . . 4 72 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 73 6. IP Layer Compression . . . . . . . . . . . . . . . . . . . . 6 74 7. UDP Transport Layer Compression . . . . . . . . . . . . . . . 8 75 8. UDP-Lite Transport Layer Compression . . . . . . . . . . . . 9 76 9. TCP Transport Layer Compression . . . . . . . . . . . . . . . 10 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 11 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 13.2. Informational References . . . . . . . . . . . . . . . . 12 83 Appendix A. Interaction with ROHC profiles . . . . . . . . . . . 12 84 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in[RFC2119]. 93 2. Introduction 95 Diet-ESP [I-D.mglt-ipsecme-diet-esp] describes how to compress ESP 96 fields. Fields are compressed according to a Diet-ESP Context. 97 Diet-ESP has been described as a specific ROHC [RFC5795] framework 98 that has no IR, IR-DYN nor any feed back ROHC message. It works in 99 the Unidirectional mode of operation (U mode), and all necessary 100 parameters are transmitted via the Diet-ESP Context that is 101 negotiated between the two peers. As a result Diet-ESP defines a 102 very specific and simplified ROHC framework which makes possible to 103 implement Diet-ESP without implementing the whole ROHC. 105 In fact, Diet-ESP avoids ROHC complexity as a lot of parameters have 106 already been negotiated with IKEv2 [RFC5996]. 108 This document describes the Diet-ESP Payload Compression Extension. 109 It does not consider the compression of the ESP fields. Instead, it 110 goes one step further and describes how to compress the Clear Text 111 Data or ESP Payload before it is encrypted by Diet-ESP. The Clear 112 Text Data is generally constituted by an IP packet with IP -- if 113 IPsec tunnel mode is used --, transport and application layers. 114 Similarly to Diet-ESP, compression takes advantage of the IPsec 115 parameters -- like IP addresses, transport layer parameters -- that 116 have been negotiated in order to establish the Security Association 117 -- via IKEv2 for example. In addition, similarly to Diet-ESP, the 118 compression is described using the ROHC terminology, but uses a very 119 specific and simplified ROHC framework of Diet-ESP. This makes 120 possible compression of the Clear Text Data without implementing a 121 whole ROHC framework for ROHCoverIPsec [RFC5856]. 123 [I-D.mglt-ipsecme-diet-esp] clarifies the interactions of Diet-ESP 124 with ROHC and 6LoWPAN. The Diet-ESP extension explained in this 125 document replaces ROHCoverIPsec and 6LoWPANoverIPsec, protocols which 126 offers similar functionality without using the IPsec databases. The 127 Diet-ESP Payload Compression Extension uses the IPsec databases to 128 avoid complex dialogues between compressors and decompressors. 130 The Diet-ESP Payload Compression Extension can be described as 131 follows: 133 - 1. Definition or Diet-ESP parameters: COMPRESS_ESP_PAYLOAD, 134 CHECKSUM_LSB and SEQUENCE_NUMBER_LSB. COMPRESS_ESP_PAYLOAD 135 indicates the peers expect the Clear Text Data to be compressed, 136 CHECKSUM_LSB and SEQUENCE_NUMBER_LSB are additional parameters to 137 perform the compression. 139 - 2. Definition of a Diet-ESP Payload Compression algorithm. 141 The remaining of the document is as follows. Section 4 describes the 142 new parameters for the Diet-ESP Context. Section 5 describes the 143 protocol. Section 6, Section 7, Section 7 and Section 9 describe the 144 compression of the IP layer and the transport layer (UDP, UDP-Lite. 146 3. Terminology 148 Diet-ESP Context: Like defined in Diet-ESP document. 150 SPD: Security Policy Database 152 SAD: Security Association Database 154 TS: Traffic Selector of a Security Association. 156 LSB: Least Significant Byte 158 MSB: Most Significant Byte 160 4. Diet-ESP Context Extension 162 This section describes the additional parameters of the Diet-ESP 163 Context to implement the ESP Payload Compression extension. 165 +----------------------+--------------------------------------------+ 166 | Context Field Name | Overview | 167 +----------------------+--------------------------------------------+ 168 | COMPRESS_ESP_PAYLOAD | Defines the use of the Traffic Selector | 169 | | for (de-)compression. | 170 | CHECKSUM_LSB | LSB of the UDP, UDP-Lite or TCP checksum | 171 | SEQUENCE_NUMBER_LSB | LSB of the TCP Sequence Number. | 172 +----------------------+--------------------------------------------+ 174 Table 1: Diet-ESP Context. 176 COMPRESS_ESP_PAYLOAD: 177 Defines if the ESP Payload MUST be compressed or not. Note that 178 as detailed later, compression of the ESP Payload requires that IP 179 addresses, or protocols are unique in the Security Association 180 Databases. If not the compression does not compress does not 181 output a compressed ESP Payload. 183 CHECKSUM_LSB: 184 If an inner header provides a checksum this can be compressed by 185 the LSB mechanism. How the checksum is compressed is specified by 186 the related profiles, e.g. UDP Section 7 , UDP-Lite Section 8 and 187 TCP Section 9. 189 SEQUENCE_NUMBER_LSB: 190 If an inner header provides a Sequence Number, one MAY choose to 191 use the SN stored in the SA for compression. Therefore the 192 context provides the LSB of the Sequence Number which is used by 193 all profiles, defining the Sequence Number as compressed with LSB, 194 e.g. TCP Section 9. 196 5. Protocol Overview 198 The Diet-ESP Payload Compression is described by the pseudo code in 199 Figure 1. The Clear Text Data is compressed only if 200 COMPRESS_ESP_PAYLOAD is set. Otherwise, it is left unchanged. When 201 COMPRESS_ESP_PAYLOAD is set, compression is performed on the IP and 202 transport layer if and only if two conditions are met. First the 203 layer must exist. This means for example that the IP layer is 204 compressed only for the tunnel mode. Then, the layer can be 205 compressed if and only if the values are uniquely derived from the 206 IPsec databases. More specifically, if a SPD match occurs with at 207 least two different values, then the compression do not occurs. 209 As a result, the IP layer can be compressed only if the IP address 210 appears as a Traffic Selector. If the Traffic Selector is defined as 211 a subnetwork, a SPD match occurs with more then one IP address, and 212 then no compression occurs. Similarly, the transport layer is 213 compressed if and only if it appears as a Traffic Selector. If a SPD 214 match occurs with different transport protocol then the compression 215 of the transport layer does not occurs. 217 The Diet-ESP Payload Compression is straight forward, but may at some 218 point not fits all the needs. At some point using alternative 219 compression as those proposed by ROHCoverIPsec may be preferred. In 220 these cases, Diet-ESP Payload Compression MUST NOT be performed and 221 COMPRESS_ESP_PAYLOAD MUST be unset. 223 if COMPRESS_ESP_PAYLOAD is set : 224 proceed to Diet-ESP Payload Compression 225 else: 226 clear_text_data is left unchanged. 228 def diet_esp_payload_compression(clear_text_data, \ 229 CHECKSUM_LSB,\ 230 SEQUENCE_NUMBER_LSB): 231 if clear_text_data has IP layer and \ ## i.e. IPsec mode Tunnel mode 232 IP address is a Traffic Selector: ## subnets are not considered 233 compress the IP layer 234 if clear_text_data has transport layer and \ 235 transport layer is a Traffic Selector: 236 compress transport layer 238 Figure 1: Diet-ESP Payload Compression Pseudo Code 240 Roughly speaking Diet-ESP is able to remove all header fields which 241 have unique values inside the Security Association Database. Most 242 probably they are stored in the Traffic Selector, which defines the 243 traffic which has to be secured with IPsec. Table 2 shows some 244 header fields which can be adopted from the Traffic Selector. The 245 table provides the ROHC class of these values, as we use the ROHC 246 terminology to describe the compression algorithms. 248 +---------------------+----------+--------------+ 249 | Field | Protocol | ROHC class | 250 +---------------------+----------+--------------+ 251 | IP version | IP/IPv6 | STATIC-KNOWN | 252 | Source Address | IP/IPv6 | STATIC-DEF | 253 | Destination Address | IP/IPv6 | STATIC-DEF | 254 | Next Header | IP/IPv6 | STATIC | 255 | Source PORT | UPD/TCP | STATIC-DEF | 256 | Destination PORT | UPD/TCP | STATIC-DEF | 257 +---------------------+----------+--------------+ 259 Table 2: This values are carried in the Security Association. 261 6. IP Layer Compression 263 This section describes how the compression of the IP layer is 264 performed. The compression of this layer mostly occurs when the 265 peers have negotiated the IPsec tunnel mode. 267 The basic idea for IP layer compression is to remove the IP layer 268 before Diet-ESP encrypts the Clear Text Data. Similarly, for 269 incoming packet, Diet-ESP decrypts the ESP packet, and restores the 270 IP layer by reading the IP address in the IPsec SAD. However, the IP 271 address is not sufficient to restore the complete IP header as other 272 fields must be considered. To appropriately describes the 273 compression of the IP layer, this section uses the ROHC terminology 274 and describes the associated profile. 276 The IP header is classified as shown in Table 3 278 +--------------+------------+--------------+-------------+----------+ 279 | Field | Class | Compression | Diet-ESP | Data | 280 | | | Method | ROHC class | origin | 281 +--------------+------------+--------------+-------------+----------+ 282 | Version | STATIC | removed | STATIC | TS | 283 | Traffic | CHANGING | removed | INFERRED | outer IP | 284 | Class | | | | | 285 | Flow Label | STATIC-DEF | removed | STATIC-DEF | outer IP | 286 | Payload | INFERRED | removed | INFERRED | outer IP | 287 | Length | | | | | 288 | Next Header | STATIC | removed | STATIC | TS | 289 | Hop Limit | RACH | removed | INFERRED | outer IP | 290 | Source | STATIC-DEF | removed | STATIC-DEF | TS | 291 | Address | | | | | 292 | Destination | STATIC-DEF | removed | STATIC-DEF | TS | 293 | Address | | | | | 294 +--------------+------------+--------------+-------------+----------+ 296 Table 3: Header classification for IPv6. 298 Version: 299 The IP version is specified in the SA and can be copied to the 300 ROHC context, before the first packet is sent/received. 302 Traffic Class: 303 Traffic Class can be read from the outer IP header. Therefore the 304 classification is changed to INFERRED. 306 Flow Label: 307 Flow Label can be read from the outer IP header. Therefore the 308 classification is changed to INFERRED. 310 Next Header 311 The Next Header is stored in the protocol of the Traffic Selector 312 and is fixed. It can be copied to the ROHC context, before the 313 first packet is sent/received. 315 Hop Limit 316 The Hop Limit can be read from the outer IP header. Therefore the 317 classification is changed to INFERRED. 319 Source Address: 320 The Source Address is fixed in the SA and can be copied to the 321 ROHC context, before the first packet is sent/received. 323 Destination Address: 324 The Destination Address is fixed in the SA and can be copied to 325 the ROHC context, before the first packet is sent/received. 327 7. UDP Transport Layer Compression 329 This section shows the compression of ESP payload for all ROHC 330 profiles including an UDP header. 332 The UDP header is classified as shown in Table 4 334 +-------------+------------+-----------+---------------+------------+ 335 | Field | Class | Compr. | Diet-ESP ROHC | Data | 336 | | | Method | class | origin | 337 +-------------+------------+-----------+---------------+------------+ 338 | Source Port | STATIC-DEF | removed | STATIC-DEF | TS | 339 | Destination | STATIC-DEF | removed | STATIC-DEF | TS | 340 | Port | | | | | 341 | Length | INFERRED | removed | INFERRED | IP payload | 342 | | | | | length | 343 | Checksum | IRREGULAR | LSB | INFERRED | calc. | 344 +-------------+------------+-----------+---------------+------------+ 346 Table 4: Header classification for UDP. 348 Source Port: 349 The Source Port is fixed in the SA and can be copied to the ROHC 350 context, before the first packet is sent/received. 352 Destination Port: 353 The Destination Port is fixed in the SA and can be copied to the 354 ROHC context, before the first packet is sent/received. 356 Length: 357 The length of the UDP header can be calculated like: IP header - 358 IP header length. Therefore there is no need to send it on the 359 wire and it is defined as INFERRED. 361 Checksum: 362 The checksum can be calculated by Diet-ESP and proved by comparing 363 the LSB sent on the wire. The number of bytes sent on the wire 364 can be 0, 1 and 2 stored in CHECKSUM_LSB. If 0 LSB is chosen, the 365 checksum MUST be decompressed with the value 0. If the UDP 366 implementation of the sender chose to disable the UDP checksum by 367 setting the checksum to 0 Diet-ESP SHOULD be used with 368 CHECKSUM_LSB = 0. 370 8. UDP-Lite Transport Layer Compression 372 This section shows the compression of ESP payload for all ROHC 373 profiles including an UDP-Lite header. 375 The UDP header is classified as shown in Table 5 377 +--------------+------------+--------------+-------------+----------+ 378 | Field | Class | Compression | Diet-ESP | Data | 379 | | | Method | ROHC class | origin | 380 +--------------+------------+--------------+-------------+----------+ 381 | Source Port | STATIC-DEF | removed | STATIC-DEF | TS | 382 | Destination | STATIC-DEF | removed | STATIC-DEF | TS | 383 | Port | | | | | 384 | Checksum | IRREGULAR | LSB | IRREGULAR | calc. | 385 | Coverage | | | | | 386 | Checksum | IRREGULAR | LSB | INFERRED | calc. | 387 +--------------+------------+--------------+-------------+----------+ 389 Table 5: Header classification for UDP-Lite. 391 Source Port: 392 The Source Port is fixed in the SA and can be copied to the ROHC 393 context, before the first packet is sent/received. 395 Destination Port: 396 The Destination Port is fixed in the SA and can be copied to the 397 ROHC context, before the first packet is sent/received. 399 Checksum Coverage: 400 The Checksum specifies the number of octets carried by the UDP- 401 Lite checksum. It can have the same value as the UDP length (0 or 402 UDP length) or any value between 8 and UDP length. This field is 403 compressed with CHECKSUM_LSB of 0, 1 or 2 bytes. If 0 or 1 LSB is 404 chosen, the field MUST be decompressed with the UDP length. If 2 405 LSB is chosen, the checksum has to carry this behaviour. 407 Checksum: 408 The checksum can be calculated by Diet-ESP and proved by comparing 409 the LSB sent on the wire. The number of bytes sent on the wire 410 can be 0, 1 and 2 stored in CHECKSUM_LSB. If 0 LSB is chosen, the 411 checksum MUST be decompressed with the value 0. If an UDP-lite 412 implementation of the sender chose to disable the UDP checksum by 413 setting the checksum to 0 Diet-ESP SHOULD be used with 414 CHECKSUM_LSB = 0. 416 9. TCP Transport Layer Compression 418 This section shows the compression of ESP payload for all ROHC 419 profiles including a TCP header. The ROHC context is partly filled 420 while the Diet-ESP context exchange, wherefore some values can be 421 removed. Since TCP is not stateless only fields with the compression 422 methods 'removed' and 'LSB' are allowed to be compressed, the other 423 fields MUST be sent on the wire uncompressed. 425 The UDP header is classified as shown in Table 6 427 +-----------------+------------+-------------+------------+---------+ 428 | Field | Class | Compression | Diet-ESP | Data | 429 | | | Method | ROHC class | origin | 430 +-----------------+------------+-------------+------------+---------+ 431 | Source Port | STATIC-DEF | removed | STATIC-DEF | TS | 432 | Destination | STATIC-DEF | removed | STATIC-DEF | TS | 433 | Port | | | | | 434 | Sequence Number | CHANGING | LSB | CHANGING | ESP SN | 435 | Acknowledgement | INFERRED | N/A | INFERRED | | 436 | Num | | | | | 437 | Data Offset | CHANGING | N/A | CHANGING | | 438 | Reserved | CHANGING | N/A | CHANGING | | 439 | CWR flag | CHANGING | N/A | CHANGING | | 440 | ECE flag | CHANGING | N/A | CHANGING | | 441 | URG flag | CHANGING | N/A | CHANGING | | 442 | ACK flag | CHANGING | N/A | CHANGING | | 443 | PSH flag | CHANGING | N/A | CHANGING | | 444 | RST flag | CHANGING | N/A | CHANGING | | 445 | SYN flag | CHANGING | N/A | CHANGING | | 446 | FIN flag | CHANGING | N/A | CHANGING | | 447 | Window | CHANGING | N/A | CHANGING | | 448 | Checksum | IRREGULAR | LSB | INFERRED | calc. | 449 | Urgent Pointer | CHANGING | N/A | CHANGING | | 450 | Options | CHANGING | N/A | CHANGING | | 451 +-----------------+------------+-------------+------------+---------+ 453 Table 6: Header classification for TCP. 455 Source Port: 456 The Source Port is fixed in the SA and can be copied to the ROHC 457 context, before the first packet is sent/received. 459 Destination Port: 460 The Destination Port is fixed in the SA and can be copied to the 461 ROHC context, before the first packet is sent/received. 463 Sequence Number: 465 The Sequence Number can be compressed with a LSB by using the SN 466 stored in the SA for the remaining MSB not sent on the wire. 468 Checksum: 469 The checksum can be calculated by Diet-ESP and proved by comparing 470 the LSB sent on the wire. The number of bytes sent on the wire 471 can be 0, 1 and 2 stored in CHECKSUM_LSB. If 0 LSB is chosen, the 472 checksum MUST be decompressed with the value 0. If an UDP-lite 473 implementation of the sender chose to disable the UDP checksum by 474 setting the checksum to 0 Diet-ESP SHOULD be used with 475 CHECKSUM_LSB = 0. 477 10. IANA Considerations 479 There are no IANA consideration for this document. 481 11. Security Considerations 483 12. Acknowledgment 485 The current draft represents the work of Tobias Guggemos while his 486 internship at Orange [GUGG14] . 488 Diet-ESP is a joint work between Orange and Ludwig-Maximilians- 489 Universitaet Munich. We thank Daniel Palomares and Carsten Bormann 490 for their useful remarks, comments and guidance. 492 13. References 494 13.1. Normative References 496 [I-D.mglt-ipsecme-diet-esp] 497 Migault, D., Guggemos, T., and D. Palomares, "Diet-ESP: a 498 flexible and compressed format for IPsec/ESP", draft-mglt- 499 ipsecme-diet-esp-00 (work in progress), March 2014. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", BCP 14, RFC 2119, March 1997. 504 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 505 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 506 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 507 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 508 Compression (ROHC): Framework and four profiles: RTP, UDP, 509 ESP, and uncompressed", RFC 3095, July 2001. 511 [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 512 (ROHC): A Compression Profile for IP", RFC 3843, June 513 2004. 515 [RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles 516 for User Datagram Protocol (UDP) Lite", RFC 4019, April 517 2005. 519 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 520 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 521 UDP-Lite", RFC 5225, April 2008. 523 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 524 Header Compression (ROHC) Framework", RFC 5795, March 525 2010. 527 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 528 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 529 5996, September 2010. 531 [RFC6846] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 532 "RObust Header Compression (ROHC): A Profile for TCP/IP 533 (ROHC-TCP)", RFC 6846, January 2013. 535 13.2. Informational References 537 [GUGG14] Guggemos, TG., "Diet-ESP: Applying IP-Layer Security in 538 Constrained Environments (Masterthesis)", September 2014. 540 [RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, 541 "Integration of Robust Header Compression over IPsec 542 Security Associations", RFC 5856, May 2010. 544 Appendix A. Interaction with ROHC profiles 546 Each ROHC profile defines compression rules for a set of protocol 547 headers. Table 7 clarifies how ROHC profiles can be mapped to Diet- 548 ESP payload compression. 550 +-----------+---------+-----------------+-----------+---------------+ 551 | Profile | ROHC | Protocol | RFC | Diet-ESP | 552 | Number | version | | | compression | 553 +-----------+---------+-----------------+-----------+---------------+ 554 | 0x0000 | ROHC | uncompressed IP | [RFC3095] | no | 555 | | | | | compression | 556 | 0x0001 | ROHC | RTP/UDP/IP | [RFC3095] | not used | 557 | 0x1001 | ROHCv2 | RTP/UDP/IP | [RFC5225] | not used | 558 | 0x0002 | ROHC | UDP/IP | [RFC3095] | UDP and IP in | 559 | | | | | Tunnel Mode | 560 | 0x1002 | ROHCv2 | UDP/IP | [RFC5225] | UDP and IP in | 561 | | | | | Tunnel Mode | 562 | 0x0003 | ROHC | ESP/IP | [RFC3095] | not used | 563 | 0x1003 | ROHCv2 | ESP/IP | [RFC5225] | not used | 564 | 0x0004 | ROHC | IP | [RFC3843] | IP in Tunnel | 565 | | | | | Mode | 566 | 0x1004 | ROHCv2 | IP | [RFC5225] | IP in Tunnel | 567 | | | | | Mode | 568 | 0x0006 | ROHC | TCP/IP | [RFC6846] | TCP and IP in | 569 | | | | | Tunnel Mode | 570 | 0x0007 | ROHC | RTP/UDP-Lite/IP | [RFC4019] | not used | 571 | 0x1007 | ROHCv2 | RTP/UDP-Lite/IP | [RFC5225] | not used | 572 | 0x0008 | ROHC | UDP-Lite/IP | [RFC4019] | UDP-Lite and | 573 | | | | | IP in Tunnel | 574 | | | | | Mode | 575 | 0x1008 | ROHCv2 | UDP-Lite/IP | [RFC5225] | UDP-Lite and | 576 | | | | | IP in Tunnel | 577 | | | | | Mode | 578 +-----------+---------+-----------------+-----------+---------------+ 580 Table 7: Overview over currently existing ROHC profiles. 582 Appendix B. Document Change Log 584 00-First version published 586 Authors' Addresses 588 Daniel Migault (editor) 589 Orange 590 38 rue du General Leclerc 591 92794 Issy-les-Moulineaux Cedex 9 592 France 594 Phone: +33 1 45 29 60 52 595 Email: daniel.migault@orange.com 596 Tobias Guggemos (editor) 597 Orange / LMU Munich 598 Am Osteroesch 9 599 87637 Seeg, Bavaria 600 Germany 602 Email: tobias.guggemos@gmail.com