idnits 2.17.1 draft-ietf-lwig-minimal-esp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 1, 2021) is 1120 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-mglt-ipsecme-diet-esp-07 == Outdated reference: A later version (-04) exists of draft-mglt-ipsecme-ikev2-diet-esp-extension-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Light-Weight Implementation Guidance (lwig) D. Migault 3 Internet-Draft Ericsson 4 Intended status: Informational T. Guggemos 5 Expires: October 3, 2021 LMU Munich 6 April 1, 2021 8 Minimal ESP 9 draft-ietf-lwig-minimal-esp-04 11 Abstract 13 This document describes a minimal implementation of the IP 14 Encapsulation Security Payload (ESP) defined in RFC 4303. Its 15 purpose is to enable implementation of ESP with a minimal set of 16 options to remain compatible with ESP as described in RFC 4303. A 17 minimal version of ESP is not intended to become a replacement of the 18 RFC 4303 ESP. Instead, a minimal implementation is expected to be 19 optimized for constrained environment while remaining interoperable 20 with implementations of RFC 4303 ESP. Some constrains include 21 limiting the number of flash writes, handling frequent wakeup / sleep 22 states, limiting wakeup time, or reducing the use of random 23 generation. 25 This document does not update or modify RFC 4303, but provides a 26 compact description of how to implement the minimal version of the 27 protocol. RFC 4303 remains the authoritative description. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 3, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 3. Security Parameter Index (SPI) (32 bit) . . . . . . . . . . . 4 66 3.1. Considerations over SPI generation . . . . . . . . . . . 4 67 4. Sequence Number(SN) (32 bit) . . . . . . . . . . . . . . . . 6 68 5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. Next Header (8 bit) . . . . . . . . . . . . . . . . . . . . . 9 70 7. ICV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 8. Cryptographic Suites . . . . . . . . . . . . . . . . . . . . 10 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 11. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 12 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 12.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Requirements Notation 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in 85 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 86 capitals, as shown here. 88 2. Introduction 90 ESP [RFC4303] is part of the IPsec protocol suite [RFC4301]. IPsec 91 is used to provide confidentiality, data origin authentication, 92 connectionless integrity, an anti-replay service (a form of partial 93 sequence integrity) and limited traffic flow confidentiality. 95 Figure 1 describes an ESP Packet. Currently ESP is implemented in 96 the kernel of major multipurpose Operating Systems (OS). The ESP and 97 IPsec suite is usually implemented in a complete way to fit multiple 98 purpose usage of these OS. However, completeness of the IPsec suite 99 as well as multipurpose scope of these OS is often performed at the 100 expense of resources, or performance. As a result, constrained 101 devices are likely to have their own implementation of ESP optimized 102 and adapted to their specificities such as limiting the number of 103 flash writes (for each packet or across wake time), handling frequent 104 wakeup and sleep state, limiting wakeup time, or reducing the use of 105 random generation. With the adoption of IPsec by IoT devices with 106 minimal IKEv2 [RFC7815] and ESP Header Compression (EHC) with 107 [I-D.mglt-ipsecme-diet-esp] or 108 [I-D.mglt-ipsecme-ikev2-diet-esp-extension], it becomes crucial that 109 ESP implementation designed for constrained devices remains inter- 110 operable with the standard ESP implementation to avoid a fragmented 111 usage of ESP. This document describes the minimal properties an ESP 112 implementation needs to meet to remain interoperable with [RFC4303] 113 ESP. In addition, this document also provides a set of options to 114 implement these properties under certain constrained environments. 116 For each field of the ESP packet represented in Figure 1 this 117 document provides recommendations and guidance for minimal 118 implementations. The primary purpose of Minimal ESP is to remain 119 interoperable with other nodes implementing RFC 4303 ESP, while 120 limiting the standard complexity of the implementation. 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) | ^Int. 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 127 | Sequence Number | |ered 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 129 | Payload Data* (variable) | | ^ 130 ~ ~ | | 131 | | |Conf. 132 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 133 | | Padding (0-255 bytes) | |ered* 134 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 135 | | Pad Length | Next Header | v v 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 137 | Integrity Check Value-ICV (variable) | 138 ~ ~ 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: ESP Packet Description 144 3. Security Parameter Index (SPI) (32 bit) 146 According to the [RFC4303], the SPI is a mandatory 32 bits field and 147 is not allowed to be removed. 149 The SPI has a local significance to index the Security Association 150 (SA). From [RFC4301] section 4.1, nodes supporting only unicast 151 communications can index their SA only using the SPI. On the other 152 hand, nodes supporting multicast communications must also use the IP 153 addresses and thus SA lookup needs to be performed using the longest 154 match. 156 For nodes supporting only unicast communications, it is RECOMMENDED 157 to index SA with the SPI only. The index MAY be based on the full 32 158 bits of SPI or a subset of these bits. Some other local constraints 159 on the node may require a combination of the SPI as well as other 160 parameters to index the SA. 162 Values 0-255 MUST NOT be used. As per section 2.1 of [RFC4303], 163 values 1-255 are reserved and 0 is only allowed to be used internal 164 and it MUST NOT be sent on the wire. 166 [RFC4303] does not require the SPI to be randomly generated over 32 167 bits. However, this is the RECOMMENDED way to generate SPIs as it 168 provides some privacy benefits and avoids, for example, correlation 169 between ESP communications. To randomly generate a 32 bit SPI, the 170 node generates a random 32 bit value, checks does not fall in the 171 0-255 range. If the SPI has an acceptable value, it is used to index 172 the inbound session, otherwise the SPI is re-generated until an 173 acceptable value is found. 175 However, some constrained nodes may be less concerned by the privacy 176 properties associated to SPIs randomly generated. Examples of such 177 nodes might include sensors looking to reduce their code complexity, 178 in which case the use of a predictive function to generate the SPI 179 might be preferred over the generation and handling of random values. 180 An example of such predictable function may consider the combination 181 of a fixed value and the memory address of the SAD structure. For 182 every incoming packet, the node will be able to point the SAD 183 structure directly from the SPI value. This avoids having a separate 184 and additional binding between SPI and SAD entries that is involved 185 for every incoming packet. 187 3.1. Considerations over SPI generation 189 SPI that are not randomly generated over 32 bits MAY lead to privacy 190 and security concerns. As a result, the use of alternative designs 191 requires careful security and privacy reviews. This section provides 192 some considerations upon the adoption of alternative designs. 194 Note that SPI value is used only for inbound traffic, as such the SPI 195 negotiated with IKEv2 [RFC7296] or [RFC7815] by a peer, is the value 196 used by the remote peer when it sends traffic. As SPI is only used 197 for inbound traffic by the peer, this allows each peer to manage the 198 set of SPIs used for its inbound traffic. Similarly, the privacy 199 concerns associated with the generation of nonrandom SPI is also 200 limited to the incoming traffic. 202 When alternate designs are considered, it is likely that the number 203 of possible SPIs will be limited. This limit should both consider 204 the number of inbound SAs - possibly per IP addresses - as well as 205 the ability for the node to rekey. SPI can typically be used to 206 proceed to clean key update and the SPI value may be used to indicate 207 which key is being used. This can typically be implemented by a SPI 208 being encoded with the Security Association Database (SAD) entry on a 209 subset of bytes (for example 3 bytes), while the remaining byte is 210 left to indicate the rekey index. 212 The use of a smaller number of SPIs across communications comes with 213 privacy and security concerns. Typically some specific values or 214 subset of SPI values may reveal the models or manufacturer of the 215 node implementing ESP. This may raise some privacy issues as an 216 observer is likely to be able to determine the constrained devices of 217 the network. In some cases, these nodes may host a very limited 218 number of applications - typically a single application - in which 219 case the SPI would provide some information related to the 220 application of the user. In addition, the device or application may 221 be associated with some vulnerabilities, in which case specific SPI 222 values may be used by an attacker to discover vulnerabilities. 224 While the use of randomly generated SPI may reduce the leakage or 225 privacy or security related information by ESP itself, these 226 information may also be leaked otherwise and a privacy analysis 227 should consider at least the type of information as well the traffic 228 pattern. Typically, temperature sensors, wind sensors, used outdoors 229 do not leak privacy sensitive information and mosty of its traffic is 230 expected to be outbound traffic. When used indoors, a sensor that 231 reports every minute an encrypted status of the door (closed or 232 opened) leaks truly little privacy sensitive information outside the 233 local network. 235 4. Sequence Number(SN) (32 bit) 237 According to [RFC4303], the Sequence Number (SN) is a mandatory 32 238 bits field in the packet. 240 The SN is set by the sender so the receiver can implement anti-replay 241 protection. The SN is derived from any strictly increasing function 242 that guarantees: if packet B is sent after packet A, then SN of 243 packet B is strictly greater than the SN of packet A. 245 Some constrained devices may establish communication with specific 246 devices, like a specific gateway, or nodes similar to them. As a 247 result, the sender may know whereas the receiver implements anti- 248 replay protection or not. Even though the sender may know the 249 receiver does not implement anti-replay protection, the sender MUST 250 implement an always increasing function to generate the SN. 252 Usually, SN is generated by incrementing a counter for each packet 253 sent. A constrained device may avoid maintaining this context and 254 use another source that is known to always increase. Typically, 255 constrained nodes using 802.15.4 Time Slotted Channel Hopping (TSCH), 256 whose communication is heavily dependent on time, can take advantage 257 of their clock to generate the SN. A lot of IoT devices are in a 258 sleep state most of the time wake up and are only awake to perform a 259 specific operation before going back to sleep. They do have separate 260 hardware that allows them to wake up after a certain timeout, and 261 most likely also timers that start running when the device was booted 262 up, so they might have a concept of time with certain granularity. 263 This requires to store any information in a stable storage - such as 264 flash memory - that can be restored across sleeps. Storing 265 information associated with the SA such as SN requires some read and 266 writing operation on a stable storage after each packet is sent as 267 opposed to SPI or keys that are only written at the creation of the 268 SA. Such operations are likely to wear out the flash, and slow down 269 the system greatly, as writing to flash is not as fast as reading. 270 Their internal clocks/timers might not be very accurate, but they 271 should be enough to know that each time they wake up their time is 272 greater than what it was last time they woke up. Using time for SN 273 would guarantee a strictly increasing function and avoid storing any 274 additional values or context related to the SN. When the use of a 275 clock is considered, one should take care that packets associated 276 with a given SA are not sent with the same time value. Note however 277 that standard receivers are generally configured with incrementing 278 counters and, if not appropriately configured, the use of a 279 significantly larger SN may result in the packet out of the 280 receiver's windows and that packet being discarded. 282 For inbound traffic, it is RECOMMENDED that any receiver provides 283 anti-replay protection, and the size of the window depends on the 284 ability of the network to deliver packets out of order. As a result, 285 in an environment where out of order packets is not possible the 286 window size can be set to one. However, while RECOMMENDED, there are 287 no requirements to implement an anti-replay protection mechanism 288 implemented by IPsec. Similarly to the SN the implementation of anti 289 replay protection may require the device to write the received SN for 290 every packet, which may in some cases come with the same drawbacks as 291 those exposed for SN. As a result, some implementations MAY drop an 292 non required anti replay protection especially when the necessary 293 resource involved overcomes the benefit of the mechanism. A typical 294 example might consider an IoT device such as a temperature sensor 295 that is sending a temperature every 60 seconds, and that receives an 296 acknowledgment from the receiver. In such cases, the ability to 297 spoof and replay an acknowledgement is of limited interest and may 298 not justify the implementation of an anti replay mechanism. 299 Receiving peers may also implement their own anti-replay mechanism. 300 Typically, when the sending peer is using SN based on time, anti- 301 replay may be implemented by discarding any packets that present a SN 302 whose value is too much in the past. Note that such mechanisms may 303 consider clock drifting in various ways in addition to acceptable 304 delay induced by the network to avoid the anti replay windows 305 rejecting legitimate packets. When a packet is received at a regular 306 time interval, some variant of time based mechanisms may not even use 307 the value of the SN, but instead only consider the receiving time of 308 the packet. 310 SN can be encoded over 32 bits or 64 bits - known as Extended 311 Sequence Number (ESN). As per [RFC4303], the support ESN is not 312 mandatory. The determination of the use of ESN is based on the 313 largest possible value a SN can take over a session. When SN is 314 incremented for each packet, the number of packets sent over the 315 lifetime of a session may be considered. However, when the SN is 316 incremented differently - such as when time is used - the maximum 317 value SN needs to be considered instead. Note that the limit of 318 messages being sent is primarily determined by the security 319 associated with the key rather than the SN. The security of all data 320 protected under a given key decreases slightly with each message and 321 a node MUST ensure the limit is not reached - even though the SN 322 would permit it. Estimation of the maximum number of packets to be 323 sent by a node is always challenging and as such should be considered 324 cautiously as nodes could be online for much more time than expected. 325 Even for constrained devices, it is RECOMMENDED to implement some 326 rekey mechanisms (see Section 10). 328 5. Padding 330 The purpose of padding is to respect the 32 bit alignment of ESP or 331 block size expected by an encryption transform - such as AES-CBC for 332 example. ESP MUST have at least one padding byte Pad Length that 333 indicates the padding length. ESP padding bytes are generated by a 334 succession of unsigned bytes starting with 1, 2, 3 with the last byte 335 set to Pad Length, where Pad Length designates the length of the 336 padding bytes. 338 Checking the padding structure is not mandatory, so the constrained 339 device may not proceed to such checks, however, in order to 340 interoperate with existing ESP implementations, it MUST build the 341 padding bytes as recommended by ESP. 343 In some situation the padding bytes may take a fix value. This would 344 typically be the case when the Data Payload is of fix size. 346 ESP [RFC4303] also provides Traffic Flow Confidentiality (TFC) as a 347 way to perform padding to hide traffic characteristics, which differs 348 from respecting a 32 bit alignment. TFC is not mandatory and MUST be 349 negotiated with the SA management protocol. TFC has not yet being 350 widely adopted for standard ESP traffic. One possible reason is that 351 it requires to shape the traffic according to one traffic pattern 352 that needs to be maintained. This is likely to require extra 353 processing as well as providing a "well recognized" traffic shape 354 which could end up being counterproductive. As such, it is NOT 355 RECOMMENDED that minimal ESP implementation supports TFC. 357 As a result, TFC cannot be enabled with minimal ESP, and 358 communication protection that were rely on TFC will be more sensitive 359 to traffic shaping. This could expose the application as well as the 360 devices used to a passive monitoring attacker. Such information 361 could be used by the attacker in case a vulnerability is disclosed on 362 the specific device. In addition, some application use - such as 363 health applications - may also reveal important privacy oriented 364 information. 366 Some constrained nodes that have limited battery lifetime may also 367 prefer avoiding sending extra padding bytes. However, the same nodes 368 may also be very specific to an application and device. As a result, 369 they are also likely to be the main target for traffic shaping. In 370 most cases, the payload carried by these nodes is quite small, and 371 the standard padding mechanism may also be used as an alternative to 372 TFC, with a sufficient tradeoff between the require energy to send 373 additional payload and the exposure to traffic shaping attacks. In 374 addition, the information leaked by the traffic shaping may also be 375 addressed by the application level. For example, it is preferred to 376 have a sensor sending some information at regular time interval, 377 rather when a specific event is happening. Typically, a sensor 378 monitoring the temperature, or a door is expected to send regularly 379 the information - i.e. the temperature of the room or whether the 380 door is closed or open) instead of only sending the information when 381 the temperature has raised or when the door is being opened. 383 6. Next Header (8 bit) 385 According to [RFC4303], the Next Header is a mandatory 8 bits field 386 in the packet. Next header specifies the data contained in the 387 payload as well as dummy packet, i.e. packets with the Next Header 388 with a value 59 meaning "no next header". In addition, the Next 389 Header may also carry an indication on how to process the packet 390 [I-D.nikander-esp-beet-mode]. 392 The ability to generate and receive dummy packet is required by 393 [RFC4303]. For interoperability, a minimal ESP implementation MUST 394 discard dummy packets without indicating an error. Note that such 395 recommendation only applies for nodes receiving packets, and that 396 nodes designed to only send data may not implement this capability. 398 As the generation of dummy packets is subject to local management and 399 based on a per-SA basis, a minimal ESP implementation may not 400 generate such dummy packet. More especially, in constrained 401 environment sending dummy packets may have too much impact on the 402 device lifetime, and so may be avoided. On the other hand, 403 constrained nodes may be dedicated to specific applications, in which 404 case, traffic pattern may expose the application or the type of node. 405 For these nodes, not sending dummy packet may have some privacy 406 implication that needs to be measured. However, for the same reasons 407 exposed in Section 5 traffic shaping at the IPsec layer may also 408 introduce some traffic pattern, and on constrained devices the 409 application is probably the most appropriated layer to limit the risk 410 of leaking information by traffic shaping. 412 In some cases, devices are dedicated to a single application or a 413 single transport protocol, in which case, the Next Header has a fix 414 value. 416 Specific processing indications have not been standardized yet 417 [I-D.nikander-esp-beet-mode] and is expected to result from an 418 agreement between the peers. As a result, it SHOULD NOT be part of a 419 minimal implementation of ESP. 421 7. ICV 423 The ICV depends on the cryptographic suite used. Currently [RFC8221] 424 only recommends cryptographic suites with an ICV which makes the ICV 425 a mandatory field. 427 As detailed in [RFC8221] authentication or authenticated encryption 428 are RECOMMENDED and as such the ICV field MUST be present with a size 429 different from zero. It length is defined by the security 430 recommendations only. 432 8. Cryptographic Suites 434 The cryptographic suites implemented are an important component of 435 ESP. The recommended algorithms to use are expected to evolve over 436 time and implementers SHOULD follow the recommendations provided by 437 [RFC8221] and updates. 439 This section lists some of the criteria that may be considered. The 440 list is not expected to be exhaustive and may also evolve overtime. 441 As a result, the list is provided as indicative: 443 1. Security: Security is the criteria that should be considered 444 first for the selection of encryption algorithm transform. The 445 security of encryption algorithm transforms is expected to evolve 446 over time, and it is of primary importance to follow up-to-date 447 security guidance and recommendations. The chosen encryption 448 algorithm MUST NOT be known vulnerable or weak (see [RFC8221] for 449 outdated ciphers). ESP can be used to authenticate only or to 450 encrypt the communication. In the latter case, authenticated 451 encryption must always be considered [RFC8221]. 453 2. Resilience to nonce re-use: Some transforms -including AES-GCM - 454 are very sensitive to nonce collision with a given key. While 455 the generation of the nonce may prevent such collision during a 456 session, the mechanisms are unlikely to provide such protection 457 across reboot. This causes an issue for devices that are 458 configured with a key. When the key is likely to be re-used 459 across reboots, it is RECOMMENDED to consider algorithms that are 460 nonce misuse resistant such as, for example, AES-SIV [RFC5297], 461 AES-GCM-SIV [RFC8452] or Deoxys-II [DeoxysII]. Note however that 462 currently none of them has yet been defined for ESP. 464 3. Interoperability: Interoperability considers the encryption 465 algorithm transforms shared with the other nodes. Note that it 466 is not because an encryption algorithm transform is widely 467 deployed that it is secured. As a result, security SHOULD NOT be 468 weakened for interoperability. [RFC8221] and successors consider 469 the life cycle of encryption algorithm transforms sufficiently 470 long to provide interoperability. Constraint devices may have 471 limited interoperability requirements which makes possible to 472 reduces the number of encryption algorithm transforms to 473 implement. 475 4. Power Consumption and Cipher Suite Complexity: Complexity of the 476 encryption algorithm transform or the energy associated to it are 477 especially considered when devices have limited resources or are 478 using some batteries, in which case the battery determines the 479 life of the device. The choice of a cryptographic function may 480 consider re-using specific libraries or to take advantage of 481 hardware acceleration provided by the device. For example, if 482 the device benefits from AES hardware modules and uses AES-CTR, 483 it may prefer AUTH_AES-XCBC for its authentication. In addition, 484 some devices may also embed radio modules with hardware 485 acceleration for AES-CCM, in which case, this mode may be 486 preferred. 488 5. Power Consumption and Bandwidth Consumption: Similarly to the 489 encryption algorithm transform complexity, reducing the payload 490 sent, may significantly reduce the energy consumption of the 491 device. As a result, encryption algorithm transforms with low 492 overhead may be considered. To reduce the overall payload size 493 one may, for example: 495 1. Use of counter-based ciphers without fixed block length (e.g. 496 AES-CTR, or ChaCha20-Poly1305). 498 2. Use of ciphers with capability of using implicit IVs 499 [RFC8750]. 501 3. Use of ciphers recommended for IoT [RFC8221]. 503 4. Avoid Padding by sending payload data which are aligned to 504 the cipher block length - 2 for the ESP trailer. 506 9. IANA Considerations 508 There are no IANA consideration for this document. 510 10. Security Considerations 512 Security considerations are those of [RFC4303]. In addition, this 513 document provided security recommendations and guidance over the 514 implementation choices for each field. 516 The security of a communication provided by ESP is closely related to 517 the security associated to the management of that key. This usually 518 include mechanisms to prevent a nonce to repeat for example. When a 519 node is provisioned with a session key that is used across reboot, 520 the implementer MUST ensure that the mechanisms put in place remain 521 valid across reboot as well. 523 It is RECOMMENDED to use ESP in conjunction of key management 524 protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 525 [RFC7815]. Such mechanisms are responsible to negotiate fresh 526 session keys as well as prevent a session key being use beyond its 527 lifetime. When such mechanisms cannot be implemented and the session 528 key is, for example, provisioned, the nodes MUST ensure that keys are 529 not used beyond their lifetime and that the appropriate use of the 530 key remains across reboots - e.g. conditions on counters and nonces 531 remains valid. 533 When a node generates its key or when random value such as nonces are 534 generated, the random generation MUST follow [RFC4086]. In addition 535 [SP-800-90A-Rev-1] provides appropriated guidance to build random 536 generators based on deterministic random functions. 538 11. Acknowledgment 540 The authors would like to thank Daniel Palomares, Scott Fluhrer, Tero 541 Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson for their 542 valuable comments. In particular Scott Fluhrer suggested to include 543 the rekey index in the SPI as well as the use of transform resilient 544 to nonce misuse. Tero Kivinen provided also multiple clarifications 545 and examples of deployment ESP within constrained devices with their 546 associated optimizations. 548 12. References 550 12.1. Normative References 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 558 "Randomness Requirements for Security", BCP 106, RFC 4086, 559 DOI 10.17487/RFC4086, June 2005, 560 . 562 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 563 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 564 December 2005, . 566 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 567 RFC 4303, DOI 10.17487/RFC4303, December 2005, 568 . 570 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 571 Kivinen, "Internet Key Exchange Protocol Version 2 572 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 573 2014, . 575 [RFC7815] Kivinen, T., "Minimal Internet Key Exchange Version 2 576 (IKEv2) Initiator Implementation", RFC 7815, 577 DOI 10.17487/RFC7815, March 2016, 578 . 580 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 581 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 582 May 2017, . 584 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 585 Kivinen, "Cryptographic Algorithm Implementation 586 Requirements and Usage Guidance for Encapsulating Security 587 Payload (ESP) and Authentication Header (AH)", RFC 8221, 588 DOI 10.17487/RFC8221, October 2017, 589 . 591 [RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit 592 Initialization Vector (IV) for Counter-Based Ciphers in 593 Encapsulating Security Payload (ESP)", RFC 8750, 594 DOI 10.17487/RFC8750, March 2020, 595 . 597 12.2. Informative References 599 [DeoxysII] 600 Jeremy, J., Ivica, I., Thomas, T., and Y. Yannick, "Deoxys 601 v1.41", October 2016, 602 . 604 [I-D.mglt-ipsecme-diet-esp] 605 Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, 606 "ESP Header Compression and Diet-ESP", draft-mglt-ipsecme- 607 diet-esp-07 (work in progress), March 2019. 609 [I-D.mglt-ipsecme-ikev2-diet-esp-extension] 610 Migault, D., Guggemos, T., and D. Schinazi, "Internet Key 611 Exchange version 2 (IKEv2) extension for the ESP Header 612 Compression (EHC) Strategy", draft-mglt-ipsecme-ikev2- 613 diet-esp-extension-01 (work in progress), June 2018. 615 [I-D.nikander-esp-beet-mode] 616 Nikander, P. and J. Melen, "A Bound End-to-End Tunnel 617 (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 618 (work in progress), August 2008. 620 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 621 Authenticated Encryption Using the Advanced Encryption 622 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 623 2008, . 625 [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: 626 Nonce Misuse-Resistant Authenticated Encryption", 627 RFC 8452, DOI 10.17487/RFC8452, April 2019, 628 . 630 [SP-800-90A-Rev-1] 631 Elain, E. and J. Kelsey, "Recommendation for Random Number 632 Generation Using Deterministic Random Bit Generators", 633 . 636 Authors' Addresses 638 Daniel Migault 639 Ericsson 640 8400 boulevard Decarie 641 Montreal, QC H4P 2N2 642 Canada 644 EMail: daniel.migault@ericsson.com 646 Tobias Guggemos 647 LMU Munich 648 MNM-Team 649 Oettingenstr. 67 650 80538 Munich, Bavaria 651 Germany 653 EMail: guggemos@mnm-team.org