idnits 2.17.1 draft-mglt-ipsecme-diet-esp-07.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 == Line 265 has weird spacing: '...ost-esp the p...' -- The document date (March 11, 2019) is 1870 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) == Unused Reference: 'RFC5858' is defined on line 1452, but no explicit reference was found in the text == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 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: September 12, 2019 LMU Munich 6 C. Bormann 7 Universitaet Bremen TZI 8 D. Schinazi 9 Google LLC 10 March 11, 2019 12 ESP Header Compression and Diet-ESP 13 draft-mglt-ipsecme-diet-esp-07 15 Abstract 17 With the use of encrypted ESP for secure IP communication, the 18 compression of IP payload is only possible with complex frameworks, 19 such as RObust Header Compression (ROHC). Such frameworks are too 20 complex for numerous use cases and especially for IoT scenarios, 21 which makes IPsec not being used here, although it offers 22 architectural benefits. 24 ESP Header Compression (EHC) defines a flexible framework to compress 25 communications protected with IPsec/ESP. Compression and 26 decompression is defined by EHC Rules orchestrated by EHC Strategies. 27 The necessary state is hold within the IPsec Security Association and 28 can be negotiated during key agreement, e.g. with IKEv2. 30 The document specifies the necessary parameters of the EHC Context to 31 allow compression of ESP and the most common included protocols, such 32 as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules. It also 33 defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per 34 packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent 35 over a single TCP or UDP session. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 12, 2019. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 75 5. IPsec Compression Mode . . . . . . . . . . . . . . . . . . . 7 76 6. EHC Context . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 6.1. EHC Context Parameters for ESP . . . . . . . . . . . . . 8 78 6.2. EHC Context Parameters for Inner IP . . . . . . . . . . . 8 79 6.3. EHC Context Parameters for Transport Protocol . . . . . . 9 80 7. EHC Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. EHC Rules for ESP . . . . . . . . . . . . . . . . . . . . 13 82 7.2. EHC Rules for inner IPv4 . . . . . . . . . . . . . . . . 15 83 7.3. EHC Rules for inner IPv6 . . . . . . . . . . . . . . . . 17 84 7.4. EHC Rules for UDP . . . . . . . . . . . . . . . . . . . . 18 85 7.5. EHC Rules for UDP-Lite . . . . . . . . . . . . . . . . . 19 86 7.6. EHC Rules for TCP . . . . . . . . . . . . . . . . . . . . 20 87 8. Diet-ESP EHC Strategy . . . . . . . . . . . . . . . . . . . . 21 88 8.1. Outbound Packet Processing . . . . . . . . . . . . . . . 24 89 8.2. Inbound Packet Processing . . . . . . . . . . . . . . . . 26 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 92 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 30 93 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 31 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 95 13.1. Normative References . . . . . . . . . . . . . . . . . . 31 96 13.2. Informational References . . . . . . . . . . . . . . . . 32 98 Appendix A. Illustrative Examples . . . . . . . . . . . . . . . 33 99 A.1. Single UDP Session IoT VPN . . . . . . . . . . . . . . . 33 100 A.2. Single TCP session IoT VPN . . . . . . . . . . . . . . . 36 101 A.3. Traditional VPN . . . . . . . . . . . . . . . . . . . . . 39 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 104 1. Requirements notation 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 2. Introduction 114 IPsec/ESP [RFC4303] secures communications either using end-to-end 115 security or by building a VPN, where the traffic is carried to a 116 secure domain via a security gateway. 118 IPsec/ESP was not designed to minimize its associated networking 119 overhead. In fact, bandwidth optimization often adds computational 120 overhead that may negatively impact large infrastructures in which 121 bandwidth usage is not a constraint. On the other hand, in IoT 122 communications, sending extra bytes can significantly impact the 123 battery life of devices and thus the life time of the device. The 124 document describes a framework that optimizes the networking overhead 125 associated to IPsec/ESP for these devices. 127 Most compression mechanisms work with dynamic compression contexts. 128 Some mechanisms, such as ROHC, agree and dynamically change the 129 context over a dedicated channel. Others, such as 6LowPAN, send the 130 context together with the actual protocol information in a separate 131 compression header. Those mechanism fail when it comes to compress 132 encrypted payloads as appearing in ESP. This is found to be a major 133 reason, why IPsec and in particular ESP is not widely developed in 134 environments where bandwidth saving is a critical task, such as in 135 IoT scenarios. 137 ESP Header Compression (EHC) chooses another form of context 138 agreement, which is similar to the one defined by Static Context 139 Header Compression (SCHC). It works with a static compression 140 context agreed for a specific Security Association. The context 141 itself can be negotiated during the key agreement, which allows only 142 minimal the changes to the actual ESP implementation. 144 EHC itself is defined as a framework that specifically compresses ESP 145 protected communications. EHC is highly flexible to address any use 146 case where compression is necessary. EHC takes advantage of the 147 negotiation between the communication endpoint to agree on the 148 cryptographic parameters, which in some cases already includes 149 parameters that remain constant during the communications (like layer 150 4 ports, or IP addresses) and can thus be used as part of the 151 compression context. Only additional, EHC specific parameters need 152 to be agreed for the purpose of compression. In addition EHC Rules 153 define how fields may be compressed and decompressed given the 154 provided parameters. Finally, EHC defines EHC Strategy which defines 155 how a set of EHC Rule is coordinated. 157 This document specifies EHC Context parameters for the most common 158 Layer 3 and 4 protocols and the associated EHC Rules. Additionally, 159 an EHC Strategy called Diet-ESP is defined, which compresses up to 32 160 bytes per packet for traditional VPN and up to 66 bytes for VPN set 161 over a single TCP or UDP session. Its main purpose is a maximum 162 level of compression with a minimum of additional agreement. This is 163 achieved by defining a default usage of existing IPsec SA parameters 164 wherever possible. 166 3. Terminology 168 This document uses the following terminology: 170 - EHC ESP Header Compression 171 - IoT Internet of Things 172 - IP If not stated otherwise, IP means IPv6. 173 - LSB Least Significant Bytes 174 - MSB Most Significant Bytes 175 - SAD IPsec Security Association Database 176 - SA IPsec Security Association 177 - SPD IPsec Security Policy Database 178 - TS IPsec Traffic Selector 179 - SPI ESP Security Parameter Index 180 - SN ESP Sequence Number 181 - PAD ESP Padding 182 - PL ESP Pad Length 183 - NH Next Header 184 - IV Initialization Vector 185 - IIV Implicit Initialization Vector 186 - ICV Integrity Check Value 187 - VPN Virtual Private Network 189 4. Protocol Overview 191 ESP Header Compression (EHC) compresses IPsec ESP packets, thus 192 reducing the size of the packet sent on the wire, while carrying an 193 equivalent level of information with an equivalent level of security. 195 EHC is able to compress any protocol encapsulated in ESP and ESP 196 itself. Concerned fields include those of the ESP protocol, as well 197 as other protocols in the ESP payload such as the IP header when the 198 tunnel mode is used, but also upper layer protocols, such as the UDP 199 or the TCP header. Non ESP fields may be compressed by ESP under 200 certain circumstances, but EHC is not intended to provide a generic 201 way outside of ESP to compress these protocols. Compression of the 202 unprotected IP header and the unencrypted ESP header may be performed 203 by mechanism such as 6LoWPAN [RFC4944], SCHC 204 [I-D.toutain-6lpwa-ipv6-static-context-hc], ROHC [RFC5795] or 205 6LoWPAN-GHC [RFC7400]. 207 EHC is based on a static compression context, EHC Rules coordinated 208 by an EHC Strategy: 210 EHC Context: Stores the information of a specific header field which 211 can be compressed by EHC. This can be specific header values 212 such as IP addresses or L4 ports do not have to be send on the 213 wire at all, or compression information for fields which can be 214 partially compressed, such as sequence numbers. 215 EHC Rules: Defines how the information of the EHC Context is used to 216 compress a specific field. It defines compression functions, 217 such as "elided", "least significant byte" and others, being 218 applied on the header field. 219 EHC Strategy: Is applied to efficiently coordinate EHC Context and 220 EHC Strategy. The EHC Strategy "Diet-ESP" defined in this 221 document utilizes the information in the IPsec SA to pre-define 222 the EHC Context without explicitly exchanging the EHC Context. 224 As depicted in Figure 1, the EHC Strategy - Diet-ESP in our case - 225 and the EHC Context are agreed upon between the two peers, e.g. 226 during key exchange. The EHC Rules are to be implemented on the 227 peers and do not require further agreement. 229 EHC Strategy, EHC Strategy, 230 EHC Context <==================> EHC Context 231 | | 232 EHC Rules | EHC Rules | 233 | | | | 234 v v v v 235 +====================+ +====================+ 236 | ESP | | ESP | 237 +====================+ +====================+ 238 | < pre-esp > | | < pre-esp > | 239 +--------------------+ +--------------------+ 240 | < clear text esp > | | < clear text esp > | 241 +--------------------+ +--------------------+ 242 | < encryption > | | < encryption > | 243 +--------------------+ +--------------------+ 244 | < post-esp > | | < post-esp > | 245 +--------------------+ +--------------------+ 247 Figure 1: ESP Header Compression Overview 249 In Figure 1, the ESP stack is represented by various sub layers 250 describing the packet processing inside the ESP: 252 pre-esp: represents treatment performed to a non ESP packet, i.e. 253 before ESP encapsulation or decapsulation is being performed. 254 Any compression of protocols not specific to but encrypted by 255 ESP, such as L4 and higher protocols, is performed here. 256 clear text esp: designates the ESP encapsulation / decapsulation 257 processing performed on an non encrypted ESP packet. This layer 258 includes compression for fields which are included during the ESP 259 encapsulation. A typical example is the later encrypted Tunnel 260 IP header and the fields of the ESP trailer. 261 encryption: designates the encryption/decryption phase This layer 262 could include compression of encryption information (e.g. 263 Initialization Vector, etc.), but this is currently out of scope 264 of this document. 265 post-esp the processing performed on an ESP encrypted packet. This 266 layer includes compression of the ESP header. 268 EHC Rules may be processed at any of these layers and thus impact 269 differently the standard ESP. More specifically, EHC Rules performed 270 at the "pre-esp" or "post-esp" layer do not require the current ESP 271 stack to be updated and can simply be appended to the current ESP 272 stack. On the other hand, EHC Rules at the "clear text esp" may 273 require modification of the current ESP stack. 275 The set of EHC rules described in this document as well as the EHC 276 Strategies may be extended in the future. Nothing prevents such EHC 277 Rules and Strategies to be updated. 279 5. IPsec Compression Mode 281 Signalling the compression of a certain ESP packet is crucial for 282 correct decompression at the sender. Situation where decompression 283 may fail unforeseen are various, such as IP fragmentation, UDP 284 options [I-D.ietf-tsvwg-udp-options] just to name a few. 286 With EHC, the agreement of the level or occurrence of compression is 287 left the negotiation protocol (e.g. IKEv2), contradicting the 288 signalization of the level of compression for a certain packet send 289 over the wire. In order to achieve per-packet signalization of the 290 compression level, this document proposes new IPsec modes "Compressed 291 Transport" and "Compressed Tunnel", which are meant to be agreed 292 during the negotiation of the EHC Contex and EHC Strategy. This 293 leads to multiple SAs, and thus, multiple SPIs for different levels 294 of compression agreed with the EHC Context. The receiver can detect 295 the level of compression of an incoming packet by looking up the used 296 EHC Context and EHC strategy in the corresponding SA. 298 If the sender detects the de-compression can not be guaranteed with a 299 given EHC Context and EHC Strategy, it MUST NOT apply compression. 300 If an SA with IPsec Mode "Tunnel"/"Transport" is available, the 301 sender SHOULD send the packet uncompressed, rather than discard the 302 packet. When there is no uncompressed SA available, the packet MUST 303 be dropped. 305 6. EHC Context 307 The EHC Context provides the necessary information so the two peers 308 can proceed to the appropriated compression and decompression defined 309 by the EHC Strategy. 311 The EHC Context is defined on a per-SA basis. A context can be 312 defined for any protocol encapsulated with ESP and for ESP itself. 313 For each header field, a context attribute is provided to the EHC 314 Context in order to allow compression and decompression. Most power 315 of EHC lies in the fact, that the attributes for some protocols are 316 already available in the IPsec SA (e.g. IP addresses in the Traffic 317 Selector). Such attributes are designated by "Yes" in the "In SA" 318 column. All others need to be negotiated separately in order to 319 allow EHC to work properly. 321 As this document is limited to the Diet-ESP strategy, the EHC Context 322 in this section used by the Diet-ESP Strategy to activate specific 323 EHC Rules as well as to execute the EHC Rules by providing the 324 necessary parameters.. 326 6.1. EHC Context Parameters for ESP 328 +-------------------+-------+--------------------------+ 329 | Context Attribute | In SA | Possible Values | 330 +-------------------+-------+--------------------------+ 331 | ipsec_mode | Yes | "Tunnel", "Transport" | 332 | outer_version | Yes | "IPv4", "IPv6" | 333 | esp_spi | Yes | ESP SPI | 334 | esp_spi_lsb | No | 0, 1, 2, 3, 4 | 335 | esp_sn | Yes | ESP Sequence Number | 336 | esp_sn_lsb | No | 0, 1, 2, 3, 4 | 337 | esp_sn_gen | No | "Time", "Incremental" | 338 | esp_align | No | 8, 16, 24, 32 | 339 | esp_encr | Yes | ESP Encryption Algorithm | 340 +-------------------+-------+--------------------------+ 342 6.2. EHC Context Parameters for Inner IP 344 Parameters associated to the Inner IP addresses are only specified 345 when the SA has been configured with the tunnel mode. As a result 346 when ipsec_mode is set to "Transport" the parameters below MUST NOT 347 be considered and are considered as "Undefined" 349 +-------------------+-------+-----------------+ 350 | Context Attribute | In SA | Possible Values | 351 +-------------------+-------+-----------------+ 352 | ip_version | Yes | "IPv4", "IPv6" | 353 +-------------------+-------+-----------------+ 355 6.2.1. EHC Context Parameters for inner IPv6 357 +-------------------+-------+------------------------------+ 358 | Context Attribute | In SA | Possible Values | 359 +-------------------+-------+------------------------------+ 360 | ip6_tcfl_comp | No | "Outer", "Value", "UnComp" | 361 | ip6_tc | No | IPv6 Traffic Class | 362 | ip6_fl | No | IPv6 Flow Label | 363 | ip6_hl_comp | No | "Outer", "Value", "UnComp" | 364 | ip6_hl | No | Hop Limit Value | 365 | ip6_src | Yes | IPv6 Source Address | 366 | ip6_dst | Yes | IPv6 Destination Address | 367 +-------------------+-------+------------------------------+ 369 ip6_tcfl_comp indicates how Traffic Class and Flow Label fields of 370 the inner IP Header are expected to be compressed. "Outer" indicates 371 Traffic Class and Flow Label are read from the outer IP header, 372 "Value" indicates these values are provided by the Diet-ESP Context, 373 while "Uncompress" indicates that no compression occurs and these 374 values are read in the inner IP inner header. 376 ip6_hl_comp indicates how Hop Limit field of the inner IP Header is 377 expected to be compressed. (see ip6_tcfl_comp). 379 ip6_dst designates the Destination IPv6 Address of the inner IP 380 header. The IP address is provided by the TS, and can be defined as 381 a range of IP addresses. Compression is only considered when ip6_dst 382 indicates a single IP Address. When the TS defines more than a 383 single IP address ip6_dst is considered as "Unspecified" and its 384 value MUST NOT be considered for compression. 386 6.2.2. EHC Context Parameters for inner IPv4 388 +-------------------+-------+------------------------------+ 389 | Context Attribute | In SA | Possible Values | 390 +-------------------+-------+------------------------------+ 391 | ip4_options | No | "Options", "No_Options" | 392 | ip4_id | No | IPv4 Identification | 393 | ip4_id_lsb | No | 0,1,2 | 394 | ip4_ttl_comp | No | "Outer", "Value", "UnComp" | 395 | ip4_ttl | No | IPv4 Time To Live | 396 | ip4_src | Yes | IPv4 Source Address | 397 | ip4_dst | Yes | IPv4 Destination Address | 398 | ip4_frag_enable | No | "True", "False" | 399 +-------------------+-------+------------------------------+ 401 ip4_options specifies if the IPv4 header contains any options. If 402 set to "No_Options", the first 8 bit of the IPv4 header (being the IP 403 version and IP header length) are compressed. If set to "Options" 404 this bits are sent uncompressed. 406 ip4_ttl indicates how the Time To Live field of the inner IP Header 407 is expected to be compressed. (see ip6_hl_comp). 409 6.3. EHC Context Parameters for Transport Protocol 411 The following parameters are provided by the SA but the SA may 412 specify single value or a range of values. When the SA specifies a 413 range of values, these parameters MUST NOT be considered and are 414 considered as Unspecified. 416 +-------------------+-------+------------------------------------+ 417 | Context Attribute | In SA | Possible Values | 418 +-------------------+-------+------------------------------------+ 419 | l4_proto | Yes | IPv6/ESP Next Header,IPv4 Protocol | 420 | l4_src | Yes | UDP/UDP-Lite/TCP Source Port | 421 | l4_dst | Yes | UDP/UDP-Lite/TCP Destination Port | 422 +-------------------+-------+------------------------------------+ 424 6.3.1. EHC Context Parameters for UDP 426 For UDP, there are no additional parameters necessary than the ones 427 in Section 6.3 429 6.3.2. EHC Context Parameters for UDP-Lite 431 +-------------------+-------+----------------------------------+ 432 | Context Attribute | In SA | Possible Values | 433 +-------------------+-------+----------------------------------+ 434 | udplite_coverage | No | 8-6535, "Length", "uncompressed" | 435 +-------------------+-------+----------------------------------+ 437 udplite_coverage: For UDP-Lite, the checksum can have different 438 coverages, which is defined by the "Checksum Coverage" field which 439 replaces the "Length" field of UDP. This context field defines the 440 coverage in advance by either a specific value (8-16535), the actual 441 length of the UDP-Lite payload ("Length" or 0) or as uncompressed. 442 Note that udplite coverage is indicated on a packet basis and cannot 443 be greater than the UDP length. In this case udplite_coverage is 444 negotiated for all packets and the actual coverage for a given UDP 445 packet is derived as the minimum value between udplite_coverage and 446 the length of the UDP packet. 448 6.3.3. EHC Context Parameters for TCP 450 +-------------------+-------+---------------------------+ 451 | Context Attribute | In SA | Possible Values | 452 +-------------------+-------+---------------------------+ 453 | tcp_sn | No | TCP Sequence Number | 454 | tcp_ack | No | TCP Acknowledgment Number | 455 | tcp_lsb | No | 0, 1, 2, 3, 4 | 456 | tcp_options | No | "True", "False" | 457 | tcp_urgent | No | "True", "False" | 458 +-------------------+-------+---------------------------+ 460 tcp_sn holds the current Sequence Number of the TCP session. 462 tcp_ack holds the current Acknowledgement Number of the TCP session. 464 tcp_lsb holds the number of lsb of tcp_sn and tcp_ack sent on the 465 wire. 467 tcp_options says if options are enabled in the current TCP session. 468 If tcp_options is set to "False" the Options field in TCP can be 469 elided. 471 tcp_urgent says if the urgent pointer is enabled in the current TCP 472 session. If tcp_urgent is set to "False" the Urgent Pointer field in 473 TCP can be elided. 475 7. EHC Rules 477 This section describes the EHC Rules involved in Diet-ESP. The EHC 478 Rules defined by Diet-ESP may be used in the future by EHC Strategies 479 other than Diet-ESP, so they are described in an independent way. 481 A EHC Rule defines the compression and decompression of one or more 482 fields and EHC Rules are represented this way: 484 +---------------+-------+---------+----------------+ 485 | EHC Rule | Field | Action | Parameters | 486 +---------------+-------+---------+----------------+ 487 | | f1 | a1 | p1_1, ... p1_n | 488 | +-------+---------+----------------+ 489 | EHC_RULE_NAME ~ ... ~ 490 | +-------+---------+----------------+ 491 | | fm | am | pm_1, ... pm_n | 492 +---------------+-------+---------+----------------+ 494 Figure 2: EHC Rules 496 The EHC Rule is designated by a name (EHC_RULE_NAME) and the 497 concerned Fields (f1, ..., fm). Each field compression and 498 decompression is represented by an Action (a1, ..., am). The 499 Parameters indicate the necessary parameters for the action to 500 perform both the compression and the decompression. 502 The table below provides a high level description of the Actions used 503 by Diet-ESP. As these Action may take different arguments and may 504 operate differently for each field a compete description is provided 505 in the next sections as part of the EHC Rule description. 507 +-----------------+-----------------+----------------------+ 508 | Function | Compression | Decompression | 509 +-----------------+-----------------+----------------------+ 510 | send-value | No | No | 511 | elided | Not send | Get from EHC Context | 512 | lsb(_lsb_size) | Sent LSB | Get from EHC Context | 513 | lower | Not send | Get from lower layer | 514 | checksum | Not send | Compute checksum. | 515 | padding(_align) | Compute padding | Get padding | 516 +-----------------+-----------------+----------------------+ 518 a. send-value designates an action that does not perform any 519 compression or decompression of a field. 520 b. elided designates an action where both peers have a local value 521 of the field. The compression of the field consists in removing 522 the field, and the decompression consists in retrieving the field 523 value from a known local value. The local value may be stored in 524 a EHC Context or defined by the EHC Rule (like a zero value for 525 example). 526 c. lsb designates an action where both peers have a local value of 527 the field, but the compression consists in sending only the LSB 528 bytes instead of the whole field. The decompression consists in 529 retrieving the field from the LSB sent as well as some other 530 additional local values. 531 d. lower designates an action where the compression consists in not 532 sending the field. The decompression consists in retrieving the 533 field from the lower layers of the packet. A typical example is 534 when both IP and UDP carry the length of the payload, then the 535 length of the UDP payload can be inferred from the one of the IP 536 layer. 537 e. checksum designates an action where the compression consists in 538 not sending a checksum field. The decompression consists in re- 539 computing the checksum. ESP provides an integrity-check based on 540 signature of the ESP payload (ICV). This makes removing checksum 541 possible, without harming the checksum mechanism. 542 f. padding designates an action that computes the padding of the ESP 543 packet. The function is specific to the ESP. 545 For all actions, the function can be performed only when the 546 appropriated parameters and fields are provided. When a field or a 547 parameters does not have an appropriated value its value is 548 designated as "Unspecified". Specifically some fields such as inner 549 IP addresses, ports or transport protocols are agreed during the SA 550 negotiation and are specified by the SA. Their value in the SA may 551 take various values that are not appropriated to enable a 552 compression. For example, when these fields are defined as a range 553 of values, or by selectors such as OPAQUE or ANY these fields cannot 554 be retrieved from a local value. Instead, when they are defined as a 555 "Single" value (i.e a single IP address, or a single port number or a 556 single transport protocol number) compression and decompression can 557 be performed. These SA related fields are considered as 558 "Unspecified" when not limited to a "Single" value. 560 When a field or a parameter is "Unspecified", the EHC Rule MUST NOT 561 be activated. This is the purpose of the EHC Strategy to avoid 562 ending in such case. In any case, when one of these condition is not 563 met, the EHC Rule MUST NOT perform any compression or decompression 564 action and the packet MUST be discarded. When possible, an error 565 SHOULD be raised and logged. 567 7.1. EHC Rules for ESP 569 This section describes the EHC Rules for ESP which are summed up in 570 the table below. 572 +---------+-------------------+---------+---------------------------+ 573 | EHC | Field | Action | Parameters | 574 | Rule | | | | 575 +---------+-------------------+---------+---------------------------+ 576 | ESP_SPI | SPI | lsb | esp_spi_lsb, esp_spi | 577 | ESP_SN | Sequence Number | lsb | esp_sn_lsb, esp_sn_gen, | 578 | | | | esp_sn | 579 | ESP_NH | Next Header | elided | l4_proto, ipsec_mode | 580 | ESP_PAD | Pad Length, | padding | esp_align, esp_encr | 581 | | Padding | | | 582 +---------+-------------------+---------+---------------------------+ 584 ESP_SPI designates the EHC Rule compressing / decompressing the SPI. 585 ESP_SPI is performed in the "post-esp" phase. The SPI is compressed 586 using "lsb". The sending peer only places the LSB bytes of the SPI 587 and the receiving peer retrieve the SPI from the LSB bytes carried in 588 the packets as well as from the SPI value stored in the SA. The SPI 589 MUST be retrieved as its full value is included in the signature 590 check. The two peers MUST agree on the number of LSB bytes to be 591 sent: "esp_spi_lsb". Upon agreeing on "esp_spi_lsb", the receiving 592 peer MUST NOT agree on a value not carrying sufficient information to 593 retrieve the full SPI. 595 ESP_SN designates the EHC Rule compressing / decompressing the ESP 596 Sequence Number. ESP_SN is performed in the "post-esp" phase. 597 ESP_SN is only activated if the SN ("esp_sn"), the LSB significant 598 bytes ("esp_sn_lsb") and the method used to generate the SN 599 ("esp_sn_gen") are defined. The Sequence Number is compressed using 600 "lsb". Similarly to the SPI, the Sequence Number MUST be retrieved 601 in order to complete the signature check of the ESP packet. Unlike 602 the SPI, the Sequence Number is not agreed by the peers, but is 603 changing for every packet. As a result, in order to retrieve the 604 Sequence Number from the LSB "esp_sn_lsb", the peers MUST agree on 605 generating Sequence Number in a similar way. This is negotiated with 606 "esp_sn_gen" and the receiver MUST ensure that "esp_sn_lsb" is big 607 enough to absorb minor packet losses or time differences between the 608 peers. 610 ESP_NH designates the EHC Rule compressing / decompressing the ESP 611 Next Header. ESP_NH is performed in the "clear text esp" phase. 612 ESP_NH is only activated if the Next Header is specified. The Next 613 Header can be specified as IP (IPv4 or IPv6) when the IPsec tunnel 614 mode is used ("ipsec_mode" set to "Tunnel") or when the transport 615 mode ("ipsec_mode" set to "Transport") is used when the Traffic 616 Selector defines a "Single" Protocol ID ("l4_proto"). The Next 617 Header, is compressed using "elided". The Next Header indicates the 618 Header in the Payload Data. When the Tunnel mode is chosen, the type 619 of the header is known to be an IP header. Similarly, the TS may 620 also hold transport layer protocol, which specifies the Next Header 621 value for Transport mode. The Next Header value is only there to 622 provide sufficient information for decapsulating ESP. In other words 623 decompressing this fields would occur in the "clear text esp" phase 624 and striped but directly removed again by the ESP stack. For these 625 reasons, implementation may simply omit decompressing this field. 627 ESP_PAD designates the EHC Rule compressing / decompressing the Pad 628 Length and Padding fields. ESP_PAD is performed in the "clear text 629 esp" phase. Pad Length and Padding define the padding. The purpose 630 of padding is to respect a 32 bit alignment for ESP or block sizes of 631 the used cryptographic suite. As the ESP trailer is encrypted, 632 Padding and Pad Length MUST to be performed by ESP and not by the 633 encryption algorithm. Thus, ESP_PAD always needs to respect the 634 cipher alignment ("esp_encr"), if applicable. Compression may be 635 performed especially when device support alignment smaller than 32 636 bit. Such alignment is designated as "esp_align" and the padding 637 bytes are the necessary bytes so the ESP packet has a length that is 638 a multiple of "esp_align". 640 When "esp_align" is set to an 8-bit alignment padding bytes are not 641 necessary, and Padding as well as Pad Length are removed. For values 642 that are different from 8-bit alignment, padding bytes needs to be 643 computed according to the ESP packet length why ESP_PAD MUST be the 644 last action of "clear text esp". The resulting number of padding 645 byte is then expressed in Padding and Pad Length fields with Pad 646 Length set to padding bytes number - 1 and Padding is generated as 647 described in [RFC4303]. 649 Combining the Pad Length and Padding fields could potentially add an 650 overhead on fixed size padding. In fact some applications may only 651 send the same type of fixed size data, in which case the Pad Length 652 would not be necessary to be specified. However, the only corner 653 case Pad Length fields would actually add an overhead is when padding 654 is expected to be of zero size. In this case, specifying an 8-bit 655 alignment solve this issue. 657 7.2. EHC Rules for inner IPv4 659 All IPv4 EHC Rules MUST be performed during the "clear text esp" 660 phase. The EHC Rules are only defined for compressing the inner IPv4 661 header and thus can only be used when the SA is using the Tunnel 662 mode. 664 +---------------+-----------------+----------+--------------------+ 665 | EHC Rule | Field | Action | Parameters | 666 +---------------+-----------------+----------+--------------------+ 667 | IP4_OPT_DIS | Version | elided | ip_version | 668 | | Header Length | elided | | 669 | IP4_LENGTH | Total Length | lower | | 670 | IP4_ID | Identification | lsb | ip4_id, ip4_id_lsb | 671 | IP4_FRAG_DIS | Flags | elided | | 672 | | Fragment Offset | elided | | 673 | IP4_TTL_OUTER | Time To Live | elided | ip4_ttl | 674 | IP4_TTL_VALUE | Time To Live | elided | ip4_ttl | 675 | IP4_PROT | Protocol | elided | l4_proto | 676 | IP4_CHECK | Header Checksum | checksum | | 677 | IP4_SRC | Source Address | elided | ip4_src | 678 | IP4_DST | Dest. Address | elided | ip4_dst | 679 +---------------+-----------------+----------+--------------------+ 681 IP4_OPT_DIS designates that the IPv4 header does not include any 682 options and indicates if the first byte of the IPv4 header - 683 consisting of IP version and IPv4 Header Length, are compressed. The 684 Version "ip_version" is defined by the SA and is thus compressed 685 using "elided". If the header does not contain any options, it is 686 compressed with "elided" and decompressed to "20", the default length 687 of the IPv4 header. If the header does contains some options, the 688 length is not compressed. 690 IP4_LENGTH designates the EHC Rule compressing / decompressing the 691 Total Length Field of the inner IPv4 header. The Total Length is 692 compressed by the sender and not sent. The receiver decompresses it 693 by recomputing the Total Length from the outer IP header. The outer 694 IP header can be IPv4 or IPv6 and IP4_LENGTH MUST support both 695 versions if both versions are supported by the device. Note that the 696 length of the inner IP payload may also be subject to updates if 697 decompression of the upper layers occurs. 699 IP4_ID designates the EHC Rule compressing / decompressing the 700 Identification Field. IP4_ID is only activated if the ID ("ip4_id"), 701 the LSB significant bytes ("ip4_id_lsb") are defined. Upon agreeing 702 on "ip4_id_lsb", the receiving peer MUST NOT agree on a value not 703 carrying sufficient information to retrieve the full IP 704 Identification. Note also that unlike the ESP SN, the IPv4 705 Identification is not part of the SA. As a result, when the ID is 706 compressed, its value MUST be stored in the EHC Context. The 707 reserved attribute for that is "ip4_id" 709 IP4_FRAG_DIS designates that the inner IPv4 header does not support 710 fragmentation. If activated, IP4_FRAG_DIS indicates compression of 711 Flags and Fragment Offset field in the IPv4 header which consists of 712 2 bytes. Both fields are compressed with "elided" and decompressed 713 with their default value according to [RFC0791], which is 0b010 for 714 Flags and 0 for Fragment Offset. 716 IP4_TTL_OUTER designates an EHC Rule compressing / decompressing the 717 Time To Live field of the inner IP header. If the outer IP header is 718 an IPv6 header, the Hop Limit is used for decompression. The Time To 719 Live field is compressed / decompressed using "lower", thus the field 720 is not sent. The receiver decompresses it by reading its value from 721 the outer IP header (TTL in case of IPv4 or HL in case of IPv6). 723 IP4_TTL_VALUE designates an EHC Rule compressing / decompressing the 724 Time To Live field of the inner IP header. IP4_TTL_VALUE is only 725 activated when the Hop Limit ("ip4_ttl") has been agreed. Time To 726 Live is compressed / decompressed using the "elided" method. 728 IP4_PROTO designates the EHC Rule compressing / decompressing the 729 Protocol field of the inner IPv4 header. IP4_PROTO is only activated 730 if the Protocol is specified, that is when the Traffic Selectors 731 defines a "Single" Protocol ID ("l4_proto"). When the Protocol ID 732 identified by the SA has a "Single" value, the Protocol is compressed 733 and decompressed using the "elided" method. 735 IP4_CHECK designates the EHC rule compressing / decompressing the 736 Header Checksum field of the inner IPv4 header. The IPv4 header 737 checksum is not sent by the sender and the receiver computes from the 738 decompressed inner IPv4 header. IP4_CHECK MUST compute the checksum 739 and not fill the checksum field with zeros. As a result, IP4_CHECK 740 is the last decompressing EHC Rule to be performed on the 741 decompressed IPv4 header. 743 IP4_SRC compresses the source IP address of the inner IPv4 header. 744 IP4_SRC_IP is only be activated when the Traffic Selectors agreed by 745 the SA defines a "Single" source IP address ("ip4_src"). The Source 746 IP address is compressed / decompressed using the "elided" method. 748 IP4_DST works in a similar way as IP4_SRC_IP but for the destination 749 IP address ("ip4_dst") 751 7.3. EHC Rules for inner IPv6 753 All IPv6 EHC Rules MUST be performed during the "clear text esp" 754 phase. The EHC Rules are only defined for compressing the inner IPv6 755 header and thus can only be used when the SA is using the Tunnel 756 mode. 758 +--------------+----------------+--------+------------+ 759 | EHC Rule | Field | Action | Parameters | 760 +--------------+----------------+--------+------------+ 761 | IP6_OUTER | Version | elided | ip_version | 762 | | Traffic Class | lower | | 763 | | Flow Label | lower | | 764 | IP6_VALUE | Version | elided | ip_version | 765 | | Traffic Class | elided | ip6_tc | 766 | | Flow Label | elided | ip6_fl | 767 | IP6_LENGTH | Payload Length | lower | | 768 | IP6_NH | Next Header | elided | l4_proto | 769 | IP6_HL_OUTER | Hop Limit | lower | | 770 | IP6_HL_VALUE | Hop Limit | elided | ip6_hl | 771 | IP6_SRC | Source Address | elided | ip6_src | 772 | IP6_DST | Dest. Address | elided | ip6_dst | 773 +--------------+----------------+--------+------------+ 775 IP6_OUTER designates an EHC Rule for compressing / decompressing the 776 first 32 bits of the inner IPv6 header formed by the Version, Traffic 777 Class and Flow Label. IP6_OUTER only proceeds to compression when 778 both the outer and inner IP header are IPv6 header. When the outer 779 IP header is an IPv4, the compression is bypassed. Bypassing enables 780 to proceed to compression of IPv4 and IPv6 traffic in a VPN use case 781 with a single SA. The Version "ip_version" is defined by the SA and 782 is thus compressed using "elided". The other parameters Traffic 783 Class and Flow Label are compressed using "lower". More 784 specifically, the fields are not sent. The receiver decompresses 785 them by reading their value from the outer IPv6 header. 787 IP6_VALUE designates an EHC Rule for compressing / decompressing the 788 first 32 bits of the inner IPv6 header formed by the Version, Traffic 789 Class and Flow Label. IP6_VALUE is only activated if the Version of 790 the inner IP header agreed by the SA is set to "Version 6" 791 ("ip_version" set to "Version 6") and the specific values of the 792 Traffic Class ("ip6_tc") and the Flow Label ("ip6_fl") are specified. 793 With IP6_VALUE all fields are compressed and decompressed using 794 "elided". Version is provided by the SA ("ip_version") while other 795 fields are explicitly provided (ip6_tc, ip6_fl. 797 IP6_LENGTH designates the EHC Rule compressing / decompressing the 798 Payload Length Field of the inner IPv6 header. The Payload Length is 799 compressed by the sender and is not sent. The receiver decompress it 800 by recomputing the Payload Length from the outer IP header. The IP 801 header can be IPv4 or IPv6 and IP6_LENGTH MUST support both versions 802 if both versions are supported by the device. Note that the length 803 of the inner IP payload may also be subject to updates if 804 decompression of the upper layers occurs. 806 IP6_NH designates the EHC Rule compressing / decompressing the Next 807 Header field of the inner IPv6 header. IP6_NH is only activated if 808 the Next Header is specified, that is when the Traffic Selectors 809 defines a "Single" Protocol ID ("l4_proto"). When the Protocol ID 810 identified by the SA has a "Single" value, the Next Header is 811 compressed and decompressed using the "elided" method. 813 IP6_HL_OUTER designates an EHC Rule compressing / decompressing the 814 Hop Limit field of the inner IP header. If the outer IP header is an 815 IPv4 header, the Time To Live is used for decompression. The Hop 816 Limit field is compressed / decompressed using the "lower". More 817 specifically, the fields are not sent. The receiver decompresses 818 them by reading their value from the outer IPv6 header. 820 IP6_HL_VALUE designates an EHC Rule compressing / decompressing the 821 Hop Limit field of the inner IP header. IP6_HL_VALUE is only 822 activated when the Hop Limit ("ip6_hl") has been agreed. The Hop 823 Limit is compressed / decompressed using the "elided" method. 825 IP6_SRC compresses the source IP address of the inner IP header. 826 IP6_SRC_IP is only be activated when the Traffic Selectors agreed by 827 the SA defines a "Single" source IP address ("ip6_src"). The Source 828 IP address is compressed / decompressed using the "elided" method. 830 IP6_DST works in a similar way as IP6_SRC_IP but for the destination 831 IP address ("ip6_dst") 833 7.4. EHC Rules for UDP 835 All UDP EHC Rules MUST be performed during the "pre-esp" phase. The 836 EHC Rules are only defined when the Traffic Selectors agreed during 837 the SA negotiation results in "Single" Protocol ID ("l4_proto") which 838 is set to UDP (17). 840 +------------+--------------+----------+------------+ 841 | EHC Rule | Field | Action | Parameters | 842 +------------+--------------+----------+------------+ 843 | UDP_SRC | Source Port | elided | l4_source | 844 | UDP_DST | Dest. Port | elided | l4_dest | 845 | UDP_LENGTH | Length | lower | | 846 | UDP_CHECK | UDP Checksum | checksum | | 847 +------------+--------------+----------+------------+ 849 UDP_SRC designates the EHC Rule that compresses / decompresses the 850 UDP Source Port. UDP_SRC is only activated when the Source Port 851 agreed by the SA negotiation ("l4_src") is "Single". The Source Port 852 is then compressed / decompressed using the "elided" method. 854 UDP_DST works in a similar way as UDP_SRC but for the Destination 855 Port ("l4_dst"). 857 UDP_LENGTH designates the EHC Rule compressing / decompressing the 858 Length Field of the UDP header. The length is compressed by the 859 sender and is not sent. The receiver decompresses it by recomputing 860 the Length from the IP address header. The IP address can be IPv4 or 861 IPv6 and UDP_LENGTH MUST support both versions if both versions are 862 supported by the device. 864 UDP_CHECK designates the EHC Rule compressing / decompressing the UDP 865 Checksum. The UDP Checksum is not sent by the sender and the 866 receiver computes from the decompressed UDP payload. UDP_CHECK MUST 867 compute the checksum and not fill the checksum field with zeros. As 868 a result, UDP_CHECK is the last decompressing EHC Rule to be 869 performed on the decompressed UDP Payload. 871 7.5. EHC Rules for UDP-Lite 873 All UDP-lite EHC Rules MUST be performed during the "pre-esp" phase. 874 The EHC Rules are only defined when the Traffic Selectors agreed 875 during the SA negotiation results in a "Single" Protocol ID 876 ("l4_proto") which is set to UDPLite (136). 878 +-------------------+-----------------+----------+------------------+ 879 | EHC Rule | Field | Action | Parameters | 880 +-------------------+-----------------+----------+------------------+ 881 | UDP-LITE_SRC | Source Port | elided | l4_source | 882 | UDP-LITE_DST | Dest. Port | elided | l4_dest | 883 | UDP-LITE_COVERAGE | Checksum | elided | udplite_coverage | 884 | | Coverage | | | 885 | UDP-LITE_CHECK | UDP-Lite | checksum | | 886 | | Checksum | | | 887 +-------------------+-----------------+----------+------------------+ 888 UDP-LITE_SRC works similarly to UDP_SRC 890 UDP-LITE_DST works similarly to UDP_DST 892 UDP-LITE_COVERAGE designates the EHC Rule compressing / decompressing 893 the UDP-Lite Coverage field. UDP-LITE_COVERAGE is only activated 894 when the Coverage ("udplite_coverage") has been agreed with a valid 895 value. The Coverage is compressed / decompressed using the "elided" 896 method. 898 UDP-LITE_CHECK designates the EHC Rule compressing / decompressing 899 the UDP-Lite checksum. UDP-LITE_CHECK is only activated if the 900 Coverage is defined either elided or sent. UDP-LITE_CHECK computes 901 the checksum using "checksum" according to the uncompressed UDP 902 packet and the value of the Coverage. 904 7.6. EHC Rules for TCP 906 All TCP EHC Rules MUST be performed during the "pre-esp" phase. The 907 EHC Rules are only defined when the Traffic Selectors agreed during 908 the SA negotiation results in a"Single" Protocol ID ("l4_proto") 909 which is set to TCP (6). 911 +-------------+-----------------------+----------+------------------+ 912 | EHC Rule | Field | Action | Parameters | 913 +-------------+-----------------------+----------+------------------+ 914 | TCP_SRC | Source Port | elided | l4_source | 915 | TCP_DST | Dest. Port | elided | l4_dest | 916 | TCP_SN | Sequence Number | lsb | tcp_sn, tcp_lsb | 917 | TCP_ACK | Acknowledgment Number | lsb | tcp_ack, tcp_lsb | 918 | TCP_OPTIONS | Data Offset | elided | tcp_options | 919 | | Reserved Bits | elided | | 920 | TCP_CHECK | TCP Checksum | checksum | | 921 | TCP_URGENT | TCP Urgent Field | elided | tcp_urgent | 922 +-------------+-----------------------+----------+------------------+ 924 TCP_SRC works similarly to UDP_SRC. 926 TCP_DST works similarly to UDP_DST. 928 TCP_SN designates the EHC Rule compressing / decompressing the TCP 929 Sequence Number. TCP_SN is only activated if the SN ("tcp_sn") and 930 the LSB significant bytes ("tcp_lsb") are defined. The TCP SN is 931 compressed using "lsb". The sending peer only places the LSB bytes 932 of the TCP SN ("tcp_sn") and the receiving peer retrieve the TCP SN 933 from the LSB bytes carried in the packets as well as from the TCP SN 934 value stored in EHC Context ("tcp_sn"). The two peers MUST agree on 935 the number of LSB bytes to be sent: "tcp_lsb". Upon agreeing on 936 "tcp_lsb", the receiving peer MUST NOT agree on a value not carrying 937 sufficient information to retrieve the full TCP SN. Note also that 938 unlike the ESP SN, the TCP SN is not part of the SA. As a result, 939 when the SN is compressed, the value of the TCP SN MUST be stored in 940 the EHC Context. The reserved attribute for that is "tcp_sn" 942 TCP_ACK designates the EHC Rule compressing / decompressing the TCP 943 Acknowledgment Number and works similarly to TCP SN. Note that 944 "tcp_lsb" is agreed for both TCP SN and TCP Acknowledgment. 945 Similarly the value of the complete TCP Acknowledgment Number MUST be 946 stored in the "tcp_ack" attribute of the EHC Context. 948 TCP_OPTIONS designates the EHC Rule compressing / decompressing TCP 949 options related fields such as Data Offset and Reserved Bits. 950 TCP_OPTION can only be activated when the TCP Option ("tcp_options") 951 is defined. When "tcp_options" is set to "False" and indicates there 952 are no TCP Options, the Data Offsets and Reserved Bits are compressed 953 / decompressed using the "elided" method with Data Offset and 954 Reserved Bits set to zero. 956 TCP_CHECK designates the EHC Rule compressing / decompressing the TCP 957 Checksum. TCP_CHECK works similarly as UDP_CHECK. 959 TCP_URGENT designates the EHC Rule compressing / decompressing the 960 urgent related information. When "tcp_urgent" is set to "False" and 961 indicates there are no TCP Urgent related information, the Urgent 962 Pointer is then "elided" and filled with zeros. 964 8. Diet-ESP EHC Strategy 966 From the attributes of the EHC Context, Diet-ESP defined as an EHC 967 Strategy, which EHC Rules to apply. The EHC Strategy is defined for 968 outbound packets which compresses the packet as well as for inbound 969 packet where the decompression occurs. 971 Diet-ESP results from a compromise between compression efficiency, 972 ease to configure Diet-ESP and the various use cases considered. In 973 order to achieve a great simplicity, 975 o Diet-ESP favors compression methods that required fewer 976 configuration: For IPv6, ip6_tcfl_comp and ip6_hl_com to "Outer" 977 so that ip6_tc, ip6_fl and ip6_hl can be derived from the packet. 978 Similarly, ip4_ttl_comp has is set to "Outer" so ip4_tll can be 979 derived from the packet. 980 o Diet-ESP limits compression method to those foreseen as the most 981 commonly used. As such, esp_sn_gen has been set to "Incremental" 982 as this is the most common method used to generate SN. The other 983 method would be "Time". 985 o Diet-ESP limits compression to the most foreseen scenarios. IPv4 986 compression has been limited in favor of IPv6 as constraint 987 devices have largely adopted IPv6, and the gain versus the 988 complexity to deploy IPv4 inner IP addresses has not been proved. 989 As a result some compressions for IPv4 are not considered by DIet- 990 ESP. This involved compression of the IPv4 options by setting 991 ip4_options to "No_Options". Similarly IPv4 ID compression has 992 not been enabled by setting ip4_id and ip4_id_lsb to 993 "Unspecified". 994 o Diet-ESP negotiated values shared by different rules such as 995 tcp_lsb which is shared for TCP ACK as well as for the TCP SN. 996 o Diet-ESP defines a logic to set the necessary parameters from 997 those agreed by the standard ESP agreement, which limits the 998 setting of parameters. 1000 The following tables shows, which EHC Rules are activated by default 1001 for the supported protocols ESP, IPv4, IPv6, UDP, UDP-Lite and TCP 1002 when using the Diet-ESP strategy and which ones are activated due to 1003 certain circumstances or explicit negotiation 1005 ESP: 1007 +----------+--------------+-------------+------------+ 1008 | EHC Rule | Activated if | Parameter | Value | 1009 +----------+--------------+-------------+------------+ 1010 | ESP_SPI | Diet-ESP | esp_spi_lsb | Negotiated | 1011 | | | esp_spi | In SA | 1012 | ESP_SN | Diet-ESP | esp_sn_lsb | Negotiated | 1013 | | | esp_sn_gen | Negotiated | 1014 | | | esp_sn | In SA | 1015 | ESP_NH | Diet-ESP | ipsec_mode | In SA | 1016 | | | l4_proto | In SA | 1017 | ESP_PAD | Diet-ESP | esp_align | Negotiated | 1018 | | | esp_encr | In SA | 1019 +----------+--------------+-------------+------------+ 1020 IPv4: 1022 +---------------+---------------+------------+-------+ 1023 | EHC Rule | Activated if | Parameter | Value | 1024 +---------------+---------------+------------+-------+ 1025 | IP4_OPT_DIS | ip_version==4 | ip_version | In SA | 1026 | IP4_LENGTH | ip_version==4 | None | | 1027 | IP4_FRAG_DIS | ip_version==4 | None | | 1028 | IP4_TTL_OUTER | ip_version==4 | None | | 1029 | IP4_TTL_OUTER | ip_version==4 | l4_proto | In SA | 1030 | IP4_CHECK | ip_version==4 | None | | 1031 | IP4_SRC | ip_version==4 | ip4_src | In SA | 1032 | IP4_DST | ip_version==4 | ip4_dst | In SA | 1033 +---------------+---------------+------------+-------+ 1035 IPv6: 1037 +--------------+---------------+------------+-------+ 1038 | EHC Rule | Activated if | Parameter | Value | 1039 +--------------+---------------+------------+-------+ 1040 | IP6_OUTER | ip_version==6 | ip_version | In SA | 1041 | IP6_LENGTH | ip_version==6 | None | | 1042 | IP6_NH | ip_version==6 | l4_proto | In SA | 1043 | IP6_HL_OUTER | ip_version==6 | None | | 1044 | IP6_SRC | ip_version==6 | ip6_src | In SA | 1045 | IP6_DST | ip_version==6 | ip6_dst | In SA | 1046 +--------------+---------------+------------+-------+ 1048 UDP: 1050 +------------+--------------+-----------+-------+ 1051 | EHC Rule | Activated if | Parameter | Value | 1052 +------------+--------------+-----------+-------+ 1053 | UDP_SRC | l4_proto==17 | l4_source | In SA | 1054 | UDP_DST | l4_proto==17 | l4_dest | In SA | 1055 | UDP_LENGTH | l4_proto==17 | None | | 1056 | UDP_CHECK | l4_proto==17 | None | | 1057 +------------+--------------+-----------+-------+ 1058 UDP-Lite: 1060 +-------------------+---------------+------------------+------------+ 1061 | EHC Rule | Activated if | Parameter | Value | 1062 +-------------------+---------------+------------------+------------+ 1063 | UDP_LITE_SRC | l4_proto==136 | l4_source | In SA | 1064 | UDP_LITE_DST | l4_proto==136 | l4_dest | In SA | 1065 | UDP_LITE_COVERAGE | l4_proto==136 | udplite_coverage | Negotiated | 1066 | UDP_LITE_CHECK | l4_proto==136 | None | | 1067 +-------------------+---------------+------------------+------------+ 1069 TCP: 1071 +-------------+--------------+-------------+------------+ 1072 | EHC Rule | Activated if | Parameter | Value | 1073 +-------------+--------------+-------------+------------+ 1074 | TCP_SRC | l4_proto==6 | l4_source | In SA | 1075 | TCP_DST | l4_proto==6 | l4_dest | In SA | 1076 | TCP_SN | l4_proto==6 | tcp_sn | In SA | 1077 | | | tcp_lsb | Negotiated | 1078 | TCP_ACK | l4_proto==6 | tcp_ack | In SA | 1079 | | | tcp_lsb | Negotiated | 1080 | TCP_OPTIONS | l4_proto==6 | tcp_options | Negotiated | 1081 | TCP_CHECK | l4_proto==6 | None | | 1082 | TCP_URGENT | l4_proto==6 | tcp_urgent | Negotiated | 1083 +-------------+--------------+-------------+------------+ 1085 Thus, the parameters that the two peers needs to agree on are: 1087 o esp_sn_lsb 1088 o esp_spi_lsb 1089 o esp_align 1090 o udplite_coverage 1091 o tcp_lsb 1092 o tcp_options 1093 o tcp_urgent 1095 Implementation may differ from the description below. However, the 1096 outcome MUST remain the same. 1098 8.1. Outbound Packet Processing 1100 Diet-ESP compression is defined as follows: 1102 1. In phase "pre-esp": Match the inbound packet with the SA and 1103 determine if the Diet-ESP EHC Strategy has been activated. If 1104 the Diet-ESP EHC Strategy has been activated proceed to next 1105 step, otherwise skip all steps associated to Diet-ESP and proceed 1106 to the standard ESP as defined in [RFC4303] 1107 2. In phase "pre-esp": If "l4_proto" designates a "Single" Protocol 1108 ID (UDP, TCP or UDP-Lite), proceed to the compression of the 1109 specific layer. Otherwise, the transport layer is not 1110 compressed. 1111 3. In phase "clear text esp": If "ipsec_mode" is set to "Tunnel" 1112 mode, determine "ip_version" the IP version of the inner IP 1113 addresses and proceed to the appropriated inner IP address 1114 compression. 1115 4. In phase "clear text esp" and "post-esp": Proceed to the ESP 1116 compression. 1118 UDP compression is defined as below: 1120 1. If "l4_src" designates a "Single" Source Port, apply UDP_SRC to 1121 compress the Source Port. 1122 2. If "l4_dst" designates a "Single" Destination Port, apply UDP_DST 1123 to compress the Destination Port. 1124 3. Apply UDP_CHECK to compress the Checksum. 1125 4. Apply UDP_LENGTH to compress the Length. 1127 UDP-lite compression is defined as below: 1129 1. If "l4_src" designates a "Single" Source Port, apply the UDP- 1130 LITE_SRC to compress the Source Port. 1131 2. If "l4_dst" designates a "Single" Destination Port, apply the 1132 UDP-LITE_DST, to compress the Destination Port. 1133 3. If "udplite_coverage" is specified, apply the UDP-LITE_COVERAGE, 1134 to compress the Coverage. 1135 4. Apply UDP-LITE_CHECK to compress the Checksum. 1137 TCP compression is defined as below: 1139 1. If "l4_src" designates a "Single" Source Port than apply the 1140 TCP_SRC to compress the Source Port. 1141 2. If "l4_dst" designates a "Single" Destination Port than apply the 1142 TCP_DST to compress the Destination Port. 1143 3. If "tcp_lsb" is lower than 4, then "tcp_sn" "tcp_ack" attributes 1144 of the Diet-ESP Context are updated with the value provided from 1145 the packet before applying the TCP_SN and the TCP_ACK EHC Rules. 1146 4. If "tcp_options" is set to "False" apply the TCP_OPTIONS EHC 1147 Rule. 1148 5. If "tcp_urgent" is set to "False" apply the TCP_URGENT EHC Rule. 1149 6. Apply TCP_CHECK to compress the Checksum. 1151 Inner IPv6 Header compression is defined as below: 1153 1. If "ip6_src" designates a "Single" Source IP address, apply the 1154 IP6_SRC to compress the IPv6 Source Address. 1155 2. If "ip6_dst" designates a "Single" Destination IP address, apply 1156 the IP6_DST to decompress the IPv6 Destination Address. 1157 3. Apply IPv6_HL_OUTER to compress the Hop Limit. 1158 4. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP- 1159 Lite), apply IP6_NH to compress the Next Header. 1160 5. Apply, IP6_LENGTH to compress the Length. 1161 6. Apply IP6_OUTER to compress Version, Traffic Class and Flow 1162 Label. 1164 Inner IPv4 Header compression is defined as below: 1166 1. Apply, IP4_LENGTH to compress the Length. 1167 2. Apply IP4__TTL_OUTER to compress Time To Live. 1168 3. Apply, IP4_CHECK to compress the IPv4 header checksum. 1169 4. If "ip4_src" designates a "Single" Source IP address, apply the 1170 IP4_SRC to compress the IPv4 Source Address. 1171 5. If "ip4_dst" designates a "Single" Destination IP address, apply 1172 the IP4_DST to decompress the IPv4 Destination Address. 1174 ESP compression is defined as below: 1176 1. In phase "clear text esp": If "ipsec_mode" is set to "Tunnel" or 1177 "l4_proto" is set to a "Single value - eventually different from 1178 TCP, UDP or UDP-Lite, apply ESP_NH, to compress the Next Header. 1179 2. In phase "clear text esp": If "esp_encr" specify an encryption 1180 algorithm that does not provide padding, then apply ESP_PAD to 1181 compress the Pad Length and Padding. 1182 3. Proceed to the ESP encryption as defined in [RFC4303]. 1183 4. In phase "post-esp: If "esp_sn_lsb" is different from 4, then 1184 apply ESP_SN. To compress the ESP SN. 1185 5. In phase "post-esp": If "esp_spi_lsb" is different from 4, then 1186 apply ESP_SPI to compress the SPI. 1188 8.2. Inbound Packet Processing 1190 Diet-ESP decompression is defined as follows: 1192 1. Match the inbound packet with the SA and determine if the Diet- 1193 ESP EHC Strategy has been activated. When Diet-ESP is activated 1194 this means that the "esp_spi_lsb" are sufficient to index the SA 1195 and proceed to next step, otherwise skip all steps associated to 1196 Diet-ESP and proceed to the standard ESP as defined in [RFC4303] 1197 2. In phase "clear text esp" and "post-esp": Proceed to the ESP 1198 decompression. 1199 3. In phase "clear text esp": If "ipsec_mode" is set to "Tunnel" 1200 mode, determine "ip_version" the IP version of the inner IP 1201 addresses and proceed to the appropriated inner IP address 1202 decompression, except for the computation of the checksums and 1203 length. 1204 4. In phase "pre-esp": If "l4_proto" designates a "Single" Protocol 1205 ID (UDP, TCP or UDP-Lite), proceed to the decompression of the 1206 specific layer, except for the computation of the checksums and 1207 length replaced by zero fields. 1208 5. In phase "pre-esp": Proceed to the decompression of the checksums 1209 and length. 1211 ESP decompression is defined as follows: 1213 1. In phase "post-esp": If "esp_spi_lsb" is different from 4, then 1214 apply ESP_SPI to decompress the SPI. 1215 2. In phase "post-esp: If "esp_sn_lsb" is different from 4, then 1216 apply ESP_SN. To decompress the ESP SN. 1217 3. Proceed to the ESP signature validation and decryption as defined 1218 in [RFC4303]. 1219 4. In phase "clear text esp": If "ipsec_mode" is set to "Tunnel" or 1220 "l4_proto" is set to a "Single value - eventually different from 1221 TCP, UDP or UDP-Lite, apply ESP_NH, to decompress the Next 1222 Header. 1223 5. In phase "clear text esp": If "esp_encr" specify an encryption 1224 algorithm that does not provide padding, then apply ESP_PAD to 1225 compress the Pad Length and Padding. 1226 6. Extract the ESP Data Payload and apply decompression EHC Rule to 1227 the ESP Data Payload. 1229 UDP decompression is defined as follows: 1231 1. If "l4_src" designates a "Single" Source Port, apply UDP_SRC to 1232 decompress the Source Port. 1233 2. If "l4_dst" designates a "Single" Destination Port, apply UDP_DST 1234 to decompress the Destination Port. 1235 3. Apply UDP_LENGTH to compress the Length. The length value is 1236 computed from the length provided by the lower layer, with the 1237 additional added bytes during the UDP decompression including the 1238 length size. 1239 4. Apply UDP_CHECK to decompress the Checksum. 1240 5. Update the Length of the lower layers: 1242 1. If "ipsec_mode" is set to "Transport" mode, update the Length 1243 of the outer IP header (IPv4 or IPv6). The Length is 1244 incremented by the number of bytes generated by the 1245 decompression of the transport layer. 1246 2. If "ipsec_mode" is set to "Tunnel" mode, update the Length of 1247 the inner IP address (IPv4 or IPv6) as well as the outer IP 1248 header (IPv4 or IPv6). The Length is incremented by the 1249 number of bytes generated by the decompression of the 1250 transport layer. 1252 UDP-Lite decompression is defined as follows: 1254 1. If "l4_src" designates a "Single" Source Port, apply the UDP- 1255 LITE_SRC to decompress the Source Port. 1256 2. If "l4_dst" designates a "Single" Destination Port, apply the 1257 UDP-LITE_DST, to decompress the Destination Port. 1258 3. If "udplite_coverage" is specified, apply the UDP-LITE_COVERAGE, 1259 to decompress the Coverage. 1260 4. Apply UDP-LITE_CHECK to compress the Checksum. 1261 5. Update the Length of the lower layers as defined in UDP. 1263 TCP decompression is defined as follows: 1265 1. If "l4_src" designates a "Single" Source Port than apply the 1266 TCP_SRC to decompress the Source Port. 1267 2. If "l4_dst" designates a "Single" Destination Port than apply the 1268 TCP_DST to decompress the Destination Port. 1269 3. If "tcp_lsb" is lower than 4, apply TCP_SN and the TCP_ACK to 1270 decompress the TCP Sequence Number and the TCP Acknowledgment 1271 Number. 1272 4. If "tcp_options" is set to "False" apply TCP_OPTIONS to 1273 decompress Data Offset and Reserved Bits. 1274 5. If "tcp_urgent" is set to "False" apply the TCP_URGENT to 1275 decompress the Urgent Pointer. 1276 6. Apply TCP_CHECK to decompress the Checksum. 1278 Inner IPv6 decompression is defined as follows: 1280 1. Apply IP6_OUTER to decompress Version, Traffic Class and Flow 1281 Label. 1282 2. Set the Length to zero. 1283 3. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP- 1284 Lite), apply IP6_NH to decompress the Next Header. 1285 4. Hop Limit is decompressed with IP6_HL_OUTER (with "ip6_hl_comp" 1286 set to "Outer"). 1287 5. If the "ip6_src" designates a "Single" Source IP address, apply 1288 the IP6_SRC to de compress the IPv6 Source Address. 1289 6. If the "ip6_dst" designates a "Single" Destination IP address 1290 than apply the IP6_DST to decompress the IPv6 Destination 1291 Address. 1292 7. Apply, IP6_LENGTH to provide the replace the zero length value by 1293 its appropriated appropriated value. The Length value considers 1294 the length provided by the lower layers to which are added the 1295 additional bytes due to the decompression, minus the length of 1296 the inner IP6 Header. 1298 Inner IPv4 decompression is defined as follows: 1300 1. Apply, IP4_LENGTH to provide the replace the zero length value by 1301 its appropriated appropriated value. The Length value considers 1302 the length provided by the lower layers to which are added the 1303 additional bytes due to the decompression, minus the length of 1304 the inner IPv4 Header. The value computed from the lower layer 1305 will have to be overwritten in case further decompression occurs. 1306 2. Apply IP4_TTL_OUTER to decompress Time To Live. 1307 3. If "l4_proto" designates a "Single" Protocol ID (UDP, TCP or UDP- 1308 Lite), apply IP4_PROT to decompress the Protocol Field. 1309 4. If "ip4_src" designates a "Single" Source IP address, apply the 1310 IP4_SRC to de compress the IPv4 Source Address. 1311 5. If "ip4_dst" designates a "Single" Destination IP address than 1312 apply the IP4_DST to decompress the IPv4 Destination Address. 1313 6. Apply IP4_CHECK to decompress the checksum of the IPv4 header 1315 9. IANA Considerations 1317 There are no IANA consideration for this document. 1319 10. Security Considerations 1321 This section lists security considerations related to the Diet-ESP 1322 protocol. 1324 Security Parameter Index (SPI): 1325 The Security Parameter Index (SPI) is used by the receiver to 1326 index the Security Association that contains appropriated 1327 cryptographic material. If the SPI is not found, the packet is 1328 rejected as no further checks can be performed. In EHC, the value 1329 of the SPI is not reduced, but compressed why the SPI value may 1330 not be fully provided between the compressor and the de- 1331 compressor. On the other hand, its uncompressed value is provided 1332 to the ESP-procession and no weakness is introduced to ESP itself. 1333 On an implementation perspective, it is strongly recommended that 1334 decompression is deterministic. Compression and decompression 1335 adds some additional treatment to the ESP packet, which might be 1336 used by an attacker. In order to minimize the load associated to 1337 decompression, decompression is expected to be deterministic. The 1338 incoming compressed SPI with the associated IP addresses should 1339 output a single and unique uncompressed SPI value. If an 1340 uncompressed SPI values have to be considered, then the receiver 1341 could end in n signature checks which may be used by an attacker 1342 for a DoS attack. 1343 Sequence Numer (SN): 1344 The Sequence Number (SN) is used as an anti-replay attack 1345 mechanism. Compression and decompression of the SN is already 1346 part of the standard ESP namely the Extended Sequence Number 1347 (ESN). The SN in a standard ESP packet is 32 bit long, whether 1348 EHC enables to reduce it to 0 bytes and the main limitation to the 1349 compression a deterministic decompression. SN compression 1350 consists in indicating the least significant bits of the 1351 uncompressed SN on the wire. The size of the compressed SN must 1352 consider the maximum reordering index such that the probability 1353 that a later sent packet arrives before an earlier one. In 1354 addition the size of SN should also consider maximum consecutive 1355 packets lost during transmission. In the case of ESP, this number 1356 is set to 2^32 which is, in most real world case, largely over- 1357 provisioned. When the compression of the SN is not appropriately 1358 provisioned, the most significant bit value may be de-synchronized 1359 between the sending and receiving parties. Although IKEv2 1360 provides some re-synchronization mechanisms, in case of IoT the 1361 de-synchronization will most likely result in a renegotiation and 1362 thus DoS possibilities. Note that IoT communication may also use 1363 some external parameters, i.e. other than the compressed SN, to 1364 define whether a packet be considered or not and eventually derive 1365 the SN. One such scenario may be the use of time windows. 1366 Suppose a device is expected to send some information every hour 1367 or every week. In this case, for example, the SN may be 1368 compressed to zero bytes. Instead the SN may be derived by 1369 incrementing the SN every hour after the last received valid 1370 packet. Considering the time the packet is received make it 1371 possible to consider the time derivation of the sensor clock. If 1372 TIME is used as the method to generate the SN, the receiver MUST 1373 ensure that the esp_sn_lsb is big enough to resist time 1374 differences between the nodes. Note also that the anti-replay 1375 mechanism needs to define the size of the anti-replay 1376 window.[RFC4303] provides guidance to set the window size and are 1377 similar to those used to define the size of the compressed SN. 1379 11. Privacy Considerations 1381 Security Parameter Index (SPI): 1382 Until Diet-ESP is not deployed outside the scope of IoT and small 1383 devices, the use of a compressed SPI may provide an indication 1384 that one of the endpoint is a sensor. Such information may be 1385 used, for example, to evaluate the number of appliances deployed, 1386 or - in addition with other information, such as the time 1387 interval, the geographic location - be used to derive the type of 1388 data transmitted. 1389 Sequence Number (SN): If incremented for each ESP packet, the SN may 1390 leak some information like the amount of transmitted data or the 1391 age of the sensor. The age of the sensor may be correlated with 1392 the software used and the potential bugs. On the other hand, re- 1393 keying will re-initialize the SN, but the cost of a re-keying may 1394 not be negligible and thus, frequent re-keying can be considered. 1395 In addition to the re-key operation, the SN may be generated in 1396 order to reduce the accuracy of the information leaked. In fact, 1397 the SN does not have to be incremented by one for each packet it 1398 just has to be an increasing function. Using a function such as a 1399 TIME may prevent characterizing the age or the use of the sensor. 1400 Note that the use of such function may also impact the compression 1401 efficiency and result in larger compressed SN. 1403 12. Acknowledgment 1405 We would like to thank Orange and Universitee Pierre et Marie Curie 1406 for initiating the work on Diet-ESP. We Would like to thank Sylvain 1407 Killian for implementing an open source Diet-ESP on Contiki and 1408 testing it on the FIT IoT-LAB [fit-iot-lab] funded by the French 1409 Ministry of Higher Education and Research. We thank the IoT-Lab Team 1410 and the INRIA for maintaining the FIT IoT-LAB platform and for 1411 providing feed backs in an efficient way. 1413 We would like to thank Bob Moskowitz for not copyrighting Diet HIP. 1414 The "Diet" terminology is from him. 1416 We would like to thank those we received many useful feed backs among 1417 others: Dominique Bartel, Anna Minaburo, Suresh Krishnan, Samita 1418 Chakrabarti, Michael Richarson, Tero Kivinen. 1420 13. References 1422 13.1. Normative References 1424 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1425 DOI 10.17487/RFC0791, September 1981, 1426 . 1428 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1429 Requirement Levels", BCP 14, RFC 2119, 1430 DOI 10.17487/RFC2119, March 1997, 1431 . 1433 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1434 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1435 . 1437 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 1438 Mode with IPsec Encapsulating Security Payload (ESP)", 1439 RFC 4309, DOI 10.17487/RFC4309, December 2005, 1440 . 1442 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1443 "Transmission of IPv6 Packets over IEEE 802.15.4 1444 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 1445 . 1447 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 1448 Header Compression (ROHC) Framework", RFC 5795, 1449 DOI 10.17487/RFC5795, March 2010, 1450 . 1452 [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec 1453 Extensions to Support Robust Header Compression over 1454 IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010, 1455 . 1457 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 1458 IPv6 over Low-Power Wireless Personal Area Networks 1459 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 1460 2014, . 1462 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1463 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1464 May 2017, . 1466 13.2. Informational References 1468 [I-D.toutain-6lpwa-ipv6-static-context-hc] 1469 Minaburo, A. and L. Toutain, "6LPWA Static Context Header 1470 Compression (SCHC) for IPV6 and UDP", draft-toutain-6lpwa- 1471 ipv6-static-context-hc-01 (work in progress), June 2016. 1473 [I-D.mglt-ipsecme-implicit-iv] 1474 Migault, D., Guggemos, T., and Y. Nir, "Implicit IV for 1475 Counter-based Ciphers in IPsec", draft-mglt-ipsecme- 1476 implicit-iv-04 (work in progress), June 2017. 1478 [I-D.ietf-tsvwg-udp-options] 1479 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 1480 udp-options-07 (work in progress), March 2019. 1482 [fit-iot-lab] 1483 "Future Internet of Things (FIT) IoT-LAB", 1484 . 1486 Appendix A. Illustrative Examples 1488 A.1. Single UDP Session IoT VPN 1490 This section considers a IoT IPv6 probe hosting a UDP application. 1491 The probe is dedicated to a single application and establishes a 1492 single UDP session. As a result, inner IP addresses and UDP Ports 1493 have a "Single" value and can be easily compressed. The probes sets 1494 an IPsec VPN using IPv6 addresses in order to connect its secure 1495 domain - typically a Home Gateway. The use of IPv6 for inner and 1496 outer IP addresses, enables to infer inner IP fields from the outer 1497 IP address. The probes encrypts with AES-CCM_8 [RFC4309]. AES-CCM 1498 does not have padding, so the padding is performed by ESP. The 1499 probes uses an 8 bit alignment which enables to fully compress the 1500 ESP Trailer. In addition, as the probe SA is indexed using the outer 1501 IP addresses (or eventually the radio identifiers) which enables to 1502 fully compress the SPI. As the probe provides information every 1503 hour, the Sequence Number using time can be derived from the received 1504 time, which enables to fully compress the SN. 1506 Figure 3 represents the original UDP packet and Figure 4 represents 1507 the corresponding packet compressed with Diet-ESP. The compression 1508 with Diet-ESP results in a reduction of 61 bytes overhead. With IPv4 1509 inner IP addressed Diet-ESP results in an 45 byte overhead reduction. 1511 Further compression may be done for example by using an implicit IV 1512 [I-D.mglt-ipsecme-implicit-iv] and by compressing the outer IP 1513 addresses (not represented) on the figure. In addition, application 1514 data may also be compressed with mechanisms outside of the scope of 1515 Diet-ESP. 1517 0 1 2 3 1518 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 1519 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1520 E| Security Parameters Index (SPI) | ^ 1521 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1522 P| Sequence Number (SN) | | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1524 | | | 1525 | IV | | 1526 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1527 I|version| traffic class | flow label |^ | 1528 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1529 v| payload length | next header | hop limit || | 1530 6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1531 | || a 1532 | inner source IP || u 1533 | |e t 1534 | |n h 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e 1536 | |r n 1537 | inner destination IP |y t 1538 | |p i 1539 | |t c 1540 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1541 U| source port | dest port |d t 1542 D+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1543 P| length | checksum || d 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 3: Standard ESP 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-- 1562 | | ^ 1563 | IV | | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ aut 1565 | | hen 1566 ~ APPLICATION DATA ~ tic 1567 | (encrypted) | ate 1568 | +-+-+-+-+-+-+-+-+ | 1569 | | | V 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-- 1571 | Integrity Check Value-ICV (variable) | 1572 | +-+-+-+-+-+-+-+-+ 1573 | | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 Figure 4: Diet-ESP Single UDP Session IoT VPN Packet Description 1578 The following table illustrates the activated rules and the 1579 attributes of the Diet-ESP Context that needs an explicit agreement 1580 to achieve the compression. All other attributes used by the rules 1581 are part of the SA agreement. Parameters of not activated rules are 1582 left "Unspecified". 1584 +--------------+-------------------+-------+ 1585 | EHC Rule | Context Attribute | Value | 1586 +--------------+-------------------+-------+ 1587 | ESP_SPI | esp_spi_lsb | 0 | 1588 | ESP_SN | esp_sn_lsb | 0 | 1589 | | esp_sn_gen | | 1590 | ESP_NH | | | 1591 | ESP_PAD | esp_align | 8 | 1592 | | | | 1593 | IP6_OUTER | ip6_tcfl_comp | | 1594 | | ip6_hl_comp | | 1595 | IP6_LENGTH | | | 1596 | IP6_NH | | | 1597 | IP6_HL_OUTER | | | 1598 | IP6_SRC | | | 1599 | IP6_DST | | | 1600 | | | | 1601 | UDP_SRC | | | 1602 | UDP_DST | | | 1603 | UDP_LENGTH | | | 1604 | UDP_CHECK | | | 1605 +--------------+-------------------+-------+ 1607 A.2. Single TCP session IoT VPN 1609 This section considers the same probe as described in Appendix A.1 1610 but instead of using UDP as a transport layer, the probe uses TCP. 1611 In this case TCP is used with no options, no urgent pointers and the 1612 SN and ACK Number are compressed to 2 bytes as the throughput is 1613 expected to be low. 1615 Figure 5 represents the original TCP packet and Figure 6 represents 1616 the corresponding packet compressed with Diet-ESP. The compression 1617 with Diet-ESP results in a reduction of 66 bytes overhead. With IPv4 1618 inner address Diet-ESP results in a 50 byte overhead reduction. 1620 0 1 2 3 1621 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 1622 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1623 E| Security Parameters Index (SPI) | ^ 1624 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1625 P| Sequence Number (SN) | | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1627 | | | 1628 | IV | | 1629 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1630 I|version| traffic class | flow label |^ | 1631 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1632 v| payload length | next header | hop limit || | 1633 6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1634 | || a 1635 | inner source IP || u 1636 | |e t 1637 | |n h 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e 1639 | |r n 1640 | inner destination IP |y t 1641 | |p i 1642 | |t c 1643 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1644 T| source port | dest port |d t 1645 C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1646 P| Sequence Number (SN) || d 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1648 | ACK Sequence Number || | 1649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1650 |Off. | Rserv | Flags | Window Size || | 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1652 | Checksum | Urgent Pointer || | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1654 | || | 1655 ~ APPLICATION DATA ~| | 1656 | || | 1657 | +-+-+-+-+-+-+-+-+| | 1658 E| | Padding || | 1659 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1660 P| Padding (continue) | Pad Length | Next Header |V V 1661 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1662 | Integrity Check Value-ICV (variable) | 1663 | | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 Figure 5: Standard IoT Single TCP Session VPN Packet Description 1668 0 1 2 3 1669 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 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---a 1671 | | ^u 1672 | IV | |t 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|h 1674 | Sequence Number (SN) | ACK Sequence Number |^e|e 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|n 1676 | Flags | Window Size | ||c|t 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||r|i 1678 | ~|y|c 1679 ~ APPLICATION DATA ||p|a 1680 | ||t|t 1681 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|e 1682 | | |vdvd 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |--- 1684 | Integrity Check Value-ICV (variable) | 1685 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 | | 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 Figure 6: Diet-ESP Single TCP Session IoT VPN Packet Description 1691 The following table illustrates the activated rules and the 1692 attributes of the Diet-ESP Context that needs an explicit agreement 1693 to achieve the compression. All other attributes used by the rules 1694 are part of the SA agreement. Parameters of not activated rules are 1695 left "Unspecified". Note for simplicity, tcp_sn and tcp_ack are 1696 negotiated to start with 0, but it could be any other value as well. 1698 +--------------+-------------------+---------+ 1699 | EHC Rule | Context Attribute | Value | 1700 +--------------+-------------------+---------+ 1701 | ESP_SPI | esp_spi_lsb | 0 | 1702 | ESP_SN | esp_sn_lsb | 0 | 1703 | | esp_sn_gen | | 1704 | ESP_NH | | | 1705 | ESP_PAD | esp_align | 8 | 1706 | | | | 1707 | IP6_OUTER | ip6_tcfl_comp | | 1708 | | ip6_hl_comp | | 1709 | IP6_LENGTH | | | 1710 | IP6_NH | | | 1711 | IP6_HL_OUTER | | | 1712 | IP6_SRC | | | 1713 | IP6_DST | | | 1714 | | | | 1715 | TCP_SRC | | | 1716 | TCP_DST | | | 1717 | TCP_SN | tcp_lsb | 2 | 1718 | | tcp_sn | 0 | 1719 | TCP_ACK | tcp_lsb | 2 | 1720 | | tcp_ack | 0 | 1721 | TCP_OPTIONS | tcp_options | "False" | 1722 | TCP_CHECK | | | 1723 | TCP_URGENT | tcp_urgent | "False" | 1724 +--------------+-------------------+---------+ 1726 A.3. Traditional VPN 1728 This section illustrates the case of an company VPN. The VPN is 1729 typically set by a remote host that forwards all its traffic to the 1730 security gateway. As transport protocols are "Unspecified", 1731 compression is limited to ESP and the inner IP header. For the inner 1732 IP header, the Destination IP address is "Unspecified" so the 1733 compression of the inner IP address excludes the Destination IP 1734 address. Similarly, the inner IP Next Header cannot be compressed as 1735 the transport layer is not specified. For ESP, the security gateway 1736 may only have a sufficiently low number of remote users with 1737 relatively low throughput in which case SPI and SN can be compressed 1738 to 2 bytes. As throughput remains relatively low, the alignment may 1739 also set to 8 bits. 1741 A.3.1. IPv6 in IPv6 1743 Figure 7 represents the original TCP packet with IPv6 inner IP 1744 addresses and Figure 8 represents the corresponding packet compressed 1745 with Diet-ESP. The compression with Diet-ESP results in a reduction 1746 of 32 bytes. 1748 0 1 2 3 1749 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 1750 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1751 E| Security Parameters Index (SPI) | ^ 1752 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1753 P| Sequence Number (SN) | | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1755 | | | 1756 | IV | | 1757 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1758 I|version| traffic class | flow label |^ | 1759 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1760 v| payload length | next header | hop limit || | 1761 6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1762 | || a 1763 | inner source IP || u 1764 | |e t 1765 | |n h 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e 1767 | |r n 1768 | inner destination IP |y t 1769 | |p i 1770 | |t c 1771 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1772 T| source port | dest port |d t 1773 C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1774 P| Sequence Number (SN) || d 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1776 | ACK Sequence Number || | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1778 |Off. | Rserv | Flags | Window Size || | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1780 | Checksum | Urgent Pointer || | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1782 | || | 1783 ~ APPLICATION DATA ~| | 1784 | || | 1785 -| +-+-+-+-+-+-+-+-+| | 1786 E| | Padding || | 1787 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1788 P| Padding (continue) | Pad Length | Next Header |V V 1789 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1790 | Integrity Check Value-ICV (variable) | 1791 | | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 Figure 7: Standard ESP VPN Packet Description 1796 0 1 2 3 1797 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 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1799 | SPI | SN | ^ 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1801 | | | 1802 | IV | | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| 1804 | Next Header | |^ | 1805 +-+-+-+-+-+-+-+-+ || | 1806 | || | 1807 | inner destination IP || | 1808 | || |a 1809 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |u 1810 | | source port | dest. port ~|e|t 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|h 1812 ~ (continue) | TCP Sequence Number (SN) ~|c|e 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|r|n 1814 ~ (continue) | ACK Sequence Number (SN) ~|y|t 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|p|i 1816 ~ (continue) |Off. | Rserv | Flags | Window Size ~|t|c 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|a 1818 ~ (continue) | Checksum | Urgent ~|d|t 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |e 1820 ~ Pointer | || |d 1821 +-+-+-+-+-+-+-+-+ || | 1822 ~ APPLICATION DATA ~| | 1823 | || | 1824 | |v v 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1826 | Integrity Check Value-ICV (variable) | 1827 | | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 Figure 8: Diet-ESP VPN Packet Description 1832 The following table illustrates the activated rules and the 1833 attributes of the Diet-ESP Context that needs an explicit agreement 1834 to achieve the compression. All other attributes used by the rules 1835 are part of the SA agreement. Parameters of not activated rules are 1836 left "Unspecified". 1838 +--------------+-------------------+-------+ 1839 | EHC Rule | Context Attribute | Value | 1840 +--------------+-------------------+-------+ 1841 | ESP_SPI | esp_spi_lsb | 2 | 1842 | ESP_SN | esp_sn_lsb | 2 | 1843 | | esp_sn_gen | | 1844 | ESP_NH | | | 1845 | ESP_PAD | esp_align | 8 | 1846 | | | | 1847 | IP6_OUTER | ip6_tcfl_comp | | 1848 | IP6_LENGTH | | | 1849 | IP6_HL_OUTER | ip6_hl_comp | | 1850 | IP6_SRC | | | 1851 +--------------+-------------------+-------+ 1853 A.3.2. IPv6 in IPv4 1855 If the compressed inner IP header is an IPv6, but the outer IP header 1856 is an IPv4 header, the activated rules differ, as IP6_OUTER cannot be 1857 used. Instead, ip6_tcfl_comp and ip6_hl_comp are set to "Value". 1858 The resulting ESP packet is the same as in Figure 8. 1860 +--------------+-------------------+-------+ 1861 | EHC Rule | Context Attribute | Value | 1862 +--------------+-------------------+-------+ 1863 | ESP_SPI | esp_spi_lsb | 2 | 1864 | ESP_SN | esp_sn_lsb | 2 | 1865 | | esp_sn_gen | | 1866 | ESP_NH | | | 1867 | ESP_PAD | esp_align | 8 | 1868 | | | | 1869 | IP6_OUTER | ip6_tcfl_comp | | 1870 | IP6_LENGTH | | | 1871 | IP6_HL_OUTER | ip6_hl_comp | | 1872 | IP6_SRC | | | 1873 +--------------+-------------------+-------+ 1875 A.3.3. IPv4 in IPv4 1877 Figure 9 represents the original TCP packet with IPv4 inner IP 1878 addresses and Figure 10 represents the corresponding packet 1879 compressed with Diet-ESP. The compression with Diet-ESP results in a 1880 reduction of 24 bytes. 1882 0 1 2 3 1883 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 1884 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1885 E| Security Parameters Index (SPI) | ^ 1886 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1887 P| Sequence Number (SN) | | 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1889 | | | 1890 | IV | | 1891 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | 1892 I|Version| IHL |Type of Service| Total Length |^ | 1893 P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1894 v| Identification |Flags| Fragment Offset || a 1895 4+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| u 1896 | Time to Live | Protocol | Header Checksum |e t 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n h 1898 | Source Address |c e 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+r n 1900 | Destination Address |y t 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+p i 1902 | Options | Padding |t c 1903 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a 1904 T| source port | dest port |d t 1905 C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e 1906 P| Sequence Number (SN) || d 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1908 | ACK Sequence Number || | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1910 |Off. | Rserv | Flags | Window Size || | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1912 | Checksum | Urgent Pointer || | 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1914 | || | 1915 ~ APPLICATION DATA ~| | 1916 | || | 1917 -| +-+-+-+-+-+-+-+-+| | 1918 E| | Padding || | 1919 S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | 1920 P| Padding (continue) | Pad Length | Next Header |V V 1921 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1922 | Integrity Check Value-ICV (variable) | 1923 | | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 Figure 9: Standard ESP VPN Packet Description 1928 0 1 2 3 1929 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 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1931 | SPI | SN | ^ 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1933 | | | 1934 | IV | | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--| 1936 |Type of Service| Protocol | inner destination IP ~^ | 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|| | 1938 ~ (continue) | source port || |a 1939 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |u 1940 | destination port | TCP Sequence Number (SN) ~|e|t 1941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|h 1942 ~ (continue) | ACK Sequence Number ~|c|e 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|r|n 1944 ~ (continue) |Off. | Rserv | Flags ||y|t 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|p|i 1946 | Window Size | Checksum ||t|c 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|e|a 1948 | Urgent Pointer | APPLICATION DATA ||d|t 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| |e 1950 ~ || |d 1951 | || | 1952 | |v v 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 1954 | Integrity Check Value-ICV (variable) | 1955 | | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 Figure 10: Diet-ESP VPN Packet Description 1960 The following table illustrates the activated rules and the 1961 attributes of the Diet-ESP Context that needs an explicit agreement 1962 to achieve the compression. All other attributes used by the rules 1963 are part of the SA agreement. Parameters of not activated rules are 1964 left "Unspecified". 1966 +---------------+-------------------+---------------+ 1967 | EHC Rule | Context Attribute | Value | 1968 +---------------+-------------------+---------------+ 1969 | ESP_SPI | esp_spi_lsb | 2 | 1970 | ESP_SN | esp_sn_lsb | 2 | 1971 | | esp_sn_gen | "Incremental" | 1972 | ESP_NH | | | 1973 | ESP_PAD | esp_align | 8 | 1974 | | | | 1975 | IP4_OPT_DIS | | | 1976 | IP4_LENGTH | | | 1977 | IP4_FRAG_DIS | | | 1978 | IP4_TTL_OUTER | | | 1979 | IP4_CHECK | | | 1980 | IP4_SRC | | | 1981 +---------------+-------------------+---------------+ 1983 A.3.4. IPv4 in IPv6 1985 If the compressed inner IP header is an IPv4, but the outer IP header 1986 is an IPv6 header, the activated rules differ, as IP4_TTL_OUTER 1987 cannot be used. Instead, IP4_TTL_VALUE is used. The resulting ESP 1988 packet is the same as in Figure 10. 1990 +--------------+-------------------+---------------+ 1991 | EHC Rule | Context Attribute | Value | 1992 +--------------+-------------------+---------------+ 1993 | ESP_SPI | esp_spi_lsb | 2 | 1994 | ESP_SN | esp_sn_lsb | 2 | 1995 | | esp_sn_gen | "Incremental" | 1996 | ESP_NH | | | 1997 | ESP_PAD | esp_align | 8 | 1998 | | | | 1999 | IP4_OPT_DIS | | | 2000 | IP4_LENGTH | | | 2001 | IP4_FRAG_DIS | | | 2002 | IP4_CHECK | | | 2003 | IP4_SRC | | | 2004 +--------------+-------------------+---------------+ 2006 Authors' Addresses 2007 Daniel Migault 2008 Ericsson 2009 8400 boulevard Decarie 2010 Montreal, QC H4P 2N2 2011 Canada 2013 Email: daniel.migault@ericsson.com 2015 Tobias Guggemos 2016 LMU Munich 2017 Oettingenstr. 67 2018 80538 Munchen, Bavaria 2019 Germany 2021 Email: guggemos@nm.ifi.lmu.de 2022 URI: http://www.nm.ifi.lmu.de/~guggemos 2024 Carsten Bormann 2025 Universitaet Bremen TZI 2026 Postfach 330440 2027 Bremen D-28359 2028 Germany 2030 Phone: +49-421-218-63921 2031 Email: cabo@tzi.org 2033 David Schinazi 2034 Google LLC 2035 1600 Amphitheatre Parkway 2036 Mountain View, California 94043 2037 USA 2039 Email: dschinazi.ietf@gmail.com