idnits 2.17.1 draft-ietf-lwig-minimal-esp-07.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 (28 September 2021) is 935 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 552, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 580, 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: 1 April 2022 LMU Munich 6 28 September 2021 8 Minimal ESP 9 draft-ietf-lwig-minimal-esp-07 11 Abstract 13 This document describes a minimal IP Encapsulation Security Payload 14 (ESP) defined in RFC 4303. Its purpose is to enable implementation 15 of ESP with a minimal set of options to remain compatible with ESP as 16 described in RFC 4303. A minimal version of ESP is not intended to 17 become a replacement of the RFC 4303 ESP. Instead, a minimal 18 implementation is expected to be optimized for constrained 19 environment while remaining interoperable with implementations of RFC 20 4303 ESP. In addition, this document also provides some 21 considerations to implement minimal ESP in a constrained environment 22 which includes limiting the number of flash writes, handling frequent 23 wakeup / sleep states, limiting wakeup time, or reducing the use of 24 random generation. 26 This document does not update or modify RFC 4303, but provides a 27 compact description of how to implement the minimal version of the 28 protocol. RFC 4303 remains the authoritative description. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 1 April 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Security Parameter Index (SPI) (32 bit) . . . . . . . . . . . 3 65 2.1. Considerations over SPI generation . . . . . . . . . . . 4 66 3. Sequence Number(SN) (32 bit) . . . . . . . . . . . . . . . . 5 67 4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Next Header (8 bit) . . . . . . . . . . . . . . . . . . . . . 9 69 6. ICV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 7. Cryptographic Suites . . . . . . . . . . . . . . . . . . . . 10 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 12 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 11.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 ESP [RFC4303] is part of the IPsec protocol suite [RFC4301]. IPsec 82 is used to provide confidentiality, data origin authentication, 83 connectionless integrity, an anti-replay service (a form of partial 84 sequence integrity) and limited traffic flow confidentiality (TFC) 85 padding. 87 Figure 1 describes an ESP Packet. Currently ESP is implemented in 88 the kernel of major multipurpose Operating Systems (OS). The ESP and 89 IPsec suite is usually implemented in a complete way to fit multiple 90 purpose usage of these OS. However, completeness of the IPsec suite 91 as well as multipurpose scope of these OS is often performed at the 92 expense of resources, or performance. As a result, constrained 93 devices are likely to have their own implementation of ESP optimized 94 and adapted to their specificities such as limiting the number of 95 flash writes (for each packet or across wake time), handling frequent 96 wakeup and sleep state, limiting wakeup time, or reducing the use of 97 random generation. With the adoption of IPsec by IoT devices with 98 minimal IKEv2 [RFC7815] and ESP Header Compression (EHC) with 99 [I-D.mglt-ipsecme-diet-esp] or 100 [I-D.mglt-ipsecme-ikev2-diet-esp-extension], it becomes crucial that 101 ESP implementation designed for constrained devices remains inter- 102 operable with the standard ESP implementation to avoid a fragmented 103 usage of ESP. This document describes the minimal properties an ESP 104 implementation needs to meet to remain interoperable with [RFC4303] 105 ESP. In addition, this document also provides a set of options to 106 implement these properties under certain constrained environments. 107 This document does not update or modify RFC 4303, but provides a 108 compact description of how to implement the minimal version of the 109 protocol. RFC 4303 remains the authoritative description. 111 For each field of the ESP packet represented in Figure 1 this 112 document provides recommendations and guidance for minimal 113 implementations. The primary purpose of Minimal ESP is to remain 114 interoperable with other nodes implementing RFC 4303 ESP, while 115 limiting the standard complexity of the implementation. 117 0 1 2 3 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 120 | Security Parameters Index (SPI) | ^Int. 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 122 | Sequence Number | |ered 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 124 | Payload Data* (variable) | | ^ 125 ~ ~ | | 126 | | |Conf. 127 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 128 | | Padding (0-255 bytes) | |ered* 129 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 130 | | Pad Length | Next Header | v v 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 132 | Integrity Check Value-ICV (variable) | 133 ~ ~ 134 | | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 Figure 1: ESP Packet Description 139 2. Security Parameter Index (SPI) (32 bit) 141 According to the [RFC4303], the SPI is a mandatory 32 bits field and 142 is not allowed to be removed. 144 The SPI has a local significance to index the Security Association 145 (SA). From [RFC4301] section 4.1, nodes supporting only unicast 146 communications can index their SA only using the SPI. On the other 147 hand, nodes supporting multicast communications must also use the IP 148 addresses and thus SA lookup needs to be performed using the longest 149 match. 151 For nodes supporting only unicast communications, it is recommended 152 to index SA with the SPI only. The index may be based on the full 32 153 bits of SPI or a subset of these bits. The node may require a 154 combination of the SPI as well as other parameters (like the IP 155 address) to index the SA. 157 Values 0-255 must not be used. As per section 2.1 of [RFC4303], 158 values 1-255 are reserved and 0 is only allowed to be used internally 159 and it must not be sent on the wire. 161 [RFC4303] does not require the SPI to be randomly generated over 32 162 bits. However, this is the recommended way to generate SPIs as it 163 provides some privacy benefits and avoids, for example, correlation 164 between ESP communications. To randomly generate a 32 bit SPI, the 165 node generates a random 32 bit valueand checks it does not fall in 166 the 0-255 range. If the SPI has an acceptable value, it is used to 167 index the inbound session, otherwise the SPI is re-generated until an 168 acceptable value is found. 170 However, some constrained nodes may be less concerned by the privacy 171 properties associated to SPIs randomly generated. Examples of such 172 nodes might include sensors looking to reduce their code complexity, 173 in which case the use of a predictive function to generate the SPI 174 might be preferred over the generation and handling of random values. 175 An example of such predictable function may consider the combination 176 of a fixed value and the memory address of the SAD structure. For 177 every incoming packet, the node will be able to point the SAD 178 structure directly from the SPI value. This avoids having a separate 179 and additional binding between SPI and SAD entries that is involved 180 for every incoming packet. 182 2.1. Considerations over SPI generation 184 SPI that are not randomly generated over 32 bits may lead to privacy 185 and security concerns. As a result, the use of alternative designs 186 requires careful security and privacy reviews. This section provides 187 some considerations upon the adoption of alternative designs. 189 Note that SPI value is used only for inbound traffic, as such the SPI 190 negotiated with IKEv2 [RFC7296] or [RFC7815] by a peer, is the value 191 used by the remote peer when it sends traffic. As SPI is only used 192 for inbound traffic by the peer, this allows each peer to manage the 193 set of SPIs used for its inbound traffic. Similarly, the privacy 194 concerns associated with the generation of nonrandom SPI is also 195 limited to the incoming traffic. 197 When alternate designs are considered, it is likely that the number 198 of possible SPIs will be limited. This limit should both consider 199 the number of inbound SAs - possibly per IP addresses - as well as 200 the ability for the node to rekey. SPI can typically be used to 201 implement a key update with the SPI indicating the key is being used. 202 For example, a SPI might be encoded with the Security Association 203 Database (SAD) entry on a subset of bytes (for example 3 bytes), 204 while the remaining byte indicates the rekey index. 206 The use of a smaller number of SPIs across communications comes with 207 privacy and security concerns. Typically some specific values or 208 subset of SPI values may reveal the models or manufacturer of the 209 node implementing ESP. This may raise some privacy issues as an 210 observer is likely to be able to determine the constrained devices of 211 the network. In some cases, these nodes may host a very limited 212 number of applications - typically a single application - in which 213 case the SPI would provide some information related to the 214 application of the user. In addition, the device or application may 215 be associated with some vulnerabilities, in which case specific SPI 216 values may be used by an attacker to discover vulnerabilities. 218 While the use of randomly generated SPIs may reduce the leakage or 219 privacy of security related information by ESP itself, these 220 information may also be leaked otherwise. As a result, a privacy 221 analysis should consider at least the type of information as well the 222 traffic pattern before determining non random SPI can be used. 223 Typically, temperature sensors, wind sensors, used outdoors do not 224 leak privacy sensitive information and mosty of its traffic is 225 expected to be outbound traffic. When used indoors, a sensor that 226 reports every minute an encrypted status of the door (closed or 227 opened) leaks truly little privacy sensitive information outside the 228 local network. 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. When the use of a 270 clock is considered, one should take care that packets associated 271 with a given SA are not sent with the same time value. Note however 272 that standard receivers are generally configured with incrementing 273 counters and, if not appropriately configured, the use of a 274 significantly larger SN may result in the packet out of the 275 receiver's windows and that packet being discarded. 277 For inbound traffic, it is recommended that any receiver provides 278 anti-replay protection, and the size of the window depends on the 279 ability of the network to deliver packets out of order. As a result, 280 in an environment where out of order packets is not possible the 281 window size can be set to one. However, while recommended, there are 282 no requirements to implement an anti-replay protection mechanism 283 implemented by IPsec. Similarly to the SN the implementation of anti 284 replay protection may require the device to write the received SN for 285 every packet, which may in some cases come with the same drawbacks as 286 those exposed for SN. As a result, some implementations may drop a 287 non required anti replay protection especially when the necessary 288 resource involved overcomes the benefit of the mechanism. These 289 resources need also to balance that absence of anti-replay mechanism, 290 may lead to unnecessary integrity check operations that might be 291 significantly more expensive as well. A typical example might 292 consider an IoT device such as a temperature sensor that is sending a 293 temperature every 60 seconds, and that receives an acknowledgment 294 from the receiver. In such cases, the ability to spoof and replay an 295 acknowledgement is of limited interest and may not justify the 296 implementation of an anti replay mechanism. Receiving peers may also 297 implement their own anti-replay mechanism. Typically, when the 298 sending peer is using SN based on time, anti-replay may be 299 implemented by discarding any packets that present a SN whose value 300 is too much in the past. Note that such mechanisms may consider 301 clock drifting in various ways in addition to acceptable delay 302 induced by the network to avoid the anti replay windows rejecting 303 legitimate packets. When a packet is received at a regular time 304 interval, some variant of time based mechanisms may not even use the 305 value of the SN, but instead only consider the receiving time of the 306 packet. 308 SN can be encoded over 32 bits or 64 bits - known as Extended 309 Sequence Number (ESN). As per [RFC4303], the support of ESN is not 310 mandatory. The determination of the use of ESN is based on the 311 largest possible value a SN can take over a session. When SN is 312 incremented for each packet, the number of packets sent over the 313 lifetime of a session may be considered. However, when the SN is 314 incremented differently - such as when time is used - the maximum 315 value SN needs to be considered instead. Note that the limit of 316 messages being sent is primarily determined by the security 317 associated with the key rather than the SN. The security of all data 318 protected under a given key decreases slightly with each message and 319 a node must ensure the limit is not reached - even though the SN 320 would permit it. Estimation of the maximum number of packets to be 321 sent by a node is always challenging and as such should be considered 322 cautiously as nodes could be online for much more time than expected. 323 Even for constrained devices, it is recommended to implement some 324 rekey mechanisms (see Section 9). 326 4. Padding 328 The purpose of padding is to respect the 32 bit alignment of ESP or 329 block size expected by an encryption transform - such as AES-CBC for 330 example. ESP must have at least one padding byte Pad Length that 331 indicates the padding length. ESP padding bytes are generated by a 332 succession of unsigned bytes starting with 1, 2, 3 with the last byte 333 set to Pad Length, where Pad Length designates the length of the 334 padding bytes. 336 Checking the padding structure is not mandatory, so the constrained 337 device may not proceed to such checks, however, in order to 338 interoperate with existing ESP implementations, it must build the 339 padding bytes as recommended by ESP. 341 In some situation the padding bytes may take a fixed value. This 342 would typically be the case when the Data Payload is of fix size. 344 ESP [RFC4303] also provides Traffic Flow Confidentiality (TFC) as a 345 way to perform padding to hide traffic characteristics, which differs 346 from respecting a 32 bit alignment. TFC is not mandatory and must be 347 negotiated with the SA management protocol. TFC has not yet being 348 widely adopted for standard ESP traffic. One possible reason is that 349 it requires to shape the traffic according to one traffic pattern 350 that needs to be maintained. This is likely to require extra 351 processing as well as providing a "well recognized" traffic shape 352 which could end up being counterproductive. As such, it is NOT 353 recommended that minimal ESP implementation supports TFC. 355 As a result, TFC cannot be enabled with minimal ESP, and 356 communication protection that were relying on TFC will be more 357 sensitive to traffic shaping. This could expose the application as 358 well as the devices used to a passive monitoring attacker. Such 359 information could be used by the attacker in case a vulnerability is 360 disclosed on the specific device. In addition, some application use 361 - such as health applications - may also reveal important privacy 362 oriented information. 364 Some constrained nodes that have limited battery lifetime may also 365 prefer avoiding sending extra padding bytes. However, the same nodes 366 may also be very specific to an application and device. As a result, 367 they are also likely to be the main target for traffic shaping. In 368 most cases, the payload carried by these nodes is quite small, and 369 the standard padding mechanism may also be used as an alternative to 370 TFC, with a sufficient tradeoff between the require energy to send 371 additional payload and the exposure to traffic shaping attacks. In 372 addition, the information leaked by the traffic shaping may also be 373 addressed by the application level. For example, it is preferred to 374 have a sensor sending some information at regular time interval, 375 rather than when a specific event is happening. Typically, a sensor 376 monitoring the temperature, or a door is expected to send regularly 377 the information - i.e. the temperature of the room or whether the 378 door is closed or open) instead of only sending the information when 379 the temperature has raised or when the door is being opened. 381 5. Next Header (8 bit) 383 According to [RFC4303], the Next Header is a mandatory 8 bits field 384 in the packet. Next header specifies the data contained in the 385 payload as well as dummy packet, i.e. packets with the Next Header 386 with a value 59 meaning "no next header". In addition, the Next 387 Header may also carry an indication on how to process the packet 388 [I-D.nikander-esp-beet-mode]. 390 The ability to generate and receive dummy packets is required by 391 [RFC4303]. For interoperability, a minimal ESP implementation must 392 discard dummy packets without indicating an error. Note that such 393 recommendation only applies for nodes receiving packets, and that 394 nodes designed to only send data may not implement this capability. 396 As the generation of dummy packets is subject to local management and 397 based on a per-SA basis, a minimal ESP implementation may not 398 generate such dummy packet. More especially, in constrained 399 environment sending dummy packets may have too much impact on the 400 device lifetime, and so may be avoided. On the other hand, 401 constrained nodes may be dedicated to specific applications, in which 402 case, traffic pattern may expose the application or the type of node. 403 For these nodes, not sending dummy packet may have some privacy 404 implication that needs to be measured. However, for the same reasons 405 exposed in Section 4 traffic shaping at the IPsec layer may also 406 introduce some traffic pattern, and on constrained devices the 407 application is probably the most appropriated layer to limit the risk 408 of leaking information by traffic shaping. 410 In some cases, devices are dedicated to a single application or a 411 single transport protocol, in which case, the Next Header has a fixed 412 value. 414 Specific processing indications have not been standardized yet 415 [I-D.nikander-esp-beet-mode] and is expected to result from an 416 agreement between the peers. As a result, it should not be part of a 417 minimal implementation of ESP. 419 6. ICV 421 The ICV depends on the cryptographic suite used. Currently [RFC8221] 422 only recommends cryptographic suites with an ICV which makes the ICV 423 a mandatory field. 425 As detailed in [RFC8221] authentication or authenticated encryption 426 are recommended and as such the ICV field must be present with a size 427 different from zero. It length is defined by the security 428 recommendations only. 430 7. Cryptographic Suites 432 The cryptographic suites implemented are an important component of 433 ESP. The recommended algorithms to use are expected to evolve over 434 time and implementers should follow the recommendations provided by 435 [RFC8221] and updates. 437 This section lists some of the criteria that may be considered. The 438 list is not expected to be exhaustive and may also evolve overtime. 439 As a result, the list is provided as informational: 441 1. Security: Security is the criteria that should be considered 442 first for the selection of encryption algorithm transform. The 443 security of encryption algorithm transforms is expected to evolve 444 over time, and it is of primary importance to follow up-to-date 445 security guidance and recommendations. The chosen encryption 446 algorithm must not be known vulnerable or weak (see [RFC8221] for 447 outdated ciphers). ESP can be used to authenticate only or to 448 encrypt the communication. In the latter case, authenticated 449 encryption must always be considered [RFC8221]. 451 2. Resilience to nonce re-use: Some transforms -including AES-GCM - 452 are very sensitive to nonce collision with a given key. While 453 the generation of the nonce may prevent such collision during a 454 session, the mechanisms are unlikely to provide such protection 455 across reboot. This causes an issue for devices that are 456 configured with a key. When the key is likely to be re-used 457 across reboots, it is recommended to consider algorithms that are 458 nonce misuse resistant such as, for example, AES-SIV [RFC5297], 459 AES-GCM-SIV [RFC8452] or Deoxys-II [DeoxysII]. Note however that 460 currently none of them has yet been defined for ESP. 462 3. Interoperability: Interoperability considers the encryption 463 algorithm transforms shared with the other nodes. Note that it 464 is not because an encryption algorithm transform is widely 465 deployed that it is secured. As a result, security should not be 466 weakened for interoperability. [RFC8221] and successors consider 467 the life cycle of encryption algorithm transforms sufficiently 468 long to provide interoperability. Constrained devices may have 469 limited interoperability requirements which makes possible to 470 reduces the number of encryption algorithm transforms to 471 implement. 473 4. Power Consumption and Cipher Suite Complexity: Complexity of the 474 encryption algorithm transform or the energy associated with it 475 are especially considered when devices have limited resources or 476 are using some batteries, in which case the battery determines 477 the life of the device. The choice of a cryptographic function 478 may consider re-using specific libraries or to take advantage of 479 hardware acceleration provided by the device. For example, if 480 the device benefits from AES hardware modules and uses AES-CTR, 481 it may prefer AUTH_AES-XCBC for its authentication. In addition, 482 some devices may also embed radio modules with hardware 483 acceleration for AES-CCM, in which case, this mode may be 484 preferred. 486 5. Power Consumption and Bandwidth Consumption: Similarly to the 487 encryption algorithm transform complexity, reducing the payload 488 sent, may significantly reduce the energy consumption of the 489 device. As a result, encryption algorithm transforms with low 490 overhead may be considered. To reduce the overall payload size 491 one may, for example: 493 1. Use of counter-based ciphers without fixed block length (e.g. 494 AES-CTR, or ChaCha20-Poly1305). 496 2. Use of ciphers with capability of using implicit IVs 497 [RFC8750]. 499 3. Use of ciphers recommended for IoT [RFC8221]. 501 4. Avoid Padding by sending payload data which are aligned to 502 the cipher block length - 2 for the ESP trailer. 504 8. IANA Considerations 506 There are no IANA consideration for this document. 508 9. Security Considerations 510 Security considerations are those of [RFC4303]. In addition, this 511 document provided security recommendations and guidance over the 512 implementation choices for each field. 514 The security of a communication provided by ESP is closely related to 515 the security associated with the management of that key. This 516 usually includes mechanisms to prevent a nonce from repeating, for 517 example. When a node is provisioned with a session key that is used 518 across reboot, the implementer must ensure that the mechanisms put in 519 place remain valid across reboot as well. 521 It is recommended to use ESP in conjunction with key management 522 protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 523 [RFC7815]. Such mechanisms are responsible for negotiating fresh 524 session keys as well as prevent a session key being use beyond its 525 lifetime. When such mechanisms cannot be implemented and the session 526 key is, for example, provisioned, the nodes must ensure that keys are 527 not used beyond their lifetime and that the appropriate use of the 528 key remains across reboots - e.g. conditions on counters and nonces 529 remains valid. 531 When a node generates its key or when random value such as nonces are 532 generated, the random generation must follow [RFC4086]. In addition 533 [SP-800-90A-Rev-1] provides appropriated guidance to build random 534 generators based on deterministic random functions. 536 10. Acknowledgment 538 The authors would like to thank Daniel Palomares, Scott Fluhrer, Tero 539 Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson, Thomas Peyrin 540 and Eric Thormarker for their valuable comments. In particular Scott 541 Fluhrer suggested to include the rekey index in the SPI. Tero 542 Kivinen provided also multiple clarifications and examples of 543 deployment ESP within constrained devices with their associated 544 optimizations. Thomas Peyrin Eric Thormarker and Scott Fluhrer 545 suggested and clarified the use of transform resilient to nonce 546 misuse. 548 11. References 550 11.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 11.2. Informative References 599 [DeoxysII] Jeremy, J. J., Ivica, I. N., Thomas, T. P., and Y. S. 600 Yannick, "Deoxys v1.41", October 2016, 601 . 603 [I-D.mglt-ipsecme-diet-esp] 604 Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, 605 "ESP Header Compression and Diet-ESP", Work in Progress, 606 Internet-Draft, draft-mglt-ipsecme-diet-esp-07, 11 March 607 2019, . 610 [I-D.mglt-ipsecme-ikev2-diet-esp-extension] 611 Migault, D., Guggemos, T., and D. Schinazi, "Internet Key 612 Exchange version 2 (IKEv2) extension for the ESP Header 613 Compression (EHC) Strategy", Work in Progress, Internet- 614 Draft, draft-mglt-ipsecme-ikev2-diet-esp-extension-01, 26 615 June 2018, . 618 [I-D.nikander-esp-beet-mode] 619 Nikander, P. and J. Melen, "A Bound End-to-End Tunnel 620 (BEET) mode for ESP", Work in Progress, Internet-Draft, 621 draft-nikander-esp-beet-mode-09, 5 August 2008, 622 . 625 [RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) 626 Authenticated Encryption Using the Advanced Encryption 627 Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 628 2008, . 630 [RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: 631 Nonce Misuse-Resistant Authenticated Encryption", 632 RFC 8452, DOI 10.17487/RFC8452, April 2019, 633 . 635 [SP-800-90A-Rev-1] 636 Elain, E. B. and J. K. Kelsey, "Recommendation for Random 637 Number Generation Using Deterministic Random Bit 638 Generators", . 641 Authors' Addresses 643 Daniel Migault 644 Ericsson 645 8400 boulevard Decarie 646 Montreal, QC H4P 2N2 647 Canada 649 Email: daniel.migault@ericsson.com 651 Tobias Guggemos 652 LMU Munich 653 MNM-Team 654 Oettingenstr. 67 655 80538 Munich 656 Germany 658 Email: guggemos@mnm-team.org