idnits 2.17.1 draft-mglt-ipsecme-diet-esp-05.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 (October 27, 2017) is 2345 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 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Guggemos 5 Expires: April 30, 2018 LMU Munich 6 C. Bormann 7 Universitaet Bremen TZI 8 October 27, 2017 10 ESP Header Compression and Diet-ESP 11 draft-mglt-ipsecme-diet-esp-05 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 https://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 April 30, 2018. 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 (https://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 . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 62 5. EHC Context . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. Diet-ESP Context Parameters for ESP . . . . . . . . . . . 6 64 5.2. EHC Context Parameters for Inner IP . . . . . . . . . . . 6 65 5.3. EHC Context Parameters for Transport Protocol . . . . . . 8 66 6. EHC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.1. EHC Rules for ESP . . . . . . . . . . . . . . . . . . . . 11 68 6.2. EHC Rules for inner IPv4 . . . . . . . . . . . . . . . . 13 69 6.3. EHC Rules for inner IPv6 . . . . . . . . . . . . . . . . 15 70 6.4. EHC Rules for UDP . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . 22 75 7.2. Inbound Packet Processing . . . . . . . . . . . . . . . . 24 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 78 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 79 11. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 29 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 82 12.2. Informational References . . . . . . . . . . . . . . . . 30 83 Appendix A. Illustrative Examples . . . . . . . . . . . . . . . 30 84 A.1. Single UDP Session IoT VPN . . . . . . . . . . . . . . . 30 85 A.2. Single TCP session IoT VPN . . . . . . . . . . . . . . . 33 86 A.3. Traditional VPN . . . . . . . . . . . . . . . . . . . . . 36 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 89 1. Requirements notation 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Introduction 97 IPsec/ESP [RFC4303] secures communications either using end-to-end 98 security or by building a VPN where the traffic is carried to a 99 secure domain via a security gateway. 101 IPsec/ESP was not designed to minimize its associated networking 102 overhead. In fact, bandwidth optimization often adds computational 103 overhead that may negatively impact large infrastructures in which 104 bandwidth usage is not a constraint. On the other hand, in IoT 105 communications, sending extra bytes can significantly impact the 106 battery life of devices and thus the life time of the device. The 107 document describes a framework that optimizes the networking overhead 108 associated to IPsec/ESP for these devices. 110 ESP Header Compression (EHC) is a framework that compresses ESP 111 protected communications. EHC is highly flexible to address any use 112 case where compression is necessary. EHC takes advantage of the 113 negotiation between the communication endpoint to agree on the 114 cryptographic parameters. In some cases, the agreement already 115 includes parameters that remain constant during the communications 116 (like layer 4 ports, or IP addresses). EHC takes advantage of these 117 already agreed parameters and defines additional parameters that 118 could be agreed for the purpose of compression. Similarly, EHC also 119 defines EHC Rules which define how fields may be compressed and 120 decompressed given the provided parameters. Finally, EHC defines EHC 121 Strategy which defines how a set of EHC Rule is coordinated. 123 The document specifies the Diet-ESP EHC Strategy and associated EHC 124 Rules. Diet-ESP compresses up to 32 bytes per packet for traditional 125 VPN and up to 66 bytes for VPN set over a single TCP or UDP session. 127 3. Terminology 129 This document uses the following terminology: 131 - EHC ESP Header Compression 132 - IoT Internet of Things 133 - IP If not stated otherwise, IP means IPv6. 134 - LSB Least Significant Bytes 135 - MSB Most Significant Bytes 136 - SAD IPsec Security Association Database 137 - SA IPsec Security Association 138 - SPD IPsec Security Policy Database 139 - TS IPsec Traffic Selector 140 - SPI ESP Security Parameter Index 141 - SN ESP Sequence Number 142 - PAD ESP Padding 143 - PL ESP Pad Length 144 - NH Next Header 145 - IV Initialization Vector 146 - IIV Implicit Initialization Vector 147 - ICV Integrity Check Value 148 - VPN Virtual Private Network 150 4. Protocol Overview 152 ESP Header Compression (EHC) compresses IPsec ESP packets, thus 153 reducing the size of the packet sent on the wire, while carrying an 154 equivalent level of information with an equivalent level of security. 156 The primarily motivation for payload size reduction were IoT related 157 use cases, were the cost of sending extra bytes largely overcomes 158 additional computations and thus considerably reduces the life time 159 of battery powered devices. As a result, IoT communication rather 160 favors expensive compression over additional bandwidth. Standard 161 IPsec VPN may also consider reduction of their bandwidth, but on the 162 other hand, the acceptable computation overhead must remain very low. 163 The ESP Header Compression designated in this document together with 164 the EHC Strategy named Diet-ESP attempts to reach both of these two 165 goals. 167 ESP Header Compression compresses the standard ESP payload by 168 compressing different fields with specific compression rules 169 performed in the ESP stack. Concerned fields include those of the 170 ESP protocol, as well as other protocols in the ESP payload such as 171 the IP header when the tunnel mode is used, the UDP or the TCP 172 header. In fact non ESP fields may be compressed by ESP under 173 certain circumstances and ESP Header Compression is not intended to 174 provide a generic way outside of ESP to compress these protocols. 175 Further compression of the ESP payload may be performed by generic 176 mechanism and outside ESP with more generic mechanisms such as for 177 example ROHCoverIPsec [RFC5858] or SCHC 178 [I-D.toutain-6lpwa-ipv6-static-context-hc] which are orthogonal to 179 ESP Header Compression. 181 As depicted in Figure 1, in order to compress the ESP packets, the 182 two peers are expected to agree on the EHC Strategy - Diet-ESP in our 183 case - as well as some extra parameters needed to derive the EHC 184 Rules and EHC Context. 186 EHC Strategy, EHC Strategy, 187 EHC Context <==================> EHC Context 188 | | 189 EHC Rules | EHC Rules | 190 | | | | 191 v v v v 192 +====================+ +====================+ 193 | ESP | | ESP | 194 +====================+ +====================+ 195 | < pre-esp > | | < pre-esp > | 196 +--------------------+ +--------------------+ 197 | < clear text esp > | | < clear text esp > | 198 +--------------------+ +--------------------+ 199 | < encryption > | | < encryption > | 200 +--------------------+ +--------------------+ 201 | < post-esp > | | < post-esp > | 202 +--------------------+ +--------------------+ 204 Figure 1: ESP Header Compression Overview 206 In Figure 1, the ESP stack is represented by various sub layers 207 describing the packet processing inside the ESP. The "pre-esp" layer 208 represents treatment performed to a non ESP packet, i.e. before ESP 209 encapsulation or decapsulation is being proceeded. "clear text esp" 210 designates the ESP encapsulation / decapsulation processing performed 211 on an non encrypted ESP packet. "encryption" designates the 212 encryption/decryption phase and "post-esp" the processing performed 213 on an ESP encrypted packet. EHC Rules may be processed at any of 214 these layers - except for "encryption" layer, and thus impact 215 differently the standard ESP. More specifically, EHC Rules performed 216 at the "pre-esp" or "post-esp" layer does not require the current ESP 217 stack to be updated and can simply be appended to the current ESP 218 stack. On the other hand, EHC Rules at the "clear text esp" may 219 require modification of the current ESP stack. 221 The set of EHC rules described in this document as well as the EHC 222 Strategies may be extended in the future. Nothing prevents such EHC 223 Rules and Strategies to be updated. 225 5. EHC Context 227 The EHC Context provides the necessary information so the two peers 228 can proceed to the appropriated compression and decompression defined 229 by the EHC Strategy. As this document is limited to the Diet-ESP 230 strategy, the EHC Context in this section is also designated as Diet- 231 ESP Context and is used by the Diet-ESP Strategy to activate specific 232 EHC Rules as well as to execute the EHC Rule by providing the 233 necessary parameters.. 235 The Diet-ESP Context is defined on a per-SA basis. It is composed of 236 attributes that are not Diet-ESP specific, as well as attributes that 237 are Diet-ESP specific. Attributes that are not Diet-ESP specific are 238 already stored in some form in the SA (e.g. IP addresses in the 239 Traffic Selector). Such attributes are designated by "Yes" in the 240 "In SA" column. Diet-ESP specific attributes may need to be 241 specified so Diet-ESP can be executed properly. 243 5.1. Diet-ESP Context Parameters for ESP 245 +-------------------+-------+--------------------------+ 246 | Context Attribute | In SA | Possible Values | 247 +-------------------+-------+--------------------------+ 248 | ipsec_mode | Yes | "Tunnel", "Transport" | 249 | outer_version | Yes | "IPv4", "IPv6" | 250 | esp_spi | Yes | ESP SPI | 251 | esp_spi_lsb | No | 0, 1, 2, 3, 4 | 252 | esp_sn | Yes | ESP Sequence Number | 253 | esp_sn_lsb | No | 0, 1, 2, 3, 4 | 254 | esp_sn_gen | No | "Time", "Incremental" | 255 | esp_align | No | 8, 16, 24, 32 | 256 | esp_encr | Yes | ESP Encryption Algorithm | 257 +-------------------+-------+--------------------------+ 259 5.2. EHC Context Parameters for Inner IP 261 Parameters associated to the Inner IP addresses are only specified 262 when the SA has been configured with the tunnel mode. As a result 263 when ipsec_mode is set to "Transport" the parameters below MUST NOT 264 be considered and are considered as "Undefined" 266 +-------------------+-------+-----------------+ 267 | Context Attribute | In SA | Possible Values | 268 +-------------------+-------+-----------------+ 269 | ip_version | Yes | "IPv4", "IPv6" | 270 +-------------------+-------+-----------------+ 272 5.2.1. EHC Context Parameters for inner IPv6 273 +-------------------+-------+------------------------------+ 274 | Context Attribute | In SA | Possible Values | 275 +-------------------+-------+------------------------------+ 276 | ip6_tcfl_comp | No | "Outer", "Value", "UnComp" | 277 | ip6_tc | No | IPv6 Traffic Class | 278 | ip6_fl | No | IPv6 Flow Label | 279 | ip6_hl_comp | No | "Outer", "Value", "UnComp" | 280 | ip6_hl | No | Hop Limit Value | 281 | ip6_src | Yes | IPv6 Source Address | 282 | ip6_dst | Yes | IPv6 Destination Address | 283 +-------------------+-------+------------------------------+ 285 ip6_tcfl_comp indicates how Traffic Class and Flow Label fields of 286 the inner IP Header are expected to be compressed. "Outer" indicates 287 Traffic Class and Flow Label are read from the outer IP header, 288 "Value" indicates these values are provided by the Diet-ESP Context, 289 while "Uncompress" indicates that no compression occurs and these 290 values are read in the inner IP inner header. 292 ip6_hl_comp indicates how Hop Limit field of the inner IP Header is 293 expected to be compressed. (see ip6_tcfl_comp). 295 ip6_dst designates the Destination IPv6 Address of the inner IP 296 header. The IP address is provided by the TS, and can be defined as 297 a range of IP addresses. Compression is only considered when ip6_dst 298 indicates a single IP Address. When the TS defines more than a 299 single IP address ip6_dst is considered as "Unspecified" and its 300 value MUST NOT be considered for compression. 302 5.2.2. EHC Context Parameters for inner IPv4 304 +-------------------+-------+------------------------------+ 305 | Context Attribute | In SA | Possible Values | 306 +-------------------+-------+------------------------------+ 307 | ip4_options | No | "Options", "No_Options" | 308 | ip4_id | No | IPv4 Identification | 309 | ip4_id_lsb | No | 0,1,2 | 310 | ip4_ttl_comp | No | "Outer", "Value", "UnComp" | 311 | ip4_ttl | No | IPv4 Time To Live | 312 | ip4_src | Yes | IPv4 Source Address | 313 | ip4_dst | Yes | IPv4 Destination Address | 314 | ip4_frag_enable | No | "True", "False" | 315 +-------------------+-------+------------------------------+ 317 ip4_options specifies if the IPv4 header contains any options. If 318 set to "No_Options", the first 8 bit of the IPv4 header (being the IP 319 version and IP header length) are compressed. If set to "Options" 320 this bits are sent uncompressed. 322 ip4_ttl indicates how the Time To Live field of the inner IP Header 323 is expected to be compressed. (see ip6_hl_comp). 325 5.3. EHC Context Parameters for Transport Protocol 327 The following parameters are provided by the SA but the SA may 328 specify single value or a range of values. When the SA specifies a 329 range of values, these parameters MUST NOT be considered and are 330 considered as Unspecified. 332 +-------------------+-------+------------------------------------+ 333 | Context Attribute | In SA | Possible Values | 334 +-------------------+-------+------------------------------------+ 335 | l4_proto | Yes | IPv6/ESP Next Header,IPv4 Protocol | 336 | l4_src | Yes | UDP/UDP-Lite/TCP Source Port | 337 | l4_dst | Yes | UDP/UDP-Lite/TCP Destination Port | 338 +-------------------+-------+------------------------------------+ 340 5.3.1. EHC Context Parameters for UDP 342 For UDP, there are no additional parameters necessary than the ones 343 in Section 5.3 345 5.3.2. EHC Context Parameters for UDP-Lite 347 +-------------------+-------+-----------------------------------+ 348 | Context Attribute | In SA | Possible Values | 349 +-------------------+-------+-----------------------------------+ 350 | udplite_coverage | No | 8-16535, "Length", "uncompressed" | 351 +-------------------+-------+-----------------------------------+ 353 udplite_coverage: For UDP-Lite, the checksum can have different 354 coverages, which is defined by the "Checksum Coverage" field which 355 replaces the "Length" field of UDP. This context field defines the 356 coverage in advance by either a specific value (8-16535), the actual 357 length of the UDP-Lite payload ("Length" or 0) or as uncompressed. 358 Note that udplite coverage is indicated on a packet basis and cannot 359 be greater than the UDP length. In this case udplite_coverage is 360 negotiated for all packets and the actual coverage for a given UDP 361 packet is derived as the minimum value between udplite_coverage and 362 the length of the UDP packet. 364 5.3.3. EHC Context Parameters for TCP 365 +-------------------+-------+---------------------------+ 366 | Context Attribute | In SA | Possible Values | 367 +-------------------+-------+---------------------------+ 368 | tcp_sn | No | TCP Sequence Number | 369 | tcp_ack | No | TCP Acknowledgment Number | 370 | tcp_lsb | No | 0, 1, 2, 3, 4 | 371 | tcp_options | No | "True", "False" | 372 | tcp_urgent | No | "True", "False" | 373 +-------------------+-------+---------------------------+ 375 tcp_sn holds the current Sequence Number of the TCP session. 377 tcp_ack holds the current Acknowledgement Number of the TCP session. 379 tcp_lsb holds the number of lsb of tcp_sn and tcp_ack sent on the 380 wire. 382 tcp_options says if options are enabled in the current TCP session. 383 If tcp_options is set to "False" the Options field in TCP can be 384 elided. 386 tcp_urgent says if the urgent pointer is enabled in the current TCP 387 session. If tcp_urgent is set to "False" the Urgent Pointer field in 388 TCP can be elided. 390 6. EHC Rules 392 This section describes the EHC Rules involved in Diet-ESP. The EHC 393 Rules defined by Diet-ESP may be used in the future by EHC Strategies 394 other than Diet-ESP, so they are described in an independent way. 396 A EHC Rule defines the compression and decompression of one or more 397 fields and EHC Rules are represented this way: 399 +---------------+-------+---------+----------------+ 400 | EHC Rule | Field | Action | Parameters | 401 +---------------+-------+---------+----------------+ 402 | | f1 | a1 | p1_1, ... p1_n | 403 | +-------+---------+----------------+ 404 | EHC_RULE_NAME ~ ... ~ 405 | +-------+---------+----------------+ 406 | | fm | am | pm_1, ... pm_n | 407 +---------------+-------+---------+----------------+ 409 Figure 2: EHC Rules 411 The EHC Rule is designated by a name (EHC_RULE_NAME) and the 412 concerned Fields (f1, ..., fm). Each field compression and 413 decompression is represented by an Action (a1, ..., am). The 414 Parameters indicate the necessary parameters for the action to 415 perform both the compression and the decompression. 417 The table below provides a high level description of the Actions used 418 by Diet-ESP. As these Action may take different arguments and may 419 operate differently for each field a compete description is provided 420 in the next sections as part of the EHC Rule description. 422 +-----------------+-----------------+----------------------+ 423 | Function | Compression | Decompression | 424 +-----------------+-----------------+----------------------+ 425 | send-value | No | No | 426 | elided | Not send | Get from EHC Context | 427 | lsb(_lsb_size) | Sent LSB | Get from EHC Context | 428 | lower | Not send | Get from lower layer | 429 | checksum | Not send | Compute checksum. | 430 | padding(_align) | Compute padding | Get padding | 431 +-----------------+-----------------+----------------------+ 433 a. send-value designates an action that does not perform any 434 compression or decompression of a field. 435 b. elided designates an action where both peers have a local value 436 of the field. The compression of the field consists in removing 437 the field, and the decompression consists in retrieving the field 438 value from a known local value. The local value may be stored in 439 a EHC Context or defined by the EHC Rule (like a zero value for 440 example). 441 c. lsb designates an action where both peers have a local value of 442 the field, but the compression consists in sending only the LSB 443 bytes instead of the whole field. The decompression consists in 444 retrieving the field from the LSB sent as well as some other 445 additional local values. 446 d. lower designates an action where the compression consists in not 447 sending the field. The decompression consists in retrieving the 448 field from the lower layers of the packet. A typical example is 449 when both IP and UDP carry the length of the payload, then the 450 length of the UDP payload can be inferred from the one of the IP 451 layer. 452 e. checksum designates an action where the compression consists in 453 not sending a checksum field. The decompression consists in re- 454 computing the checksum. ESP provides an integrity-check based on 455 signature of the ESP payload (ICV). This makes removing checksum 456 possible, without harming the checksum mechanism. 457 f. padding designates an action that computes the padding of the ESP 458 packet. The function is specific to the ESP. 460 For all actions, the function can be performed only when the 461 appropriated parameters and fields are provided. When a field or a 462 parameters does not have an appropriated value its value is 463 designated as "Unspecified". Specifically some fields such as inner 464 IP addresses, ports or transport protocols are agreed during the SA 465 negotiation and are specified by the SA. Their value in the SA may 466 take various values that are not appropriated to enable a 467 compression. For example, when these fields are defined as a range 468 of values, or by selectors such as OPAQUE or ANY these fields cannot 469 be retrieved from a local value. Instead, when they are defined as a 470 "Single" value (i.e a single IP address, or a single port number or a 471 single transport protocol number) compression and decompression can 472 be performed. These SA related fields are considered as 473 "Unspecified" when not limited to a "Single" value. 475 When a field or a parameter is "Unspecified", the EHC Rule MUST NOT 476 be activated. This is the purpose of the EHC Strategy to avoid 477 ending in such case. In any case, when one of these condition is not 478 met, the EHC Rule MUST NOT perform any compression or decompression 479 action and the packet MUST be discarded. When possible, an error 480 SHOULD be raised and logged. 482 6.1. EHC Rules for ESP 484 This section describes the EHC Rules for ESP which are summed up in 485 the table below. 487 +---------+-------------------+---------+---------------------------+ 488 | EHC | Field | Action | Parameters | 489 | Rule | | | | 490 +---------+-------------------+---------+---------------------------+ 491 | ESP_SPI | SPI | lsb | esp_spi_lsb, esp_spi | 492 | ESP_SN | Sequence Number | lsb | esp_sn_lsb, esp_sn_gen, | 493 | | | | esp_sn | 494 | ESP_NH | Next Header | elided | l4_proto, ipsec_mode | 495 | ESP_PAD | Pad Length, | padding | esp_align, esp_encr | 496 | | Padding | | | 497 +---------+-------------------+---------+---------------------------+ 499 ESP_SPI designates the EHC Rule compressing / decompressing the SPI. 500 ESP_SPI is performed in the "post-esp" phase. The SPI is compressed 501 using "lsb". The sending peer only places the LSB bytes of the SPI 502 and the receiving peer retrieve the SPI from the LSB bytes carried in 503 the packets as well as from the SPI value stored in the SA. The SPI 504 MUST be retrieved as its full value is included in the signature 505 check. The two peers MUST agree on the number of LSB bytes to be 506 sent: "esp_spi_lsb". Upon agreeing on "esp_spi_lsb", the receiving 507 peer MUST NOT agree on a value not carrying sufficient information to 508 retrieve the full SPI. 510 ESP_SN designates the EHC Rule compressing / decompressing the ESP 511 Sequence Number. ESP_SN is performed in the "post-esp" phase. 512 ESP_SN is only activated if the SN ("esp_sn"), the LSB significant 513 bytes ("esp_sn_lsb") and the method used to generate the SN 514 ("esp_sn_gen") are defined. The Sequence Number is compressed using 515 "lsb". Similarly to the SPI, the Sequence Number MUST be retrieved 516 in order to complete the signature check of the ESP packet. Unlike 517 the SPI, the Sequence Number is not agreed by the peers, but is 518 changing for every packet. As a result, in order to retrieve the 519 Sequence Number from the LSB "esp_sn_lsb", the peers MUST agree on 520 generating Sequence Number in a similar way. This is negotiated with 521 "esp_sn_gen" and the receiver MUST ensure that "esp_sn_lsb" is big 522 enough to absorb minor packet losses or time differences between the 523 peers. 525 ESP_NH designates the EHC Rule compressing / decompressing the ESP 526 Next Header. ESP_NH is performed in the "clear text esp" phase. 527 ESP_NH is only activated if the Next Header is specified. The Next 528 Header can be specified as IP (IPv4 or IPv6) when the IPsec tunnel 529 mode is used ("ipsec_mode" set to "Tunnel") or when the transport 530 mode ("ipsec_mode" set to "Transport") is used when the Traffic 531 Selector defines a "Single" Protocol ID ("l4_proto"). The Next 532 Header, is compressed using "elided". The Next Header indicates the 533 Header in the Payload Data. When the Tunnel mode is chosen, the type 534 of the header is known to be an IP header. Similarly, the TS may 535 also hold transport layer protocol, which specifies the Next Header 536 value for Transport mode. The Next Header value is only there to 537 provide sufficient information for decapsulating ESP. In other words 538 decompressing this fields would occur in the "clear text esp" phase 539 and striped but directly removed again by the ESP stack. For these 540 reasons, implementation may simply omit decompressing this field. 542 ESP_PAD designates the EHC Rule compressing / decompressing the Pad 543 Length and Padding fields. ESP_PAD is performed in the "clear text 544 esp" phase. Pad Length and Padding define the padding. The purpose 545 of padding is to respect a 32 bit alignment for ESP or block sizes of 546 the used cryptographic suite. As the ESP trailer is encrypted, 547 Padding and Pad Length MUST to be performed by ESP and not by the 548 encryption algorithm. Thus, ESP_PAD always needs to respect the 549 cipher alignment ("esp_encr"), if applicable. Compression may be 550 performed especially when device support alignment smaller than 32 551 bit. Such alignment is designated as "esp_align" and the padding 552 bytes are the necessary bytes so the ESP packet has a length that is 553 a multiple of "esp_align". 555 When "esp_align" is set to an 8-bit alignment padding bytes are not 556 necessary, and Padding as well as Pad Length are removed. For values 557 that are different from 8-bit alignment, padding bytes needs to be 558 computed according to the ESP packet length why ESP_PAD MUST be the 559 last action of "clear text esp". The resulting number of padding 560 byte is then expressed in Padding and Pad Length fields with Pad 561 Length set to padding bytes number - 1 and Padding is generated as 562 described in [RFC4303]. 564 Combining the Pad Length and Padding fields could potentially add an 565 overhead on fixed size padding. In fact some applications may only 566 send the same type of fixed size data, in which case the Pad Length 567 would not be necessary to be specified. However, the only corner 568 case Pad Length fields would actually add an overhead is when padding 569 is expected to be of zero size. In this case, specifying an 8-bit 570 alignment solve this issue. 572 6.2. EHC Rules for inner IPv4 574 All IPv4 EHC Rules MUST be performed during the "clear text esp" 575 phase. The EHC Rules are only defined for compressing the inner IPv4 576 header and thus can only be used when the SA is using the Tunnel 577 mode. 579 +---------------+-----------------+----------+--------------------+ 580 | EHC Rule | Field | Action | Parameters | 581 +---------------+-----------------+----------+--------------------+ 582 | IP4_OPT_DIS | Version | elided | ip_version | 583 | | Header Length | elided | | 584 | IP4_LENGTH | Total Length | lower | | 585 | IP4_ID | Identification | lsb | ip4_id, ip4_id_lsb | 586 | IP4_FRAG_DIS | Flags | elided | | 587 | | Fragment Offset | elided | | 588 | IP4_TTL_OUTER | Time To Live | elided | ip4_ttl | 589 | IP4_TTL_VALUE | Time To Live | elided | ip4_ttl | 590 | IP4_PROT | Protocol | elided | l4_proto | 591 | IP4_CHECK | Header Checksum | checksum | | 592 | IP4_SRC | Source Address | elided | ip4_src | 593 | IP4_DST | Dest. Address | elided | ip4_dst | 594 +---------------+-----------------+----------+--------------------+ 596 IP4_OPT_DIS designates that the IPv4 header does not include any 597 options and indicates if the first byte of the IPv4 header - 598 consisting of IP version and IPv4 Header Length, are compressed. The 599 Version "ip_version" is defined by the SA and is thus compressed 600 using "elided". If the header does not contain any options, it is 601 compressed with "elided" and decompressed to "20", the default length 602 of the IPv4 header. If the header does contains some options, the 603 length is not compressed. 605 IP4_LENGTH designates the EHC Rule compressing / decompressing the 606 Total Length Field of the inner IPv4 header. The Total Length is 607 compressed by the sender and not sent. The receiver decompresses it 608 by recomputing the Total Length from the outer IP header. The outer 609 IP header can be IPv4 or IPv6 and IP4_LENGTH MUST support both 610 versions if both versions are supported by the device. Note that the 611 length of the inner IP payload may also be subject to updates if 612 decompression of the upper layers occurs. 614 IP4_ID designates the EHC Rule compressing / decompressing the 615 Identification Field. IP4_ID is only activated if the ID ("ip4_id"), 616 the LSB significant bytes ("ip4_id_lsb") are defined. Upon agreeing 617 on "ip4_id_lsb", the receiving peer MUST NOT agree on a value not 618 carrying sufficient information to retrieve the full IP 619 Identification. Note also that unlike the ESP SN, the IPv4 620 Identification is not part of the SA. As a result, when the ID is 621 compressed, its value MUST be stored in the EHC Context. The 622 reserved attribute for that is "ip4_id" 624 IP4_FRAG_DIS designates that the inner IPv4 header does not support 625 fragmentation. If activated, IP4_FRAG_DIS indicates compression of 626 Flags and Fragment Offset field in the IPv4 header which consists of 627 2 bytes. Both fields are compressed with "elided" and decompressed 628 with their default value according to [RFC0791], which is 0b010 for 629 Flags and 0 for Fragment Offset. 631 IP4_TTL_OUTER designates an EHC Rule compressing / decompressing the 632 Time To Live field of the inner IP header. If the outer IP header is 633 an IPv6 header, the Hop Limit is used for decompression. The Time To 634 Live field is compressed / decompressed using "lower", thus the field 635 is not sent. The receiver decompresses it by reading its value from 636 the outer IP header (TTL in case of IPv4 or HL in case of IPv6). 638 IP4_TTL_VALUE designates an EHC Rule compressing / decompressing the 639 Time To Live field of the inner IP header. IP4_TTL_VALUE is only 640 activated when the Hop Limit ("ip4_ttl") has been agreed. Time To 641 Live is compressed / decompressed using the "elided" method. 643 IP4_PROTO designates the EHC Rule compressing / decompressing the 644 Protocol field of the inner IPv4 header. IP4_PROTO is only activated 645 if the Protocol is specified, that is when the Traffic Selectors 646 defines a "Single" Protocol ID ("l4_proto"). When the Protocol ID 647 identified by the SA has a "Single" value, the Protocol is compressed 648 and decompressed using the "elided" method. 650 IP4_CHECK designates the EHC rule compressing / decompressing the 651 Header Checksum field of the inner IPv4 header. The IPv4 header 652 checksum is not sent by the sender and the receiver computes from the 653 decompressed inner IPv4 header. IP4_CHECK MUST compute the checksum 654 and not fill the checksum field with zeros. As a result, IP4_CHECK 655 is the last decompressing EHC Rule to be performed on the 656 decompressed IPv4 header. 658 IP4_SRC compresses the source IP address of the inner IPv4 header. 659 IP4_SRC_IP is only be activated when the Traffic Selectors agreed by 660 the SA defines a "Single" source IP address ("ip4_src"). The Source 661 IP address is compressed / decompressed using the "elided" method. 663 IP4_DST works in a similar way as IP4_SRC_IP but for the destination 664 IP address ("ip4_dst") 666 6.3. EHC Rules for inner IPv6 668 All IPv6 EHC Rules MUST be performed during the "clear text esp" 669 phase. The EHC Rules are only defined for compressing the inner IPv6 670 header and thus can only be used when the SA is using the Tunnel 671 mode. 673 +--------------+----------------+--------+------------+ 674 | EHC Rule | Field | Action | Parameters | 675 +--------------+----------------+--------+------------+ 676 | IP6_OUTER | Version | elided | ip_version | 677 | | Traffic Class | lower | | 678 | | Flow Label | lower | | 679 | IP6_VALUE | Version | elided | ip_version | 680 | | Traffic Class | elided | ip6_tc | 681 | | Flow Label | elided | ip6_fl | 682 | IP6_LENGTH | Payload Length | lower | | 683 | IP6_NH | Next Header | elided | l4_proto | 684 | IP6_HL_OUTER | Hop Limit | lower | | 685 | IP6_HL_VALUE | Hop Limit | elided | ip6_hl | 686 | IP6_SRC | Source Address | elided | ip6_src | 687 | IP6_DST | Dest. Address | elided | ip6_dst | 688 +--------------+----------------+--------+------------+ 690 IP6_OUTER designates an EHC Rule for compressing / decompressing the 691 first 32 bits of the inner IPv6 header formed by the Version, Traffic 692 Class and Flow Label. IP6_OUTER only proceeds to compression when 693 both the outer and inner IP header are IPv6 header. When the outer 694 IP header is an IPv4, the compression is bypassed. Bypassing enables 695 to proceed to compression of IPv4 and IPv6 traffic in a VPN use case 696 with a single SA. The Version "ip_version" is defined by the SA and 697 is thus compressed using "elided". The other parameters Traffic 698 Class and Flow Label are compressed using "lower". More 699 specifically, the fields are not sent. The receiver decompresses 700 them by reading their value from the outer IPv6 header. 702 IP6_VALUE designates an EHC Rule for compressing / decompressing the 703 first 32 bits of the inner IPv6 header formed by the Version, Traffic 704 Class and Flow Label. IP6_VALUE is only activated if the Version of 705 the inner IP header agreed by the SA is set to "Version 6" 706 ("ip_version" set to "Version 6") and the specific values of the 707 Traffic Class ("ip6_tc") and the Flow Label ("ip6_fl") are specified. 708 With IP6_VALUE all fields are compressed and decompressed using 709 "elided". Version is provided by the SA ("ip_version") while other 710 fields are explicitly provided (ip6_tc, ip6_fl. 712 IP6_LENGTH designates the EHC Rule compressing / decompressing the 713 Payload Length Field of the inner IPv6 header. The Payload Length is 714 compressed by the sender and is not sent. The receiver decompress it 715 by recomputing the Payload Length from the outer IP header. The IP 716 header can be IPv4 or IPv6 and IP6_LENGTH MUST support both versions 717 if both versions are supported by the device. Note that the length 718 of the inner IP payload may also be subject to updates if 719 decompression of the upper layers occurs. 721 IP6_NH designates the EHC Rule compressing / decompressing the Next 722 Header field of the inner IPv6 header. IP6_NH is only activated if 723 the Next Header is specified, that is when the Traffic Selectors 724 defines a "Single" Protocol ID ("l4_proto"). When the Protocol ID 725 identified by the SA has a "Single" value, the Next Header is 726 compressed and decompressed using the "elided" method. 728 IP6_HL_OUTER designates an EHC Rule compressing / decompressing the 729 Hop Limit field of the inner IP header. If the outer IP header is an 730 IPv4 header, the Time To Live is used for decompression. The Hop 731 Limit field is compressed / decompressed using the "lower". More 732 specifically, the fields are not sent. The receiver decompresses 733 them by reading their value from the outer IPv6 header. 735 IP6_HL_VALUE designates an EHC Rule compressing / decompressing the 736 Hop Limit field of the inner IP header. IP6_HL_VALUE is only 737 activated when the Hop Limit ("ip6_hl") has been agreed. The Hop 738 Limit is compressed / decompressed using the "elided" method. 740 IP6_SRC compresses the source IP address of the inner IP header. 741 IP6_SRC_IP is only be activated when the Traffic Selectors agreed by 742 the SA defines a "Single" source IP address ("ip6_src"). The Source 743 IP address is compressed / decompressed using the "elided" method. 745 IP6_DST works in a similar way as IP6_SRC_IP but for the destination 746 IP address ("ip6_dst") 748 6.4. EHC Rules for UDP 750 All UDP EHC Rules MUST be performed during the "pre-esp" phase. The 751 EHC Rules are only defined when the Traffic Selectors agreed during 752 the SA negotiation results in "Single" Protocol ID ("l4_proto") which 753 is set to UDP (17). 755 +------------+--------------+----------+------------+ 756 | EHC Rule | Field | Action | Parameters | 757 +------------+--------------+----------+------------+ 758 | UDP_SRC | Source Port | elided | l4_source | 759 | UDP_DST | Dest. Port | elided | l4_dest | 760 | UDP_LENGTH | Length | lower | | 761 | UDP_CHECK | UDP Checksum | checksum | | 762 +------------+--------------+----------+------------+ 764 UDP_SRC designates the EHC Rule that compresses / decompresses the 765 UDP Source Port. UDP_SRC is only activated when the Source Port 766 agreed by the SA negotiation ("l4_src") is "Single". The Source Port 767 is then compressed / decompressed using the "elided" method. 769 UDP_DST works in a similar way as UDP_SRC but for the Destination 770 Port ("l4_dst"). 772 UDP_LENGTH designates the EHC Rule compressing / decompressing the 773 Length Field of the UDP header. The length is compressed by the 774 sender and is not sent. The receiver decompresses it by recomputing 775 the Length from the IP address header. The IP address can be IPv4 or 776 IPv6 and UDP_LENGTH MUST support both versions if both versions are 777 supported by the device. 779 UDP_CHECK designates the EHC Rule compressing / decompressing the UDP 780 Checksum. The UDP Checksum is not sent by the sender and the 781 receiver computes from the decompressed UDP payload. UDP_CHECK MUST 782 compute the checksum and not fill the checksum field with zeros. As 783 a result, UDP_CHECK is the last decompressing EHC Rule to be 784 performed on the decompressed UDP Payload. 786 6.5. EHC Rules for UDP-Lite 788 All UDP-lite EHC Rules MUST be performed during the "pre-esp" phase. 789 The EHC Rules are only defined when the Traffic Selectors agreed 790 during the SA negotiation results in a "Single" Protocol ID 791 ("l4_proto") which is set to UDPLite (136). 793 +-------------------+-----------------+----------+------------------+ 794 | EHC Rule | Field | Action | Parameters | 795 +-------------------+-----------------+----------+------------------+ 796 | UDP-LITE_SRC | Source Port | elided | l4_source | 797 | UDP-LITE_DST | Dest. Port | elided | l4_dest | 798 | UDP-LITE_COVERAGE | Checksum | elided | udplite_coverage | 799 | | Coverage | | | 800 | UDP-LITE_CHECK | UDP-Lite | checksum | | 801 | | Checksum | | | 802 +-------------------+-----------------+----------+------------------+ 804 UDP-LITE_SRC works similarly to UDP_SRC 806 UDP-LITE_DST works similarly to UDP_DST 808 UDP-LITE_COVERAGE designates the EHC Rule compressing / decompressing 809 the UDP-Lite Coverage field. UDP-LITE_COVERAGE is only activated 810 when the Coverage ("udplite_coverage") has been agreed with a valid 811 value. The Coverage is compressed / decompressed using the "elided" 812 method. 814 UDP-LITE_CHECK designates the EHC Rule compressing / decompressing 815 the UDP-Lite checksum. UDP-LITE_CHECK is only activated if the 816 Coverage is defined either elided or sent. UDP-LITE_CHECK computes 817 the checksum using "checksum" according to the uncompressed UDP 818 packet and the value of the Coverage. 820 6.6. EHC Rules for TCP 822 All TCP EHC Rules MUST be performed during the "pre-esp" phase. The 823 EHC Rules are only defined when the Traffic Selectors agreed during 824 the SA negotiation results in a"Single" Protocol ID ("l4_proto") 825 which is set to TCP (6). 827 +-------------+-----------------------+----------+------------------+ 828 | EHC Rule | Field | Action | Parameters | 829 +-------------+-----------------------+----------+------------------+ 830 | TCP_SRC | Source Port | elided | l4_source | 831 | TCP_DST | Dest. Port | elided | l4_dest | 832 | TCP_SN | Sequence Number | lsb | tcp_sn, tcp_lsb | 833 | TCP_ACK | Acknowledgment Number | lsb | tcp_ack, tcp_lsb | 834 | TCP_OPTIONS | Data Offset | elided | tcp_options | 835 | | Reserved Bits | elided | | 836 | TCP_CHECK | TCP Checksum | checksum | | 837 | TCP_URGENT | TCP Urgent Field | elided | tcp_urgent | 838 +-------------+-----------------------+----------+------------------+ 840 TCP_SRC works similarly to UDP_SRC. 842 TCP_DST works similarly to UDP_DST. 844 TCP_SN designates the EHC Rule compressing / decompressing the TCP 845 Sequence Number. TCP_SN is only activated if the SN ("tcp_sn") and 846 the LSB significant bytes ("tcp_lsb") are defined. The TCP SN is 847 compressed using "lsb". The sending peer only places the LSB bytes 848 of the TCP SN ("tcp_sn") and the receiving peer retrieve the TCP SN 849 from the LSB bytes carried in the packets as well as from the TCP SN 850 value stored in EHC Context ("tcp_sn"). The two peers MUST agree on 851 the number of LSB bytes to be sent: "tcp_lsb". Upon agreeing on 852 "tcp_lsb", the receiving peer MUST NOT agree on a value not carrying 853 sufficient information to retrieve the full TCP SN. Note also that 854 unlike the ESP SN, the TCP SN is not part of the SA. As a result, 855 when the SN is compressed, the value of the TCP SN MUST be stored in 856 the EHC Context. The reserved attribute for that is "tcp_sn" 858 TCP_ACK designates the EHC Rule compressing / decompressing the TCP 859 Acknowledgment Number and works similarly to TCP SN. Note that 860 "tcp_lsb" is agreed for both TCP SN and TCP Acknowledgment. 861 Similarly the value of the complete TCP Acknowledgment Number MUST be 862 stored in the "tcp_ack" attribute of the EHC Context. 864 TCP_OPTIONS designates the EHC Rule compressing / decompressing TCP 865 options related fields such as Data Offset and Reserved Bits. 866 TCP_OPTION can only be activated when the TCP Option ("tcp_options") 867 is defined. When "tcp_options" is set to "False" and indicates there 868 are no TCP Options, the Data Offsets and Reserved Bits are compressed 869 / decompressed using the "elided" method with Data Offset and 870 Reserved Bits set to zero. 872 TCP_CHECK designates the EHC Rule compressing / decompressing the TCP 873 Checksum. TCP_CHECK works similarly as UDP_CHECK. 875 TCP_URGENT designates the EHC Rule compressing / decompressing the 876 urgent related information. When "tcp_urgent" is set to "False" and 877 indicates there are no TCP Urgent related information, the Urgent 878 Pointer is then "elided" and filled with zeros. 880 7. Diet-ESP EHC Strategy 882 From the attributes of the EHC Context, Diet-ESP defined as an EHC 883 Strategy, which EHC Rules to apply. The EHC Strategy is defined for 884 outbound packets which compresses the packet as well as for inbound 885 packet where the decompression occurs. 887 Diet-ESP results from a compromise between compression efficiency, 888 ease to configure Diet-ESP and the various use cases considered. In 889 order to achieve a great simplicity, 890 o Diet-ESP favors compression methods that required fewer 891 configuration: For IPv6, ip6_tcfl_comp and ip6_hl_com to "Outer" 892 so that ip6_tc, ip6_fl and ip6_hl can be derived from the packet. 893 Similarly, ip4_ttl_comp has is set to "Outer" so ip4_tll can be 894 derived from the packet. 895 o Diet-ESP limits compression method to those foreseen as the most 896 commonly used. As such, esp_sn_gen has been set to "Incremental" 897 as this is the most common method used to generate SN. The other 898 method would be "Time". 899 o Diet-ESP limits compression to the most foreseen scenarios. IPv4 900 compression has been limited in favor of IPv6 as constraint 901 devices have largely adopted IPv6, and the gain versus the 902 complexity to deploy IPv4 inner IP addresses has not been proved. 903 As a result some compressions for IPv4 are not considered by DIet- 904 ESP. This involved compression of the IPv4 options by setting 905 ip4_options to "No_Options". Similarly IPv4 ID compression has 906 not been enabled by setting ip4_id and ip4_id_lsb to 907 "Unspecified". 908 o Diet-ESP negotiated values shared by different rules such as 909 tcp_lsb which is shared for TCP ACK as well as for the TCP SN. 910 o Diet-ESP defines a logic to set the necessary parameters from 911 those agreed by the standard ESP agreement, which limits the 912 setting of parameters. 914 The following tables shows, which EHC Rules are activated by default 915 for the supported protocols ESP, IPv4, IPv6, UDP, UDP-Lite and TCP 916 when using the Diet-ESP strategy and which ones are activated due to 917 certain circumstances or explicit negotiation 919 ESP: 921 +----------+--------------+-------------+------------+ 922 | EHC Rule | Activated if | Parameter | Value | 923 +----------+--------------+-------------+------------+ 924 | ESP_SPI | Diet-ESP | esp_spi_lsb | Negotiated | 925 | | | esp_spi | In SA | 926 | ESP_SN | Diet-ESP | esp_sn_lsb | Negotiated | 927 | | | esp_sn_gen | Negotiated | 928 | | | esp_sn | In SA | 929 | ESP_NH | Diet-ESP | ipsec_mode | In SA | 930 | | | l4_proto | In SA | 931 | ESP_PAD | Diet-ESP | esp_align | Negotiated | 932 | | | esp_encr | In SA | 933 +----------+--------------+-------------+------------+ 934 IPv4: 936 +---------------+---------------+------------+-------+ 937 | EHC Rule | Activated if | Parameter | Value | 938 +---------------+---------------+------------+-------+ 939 | IP4_OPT_DIS | ip_version==4 | ip_version | In SA | 940 | IP4_LENGTH | ip_version==4 | None | | 941 | IP4_FRAG_DIS | ip_version==4 | None | | 942 | IP4_TTL_OUTER | ip_version==4 | None | | 943 | IP4_TTL_OUTER | ip_version==4 | l4_proto | In SA | 944 | IP4_CHECK | ip_version==4 | None | | 945 | IP4_SRC | ip_version==4 | ip4_src | In SA | 946 | IP4_DST | ip_version==4 | ip4_dst | In SA | 947 +---------------+---------------+------------+-------+ 949 IPv6: 951 +--------------+---------------+------------+-------+ 952 | EHC Rule | Activated if | Parameter | Value | 953 +--------------+---------------+------------+-------+ 954 | IP6_OUTER | ip_version==6 | ip_version | In SA | 955 | IP6_LENGTH | ip_version==6 | None | | 956 | IP6_NH | ip_version==6 | l4_proto | In SA | 957 | IP6_HL_OUTER | ip_version==6 | None | | 958 | IP6_SRC | ip_version==6 | ip6_src | In SA | 959 | IP6_DST | ip_version==6 | ip6_dst | In SA | 960 +--------------+---------------+------------+-------+ 962 UDP: 964 +------------+--------------+-----------+-------+ 965 | EHC Rule | Activated if | Parameter | Value | 966 +------------+--------------+-----------+-------+ 967 | UDP_SRC | l4_proto==17 | l4_source | In SA | 968 | UDP_DST | l4_proto==17 | l4_dest | In SA | 969 | UDP_LENGTH | l4_proto==17 | None | | 970 | UDP_CHECK | l4_proto==17 | None | | 971 +------------+--------------+-----------+-------+ 972 UDP-Lite: 974 +-------------------+---------------+------------------+------------+ 975 | EHC Rule | Activated if | Parameter | Value | 976 +-------------------+---------------+------------------+------------+ 977 | UDP_LITE_SRC | l4_proto==136 | l4_source | In SA | 978 | UDP_LITE_DST | l4_proto==136 | l4_dest | In SA | 979 | UDP_LITE_COVERAGE | l4_proto==136 | udplite_coverage | Negotiated | 980 | UDP_LITE_CHECK | l4_proto==136 | None | | 981 +-------------------+---------------+------------------+------------+ 983 TCP: 985 +-------------+--------------+-------------+------------+ 986 | EHC Rule | Activated if | Parameter | Value | 987 +-------------+--------------+-------------+------------+ 988 | TCP_SRC | l4_proto==6 | l4_source | In SA | 989 | TCP_DST | l4_proto==6 | l4_dest | In SA | 990 | TCP_SN | l4_proto==6 | tcp_sn | In SA | 991 | | | tcp_lsb | Negotiated | 992 | TCP_ACK | l4_proto==6 | tcp_ack | In SA | 993 | | | tcp_lsb | Negotiated | 994 | TCP_OPTIONS | l4_proto==6 | tcp_options | Negotiated | 995 | TCP_CHECK | l4_proto==6 | None | | 996 | TCP_URGENT | l4_proto==6 | tcp_urgent | Negotiated | 997 +-------------+--------------+-------------+------------+ 999 Thus, the parameters that the two peers needs to agree on are: 1001 o esp_sn_lsb 1002 o esp_spi_lsb 1003 o esp_align 1004 o udplite_coverage 1005 o tcp_lsb 1006 o tcp_options 1007 o tcp_urgent 1009 Implementation may differ from the description below. However, the 1010 outcome MUST remain the same. 1012 7.1. Outbound Packet Processing 1014 Diet-ESP compression is defined as follows: 1016 1. In phase "pre-esp": Match the inbound packet with the SA and 1017 determine if the Diet-ESP EHC Strategy has been activated. If 1018 the Diet-ESP EHC Strategy has been activated proceed to next 1019 step, otherwise skip all steps associated to Diet-ESP and proceed 1020 to the standard ESP as defined in [RFC4303] 1021 2. In phase "pre-esp": If "l4_proto" designates a "Single" Protocol 1022 ID (UDP, TCP or UDP-Lite), proceed to the compression of the 1023 specific layer. Otherwise, the transport layer is not 1024 compressed. 1025 3. In phase "clear text esp": If "ipsec_mode" is set to "Tunnel" 1026 mode, determine "ip_version" the IP version of the inner IP 1027 addresses and proceed to the appropriated inner IP address 1028 compression. 1029 4. In phase "clear text esp" and "post-esp": Proceed to the ESP 1030 compression. 1032 UDP compression is defined as below: 1034 1. If "l4_src" designates a "Single" Source Port, apply UDP_SRC to 1035 compress the Source Port. 1036 2. If "l4_dst" designates a "Single" Destination Port, apply UDP_DST 1037 to compress the Destination Port. 1038 3. Apply UDP_CHECK to compress the Checksum. 1039 4. Apply UDP_LENGTH to compress the Length. 1041 UDP-lite compression is defined as below: 1043 1. If "l4_src" designates a "Single" Source Port, apply the UDP- 1044 LITE_SRC to compress the Source Port. 1045 2. If "l4_dst" designates a "Single" Destination Port, apply the 1046 UDP-LITE_DST, to compress the Destination Port. 1047 3. If "udplite_coverage" is specified, apply the UDP-LITE_COVERAGE, 1048 to compress the Coverage. 1049 4. Apply UDP-LITE_CHECK to compress the Checksum. 1051 TCP compression is defined as below: 1053 1. If "l4_src" designates a "Single" Source Port than apply the 1054 TCP_SRC to compress the Source Port. 1055 2. If "l4_dst" designates a "Single" Destination Port than apply the 1056 TCP_DST to compress the Destination Port. 1057 3. If "tcp_lsb" is lower than 4, then "tcp_sn" "tcp_ack" attributes 1058 of the Diet-ESP Context are updated with the value provided from 1059 the packet before applying the TCP_SN and the TCP_ACK EHC Rules. 1060 4. If "tcp_options" is set to "False" apply the TCP_OPTIONS EHC 1061 Rule. 1062 5. If "tcp_urgent" is set to "False" apply the TCP_URGENT EHC Rule. 1063 6. Apply TCP_CHECK to compress the Checksum. 1065 Inner IPv6 Header compression is defined as below: 1067 1. If "ip6_src" designates a "Single" Source IP address, apply the 1068 IP6_SRC to compress the IPv6 Source Address. 1069 2. If "ip6_dst" designates a "Single" Destination IP address, apply 1070 the IP6_DST to decompress the IPv6 Destination Address. 1071 3. Apply IPv6_HL_OUTER to compress the Hop Limit. 1072 4. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP- 1073 Lite), apply IP6_NH to compress the Next Header. 1074 5. Apply, IP6_LENGTH to compress the Length. 1075 6. Apply IP6_OUTER to compress Version, Traffic Class and Flow 1076 Label. 1078 Inner IPv4 Header compression is defined as below: 1080 1. Apply, IP4_LENGTH to compress the Length. 1081 2. Apply IP4__TTL_OUTER to compress Time To Live. 1082 3. Apply, IP4_CHECK to compress the IPv4 header checksum. 1083 4. If "ip4_src" designates a "Single" Source IP address, apply the 1084 IP4_SRC to compress the IPv4 Source Address. 1085 5. If "ip4_dst" designates a "Single" Destination IP address, apply 1086 the IP4_DST to decompress the IPv4 Destination Address. 1088 ESP compression is defined as below: 1090 1. In phase "clear text esp": If "ipsec_mode" is set to "Tunnel" or 1091 "l4_proto" is set to a "Single value - eventually different from 1092 TCP, UDP or UDP-Lite, apply ESP_NH, to compress the Next Header. 1093 2. In phase "clear text esp": If "esp_encr" specify an encryption 1094 algorithm that does not provide padding, then apply ESP_PAD to 1095 compress the Pad Length and Padding. 1096 3. Proceed to the ESP encryption as defined in [RFC4303]. 1097 4. In phase "post-esp: If "esp_sn_lsb" is different from 4, then 1098 apply ESP_SN. To compress the ESP SN. 1099 5. In phase "post-esp": If "esp_spi_lsb" is different from 4, then 1100 apply ESP_SPI to compress the SPI. 1102 7.2. Inbound Packet Processing 1104 Diet-ESP decompression is defined as follows: 1106 1. Match the inbound packet with the SA and determine if the Diet- 1107 ESP EHC Strategy has been activated. When Diet-ESP is activated 1108 this means that the "esp_spi_lsb" are sufficient to index the SA 1109 and proceed to next step, otherwise skip all steps associated to 1110 Diet-ESP and proceed to the standard ESP as defined in [RFC4303] 1111 2. In phase "clear text esp" and "post-esp": Proceed to the ESP 1112 decompression. 1113 3. In phase "clear text esp": If "ipsec_mode" is set to "Tunnel" 1114 mode, determine "ip_version" the IP version of the inner IP 1115 addresses and proceed to the appropriated inner IP address 1116 decompression, except for the computation of the checksums and 1117 length. 1118 4. In phase "pre-esp": If "l4_proto" designates a "Single" Protocol 1119 ID (UDP, TCP or UDP-Lite), proceed to the decompression of the 1120 specific layer, except for the computation of the checksums and 1121 length replaced by zero fields. 1122 5. In phase "pre-esp": Proceed to the decompression of the checksums 1123 and length. 1125 ESP decompression is defined as follows: 1127 1. In phase "post-esp": If "esp_spi_lsb" is different from 4, then 1128 apply ESP_SPI to decompress the SPI. 1129 2. In phase "post-esp: If "esp_sn_lsb" is different from 4, then 1130 apply ESP_SN. To decompress the ESP SN. 1131 3. Proceed to the ESP signature validation and decryption as defined 1132 in [RFC4303]. 1133 4. In phase "clear text esp": If "ipsec_mode" is set to "Tunnel" or 1134 "l4_proto" is set to a "Single value - eventually different from 1135 TCP, UDP or UDP-Lite, apply ESP_NH, to decompress the Next 1136 Header. 1137 5. In phase "clear text esp": If "esp_encr" specify an encryption 1138 algorithm that does not provide padding, then apply ESP_PAD to 1139 compress the Pad Length and Padding. 1140 6. Extract the ESP Data Payload and apply decompression EHC Rule to 1141 the ESP Data Payload. 1143 UDP decompression is defined as follows: 1145 1. If "l4_src" designates a "Single" Source Port, apply UDP_SRC to 1146 decompress the Source Port. 1147 2. If "l4_dst" designates a "Single" Destination Port, apply UDP_DST 1148 to decompress the Destination Port. 1149 3. Apply UDP_LENGTH to compress the Length. The length value is 1150 computed from the length provided by the lower layer, with the 1151 additional added bytes during the UDP decompression including the 1152 length size. 1153 4. Apply UDP_CHECK to decompress the Checksum. 1154 5. Update the Length of the lower layers: 1156 1. If "ipsec_mode" is set to "Transport" mode, update the Length 1157 of the outer IP header (IPv4 or IPv6). The Length is 1158 incremented by the number of bytes generated by the 1159 decompression of the transport layer. 1160 2. If "ipsec_mode" is set to "Tunnel" mode, update the Length of 1161 the inner IP address (IPv4 or IPv6) as well as the outer IP 1162 header (IPv4 or IPv6). The Length is incremented by the 1163 number of bytes generated by the decompression of the 1164 transport layer. 1166 UDP-Lite decompression is defined as follows: 1168 1. If "l4_src" designates a "Single" Source Port, apply the UDP- 1169 LITE_SRC to decompress the Source Port. 1170 2. If "l4_dst" designates a "Single" Destination Port, apply the 1171 UDP-LITE_DST, to decompress the Destination Port. 1172 3. If "udplite_coverage" is specified, apply the UDP-LITE_COVERAGE, 1173 to decompress the Coverage. 1174 4. Apply UDP-LITE_CHECK to compress the Checksum. 1175 5. Update the Length of the lower layers as defined in UDP. 1177 TCP decompression is defined as follows: 1179 1. If "l4_src" designates a "Single" Source Port than apply the 1180 TCP_SRC to decompress the Source Port. 1181 2. If "l4_dst" designates a "Single" Destination Port than apply the 1182 TCP_DST to decompress the Destination Port. 1183 3. If "tcp_lsb" is lower than 4, apply TCP_SN and the TCP_ACK to 1184 decompress the TCP Sequence Number and the TCP Acknowledgment 1185 Number. 1186 4. If "tcp_options" is set to "False" apply TCP_OPTIONS to 1187 decompress Data Offset and Reserved Bits. 1188 5. If "tcp_urgent" is set to "False" apply the TCP_URGENT to 1189 decompress the Urgent Pointer. 1190 6. Apply TCP_CHECK to decompress the Checksum. 1192 Inner IPv6 decompression is defined as follows: 1194 1. Apply IP6_OUTER to decompress Version, Traffic Class and Flow 1195 Label. 1196 2. Set the Length to zero. 1197 3. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP- 1198 Lite), apply IP6_NH to decompress the Next Header. 1199 4. Hop Limit is decompressed with IP6_HL_OUTER (with "ip6_hl_comp" 1200 set to "Outer"). 1201 5. If the "ip6_src" designates a "Single" Source IP address, apply 1202 the IP6_SRC to de compress the IPv6 Source Address. 1203 6. If the "ip6_dst" designates a "Single" Destination IP address 1204 than apply the IP6_DST to decompress the IPv6 Destination 1205 Address. 1206 7. Apply, IP6_LENGTH to provide the replace the zero length value by 1207 its appropriated appropriated value. The Length value considers 1208 the length provided by the lower layers to which are added the 1209 additional bytes due to the decompression, minus the length of 1210 the inner IP6 Header. 1212 Inner IPv4 decompression is defined as follows: 1214 1. Apply, IP4_LENGTH to provide the replace the zero length value by 1215 its appropriated appropriated value. The Length value considers 1216 the length provided by the lower layers to which are added the 1217 additional bytes due to the decompression, minus the length of 1218 the inner IPv4 Header. The value computed from the lower layer 1219 will have to be overwritten in case further decompression occurs. 1220 2. Apply IP4_TTL_OUTER to decompress Time To Live. 1221 3. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP- 1222 Lite), apply IP4_PROT to decompress the Protocol Field. 1223 4. If "ip4_src" designates a "Single" Source IP address, apply the 1224 IP4_SRC to de compress the IPv4 Source Address. 1225 5. If "ip4_dst" designates a "Single" Destination IP address than 1226 apply the IP4_DST to decompress the IPv4 Destination Address. 1227 6. Apply IP4_CHECK to decompress the checksum of the IPv4 header 1229 8. IANA Considerations 1231 There are no IANA consideration for this document. 1233 9. Security Considerations 1235 This section lists security considerations related to the Diet-ESP 1236 protocol. 1238 Security Parameter Index (SPI): 1239 The Security Parameter Index (SPI) is used by the receiver to 1240 index the Security Association that contains appropriated 1241 cryptographic material. If the SPI is not found, the packet is 1242 rejected as no further checks can be performed. In EHC, the value 1243 of the SPI is not reduced, but compressed why the SPI value may 1244 not be fully provided between the compressor and the de- 1245 compressor. On the other hand, its uncompressed value is provided 1246 to the ESP-procession and no weakness is introduced to ESP itself. 1247 On an implementation perspective, it is strongly recommended that 1248 decompression is deterministic. Compression and decompression 1249 adds some additional treatment to the ESP packet, which might be 1250 used by an attacker. In order to minimize the load associated to 1251 decompression, decompression is expected to be deterministic. The 1252 incoming compressed SPI with the associated IP addresses should 1253 output a single and unique uncompressed SPI value. If an 1254 uncompressed SPI values have to be considered, then the receiver 1255 could end in n signature checks which may be used by an attacker 1256 for a DoS attack. 1257 Sequence Numer (SN): 1258 The Sequence Number (SN) is used as an anti-replay attack 1259 mechanism. Compression and decompression of the SN is already 1260 part of the standard ESP namely the Extended Sequence Number 1261 (ESN). The SN in a standard ESP packet is 32 bit long, whether 1262 EHC enables to reduce it to 0 bytes and the main limitation to the 1263 compression a deterministic decompression. SN compression 1264 consists in indicating the least significant bits of the 1265 uncompressed SN on the wire. The size of the compressed SN must 1266 consider the maximum reordering index such that the probability 1267 that a later sent packet arrives before an earlier one. In 1268 addition the size of SN should also consider maximum consecutive 1269 packets lost during transmission. In the case of ESP, this number 1270 is set to 2^32 which is, in most real world case, largely over- 1271 provisioned. When the compression of the SN is not appropriately 1272 provisioned, the most significant bit value may be de-synchronized 1273 between the sending and receiving parties. Although IKEv2 1274 provides some re-synchronization mechanisms, in case of IoT the 1275 de-synchronization will most likely result in a renegotiation and 1276 thus DoS possibilities. Note that IoT communication may also use 1277 some external parameters, i.e. other than the compressed SN, to 1278 define whether a packet be considered or not and eventually derive 1279 the SN. One such scenario may be the use of time windows. 1280 Suppose a device is expected to send some information every hour 1281 or every week. In this case, for example, the SN may be 1282 compressed to zero bytes. Instead the SN may be derived by 1283 incrementing the SN every hour after the last received valid 1284 packet. Considering the time the packet is received make it 1285 possible to consider the time derivation of the sensor clock. If 1286 TIME is used as the method to generate the SN, the receiver MUST 1287 ensure that the esp_sn_lsb is big enough to resist time 1288 differences between the nodes. Note also that the anti-replay 1289 mechanism needs to define the size of the anti-replay 1290 window.[RFC4303] provides guidance to set the window size and are 1291 similar to those used to define the size of the compressed SN. 1293 10. Privacy Considerations 1295 Security Parameter Index (SPI): 1296 Until Diet-ESP is not deployed outside the scope of IoT and small 1297 devices, the use of a compressed SPI may provide an indication 1298 that one of the endpoint is a sensor. Such information may be 1299 used, for example, to evaluate the number of appliances deployed, 1300 or - in addition with other information, such as the time 1301 interval, the geographic location - be used to derive the type of 1302 data transmitted. 1303 Sequence Number (SN): If incremented for each ESP packet, the SN may 1304 leak some information like the amount of transmitted data or the 1305 age of the sensor. The age of the sensor may be correlated with 1306 the software used and the potential bugs. On the other hand, re- 1307 keying will re-initialize the SN, but the cost of a re-keying may 1308 not be negligible and thus, frequent re-keying can be considered. 1309 In addition to the re-key operation, the SN may be generated in 1310 order to reduce the accuracy of the information leaked. In fact, 1311 the SN does not have to be incremented by one for each packet it 1312 just has to be an increasing function. Using a function such as a 1313 TIME may prevent characterizing the age or the use of the sensor. 1314 Note that the use of such function may also impact the compression 1315 efficiency and result in larger compressed SN. 1317 11. Acknowledgment 1319 We would like to thank Orange and Universitee Pierre et Marie Curie 1320 for initiating the work on Diet-ESP. We Would like to thank Sylvain 1321 Killian for implementing an open source Diet-ESP on Contiki and 1322 testing it on the FIT IoT-LAB [fit-iot-lab] funded by the French 1323 Ministry of Higher Education and Research. We thank the IoT-Lab Team 1324 and the INRIA for maintaining the FIT IoT-LAB platform and for 1325 providing feed backs in an efficient way. 1327 We would like to thank Bob Moskowitz for not copyrighting Diet HIP. 1328 The "Diet" terminology is from him. 1330 We would like to thank those we received many useful feed backs among 1331 others: Dominique Bartel, Anna Minaburo, Suresh Krishnan, Samita 1332 Chakrabarti, Michael Richarson, Tero Kivinen. 1334 12. References 1336 12.1. Normative References 1338 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1339 DOI 10.17487/RFC0791, September 1981, 1340 . 1342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1343 Requirement Levels", BCP 14, RFC 2119, 1344 DOI 10.17487/RFC2119, March 1997, 1345 . 1347 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1348 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1349 . 1351 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1352 Mode with IPsec Encapsulating Security Payload (ESP)", 1353 RFC 4309, DOI 10.17487/RFC4309, December 2005, 1354 . 1356 [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec 1357 Extensions to Support Robust Header Compression over 1358 IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010, 1359 . 1361 12.2. Informational References 1363 [I-D.toutain-6lpwa-ipv6-static-context-hc] 1364 Minaburo, A. and L. Toutain, "6LPWA Static Context Header 1365 Compression (SCHC) for IPV6 and UDP", draft-toutain-6lpwa- 1366 ipv6-static-context-hc-01 (work in progress), June 2016. 1368 [I-D.mglt-ipsecme-implicit-iv] 1369 Migault, D., Guggemos, T., and Y. Nir, "Implicit IV for 1370 Counter-based Ciphers in IPsec", draft-mglt-ipsecme- 1371 implicit-iv-04 (work in progress), June 2017. 1373 [fit-iot-lab] 1374 "Future Internet of Things (FIT) IoT-LAB", 1375 . 1377 Appendix A. Illustrative Examples 1379 A.1. Single UDP Session IoT VPN 1381 This section considers a IoT IPv6 probe hosting a UDP application. 1382 The probe is dedicated to a single application and establishes a 1383 single UDP session. As a result, inner IP addresses and UDP Ports 1384 have a "Single" value and can be easily compressed. The probes sets 1385 an IPsec VPN using IPv6 addresses in order to connect its secure 1386 domain - typically a Home Gateway. The use of IPv6 for inner and 1387 outer IP addresses, enables to infer inner IP fields from the outer 1388 IP address. The probes encrypts with AES-CCM_8 [RFC4309]. AES-CCM 1389 does not have padding, so the padding is performed by ESP. The 1390 probes uses an 8 bit alignment which enables to fully compress the 1391 ESP Trailer. In addition, as the probe SA is indexed using the outer 1392 IP addresses (or eventually the radio identifiers) which enables to 1393 fully compress the SPI. As the probe provides information every 1394 hour, the Sequence Number using time can be derived from the received 1395 time, which enables to fully compress the SN. 1397 Figure 3 represents the original UDP packet and Figure 4 represents 1398 the corresponding packet compressed with Diet-ESP. The compression 1399 with Diet-ESP results in a reduction of 61 bytes overhead. With IPv4 1400 inner IP addressed Diet-ESP results in an 45 byte overhead reduction. 1402 Further compression may be done for example by using an implicit IV 1403 [I-D.mglt-ipsecme-implicit-iv] and by compressing the outer IP 1404 addresses (not represented) on the figure. In addition, application 1405 data may also be compressed with mechanisms outside of the scope of 1406 Diet-ESP. 1408 0 1 2 3 1409 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 1410 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1411 E| Security Parameters Index (SPI) | ^ 1412 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1413 P| Sequence Number (SN) | | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1415 | | | 1416 | IV | | 1417 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1418 I|version| traffic class | flow label |^ | 1419 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1420 v| payload length | next header | hop limit || | 1421 6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1422 | || a 1423 | inner source IP || u 1424 | |e t 1425 | |n h 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e 1427 | |r n 1428 | inner destination IP |y t 1429 | |p i 1430 | |t c 1431 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1432 U| source port | dest port |d t 1433 D+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1434 P| length | checksum || d 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1436 | || | 1437 ~ APPLICATION DATA ~| | 1438 | || | 1439 -| +-+-+-+-+-+-+-+-+| | 1440 E| | Padding || | 1441 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1442 P| Padding (continue) | Pad Length | Next Header |v v 1443 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1444 | Integrity Check Value-ICV (variable) | 1445 | | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 Figure 3: Standard ESP VPN Packet Description 1450 0 1 2 3 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- 1453 | | ^ 1454 | IV | | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ aut 1456 | | hen 1457 ~ APPLICATION DATA ~ tic 1458 | (encrypted) | ate 1459 | +-+-+-+-+-+-+-+-+ | 1460 | | | V 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-- 1462 | Integrity Check Value-ICV (variable) | 1463 | +-+-+-+-+-+-+-+-+ 1464 | | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 Figure 4: Diet-ESP Single UDP Session IoT VPN Packet Description 1469 The following table illustrates the activated rules and the 1470 attributes of the Diet-ESP Context that needs an explicit agreement 1471 to achieve the compression. All other attributes used by the rules 1472 are part of the SA agreement. Parameters of not activated rules are 1473 left "Unspecified". 1475 +--------------+-------------------+-------+ 1476 | EHC Rule | Context Attribute | Value | 1477 +--------------+-------------------+-------+ 1478 | ESP_SPI | esp_spi_lsb | 0 | 1479 | ESP_SN | esp_sn_lsb | 0 | 1480 | | esp_sn_gen | | 1481 | ESP_NH | | | 1482 | ESP_PAD | esp_align | 8 | 1483 | | | | 1484 | IP6_OUTER | ip6_tcfl_comp | | 1485 | | ip6_hl_comp | | 1486 | IP6_LENGTH | | | 1487 | IP6_NH | | | 1488 | IP6_HL_OUTER | | | 1489 | IP6_SRC | | | 1490 | IP6_DST | | | 1491 | | | | 1492 | UDP_SRC | | | 1493 | UDP_DST | | | 1494 | UDP_LENGTH | | | 1495 | UDP_CHECK | | | 1496 +--------------+-------------------+-------+ 1498 A.2. Single TCP session IoT VPN 1500 This section considers the same probe as described in Appendix A.1 1501 but instead of using UDP as a transport layer, the probe uses TCP. 1502 In this case TCP is used with no options, no urgent pointers and the 1503 SN and ACK Number are compressed to 2 bytes as the throughput is 1504 expected to be low. 1506 Figure 5 represents the original TCP packet and Figure 6 represents 1507 the corresponding packet compressed with Diet-ESP. The compression 1508 with Diet-ESP results in a reduction of 66 bytes overhead. With IPv4 1509 inner address Diet-ESP results in a 50 byte overhead reduction. 1511 0 1 2 3 1512 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 1513 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1514 E| Security Parameters Index (SPI) | ^ 1515 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1516 P| Sequence Number (SN) | | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1518 | | | 1519 | IV | | 1520 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1521 I|version| traffic class | flow label |^ | 1522 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1523 v| payload length | next header | hop limit || | 1524 6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1525 | || a 1526 | inner source IP || u 1527 | |e t 1528 | |n h 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e 1530 | |r n 1531 | inner destination IP |y t 1532 | |p i 1533 | |t c 1534 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1535 T| source port | dest port |d t 1536 C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1537 P| Sequence Number (SN) || d 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1539 | ACK Sequence Number || | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1541 |Off. | Rserv | Flags | Window Size || | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1543 | Checksum | Urgent Pointer || | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1545 | || | 1546 ~ APPLICATION DATA ~| | 1547 | || | 1548 | +-+-+-+-+-+-+-+-+| | 1549 E| | Padding || | 1550 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1551 P| Padding (continue) | Pad Length | Next Header |V V 1552 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1553 | Integrity Check Value-ICV (variable) | 1554 | | 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 Figure 5: Standard IoT Single TCP Session VPN Packet Description 1559 0 1 2 3 1560 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 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---a 1562 | | ^u 1563 | IV | |t 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|h 1565 | Sequence Number (SN) | ACK Sequence Number |^e|e 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|n 1567 | Flags | Window Size | ||c|t 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||r|i 1569 | ~|y|c 1570 ~ APPLICATION DATA ||p|a 1571 | ||t|t 1572 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|e 1573 | | |vdvd 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |--- 1575 | Integrity Check Value-ICV (variable) | 1576 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 Figure 6: Diet-ESP Single TCP Session IoT VPN Packet Description 1582 The following table illustrates the activated rules and the 1583 attributes of the Diet-ESP Context that needs an explicit agreement 1584 to achieve the compression. All other attributes used by the rules 1585 are part of the SA agreement. Parameters of not activated rules are 1586 left "Unspecified". Note for simplicity, tcp_sn and tcp_ack are 1587 negotiated to start with 0, but it could be any other value as well. 1589 +--------------+-------------------+---------+ 1590 | EHC Rule | Context Attribute | Value | 1591 +--------------+-------------------+---------+ 1592 | ESP_SPI | esp_spi_lsb | 0 | 1593 | ESP_SN | esp_sn_lsb | 0 | 1594 | | esp_sn_gen | | 1595 | ESP_NH | | | 1596 | ESP_PAD | esp_align | 8 | 1597 | | | | 1598 | IP6_OUTER | ip6_tcfl_comp | | 1599 | | ip6_hl_comp | | 1600 | IP6_LENGTH | | | 1601 | IP6_NH | | | 1602 | IP6_HL_OUTER | | | 1603 | IP6_SRC | | | 1604 | IP6_DST | | | 1605 | | | | 1606 | TCP_SRC | | | 1607 | TCP_DST | | | 1608 | TCP_SN | tcp_lsb | 2 | 1609 | | tcp_sn | 0 | 1610 | TCP_ACK | tcp_lsb | 2 | 1611 | | tcp_ack | 0 | 1612 | TCP_OPTIONS | tcp_options | "False" | 1613 | TCP_CHECK | | | 1614 | TCP_URGENT | tcp_urgent | "False" | 1615 +--------------+-------------------+---------+ 1617 A.3. Traditional VPN 1619 This section illustrates the case of an company VPN. The VPN is 1620 typically set by a remote host that forwards all its traffic to the 1621 security gateway. As transport protocols are "Unspecified", 1622 compression is limited to ESP and the inner IP header. For the inner 1623 IP header, the Destination IP address is "Unspecified" so the 1624 compression of the inner IP address excludes the Destination IP 1625 address. Similarly, the inner IP Next Header cannot be compressed as 1626 the transport layer is not specified. For ESP, the security gateway 1627 may only have a sufficiently low number of remote users with 1628 relatively low throughput in which case SPI and SN can be compressed 1629 to 2 bytes. As throughput remains relatively low, the alignment may 1630 also set to 8 bits. 1632 A.3.1. IPv6 in IPv6 1634 Figure 7 represents the original TCP packet with IPv6 inner IP 1635 addresses and Figure 8 represents the corresponding packet compressed 1636 with Diet-ESP. The compression with Diet-ESP results in a reduction 1637 of 32 bytes. 1639 0 1 2 3 1640 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 1641 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1642 E| Security Parameters Index (SPI) | ^ 1643 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1644 P| Sequence Number (SN) | | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1646 | | | 1647 | IV | | 1648 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1649 I|version| traffic class | flow label |^ | 1650 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1651 v| payload length | next header | hop limit || | 1652 6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1653 | || a 1654 | inner source IP || u 1655 | |e t 1656 | |n h 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e 1658 | |r n 1659 | inner destination IP |y t 1660 | |p i 1661 | |t c 1662 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1663 T| source port | dest port |d t 1664 C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1665 P| Sequence Number (SN) || d 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1667 | ACK Sequence Number || | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1669 |Off. | Rserv | Flags | Window Size || | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1671 | Checksum | Urgent Pointer || | 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1673 | || | 1674 ~ APPLICATION DATA ~| | 1675 | || | 1676 -| +-+-+-+-+-+-+-+-+| | 1677 E| | Padding || | 1678 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1679 P| Padding (continue) | Pad Length | Next Header |V V 1680 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1681 | Integrity Check Value-ICV (variable) | 1682 | | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 Figure 7: Standard ESP VPN Packet Description 1687 0 1 2 3 1688 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 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1690 | SPI | SN | ^ 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1692 | | | 1693 | IV | | 1694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| 1695 | Next Header | |^ | 1696 +-+-+-+-+-+-+-+-+ || | 1697 | || | 1698 | inner destination IP || | 1699 | || |a 1700 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |u 1701 | | source port | dest. port ~|e|t 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|h 1703 ~ (continue) | TCP Sequence Number (SN) ~|c|e 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|r|n 1705 ~ (continue) | ACK Sequence Number (SN) ~|y|t 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|p|i 1707 ~ (continue) |Off. | Rserv | Flags | Window Size ~|t|c 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|a 1709 ~ (continue) | Checksum | Urgent ~|d|t 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |e 1711 ~ Pointer | || |d 1712 +-+-+-+-+-+-+-+-+ || | 1713 ~ APPLICATION DATA ~| | 1714 | || | 1715 | |v v 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1717 | Integrity Check Value-ICV (variable) | 1718 | | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 Figure 8: Diet-ESP VPN Packet Description 1723 The following table illustrates the activated rules and the 1724 attributes of the Diet-ESP Context that needs an explicit agreement 1725 to achieve the compression. All other attributes used by the rules 1726 are part of the SA agreement. Parameters of not activated rules are 1727 left "Unspecified". 1729 +--------------+-------------------+-------+ 1730 | EHC Rule | Context Attribute | Value | 1731 +--------------+-------------------+-------+ 1732 | ESP_SPI | esp_spi_lsb | 2 | 1733 | ESP_SN | esp_sn_lsb | 2 | 1734 | | esp_sn_gen | | 1735 | ESP_NH | | | 1736 | ESP_PAD | esp_align | 8 | 1737 | | | | 1738 | IP6_OUTER | ip6_tcfl_comp | | 1739 | IP6_LENGTH | | | 1740 | IP6_HL_OUTER | ip6_hl_comp | | 1741 | IP6_SRC | | | 1742 +--------------+-------------------+-------+ 1744 A.3.2. IPv6 in IPv4 1746 If the compressed inner IP header is an IPv6, but the outer IP header 1747 is an IPv4 header, the activated rules differ, as IP6_OUTER cannot be 1748 used. Instead, ip6_tcfl_comp and ip6_hl_comp are set to "Value". 1749 The resulting ESP packet is the same as in Figure 8. 1751 +--------------+-------------------+-------+ 1752 | EHC Rule | Context Attribute | Value | 1753 +--------------+-------------------+-------+ 1754 | ESP_SPI | esp_spi_lsb | 2 | 1755 | ESP_SN | esp_sn_lsb | 2 | 1756 | | esp_sn_gen | | 1757 | ESP_NH | | | 1758 | ESP_PAD | esp_align | 8 | 1759 | | | | 1760 | IP6_OUTER | ip6_tcfl_comp | | 1761 | IP6_LENGTH | | | 1762 | IP6_HL_OUTER | ip6_hl_comp | | 1763 | IP6_SRC | | | 1764 +--------------+-------------------+-------+ 1766 A.3.3. IPv4 in IPv4 1768 Figure 9 represents the original TCP packet with IPv4 inner IP 1769 addresses and Figure 10 represents the corresponding packet 1770 compressed with Diet-ESP. The compression with Diet-ESP results in a 1771 reduction of 24 bytes. 1773 0 1 2 3 1774 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 1775 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1776 E| Security Parameters Index (SPI) | ^ 1777 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1778 P| Sequence Number (SN) | | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1780 | | | 1781 | IV | | 1782 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1783 I|Version| IHL |Type of Service| Total Length |^ | 1784 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1785 v| Identification |Flags| Fragment Offset || a 1786 4+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| u 1787 | Time to Live | Protocol | Header Checksum |e t 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n h 1789 | Source Address |c e 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+r n 1791 | Destination Address |y t 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+p i 1793 | Options | Padding |t c 1794 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1795 T| source port | dest port |d t 1796 C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1797 P| Sequence Number (SN) || d 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1799 | ACK Sequence Number || | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1801 |Off. | Rserv | Flags | Window Size || | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1803 | Checksum | Urgent Pointer || | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1805 | || | 1806 ~ APPLICATION DATA ~| | 1807 | || | 1808 -| +-+-+-+-+-+-+-+-+| | 1809 E| | Padding || | 1810 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1811 P| Padding (continue) | Pad Length | Next Header |V V 1812 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1813 | Integrity Check Value-ICV (variable) | 1814 | | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 Figure 9: Standard ESP VPN Packet Description 1819 0 1 2 3 1820 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 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1822 | SPI | SN | ^ 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1824 | | | 1825 | IV | | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| 1827 |Type of Service| Protocol | inner destination IP ~^ | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|| | 1829 ~ (continue) | source port || |a 1830 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |u 1831 | destination port | TCP Sequence Number (SN) ~|e|t 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|h 1833 ~ (continue) | ACK Sequence Number ~|c|e 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|r|n 1835 ~ (continue) |Off. | Rserv | Flags ||y|t 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|p|i 1837 | Window Size | Checksum ||t|c 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|a 1839 | Urgent Pointer | APPLICATION DATA ||d|t 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| |e 1841 ~ || |d 1842 | || | 1843 | |v v 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1845 | Integrity Check Value-ICV (variable) | 1846 | | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 Figure 10: Diet-ESP VPN Packet Description 1851 The following table illustrates the activated rules and the 1852 attributes of the Diet-ESP Context that needs an explicit agreement 1853 to achieve the compression. All other attributes used by the rules 1854 are part of the SA agreement. Parameters of not activated rules are 1855 left "Unspecified". 1857 +---------------+-------------------+---------------+ 1858 | EHC Rule | Context Attribute | Value | 1859 +---------------+-------------------+---------------+ 1860 | ESP_SPI | esp_spi_lsb | 2 | 1861 | ESP_SN | esp_sn_lsb | 2 | 1862 | | esp_sn_gen | "Incremental" | 1863 | ESP_NH | | | 1864 | ESP_PAD | esp_align | 8 | 1865 | | | | 1866 | IP4_OPT_DIS | | | 1867 | IP4_LENGTH | | | 1868 | IP4_FRAG_DIS | | | 1869 | IP4_TTL_OUTER | | | 1870 | IP4_CHECK | | | 1871 | IP4_SRC | | | 1872 +---------------+-------------------+---------------+ 1874 A.3.4. IPv4 in IPv6 1876 If the compressed inner IP header is an IPv4, but the outer IP header 1877 is an IPv6 header, the activated rules differ, as IP4_TTL_OUTER 1878 cannot be used. Instead, IP4_TTL_VALUE is used. The resulting ESP 1879 packet is the same as in Figure 10. 1881 +--------------+-------------------+---------------+ 1882 | EHC Rule | Context Attribute | Value | 1883 +--------------+-------------------+---------------+ 1884 | ESP_SPI | esp_spi_lsb | 2 | 1885 | ESP_SN | esp_sn_lsb | 2 | 1886 | | esp_sn_gen | "Incremental" | 1887 | ESP_NH | | | 1888 | ESP_PAD | esp_align | 8 | 1889 | | | | 1890 | IP4_OPT_DIS | | | 1891 | IP4_LENGTH | | | 1892 | IP4_FRAG_DIS | | | 1893 | IP4_CHECK | | | 1894 | IP4_SRC | | | 1895 +--------------+-------------------+---------------+ 1897 Authors' Addresses 1898 Daniel Migault 1899 Ericsson 1900 8400 boulevard Decarie 1901 Montreal, QC H4P 2N2 1902 Canada 1904 Email: daniel.migault@ericsson.com 1906 Tobias Guggemos 1907 LMU Munich 1908 Oettingenstr. 67 1909 80538 Munchen, Bavaria 1910 Germany 1912 Email: guggemos@mnm-team.org 1913 URI: http://www.mnm-team.org/~guggemos 1915 Carsten Bormann 1916 Universitaet Bremen TZI 1917 Postfach 330440 1918 Bremen D-28359 1919 Germany 1921 Phone: +49-421-218-63921 1922 Email: cabo@tzi.org