RFC 9333

Minimal IP Encapsulating Security Payload (ESP)

📅 published January 2023, from ietf

Minimal IP Encapsulating Security Payload (ESP) 🦋

Okay bestie, here's the title block first 💅

RFC: 9333 🎀
Authors: D. Migault (Ericsson) and T. Guggemos (LMU Munich) 👑
Category: Informational, so it's published for info and it's not a Standards Track spec 🧚
Date: January 2023 🌸
ISSN: 2070-1721
Obsoletes / Updates: It doesn't obsolete anything, and it doesn't update anything either. It says outright that it does not update or modify RFC 4303 🙈

Abstract ✨

Okay so this doc describes the minimal stuff an IP Encapsulating Security Payload (ESP) implementation needs to have so it can still talk to standard ESP as defined in RFC 4303 🔥 A minimal version is not meant to replace ESP from RFC 4303, obviously. It's just meant to be trimmed down for constrained devices while staying interoperable with regular ESP implementations 💜 The doc also gives tips for doing minimal ESP on constrained hardware, like limiting flash writes, handling frequent wakeup and sleep states, limiting wakeup time, and using less random generation 🦋

It also says it doesn't update or modify RFC 4303. It's a compact guide to implementing a minimal version of that protocol, and RFC 4303 is still the authoritative source 💖

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes 🌈

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It's had public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨ Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets 🧐

For info about the current status, errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9333 🎀

Copyright Notice 💅

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License 🫶

Table of Contents 🧚

1.  Introduction
2.  Requirements Notation
3.  Security Parameters Index (SPI)
  3.1.  Considerations for SPI Generation
4.  Sequence Number (SN)
5.  Padding
6.  Next Header and "Dummy" Packets
7.  ICV
8.  Cryptographic Suites
9.  IANA Considerations
10. Security Considerations
11. Privacy Considerations
12. References
  12.1.  Normative References
  12.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🌸

Okay so ESP [RFC4303] is part of the IPsec protocol suite [RFC4301] 💖 IPsec gives you confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited Traffic Flow Confidentiality (TFC) padding. Iconic 🔥

Figure 1 shows an ESP packet. Right now ESP is built into the kernel of most major multipurpose Operating Systems (OSes). It's usually implemented with every feature turned on so it fits all those general-purpose uses, which costs resources, and code size isn't really considered at all 😭 Constrained devices are likely to write their own ESP implementation that's tuned for their specific job. Think limiting flash writes (per packet or across wake time), handling frequent wakeup and sleep states, limiting wakeup time, and reducing random generation ✨

IoT devices are adopting IPsec with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC) [EHC-DIET-ESP] [EHC-IKEv2], and these ESP implementations MUST remain interoperable with standard ESP implementations 🦋 This doc describes the minimal properties an ESP implementation needs in order to stay interoperable with ESP [RFC4303]. It also gives implementers advice for doing ESP in constrained environments. And again, it does not update or modify [RFC4303] 🙈

For each field of the ESP packet in Figure 1, this doc gives recommendations and guidance for minimal implementations. The main goal of minimal ESP is to keep talking to other ESP [RFC4303] nodes while cutting down on the usual complexity of the implementation 💅

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|               Security Parameters Index (SPI)                 | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|                      Sequence Number                          | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|                    Payload Data* (variable)                   | |   ^
~                                                               ~ |   |
|                                                               | |Conf.
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|               |     Padding (0-255 bytes)                     | |ered*
+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
|                               |  Pad Length   | Next Header   | v   v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|         Integrity Check Value (ICV) (variable)                |
~                                                               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: ESP Packet Description 🎀

2. Requirements Notation 📜

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥

3. Security Parameters Index (SPI) 🔐

[RFC4303] defines the SPI as a mandatory 32-bit field 💖

The SPI has local significance and is used to index the Security Association (SA). As described in Section 4.1 of [RFC4301], nodes that only support unicast communications can index their SA using just the SPI. Nodes that support multicast also need IP addresses, so SA lookup has to be done with the longest match 🧚

For nodes that only support unicast, indexing the SA using only the SPI is RECOMMENDED. The index can be based on all 32 bits of the SPI or on a subset of them. A node might need a combo of the SPI and other parameters (like the IP address) to index the SA 💅

Values 0-255 MUST NOT be used. As per Section 2.1 of [RFC4303], values 1-255 are reserved, and 0 is only allowed for internal use and MUST NOT be sent over the wire ✨

