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