idnits 2.17.1 draft-mglt-6lo-diet-esp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2820 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) -- Looks like a reference, but probably isn't: '43' on line 659 -- Looks like a reference, but probably isn't: '6' on line 660 == Missing Reference: 'M' is mentioned on line 1120, but not defined == Unused Reference: 'RFC4104' is defined on line 730, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7321 (Obsoleted by RFC 8221) -- No information found for draft-mglt-6lo-diet-esp-payload-compression - is the name correct? == Outdated reference: A later version (-02) exists of draft-mglt-6lo-diet-esp-requirements-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track T. Guggemos 5 Expires: January 9, 2017 LMU Munich 6 C. Bormann 7 Universitaet Bremen TZI 8 July 8, 2016 10 Diet-ESP: a flexible and compressed format for IPsec/ESP 11 draft-mglt-6lo-diet-esp-02.txt 13 Abstract 15 This document defines Diet-ESP that adapts IPsec/ESP for IoT. Diet- 16 ESP compresses fields of the Standard ESP. The compression is 17 defined by profiles based ROHC and ROHCoverIPsec as well as 18 parameters mentioned in the Diet-ESP Context agreed between the two 19 Diet-ESP peers for example using IKEv2. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 9, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. IoT context . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Document Overview . . . . . . . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Diet-ESP Context . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Diet-ESP Protocol Description . . . . . . . . . . . . . . . . 9 62 5.1. Robust Header Compression (ROHC) . . . . . . . . . . . . 10 63 5.2. Diet-ESP ROHC framework . . . . . . . . . . . . . . . . . 11 64 5.3. Diet-ESP header classification . . . . . . . . . . . . . 12 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 68 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 16 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 71 10.2. Informational References . . . . . . . . . . . . . . . . 18 72 Appendix A. Example of light Diet-ESP implementation for sensor 18 73 Appendix B. Difference between Diet-ESP and ESP . . . . . . . . 20 74 B.1. Packet Alignment . . . . . . . . . . . . . . . . . . . . 21 75 B.2. SAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 B.2.1. Inbound Security Association Lookup . . . . . . . . . 21 77 B.2.2. Outgoing Security Association Lookup . . . . . . . . 24 78 B.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 24 79 B.4. Outgoing Packet processing . . . . . . . . . . . . . . . 25 80 B.5. Inbound Packet processing . . . . . . . . . . . . . . . . 26 81 Appendix C. Interaction with other Compression Protocols . . . . 27 82 C.1. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 C.2. ROHC . . . . . . . . . . . . . . . . . . . . . . . . . . 27 84 C.3. ROHCoverIPsec and 6LoWPANoverIPsec . . . . . . . . . . . 28 85 Appendix D. Diet-ESP and Requirements . . . . . . . . . . . . . 29 86 Appendix E. Document Change Log . . . . . . . . . . . . . . . . 30 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 89 1. Requirements notation 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Introduction 97 2.1. IoT context 99 The IPsec/ESP [RFC4303] is represented in Figure 1. It was designed 100 to: 1) provide general purposes security protocol with high level of 101 security, 2) favor interoperability between implementations and 3) 102 scale on large infrastructures. 104 In order to match these goals, ESP format favor mandatory fields with 105 fixed sizes that are designed considering extreme or worst case 106 scenarios. This results in a kind of "unique" packet format common 107 to all considered scenarios using ESP. On the other hand ESP ends up 108 carrying "unnecessary" or "larger than required" fields. This cost 109 of additional bytes were considered as negligible versus 110 interoperability, making ESP very successful over the years. 112 With IoT, requirements become slightly different. For most devices, 113 like sensors, sending extra bytes directly impacts the battery and so 114 the life time of the sensor. As a result, IoT may look at reducing 115 the number of bytes sent on the wire. 117 This document describes Diet-ESP which compresses fields of the 118 Standard ESP. The compression is defined by profiles based ROHC and 119 ROHCoverIPsec as well as parameters mentioned in the Diet-ESP Context 120 agreed between the two Diet-ESP peers for example using IKEv2 121 [RFC7296] 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 125 | Security Parameters Index (SPI) | ^ 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I 127 | Sequence Number (SN) | n 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ t-- 129 | Payload Data* (variable) | e ^ 130 ~ ~ g c 131 | | r o 132 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i n 133 | | Padding (0-255 bytes) | t f 134 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ y . 135 | | Pad Length | Next Header | v v 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 137 | Integrity Check Value-ICV (variable) | 138 ~ ~ 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: ESP Packet Description 144 2.2. Document Overview 146 This document describes how to compress ESP fields sent on the wire. 147 Concerned fields are those of the ESP Header and the ESP Trailer. 148 Compression of the Payload Data, including the Initialization Vector 149 (IV) or the Integrity Check Value (ICV) are out of scope of the 150 document. 152 The compression mechanisms defined in this document are based on ROHC 153 [RFC3095], [RFC5225] and ROHCoverIPsec [RFC5856], [RFC5857], 154 [RFC5858]. 156 ROHC defines mechanisms to compress/decompress fields of an IP 157 packet. These compressors are placed between the MAC layer and the 158 IP layer. In the case of ESP, ROHC can be used to compress/ 159 decompress SPI, SN. However, ROHC cannot be used to compress 160 encrypted fields like Padding, Pad Length, Next Header -- and later 161 the Clear Text Data before encryption. In fact, at the MAC layer, 162 these fields are encrypted and their encrypted value is used generate 163 the ICV. As a result, compression an ESP packet at the MAC layer 164 requires to decrypt the packet to be able to compress fields like 165 Clear Text Data, Pad Length in order to be able to eventually remove 166 the Padding Field. Similarly, decompressing a compress ESP packet at 167 the MAC layer would require to decrypt the received packet, 168 decompress the packet the Clear Text Data as well as the other ESP 169 fields, before forwarding the ESP packet to the IP stack. Note that 170 in some case decompression is not feasible. Consider for example an 171 ESP implementation that generates a random Padding. If this field is 172 removed by the compressor, it can hardly be recovered by the 173 decompressor. Using a different Padding field would result is ESP 174 rejecting the packet as the ICV check will not succeed. As a result 175 ROHC cannot be used alone. 177 On the other hand, ROHCoverIPsec makes compression possible before 178 the ESP payload is encrypted, and so the Clear Text Data can be 179 compressed, but not the ESP related fields like Padding, Pad Length 180 and Next Header. 182 ROHC and ROHCoverIPsec have been designed for bandwidth optimization, 183 but not necessarily for constraint devices. As a result, defining 184 ROHC and ROHCoverIPsec profiles is not sufficient to fulfill the 185 complete set of Diet-ESP requirements listed in 186 [I-D.mglt-6lo-diet-esp-requirements]. In fact Diet-ESP MUST result 187 in an light implementation that does not require implementation of 188 the full ROHC and ROHCoverIPsec frameworks. 190 In order to achieve ESP field compression, this document describes 191 the Diet-ESP Context. This context contains all necessary parameters 192 to compress an ESP packet. This Diet-ESP Context can be provided as 193 input to proceed to Diet-ESP compression / decompression. This 194 document uses the ROHC and ROHCoverIPsec framework to compress the 195 ESP packet. The advantage of using ROHC and ROHCoverIPsec is that 196 compression behavior follows a standardized compression framework. 197 On the other hand, ROHC and ROHCoverIPsec frameworks are used in a 198 stand alone mode, which means no ROHC communications between 199 compressor and decompressor are considered. This enables specific 200 and lighter implementations to perform Diet-ESP compression without 201 implementing the ROHC or ROHCoverIPsec frameworks. All Diet-ESP 202 implementations only have to agree on the Diet-ESP Context to become 203 inter-operable. 205 The remaining of the document is as follows. Section 4 described the 206 Diet-ESP Context. Section 5 describes how the parameters of the 207 Diet-ESP Context are used by the ROHC and ROHCoverIPsec framework to 208 compress the ESP packet. This requires definition of new profiles 209 and extensions. Finally, Section 7 and Section 8 provides a security 210 and privacy analysis on Diet-ESP over standard ESP. Informational 211 material have been added into the Appendix section. Appendix A 212 illustrates how an minimal Diet-ESP implementation may be used in IoT 213 devices. Appendix B lists the differences between Diet-ESP and 214 Standard ESP. Appendix C describes the interactions of Diet-ESP 215 interacts with other compression protocols such as 6lowPAN and ROHC 216 compression for other protocols than ESP. Finally, Appendix D 217 describes how Diet-ESP matches the requirements for Diet-ESP 218 [I-D.mglt-6lo-diet-esp-requirements]. 220 3. Terminology 222 This document uses the following terminology: 224 - IoT: Internet of Things 226 - LSB: Last Significant Bytes 228 - IP alignment: The necessary alignment for IPv4 (32 bits) resp. 229 IPv6 (64 bits) 231 - Clear Text Data: designates the original data that are carried by 232 ESP. 234 - Encrypted Payload: carries the encrypted Data Payload including 235 cryptographic material like the IV and the ESP Trailer. 237 4. Diet-ESP Context 239 The Diet-ESP context provides the necessary parameters for the 240 compressor and decompressor to perform the appropriated compression 241 and decompression of the ESP packet. Table 1 the different 242 parameters of the Diet-ESP Context. 244 +-----------------+-------------------------------------------------+ 245 | Context Field | Overview | 246 | Name | | 247 +-----------------+-------------------------------------------------+ 248 | ALIGN | Necessary Alignment for the specific device. | 249 | SPI_SIZE | Size in bytes of the SPI field in the sent | 250 | | packet. | 251 | SN_SIZE | Size in byte of the SN field in the sent | 252 | | packet. | 253 | NH | Presence of the Next Header field in the ESP | 254 | | Trailer. | 255 | PAD | Presence of the Pad Length field present in the | 256 | | ESP trailer. | 257 +-----------------+-------------------------------------------------+ 259 Table 1: Diet-ESP Context. 261 ALIGN: 262 Alignment is the minimum alignment accepted by the hardware. 263 Constrains may come from various reasons. Hardware may have some 264 specific requirements, but also operating systems. For most 265 servers CPU and OS have been designed with 32 bit or 64 bit 266 alignment. As a result, IP headers have been standardized with 32 267 bits (resp. 64 bits in IPv6) alignment for each IP extension 268 header. ESP is one of these extension headers with an Header (SPI 269 and SN) of 64 bits and the Trailer (NH, PL, PAD) of (2 + PL) 270 bytes. Since the trailer is part of the ESP extension header, it 271 must provide the necessary padding for a correct alignment of the 272 NH field to 32 (resp. 64) bits. The alignment may also be 273 relevant if Block-Ciphers like AES-CBC needs an aligned payload to 274 perform the encryption. To inter-oprate with the standard ESP, IP 275 alignment must be 32 bit for IPv4 and 64 bit for IPv6. 277 Diet-ESP reduces the ALIGN value from 32 bits for IPv4 or 64 bits 278 for IPv6 to 8, 16, 32 and 64 bit alignment. 280 Motivations to do so is to remove the Padding and other mandatory 281 fields of the ESP packet. Then, most IoT embeds small 8 or 16 bit 282 CPUs. Finally, even though ESP is an extension header, it is 283 often the last extension header of a header-only IP packet. The 284 ESP header is only read by the real receiver and is uninteresting 285 for other devices like routers, placed between the to peers. As a 286 result, there seems no real impact on the system if ESP extension 287 header is not aligned. 289 Note that the benefices of ALIGN also depends on the used 290 cryptographic mode. More specifically AES-CTR has a 8 bit block 291 whereas AES-CBC has a 128 bit block. As a result the use of AES- 292 CBC with small Clear Text Data results in large encrypted Data 293 with embedded padding. In other words, the alignment for one 294 packet is always MAX(CIPHER_BLOCK_SIZE, ALIGN). 296 SPI_SIZE: 297 ESP Security Policy Index is 4 byte long to identify the SAD-entry 298 for incoming traffic. To interoperate with the standard ESP, the 299 SPI_SIZE must be of 4 bytes. 300 Diet-ESP omits, leaves unchanged, or reduces the SPI sent on the 301 wire to the 0, 1, 2, 3 or 4 LSB. 302 Compression only impacts the data sent on the wire and therefore 303 SHOULD only deal with 4 byte decompressed SPIs in the SAD. This 304 allows systems to send and receive multiple SPI_SIZE with 305 different hosts. Decompressing the SPI at the receiver may 306 involve IP addresses (see Appendix B.2.1). 307 Compressing the SPI has significant security impacts as detailed 308 in Section 7. It should be guided by 1) the number of 309 simultaneous inbound SA the device is expected to handle and 2) 310 reliability of the IP addresses in order to identify the proper SA 311 for incoming packets. More specifically, a sensor with a single 312 connection to a Security Gateway, may bind incoming packets to the 313 proper SA based only in its IP addresses. In that case, the SPI 314 may not be necessary. Other scenarios may consider using the SPI 315 to index the SAs or may consider having multiple ESP channels with 316 the same host from a single host. In that case one may choose a 317 reduced length for the SPI. Note also that the value 0 for the 318 SPI is not allowed to be sent on the wire as described in 319 [RFC4303]. 321 SN_SIZE: 322 ESP Sequence Number is 32 bit and extended SN is 64 bit long and 323 used for anti-replay protection. To interoperate with standard 324 ESP the SN_SIZE must be of 4 bytes. 325 Diet-ESP omits, leaves unchanged or reduces SN sent on the wire to 326 0, 1, 2, 3 or 4 LSB. 327 Decompressing the SN at the receiver is guided by a linear 328 extrapolation of the expected received Sequence Number and the 329 LSB-SN sent on the wire. To avoid packet overhead, this 330 configuration is stored within the SA, whereas it remains valid 331 during its lifetime. Therefore an implementer should consider the 332 LSB window such that two consecutive received SN should not 333 present a difference of more than the LSB window. 334 In some cases, the received SN may increase by a high number e.g. 335 using the time as the SN or because of a high number of packet 336 loss. See Section 7 for the related security considerations. 338 Note that SN and SPI MUST be aligned to a multiple of the 339 Alignment value (ALIGN). 341 NH: 342 Next Header in ESP is used to identify the first header inside the 343 ESP payload. To interoperate with standard ESP, the Next Header 344 must be indicated and present. 345 Diet-ESP is able to remove the Next Header field from the ESP- 346 Trailer. 347 Removing the Next Header is possible only if the underlying 348 protocol can be derived from the Traffic Selector (TS) within the 349 Security Association (SA). More specifically, the Next Header 350 indicates whether the encrypted ESP payload is an IP packet, a UDP 351 packet, a TCP packet or no next header. The NH can only be 352 removed if this has been explicitly specified in the SA or if the 353 device has a single application. 354 Note that removing the Next Header impacts how encryption is 355 performed. For example, the use of AES-CBC [RFC3602] mode 356 requires the last block to be padded, reaching a 128 bit 357 alignment. In this case removing the Next Header increases the 358 padding by the Next Header length, which is 8 bits. In this case, 359 removing the Next Header provides few advantages, as it does not 360 reduce the ESP packet length. With AES-CBC, the only advantage of 361 removing the Next Header would be for data with the last block of 362 15 bytes. In that case, ESP pads with 15 modulo 16 bytes, sets 363 the 1 byte pad length field to 15 and add the one byte Next Header 364 field. This leads to 15 + 15 + 1 + 1 = 32 bytes to be sent. On 365 the other hand, removing the Next Header would require only the 366 concatenation of the pad length byte with a 0 value, which leads 367 to 16 bytes to be sent. 368 Other modes like AES-CTR [RFC3686] do not have block alignment 369 requirements, so the only alignment constraint comes from the 370 device hardware alignment (ALIGN). Suppose A designates the 371 alignment constraint from OS, hardware, encryption, packet 372 format...). A is fixed and consider then any data of length k * A 373 + A - 1 bytes with k an integer. Sending this data using ESP 374 takes advantage of removing the Next Header as it reduces the 375 number of bytes to be sent by A over the traditional ESP. As a 376 result, for 8 bit alignment hardware (A = 1) removing the Next 377 Header always prevent an unnecessary byte to be sent. 379 PAD: 380 With ESP, all packets have a Pad Length field. This field is 381 usually present because ESP requires IP alignment which is ensured 382 with padding. In order to interoperate with the standard ESP, the 383 Pad Length must be indicated and be present. 384 Diet-ESP considers removing the Padding and the Pad Length field. 385 If PAD is present, then it is computed according to ALIGN. 386 In fact, some devices might use an 8 bits alignment, in which case 387 padding is not necessary. Similarly, sensors may send application 388 data of fixed length matching the alignment. Note that alignment 389 may be required by the device (8-bit, 16-bit, or more generally 390 32-bit), but it may also be required by the encryption block size 391 (AES-CBC uses 128 bit blocks). With ESP these scenarios would 392 result in an unnecessary Pad Length field always set to zero. 393 Diet-ESP considers those case with no padding, and thus the Pad 394 Length field can be omitted. 396 Some additional parameters may be added to the Diet-ESP Context. 397 Such parameters are defined in other documents, like 398 [I-D.mglt-6lo-diet-esp-payload-compression] the compression of 399 protocol headers inside the encrypted ESP payload. 401 5. Diet-ESP Protocol Description 403 This section defines Diet-ESP on the top of the ROHC and 404 ROHCoverIPsec framework. Section 5.1 presents and explains the 405 choice of these frameworks. This section is informational and its 406 only goal is to position our work toward ROHC and ROHCoverIPsec. 408 5.1. Robust Header Compression (ROHC) 410 ROHC enables the compression of different protocols of all layers. 411 It is designed as a framework, where protocol compression is defined 412 as profile. Each profile is defined for a specific layer, and ROHC 413 compression in [RFC3095] defines profiles for the following 414 protocols: uncompressed, UDP/IP, ESP/IP and RTP/UDP/IP. The 415 compression occurs between the IP and the MAC layer, and so remains 416 independent of an eventual IP alignment. 418 The general idea of ROHC is to classify the different protocol 419 fields. According to the classification, they can either completely 420 and always be omitted, omitted only after the fields has been sent 421 once and registered by the receiver or partly sent and be regenerated 422 by the receiver. For example, a static field value may be negotiated 423 out of band (for example IP version) and thus not be sent at all. In 424 some cases, the value is not negotiated out of band and is carried in 425 the first packet (for example SPI, UDP ports). As a result, the 426 first packet is usually not so highly compressed with ROHC. Finally, 427 some variable fields (for example Sequence Number) can be represented 428 partially by their Last Significant Bits (LSB) and regenerated by the 429 receiver. 431 The main issue encountered with ESP and ROHC is that ESP may contain 432 encrypted data which makes compression between the IP and MAC layer 433 complex to achieve. Therefore ROHC defines different compression of 434 the ESP protocol (see Figure 2), so compression of the Clear Text 435 Data can occur before the ESP encryption. Regular ROHC can compress 436 the ESP header. If the packet is not encrypted, the rate of 437 compression is extremely high as the whole packet including padding 438 can be compressed in the regular ROHC stack, too. For encrypted 439 payload ROHC defines ROHCoverIPsec ([RFC5856], [RFC5857], [RFC5858]) 440 to compress the ESP payload before it is going to be encrypted. This 441 leads to a second ESP stack, where another ROHC compressor (resp. 442 decompressor) works (see Figure 2). Excluding the first packet which 443 initializes the ROHC context, this makes ESP compression highly 444 efficient. 446 +-------------------------------+--- 447 | Transport Layer | Layer 4 448 +---------------+---------------+--- 449 | ROHCoverIPsec | Standard ESP | ^ 450 +---------------+---------------+ | Layer 3 451 | IP Layer | v 452 +-------------------------------+--- 453 | ROHC (de-)compressor | ^ 454 +-------------------------------+ | Layer 2 455 | MAC Layer | v 456 +-------------------------------+--- 458 Figure 2: The two different ROHC layers in the TCP/IP stack. 460 The first drawback for ROHC and ROHCoverIPsec is, that it leads to 461 two ROHC compression layers (ROHCoverIPsec before ESP encryption and 462 ROHC before the MAC layer) in addition to two ESP implementations 463 (Standard ESP and ROHCoverIPsec ESP). Both frameworks are quite 464 complex and require a lot of resources which does not fit IoT 465 requirements. Then ROHCoverIPsec also limits the compression of the 466 ESP protocol, according to the IP restrictions. Padding remains 467 necessary as IPsec is part of the IP stack which requires a 32 bits 468 (resp. 64 bits for IPv6) aligned packet. This makes compression 469 quite inefficient when small amount of data are sent. 471 Note that mechanism to compress encrypted fields may be possible with 472 ROHC only and without ROHCoverIPsec. Such mechanisms may be possible 473 for fields like the Next Header or the Padding and Pad Length when 474 the data sent is of fixed size. As the sizes of the fields are known 475 the compressor may simply remove these fields. However, even in this 476 case, it almost doubles the amount of computation on the receiver's 477 side. In fact, the ROHC compressor would almost decompress and re- 478 encrypt the compressed ESP payload before forwarding it to the IP 479 stack. In addition, since the receiver has to re-encrypt the 480 decompressed information before integrity of the packet can be 481 checked, one can easily construct a DoS attack. Flooding the 482 receiver with invalid packet causes the receiver to perform the 483 complex encryption and authentication algorithm for each packet. 485 5.2. Diet-ESP ROHC framework 487 This section defines how the compression of all ESP fields is 488 performed within the ROHC and ROHCoverIPsec frameworks. More 489 especially fields that are in the ESP Header (i.e. the SPI and the 490 SN) and the ICV are compressed by the ROHC framework. The other 491 fields, that is to say those of the ESP Trailer, are compressed by 492 the ROHCoverIPsec framework. 494 Diet-ESP fits in the ROHC and the ROHCoverIPsec in a very specific 495 way. 497 1 - Diet-ESP does not need any ROHC signaling between the peers. 498 More specifically, ROHC Initialization and Refresh (IR), or 499 ROHC IR-DYN or ROHC Feed back packet are not considered with 500 Diet-ESP. The first reason is that fields are either STATIC or 501 PATTERN and their value or profile is defined through the Diet- 502 ESP Context agreement. This agreement is out of scope of ROHC, 503 it is expected to be agreed by other protocols like IKEv2 and 504 thus is considered as an out-of band agreement by the peers. 505 Then, the profiles are applied for each Security Association 506 that is unidirectional. In fact an IKEv2 negotiation results 507 in two unidirectional SA. As a result, each SA the packets are 508 sent in one direction only, which corresponds to the 509 Unidirectional mode -- U-mode of ROHC. 511 2 - Diet-ESP only exchanges compressed data. How the compression / 512 decompression occurs is defined by the Diet-ESP Context. Once 513 the Diet-ESP Context has been agreed, both peers are in a 514 Second Order (SO) State and exchange only compressed data. 516 3 - Diet-ESP only compresses ESP packets, it may include inner 517 packet compression, but Diet-ESP does not make any assumption 518 on the IP compression. This is made in order to make Diet-ESP 519 interoperable with multiple IP compression protocols. 521 4 - Diet-ESP compresses partially STATIC fields as they are used as 522 indexes by the receiver, and may not completely be removed. 524 5.3. Diet-ESP header classification 526 The ROHC header field classifications are defined in Appendix A.1 of 527 [RFC3095] and Appendix A of [RFC5225]. 529 +---------+------------+---------------+-----------+----------------+ 530 | Field | ROHC class | Framework | Encoding | Diet-ESP | 531 | | | | Method | Context | 532 | | | | | Parameters | 533 +---------+------------+---------------+-----------+----------------+ 534 | SPI | STATIC-DEF | ROHC | LSB | SPI_SIZE | 535 | SN | PATTERN | ROHC | LSB | SN_SIZE | 536 | Padding | PATTERN | ROHCoverIPsec | Removed | PAD, ALIGN | 537 | Pad | PATTERN | ROHCoverIPsec | Removed | PAD, ALIGN | 538 | Length | | | | | 539 | Next | STATIC-DEF | ROHCoverIPsec | Removed | NH | 540 | Header | | | | | 541 +---------+------------+---------------+-----------+----------------+ 543 Table 2: Diet-ESP ROHC profile. 545 SPI: 546 The SPI indexes the SA, is negotiated by the two peers (e.g. via 547 IKEv2 or manually) and remains the same during the session. 548 Therefore, as defined in Appendix A.6 of [RFC5225] this field is 549 classified as STATIC-DEF. The compressed SPI consists in the 550 SPI_SIZE LSB of the negotiated 32 bit SPI, and SPI_SIZE is 551 provided by the Diet-ESP Context. 553 SN: 554 The SN is used for anti-replay protection and is modified in every 555 packet. In default cases, the ESP Sequence Number will be 556 incremented by one for each packet sent. Therefore, as defined in 557 Appendix A.6 of [RFC5225] this field is classified as PATTERN. 558 The compressed SN consists in the SN_SIZE LSB of the 32 bit or 64 559 bit SN, and SN_SIZE is provided by the Diet-ESP Context. 561 Padding: 562 Padding is used for alignment purposes and is computed on a per- 563 packet basis. Therefore it is classified as PATTERN. The 564 compressed Padding is defined by PAD and ALIGN provided by the the 565 Diet-ESP Context. If PAD is set the Padding and Pad Length fields 566 are removed. If PAD is unset, Padding is computed according to 567 the ALIGN and the padding length is indicated in the PAD Length 568 field. 570 Pad Length: 571 Pad Length indicates the length of the Padding field and is 572 computed on a per-packet basis. Therefore it is classified as 573 PATTERN. See Padding for the compressed Pad Length. 575 Next Header: 577 The Next Header indicates the next layer in the inner ESP Payload. 578 To be compressed the Next Header MUST remain the same during the 579 session. This means that it MUST have been negotiated (e.g. by 580 IKEv2) and can be derived from the Traffic Selectors. If this 581 condition is met and the Next Header compression is requested by 582 the peers with NH set in the Diet-ESP Context, then the Next 583 Header field MUST be removed. 585 6. IANA Considerations 587 There are no IANA consideration for this document. 589 7. Security Considerations 591 This section lists security considerations related to the Diet-ESP 592 protocol. 594 Security Parameter Index (SPI): 595 The Security Parameter Index (SPI) is used by the receiver to 596 index the Security Association that contains appropriated 597 cryptographic material. If the SPI is not found, the packet is 598 rejected as no further checks can be performed. In Diet-ESP, the 599 value of the SPI is not reduced, but compressed why the SPI value 600 may not be fully provided between the compressor and the 601 decompressor. On the other hand, its uncompressed value is 602 provided to the ESP-procession and no weakness is introduced to 603 ESP itself. On an implementation perspective, it is strongly 604 recommended that decompression is deterministic. Compression and 605 decompression adds some additional treatment to the ESP packet, 606 which might be used by an attacker. In order to minimize the load 607 associated to decompression, decompression is expected to be 608 deterministic. The incoming compressed SPI with the associated IP 609 addresses should output a single and unique uncompressed SPI 610 value. If n uncompressed SPI values have to be considered, then 611 the receiver could end in n signature checks which may be used by 612 an attacker for a DoS attack. On a privacy perspective, until 613 Diet-ESP is not deployed outside the scope of IoT and small 614 devices, the use of a compressed SPI may provide an indication 615 that one of the endpoint is a sensor. Such information may be 616 used, for example, to evaluate the number of appliances deployed, 617 or - in addition with other information, such as the time 618 interval, the geographic location - be used to derive the type of 619 data transmitted. 621 Sequence Numer (SN): 622 The Sequence Number (SN) is used as an anti-replay attack 623 mechanism. Compression and decompression of the SN is already 624 part of the standard ESP namely the Extended Sequence Number 625 (ESN). The SN in a standard ESP packet is 32 bit long, whether 626 Diet-ESP enables to reduce it to 0 bytes and the main limitation 627 to the compression a deterministic decompression. SN compression 628 consists in indicating the least significant bits of the 629 uncompressed SN on the wire. The size of the compressed SN must 630 consider the maximum reordering index such that the probability 631 that a later sent packet arrives before an earlier one. In 632 addition the size of SN should also consider maximum consecutive 633 packets lost during transmission. In the case of ESP, this number 634 is set to 2^32 which is, in most real world case, largely over- 635 provisioned. When the compression of the SN is not appropriately 636 provisioned, the most significant bit value may be desynchronized 637 between the sending and receiving parties. Although IKEv2 638 provides some re-synchronization mechanisms, in case of IoT the 639 de-synchronization will most likely result in a renegotiation and 640 thus DoS possibilities. Note that IoT communication may also use 641 some external parameters, i.e. other than the compressed SN, to 642 define whether a packet be considered or not and eventually derive 643 the SN. One such scenario may be the use of time windows. 644 Suppose a device is expected to send some information every hour 645 or every week. In this case, for example, the SN may be 646 compressed to zero bytes. Instead the SN may be derived by 647 incrementing the SN every hour after the last received valid 648 packet. Considering the time the packet is received make it 649 possible to consider the time derivation of the sensor clock. 650 Note also that the anti-replay mechanism needs to define the size 651 of the anti-replay window. [RFC4303] provides guidance to set the 652 window size and are similar to those used to define the size of 653 the compressed SN 655 ESP Trailer: 656 Padding, Pad Length and Next Header are fields stored inside the 657 encrypted payload. They are part of the ESP payload so that ESP 658 can be seen as an IP option. IP extension headers must have 32 659 bit Byte-Alignment in IPv4 [43] and 64 bit Byte-Alignment in IPv6 660 [6]. The main motivation for the alignment is the improvement of 661 packet processing on 32 or 64 bit processors. As a result, 662 compression of these static fields does not impact the security of 663 Diet-ESP compared to the one provided by ESP. 665 8. Privacy Considerations 667 Security Parameter Index (SPI): 668 Until Diet-ESP is not deployed outside the scope of IoT and small 669 devices, the use of a compressed SPI may provide an indication 670 that one of the endpoint is a sensor. Such information may be 671 used, for example, to evaluate the number of appliances deployed, 672 or - in addition with other information, such as the time 673 interval, the geographic location - be used to derive the type of 674 data transmitted. 676 Sequence Number (SN): If incremented for each ESP packet, the SN may 677 leak some information like the amount of transmitted data or the 678 age of the sensor. The age of the sensor may be correlated with 679 the software used and the potential bugs. On the other hand, re- 680 keying will re-initialize the SN, but the cost of a re-keying may 681 not be negligible and thus, frequent re-keying can be considered. 682 In addition to the re-key operation, the SN may be generated in 683 order to reduce the accuracy of the information leaked. In fact, 684 the SN does not have to be incremented by one for each packet it 685 just has to be an increasing function. Using a function such as a 686 clock may prevent characterizing the age or the use of the sensor. 687 Note that the use of such function may also impact the compression 688 efficiency and result in larger compressed SN. 690 9. Acknowledgment 692 The current work on Diet-ESP results from exchange and cooperation 693 between Orange, Ludwig-Maximilians-Universitaet Munich, Universite 694 Pierre et Marie Curie. We thank Daniel Palomares and Carsten Bormann 695 for their useful remarks, comments and guidances on the design. We 696 thank Sylvain Killian for implementing an open source Diet-ESP on 697 Contiki and testing it on the FIT IoT-LAB [fit-iot-lab] funded by the 698 French Ministry of Higher Education and Research. We thank the IoT- 699 Lab Team and the INRIA for maintaining the FIT IoT-LAB platform and 700 for providing feed backs in an efficient way. We thank Ana Minaburo 701 for her ROHC review. 703 10. References 705 10.1. Normative References 707 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 708 Requirement Levels", BCP 14, RFC 2119, 709 DOI 10.17487/RFC2119, March 1997, 710 . 712 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 713 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 714 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 715 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 716 Compression (ROHC): Framework and four profiles: RTP, UDP, 717 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 718 July 2001, . 720 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 721 Algorithm and Its Use with IPsec", RFC 3602, 722 DOI 10.17487/RFC3602, September 2003, 723 . 725 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 726 Counter Mode With IPsec Encapsulating Security Payload 727 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 728 . 730 [RFC4104] Pana, M., Ed., Reyes, A., Barba, A., Moron, D., and M. 731 Brunner, "Policy Core Extension Lightweight Directory 732 Access Protocol Schema (PCELS)", RFC 4104, 733 DOI 10.17487/RFC4104, June 2005, 734 . 736 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 737 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 738 December 2005, . 740 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 741 RFC 4303, DOI 10.17487/RFC4303, December 2005, 742 . 744 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 745 Mode with IPsec Encapsulating Security Payload (ESP)", 746 RFC 4309, DOI 10.17487/RFC4309, December 2005, 747 . 749 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 750 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 751 . 753 [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression 754 Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and 755 UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, 756 . 758 [RFC5857] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. 759 Bormann, "IKEv2 Extensions to Support Robust Header 760 Compression over IPsec", RFC 5857, DOI 10.17487/RFC5857, 761 May 2010, . 763 [RFC5858] Ertekin, E., Christou, C., and C. Bormann, "IPsec 764 Extensions to Support Robust Header Compression over 765 IPsec", RFC 5858, DOI 10.17487/RFC5858, May 2010, 766 . 768 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 769 Kivinen, "Internet Key Exchange Protocol Version 2 770 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 771 2014, . 773 [RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm 774 Implementation Requirements and Usage Guidance for 775 Encapsulating Security Payload (ESP) and Authentication 776 Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, 777 . 779 10.2. Informational References 781 [fit-iot-lab] 782 "Future Internet of Things (FIT) IoT-LAB", 783 . 785 [I-D.mglt-6lo-diet-esp-payload-compression] 786 Migault, D. and T. Guggemos, "Diet-IPsec: ESP Payload 787 Compression of IPv6 / UDP / TCP / UDP-Lite", January 2015. 789 [I-D.mglt-6lo-diet-esp-requirements] 790 Migault, D. and T. Guggemos, "Requirements for Diet-ESP 791 the IPsec/ESP protocol for IoT", draft-mglt-6lo-diet-esp- 792 requirements-01 (work in progress), February 2015. 794 [I-D.raza-6lowpan-ipsec] 795 Raza, S., Duquennoy, S., and G. Selander, "Compression of 796 IPsec AH and ESP Headers for Constrained Environments", 797 draft-raza-6lowpan-ipsec-01 (work in progress), September 798 2013. 800 [RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, 801 "Integration of Robust Header Compression over IPsec 802 Security Associations", RFC 5856, DOI 10.17487/RFC5856, 803 May 2010, . 805 Appendix A. Example of light Diet-ESP implementation for sensor 807 Diet-ESP has been designed to enable light implementation. This 808 section illustrates the case of a sensor sending a specific amount of 809 data periodically. This section is not normative and has only an 810 illustrative purpose. In this scenario the sensor measures a 811 temperature every minute and sends its value to a gateway, which is 812 assumed to collect the data. The data is sent in an UDP packet and 813 there is no other connection between the two peers. The 814 communication between the sensor and the gateway should be secured by 815 a Diet-ESP connection in transport mode. Therefore the following 816 context is chosen: 818 ALIGN: 8 bit 819 Sensors are not expected to be 32 or 64 bit CPU, and micro- 820 controllers are expected to support 8 bit alignment. 822 SPI_SIZE: 0 823 As it is a single connection, the SA can be identified by using 824 the IP addresses. As a result the SPI is not needed. 826 SN_SIZE: 0 827 Because only one packet every minute is sent, the packets will 828 arrive at the receiver in an ordered way. The receiver can 829 rebuild the SN which should be present in the packet, assuming the 830 SN is incremented by one for each packet. Note that setting SN to 831 0 does not mean there is no anti replay protection. In fact, the 832 SN is needed for the computation of the Diet-ESP ICV. 834 NH: Remove Next Header 835 Since the protocol is always UDP, the Next header can be omitted. 837 PAD: Remove Padding 838 With 8 bit alignment Padding has always a Pad Length of 0. 839 Setting PAD to "Remove Padding" removes the Pad Length field. 841 Diet-ESP_ICV_SIZE: 4 bytes 842 The ICV is chosen to be 32 bits in order to find a fair trade-off 843 between security and energy costs. 845 Encapsulating the outgoing Diet-ESP packet is proceeded as follows: 847 1) SAD lookup for outgoing traffic 849 2) Compress ESP payload incl. Transport Header (UDP) 851 3) Encrypt IP payload 853 4) Build ESP header 855 5) Calculate Diet-ESP ICV 857 6) Compress ESP header 859 7) Add ${Diet-ESP_ICV_SIZE} LSB of ICV to the packet. 861 Diet-ESP | Standard ESP 862 +--------------------+ | +--------------------+ 863 | orig | | | | | orig | | | 864 |IP hdr | UDP | Data | | |IP hdr | UDP | Data | 865 +--------------------+ | +--------------------+ 866 | | | 867 V | V 868 +-----------+ | +-----------+ 869 | Diet-ESP | | | ESP | 870 +-----------+ | +-----------+ 871 | | | 872 V | V 873 +----------------------+|+---------------------------------------+ 874 | orig | | Diet-ESP||| orig | ESP | | | ESP | ESP| 875 |IP hdr |Data| ICV |||IP hdr | Hdr | UDP |Data| Trailer | ICV| 876 +----------------------+|+---------------------------------------+ 878 Figure 3: Minimal Example - Input and Output of the Diet-ESP function 879 vs. Standard ESP. 881 Incoming Diet-ESP packet is processed as follows: 883 1) SAD lookup for incoming traffic traffic 885 2) Decompress ESP-header incl. Transport Header (UDP) 887 3) Calculate packet Diet-ESP ICV 889 4) Check integrity with ${Diet-ESP_ICV_SIZE} LSB of Diet-ESP ICV 891 5) Check anti-replay 893 6) Decrypt IP payload (excluding ICV) 895 7) Decompress ESP payload 897 Appendix B. Difference between Diet-ESP and ESP 899 This section details how to use Diet-ESP to send and receive 900 messages. The use of Diet-ESP is based on the IPsec architecture 901 [RFC4301] and ESP [RFC4303]. We suppose the reader to be familiar 902 with these documents and we list here possible adaptations that may 903 be involved by Diet-ESP. 905 B.1. Packet Alignment 907 Each ESP packet has a fixed alignment to 32 bits (resp. 64 bits in 908 IPv6). For Diet-ESP each device has an internal parameter that 909 defines the minimal acceptable alignment. ALIGN SHOULD be a the 910 maximum of the peer's minimal alignment. 912 Diet-ESP Context with SPI_SIZE + SN_SIZE that is not a multiple of 913 ALIGN MUST be rejected. 915 B.2. SAD 917 B.2.1. Inbound Security Association Lookup 919 For devices that are configured with a single SPI_SIZE value can 920 process inbound packet as defined in [RFC4301]. As such, no 921 modifications is required by Diet-ESP. 923 Detecting Inbound Security Association: Identifying the SA for 924 incoming packets is a one of the main reasons the SPI is send in each 925 packet on the wire. For regular ESP (and AH) packets, the Security 926 Association is detected as follows: 928 1. Search the SAD for a match on {SPI, destination address, source 929 address}. If an SAD entry matches, then process the inbound ESP 930 packet with that matching SAD entry. Otherwise, proceed to step 931 2. 933 2. Search the SAD for a match on {SPI, destination address}. If the 934 SAD entry matches, then process the inbound ESP packet with that 935 matching SAD entry. Otherwise, proceed to step 3. 937 3. Search the SAD for a match on only {SPI} if the receiver has 938 chosen to maintain a single SPI space for AH and ESP, or on {SPI, 939 protocol} otherwise. If an SAD entry matches, then process the 940 inbound ESP packet with that matching SAD entry. Otherwise, 941 discard the packet and log an audible event. 943 For device that are dealing with different SPI_SIZE SPI, the way 944 inbound packets are handled differs from the [RFC4301]. In fact, 945 when a inbound packet is received, the peer does not know the 946 SPI_SIZE. As a result, it does not know the SPI that applies to the 947 incoming packet. The different values could be the 0 (resp. 1, 2, 3 948 and 4) first bytes of the IP payload. 950 Since the size of the SPI is not known for incoming packets, the 951 detection of inbound SAs has to be redefined in a Diet-ESP 952 environment. In order to ensure a detection of a SA the above 953 described regular detection have to be done for each supported SPI 954 size (in most cases 5 times). In most common cases this will return 955 a unique Security Association. 957 If there is more than one SA matching the lookup, the authentication 958 MUST be performed for all found SAs to detect the SA with the correct 959 key. In case there is no match, the packet MUST be dropped. Of 960 course this can lead into DoS vulnerability as an attacker recognizes 961 an overlap of one or more IP-SPI combinations. Therefore it is 962 highly recommended to avoid different values of the SPI_SIZE for one 963 tuple of Source and Destination IP address. Furthermore this 964 recommendation becomes mandatory if NULL authentication is supported. 965 This is easy to implement as long as the sensors are not mobile and 966 do not change their IP address. 968 The following optimizations MAY be considered for sensor that are not 969 likely to perform mobility or multihoming features provided by MOBIKE 970 [RFC4555] or any change of IP address during the lifetime of the SA. 972 Optimization 1 - SPI_SIZE is mentioned inside the SPI: 973 The SPI_SIZE is defined as part of the SPI sent in each packet. 974 Therefore the receiver has to choose the most significant 2 bits 975 of the SPI in the following way in order to recognize the right 976 size for incoming Diet-ESP packets: 978 00: SPI_SIZE of 1 byte is used. 980 01: SPI_SIZE of 2 byte is used. 982 10: SPI_SIZE of 3 byte is used. 984 11: SPI_SIZE of 4 byte is used. 986 If the the value 0 is chosen for the SPI_SIZE this option is not 987 feasible. 989 Optimization 2 - IP address based lookup: 990 IP address based search is one optimization one may choose to 991 avoid several SAD lookups. It is based on the IP address and the 992 stored SPI_SIZE, which MUST be the same value for each SA of one 993 IP address. Otherwise it can't neither be ensured that an SA is 994 found nor that the correct one is found. Note that in case of 995 mobile IP the SPI_SIZE MUST be updated for all SAs related to the 996 new IP address which may cause renegotiation. Figure 4 shows this 997 lookup described below. 999 1. Search most significant SA as follows: 1001 1.1 Search the first SA for a match on {destination address, 1002 source address}. If an SA entry matches, then process to 1003 step 2. Otherwise, proceed to step 1.2. 1005 1.2 Search the first SA for a match on {source address}. If an 1006 SA entry matches, then process to step 2. Otherwise, drop 1007 the packet. 1009 2. Identify the size of the compressed SPI for the found SA, 1010 stored in the Diet-ESP context. Note that all SAs to one IP 1011 address MUST have the same value for the SPI_SIZE. Then go to 1012 step 3. 1014 3. If the SPI_SIZE is NOT zero, read the SPI_SIZE SPI from the 1015 packet and perform a regular SAD lookup as described in 1016 [RFC4301]. If the SPI_SIZE is zero, the SA from step 1 is 1017 unique and can be used. 1019 Note that some implementations may collect all SPI matching the IP 1020 addresses in step 2 to avoid an additional lookup over the whole 1021 SAD. This is implementation dependent. 1023 If the sensor is likely to change its IP address, the outcome may 1024 be a given IP address associated to different SPI_SIZE. This case 1025 may occur if one IP address has been used by a device not anymore 1026 online, but the SA has not been removed. The IP has then been 1027 provided to another device. In this case the Diet-ESP Context 1028 SHOULD NOT be accepted by the Security Gateway when the new Diet- 1029 ESP Context is provided to the Security Gateway. At least the 1030 Security Gateway can check the previous peer is reachable and then 1031 delete the SA before accepting the new SA. 1033 Another case may be that a sensor got two interfaces with 1034 different IP addresses, negotiates a different SPI_SIZE on each 1035 interface and then use MOBIKE to move the IPsec channels from one 1036 interface to the other. In this case, the Security Gateway SHOULD 1037 NOT accept the update, or force a renegotiation of the SPI_SIZE 1038 for all SAs, basically by re-keying the SAs. 1040 +-----------+ 1041 | START | 1042 +-----------+ 1043 | 1044 V 1045 +-----------------+ 1046 | find 1st SA to | 1047 | IP address |------------------+ 1048 +-----------------+ | 1049 | | 1050 ____V____ V 1051 yes / \ +-----+ 1052 +------/ SPI_SIZE \ /----->|'---'| 1053 | \ = 0 ? / / | SAD | 1054 | \_________/ / + + 1055 | |no / '---' 1056 | V / 1057 | +-----------------+ / 1058 | | find 1st SA to |--/ 1059 | | SPI +IP | 1060 | | address | 1061 | +-----------------+ 1062 | | 1063 | V 1064 | +-----------------+ 1065 | | Diet-ESP packet | 1066 +-->| procession | 1067 +-----------------+ 1069 Figure 4: SAD lookup for incoming packets. 1071 B.2.2. Outgoing Security Association Lookup 1073 Outgoing lookups for the SPI are performed in the same way as it is 1074 done in ESP. The Traffic Selector for the packet is searched and the 1075 right SA is read from the SA. The SPI used in the packet MUST be 1076 reduced to the value stored in SPI_SIZE. 1078 B.3. Sequence Number 1080 Sequence number in ESP [RFC4303] can be of 4 bytes or 8 bytes for 1081 extended ESP. Diet-ESP introduces different sizes. One way to deal 1082 with this is to add a MAX_SN value that stores the maximum value the 1083 SN can have. Any new value of the SN will be check against this 1084 MAX_SN. 1086 B.4. Outgoing Packet processing 1088 NH, TH, IH, P indicate fields or payloads that are removed from the 1089 Diet-ESP packet. How the Diet-ESP packet is generated depends on the 1090 length Payload Data LPD, BLCK the block size of the encryption 1091 algorithm and the device alignment ALIGN. We note M = MAX(BLCK, 1092 ALIGN). 1094 - 1: Compress the headers inside the ESP payload. 1096 - 2: if PAD and NH are set to present: Diet-ESP considers both 1097 fields Pad Length and Next Header. The Diet-ESP Payload is the 1098 encryption of the following clear text: 1099 Payload Data | Padding of Pad Length bytes | Pad Length field | 1100 Next Header field. 1101 The Pad Length value is (LPD + 2) mod [M]. 1103 - 3: if PAD is set to present and NH is set to removed: Diet-ESP 1104 considers the Pad Length field but removes the Next Header 1105 field. The ESP Payload is the encryption of the following 1106 clear text: Payload Data | Padding of Pad Length bytes | Pad 1107 Length field | Next Header field. The Pad Length value is (LPD 1108 + 1) mod [M]. 1110 - 4: if PAD is set to removed and NH is set to present: Diet-ESP 1111 considers the Next Header but do not consider the Pad Length 1112 field or the Padding Field. This is valid as long as (LPD + 1) 1113 mod [M] = 0. If M = 1 as it is the case for AES-CTR this 1114 equation is always true. On the other hand the use of specific 1115 block size requires the application to send specific length of 1116 application data. 1118 - 5: if PAD and NH are set to removed: Diet-ESP does consider 1119 neither the Next Header field nor the Pad Length field nor the 1120 Padding Field. This is valid as long as LPD mod [M] = 0. If M 1121 = 1 as it is the case for AES-CTR this equation is always true. 1122 On the other hand the use of specific block size requires the 1123 application to send specific length of application data. 1125 - 6: Encrypt the Diet-ESP payload. 1127 - 7: Add ESP header. 1129 - 8: Generate and add Diet-ESP ICV. 1131 - 9: Compress ESP header. 1133 B.5. Inbound Packet processing 1135 Decryption is for performed the other way around. 1137 After SAD lookup, authenticating and decrypting the Diet-ESP payload 1138 the original packet is rebuild as follows: 1140 - 1: Decompress ESP header. 1142 - 2: Generate Diet-ESP ICV and check ICV send in the packet. 1144 - 3: Check anti-replay 1146 - 4: Remove compressed header. 1148 - 5: Encrypt the Diet-ESP payload. 1150 - 6: if PAD and NH are set to removed: Diet-ESP does consider 1151 neither the Next Header field nor the Pad Length field nor the 1152 Padding Field. The Next Header field of the IP packet is set 1153 to the protocol defined for incoming traffic within the 1154 Traffic Selector of the SA. Because there is no Padding it is 1155 disregarded. 1157 - 7: if PAD is set to removed and NH is set to present: Diet-ESP 1158 considers the Next Header but do not consider the Pad Length 1159 field or the Padding Field. The Next Header field of the IP 1160 packet is set to the value within the Diet-ESP trailer. 1162 - 8: if PAD is set to present and NH is set to removed: Diet-ESP 1163 considers the Pad Length field but removes the Next Header 1164 field. The Next Header field of the IP packet is set to the 1165 protocol defined for incoming traffic within the Traffic 1166 Selector of the SA. The Pad Length field is read and the 1167 Padding is removed from the Data Payload which results the 1168 original Data Payload. 1170 - 9: if PAD and NH are set to present: Diet-ESP considers both 1171 fields Pad Length and Next Header. The Next Header field of 1172 the IP packet is set to the value within the Diet-ESP trailer. 1173 The Pad Length field is read and the Padding is removed from 1174 the Data Payload which results the original Data Payload. 1176 - 10: Decompress the headers inside the ESP payload. 1178 Appendix C. Interaction with other Compression Protocols 1180 Diet-ESP exclusively defines compression for the ESP protocol as well 1181 as the ESP payload. It does not consider compression of the IP 1182 protocol. ROHC or 6LoWPAN may be used by a sensor to compress the IP 1183 (resp. IPv6) header. Since compression usually occurs between the 1184 MAC and IP layers, there are no expected complications with this 1185 family of compression protocols. 1187 C.1. 6LoWPAN 1189 Diet-ESP smoothly interacts with 6LoWPAN. Every 6LoWPAN compression 1190 header (NHC_EH) has an NH bit. This one is set to 1 if the following 1191 header is compressed with 6LoWPAN. Similarly, the NH bit is set to 0 1192 if the following header is not compressed with 6LowPAN. Thus, 1193 interactions between 6LowPAN and Diet-ESP considers two case: 1) NH 1194 set to 0: 6LowPAN indicates the Diet-ESP payload is not compressed 1195 and 2) NH set to 1: 6LowPAN indicates the Diet-ESP payload is 1196 compressed. 1198 Suppose 6LowPAN indicates the Next Header ESP is not compressed by 1199 6LowPAN. If the peers have agreed to use Diet-ESP, then the ESP 1200 layer on each peers receives the expected Diet-ESP packet. Diet-ESP 1201 is fully compatible with 6LowPAN ESP compression disabled. 1203 Suppose 6LowPAN indicates the Next Header ESP is compressed by 1204 6LowPAN. ESP compression with 6LowPAN [I-D.raza-6lowpan-ipsec] 1205 considers the compression of the ESP Header, that is to say the 1206 compression of the SPI and SN fields. As a result 6LowPAN 1207 compression expects a 4 byte SPI and a 4 byte SN from the ESP layer. 1208 Similarly 6LowPAN decompression provides a 4 byte SPI and a 4 byte SN 1209 to the ESP layer. If the peers have agreed to use Diet-ESP and one 1210 of them uses 6LowPAN ESP compression, then the Diet-ESP MUST use SPI 1211 SIZE and the SN SIZE MUST be set to 4 bytes. 1213 C.2. ROHC 1215 ROHC and ROHCoverIPsec have been used to describe Diet-ESP. This 1216 means the ROHC and ROHCoverIPsec concepts and terminology have been 1217 used to describe Diet-ESP. In that sens Diet-ESP is compatible with 1218 the ROHC and ROHCoverIPsec framework. The remaining of the section 1219 describes how Diet-ESP interacts with ROHC and ROHCoverIPsec profiles 1220 and payloads. 1222 ROHC compress packets between the MAC and the IP layer. Compression 1223 can only be performed over non encrypted packets. As a results, this 1224 section considers the case of an ESP encrypted packet and an ESP non 1225 encrypted packet. 1227 For encrypted ESP packet, ROHC profiles that enable ESP compression 1228 (e.g. profile 0x0003 and 0x1003) compresses only the ESP Header and 1229 the IP header. To enable ROHC compression a Diet-ESP packet MUST 1230 present an similar header as the ESP Header, that is a 4 byte SPI and 1231 a 4 byte SN. This is accomplished by setting SPI_SIZE = 4 and 1232 SN_SIZE = 4 in the Diet-ESP Context. Reversely, if the Diet-ESP 1233 packet presents a 4 byte SPI and a 4 byte SN, ROHC can proceed to the 1234 compression. Note that Diet-ESP does not consider the IP header, 1235 then ESP and Diet-ESP are encrypted, thus ROHC can hardly make the 1236 difference between Diet-ESP and ESP packets. For encrypted packets, 1237 the only difference at the MAC layer might be the alignment. 1239 For non encrypted ESP packet, ROHC MAY proceed to the compression of 1240 different fields of ESP and other layers, as the payload appears in 1241 clear. ROHC compressor are unlikely to deal with ESP fields 1242 compressed by Diet-ESP. As a result, it is recommended not to 1243 combine Diet-ESP and ROHC ESP compression with non encrypted ESP 1244 packets. 1246 C.3. ROHCoverIPsec and 6LoWPANoverIPsec 1248 ROHC or 6LoWPAN are not able to compress the ESP payload, as long as 1249 it is encrypted. Diet-ESP describes how to compress the ESP-Trailer, 1250 which is part of the encrypted payload can be compressed. 1251 6LowPANoverIPsec (section 2 of [I-D.raza-6lowpan-ipsec]) and 1252 ROHCoverIPsec define the compression of the ESP payload, more 1253 specifically the upper layer headers (e.g. IP header or Transport 1254 layer header). These protocols need a second, modified ESP stack in 1255 order to make the payload compression possible. Then the packets 1256 with compressed payload are forwarded to this second ESP stack which 1257 can compress or decompress the payload. 1259 Diet-ESP and its extensions also needs a modified ESP stack in order 1260 to perform the compression of ESP payload possible. In addition, 1261 fields that are subject to compression are most likely to be the same 1262 with Diet6ESP and 6LowPANoverIPsec and/or ROHCoverIPsec. Therefore, 1263 if a device implements Diet-ESP and 6LowPANoverIPsec and/or 1264 ROHCoverIPsec the developer needs to define an order the various 1265 frameworks perform the compression. Currently this order has not 1266 been defined, and Diet-ESP is unlikely to be compatible with 1267 6LowPANoverIPsec and/or ROHCoverIPsec. Integration of Diet-ESP and 1268 6LowPANoverIPsec and/or ROHCoverIPsec has not been considered in the 1269 current document as Diet-ESP has been designed to avoid 1270 implementations of 6LowPANoverIPsec and/or ROHCoverIPsec frameworks 1271 to be implemented into the devices. Diet-ESP has been designed to be 1272 more lightweight than 6LowPANoverIPsec and/or ROHCoverIPsec by 1273 avoiding negotiations between compressors and decompressors. 1275 Appendix D. Diet-ESP and Requirements 1277 [I-D.mglt-6lo-diet-esp-requirements] lists the requirements for Diet- 1278 ESP. This section position Diet-ESP described in this document 1279 toward these requirements. 1281 R1: Diet-ESP is completly based on IPsec/ESP and as such benefits 1282 from the standard IPsec security. 1284 R2: Diet-ESP does not introduces vulnerabilities to IPsec/ESP. The 1285 only difference is that compression results in sending less 1286 bytes on the wire. In return the bytes sent over the wire are 1287 decompress to feed the IPsec stack with the appropriated bytes. 1288 Compression MAY require a non standard IPsec/ESP 1289 implementation, as some fields may have been removed. This 1290 fields are packet descriptors (like padding, length...), and 1291 are not related to the security of the standard IPsec/ESP. 1293 R3: Diet-ESP is fully derived from IPsec/ESP ROHC and ROHCoverIPsec 1294 and as such relies on the security of these protocols. 1296 R4: Diet-ESP is able to handle alignments of 8, 16, 32 and 64 bits. 1298 R5: is not in the scope of Diet-ESP. Announcement of the Byte- 1299 Alignment should be performed by IKEv2. 1301 R6: Diet-ESP does not modify how encryption occurs. It only 1302 changes the encrypted payload, which is one of the parameters 1303 for the encryption function. Therefore Diet-ESP is able to 1304 work with any encryption defined in [RFC7321] which also 1305 includes AES-CCM [RFC4309]. 1307 Combined Mode algorithm (e.g. AES-CCM, AES-GCM) have an 1308 additional parameter, called Addition Authentication Data 1309 (AAD). This AAD requires the uncompressed ESP header that is 1310 to say the full SPI and SN. These parameters are not removed 1311 by Diet-ESP. There are well known by the two peer. The ESP 1312 Header MUST be uncompressed before proceeding to encryption/ 1313 decryption. 1315 R7: Diet-ESP can remove all static and compress fields from the 1316 protocol. 1318 R8: The inner payload compression mechanisms are not defined in 1319 this document. This aspect is the purpose of [draft-mglt- 1320 inner-compression] 1322 R9: Diet-ESP compressed packet fields are always a number of bytes 1323 -- that is Diet-ESP do not result in compressed fields that are 1324 not expressed in a natural number of bytes. 1326 R10: Diet-ESP allows the developer define the maximum compression 1327 within the Diet-ESP context. The way the agreement is done, is 1328 out of scope of this document and is described in [draft-mglt- 1329 diet-esp-ikev2]. 1331 R11: Each field in the packet can be compressed separately, which 1332 provides high flexibility. 1334 R12: Since Diet-ESP does not propose compression method flexibility. 1335 The proposed methods are generic enough and there is not 1336 advantage for this flexibility and so it does not seems 1337 appropriated for Diet-ESP. 1339 R13: Each Diet-ESP client can have his own set of supported 1340 contexts. The negotiation is out of scope of this document and 1341 described in [draft-mglt-diet-esp-ikev2]. 1343 R14: Diet-ESP adds small complexity to Standard ESP, like described 1344 in Appendix B. In- and Outbound packet procession is straight- 1345 forward, like shown in Appendix B.5 and Appendix B.5. 1346 Appendix A provides a implementation guideline for a minimal 1347 use case. This one can be ported to any other use case. 1349 R15: Diet-ESP is easy to configure and provides a default-context if 1350 a developer does not want to dive into the details of Diet-ESP. 1352 R16: Diet-ESP can interact with 6LoWPAN and ROHC IP compression, but 1353 SHOULD be able to interact with all future compression applying 1354 after the IP layer as well. 1356 R17: Compatibility with Standard ESP 1: Diet-ESP can be implemented 1357 instead of, nearby or like an add-on to an existing Standard 1358 ESP implementation. 1360 R18: Compatibility with Standard ESP 2: Diet-ESP is able to work 1361 without compression and works with 32 and 64 bits alignment, 1362 which makes it compatible with Standard ESP. 1364 Appendix E. Document Change Log 1366 [draft-mglt-6lo-diet-esp-00.txt]: 1367 Changing affiliation 1369 [draft-mglt-6lo-diet-esp-00.txt]: 1371 Updating references 1373 [draft-mglt-ipsecme-diet-esp-01.txt]: 1374 Diet ESP described in the ROHC framework 1375 ESP is not modified. 1377 [draft-mglt-ipsecme-diet-esp-00.txt]: 1378 NAT consideration added. 1379 Comparison actualized to new Version of 6LoWPAN ESP. 1381 [draft-mglt-dice-diet-esp-00.txt]: First version published. 1383 Authors' Addresses 1385 Daniel Migault 1386 Ericsson 1387 8400 boulevard Decarie 1388 Montreal, QC H4P 2N2 1389 Canada 1391 Email: daniel.migault@ericsson.com 1393 Tobias Guggemos 1394 LMU Munich 1395 Oettingenstr. 67 1396 80538 Muenchen, Bavaria 1397 Germany 1399 Email: guggemos@mnm-team.org 1401 Carsten Bormann 1402 Universitaet Bremen TZI 1403 Postfach 330440 1404 Bremen D-28359 1405 Germany 1407 Phone: +49-421-218-63921 1408 Email: cabo@tzi.org