[RFC4303] doesn't require the 32-bit SPI to be randomly generated, although random generation is RECOMMENDED. It's the RECOMMENDED way to make SPIs because it gives some privacy and security benefits and stops ESP communications from being correlated 🦋 To get a usable random 32-bit SPI, the node generates a random 32-bit value and checks that it doesn't fall in the 0-255 range. If the SPI is acceptable, it's used to index the inbound session. If not, the value gets thrown out and the process repeats until a valid one shows up 🌸

Some constrained devices care less about the privacy of randomly generated SPIs. Sensors trying to cut down code complexity are one example. For these devices, a predictable function to generate the SPI might be preferred over generating and handling random values 🙈 One way to implement that predictable function is to combine a fixed value with the memory address of the Security Association Database (SAD) structure. For every incoming packet, the node can point straight to the SAD structure from the SPI value. That skips a separate binding and lookup step from the SPI to its SAD entry on every incoming packet, which is so efficient 😭🔥

3.1. Considerations for SPI Generation ✨

Okay bestie, SPIs that aren't randomly generated over 32 bits can come with privacy and security concerns 😬 So using alternative designs needs careful security and privacy reviews 🔍 This section gives some considerations for adopting them 💅

The SPI only gets looked up for inbound traffic 📥 The SPI negotiated with IKEv2 [RFC7296] or minimal IKEv2 [RFC7815] by a peer is the value the remote peer uses when it sends traffic to you 💌 The main perk of a rekeying mechanism is that it lets you do a rekey, which means swapping an old SA for a new SA, with both indexed by distinct SPIs 🔄 The SPI is only used for inbound traffic by the peer, so each peer gets to manage its own set of SPIs for its inbound traffic 🎀 The number of SPIs you need depends on how many inbound SAs you have and whether you can rekey them 🧮 Usually, rekeying an SA means creating a new SA (with a dedicated SPI) before the old one is deleted 🗑️ That creates an extra SA and means you need to support one more SPI 🫶 Similarly, the privacy concerns around generating non-random SPIs are also limited to incoming traffic 🦋

Alternatively, some constrained devices won't implement IKEv2 or minimal IKEv2, so they can't manage a rollover between two distinct SAs 😭 On top of that, some of these devices probably have a limited number of SAs. For example, they're likely to be indexed over only 3 bytes 🧸 One possible way to enable a rekeying mechanism with these devices is to use the SPI where, for example, the first 3 bytes designate the SA while the remaining byte indicates a rekey index 🧩 SPI numbers can be used to track the inbound SAs while rekeying is happening 👀 When rekeying an SPI, the new SPI could use the SPI bytes to indicate the rekeying index 🔢

The use of a small, limited set of SPI numbers across communications comes with privacy and security concerns 🙈 Some specific values or subsets of SPI values could reveal the model or manufacturer of the node implementing ESP, or reveal a state like "not yet rekeyed" or "rekeyed 10 times" 🕵️ If a constrained host uses a very limited number of applications (eventually just one), the SPI itself could indicate what kind of traffic is being transmitted, such as the kind of application typically running 📡 This could also be correlated with encrypted data size to leak even more information to an observer on the network 💀 Plus, using specific hardcoded SPI numbers could reveal a manufacturer or device version 🏭 If updated devices use different SPI numbers, an attacker could locate vulnerable devices by their use of specific SPI numbers 🚨

A privacy analysis should consider at least the type of information as well as the traffic pattern before deciding whether non-random SPIs are safe to use 🧐 Typically, temperature and wind sensors used outdoors don't leak privacy-sensitive information, and most of their traffic is expected to be outbound 🌬️ When used indoors, a sensor that reports an encrypted status of a door (closed or opened) every minute might not leak sensitive information outside the local network 🚪 In these examples, the privacy aspect of the information itself might be limited 🌸 Being able to determine the version of the sensor, and potentially take control of it, may also have some limited security consequences 🔐 Of course, this depends on the context in which these sensors are being used 🫧 If the risks associated with privacy and security are acceptable, a non-randomized SPI can be used 💖

4. Sequence Number (SN) 🔢

The Sequence Number (SN) in [RFC4303] is a mandatory 32-bit field in the packet 📦

The SN is set by the sender so the receiver can implement anti-replay protection 🛡️ The SN is derived from any strictly increasing function that guarantees the following: if packet B is sent after packet A, then the SN of packet B is higher than the SN of packet A 📈

