idnits 2.17.1 draft-mglt-6lo-diet-esp-payload-compression-01.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 date (February 17, 2015) is 3348 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 (-02) exists of draft-mglt-6lo-diet-esp-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo D. Migault, Ed. 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Guggemos, Ed. 5 Expires: August 21, 2015 LMU Munich 6 February 17, 2015 8 Diet-IPsec: ESP Payload Compression of IPv6 / UDP / TCP / UDP-Lite 9 draft-mglt-6lo-diet-esp-payload-compression-01.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 August 21, 2015. 51 Copyright Notice 53 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 12 78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 12 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 13.2. Informational References . . . . . . . . . . . . . . . . 13 83 Appendix A. Interaction with ROHC profiles . . . . . . . . . . . 13 84 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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-6lo-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 [RFC7296]. 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-6lo-diet-esp] clarifies the interactions of Diet-ESP with 124 ROHC and 6LoWPAN. The Diet-ESP extension explained in this document 125 replaces ROHCoverIPsec and 6LoWPANoverIPsec, protocols which offers 126 similar functionality without using the IPsec databases. The Diet- 127 ESP Payload Compression Extension uses the IPsec databases to avoid 128 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 TRANSPORT_CHECKSUM_LSB and TRANSPORT_SEQUENCE_NUMBER_LSB. 135 COMPRESS_ESP_PAYLOAD indicates the peers expect the Clear Text 136 Data to be compressed, TRANSPORT_CHECKSUM_LSB and 137 TRANSPORT_SEQUENCE_NUMBER_LSB are additional parameters to perform 138 the compression. 140 - 2. Definition of a Diet-ESP Payload Compression algorithm. 142 The remaining of the document is as follows. Section 4 describes the 143 new parameters for the Diet-ESP Context. Section 5 describes the 144 protocol. Section 6, Section 7, Section 7 and Section 9 describe the 145 compression of the IP layer and the transport layer (UDP, UDP-Lite. 147 3. Terminology 149 Diet-ESP Context: Like defined in Diet-ESP document. 151 SPD: Security Policy Database 153 SAD: Security Association Database 155 TS: Traffic Selector of a Security Association. 157 LSB: Least Significant Byte 159 MSB: Most Significant Byte 161 4. Diet-ESP Context Extension 163 This section describes the additional parameters of the Diet-ESP 164 Context to implement the ESP Payload Compression extension. 166 +-------------------------------+-----------------------------------+ 167 | Context Field Name | Overview | 168 +-------------------------------+-----------------------------------+ 169 | COMPRESS_ESP_PAYLOAD | Defines the use of the Traffic | 170 | | Selector for (de-)compression. | 171 | TRANSPORT_CHECKSUM_LSB | LSB of the UDP, UDP-Lite or TCP | 172 | | checksum | 173 | TRANSPORT_SEQUENCE_NUMBER_LSB | LSB of the TCP Sequence Number. | 174 +-------------------------------+-----------------------------------+ 176 Table 1: Diet-ESP Context. 178 COMPRESS_ESP_PAYLOAD: 179 Defines if the ESP Payload MUST be compressed or not. Note that 180 as detailed later, compression of the ESP Payload requires that IP 181 addresses, or protocols are unique in the Security Association 182 Databases. If not the compression does not compress does not 183 output a compressed ESP Payload. 185 TRANSPORT_CHECKSUM_LSB: 186 If an inner header provides a checksum this can be compressed by 187 the LSB mechanism. How the checksum is compressed is specified by 188 the related profiles, e.g. UDP Section 7 , UDP-Lite Section 8 and 189 TCP Section 9. 191 TRANSPORT_SEQUENCE_NUMBER_LSB: 192 If an inner header provides a Sequence Number, one MAY choose to 193 use the SN stored in the SA for compression. Therefore the 194 context provides the LSB of the Sequence Number which is used by 195 all profiles, defining the Sequence Number as compressed with LSB, 196 e.g. TCP Section 9. 198 5. Protocol Overview 200 The Diet-ESP Payload Compression is described by the pseudo code in 201 Figure 1. The Clear Text Data is compressed only if 202 COMPRESS_ESP_PAYLOAD is set. Otherwise, it is left unchanged. When 203 COMPRESS_ESP_PAYLOAD is set, compression is performed on the IP and 204 transport layer if and only if two conditions are met. First the 205 layer must exist. This means for example that the IP layer is 206 compressed only for the tunnel mode. Then, the layer can be 207 compressed if and only if the values are uniquely derived from the 208 IPsec databases. More specifically, if a SPD match occurs with at 209 least two different values, then the compression do not occurs. 211 As a result, the IP layer can be compressed only if the IP address 212 appears as a Traffic Selector. If the Traffic Selector is defined as 213 a subnetwork, a SPD match occurs with more then one IP address, and 214 then no compression occurs. Similarly, the transport layer is 215 compressed if and only if it appears as a Traffic Selector. If a SPD 216 match occurs with different transport protocol then the compression 217 of the transport layer does not occurs. 219 The Diet-ESP Payload Compression is straight forward, but may at some 220 point not fits all the needs. At some point using alternative 221 compression as those proposed by ROHCoverIPsec may be preferred. In 222 these cases, Diet-ESP Payload Compression MUST NOT be performed and 223 COMPRESS_ESP_PAYLOAD MUST be unset. 225 226 if COMPRESS_ESP_PAYLOAD is set : 227 proceed to Diet-ESP Payload Compression 228 else: 229 clear_text_data is left unchanged. 231 def diet_esp_payload_compression(clear_text_data, \ 232 TRANSPORT_CHECKSUM_LSB,\ 233 TRANSPORT_SEQUENCE_NUMBER_LSB): 234 ## Compress IP header if the ipsec mode is tunnel and 235 ## the inner IP addresses can uniquely be derived from IPsec DB. 236 ## In other words, subnets are not considered. 237 if clear_text_data has IP layer and \ 238 IP addresses is a unique Traffic Selector and \ 239 ipsec mode is tunnel: 240 compress the IP layer 241 if clear_text_data has transport layer and \ 242 transport layer is a Traffic Selector: 243 compress transport layer 244 246 Figure 1: Diet-ESP Payload Compression Pseudo Code 248 Roughly speaking Diet-ESP is able to remove all header fields which 249 have unique values inside the Security Association Database. Most 250 probably they are stored in the Traffic Selector, which defines the 251 traffic which has to be secured with IPsec. Table 2 shows some 252 header fields which can be adopted from the Traffic Selector. The 253 table provides the ROHC class of these values, as we use the ROHC 254 terminology to describe the compression algorithms. 256 +---------------------+----------+--------------+ 257 | Field | Protocol | ROHC class | 258 +---------------------+----------+--------------+ 259 | IP version | IP/IPv6 | STATIC-KNOWN | 260 | Source Address | IP/IPv6 | STATIC-DEF | 261 | Destination Address | IP/IPv6 | STATIC-DEF | 262 | Next Header | IP/IPv6 | STATIC | 263 | Source PORT | UPD/TCP | STATIC-DEF | 264 | Destination PORT | UPD/TCP | STATIC-DEF | 265 +---------------------+----------+--------------+ 267 Table 2: This values are carried in the Security Association. 269 6. IP Layer Compression 271 This section describes how the compression of the IP layer is 272 performed. The compression of this layer mostly occurs when the 273 peers have negotiated the IPsec tunnel mode. 275 The basic idea for IP layer compression is to remove the IP layer 276 before Diet-ESP encrypts the Clear Text Data. Similarly, for 277 incoming packet, Diet-ESP decrypts the ESP packet, and restores the 278 IP layer by reading the IP address in the IPsec SAD. However, the IP 279 address is not sufficient to restore the complete IP header as other 280 fields must be considered. To appropriately describes the 281 compression of the IP layer, this section uses the ROHC terminology 282 and describes the associated profile. 284 The IP header is classified as shown in Table 3 286 +--------------+------------+--------------+-------------+----------+ 287 | Field | Class | Compression | Diet-ESP | Data | 288 | | | Method | ROHC class | origin | 289 +--------------+------------+--------------+-------------+----------+ 290 | Version | STATIC | removed | STATIC | TS | 291 | Traffic | CHANGING | removed | INFERRED | outer IP | 292 | Class | | | | | 293 | Flow Label | STATIC-DEF | removed | STATIC-DEF | outer IP | 294 | Payload | INFERRED | removed | INFERRED | outer IP | 295 | Length | | | | | 296 | Next Header | STATIC | removed | STATIC | TS | 297 | Hop Limit | RACH | removed | INFERRED | outer IP | 298 | Source | STATIC-DEF | removed | STATIC-DEF | TS | 299 | Address | | | | | 300 | Destination | STATIC-DEF | removed | STATIC-DEF | TS | 301 | Address | | | | | 302 +--------------+------------+--------------+-------------+----------+ 304 Table 3: Header classification for IPv6. 306 Version: 307 The IP version is specified in the SA and can be copied to the 308 ROHC context, before the first packet is sent/received. 310 Traffic Class: 311 Traffic Class can be read from the outer IP header. Therefore the 312 classification is changed to INFERRED. 314 Flow Label: 315 Flow Label can be read from the outer IP header. Therefore the 316 classification is changed to INFERRED. 318 Next Header 319 The Next Header is stored in the protocol of the Traffic Selector 320 and is fixed. It can be copied to the ROHC context, before the 321 first packet is sent/received. 323 Hop Limit 324 The Hop Limit can be read from the outer IP header. Therefore the 325 classification is changed to INFERRED. 327 Source Address: 328 The Source Address is fixed in the SA and can be copied to the 329 ROHC context, before the first packet is sent/received. 331 Destination Address: 332 The Destination Address is fixed in the SA and can be copied to 333 the ROHC context, before the first packet is sent/received. 335 7. UDP Transport Layer Compression 337 This section shows the compression of ESP payload for all ROHC 338 profiles including an UDP header. 340 The UDP header is classified as shown in Table 4 342 +-------------+------------+-----------+---------------+------------+ 343 | Field | Class | Compr. | Diet-ESP ROHC | Data | 344 | | | Method | class | origin | 345 +-------------+------------+-----------+---------------+------------+ 346 | Source Port | STATIC-DEF | removed | STATIC-DEF | TS | 347 | Destination | STATIC-DEF | removed | STATIC-DEF | TS | 348 | Port | | | | | 349 | Length | INFERRED | removed | INFERRED | IP payload | 350 | | | | | length | 351 | Checksum | IRREGULAR | LSB | INFERRED | calc. | 352 +-------------+------------+-----------+---------------+------------+ 354 Table 4: Header classification for UDP. 356 Source Port: 357 The Source Port is fixed in the SA and can be copied to the ROHC 358 context, before the first packet is sent/received. 360 Destination Port: 361 The Destination Port is fixed in the SA and can be copied to the 362 ROHC context, before the first packet is sent/received. 364 Length: 366 The length of the UDP header can be calculated like: IP header - 367 IP header length. Therefore there is no need to send it on the 368 wire and it is defined as INFERRED. 370 Checksum: 371 The checksum can be calculated by Diet-ESP and proved by comparing 372 the LSB sent on the wire. The number of bytes sent on the wire 373 can be 0, 1 and 2 stored in TRANSPORT_CHECKSUM_LSB. If 0 LSB is 374 chosen, the checksum MUST be decompressed with the value 0. If 375 the UDP implementation of the sender chose to disable the UDP 376 checksum by setting the checksum to 0 Diet-ESP SHOULD be used with 377 TRANSPORT_CHECKSUM_LSB = 0. 379 8. UDP-Lite Transport Layer Compression 381 This section shows the compression of ESP payload for all ROHC 382 profiles including an UDP-Lite header. 384 The UDP header is classified as shown in Table 5 386 +--------------+------------+--------------+-------------+----------+ 387 | Field | Class | Compression | Diet-ESP | Data | 388 | | | Method | ROHC class | origin | 389 +--------------+------------+--------------+-------------+----------+ 390 | Source Port | STATIC-DEF | removed | STATIC-DEF | TS | 391 | Destination | STATIC-DEF | removed | STATIC-DEF | TS | 392 | Port | | | | | 393 | Checksum | IRREGULAR | LSB | IRREGULAR | calc. | 394 | Coverage | | | | | 395 | Checksum | IRREGULAR | LSB | INFERRED | calc. | 396 +--------------+------------+--------------+-------------+----------+ 398 Table 5: Header classification for UDP-Lite. 400 Source Port: 401 The Source Port is fixed in the SA and can be copied to the ROHC 402 context, before the first packet is sent/received. 404 Destination Port: 405 The Destination Port is fixed in the SA and can be copied to the 406 ROHC context, before the first packet is sent/received. 408 Checksum Coverage: 409 The Checksum specifies the number of octets carried by the UDP- 410 Lite checksum. It can have the same value as the UDP length (0 or 411 UDP length) or any value between 8 and UDP length. This field is 412 compressed with TRANSPORT_CHECKSUM_LSB of 0, 1 or 2 bytes. If 0 413 or 1 LSB is chosen, the field MUST be decompressed with the UDP 414 length. If 2 LSB is chosen, the checksum has to carry this 415 behaviour. 417 Checksum: 418 The checksum can be calculated by Diet-ESP and proved by comparing 419 the LSB sent on the wire. The number of bytes sent on the wire 420 can be 0, 1 and 2 stored in TRANSPORT_CHECKSUM_LSB. If 0 LSB is 421 chosen, the checksum MUST be decompressed with the value 0. If an 422 UDP-lite implementation of the sender chose to disable the UDP 423 checksum by setting the checksum to 0 Diet-ESP SHOULD be used with 424 TRANSPORT_CHECKSUM_LSB = 0. 426 9. TCP Transport Layer Compression 428 This section shows the compression of ESP payload for all ROHC 429 profiles including a TCP header. The ROHC context is partly filled 430 while the Diet-ESP context exchange, wherefore some values can be 431 removed. Since TCP is not stateless only fields with the compression 432 methods 'removed' and 'LSB' are allowed to be compressed, the other 433 fields MUST be sent on the wire uncompressed. 435 The UDP header is classified as shown in Table 6 436 +-----------------+------------+-------------+------------+---------+ 437 | Field | Class | Compression | Diet-ESP | Data | 438 | | | Method | ROHC class | origin | 439 +-----------------+------------+-------------+------------+---------+ 440 | Source Port | STATIC-DEF | removed | STATIC-DEF | TS | 441 | Destination | STATIC-DEF | removed | STATIC-DEF | TS | 442 | Port | | | | | 443 | Sequence Number | CHANGING | LSB | CHANGING | ESP SN | 444 | Acknowledgement | INFERRED | N/A | INFERRED | | 445 | Num | | | | | 446 | Data Offset | CHANGING | N/A | CHANGING | | 447 | Reserved | CHANGING | N/A | CHANGING | | 448 | CWR flag | CHANGING | N/A | CHANGING | | 449 | ECE flag | CHANGING | N/A | CHANGING | | 450 | URG flag | CHANGING | N/A | CHANGING | | 451 | ACK flag | CHANGING | N/A | CHANGING | | 452 | PSH flag | CHANGING | N/A | CHANGING | | 453 | RST flag | CHANGING | N/A | CHANGING | | 454 | SYN flag | CHANGING | N/A | CHANGING | | 455 | FIN flag | CHANGING | N/A | CHANGING | | 456 | Window | CHANGING | N/A | CHANGING | | 457 | Checksum | IRREGULAR | LSB | INFERRED | calc. | 458 | Urgent Pointer | CHANGING | N/A | CHANGING | | 459 | Options | CHANGING | N/A | CHANGING | | 460 +-----------------+------------+-------------+------------+---------+ 462 Table 6: Header classification for TCP. 464 Source Port: 465 The Source Port is fixed in the SA and can be copied to the ROHC 466 context, before the first packet is sent/received. 468 Destination Port: 469 The Destination Port is fixed in the SA and can be copied to the 470 ROHC context, before the first packet is sent/received. 472 Sequence Number: 473 The Sequence Number can be compressed with a LSB by using the SN 474 stored in the SA for the remaining MSB not sent on the wire. 476 Checksum: 477 The checksum can be calculated by Diet-ESP and proved by comparing 478 the LSB sent on the wire. The number of bytes sent on the wire 479 can be 0, 1 and 2 stored in TRANSPORT_CHECKSUM_LSB. If 0 LSB is 480 chosen, the checksum MUST be decompressed with the value 0. If an 481 UDP-lite implementation of the sender chose to disable the UDP 482 checksum by setting the checksum to 0 Diet-ESP SHOULD be used with 483 TRANSPORT_CHECKSUM_LSB = 0. 485 10. IANA Considerations 487 There are no IANA consideration for this document. 489 11. Security Considerations 491 12. Acknowledgment 493 The current work on Diet-ESP results from exchange and cooperation 494 between Orange, Ludwig-Maximilians-Universitaet Munich, Universite 495 Pierre et Marie Curie. We thank Daniel Palomares and Carsten Bormann 496 for their useful remarks, comments and guidances on the design. We 497 thank Sylvain Killian for implementing an open source Diet-ESP on 498 Contiki and testing it on the FIT IoT-LAB [fit-iot-lab] funded by the 499 French Ministry of Higher Education and Research. We thank the IoT- 500 Lab Team and the INRIA for maintaining the FIT IoT-LAB platform and 501 for providing feed backs in an efficient way. 503 13. References 505 13.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 511 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 512 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 513 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 514 Compression (ROHC): Framework and four profiles: RTP, UDP, 515 ESP, and uncompressed", RFC 3095, July 2001. 517 [RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression 518 (ROHC): A Compression Profile for IP", RFC 3843, June 519 2004. 521 [RFC4019] Pelletier, G., "RObust Header Compression (ROHC): Profiles 522 for User Datagram Protocol (UDP) Lite", RFC 4019, April 523 2005. 525 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 526 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 527 UDP-Lite", RFC 5225, April 2008. 529 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 530 Header Compression (ROHC) Framework", RFC 5795, March 531 2010. 533 [RFC6846] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 534 "RObust Header Compression (ROHC): A Profile for TCP/IP 535 (ROHC-TCP)", RFC 6846, January 2013. 537 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 538 Kivinen, "Internet Key Exchange Protocol Version 2 539 (IKEv2)", STD 79, RFC 7296, October 2014. 541 13.2. Informational References 543 [I-D.mglt-6lo-diet-esp] 544 Migault, D. and T. Guggemos, "Diet-ESP: a flexible and 545 compressed format for IPsec/ESP", draft-mglt-6lo-diet- 546 esp-00 (work in progress), January 2015. 548 [RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, 549 "Integration of Robust Header Compression over IPsec 550 Security Associations", RFC 5856, May 2010. 552 [fit-iot-lab] 553 "Future Internet of Things (FIT) IoT-LAB", 554 . 556 Appendix A. Interaction with ROHC profiles 558 Each ROHC profile defines compression rules for a set of protocol 559 headers. Table 7 clarifies how ROHC profiles can be mapped to Diet- 560 ESP payload compression. 562 +-----------+---------+-----------------+-----------+---------------+ 563 | Profile | ROHC | Protocol | RFC | Diet-ESP | 564 | Number | version | | | compression | 565 +-----------+---------+-----------------+-----------+---------------+ 566 | 0x0000 | ROHC | uncompressed IP | [RFC3095] | no | 567 | | | | | compression | 568 | 0x0001 | ROHC | RTP/UDP/IP | [RFC3095] | not used | 569 | 0x1001 | ROHCv2 | RTP/UDP/IP | [RFC5225] | not used | 570 | 0x0002 | ROHC | UDP/IP | [RFC3095] | UDP and IP in | 571 | | | | | Tunnel Mode | 572 | 0x1002 | ROHCv2 | UDP/IP | [RFC5225] | UDP and IP in | 573 | | | | | Tunnel Mode | 574 | 0x0003 | ROHC | ESP/IP | [RFC3095] | not used | 575 | 0x1003 | ROHCv2 | ESP/IP | [RFC5225] | not used | 576 | 0x0004 | ROHC | IP | [RFC3843] | IP in Tunnel | 577 | | | | | Mode | 578 | 0x1004 | ROHCv2 | IP | [RFC5225] | IP in Tunnel | 579 | | | | | Mode | 580 | 0x0006 | ROHC | TCP/IP | [RFC6846] | TCP and IP in | 581 | | | | | Tunnel Mode | 582 | 0x0007 | ROHC | RTP/UDP-Lite/IP | [RFC4019] | not used | 583 | 0x1007 | ROHCv2 | RTP/UDP-Lite/IP | [RFC5225] | not used | 584 | 0x0008 | ROHC | UDP-Lite/IP | [RFC4019] | UDP-Lite and | 585 | | | | | IP in Tunnel | 586 | | | | | Mode | 587 | 0x1008 | ROHCv2 | UDP-Lite/IP | [RFC5225] | UDP-Lite and | 588 | | | | | IP in Tunnel | 589 | | | | | Mode | 590 +-----------+---------+-----------------+-----------+---------------+ 592 Table 7: Overview over currently existing ROHC profiles. 594 Appendix B. Document Change Log 596 00-First version published 598 Authors' Addresses 600 Daniel Migault (editor) 601 Ericsson 602 8400 boulevard Decarie 603 Montreal, QC H4P 2N2 604 Canada 606 Email: mglt.ietf@gmail.com 607 Tobias Guggemos (editor) 608 LMU Munich 609 Am Osteroesch 9 610 87637 Seeg, Bavaria 611 Germany 613 Email: tobias.guggemos@gmail.com