idnits 2.17.1 draft-mglt-ipsecme-diet-esp-04.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 (June 29, 2017) is 2493 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ipsecme D. Migault, Ed. 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Guggemos, Ed. 5 Expires: December 31, 2017 LMU Munich 6 C. Bormann 7 Universitaet Bremen TZI 8 June 29, 2017 10 ESP Header Compression and Diet-ESP 11 draft-mglt-ipsecme-diet-esp-04.txt 13 Abstract 15 ESP Header Compression (EHC) defines a flexible framework to compress 16 communications protected with IPsec/ESP. Compression and 17 decompression is defined by EHC Rules orchestrated by EHC Strategies. 19 The document specifies the Diet-ESP EHC Strategy and associated EHC 20 Rules. Diet-ESP compresses up to 32 bytes per packet for traditional 21 IPv6 VPN and up to 66 bytes for IPv6 VPN set over a single TCP or UDP 22 session. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 31, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Diet-ESP EHC Context . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Diet-ESP Context Parameters for ESP . . . . . . . . . . . 6 64 5.2. Diet-ESP Context Parameters for Inner IP . . . . . . . . 6 65 5.3. Diet-ESP Context Parameters for Transport Protocol . . . 8 66 6. Diet-ESP EHC Rules . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. EHC Rules for ESP . . . . . . . . . . . . . . . . . . . . 10 68 6.2. EHC Rules for inner IPv4 . . . . . . . . . . . . . . . . 12 69 6.3. EHC Rules for inner IPv6 . . . . . . . . . . . . . . . . 14 70 6.4. EHC Rules for UDP . . . . . . . . . . . . . . . . . . . . 16 71 6.5. EHC Rules for UDP-Lite . . . . . . . . . . . . . . . . . 17 72 6.6. EHC Rules for TCP . . . . . . . . . . . . . . . . . . . . 18 73 7. Diet-ESP EHC Strategy . . . . . . . . . . . . . . . . . . . . 19 74 7.1. Outbound Packet Processing . . . . . . . . . . . . . . . 19 75 7.2. Inbound Packet Processing . . . . . . . . . . . . . . . . 21 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 78 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 79 11. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 25 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 82 12.2. Informational References . . . . . . . . . . . . . . . . 26 83 Appendix A. Illustrative Examples . . . . . . . . . . . . . . . 27 84 A.1. Single UDP Session IoT VPN . . . . . . . . . . . . . . . 27 85 A.2. Single TCP session IoT VPN . . . . . . . . . . . . . . . 30 86 A.3. Traditional VPN . . . . . . . . . . . . . . . . . . . . . 33 87 Appendix B. EHC Classification (Informative) . . . . . . . . . . 40 88 B.1. ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 89 B.2. IPv6 (Inner) . . . . . . . . . . . . . . . . . . . . . . 42 90 B.3. IPv4 (Inner) . . . . . . . . . . . . . . . . . . . . . . 43 91 B.4. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 92 B.5. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 45 93 B.6. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 94 Appendix C. Document Change Log . . . . . . . . . . . . . . . . 47 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 97 1. Requirements notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 IPsec/ESP [RFC4303] secures communications either using end-to-end 106 security or by building a VPN where the traffic is carried to a 107 secure domain via the security gateway. 109 IPsec/ESP was not designed to reduce the networking overhead of the 110 communications. In fact, reducing bandwidth often adds computational 111 overhead that may negatively impact large infrastructures in which 112 bandwidth usage is not a constraint. On the other hand, IoT devices 113 have completely different constraints. In IoT communications, 114 sending any extra bytes can significantly impact the battery life of 115 devices. These devices are also often expected to be sleeping nodes, 116 for which IPsec sessions have a very different meaning. 118 This document defines ESP Header Compression (EHC), a framework that 119 compresses ESP protected communications. EHC is highly flexible to 120 address any use case where compression is necessary. EHC takes 121 advantage of the negotiation between the communication endpoint to 122 agree on the cryptographic parameters. In some cases, the agreement 123 already includes parameters that remain constant during the 124 communications (like port value, or IP address value). EHC takes 125 advantage of these already agreed parameters, and defines addition 126 parameters that could be agreed for the purpose of compression. 127 Similarly, EHC also defines EHC Rules which define how fields may be 128 compressed and decompressed given the provided parameters. Finally, 129 EHC defines EHC Strategy which defines how a set of EHC Rule is 130 coordinated. 132 The document specifies the Diet-ESP EHC Strategy and associated EHC 133 Rules. Diet-ESP compresses up to 32 bytes per packet for traditional 134 VPN and up to 66 bytes for VPN set over a single TCP or UDP session. 136 3. Terminology 138 This document uses the following terminology: 140 - IoT Internet of Things 141 - IP If not stated otherwise, IP means IPv6. 142 - LSB Least Significant Bytes 143 - MSB Most Significant Bytes 144 - SAD IPsec Security Association Database 145 - SA IPsec Security Association 146 - SPD IPsec Security Policy Database 147 - TS IPsec Traffic Selector 148 - SPI ESP Security Parameter Index 149 - SN ESP Sequence Number 150 - PAD ESP Padding 151 - PL ESP Pad Length 152 - NH Next Header 153 - IV Initialization Vector 154 - IIV Implicit Initialization Vector 155 - ICV Integrity Check Value 156 - VPN Virtual Private Network 158 4. Protocol Overview 160 ESP Header Compression (EHC) compresses IPsec ESP packets, thus 161 reducing the size of the packet sent on the wire, while carrying an 162 equivalent level of information with an equivalent level of security. 164 The primarily motivation for payload size reduction was IoT were the 165 cost of sending extra bytes largely overcomes additional computations 166 and thus considerably reduces the life time of battery powered 167 devices. As a result, IoT communication rather favor expensive 168 compression over additional bandwidth. Standard IPsec VPN may also 169 consider reduction of their bandwidth, but on the other hand, the 170 acceptable computation overhead must remain very low. The ESP Header 171 Compression designated in this document as Diet-ESP attempts to reach 172 theses two goals. 174 ESP Header Compression compresses the standard ESP payload by 175 compressing different fields with a specific compression rules 176 performed in the ESP stack. Concerned fields include fields of the 177 ESP protocol, as well as other protocols in the ESP payload such as 178 the IP header when the tunnel mode is used, the UDP or the TCP 179 header. In fact non ESP fields may be compressed by ESP under 180 certain circumstances, and ESP Header Compression is not intended to 181 provide a generic way, outside of ESP to compress these protocols. 182 Further compression of the ESP payload may be performed by generic 183 mechanism and outside ESP with more generic mechanisms such as for 184 example ROHCoverIPsec [RFC5858] or SCHC 185 [I-D.toutain-6lpwa-ipv6-static-context-hc] which are orthogonal to 186 ESP Header Compression. 188 As depicted in Figure 1, in order to compress the ESP packets, the 189 two peers are expected to agree on the EHC Strategy - Diet-ESP in our 190 case - as well as some extra parameters needed to derive the EHC 191 Rules and EHC Context. 193 EHC Strategy, EHC Strategy, 194 EHC Context <==================> EHC Context 195 | | 196 EHC Rules | EHC Rules | 197 | | | | 198 v v v v 199 +====================+ +====================+ 200 | ESP | | ESP | 201 +====================+ +====================+ 202 | < pre-esp > | | < pre-esp > | 203 +--------------------+ +--------------------+ 204 | < clear text esp > | | < clear text esp > | 205 +--------------------+ +--------------------+ 206 | < encryption > | | < encryption > | 207 +--------------------+ +--------------------+ 208 | < post-esp > | | < post-esp > | 209 +--------------------+ +--------------------+ 211 Figure 1: ESP Header Compression Overview 213 In Figure 1, the ESP stack is represented by various sub layers 214 describing the packet processing inside the ESP. The "pre-esp" layer 215 represents treatment performed to a non ESP packet, i.e. before ESP 216 encapsulation or decapsulation is being proceeded. "clear text esp" 217 designates the ESP encapsulation / decapsulation processing performed 218 on an non encrypted ESP packet. "encryption" designates the 219 encryption/decryption phase and "post-esp" the processing performed 220 on an ESP encrypted packet. EHC Rules may be processed at any of 221 these layers - except for "encryption" layer, and thus impact 222 differently the standard ESP. More specifically, EHC Rules performed 223 at the "pre-esp" or "post-esp" layer does not require the current ESP 224 stack to be updated and can simply be appended to the current ESP 225 stack. On the other hand, EHC Rules at the "clear text esp" may 226 require modification of the current ESP stack. 228 The set of EHC rules described in this document as well as the EHC 229 Strategies may be extended in the future. There is nothing to 230 prevent such EHC Rules and Strategies to be updated. 232 5. Diet-ESP EHC Context 234 The EHC Context provides the necessary information so the two peers 235 can proceed to the appropriated compression and decompression defined 236 by the EHC Strategy. As this document is limited to the Diet-ESP 237 strategy, the EHC Context in this section is also designated as Diet- 238 ESP Context and is used by the Diet-ESP Strategy to activate specific 239 EHC Rules as well as to execute the EHC Rule by providing the 240 necessary parameters.. 242 The Diet-ESP Context is defined on a per-SA basis. It is composed of 243 attributes that are not Diet-ESP specific, as well as attributes that 244 are Diet-ESP specific. Attributes that are not Diet-ESP specific are 245 already stored in some form in the SA. Such attributes are 246 designated by "Yes" in the "In SA" column. Diet-ESP specific 247 attributes may need to be specified so Diet-ESP can be executed 248 properly. 250 5.1. Diet-ESP Context Parameters for ESP 252 +-------------------+-------+--------------------------+ 253 | Context Attribute | In SA | Possible Values | 254 +-------------------+-------+--------------------------+ 255 | esp_mode | Yes | "Tunnel" or "Transport" | 256 | outer_version | Yes | "IPv4" "IPv6" | 257 | esp_spi | Yes | ESP SPI | 258 | esp_spi_lsb | No | 0, 1, 2, 3, 4 | 259 | esp_sn | Yes | ESP Sequence Number | 260 | esp_sn_lsb | No | 0, 1, 2, 3, 4 | 261 | esp_sn_gen | No | "Time", "Incremental" | 262 | esp_align | No | 8, 16, 24, 32 | 263 | esp_encr | Yes | ESP Encryption Algorithm | 264 +-------------------+-------+--------------------------+ 266 5.2. Diet-ESP Context Parameters for Inner IP 268 Parameters associated to the Inner IP addresses are only specified 269 when the SA has been configured with the tunnel mode. As a result 270 when esp_mode is set to "Transport" the parameters below MUST NOT be 271 considered and are considered as "Undefined" 273 +-------------------+-------+-----------------+ 274 | Context Attribute | In SA | Possible Values | 275 +-------------------+-------+-----------------+ 276 | ip_version | Yes | "IPv4" "IPv6" | 277 +-------------------+-------+-----------------+ 279 5.2.1. Diet-ESP Context Parameters for inner IPv6 280 +-------------------+-------+------------------------------+ 281 | Context Attribute | In SA | Possible Values | 282 +-------------------+-------+------------------------------+ 283 | ip6_tcfl_comp | No | "Outer", "Value", "UnComp" | 284 | ip6_tc | No | IPv6 Traffic Class | 285 | ip6_fl | No | IPv6 Flow Label | 286 | ip6_hl_comp | No | "Outer", "Value", "UnComp" | 287 | ip6_hl | No | Hop Limit Value | 288 | ip6_src | Yes | IPv6 Source Address | 289 | ip6_dst | Yes | IPv6 Destination Address | 290 +-------------------+-------+------------------------------+ 292 ip6_tcfl_comp indicates how Traffic Class and Flow Label fields of 293 the inner IP Header are expected to be compressed. When set to 294 "UnComp", or "Outer", values associated to ip6_tc and ip6_fl MUST NOT 295 be considered and are considered as "Undefined". Values associated 296 to ip6_tc and ip6_fl are only considered when ip6_tcfl_comp is set to 297 "Provide Values". 299 ip6_hl_comp indicates how Hop Limit field of the inner IP Header is 300 not expected to be compressed. When set to "Outer" or "UnComp", 301 values associated to ip6_hl MUST NOT be considered and is considered 302 as "Undefined". ip6_hl is only considered when ip6_hl_comp is set to 303 "Value". 305 ip6_dst designates the Destination IPv6 Address of the inner IP 306 header. The IP address is provided by the TS, and can be defined as 307 a range of IP addresses. Compression is only considered when ip6_dst 308 indicates a single IP Address. When the TS defines more than a 309 single IP address ip6_dst is considered as "Unspecified" and its 310 value MUST NOT be considered for compression. 312 5.2.2. Diet-ESP Context Parameters for inner IPv4 314 +---------------------+-------+------------------------------+ 315 | Context Attribute | In SA | Possible Values | 316 +---------------------+-------+------------------------------+ 317 | ip4_options | No | "Options", "No_Options" | 318 | ip4_id | No | IPv4 Identification | 319 | ip4_id_lsb | No | 0,1,2 | 320 | ip4_ttl_compression | No | "Outer", "Value", "UnComp" | 321 | ip4_ttl | No | IPv4 Time To Live | 322 | ip4_src | yes | IPv4 Source Address | 323 | ip4_dst | yes | IPv4 Destination Address | 324 | ip4_frag_enable | No | "True", "False" | 325 +---------------------+-------+------------------------------+ 327 5.3. Diet-ESP Context Parameters for Transport Protocol 329 The following parameters are provided by the SA but the SA may 330 specify single value or a range of values. When the SA specifies a 331 range of values, these parameters MUST NOT be considered and are 332 considered as Unspecified. 334 +-------------------+-------+------------------------------------+ 335 | Context Attribute | In SA | Possible Values | 336 +-------------------+-------+------------------------------------+ 337 | l4_proto | Yes | IPv6/ESP Next Header,IPv4 Protocol | 338 | l4_src | Yes | UDP/UDP-Lite/TCP Source Port | 339 | l4_dst | Yes | UDP/UDP-Lite/TCP Destination Port | 340 +-------------------+-------+------------------------------------+ 342 5.3.1. Diet-ESP Context Parameters for UDP-Lite 344 +-------------------+-------+-----------------------------+ 345 | Context Attribute | In SA | Possible Values | 346 +-------------------+-------+-----------------------------+ 347 | udplite_coverage | No | 8-16535, "Length", "UnComp" | 348 +-------------------+-------+-----------------------------+ 350 5.3.2. Diet-ESP Context Parameters for TCP 352 +-------------------+-------+---------------------------+ 353 | Context Attribute | In SA | Possible Values | 354 +-------------------+-------+---------------------------+ 355 | tcp_sn | No | TCP Sequence Number | 356 | tcp_ack | No | TCP Acknowledgment Number | 357 | tcp_lsb | No | 0, 1, 2, 3, 4 | 358 | tcp_options | No | "True" "False" | 359 | tcp_urgent | No | "True" "False" | 360 +-------------------+-------+---------------------------+ 362 6. Diet-ESP EHC Rules 364 This section describes the EHC Rules involved in Diet-ESP. The EHC 365 Rules defined by Diet-ESP may be used in the future by EHC Strategies 366 other than Diet-ESP, so they are described in an independent way. 368 EHC Rule defines the compression and decompression of one or more 369 fields and EHC Rules are represented this way: 371 +---------------+-------+---------+----------------+ 372 | EHC Rule | Field | Action | Parameters | 373 +---------------+-------+---------+----------------+ 374 | | f1 | a1 | p1_1, ... p1_n | 375 | +-------+---------+----------------+ 376 | EHC_RULE_NAME ~ ... ~ 377 | +-------+---------+----------------+ 378 | | fm | am | pm_1, ... pm_n | 379 +---------------+-------+---------+----------------+ 381 Figure 2: EHC Rules 383 The EHC Rule is designated by a name (EHC_RULE_NAME) which indicates 384 the concerned Fields (f1, ..., fm). Each field compression and 385 decompression is represented by an Action (a1, ..., am). Parameters 386 indicates the necessary parameters for the action to be completed, 387 i.e, to perform both the compression and the decompression. 389 The table below provides a high level description of the Actions used 390 by Diet-ESP. As these Action may take different arguments and may 391 operate differently for each field a compete description is provided 392 in the next sections as part of the EHC Rule description. 394 +-----------------+-----------------+----------------------+ 395 | Function | Compression | Decompression | 396 +-----------------+-----------------+----------------------+ 397 | send-value | No | No | 398 | elided | Not send | Get from EHC Context | 399 | lsb(_lsb_size) | Sent LSB | Get from EHC Context | 400 | lower | Not send | Get from lower layer | 401 | checksum | Not send | Compute checksum. | 402 | padding(_align) | Compute padding | Get padding | 403 +-----------------+-----------------+----------------------+ 405 a. send-value designates an action that does not perform any 406 compression or decompression of a field. 407 b. elided designates an action where both peers have a local value 408 of the field. The compression of the field consists in removing 409 the field, and the decompression consists in retrieving the field 410 value from a known local value. The local value may be stored in 411 a EHC Context or defined by the EHC Rule (like a zero value for 412 example). 413 c. lsb designates an action where both peers have a local value of 414 the field, but the compression consists in sending only the LSB 415 bytes instead of the whole field. The decompression consists in 416 retrieving the field from the LSB sent as well as some other 417 additional local values. 419 d. lower designates an action where the compression consists in not 420 sending the field. The decompression consists in retrieving the 421 field from the lower layers of the packet. A typical example is 422 when both IP and UDP carry the length of the payload, then the 423 length of the UDP payload can be inferred from the one of the IP 424 layer. 425 e. checksum designates an action where the compression consists in 426 not sending a checksum field. The decompression consists in re- 427 computing the checksum. ESP provides an integrity-check based on 428 signature of the ESP payload (ICV). This makes removing checksum 429 possible, without harming the checksum mechanism. 430 f. padding designates an action that computes the padding of the ESP 431 packet. The function is specific to the ESP. 433 For all actions, the function can be performed only when the 434 appropriated parameters and fields are provided. When a field or a 435 parameters does not have an appropriated value its value is 436 designated as "Unspecified". Specifically some fields such as inner 437 IP addresses, ports or transport protocols are agreed during the SA 438 negotiation and are specified by the SA. Their value in the SA may 439 take various values that are not appropriated to enable a 440 compression. For example, when these fields are defined as a range 441 of values, or by selectors such as OPAQUE or ANY these fields cannot 442 be retrieved from a local value. Instead, when they are defined as a 443 "Single" value (i.e a single IP address, or a single port number or a 444 single transport protocol number) compression and decompression can 445 be performed. These SA related fields are considered as 446 "Unspecified" when not limited to a "Single" value. 448 When a field or a parameter is "Unspecified", the EHC Rule MUST NOT 449 be activated. This is the purpose of the EHC Strategy to avoid 450 ending in such case. In any case, when one of these condition is not 451 met, the EHC Rule MUST NOT perform any compression or decompression 452 action and the packet MUST be discarded. When possible, an error 453 SHOULD be raised and logged. 455 6.1. EHC Rules for ESP 457 This section describes the EHC Rules for ESP which are summed up in 458 the table below. 460 +---------+-------------------+---------+---------------------------+ 461 | EHC | Field | Action | Parameters | 462 | Rule | | | | 463 +---------+-------------------+---------+---------------------------+ 464 | ESP_SPI | SPI | lsb | esp_spi_lsb, esp_spi | 465 | ESP_SN | Sequence Number | lsb | esp_sn_lsb, esp_sn_gen, | 466 | | | | esp_sn | 467 | ESP_NH | Next Header | elided | l4_proto, ipsec_mode | 468 | ESP_PAD | Pad Length, | padding | esp_align, esp_encr | 469 | | Padding | | | 470 +---------+-------------------+---------+---------------------------+ 472 ESP_SPI designates the EHC Rule compressing / decompressing the SPI. 473 ESP_SPI is performed in the "post-esp" phase. The SPI is compressed 474 using "lsb". The sending peer only places the LSB bytes of the SPI 475 and the receiving peer retrieve the SPI from the LSB bytes carried in 476 the packets as well as from the SPI value stored in the SA. The SPI 477 MUST be retrieved as its full value is included in the signature 478 check. The two peers MUST agree on the number of LSB bytes to be 479 sent: "esp_spi_lsb". Upon agreeing on "esp_spi_lsb", the receiving 480 peer MUST NOT agree on a value not carrying sufficient information to 481 retrieve the full SPI. 483 ESP_SN designates the EHC Rule compressing / decompressing the ESP 484 Sequence Number. ESP_SN is performed in the "post-esp" phase. 485 ESP_SN is only activated if the SN ("esp_sn"), the LSB significant 486 bytes ("esp_sn_lsb") and the method used to generate the SN 487 ("esp_sn_gen") are defined. The Sequence Number is compressed using 488 "lsb". Similarly to the SPI, the Sequence Number MUST be retrieved 489 in order to complete the signature check of the ESP packet. Unlike 490 the SPI, the Sequence Number is not agreed by the peers, but is 491 changing for every packet. As a result, in order to retrieve the 492 Sequence Number from the LSB "esp_sn_lsb", the peers MUST agree on 493 generating Sequence Number in a similar way. This is negotiated with 494 "esp_sn_gen" and the receiver MUST ensure that "esp_sn_lsb" is big 495 enough to absorb minor packet losses or time differences between the 496 peers. 498 ESP_NH designates the EHC Rule compressing / decompressing the ESP 499 Next Header. ESP_NH is performed in the "clear text esp" phase. 500 ESP_NH is only activated if the Next Header is specified. The Next 501 Header can be specified as IP (IPv4 or IPv6) when the IPsec tunnel 502 mode is used ("esp_mode" set to "Tunnel") or when the transport mode 503 is used when the Traffic Selectors defines a "Single" Protocol ID 504 ("l4_proto"). The Next Header, is compressed using "elided". The 505 Next Header indicates the Header in the Payload Data. When the 506 Tunnel mode is chosen, the type of the header is known to be an IP 507 header. Similarly, the TS may also hold transport layer protocol, 508 which specifies the Next Header value for Transport mode. The Next 509 Header value is only there to provide sufficient information for 510 decapsulating ESP. In other words decompressing this fields would 511 occur in the "clear text esp" phase and striped but directly removed 512 again by the ESP stack. For these reasons, implementation may simply 513 omit decompressing this field. 515 ESP_PAD designates the EHC Rule compressing / decompressing the Pad 516 Length and Padding fields. ESP_PAD is performed in the "clear text 517 exp" phase. Pad Length and Padding define the padding. The purpose 518 of padding is to respect a 32 bit alignment for ESP or block sizes of 519 the used cryptographic suite. As the ESP trailer is encrypted, 520 Padding and Pad Length MUST to be performed by ESP and not by the 521 encryption algorithm. Thus, ESP_PAD always needs to respect the 522 cipher alignment ("esp_encr"), if applicable. Compression may be 523 performed especially when device support alignment smaller than 32 524 bit. Such alignment is designated as "esp_align" and the padding 525 bytes are the necessary bytes so the ESP packet has a length that is 526 a multiple of "esp_align". 528 When "esp_align" is set to an 8-bit alignment padding bytes are not 529 necessary, and Padding as well as Pad Length are removed. For values 530 that are different from 8-bit alignment, padding bytes needs to be 531 computed according to the ESP packet length why ESP_PAD MUST be the 532 last action of "clear text esp". The resulting number of padding 533 byte is then expressed in Padding and Pad Length fields with Pad 534 Length set to padding bytes number - 1 and Padding is generated as 535 described in [RFC4303]. 537 Combining the Pad Length and Padding fields could potentially add an 538 overhead on fixed size padding. In fact some applications may only 539 send the same type of fixed size data, in which case the Pad Length 540 would not be necessary to be specified. However, the only corner 541 case Pad Length fields would actually add an overhead is when padding 542 is expected to be of zero size. In this case, specifying an 8-bit 543 alignment solve this issue. 545 6.2. EHC Rules for inner IPv4 547 All IPv4 EHC Rules MUST be performed during the "clear text esp" 548 phase. The EHC Rules are only defined for compressing the inner IPv4 549 header and thus can only be used when the SA is using the Tunnel 550 mode. 552 +---------------+-----------------+----------+--------------------+ 553 | EHC Rule | Field | Action | Parameters | 554 +---------------+-----------------+----------+--------------------+ 555 | IP4_OPT_DIS | Version | elided | ip_version | 556 | | Header Length | elided | | 557 | IP4_LENGTH | Total Length | lower | | 558 | IP4_ID | Identification | lsb | ip4_id, ip4_id_lsb | 559 | IP4_FRAG_DIS | Flags | elided | | 560 | | Fragment Offset | elided | | 561 | IP4_TTL_OUTER | Time To Live | elided | ip4-ttl | 562 | IP4_TTL_VALUE | Time To Live | elided | ip4-ttl | 563 | IP4_PROT | Protocol | elided | l4_proto | 564 | IP4_CHECK | Header Checksum | checksum | | 565 | IP4_SRC | Source Address | elided | ipv4-source | 566 | IP4_DST | Dest. Address | elided | ipv4-dest | 567 +---------------+-----------------+----------+--------------------+ 569 IP4_OPT_DIS designates that the IPv4 header does not include any 570 options and indicates if the first byte of the IPv4 header - 571 consisting of IP version and IPv4 Header Length, are compressed. The 572 Version "ip_version" is defined by the SA and is thus compressed 573 using "elided". The Header Length is static, if the header does not 574 contain any options, thus it is compressed with "elided" and 575 decompressed "20", the default length of the IPv4 header. 577 IP4_LENGTH designates the EHC Rule compressing / decompressing the 578 Total Length Field of the inner IPv4 header. The Total Length is 579 compressed by the sender and not sent. The receiver decompresses it 580 by recomputing the Total Length from the outer IP header. The outer 581 IP header can be IPv4 or IPv6 and IP4_LENGTH MUST support both 582 versions if both versions are supported by the device. Note that the 583 length of the inner IP payload may also be subject to updates if 584 decompression of the upper layers occurs. 586 IP4_ID designates the EHC Rule compressing / decompressing the 587 Identification Field. IP4_ID is only activated if the ID ("ip4_id"), 588 the LSB significant bytes ("ip4_id_lsb") are defined. Upon agreeing 589 on "ip4_id_lsb", the receiving peer MUST NOT agree on a value not 590 carrying sufficient information to retrieve the full IP 591 Identification. Note also that unlike the ESP SN, the IPv4 592 Identification is not part of the SA. As a result, when the ID is 593 compressed, its value MUST be stored in the EHC Context. The 594 reserved attribute for that is "ip4_id" 596 IP4_FRAG_DIS designates that the inner IPv4 header does not support 597 fragmentation. If activated, IP4_FRAG_DIS indicates compression of 598 Flags and Fragment Offset field in the IPv4 header which consists of 599 2 bytes. Both fields are compressed with "elided" and decompressed 600 with their default value according to [RFC0791], which is 0b010 for 601 Flags and 0 for Fragment Offset. 603 IP4_TTL_OUTER designates an EHC Rule compressing / decompressing the 604 Time To Live field of the inner IP header. IP4_TTL_OUTER is only 605 activated when both the outer and inner IP header are IPv6 header. 606 The Time To Live field is compressed / decompressed using the 607 "lower". More specifically, the field is not sent. The receiver 608 decompresses them by reading their value from the outer IPv4 header. 610 IP4_TTL_VALUE designates an EHC Rule compressing / decompressing the 611 Time To Live field of the inner IP header. IP4_TTL_VALUE is only 612 activated when the Hop Limit ("ip4_ttl") has been agreed. Time To 613 Live is compressed / decompressed using the "elided" method. 615 IP4_PROTO designates the EHC Rule compressing / decompressing the 616 Protocol field of the inner IPv4 header. IP4_PROTO is only activated 617 if the Protocol is specified, that is when the Traffic Selectors 618 defines a "Single" Protocol ID ("l4_proto"). When the Protocol ID 619 identified by the SA has a "Single" value, the Protocol is compressed 620 and decompressed using the "elided" method. 622 IP4_CHECK designates the EHC rule compressing / decompressing the 623 Header Checksum field of the inner IPv4 header. The IPv4 header 624 checksum is not sent by the sender and the receiver computes from the 625 decompressed inner IPv4 header. IP4_CHECK MUST compute the checksum 626 and not fill the checksum field with zeros. As a result, IP4_CHECK 627 is the last decompressing EHC Rule to be performed on the 628 decompressed IPv4 header. 630 IP4_SRC compresses the source IP address of the inner IPv4 header. 631 IP4_SRC_IP is only be activated when the Traffic Selectors agreed by 632 the SA defines a "Single" source IP address ("ip4_src"). The Source 633 IP address is compressed / decompressed using the "elided" method. 635 IP4_DST works in a similar way as IP4_SRC_IP but for the destination 636 IP address ("ip4_dst") 638 6.3. EHC Rules for inner IPv6 640 All IPv6 EHC Rules MUST be performed during the "clear text esp" 641 phase. The EHC Rules are only defined for compressing the inner IPv6 642 header and thus can only be used when the SA is using the Tunnel 643 mode. 645 +--------------+----------------+--------+------------+ 646 | EHC Rule | Field | Action | Parameters | 647 +--------------+----------------+--------+------------+ 648 | IP6_OUTER | Version | elided | ip_version | 649 | | Traffic Class | lower | | 650 | | Flow Label | lower | | 651 | IP6_VALUE | Version | elided | ip_version | 652 | | Traffic Class | elided | ip6_tc | 653 | | Flow Label | elided | ip6_fl | 654 | IP6_LENGTH | Payload Length | lower | | 655 | IP6_NH | Next Header | elided | l4_proto | 656 | IP6_HL_OUTER | Hop Limit | lower | | 657 | IP6_HL_VALUE | Hop Limit | elided | ip6_hl | 658 | IP6_SRC | Source Address | elided | ip6_source | 659 | IP6_DST | Dest. Address | elided | ip6_dest | 660 +--------------+----------------+--------+------------+ 662 IP6_OUTER designates an EHC Rule for compressing / decompressing the 663 first 32 bits of the inner IPv6 header formed by the Version, Traffic 664 Class and Flow Label. IP6_OUTER is only activated when both the 665 outer and inner IP header are IPv6 header. The Version "ip_version" 666 is defined by the SA and is thus compressed using "elided". The 667 other parameters Traffic Class and Flow Label are compressed using 668 "lower". More specifically, the fields are not sent. The receiver 669 decompresses them by reading their value from the outer IPv6 header. 671 IP6_VALUE designates an EHC Rule for compressing / decompressing the 672 first 32 bits of the inner IPv6 header formed by the Version, Traffic 673 Class and Flow Label. IP6_VALUE is only activated if the Version of 674 the inner IP header agreed by the SA is set to "Version 6" 675 ("ip_version" set to "Version 6") and the specific values of the 676 Traffic Class ("ip6_tc") and the Flow Label ("ip6_fl") are specified. 677 With IP6_VALUE all fields are compressed and decompressed using 678 "elided". Version is provided by the SA ("ip_version") while other 679 fields are explicitly provided (ip6_tc, ip6_fl. 681 IP6_LENGTH designates the EHC Rule compressing / decompressing the 682 Payload Length Field of the inner IPv6 header. The Payload Length is 683 compressed by the sender and is not sent. The receiver decompress it 684 by recomputing the Payload Length from the outer IP header. The IP 685 header can be IPv4 or IPv6 and IP6_LENGTH MUST support both versions 686 if both versions are supported by the device. Note that the length 687 of the inner IP payload may also be subject to updates if 688 decompression of the upper layers occurs. 690 IP6_NH designates the EHC Rule compressing / decompressing the Next 691 Header field of the inner IPv6 header. IP6_NH is only activated if 692 the Next Header is specified, that is when the Traffic Selectors 693 defines a "Single" Protocol ID ("l4_proto"). When the Protocol ID 694 identified by the SA has a "Single" value, the Next Header is 695 compressed and decompressed using the "elided" method. 697 IP6_HL_OUTER designates an EHC Rule compressing / decompressing the 698 Hop Limit field of the inner IP header. IP6_HL_OUTER is only 699 activated when both the outer and inner IP header are IPv6 header. 700 The Hop Limit field is compressed / decompressed using the "lower". 701 More specifically, the fields are not sent. The receiver 702 decompresses them by reading their value from the outer IPv6 header. 704 IP6_HL_VALUE designates an EHC Rule compressing / decompressing the 705 Hop Limit field of the inner IP header. IP6_HL_VALUE is only 706 activated when the Hop Limit ("ip6_hl") has been agreed. The Hop 707 Limit is compressed / decompressed using the "elided" method. 709 IP6_SRC compresses the source IP address of the inner IP header. 710 IP6_SRC_IP is only be activated when the Traffic Selectors agreed by 711 the SA defines a "Single" source IP address ("ip6_src"). The Source 712 IP address is compressed / decompressed using the "elided" method. 714 IP6_DST works in a similar way as IP6_SRC_IP but for the destination 715 IP address ("ip6_dst") 717 6.4. EHC Rules for UDP 719 All UDP EHC Rules MUST be performed during the "pre-esp" phase. The 720 EHC Rules are only defined when the Traffic Selectors agreed during 721 the SA negotiation results in "Single" Protocol ID ("l4_proto") which 722 is set to UDP (17). 724 +------------+--------------+----------+------------+ 725 | EHC Rule | Field | Action | Parameters | 726 +------------+--------------+----------+------------+ 727 | UDP_SRC | Source Port | elided | l4_source | 728 | UDP_DST | Dest. Port | elided | l4_dest | 729 | UDP_LENGTH | Length | lower | | 730 | UDP_CHECK | UDP Checksum | checksum | | 731 +------------+--------------+----------+------------+ 733 UDP_SRC designates the EHC Rule that compresses / decompresses the 734 UDP Source Port. UDP_SRC is only activated when the Source Port 735 agreed by the SA negotiation ("l4_src") is "Single". The Source Port 736 is then compressed / decompressed using the "elided" method. 738 UDP_DST works in a similar way as UDP_SRC but for the Destination 739 Port ("l4_dst"). 741 UDP_LENGTH designates the EHC Rule compressing / decompressing the 742 Length Field of the UDP header. The length is compressed by the 743 sender and is not sent. The receiver decompresses it by recomputing 744 the Length from the IP address header. The IP address can be IPv4 or 745 IPv6 and UDP_LENGTH MUST support both versions if both versions are 746 supported by the device. 748 UDP_CHECK designates the EHC Rule compressing / decompressing the UDP 749 Checksum. The UDP Checksum is not sent by the sender and the 750 receiver computes from the decompressed UDP payload. UDP_CHECK MUST 751 compute the checksum and not fill the checksum field with zeros. As 752 a result, UDP_CHECK is the last decompressing EHC Rule to be 753 performed on the decompressed UDP Payload. 755 6.5. EHC Rules for UDP-Lite 757 All UDP-lite EHC Rules MUST be performed during the "pre-esp" phase. 758 The EHC Rules are only defined when the Traffic Selectors agreed 759 during the SA negotiation results in a "Single" Protocol ID 760 ("l4_proto") which is set to UDPLite (136). 762 +-------------------+-----------------+----------+------------------+ 763 | EHC Rule | Field | Action | Parameters | 764 +-------------------+-----------------+----------+------------------+ 765 | UDP-LITE_SRC | Source Port | elided | l4_source | 766 | UDP-LITE_DST | Dest. Port | elided | l4_dest | 767 | UDP-LITE_COVERAGE | Checksum | elided | udplite_coverage | 768 | | Coverage | | | 769 | UDP-LITE_CHECK | UDP-Lite | checksum | | 770 | | Checksum | | | 771 +-------------------+-----------------+----------+------------------+ 773 UDP-LITE_SRC works similarly to UDP_SRC 775 UDP-LITE_DST works similarly to UDP_DST 777 UDP-LITE_COVERAGE designates the EHC Rule compressing / decompressing 778 the UDP-Lite Coverage field. UDP-LITE_COVERAGE is only activated 779 when the Coverage ("udplite_coverage") has been agreed with a valid 780 value. The Coverage is compressed / decompressed using the "elided" 781 method. 783 UDP-LITE_CHECK designates the EHC Rule compressing / decompressing 784 the UDP-Lite checksum. UDP-LITE_CHECK is only activated if the 785 Coverage is defined either elided or sent. UDP-LITE_CHECK computes 786 the checksum using "checksum" according to the uncompressed UDP 787 packet and the value of the Coverage. 789 6.6. EHC Rules for TCP 791 All TCP EHC Rules MUST be performed during the "pre-esp" phase. The 792 EHC Rules are only defined when the Traffic Selectors agreed during 793 the SA negotiation results in a"Single" Protocol ID ("l4_proto") 794 which is set to TCP (6). 796 +-------------+---------------------+------------+------------------+ 797 | EHC Rule | Field | Action | Parameters | 798 +-------------+---------------------+------------+------------------+ 799 | TCP_SRC | Source Port | elided | l4_source | 800 | TCP_DST | Dest. Port | elided | l4_dest | 801 | TCP_SN | Sequence Number | lsb | tcp_sn, tcp_ls | 802 | TCP_ACK | Acknowledgment | lsb | tcp_ack, tcp_lsb | 803 | | Number | | | 804 | TCP_OPTIONS | Data Offset | elided | tcp_options | 805 | | Reserved Bits | elided | | 806 | TCP_CHECK | TCP Checksum | checksum | | 807 | TCP_URGENT | elided | tcp_urgent | 808 +-------------+---------------------+------------+------------------+ 810 TCP_SRC works similarly to UDP_SRC. 812 TCP_DST works similarly to UDP_DST. 814 TCP_SN designates the EHC Rule compressing / decompressing the TCP 815 Sequence Number. TCP_SN is only activated if the SN ("tcp_sn") and 816 the LSB significant bytes ("tcp_lsb") are defined. The TCP SN is 817 compressed using "lsb". The sending peer only places the LSB bytes 818 of the TCP SN ("tcp_sn") and the receiving peer retrieve the TCP SN 819 from the LSB bytes carried in the packets as well as from the TCP SN 820 value stored in EHC Context ("tcp_sn"). The two peers MUST agree on 821 the number of LSB bytes to be sent: "tcp_lsb". Upon agreeing on 822 "tcp_lsb", the receiving peer MUST NOT agree on a value not carrying 823 sufficient information to retrieve the full TCP SN. Note also that 824 unlike the ESP SN, the TCP SN is not part of the SA. As a result, 825 when the SN is compressed, the value of the TCP SN MUST be stored in 826 the EHC Context. The reserved attribute for that is "tcp_sn" 828 TCP_ACK designates the EHC Rule compressing / decompressing the TCP 829 Acknowledgment Number and works similarly to TCP SN. Note that 830 "tcp_lsb" is agreed for both TCP SN and TCP Acknowledgment. 831 Similarly the value of the complete TCP Acknowledgment Number MUST be 832 stored in the "tcp_ack" attribute of the EHC Context. 834 TCP_OPTIONS designates the EHC Rule compressing / decompressing TCP 835 options related fields such as Data Offset and Reserved Bits. 836 TCP_OPTION can only be activated when the TCP Option ("tcp_options") 837 is defined. When "tcp_options" is set to "False" and indicates there 838 are no TCP Options, the Data Offsets and Reserved Bits are compressed 839 / decompressed using the "elided" method with Data Offset and 840 Reserved Bits set to zero. 842 TCP_CHECK designates the EHC Rule compressing / decompressing the TCP 843 Checksum. TCP_CHECK works similarly as UDP_CHECK. 845 TCP_URGENT designates the EHC Rule compressing / decompressing the 846 urgent related information. When "tcp_urgent" is set to "False" and 847 indicates there are no TCP Urgent related information, the Urgent 848 Pointer is then "elided" and filled with zeros. 850 7. Diet-ESP EHC Strategy 852 From the attributes of the EHC Context, Diet-ESP, defines as an EHC 853 Strategy which EHC Rules to apply. The EHC Strategy is defined both 854 for outbound packets which compresses the packet as well as for 855 inbound packet where the decompression occurs. 857 Implementation may differ from the description below. However, the 858 outcome MUST remain the same. 860 7.1. Outbound Packet Processing 862 Diet-ESP compression is defined as follows: 864 1. In phase "pre-esp": Match the inbound packet with the SA and 865 determine if the Diet-ESP EHC Strategy has been activated. If 866 the Diet-ESP HEC Strategy has been activated proceed to next 867 step, otherwise skip all steps associated to Diet-ESP and proceed 868 to the standard ESP as defined in [RFC4303] 869 2. In phase "pre-esp": If "l4_proto" designates a "Single" Protocol 870 ID (UDP, TCP or UDP-Lite), proceed to the compression of the 871 specific layer. Otherwise, the transport layer is not 872 compressed. 873 3. In phase "clear text esp": If "esp_mode" is set to "Tunnel" mode, 874 determine "ip_version" the IP version of the inner IP addresses 875 and proceed to the appropriated inner IP address compression. 876 4. In phase "clear text esp" and "post-esp": Proceed to the ESP 877 compression. 879 UDP compression is defined as below: 881 1. If the "l4_src" designates a "Single" Source Port, apply UDP_SRC 882 to compress the Source Port. 883 2. If the "l4_dst" designates a "Single" Destination Port, apply 884 UDP_DST to compress the Destination Port. 886 3. Apply UDP_CHECK to compress the Checksum. 887 4. Apply UDP_LENGTH to compress the Length. 889 UDP-lite compression is defined as below: 891 1. If the "l4_src" designates a "Single" Source Port, apply the UDP- 892 LITE_SRC to compress the Source Port. 893 2. If the "l4_dst" designates a "Single" Destination Port, apply the 894 UDP-LITE_DST, to compress the Destination Port. 895 3. If "udplite_coverage" is specified, apply the UDP-LITE_COVERAGE, 896 to compress the Coverage. 897 4. Apply UDP-LITE_CHECK to compress the Checksum. 899 TCP compression is defined as below: 901 1. If the "l4_src" designates a "Single" Source Port than apply the 902 TCP_SRC to compress the Source Port. 903 2. If the "l4_dst" designates a "Single" Destination Port than apply 904 the TCP_DST to compress the Destination Port. 905 3. If "tcp_lsb" is lower than 4, then "tcp_sn" "tcp_ack" attributes 906 of the Diet-ESP Context are updated with the value provided from 907 the packet before applying the TCP_SN and the TCP_ACK EHC Rules. 908 4. If "tcp_options" is set to "False" apply the TCP_OPTIONS EHC 909 Rule. 910 5. If "tcp_urgent" is set to "False" apply the TCP_URGENT EHC Rule. 911 6. Apply TCP_CHECK to compress the Checksum. 913 Inner IPv6 Header compression is defined as below: 915 1. If the "ip6_src" designates a "Single" Source IP address, apply 916 the IP6_SRC to compress the IPv6 Source Address. 917 2. If the "ip6_dst" designates a "Single" Destination IP address, 918 apply the IP6_DST to decompress the IPv6 Destination Address. 919 3. Hop Limit compression is performed as follows: 921 1. If "outer_version" is set to "IPv6" and "ip6_hl_comp" is set 922 to "Outer" apply IP6_HL_OUTER. 923 2. If "outer_version" is set to "IPv4" and "ip6_hl_comp" is set 924 to "Outer" raise an error and discard the packet. 925 3. If "ip6_hl_comp" is set to "Value" apply IP6_HL_VALUE. 926 4. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP- 927 Lite), apply IP6_NH to compress the Next Header. 928 5. Apply, IP6_LENGTH to compress the Length. 929 6. Version, Traffic Class and Flow Label are compressed as follows: 931 1. If "outer_version" is set to "IPv6" and "ip6_tcfl_comp" is 932 set to "Outer" apply IP6_OUTER. 934 2. If "outer_version" is set to "IPv4" and "ip6_tcfl_comp" is 935 set to "Outer" raise an error and discard the packet. 936 3. If "ip6_tcfl_comp" is set to "Value" apply IP6_VALUE. 938 ESP compression is defined as below: 940 1. In phase "clear text esp": If "esp_mode" is set to "Tunnel" or 941 "l4_proto" is set to a "Single value - eventually different from 942 TCP, UDP or UDP-Lite, apply ESP_NH, to compress the Next Header. 943 2. In phase "clear text esp": If "esp_encr" specify an encryption 944 algorithm that does not provide padding, then apply ESP_ALIGN to 945 compress the Pad Length and Padding. 946 3. Proceed to the ESP encryption as defined in [RFC4303]. 947 4. In phase "post-esp: If "esp_sn_lsb" is different from 4, then 948 apply ESP_SN. To compress the ESP SN. 949 5. In phase "post-esp": If "esp_spi_lsb" is different from 4, then 950 apply ESP_SPI to compress the SPI. 952 7.2. Inbound Packet Processing 954 Diet-ESP decompression is defined as follows: 956 1. Match the inbound packet with the SA and determine if the Diet- 957 ESP EHC Strategy has been activated. When Diet-ESP is activated 958 this means that the "esp_spi_lsb" are sufficient to index the SA 959 and proceed to next step, otherwise skip all steps associated to 960 Diet-ESP and proceed to the standard ESP as defined in [RFC4303] 961 2. In phase "clear text esp" and "post-esp": Proceed to the ESP 962 decompression. 963 3. In phase "clear text esp": If "esp_mode" is set to "Tunnel" mode, 964 determine "ip_version" the IP version of the inner IP addresses 965 and proceed to the appropriated inner IP address decompression, 966 except for the computation of the checksums and length. 967 4. In phase "pre-esp": If "l4_proto" designates a "Single" Protocol 968 ID (UDP, TCP or UDP-Lite), proceed to the decompression of the 969 specific layer, except for the computation of the checksums and 970 length replaced by zero fields. 971 5. In phase "pre-esp": Proceed to the decompression of the checksums 972 and length. 974 ESP decompression is defined as follows: 976 1. In phase "post-esp": If "esp_spi_lsb" is different from 4, then 977 apply ESP_SPI to decompress the SPI. 978 2. In phase "post-esp: If "esp_sn_lsb" is different from 4, then 979 apply ESP_SN. To decompress the ESP SN. 980 3. Proceed to the ESP signature validation and decryption as defined 981 in [RFC4303]. 983 4. In phase "clear text esp": If "esp_mode" is set to "Tunnel" or 984 "l4_proto" is set to a "Single value - eventually different from 985 TCP, UDP or UDP-Lite, apply ESP_NH, to decompress the Next 986 Header. 987 5. In phase "clear text esp": If "esp_encr" specify an encryption 988 algorithm that does not provide padding, then apply ESP_ALIGN to 989 compress the Pad Length and Padding. 990 6. Extract the ESP Data Payload and apply decompression EHC Rule to 991 the ESP Data Payload. 993 Inner IPv6 decompression is defined as follows: 995 1. Version, Traffic Class and Flow Label are decompressed as 996 follows: 998 1. If "outer_version" is set to "IPv6" and "ip6_tcfl_comp" is 999 set to "Outer" apply IP6_OUTER to decompress Version, Traffic 1000 Class and Flow Label. 1001 2. If "outer_version" is set to "IPv4" and "ip6_tcfl_comp" is 1002 set to "Outer" raise an error and discard the packet. 1003 3. If "ip6_tcfl_comp" is set to "Value" apply IP6_VALUE to 1004 Version, Traffic Class and Flow Label. 1005 4. If "ip6_tcfl_comp" is set to "UnComp", Version, Traffic Class 1006 and Flow Label are already provided in the packet. 1007 2. Set the Length to zero. 1008 3. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP- 1009 Lite), apply IP6_NH to decompress the Next Header. 1010 4. Hop Limit decompression is performed as follows: 1012 1. If "outer_version" is set to "IPv6" and "ip6_hl_comp" is set 1013 to "Outer" apply IP6_HL_OUTER to decompress Hop Limit. 1014 2. If "outer_version" is set to "IPv4" and "ip6_hl_comp" is set 1015 to "Outer" raise an error and discard the packet. 1016 3. If "ip6_hl_comp" is set to "Value" apply IP6_HL_VALUE to 1017 decompress the Hop Limit. 1018 4. If "ip6_hl_comp" is set to "UnComp", Hop Limit is already 1019 provided in the packet. 1020 5. If the "ip6_src" designates a "Single" Source IP address, apply 1021 the IP6_SRC to de compress the IPv6 Source Address. 1022 6. If the "ip6_dst" designates a "Single" Destination IP address 1023 than apply the IP6_DST to decompress the IPv6 Destination 1024 Address. 1025 7. Apply, IP6_LENGTH to provide the replace the zero length value by 1026 its appropriated appropriated value. The Length value considers 1027 the length provided by the lower layers to which are added the 1028 additional bytes due to the decompression, minus the length of 1029 the inner IP6 Header. The value computed from the lower layer 1030 will have to be overwritten in case further decompression occurs. 1032 UDP decompression is defined as follows: 1034 1. If the "l4_src" designates a "Single" Source Port, apply UDP_SRC 1035 to decompress the Source Port. 1036 2. If the "l4_dst" designates a "Single" Destination Port, apply 1037 UDP_DST to decompress the Destination Port. 1038 3. Apply UDP_LENGTH to compress the Length. The length value is 1039 computed from the length provided by the lower layer, with the 1040 additional added bytes during the UDP decompression including the 1041 length size. 1042 4. Apply UDP_CHECK to decompress the Checksum. 1043 5. Update the Length of the lower layers: 1045 1. If "esp_mode" is set to "Transport" mode, update the Length 1046 of the outer IP header (IPv4 or IPv6). The Length is 1047 incremented by the number of bytes generated by the 1048 decompression of the transport layer. 1049 2. If "esp_mode" is set to "Tunnel" mode, update the Length of 1050 the inner IP address (IPv4 or IPv6) as well as the outer IP 1051 header (IPv4 or IPv6). The Length is incremented by the 1052 number of bytes generated by the decompression of the 1053 transport layer. 1055 UDP-Lite decompression is defined as follows: 1057 1. If the "l4_src" designates a "Single" Source Port, apply the UDP- 1058 LITE_SRC to decompress the Source Port. 1059 2. If the "l4_dst" designates a "Single" Destination Port, apply the 1060 UDP-LITE_DST, to decompress the Destination Port. 1061 3. If "udplite_coverage" is specified, apply the UDP-LITE_COVERAGE, 1062 to decompress the Coverage. 1063 4. Apply UDP-LITE_CHECK to compress the Checksum. 1064 5. Update the Length of the lower layers as defined in UDP. 1066 TCP decompression is defined as follows: 1068 1. If the "l4_src" designates a "Single" Source Port than apply the 1069 TCP_SRC to decompress the Source Port. 1070 2. If the "l4_dst" designates a "Single" Destination Port than apply 1071 the TCP_DST to decompress the Destination Port. 1072 3. If "tcp_lsb" is lower than 4, apply TCP_SN and the TCP_ACK to 1073 decompress the TCP Sequence Number and the TCP Acknowledgment 1074 Number. 1075 4. If "tcp_options" is set to "False" apply TCP_OPTIONS to 1076 decompress Data Offset and Reserved Bits. 1077 5. If "tcp_urgent" is set to "False" apply the TCP_URGENT to 1078 decompress the Urgent Pointer. 1079 6. Apply TCP_CHECK to decompress the Checksum. 1081 8. IANA Considerations 1083 There are no IANA consideration for this document. 1085 9. Security Considerations 1087 This section lists security considerations related to the Diet-ESP 1088 protocol. 1090 Security Parameter Index (SPI): 1091 The Security Parameter Index (SPI) is used by the receiver to 1092 index the Security Association that contains appropriated 1093 cryptographic material. If the SPI is not found, the packet is 1094 rejected as no further checks can be performed. In EHC, the value 1095 of the SPI is not reduced, but compressed why the SPI value may 1096 not be fully provided between the compressor and the de- 1097 compressor. On the other hand, its uncompressed value is provided 1098 to the ESP-procession and no weakness is introduced to ESP itself. 1099 On an implementation perspective, it is strongly recommended that 1100 decompression is deterministic. Compression and decompression 1101 adds some additional treatment to the ESP packet, which might be 1102 used by an attacker. In order to minimize the load associated to 1103 decompression, decompression is expected to be deterministic. The 1104 incoming compressed SPI with the associated IP addresses should 1105 output a single and unique uncompressed SPI value. If an 1106 uncompressed SPI values have to be considered, then the receiver 1107 could end in n signature checks which may be used by an attacker 1108 for a DoS attack. 1109 Sequence Numer (SN): 1110 The Sequence Number (SN) is used as an anti-replay attack 1111 mechanism. Compression and decompression of the SN is already 1112 part of the standard ESP namely the Extended Sequence Number 1113 (ESN). The SN in a standard ESP packet is 32 bit long, whether 1114 EHC enables to reduce it to 0 bytes and the main limitation to the 1115 compression a deterministic decompression. SN compression 1116 consists in indicating the least significant bits of the 1117 uncompressed SN on the wire. The size of the compressed SN must 1118 consider the maximum reordering index such that the probability 1119 that a later sent packet arrives before an earlier one. In 1120 addition the size of SN should also consider maximum consecutive 1121 packets lost during transmission. In the case of ESP, this number 1122 is set to 2^32 which is, in most real world case, largely over- 1123 provisioned. When the compression of the SN is not appropriately 1124 provisioned, the most significant bit value may be de-synchronized 1125 between the sending and receiving parties. Although IKEv2 1126 provides some re-synchronization mechanisms, in case of IoT the 1127 de-synchronization will most likely result in a renegotiation and 1128 thus DoS possibilities. Note that IoT communication may also use 1129 some external parameters, i.e. other than the compressed SN, to 1130 define whether a packet be considered or not and eventually derive 1131 the SN. One such scenario may be the use of time windows. 1132 Suppose a device is expected to send some information every hour 1133 or every week. In this case, for example, the SN may be 1134 compressed to zero bytes. Instead the SN may be derived by 1135 incrementing the SN every hour after the last received valid 1136 packet. Considering the time the packet is received make it 1137 possible to consider the time derivation of the sensor clock. If 1138 TIME is used as the method to generate the SN, the receiver MUST 1139 ensure that the esp_sn_lsb is big enough to resist time 1140 differences between the nodes. Note also that the anti-replay 1141 mechanism needs to define the size of the anti-replay 1142 window.[RFC4303] provides guidance to set the window size and are 1143 similar to those used to define the size of the compressed SN. 1145 10. Privacy Considerations 1147 Security Parameter Index (SPI): 1148 Until Diet-ESP is not deployed outside the scope of IoT and small 1149 devices, the use of a compressed SPI may provide an indication 1150 that one of the endpoint is a sensor. Such information may be 1151 used, for example, to evaluate the number of appliances deployed, 1152 or - in addition with other information, such as the time 1153 interval, the geographic location - be used to derive the type of 1154 data transmitted. 1155 Sequence Number (SN): If incremented for each ESP packet, the SN may 1156 leak some information like the amount of transmitted data or the 1157 age of the sensor. The age of the sensor may be correlated with 1158 the software used and the potential bugs. On the other hand, re- 1159 keying will re-initialize the SN, but the cost of a re-keying may 1160 not be negligible and thus, frequent re-keying can be considered. 1161 In addition to the re-key operation, the SN may be generated in 1162 order to reduce the accuracy of the information leaked. In fact, 1163 the SN does not have to be incremented by one for each packet it 1164 just has to be an increasing function. Using a function such as a 1165 TIME may prevent characterizing the age or the use of the sensor. 1166 Note that the use of such function may also impact the compression 1167 efficiency and result in larger compressed SN. 1169 11. Acknowledgment 1171 We thank Orange and Universitee Pierre et Marie Curie for initiating 1172 the work on Diet-ESP. We Would like to thank Sylvain Killian for 1173 implementing an open source Diet-ESP on Contiki and testing it on the 1174 FIT IoT-LAB [fit-iot-lab] funded by the French Ministry of Higher 1175 Education and Research. We thank the IoT-Lab Team and the INRIA for 1176 maintaining the FIT IoT-LAB platform and for providing feed backs in 1177 an efficient way. 1179 We would like to thank Rob Moskowitz for not copyrighting Diet HIP. 1180 The "Diet" terminology is from him. 1182 We woudl like to thank those we received many useful feed backs among 1183 others: Dominique Bartel, Anna Minaburo, Suresh Krishnan, Samita 1184 Chakrabarti, Michael Richarson, Tero Kivinen. 1186 12. References 1188 12.1. Normative References 1190 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1191 DOI 10.17487/RFC0791, September 1981, 1192 . 1194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1195 Requirement Levels", BCP 14, RFC 2119, 1196 DOI 10.17487/RFC2119, March 1997, 1197 . 1199 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1200 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1201 . 1203 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1204 Mode with IPsec Encapsulating Security Payload (ESP)", 1205 RFC 4309, DOI 10.17487/RFC4309, December 2005, 1206 . 1208 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 1209 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 1210 UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, 1211 . 1213 [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec 1214 Extensions to Support Robust Header Compression over 1215 IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010, 1216 . 1218 12.2. Informational References 1220 [I-D.toutain-6lpwa-ipv6-static-context-hc] 1221 Minaburo, A. and L. Toutain, "6LPWA Static Context Header 1222 Compression (SCHC) for IPV6 and UDP", draft-toutain-6lpwa- 1223 ipv6-static-context-hc-01 (work in progress), June 2016. 1225 [I-D.mglt-ipsecme-implicit-iv] 1226 Migault, D., Guggemos, T., and Y. Nir, "Implicit IV for 1227 Counter-based Ciphers in IPsec", draft-mglt-ipsecme- 1228 implicit-iv-04 (work in progress), June 2017. 1230 [fit-iot-lab] 1231 "Future Internet of Things (FIT) IoT-LAB", 1232 . 1234 Appendix A. Illustrative Examples 1236 A.1. Single UDP Session IoT VPN 1238 This section considers a IoT IPv6 probe hosting a UDP application. 1239 The probe is dedicated to a single application and establishes a 1240 single UDP session. As a result, inner IP addresses and UDP Ports 1241 have a "Single" value and can be easily compressed. The probes sets 1242 an IPsec VPN using IPv6 addresses in order to connect its secure 1243 domain - typically a Home Gateway. The use of IPv6 for inner and 1244 outer IP addresses, enables to infer inner IP fields from the outer 1245 IP address. The probes encrypts with AES-CCM_8 [RFC4309]. AES-CCM 1246 does not have padding, so the padding is performed by ESP. The 1247 probes uses an 8 bit alignment which enables to fully compress the 1248 ESP Trailer. In addition, as the probe SA is indexed using the outer 1249 IP addresses (or eventually the radio identifiers) which enables to 1250 fully compress the SPI. As the probe provides information every 1251 hour, the Sequence Number using time can be derived from the received 1252 time, which enables to fully compress the SN. 1254 Figure 3 represents the original UDP packet and Figure 4 represents 1255 the corresponding packet compressed with Diet-ESP. The compression 1256 with Diet-ESP results in a reduction of 61 bytes overhead. With IPv4 1257 inner IP addressed Diet-ESP results in an 45 byte overhead reduction. 1259 Further compression may be done for example by using an implicit IV 1260 [I-D.mglt-ipsecme-implicit-iv] and by compressing the outer IP 1261 addresses (not represented) on the figure. In addition, application 1262 data may also be compressed with mechanisms outside of the scope of 1263 Diet-ESP. 1265 0 1 2 3 1266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1267 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1268 E| Security Parameters Index (SPI) | ^ 1269 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1270 P| Sequence Number (SN) | | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1272 | | | 1273 | IV | | 1274 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1275 I|version| traffic class | flow label |^ | 1276 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1277 v| payload length | next header | hop limit || | 1278 6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1279 | || a 1280 | inner source IP || u 1281 | |e t 1282 | |n h 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e 1284 | |r n 1285 | inner destination IP |y t 1286 | |p i 1287 | |t c 1288 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1289 U| source port | dest port |d t 1290 D+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1291 P| length | checksum || d 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1293 | || | 1294 ~ APPLICATION DATA ~| | 1295 | || | 1296 -| +-+-+-+-+-+-+-+-+| | 1297 E| | Padding || | 1298 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1299 P| Padding (continue) | Pad Length | Next Header |v v 1300 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1301 | Integrity Check Value-ICV (variable) | 1302 | | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 Figure 3: Standard ESP VPN Packet Description 1307 0 1 2 3 1308 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- 1310 | | ^ 1311 | IV | | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ aut 1313 | | hen 1314 ~ APPLICATION DATA ~ tic 1315 | (encrypted) | ate 1316 | +-+-+-+-+-+-+-+-+ | 1317 | | | V 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-- 1319 | Integrity Check Value-ICV (variable) | 1320 | +-+-+-+-+-+-+-+-+ 1321 | | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 Figure 4: Diet-ESP Single UDP Session IoT VPN Packet Description 1326 The following table illustrates the activated rules and the 1327 attributes of the Diet-ESP Context that needs an explicit agreement 1328 to achieve the compression. All other attributes used by the rules 1329 are part of the SA agreement. Parameters of not activated rules are 1330 left "Unspecified". 1332 +--------------+-------------------+---------------+ 1333 | EHC Rule | Context Attribute | Value | 1334 +--------------+-------------------+---------------+ 1335 | ESP_SPI | esp_spi_lsb | 0 | 1336 | ESP_SN | esp_sn_lsb | 0 | 1337 | | esp_sn_gen | "Incremental" | 1338 | ESP_NH | | | 1339 | ESP_PAD | esp_align | 8 | 1340 | | | | 1341 | IP6_OUTER | ip6_tcfl_comp | "Outer" | 1342 | | ip6_hl_comp | "Outer" | 1343 | IP6_LENGTH | | | 1344 | IP6_NH | | | 1345 | IP6_HL_OUTER | | | 1346 | IP6_SRC | | | 1347 | IP6_DST | | | 1348 | | | | 1349 | UDP_SRC | | | 1350 | UDP_DST | | | 1351 | UDP_LENGTH | | | 1352 | UDP_CHECK | | | 1353 +--------------+-------------------+---------------+ 1355 A.2. Single TCP session IoT VPN 1357 This section considers the same probe as described in Appendix A.1 1358 but instead of using UDP as a transport layer, the probe uses TCP. 1359 In this case TCP is used with no options, no urgent pointers and the 1360 SN and ACK Number are compressed to 2 bytes as the throughput is 1361 expected to be low. 1363 Figure 5 represents the original TCP packet and Figure 6 represents 1364 the corresponding packet compressed with Diet-ESP. The compression 1365 with Diet-ESP results in a reduction of 66 bytes overhead. With IPv4 1366 inner address Diet-ESP results in a 50 byte overhead reduction. 1368 0 1 2 3 1369 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1370 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1371 E| Security Parameters Index (SPI) | ^ 1372 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1373 P| Sequence Number (SN) | | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1375 | | | 1376 | IV | | 1377 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1378 I|version| traffic class | flow label |^ | 1379 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1380 v| payload length | next header | hop limit || | 1381 6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1382 | || a 1383 | inner source IP || u 1384 | |e t 1385 | |n h 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e 1387 | |r n 1388 | inner destination IP |y t 1389 | |p i 1390 | |t c 1391 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1392 T| source port | dest port |d t 1393 C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1394 P| Sequence Number (SN) || d 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1396 | ACK Sequence Number || | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1398 |Off. | Rserv | Flags | Window Size || | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1400 | Checksum | Urgent Pointer || | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1402 | || | 1403 ~ APPLICATION DATA ~| | 1404 | || | 1405 | +-+-+-+-+-+-+-+-+| | 1406 E| | Padding || | 1407 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1408 P| Padding (continue) | Pad Length | Next Header |V V 1409 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1410 | Integrity Check Value-ICV (variable) | 1411 | | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 Figure 5: Standard IoT Single TCP Session VPN Packet Description 1416 0 1 2 3 1417 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---a 1419 | | ^u 1420 | IV | |t 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|h 1422 | Sequence Number (SN) | ACK Sequence Number |^e|e 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|n 1424 | Flags | Window Size | ||c|t 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||r|i 1426 | ~|y|c 1427 ~ APPLICATION DATA ||p|a 1428 | ||t|t 1429 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|e 1430 | | |vdvd 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |--- 1432 | Integrity Check Value-ICV (variable) | 1433 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 Figure 6: Diet-ESP Single TCP Session IoT VPN Packet Description 1439 The following table illustrates the activated rules and the 1440 attributes of the Diet-ESP Context that needs an explicit agreement 1441 to achieve the compression. All other attributes used by the rules 1442 are part of the SA agreement. Parameters of not activated rules are 1443 left "Unspecified". Note for simplicity, tcp_sn and tcp_ack are 1444 negotiated to start with 0, but it could be any other value as well. 1446 +--------------+-------------------+---------------+ 1447 | EHC Rule | Context Attribute | Value | 1448 +--------------+-------------------+---------------+ 1449 | ESP_SPI | esp_spi_lsb | 0 | 1450 | ESP_SN | esp_sn_lsb | 0 | 1451 | | esp_sn_gen | "Incremental" | 1452 | ESP_NH | | | 1453 | ESP_PAD | esp_align | 8 | 1454 | | | | 1455 | IP6_OUTER | ip6_tcfl_comp | "Outer" | 1456 | | ip6_hl_comp | "Outer" | 1457 | IP6_LENGTH | | | 1458 | IP6_NH | | | 1459 | IP6_HL_OUTER | | | 1460 | IP6_SRC | | | 1461 | IP6_DST | | | 1462 | | | | 1463 | TCP_SRC | | | 1464 | TCP_DST | | | 1465 | TCP_SN | tcp_lsb | 2 | 1466 | | tcp_sn | 0 | 1467 | TCP_ACK | tcp_lsb | 2 | 1468 | | tcp_ack | 0 | 1469 | TCP_OPTIONS | tcp_options | "False" | 1470 | TCP_CHECK | | | 1471 | TCP_URGENT | tcp_urgent | "False" | 1472 +--------------+-------------------+---------------+ 1474 A.3. Traditional VPN 1476 This section illustrates the case of an company VPN. The VPN is 1477 typically set by a remote host that forwards all its traffic to the 1478 security gateway. As transport protocols are "Unspecified", 1479 compression is limited to ESP and the inner IP header. For the inner 1480 IP header, the Destination IP address is "Unspecified" so the 1481 compression of the inner IP address excludes the Destination IP 1482 address. Similarly, the inner IP Next Header cannot be compressed as 1483 the transport layer is not specified. For ESP, the security gateway 1484 may only have a sufficiently low number of remote users with 1485 relatively low throughput in which case SPI and SN can be compressed 1486 to 2 bytes. As throughput remains relatively low, the alignment may 1487 also set to 8 bits. 1489 A.3.1. IPv6 in IPv6 1491 Figure 7 represents the original TCP packet with IPv6 inner IP 1492 addresses and Figure 8 represents the corresponding packet compressed 1493 with Diet-ESP. The compression with Diet-ESP results in a reduction 1494 of 32 bytes. 1496 0 1 2 3 1497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1498 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1499 E| Security Parameters Index (SPI) | ^ 1500 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1501 P| Sequence Number (SN) | | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1503 | | | 1504 | IV | | 1505 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1506 I|version| traffic class | flow label |^ | 1507 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1508 v| payload length | next header | hop limit || | 1509 6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1510 | || a 1511 | inner source IP || u 1512 | |e t 1513 | |n h 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e 1515 | |r n 1516 | inner destination IP |y t 1517 | |p i 1518 | |t c 1519 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1520 T| source port | dest port |d t 1521 C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1522 P| Sequence Number (SN) || d 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1524 | ACK Sequence Number || | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1526 |Off. | Rserv | Flags | Window Size || | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1528 | Checksum | Urgent Pointer || | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1530 | || | 1531 ~ APPLICATION DATA ~| | 1532 | || | 1533 -| +-+-+-+-+-+-+-+-+| | 1534 E| | Padding || | 1535 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1536 P| Padding (continue) | Pad Length | Next Header |V V 1537 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1538 | Integrity Check Value-ICV (variable) | 1539 | | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 Figure 7: Standard ESP VPN Packet Description 1544 0 1 2 3 1545 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1547 | SPI | SN | ^ 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1549 | | | 1550 | IV | | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| 1552 | Next Header | |^ | 1553 +-+-+-+-+-+-+-+-+ || | 1554 | || | 1555 | inner destination IP || | 1556 | || |a 1557 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |u 1558 | | source port | dest. port ~|e|t 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|h 1560 ~ (continue) | TCP Sequence Number (SN) ~|c|e 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|r|n 1562 ~ (continue) | ACK Sequence Number (SN) ~|y|t 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|p|i 1564 ~ (continue) |Off. | Rserv | Flags | Window Size ~|t|c 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|a 1566 ~ (continue) | Checksum | Urgent ~|d|t 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |e 1568 ~ Pointer | || |d 1569 +-+-+-+-+-+-+-+-+ || | 1570 ~ APPLICATION DATA ~| | 1571 | || | 1572 | |v v 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1574 | Integrity Check Value-ICV (variable) | 1575 | | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 Figure 8: Diet-ESP VPN Packet Description 1580 The following table illustrates the activated rules and the 1581 attributes of the Diet-ESP Context that needs an explicit agreement 1582 to achieve the compression. All other attributes used by the rules 1583 are part of the SA agreement. Parameters of not activated rules are 1584 left "Unspecified". 1586 +--------------+-------------------+---------------+ 1587 | EHC Rule | Context Attribute | Value | 1588 +--------------+-------------------+---------------+ 1589 | ESP_SPI | esp_spi_lsb | 2 | 1590 | ESP_SN | esp_sn_lsb | 2 | 1591 | | esp_sn_gen | "Incremental" | 1592 | ESP_NH | | | 1593 | ESP_PAD | esp_align | 8 | 1594 | | | | 1595 | IP6_OUTER | ip6_tcfl_comp | "Outer" | 1596 | IP6_LENGTH | | | 1597 | IP6_HL_OUTER | ip6_hl_comp | "Outer" | 1598 | IP6_SRC | | | 1599 +--------------+-------------------+---------------+ 1601 A.3.2. IPv6 in IPv4 1603 If the compressed inner IP header is an IPv6, but the outer IP header 1604 is an IPv4 header, the activated rules differ, as IP6_OUTER cannot be 1605 used. Instead, ip6_tcfl_comp and ip6_hl_comp are set to "Value". 1606 The resulting ESP packet is the same as in Figure 8. 1608 +--------------+-------------------+---------------+ 1609 | EHC Rule | Context Attribute | Value | 1610 +--------------+-------------------+---------------+ 1611 | ESP_SPI | esp_spi_lsb | 2 | 1612 | ESP_SN | esp_sn_lsb | 2 | 1613 | | esp_sn_gen | "Incremental" | 1614 | ESP_NH | | | 1615 | ESP_PAD | esp_align | 8 | 1616 | | | | 1617 | IP6_VALUE | ip6_tcfl_comp | "Value" | 1618 | | ip_version | 6 | 1619 | | ip6_tc | 0 | 1620 | | ip6_fl | 0 | 1621 | IP6_LENGTH | | | 1622 | IP6_HL_OUTER | ip6_hl_comp | "Value" | 1623 | | ip6_hl | 255 | 1624 | IP6_SRC | | | 1625 +--------------+-------------------+---------------+ 1627 A.3.3. IPv4 in IPv4 1629 Figure 9 represents the original TCP packet with IPv6 inner IP 1630 addresses and Figure 10 represents the corresponding packet 1631 compressed with Diet-ESP. The compression with Diet-ESP results in a 1632 reduction of 24 bytes. 1634 0 1 2 3 1635 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1636 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1637 E| Security Parameters Index (SPI) | ^ 1638 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1639 P| Sequence Number (SN) | | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1641 | | | 1642 | IV | | 1643 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1644 I|Version| IHL |Type of Service| Total Length |^ | 1645 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1646 v| Identification |Flags| Fragment Offset || a 1647 4+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| u 1648 | Time to Live | Protocol | Header Checksum |e t 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n h 1650 | Source Address |c e 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+r n 1652 | Destination Address |y t 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+p i 1654 | Options | Padding |t c 1655 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1656 T| source port | dest port |d t 1657 C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1658 P| Sequence Number (SN) || d 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1660 | ACK Sequence Number || | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1662 |Off. | Rserv | Flags | Window Size || | 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1664 | Checksum | Urgent Pointer || | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1666 | || | 1667 ~ APPLICATION DATA ~| | 1668 | || | 1669 -| +-+-+-+-+-+-+-+-+| | 1670 E| | Padding || | 1671 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1672 P| Padding (continue) | Pad Length | Next Header |V V 1673 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1674 | Integrity Check Value-ICV (variable) | 1675 | | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 Figure 9: Standard ESP VPN Packet Description 1680 0 1 2 3 1681 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1683 | SPI | SN | ^ 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1685 | | | 1686 | IV | | 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| 1688 |Type of Service| Protocol | inner destination IP ~^ | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|| | 1690 ~ (continue) | source port || |a 1691 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |u 1692 | destination port | TCP Sequence Number (SN) ~|e|t 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|h 1694 ~ (continue) | ACK Sequence Number ~|c|e 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|r|n 1696 ~ (continue) |Off. | Rserv | Flags ||y|t 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|p|i 1698 | Window Size | Checksum ||t|c 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|a 1700 | Urgent Pointer | APPLICATION DATA ||d|t 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| |e 1702 ~ || |d 1703 | || | 1704 | |v v 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1706 | Integrity Check Value-ICV (variable) | 1707 | | 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 Figure 10: Diet-ESP VPN Packet Description 1712 The following table illustrates the activated rules and the 1713 attributes of the Diet-ESP Context that needs an explicit agreement 1714 to achieve the compression. All other attributes used by the rules 1715 are part of the SA agreement. Parameters of not activated rules are 1716 left "Unspecified". 1718 +---------------+-------------------+---------------+ 1719 | EHC Rule | Context Attribute | Value | 1720 +---------------+-------------------+---------------+ 1721 | ESP_SPI | esp_spi_lsb | 2 | 1722 | ESP_SN | esp_sn_lsb | 2 | 1723 | | esp_sn_gen | "Incremental" | 1724 | ESP_NH | | | 1725 | ESP_PAD | esp_align | 8 | 1726 | | | | 1727 | IP4_OPT_DIS | | | 1728 | IP4_LENGTH | | | 1729 | IP4_FRAG_DIS | | | 1730 | IP4_TTL_OUTER | | | 1731 | IP4_CHECK | | | 1732 | IP4_SRC | | | 1733 +---------------+-------------------+---------------+ 1735 A.3.4. IPv4 in IPv6 1737 If the compressed inner IP header is an IPv4, but the outer IP header 1738 is an IPv6 header, the activated rules differ, as IP4_TTL_OUTER 1739 cannot be used. Instead, IP4_TTL_VALUE is used. The resulting ESP 1740 packet is the same as in Figure 10. 1742 +---------------+-------------------+---------------+ 1743 | EHC Rule | Context Attribute | Value | 1744 +---------------+-------------------+---------------+ 1745 | ESP_SPI | esp_spi_lsb | 2 | 1746 | ESP_SN | esp_sn_lsb | 2 | 1747 | | esp_sn_gen | "Incremental" | 1748 | ESP_NH | | | 1749 | ESP_PAD | esp_align | 8 | 1750 | | | | 1751 | IP4_OPT_DIS | | | 1752 | IP4_LENGTH | | | 1753 | IP4_FRAG_DIS | | | 1754 | IP4_TTL_VALUE | ip4-ttl | 255 | 1755 | IP4_CHECK | | | 1756 | IP4_SRC | | | 1757 +---------------+-------------------+---------------+ 1759 Appendix B. EHC Classification (Informative) 1761 EHC Rules for Header fields depends on the property of the given 1762 field. The complete classification for all supported protocols is 1763 provided in Appendix B The current classification is based on the 1764 classification provided by ROHC (see Appendix A of [RFC5225]). 1765 However, as EHC agrees on a context out of band, not all 1766 classifications provided by ROHC are necessary and classification may 1767 end up differently. 1769 A key difference between ROHC and ESP Header Compression is that ESP 1770 needs an explicit agreement between the peers, whereas ROHC does not 1771 proceed to any out-of-band agreement. Instead ROHC learns some 1772 values by reading them from an initial packet. This learning phase 1773 is not anymore needed with ESP Header Compression as these fields can 1774 be agreed. For that reason fields classified as STATIC-DEF by ROHC 1775 becomes classified as STATIC-KNOWN for ESP Header Compression. In 1776 addition, the EHC classification also differs from the ROHC 1777 classification as EHC may be able to segment classes according to the 1778 ESP context. In that sense, EHC does not consider a single class - 1779 which is the one with the least constraints, as ROHC does. Instead, 1780 the EHC classification intends to associate the different classes to 1781 the ESP context. 1783 EHC requires these four classes, in order to classify the different 1784 header fields: 1786 STATIC-KNOWN These fields are expected to remain constant throughout 1787 the lifetime of the flow. As a result, they can be negotiated 1788 out of band and stored in a context. 1789 INFERRED These fields contain values that can be inferred from other 1790 values, for example the size of the frame carrying the packet, 1791 and thus do not have to be included in compressed packets. 1792 PATTERN These are fields that change between each packet, but change 1793 in a predictable pattern. 1794 IRREGULAR These are the fields for which no useful change pattern 1795 can be identified and should be transmitted uncompressed in all 1796 compressed packets. 1798 This section details the classification for the currently supported 1799 protocol fields. Bbeing ESP encapsulated, a given field may end up 1800 with a different classification than without encapsulation. In order 1801 to point out these differences, this section also provides for 1802 information the classification provided by ROHC. In addition, given 1803 the context associated to ESP, a given field may be classified 1804 differently. In that case, the multiple classifications are 1805 mentioned. 1807 B.1. ESP 1809 This section provides a EHC classification for the fields of the ESP 1810 protocol. 1812 +-----------------------+---------------------------+------------+ 1813 | Field | EHC Class | ROHC class | 1814 +-----------------------+---------------------------+------------+ 1815 | Security Policy Index | STATIC-KNOWN | STATIC-DEF | 1816 | Sequence Number | PATTERN | PATTERN | 1817 | Padding | INFERRED / STATIC-KNOWN | | 1818 | Pad Length | INFERRED / STATIC-KNOWN | | 1819 | Next Header | STATIC-KNOWN / IRREGULAR | | 1820 +-----------------------+---------------------------+------------+ 1822 Fields Padding, Pad Length, Next Header were not classified by ROHC 1823 because, they could not be compressed by either ROHCoverIPsec or 1824 ROHC. ROHCoverIPsec compresses protocols encapsulated by ESP. These 1825 fields are part of ESP and so cannot be compressed by ROHCoverIPsec. 1826 ROHC compresses fields sent on the wire but these fields are 1827 encrypted by ESP and so cannot be compressed by ROHC. 1829 In EHC, when present, Padding and Pad Length are INFERRED from the 1830 necessary protocol alignment, the cipher alignment and the ESP packet 1831 length before the encryption occurs. For packet with fixed size, 1832 these values will not changed during the session and as a result, may 1833 be classified as STATIC-KNOWN. Similarly, for some specific 1834 alignment values, such as 8 bit alignment, these fields may also have 1835 fixed values and thus may be classified as STATIC-KNOWN too. 1837 Next Header is STATIC-KNOWN when it is part of the TS, in which case 1838 it has been agreed between the peers. Otherwise, NH is IRREGULAR and 1839 thus cannot be compressed. 1841 B.2. IPv6 (Inner) 1843 This section provides a EHC classification for the fields of the IPv6 1844 protocol. The IPv6 address only considers the inner IP header when 1845 used in conjunction of the tunnel mode. 1847 +-------------------+--------------------------------+--------------+ 1848 | Field | EHC Class | ROHC class | 1849 +-------------------+--------------------------------+--------------+ 1850 | Version | STATIC-KNOWN | STATIC-KNOWN | 1851 | Traffic Class | STATIC-KNOWN / INFERRED / | RACH | 1852 | | IRREGULAR | | 1853 | Flow Label | STATIC-KNOWN / INFERRED / | STATIC-DEF | 1854 | | IRREGULAR | | 1855 | Payload Length | INFERRED | INFERRED | 1856 | Next Header | STATIC-KNOWN / IRREGULAR | STATIC-DEF | 1857 | Hop Limit | STATIC-KNOWN / INFERRED | RACH | 1858 | Source Address | STATIC-KNOWN | STATIC-DEF | 1859 | Destination | STATIC-KNOWN | STATIC-DEF | 1860 | Address | | | 1861 +-------------------+--------------------------------+--------------+ 1863 Traffic Class, Flow Label, Hop Limit are STATIC-KNOWN when part of 1864 the TS, in which case it has been agreed between the peers in the EHC 1865 context. Alternatively, the inner IPv6 header is INFERRED from the 1866 outer IP header if the outer IP header is an IPv6 header. In any 1867 other cases, these fields are IRREGULAR. 1869 Next Header is STATIC-KNOWN when it is part of the TS, in which case 1870 it has been agreed between the peers. Otherwise, NH is IRREGULAR and 1871 thus cannot be compressed. 1873 B.3. IPv4 (Inner) 1875 This section provides a EHC classification for the fields of the IPv6 1876 protocol. The IPv6 address only considers the inner IP header when 1877 used in conjunction of the tunnel mode. 1879 +---------------------+--------------------------+--------------+ 1880 | Field | EHC Class | ROHC class | 1881 +---------------------+--------------------------+--------------+ 1882 | Version | STATIC-KNOWN | STATIC-KNOWN | 1883 | Header Length | | | 1884 | . Options enabled | IRREGULAR | RACH | 1885 | . Options disabled | STATIC-KNOWN | STATIC-KNOWN | 1886 | Type of Service | STATIC-KNOWN | RACH | 1887 | Total Length | INFERRED | INFERRED | 1888 | Identification | | | 1889 | . Sequential | PATTERN | PATTERN | 1890 | . Seq. swap | PATTERN | PATTERN | 1891 | . Random | IRREGULAR | IRREGULAR | 1892 | . Zero | STATIC-KNOWN | STATIC-KNOWN | 1893 | Flags | STATIC-KNOWN / IRREGULAR | | 1894 | . Reserved | | STATIC-KNOWN | 1895 | . Don't Fragment | | RACH | 1896 | . More Fragment | | STATIC-KNOWN | 1897 | Fragment offset | STATIC-KNOWN / IRREGULAR | STATIC-KNOWN | 1898 | Time To Live | STATIC-KNOWN / INFERRED | INFERRED | 1899 | Protocol | STATIC-KNOWN / IRREGULAR | STATIC-DEF | 1900 | Header Checksum | INFERRED | INFERRED | 1901 | Source Address | STATIC-KNOWN | STATIC-DEF | 1902 | Destination Address | STATIC-KNOWN | STATIC-DEF | 1903 | Options | IRREGULAR | | 1904 | Padding | IRREGULAR | | 1905 +---------------------+--------------------------+--------------+ 1907 Version, Source and Destination Address and Protocol STATIC-KNOWN 1908 when part of the TS, in which case it has been agreed between the 1909 peers in the EHC context. Otherwise, they are IRREGULAR and thus 1910 cannot be compressed. 1912 Traffic Class, Flow Label, Time To Live and Flags are STATIC-KNOWN if 1913 agreed between the two peers. Otherwise the inner IPv4 header may 1914 also be inferred from the outer IP header if the outer IP header is 1915 an IPv4 header. In any other cases, these fields are IRREGULAR. 1917 Header Length depends on the options, thus when peers agree on 1918 disabling options, the Header Length becomes STATIC-KNOWN and 1919 IRREGULAR otherwise. 1921 Type of Service (DSCP and ECN) are optional and may be disabled in 1922 which case they can be classified as STATIC-KNOWN. 1924 Identification, Flags and Fragment Offset are used to deal with 1925 fragmentation. When fragmentation is disabled, these fields may be 1926 classified as STATIC-KNOWN. When fragmentation is actived, 1927 Identification may be classified as PATTERN or IRREGULAR. Flags or 1928 Fragment offset may be classified as IRREGULAR. 1930 Type of Service, Options and Padding cannot be compressed in a static 1931 way without in-band signalling, thus they are classified as 1932 IRREGULAR. 1934 B.4. UDP 1936 This section provides an EHC classification for the fields of the UDP 1937 header. 1939 +------------------+--------------------------+-------------------+ 1940 | Field | EHC Class | ROHC class | 1941 +------------------+--------------------------+-------------------+ 1942 | Source Port | STATIC-KNOWN / IRREGULAR | STATIC-DEF | 1943 | Destination Port | STATIC-KNOWN / IRREGULAR | STATIC-DEF | 1944 | Length | INFERRED | INFERRED | 1945 | Checksum | STATIC-KNOWN / INFERRED | STATIC, IRREGULAR | 1946 +------------------+--------------------------+-------------------+ 1948 Source and Destination Port are STATIC-KNOWN when part of the TS, in 1949 which case it has been agreed between the peers. Otherwise, they are 1950 IRREGULAR and thus cannot be compressed. 1952 When peers have agreed to disable UDP checksum, the checksum is 1953 always zero and so its value is STATIC-KNOWN. Otherwise the checksum 1954 needs to be computed once the packet has been decompressed. UDP 1955 checksum can be computed as ESP provides an integrity check, thus the 1956 received packet is believed to be unchanged. Note also that 1957 integrity check does not enable error correction which CRC does, but 1958 in case of a bit error encryption will fail, thus this case is 1959 considered as irrelevant. 1961 B.5. UDP-Lite 1963 This section provides an EHC classification for the fields of the 1964 UDP-Lite header. 1966 +-------------------+----------------------------------+------------+ 1967 | Field | EHC Class | ROHC class | 1968 +-------------------+----------------------------------+------------+ 1969 | Source Port | STATIC-KNOWN | STATIC-DEF | 1970 | Destination Port | STATIC-KNOWN | STATIC-DEF | 1971 | Checksum Coverage | STATIC-KNOWN / INFERRED / | IRREGULAR | 1972 | | IRREGULAR | | 1973 | Checksum | INFERRED | IRREGULAR | 1974 +-------------------+----------------------------------+------------+ 1975 See Appendix B.4 for classification of Source and Destination Port. 1977 The Checksum Coverage is the part of the UDP-Lite packet, and 1978 indicates the number of bytes covered by the checksum. The minimal 1979 value is 8, which is the UDP-Lite Header. The maximum value is the 1980 size of the UDP-Lite packet, which means that the checksum is the 1981 same as in UDP. The Coverage can be agreed to be a fixed value or a 1982 value that is function of the total length o fthe UDP packet. In 1983 these cases, Coverage can be classified as STATIC-KNOWN or INFERRED. 1984 Otherwise it is classified as IRREGULAR. 1986 In UDP-Lite the checksum cannot be disabled, but its coverage 1987 changes. Thus it will never appear as zero, but it can be INFERRED 1988 in every case, according to the value of Checksum Coverage. 1990 B.6. TCP 1992 This section provides an EHC classification for the fields of the TCP 1993 header. 1995 +------------------------+--------------+---------------------+ 1996 | Field | EHC Class | ROHC class RFC4413 | 1997 +------------------------+--------------+---------------------+ 1998 | Source Port | STATIC-KNOWN | STATIC-DEF | 1999 | Destination Port | STATIC-KNOWN | STATIC-DEF | 2000 | Sequence Number | PATTERN | CHANGING | 2001 | Acknowledgement Number | PATTERN | CHANGING | 2002 | Data Offset | | INFERRED | 2003 | . Options enabled | IRREGULAR | | 2004 | . Options disabled | STATIC-KNOWN | | 2005 | Reserved Bits | IRREGULAR | CHANGING | 2006 | Flags | IRREGULAR | CHANGING | 2007 | Window | IRREGULAR | CHANGING | 2008 | Checksum | | | 2009 | . Disabled | STATIC-KNOWN | STATIC | 2010 | . Enabled | INFERRED | IRREGULAR | 2011 | Urgent Pointer | IRREGULAR | CHANGING | 2012 | Options | IRREGULAR | CHANGING | 2013 +------------------------+--------------+---------------------+ 2015 See Appendix B.4 for classification of Source and Destination Port. 2017 The TCP Sequence and Acknowledgement Number increase in a PATTERN but 2018 caused by the different TCP-Flags the increase is not performed in 2019 every packet. 2021 Data Offset contains the length of the TCP header including the 2022 options. If options are agreed to be disabled it is STATIC-KNOWN. 2024 If Options are enabled it cannot be decompressed without in-band 2025 signalling, thus it is classified as IRREGULAR in that case. 2027 See Appendix B.4 for the checksum classification. 2029 Flags, Windows, Urgent Pointer and Options cannot be compressed 2030 without in-band signalling, thus classified as IRREGULAR in every 2031 case. 2033 Appendix C. Document Change Log 2035 [draft-mglt-6lo-diet-esp-00.txt]: 2036 Changing affiliation 2038 [draft-mglt-6lo-diet-esp-00.txt]: 2039 Updating references 2041 [draft-mglt-ipsecme-diet-esp-01.txt]: 2042 Diet ESP described in the ROHC framework 2043 ESP is not modified. 2045 [draft-mglt-ipsecme-diet-esp-00.txt]: 2046 NAT consideration added. 2047 Comparison actualized to new Version of 6LoWPAN ESP. 2049 [draft-mglt-dice-diet-esp-00.txt]: First version published. 2051 Authors' Addresses 2053 Daniel Migault (editor) 2054 Ericsson 2055 8400 boulevard Decarie 2056 Montreal, QC H4P 2N2 2057 Canada 2059 Email: daniel.migault@ericsson.com 2061 Tobias Guggemos (editor) 2062 LMU Munich 2063 Oettingenstr. 67 2064 80538 Munchen, Bavaria 2065 Germany 2067 Email: guggemos@mnm-team.org 2068 URI: http://www.mnm-team.org/~guggemos 2069 Carsten Bormann 2070 Universitaet Bremen TZI 2071 Postfach 330440 2072 Bremen D-28359 2073 Germany 2075 Phone: +49-421-218-63921 2076 Email: cabo@tzi.org