Some constrained devices may establish communication with specific devices where it is known whether or not the peer implements anti-replay protection 🤝 As per [RFC4303], the sender MUST still implement a strictly increasing function to generate the SN 🙌

It is RECOMMENDED that multipurpose ESP implementations increment a counter for each packet sent 🔁 However, a constrained device may skip maintaining this context and use another source that is known to always increase ✨ Typically, constrained devices use 802.15.4 Time Slotted Channel Hopping (TSCH) 📡 This communication is heavily dependent on time ⏰ A constrained device can take advantage of this clock mechanism to generate the SN 🫧 A lot of IoT devices spend most of their time in a sleep state and only wake up to perform a specific operation before going back to sleep 😴 These devices have separate hardware that lets them wake up after a certain timeout, and they typically also have timers that start running when the device is booted up, so they might have a concept of time with certain granularity ⏳ This requires devices to store any information in stable storage that can be restored across sleeps (e.g., flash memory) 💾 Storing information associated with the SA (such as the SN) requires some read and write operations on stable storage after each packet is sent, as opposed to an SPI number or cryptographic keys, which are only written to stable storage when the SA is created 📝 Write operations wear out the flash storage 🥀 Write operations also slow the system down significantly, since writing to flash is much slower than reading from it 🐢 While these devices have internal clocks or timers that might not be very accurate, they're good enough to guarantee that each time the device wakes up from sleep, the time is greater than what it was before it went to sleep ⏰💜 Using time for the SN would guarantee a strictly increasing function and avoid storing any additional values or context related to the SN on flash 🧠 In addition to the time value, a RAM-based counter can be used to make sure the serial numbers keep increasing and stay unique if the device sends multiple packets over an SA within one wakeup period 🧮

For inbound traffic, it is RECOMMENDED that receivers implement anti-replay protection 🛡️ The size of the window should depend on the network characteristics needed to deliver packets out of order 🌀 In an environment where out-of-order packets aren't possible, the window size can be set to one 1️⃣ An ESP implementation may choose to not implement anti-replay protection 🙃 An implementation of anti-replay protection may require the device to write the received SN for every packet to stable storage 💾 This has the same issues as discussed earlier with the SN 🔁 Some constrained device implementations may choose to not implement the optional anti-replay protection 🫠 A typical example is an IoT device, such as a temperature sensor that sends a temperature measurement every 60 seconds and receives an acknowledgment from the receiver 🌡️ In a case like this, the ability to spoof and replay an acknowledgment is of limited interest and might not justify implementing an anti-replay mechanism 🤷‍♀️ Receiving peers may also use an ESP anti-replay mechanism adapted to a specific application 🎯 Typically, when the sending peer uses an SN based on time, anti-replay may be implemented by discarding any packets whose SN is too far in the past 🕰️ Such mechanisms may consider clock drifting in various ways, plus acceptable network delay, so the anti-replay windows don't reject legitimate packets 🧭 Receiving peers could accept any SN as long as it is higher than the previously received SN 📊 Another mechanism could be used where only the time received on the device is used to decide whether a packet is valid, without looking at the SN at all ⌚

The SN can be represented as a 32-bit number or as a 64-bit number, known as an "Extended Sequence Number (ESN)" 🔢💫 As per [RFC4303], support for ESN is not mandatory, and its use is negotiated via IKEv2 [RFC7296] 🤓 An ESN is used for high-speed links to ensure there can be more than 2^32 packets before the SA needs to be rekeyed to keep the SN from rolling over 🚀 This assumes the SN is incremented by 1 for each packet ➕ When the SN is incremented differently, such as when time is used, rekeying needs to happen based on how the SN is incremented so the SN doesn't roll over 🔄 The security of all data protected under a given key decreases slightly with each message, and a node must ensure the limit is not reached, even though the SN would permit it 🚧 Estimating the maximum number of packets a node will send isn't always predictable, so large margins should be used, especially since nodes could stay online for much longer than expected 🕯️ Even for constrained devices, it is RECOMMENDED to implement some rekeying mechanisms (see Section 10) 🔐💅

5. Padding 🎀

Padding is required to keep the 32-bit alignment of ESP 📏 It's also required for some encryption transforms that need a specific block size of input, such as ENCR_AES_CBC 🧱 ESP specifies padding in the Pad Length byte, followed by up to 255 bytes of padding 🫧

