idnits 2.17.00 (12 Aug 2021) /tmp/idnits49514/draft-mglt-dice-diet-esp-00.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 (January 31, 2014) is 3025 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) == Missing Reference: 'M' is mentioned on line 579, but not defined ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DICE D. Migault (Ed) 3 Internet-Draft Orange 4 Intended status: Standards Track T. Guggemos 5 Expires: August 4, 2014 Orange / LMU Munich 6 D. Palomares 7 Orange / LIP6 - UMPC 8 January 31, 2014 10 Diet-ESP: a flexible and compressed format for IPsec/ESP 11 draft-mglt-dice-diet-esp-00.txt 13 Abstract 15 IPsec/ESP has been designed to secure IP packets exchanged between 16 two nodes. IPsec implements security at the IP layer which makes 17 security transparent to the applications, as opposed to TLS or DTLS 18 that requires application to implement TLS/DTLS. As a result, IPsec 19 enable to define the security rules in a similar way one establishes 20 firewall rules. 22 One of the IPsec's drawbacks is that implementing security on a per 23 packet basis adds overhead to each IP packet. Considering IoT 24 devices, the data transmitted over an IP packet is expected to be 25 rather small, and the cost of sending extra bytes is so high that 26 IPsec/ESP can hardly be used for IoT as it is currently defined in 27 RFC 4303. 29 This document defines Diet-ESP, a protocol that compress and reduce 30 the ESP overhead of IPsec/ESP so that it can fit security and energy 31 efficient IoT requirements. Diet-ESP use already existing mechanism 32 like IKEv2 to negotiate the compression format. Furthermore a lot of 33 information, already existing for an IPsec Security Association, are 34 reused to offer light negotiation in addition to maximum compression. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on August 4, 2014. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Diet-ESP: Protocol Description . . . . . . . . . . . . . . . 5 74 5. Diet-ESP Context: Format Description . . . . . . . . . . . . 8 75 6. Difference between Diet-ESP and ESP . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 10.2. Informational References . . . . . . . . . . . . . . . . 16 82 Appendix A. Comparison . . . . . . . . . . . . . . . . . . . . . 16 83 A.1. Transmitting 1 Byte without anti-replay . . . . . . . . . 16 84 A.2. Transmitting 1 Byte to multi directional connections. . . 18 85 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Introduction 96 The IPsec/ESP [RFC4303] is represented in Figure 1. It was designed 97 to: 1) provide high level of security as a basis, 2) favor 98 interoperability between implementations 3) scale on large 99 infrastructures. 101 In order to match these goals, ESP format favor mandatory fields with 102 fixed sizes that are designed for the worst case scenarios. This 103 results in a kind of "unique" packet format common to all considered 104 scenarios using ESP. These specific scenarios MAY result in carrying 105 "unnecessary" or "larger then required" fields. This cost of 106 additional bytes were than considered as negligible versus 107 interoperability, and this made ESP very successful over the years. 109 With IoT, requirements become slightly different. For most devices, 110 like sensors, sending extra bytes directly impacts the battery and so 111 the life time of the sensor. Furthermore, IoT scenarios MAY consider 112 that sensors MAY be designed not to interconnect between each other, 113 but instead to be connected to a specific Security Gateway. These 114 kind of dedicated connectivity, for example, does not impose the 115 sensors to be fully interoperable with any other IPsec/ESP 116 implementation. In contrast, it MAY be inter-operable with the 117 Security Gateway and those devices supporting the same sensor's 118 options. 120 In this document, we adapted ESP so IoT devices can use ESP designed 121 for their specific needs or applications. Diet-ESP allows to reduce 122 or remove all fields of the ESP format represented in figure 1. How 123 the fields are reduced is defined in the Diet-ESP Context. This 124 Diet-ESP Context MAY be announced or negotiated between the two 125 peers. How the two devices agree on using the same Diet-ESP Context 126 is out of scope of this document. Diet-ESP Context consist of a byte 127 that fully defines the parameters present in a Diet-ESP packet, 128 creating a Diet-ESP packet format agreement between compliant 129 devices. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 134 | Security Parameters Index (SPI) | ^Int. 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 136 | Sequence Number | |ered 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 138 | Payload Data* (variable) | | ^ 139 ~ ~ | | 140 | | |Conf. 141 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 142 | | Padding (0-255 bytes) | |ered* 143 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 144 | | Pad Length | Next Header | v v 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 146 | Integrity Check Value-ICV (variable) | 147 ~ ~ 148 | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: ESP Packet Description 153 3. Terminology 155 This document uses the following terminology: 157 - IoT: Internet of Things 159 - ESP: ESP like described in [RFC4303]. 161 - ESP-packet: The concatenation of the following fields: 163 - ESP-Header: The concatenation of the SPI and SN 165 - ESP Payload: The concatenation of the following two fields. 166 The ESP Payload is usually encrypted. 168 - Data Payload: The application payload. It MAY include 169 a transport layer header. 171 - ESP-Trailer: The Padding concatenated with the Pad 172 Length and Next Header fields. 174 - ESP ICV The ICV generated throw the specified algorithm. 176 - Diet-ESP: Diet version of ESP like described in this document. 178 - Diet-ESP Context: The Context that describes the Diet-ESP packet 179 format (see Section 5). 181 - Diet-ESP-packet: The concatenation of the following fields: 183 - Diet-ESP-Header: The concatenation of the SPI and SN if they 184 appear in the packet. 186 - Diet-ESP Payload: The concatenation of the following two 187 fields. The Diet-ESP Payload is usually encrypted. 189 - Data Payload: The application payload. If the 190 transport layer header is present, it MAY be 191 removed. 193 - Diet-ESP-Trailer: The Padding concatenated with the 194 Pad Length and Next Header fields if they appear in 195 the packet. 197 - Diet-ESP ICV: The ICV generated throw the specified 198 algorithm and MAYBE truncated by Diet-ESP. 200 4. Diet-ESP: Protocol Description 202 This section describes how each field of the ESP can be compressed. 204 SPI SIZE: ESP Security Policy Index is 32 bits long. Diet-ESP omits, 205 leaves unchanged, or reduces the SPI to 8, 16 or 24 bits. The length 206 of the SPI should be guided by 1) the number of simultaneous inbound 207 SA the device is expected to handle and 2) reliability of the IP 208 addresses in order to identify the proper SA for incoming packets. 209 More specifically, a sensor with a single connection to a Security 210 Gateway, may bind incoming packets to the proper SA based only in its 211 IP addresses. In that case, the SPI MAY not be necessary. Other 212 scenarios may consider using the SPI to index the SAs or may consider 213 having multiple ESP channels with the same host from a single host. 214 In that case it may choose a reduced length for the SPI. Note that 215 reducing the size of the SPI may expose the system to security flows. 216 See Section 8 for more details. 218 For those cases where a regular SPI of 32 bits has been negotiated 219 (e.g. via IKEv2 [RFC5996]), the resulting SPI used for Diet-ESP 220 packets corresponds to the high order bits of that 32 bits SPI (see 221 Section 6 for further explanations). 223 SN SIZE: ESP Sequence Number is 32 bit and extended SN is 64 bit 224 long. Diet-ESP omits, leaves unchanged or reduces SN to 8, 16, 24 225 bits. The length of the SN should be guided by 1) how the receiving 226 side handles the SN, 2) the number of packets expected to be sent 227 over Diet-ESP channel, and 3) how the node is willing to use IKEv2 to 228 re-key when SN are expired. SN are used to address replay attacks, 229 thus removing SN may expose the system to security flaws. See 230 Section 8 for more details. If SN is used, a 32 bits value may not 231 be required. Table 1 shows the lifetime of one SA before re-keying 232 is required in case the SN expires. 234 +----------+------------------+-------------------+-----------------+ 235 | SN | 1 packet per | 1 packet per | 1 packet per | 236 | Length | second | minute | hour | 237 +----------+------------------+-------------------+-----------------+ 238 | 8 bit | 4min 16sec | 4h 16min | 10 days 16h | 239 | 16 bit | 18h 12min 16sec | 6 weeks 3 days | ~7 years 25 | 240 | | | 12h | weeks | 241 | 24 bit | ~27 weeks 5 days | 31 years 47 weeks | ~1,915 years | 242 | 32 bit | ~136 years | ~8,171 years | ~490,293 years | 243 +----------+------------------+-------------------+-----------------+ 245 Table 1: Lifetime of one Security Association with different sizes of 246 Sequence Numbers compared to different use cases. 248 Note that SN and SPI MUST be aligned to a multiple of the Alignment 249 value (ALIGN). 251 NH: Diet-ESP is able to remove the Next Header field from the ESP- 252 Trailer if the underlying protocol can be derived from the Traffic 253 Selector (TS) within the SA. More specifically, the next header 254 indicates whether the encrypted ESP payload is an IP packet, a UDP 255 packet, a TCP packet or no next header. The NH can only be removed 256 if this has been explicitly specified in the SA or if the device has 257 a single application. Suppose a device sets an ESP channel with 258 another peer only considering the IP addresses as TS without 259 specifying the transport protocols or (or upper layer protocols). If 260 the device uses this channel for multiple upper layer protocols (like 261 HTTP and tnftp), then the NH cannot be removed as the receiver would 262 not be able to determine whether incoming packets are HTTP or tnftp. 264 Note that removing the Next Header impacts how encryption is 265 performed. For example, the use of AES-CBC [RFC3602] mode requires 266 the last block to be padded to reach a 128 bit alignment. In this 267 case removing the Next Header increases the padding by the Next 268 Header length, which is 8 bits. In this case, removing the Next 269 Header provides few advantages, as it does not reduce the ESP packet 270 length. With AES-CBC, the only advantage of removing the Next Header 271 would be for data with the last block of 15 bytes. In that case, ESP 272 pad with 15 modulo 16 bytes, set the 1 byte pad length field to 15 273 and add the one byte Next Header field. This leads to 15 + 15 + 1 + 274 1 bytes to be sent. On the other hand, removing the Next Header 275 would require only the concatenation of the pad length byte with a 0 276 value, which leads to 16 bytes to be sent. 278 Other modes like AES-CTR [RFC3686] do not have block alignment 279 requirements. Using AES-CTR with ESP only requires the 32 bit 280 alignment - mostly for OS implementation. In fact if an n byte 281 alignment is required (for encryption or for packet format), data of 282 length k * n + n - 1 bytes, k an integer, takes advantage of removing 283 the Next Header and reduces the data to be sent over n bytes. In the 284 case of sensor network it is very likely that data of fixed size k * 285 n + n - 1 will be used. Furthermore, if 32 bits alignment is reduced 286 to 8 bits alignment, Next Header is always an additional unnecessary 287 byte being sent. 289 PAD: With ESP, all packets have a Pad Length field. This field is 290 usually present because ESP requires a 32 bits alignment which is 291 performed with padding. Diet-ESP considers that some devices may use 292 8 bits alignment, in which case padding is not necessary. Similarly, 293 sensors may send application data that has fixed length matching the 294 alignment. Note that alignment may be required by the device (8-bit, 295 16-bit, or more generally 32-bit), but it may also be required by the 296 encryption block size (AES-CBC uses 128 bit blocks). With ESP these 297 scenarios would result in an unnecessary Pad Length field always set 298 to zero. Diet-ESP considers those case with no padding, and thus the 299 Pad Length field can be omitted. 301 ALIGN: Alignment for Padding and Pad Length. ESP is designed for 32 302 bit alignment. This is mostly an OS implementation and hardware 303 design requirements for regular PC processors. IoT may not have 304 these requirements. Having no alignment requirements or a 16 bits 305 alignment requirement prevents or reduces the number of padding bytes 306 to be sent. As a result Diet-ESP considers alternative alignment 307 (8-bit, 16 bit, 32 bit) so to reduce the number of padding bytes. 309 Note that when PAD requires the Pad Length field to be present, ALIGN 310 provides the minimum alignment padding considers. More specifically, 311 ALIGN gives more priority to the hardware or OS implementation than 312 to the encryption algorithm used. In fact with AES-CTR padding will 313 be performed based on the value provided by ALIGN. However, AES-CBC 314 padding is performed on the AES block basis (128 bits). This value 315 overwrites the one provided by ALIGN. 317 IH: With ESP using the tunnel mode, the inner IP Header is sent in 318 every ESP Payload. This extra bytes sent do not carry relevant 319 information over sent packets. As a result Diet-ESP indicates the IP 320 header has been omitted, and MUST be rebuilt by the receiver. These 321 information are negotiated via IKE and are stored in the SA. 323 TH: With ESP the transport header is transmitted in every packet. 324 This layer may not provide relevant information, especially for UDP 325 transport layer. The port parameters may be negotiated via IKE and 326 stored in the SA. As a result Diet-ESP indicates that the transport 327 protocol header (TH) has been removed from the encrypted ESP Payload. 328 This option can only be used if the header can be restored or if it 329 is unnecessary for the further packet procession. Other protocols 330 than UDP are considered out of scope of this document. TCP, for 331 example, includes information that are not as easy to restore, like 332 options, controls or windows. In order to use other transport layer 333 protocols within specific configuration, additional information may 334 be provided in the future. 336 ICV: ESP negotiates Authentication protocols. These protocols 337 generate an ICV of a length defined by the authentication protocol 338 negotiated for the SA. These authentication protocols do not provide 339 ways to perform weak authentication, as it only reduces the size of 340 the ICV. IoT is interested in weak authentication as it may sends a 341 small amount of bytes, and the trade-of between battery life time and 342 security may be worth. As a result Diet-ESP indicates the number of 343 bytes of the ICV. Diet-ESP considers sending the whole ICV or the 344 first 1 byte resp (2, 4, 8, 12, 16, 32) bytes. Note that Note that 345 reducing the size of the SPI may expose the system to security flows. 346 See Section 8 for more details. 348 5. Diet-ESP Context: Format Description 350 This section describes the Diet-ESP Context that contains all 351 necessary parameters for Diet-ESP. 353 0 1 354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 355 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 356 |SPI SIZE|SN SIZE |NH|P |ALIGN|TH|IH| ICV | X| 357 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 359 Figure 2: Diet-ESP Context 361 With the fields defined as below: 363 - SPI SIZE (3 bits): specifies the size of the SPI field length of 364 the Diet-ESP header in byte. Values can be from 0 to 4. A 365 zero value means the SPI does not appear in the Diet-ESP 366 packet. The size depends on the use case, the connection 367 should be used for. 369 - 000: indicates a 0 bit SPI. The SPI is removed from the 370 packet. 372 - 001: indicates an 8 bit SPI in each Diet-ESP-packet. 374 - 010: indicates a 16 bit SPI in each Diet-ESP-packet. 376 - 011: indicates a 24 bit SPI in each Diet-ESP-packet. 378 - 100: indicates a 32 bit SPI in each Diet-ESP-packet. This 379 configuration is according to the RFC 4303 [RFC4303] 381 - 101: Unassigned 383 - 110: Unassigned 385 - 111: Unassigned 387 - SN SIZE (3 bits): specifies the size of the Sequence Number field 388 within the Diet-ESP header in byte. Values can be from 0 to 4. 389 A zero value means the SN does not appear in the Diet-ESP 390 packet. The size depends on the use case, the connection 391 should be used for. 393 - 000: indicates a 0 bit SN. The SN is removed from the 394 packet and anti-replay is disabled on the receiver. 396 - 001: indicates an 8 bit SN in each Diet-ESP-packet. 398 - 010: indicates a 16 bit SN in each Diet-ESP-packet. 400 - 011: indicates a 24 bit SN in each Diet-ESP-packet. 402 - 100: indicates a 32 bit SN in each Diet-ESP-packet. This 403 configuration is according to the RFC 4303 [RFC4303] 405 - 101: Unassigned 407 - 110: Unassigned 409 - 111: Unassigned 411 - NH (1 bit): specifies if the Next Header field appears in the 412 Diet-ESP trailer. NH unset to 0 indicates the Next Header 413 field is present and NH set to 1 indicates the Next Header is 414 omitted. 416 - P (1 bit): specifies if the Pad Length field appears in the Diet- 417 ESP trailer. P unset to 0 indicates the Pad Length field is 418 present and P set to 1 indicates the Pad Length is omitted. 420 - ALIGN (2 bits): specifies Padding, Padding Length as follows: 422 - 00: indicates an 8 bit alignment. The field Pad Length is 423 omitted and the Diet-ESP packet never has Padding. 425 - 01: indicates a 16 bit alignment. The field Pad Length is 426 always present. 428 - 10: indicates a 32 bit alignment. The field Pad Length is 429 always present. 431 - 11: Unassigned 433 - TH (1 bit): specifies if the transport layer field appears in the 434 Diet-ESP Payload Data. TH unset to 0 indicates the Transport 435 header field is present and TH set to 1 indicates the transport 436 header is omitted. In this case, the transport protocol MUST 437 be specified in the SA with its associated port. If a non 438 unique port or a non unique transport protocol is specified, 439 this bit MUST be unset to 0. Otherwise, the device will not be 440 able to rebuilt the transport header. This document only 441 considers UDP. 443 - IH (1 bit): specifies if the inner IP address field appears in the 444 Diet-ESP Payload Data. This bit is only significant for the 445 tunnel mode. With IPsec transport mode, IH SHOULD be set to 0 446 and ignored. With tunnel mode IH unset to 0 indicates the 447 inner IP header field is present and IH set to 1 indicates the 448 inner IP header is omitted. 450 - ICV (2 bits): specifies the transmitted number of bytes to 451 authenticate the Diet-ESP packet. Note that ICV is optional so 452 if one chose not to perform authentication, it SHOULD negotiate 453 the authentication algorithm to NULL as defined in [RFC4835]. 454 The minimum length greater than 0 for ICV is 96 bits and can be 455 generated with the following hash functions: HMAC-MD5-96 456 [RFC2403], HMAC-SHA1-96 [RFC2404], AES-CMAC-96 [RFC4494], AES- 457 XCBC-MAC-96 [RFC3566]. As a result ICV only specifies size 458 lower than 96 bits. 460 - 000: ICV is left untouched as it is specified by the 461 authentication algorithm. 463 - 001: Diet-ESP ICV consists of the 8 most significant bits of 464 ESP ICV. 466 - 010: Diet-ESP ICV consists of the 16 most significant bits 467 of ESP ICV. 469 - 011: Diet-ESP ICV consists of the 32 most significant bits 470 of ESP ICV. 472 - 100: Diet-ESP ICV consists of the 64 most significant bits 473 of ESP ICV. 475 - 101: Unassigned 477 - 110: Unassigned 479 - 111: Unassigned 481 - X (1 bit): Extension bit. When set to 1, this bit indicates an 482 additional byte carry information. In this document, this bit 483 MUST be set to 0. 485 6. Difference between Diet-ESP and ESP 487 This section details how to use Diet-ESP to send and receive 488 messages. The use of Diet-ESP is based on the IPsec architecture 489 [RFC4301] and ESP [RFC4303]. We suppose the reader is familiar with 490 these documents and list here the adaptation that MAY be involved by 491 Diet-ESP. 493 Each device has an internal parameter that defines the minimal kernel 494 alignment that is acceptable. The value HARD-ALIGN defines the 495 minimum alignment allowed by the devices. 497 Diet-ESP Context with SPI SIZE + SN SIZE that is not a multiple of 498 ALIGN MUST be rejected. 500 For devices using a single SPI SIZE value (e.g. sensors), the SA will 501 be indexed with the SPI as described in ESP. More specifically, SPI 502 is used as the index in the SAD. The only difference is that it has 503 smaller size. 505 For devices that allow multiple SPI SIZE, like some IoT generic end 506 points or IoT Security Gateways, SAD lookup has to deal with indexes 507 of different sizes. One way would be to convert SPI of any size to a 508 standard 4 bytes SPI. This means that for inbound packets a 509 conversion from SPI SIZE bytes SPI to 4 bytes SPI is performed before 510 the SAD lookup is performed. Similarly, a 4 bytes SPI to SPI SIZE 511 bytes SPI conversion is performed before inserting the SPI into the 512 Diet-ESP packet. A possible implementation may consist in using the 513 SPI SIZE bytes SPI as the low order bytes of the 4 byte SPI and fill 514 with NULL bytes the remaining high order bytes. This also means that 515 any negotiated SPI must not start with NULL bytes. Another way could 516 consist in adding the SPI SIZE argument in the SAD lookup. This 517 means that instead of looking at the SPI, implementations will 518 consider looking at the (SPI, SPI SIZE). 520 The SPI of the SA may be negotiated using IKEv2 [RFC5996]. Regular 521 IKEv2 implementation negotiate a 4 byte SPI. The SPI considered in 522 Diet-ESP consists in the SPI SIZE low power bytes of this SPI. Only 523 the value should be considered in the SAD. How the SPI SIZE SPI is 524 represented in the SAD is another issue addressed above. 526 When the SPI is omitted, the device must be able to perform a SAD 527 lookup that is not based on a SPI value, but only the IP addresses. 528 This is specific to Diet-ESP, and one way to make Diet-ESP compliant 529 with the IPsec architecture is to generate a SPI from the IP 530 addresses. Most likely, no collision will occur. To avoid all 531 collision cases, one can introduce a check function that proceed to 532 the SPI and IP address match. If SPI matches but the IP address does 533 not match then the hash function can be performed again over the 534 previous SPI, until a match is found. Of course the system should 535 define the maximum number of hashes that should be performed. 537 Sequence number in ESP [RFC4303] can be of 4 bytes or 8 bytes for 538 extended ESP. Diet-ESP introduces different sizes. One way to deal 539 with this is to add a MAX_SN value that stores the maximum value the 540 SN can have. Any new value of the SN will be check against this 541 MAX_SN. 543 NH, TH, IH, P indicate fields or payloads that are removed from the 544 Diet-ESP packet. How the Diet-ESP packet is generated depends on the 545 Payload Data of lPD bytes, BLCK the block size of the encryption 546 algorithm and the device alignment ALIGN. We note M = MAX(BLCK, 547 ALIGN). Although not normative the resulting Diet-ESP packet should 548 be and explained below. We consider the Diet-ESP Payload as 549 described in Section 3 551 - 1: if TH is set to 1, then remove the transport layer of the 552 Payload Data. 554 - 2: if IH is set to 1, and the IPsec mode is tunnel, then remove 555 the inner IP address of the Payload Data. 557 - 3: if PAD is set to 0 and NH is set to 0: Diet-ESP considers both 558 fields Pad Length and Next Header. The Diet-ESP Payload is the 559 encryption of the following clear text: Payload Data | Padding 560 of Pad Length bytes | Pad Length field | Next Header field. 561 The Pad Length value is such that lPD + 2 + Pad Length = 0 [M]. 563 - 4: if PAD is set to 0 and NH is set to 1: Diet-ESP considers the 564 Pad Length field but removes the Next Header field. The ESP 565 Payload is the encryption of the following clear text: Payload 566 Data | Padding of Pad Length bytes | Pad Length field | Next 567 Header field. The Pad Length value is such that lPD + 1 + Pad 568 Length = 0 [M]. 570 - 5: if PAD is set to 1 and NH is set to 0: Diet-ESP considers the 571 Next Header but do not consider the Pad Length field or the 572 Padding Field. This is valid as long as lPD + 1 = 0 [M]. If M 573 = 1 as it is the case for AES-CTR this equation is always true. 574 On the other hand the use of specific block size requires the 575 application to send specific length of application data. 577 - 6: if PAD is set to 1 and NH is set to 1: Diet-ESP does consider 578 neither the Next Header field nor the Pad Length field nor the 579 Padding Field. This is valid as long as lAD = 0 [M]. If M = 1 580 as it is the case for AES-CTR this equation is always true. On 581 the other hand the use of specific block size requires the 582 application to send specific length of application data. 584 Decryption is performed the other way around. 586 After authenticating and encrypting the Diet-ESP payload the original 587 packet is rebuild as follows: 589 - 1: if PAD is set to 1 and NH is set to 1: Diet-ESP does consider 590 neither the Next Header field nor the Pad Length field nor the 591 Padding Field. The Next Header field of the IP packet is set 592 to the protocol defined for incoming traffic within the Traffic 593 Selector of the SA. Because there is no Padding it is 594 disregarded. 596 - 2: if PAD is set to 1 and NH is set to 0: Diet-ESP considers the 597 Next Header but do not consider the Pad Length field or the 598 Padding Field. The Next Header field of the IP packet is set 599 to the value within the Diet-ESP trailer. 601 - 3: if PAD is set to 0 and NH is set to 1: Diet-ESP considers the 602 Pad Length field but removes the Next Header field. The Next 603 Header field of the IP packet is set to the protocol defined 604 for incoming traffic within the Traffic Selector of the SA. 605 The Pad Length field is read and the Padding is removed from 606 the Data Payload which results the original Data Payload. 608 - 4: if PAD is set to 0 and NH is set to 0: Diet-ESP considers both 609 fields Pad Length and Next Header. The Next Header field of 610 the IP packet is set to the value within the Diet-ESP trailer. 611 The Pad Length field is read and the Padding is removed from 612 the Data Payload which results the original Data Payload. 614 - 5: if IH is set to 1, and the IPsec mode is tunnel and the IP 615 header is reconstructed. The source and destination address 616 and the Next Header field are read from the Traffic Selector. 617 The Payload Length is calculated including the size of the 618 transport header, regardless if it is removed with TH or not. 619 All other IP-header values are set to common defaults or have 620 to be negotiated otherwise which is out of scope of this 621 document. 623 -6: if TH is set to 1, the Transport layer header is restored with 624 the information in the Security Association. Section 4 625 describes some differences between the different protocols. In 626 this document we focus on UDP which can be easily restored with 627 the ports inside the Traffic Selector. The Length field can be 628 calculated and the checksum can be left as 0 according to 629 [RFC0768] 631 7. IANA Considerations 633 There are no IANA consideration for this document. 635 8. Security Considerations 637 This section lists security considerations related to the Diet-ESP 638 protocol. 640 Small SPI SIZE exposes the device to DoS. For a device, the number 641 of SA is related to the number of SPI. For systems using small SPI 642 SIZE values as index of their database, the number of simultaneous 643 communications is limited by the SPI SIZE. This means that a given 644 device initiating SPI SIZE communications can isolate the system. In 645 order to leverage this vulnerability, one can consider receiving 646 systems that generate 32 bits SPI with a hash function that considers 647 different parameters associated to the reduced SPI. For example, if 648 one use the IP addresses as well as the reduced SPI, the number of 649 SPI becomes SPI SIZE per IP address. This may be sufficient as 650 sensors are not likely to perform multiple communications. 652 Small size of ICV reduces the authentication strength. For example 8 653 bits mean that authentication can be spoofed with a probability of 1/ 654 256. Standard value considers a length of 96 bit for reliable 655 authentication. If specified, the ICV field is truncated after the 656 given number of bits which, for sure, has to be mentioned while 657 incoming packet procession as well. For removing authentication ESP 658 NULL has to be negotiated, as described in RFC4303. 660 Removing the SN prevents protection against replay attack. 662 9. Acknowledgment 664 10. References 666 10.1. Normative References 668 [I-D.raza-6lowpan-ipsec] 669 Raza, S., Duquennoy, S., and G. Selander, "Compression of 670 IPsec AH and ESP Headers for Constrained Environments", 671 draft-raza-6lowpan-ipsec-01 (work in progress), September 672 2013. 674 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 675 August 1980. 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, March 1997. 680 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 681 ESP and AH", RFC 2403, November 1998. 683 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 684 ESP and AH", RFC 2404, November 1998. 686 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 687 and Its Use With IPsec", RFC 3566, September 2003. 689 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 690 Algorithm and Its Use with IPsec", RFC 3602, September 691 2003. 693 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 694 Counter Mode With IPsec Encapsulating Security Payload 695 (ESP)", RFC 3686, January 2004. 697 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 698 Internet Protocol", RFC 4301, December 2005. 700 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 701 4303, December 2005. 703 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 704 Algorithm and Its Use with IPsec", RFC 4494, June 2006. 706 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 707 Requirements for Encapsulating Security Payload (ESP) and 708 Authentication Header (AH)", RFC 4835, April 2007. 710 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 711 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 712 5996, September 2010. 714 10.2. Informational References 716 [RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, 717 "Integration of Robust Header Compression over IPsec 718 Security Associations", RFC 5856, May 2010. 720 Appendix A. Comparison 722 This section compares the proposed Diet ESP with 6LoWPAN ESP 723 [I-D.raza-6lowpan-ipsec] related to IoT use cases. It shows the 724 different ESP packet sent with the two compression methods. In each 725 case the maximum possible compression is used and the underlying UDP 726 header is compressed as much as possible. The big advantage of Diet 727 ESP compression removing the UDP header appears. Furthermore there 728 are no additional compression configuration bytes to be sent in each 729 packet, like done in 6LoWPAN compression, because the configuration 730 is negotiated at the beginning of the during the IKEv2 [RFC5996] 731 negotiation. Diet ESP uses the idea of ROHC[RFC5856] compression 732 removing the disadvantage that the whole packet has to be sent once 733 at the beginning of the connection, because it considers that a lot 734 of information of the Security Association can be reused to 735 decompress the packet. 737 Both comparisons are using 8 bits alignment. The figures are aligned 738 to 16 bits to improve the readability. 740 A.1. Transmitting 1 Byte without anti-replay 742 6LoWPAN does not offer the possibility of removing the Sequence 743 number. Therefore the minimum number of 16 bit has to be sent in 744 each packet, even if it is not going to be used. If a SN of 8 or 24 745 bit should be used, similar characteristics can be recognized. 747 6LoWPAN does not offer to reduce the ICV as it is not removed with 748 NULL-authentication. Diet-ESP offers reducing to fair securely 64 749 bits. 751 AES-CTR is used for encryption. 753 Figure 3a and 3b show this comparison. The advantage of Diet ESP for 754 this example is 96 bits. 756 0 1 757 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 758 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 759 0| initialization vector | 760 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 761 16| initialization vector | 762 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 763 32| initialization vector | 764 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 765 48| initialization vector | 766 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 767 64| 1 byte data | ICV | 768 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 769 80| ICV | 770 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 771 96| ICV | 772 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 773 112| ICV | 774 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 775 128| ICV | 776 +--+--+--+--+--+--+--+--+ 778 Figure 3a) 1 byte Data Payload with Diet-ESP. 779 (no SPI, no SN, no PAD, no NH) 781 0 1 782 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 783 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 784 0| Id |0 |SP|SN|NH| SN | 785 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 786 16| SN | initialization vector | 787 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 788 32| initialization vector | 789 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 790 48| initialization vector | 791 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 792 64| initialization vector | 793 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 794 80| initialization vector |source port| dest port | 795 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 796 96| length | 797 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 798 112| 1 byte data | pad length | 799 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 800 128| Id |0 |C | P | ICV | 801 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 802 144| ICV | 803 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 804 160| ICV | 805 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 806 176| ICV | 807 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 808 192| ICV | 809 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 810 208| ICV | 811 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 812 224| ICV | 813 +--+--+--+--+--+--+--+--+ 815 Figure 3b) 1 byte data payload with 6LoWPAN ESP. 816 (no SPI, 16 bits SN, 8 bits pad length, 817 8 bits 6LoWPAN NH) 819 A.2. Transmitting 1 Byte to multi directional connections. 821 Having multiple connections to one host implies the use of the SPI to 822 identify the correct Security Association. Using 6LoWPAN ESP there 823 is no possibility of reducing the SPI, it is only possible to remove 824 it completely. Diet ESP allows the reduction to 8, 16 and 24 bit. 825 In most sensor use cases 254 possible connection are more than 826 enough, whereas the following two pictures show the advantage of Diet 827 ESP against 6LoWPAN ESP for an 8 bit SPI. This advantage remains as 828 long as there is no usage of the whole range of the 32 bit SPI, which 829 is extraordinary for sensors. Since there is no possibility to 830 remove the SN with 6LoWPAN it has to be at least 16 Bit. 832 6LoWPAN does not offer the possibility of removing the Sequence 833 number. Therefore the minimum number of 16 bit has to be sent in 834 each packet, even if it is not going to be used. If a SN of 8 or 24 835 bit should be used, similar characteristics can be recognized. 837 6LoWPAN does not offer to reduce the ICV as it is not removed with 838 NULL-authentication. Diet-ESP offers reducing to fair securely 64 839 bits. 841 AES-CTR is used for encryption. 843 Figure 4a and 4b show this comparison. In case of an 8 bit SPI the 844 advantage is 120 bits. 846 0 1 847 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 848 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 849 0| SPI | initialization vector | 850 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 851 16| initialization vector | 852 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 853 32| initialization vector | 854 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 855 48| initialization vector | 856 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 857 64| initialization vector | 1 byte data | 858 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 859 80| ICV | 860 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 861 96| ICV | 862 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 863 112| ICV | 864 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 865 128| ICV | 866 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 868 Figure 4a) 1 byte Data Payload with Diet-ESP. 869 (8 bits SPI, no SN, no PAD, no NH) 871 0 1 872 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 873 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 874 0| Id |0 |SP|SN|NH| SPI | 875 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 876 16| SPI | 877 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 878 32| SPI | SN | 879 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 880 48| SN | initialization vector | 881 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 882 64| initialization vector | 883 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 884 80| initialization vector | 885 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 886 96| initialization vector | 887 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 888 112| initialization vector |source port| dest port | 889 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 890 128| length | 891 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 892 144| 1 byte data | pad length | 893 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 894 160| Id |0 |C | P | ICV | 895 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 896 176| ICV | 897 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 898 192| ICV | 899 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 900 208| ICV | 901 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 902 224| ICV | 903 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 904 240| ICV | 905 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 906 256| ICV | 907 +--+--+--+--+--+--+--+--+ 909 Figure 4b) 1 byte data payload with 6LoWPAN ESP. 910 (32 bits SPI, 16 bits SN, 911 8 bits pad length, 8 bits 6LoWPAN NH) 913 Appendix B. Document Change Log 915 [RFC Editor: This section is to be removed before publication] 917 -00: First version published. 919 Authors' Addresses 921 Daniel Migault 922 Orange 923 38 rue du General Leclerc 924 92794 Issy-les-Moulineaux Cedex 9 925 France 927 Phone: +33 1 45 29 60 52 928 Email: daniel.migault@orange.com 930 Tobias Guggemos 931 Orange / LMU Munich 932 Am Osteroesch 9 933 87637 Seeg, Bavaria 934 Germany 936 Email: tobias.guggemos@gmail.com 938 Daniel Palomares 939 Orange / LIP6 - UMPC 940 10, Rue du Moulin 941 92170 Vanves, Ille-de-France 942 France 944 Email: daniel.palomares@orange.com