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