Checking the padding structure is not mandatory, so constrained devices may omit these checks on received ESP packets 🙌 For outgoing ESP packets, padding must be applied as required by ESP 📤

In some situations, the padding bytes may take a fixed value 🎯 This would typically be the case when the Payload Data is of fixed size 📦

ESP [RFC4303] additionally provides Traffic Flow Confidentiality (TFC) as a way to perform padding to hide traffic characteristics 🕶️ TFC is not mandatory and is negotiated with the SA management protocol, such as IKEv2 🤝 TFC has been widely implemented, but it isn't widely deployed for ESP traffic 🤔 It is NOT RECOMMENDED to implement TFC for minimal ESP 🚫

As a consequence, communication protection that relies on TFC would be more sensitive to traffic patterns without TFC 👀 This can leak application information, as well as the manufacturer or model of the device, to a passive monitoring attacker 🕵️‍♀️ Such information can be used, for example, by an attacker if a vulnerability is known for that specific device or application 💀 Some applications (such as health applications) could also leak important privacy-oriented information 🥺

Constrained devices with a limited battery lifetime may prefer to avoid sending extra padding bytes 🔋 In most cases, the payload carried by these devices is quite small, so the standard padding mechanism can be used as an alternative to TFC 🌸 Alternatively, any information leak based on the size (or presence) of the packet can also be addressed at the application level before the packet is encrypted with ESP 🧁 If application packets vary between 1 and 30 bytes, the application could always send 32-byte responses so all traffic sent is of identical length 📏💖 To keep from leaking that a sensor changed state, such as "temperature changed" or "door opened", an application could send this information at regular time intervals, rather than when a specific event happens, even if the sensor state didn't change ⏱️✨

6. Next Header and "Dummy" Packets 🎀

okay so ESP [RFC4303] says the Next Header is a mandatory 8-bit field in the packet 💅 and it's only visible after decryption. It tells you what kind of data is in the payload ✨ and it can also carry a hint about how to process the packet [BEET-ESP]. The Next Header can point at a "dummy" packet, which is a packet with the Next Header set to 59, meaning "no next header" 🙈 The data after "no next header" is unstructured "dummy" data. (This document uses the word "dummy" to match [RFC4303], so don't be confused by it 💜)

The ability to generate, receive, and ignore "dummy" packets is required by [RFC4303]. An implementation can skip generating and sending "dummy" packets entirely 🦋 But for interoperability, a minimal ESP implementation MUST be able to process and discard "dummy" packets without indicating an error. no excuses bestie 🫶

In constrained environments, sending "dummy" packets may hurt the device lifetime too much, so in that case "dummy" packets should not be generated and sent 🔋 On the other hand, constrained devices running specific applications that would leak too much information without "dummy" packets may implement this, or even do something similar at the application layer ✨ Also, just like padding and TFC can hide some traffic characteristics (see Section 5), "dummy" packets can accidentally reveal patterns that identify the application 👀 For example, say an app sends 1-byte data when something changes. That creates a packet that basically says "a change happened" 😬 So "dummy" packets can be used to stop that leak by sending a 1-byte packet every second when nothing has changed. But after an upgrade, the data becomes 2 bytes. At that point the "dummy" packets don't hide anything, and seeing 1 byte regularly versus 2 bytes makes it even easier to figure out the application version 💀 This is generally why "dummy" packets make more sense on high-speed links 🚄

In some cases, devices are dedicated to a single application or a single transport protocol. Then the Next Header has a fixed value 🧚

Specific processing indications haven't been standardized yet [BEET-ESP] and are expected to come from an agreement between the peers 🤝 So they SHOULD NOT be part of a minimal implementation of ESP. not the vibe for minimal ESP 🚫

7. ICV 🔐

The ICV depends on the cryptographic suite being used. As detailed in [RFC8221], authentication or authenticated encryption is RECOMMENDED 💖 so the ICV field must be present with a size different from zero. Its length is defined only by the security recommendations 🌸

8. Cryptographic Suites 🧁

The recommended algorithms are expected to evolve over time, so implementers SHOULD follow the recommendations in [RFC8221] and its updates 📈

This section lists some of the criteria that may be considered when picking an appropriate cryptographic suite. The list isn't expected to be exhaustive, and it may also change over time 🌈

Security: Security is the first thing you should look at when choosing encryption algorithm transforms 🔥 Security is expected to evolve over time, so it's super important to follow up-to-date security guidance and recommendations. The chosen encryption algorithm MUST NOT be vulnerable or weak (see [RFC8221] for outdated ciphers) 🙅‍♀️ ESP can be used to authenticate only (ENCR_NULL) or to encrypt the communication. When it encrypts, Authenticated Encryption with Associated Data (AEAD) is RECOMMENDED [RFC8221] 🫶
Resilience to Nonce Reuse: Some transforms, including AES-GCM, are vulnerable to nonce collision with a given key 😭 Generating the nonce can prevent collisions during a session, but those mechanisms are unlikely to protect across sleep states or reboots. This is an issue for devices configured with static keys (called "manual keying"), so manual keying should not be used with these encryption algorithms 🙈 When the key is likely to be reused across reboots, algorithms that resist nonce misuse are RECOMMENDED. Examples are AES-SIV [RFC5297], AES-GCM-SIV [RFC8452], and Deoxys-II [DeoxysII] 💜 Just note that none of these are currently defined for use with ESP 🥲
Interoperability: Constrained devices usually implement only one or very few encryption algorithm transforms 🧸 [RFC8221] considers the life cycle of encryption algorithm transforms and device manufacturing when it makes its recommendations for mandatory-to-implement (MTI) algorithms 🗓️
Power Consumption and Cipher Suite Complexity: The complexity of the encryption algorithm transform and its energy cost matter a LOT for devices with limited resources or battery power 🔋 Battery life might decide how long the whole device lasts. When choosing a cryptographic function, think about reusing specific libraries or taking advantage of hardware acceleration the device already has ⚡ For example, if the device benefits from AES hardware modules and uses ENCR_AES_CTR, it may prefer AUTH_AES-XCBC for its authentication 🎯 Also, some devices have radio modules with hardware acceleration for AES-CCM, in which case this transform may be preferred 📡
Power Consumption and Bandwidth Consumption: Sending less payload can seriously cut the device's energy use 🌿 So encryption algorithm transforms with low overhead are strongly preferred 💅 To shrink the overall payload size, you could, for example:
- Use counter-based ciphers without a fixed block length (e.g., AES-CTR or ChaCha20-Poly1305) 🍓
- Use ciphers capable of using implicit Initialization Vectors (IVs) [RFC8750] 🦋
- Use ciphers recommended for IoT [RFC8221] 🌸
- Avoid padding by sending payload data that's aligned to the cipher block length -- 2 bytes for the ESP trailer ✨

9. IANA Considerations 📋

This document has no IANA actions. nothing to see here, IANA 😌

10. Security Considerations 🛡️

This part is SERIOUS, bestie. Read it carefully 🚨

The security considerations in [RFC4303] apply to this document as well 💜 On top of that, this document gives security recommendations and guidance for the implementation choices for each ESP field.

The security ESP provides is closely tied to how the key is managed 🔑 This usually includes mechanisms that stop a nonce from repeating, for example. When a node is provisioned with a session key that's used across reboots, the implementer MUST ensure that those mechanisms stay valid across reboots too 😱

It is RECOMMENDED to use ESP together with key management protocols such as IKEv2 [RFC7296] or minimal IKEv2 [RFC7815] 🤝 These are responsible for negotiating fresh session keys and for making sure a session key isn't used beyond its lifetime ⏳ When such mechanisms cannot be implemented, such as when the session key is provisioned, the device MUST ensure that keys are not used beyond their lifetime. It also MUST ensure the key stays in compliance with all security requirements across reboots (e.g., conditions on counters and nonces remain valid) 🚫

When a device generates its own key, or when random values such as nonces are generated, the random generation MUST follow [RFC4086] 🎲 On top of that, [SP-800-90A-Rev-1] gives guidance on building random generators based on deterministic random functions 🧠

11. Privacy Considerations 🕵️‍♀️

Preventing the leak of privacy-sensitive information is a hard problem 😩 Usually you end up balancing the information that could leak against the cost of the countermeasures 💸 This problem isn't inherent to the minimal ESP described in this document. It also applies to ESP in general 🌍

This document targets minimal implementations of ESP, so it describes a minimalistic way to implement ESP 🪶 In some cases, this may reveal privacy-sensitive information. This document describes those privacy implications so the implementer can make the right decisions for their environment and deployment 💅

The main privacy risk is being able to identify an application or a device by analyzing the traffic. This is called "traffic shaping" 👀 As discussed in Section 3, using non-randomly generated SPIs in a very specific context might make it easier to determine the device or the application in some cases 😬 Similarly, padding gives limited ability to obfuscate traffic compared to what TFC provides. Those privacy consequences are detailed in Section 5 🫣

12. References 📚

12.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
           "Randomness Requirements for Security", BCP 106, RFC 4086,
           DOI 10.17487/RFC4086, June 2005,
           <https://www.rfc-editor.org/info/rfc4086>.

[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
           Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
           December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
           RFC 4303, DOI 10.17487/RFC4303, December 2005,
           <https://www.rfc-editor.org/info/rfc4303>.

[RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
           Kivinen, "Internet Key Exchange Protocol Version 2
           (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
           2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC7815]  Kivinen, T., "Minimal Internet Key Exchange Version 2
           (IKEv2) Initiator Implementation", RFC 7815,
           DOI 10.17487/RFC7815, March 2016,
           <https://www.rfc-editor.org/info/rfc7815>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8221]  Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
           Kivinen, "Cryptographic Algorithm Implementation
           Requirements and Usage Guidance for Encapsulating Security
           Payload (ESP) and Authentication Header (AH)", RFC 8221,
           DOI 10.17487/RFC8221, October 2017,
           <https://www.rfc-editor.org/info/rfc8221>.

[RFC8750]  Migault, D., Guggemos, T., and Y. Nir, "Implicit
           Initialization Vector (IV) for Counter-Based Ciphers in
           Encapsulating Security Payload (ESP)", RFC 8750,
           DOI 10.17487/RFC8750, March 2020,
           <https://www.rfc-editor.org/info/rfc8750>.

12.2. Informative References

Okay, these are the extra reads for when you want to go deeper 📚✨ Each one is listed with its tag, its full details, and its link.

[BEET-ESP] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel (BEET) mode for ESP", Work in Progress, Internet-Draft, draft-nikander-esp-beet-mode-09, 5 August 2008, https://datatracker.ietf.org/doc/html/draft-nikander-esp-beet-mode-09.
[DeoxysII] Jean, J., Nikolić, I., Peyrin, T., and Y. Seurin, "Deoxys v1.41", October 2016, https://competitions.cr.yp.to/round3/deoxysv141.pdf.
[EHC-DIET-ESP] Migault, D., Guggemos, T., Bormann, C., and D. Schinazi, "ESP Header Compression and Diet-ESP", Work in Progress, Internet-Draft, draft-mglt-ipsecme-diet-esp-08, 13 May 2022, https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-diet-esp-08.
[EHC-IKEv2] Migault, D., Guggemos, T., and D. Schinazi, "Internet Key Exchange version 2 (IKEv2) extension for the ESP Header Compression (EHC) Strategy", Work in Progress, Internet-Draft, draft-mglt-ipsecme-ikev2-diet-esp-extension-02, 13 May 2022, https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02.
[RFC5297] Harkins, D., "Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES)", RFC 5297, DOI 10.17487/RFC5297, October 2008, https://www.rfc-editor.org/info/rfc5297.
[RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", RFC 8452, DOI 10.17487/RFC8452, April 2019, https://www.rfc-editor.org/info/rfc8452.
[SP-800-90A-Rev-1] Barker, E. and J. Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", NIST SP 800-90A Rev 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015, https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final.

Acknowledgments 🫶

Huge shoutout to everyone who helped make this happen 🌈 The authors want to thank Daniel Palomares, Scott Fluhrer, Tero Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson, Thomas Peyrin, Eric Thormarker, Nancy Cam-Winget, and Bob Briscoe for their valuable comments 💜

Scott Fluhrer gets extra love for suggesting that the rekey index go into the SPI 👑 Tero Kivinen also dropped multiple clarifications and examples of ESP deployment on constrained devices, plus their optimizations, which is so helpful 🧚 Thomas Peyrin, Eric Thormarker, and Scott Fluhrer suggested and clarified the use of a transform that is resilient to nonce misuse 🔥 The authors also want to thank Mohit Sethi for his support as the LWIG Working Group Chair 🌸

Authors' Addresses 💌

Daniel Migault
Ericsson
8275 Rte Transcanadienne
Saint-Laurent QC H4S 0B6
Canada
Email: daniel.migault@ericsson.com


Tobias Guggemos
LMU Munich
MNM-Team
Oettingenstr. 67
80538 Munich
Germany
Email: guggemos@mnm-team.org

📦 where this page comes from

ietf: rfc9333 2023-01
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms