doc: Add RFC documents

1 files changed, 688 insertions, 0 deletions

diff --git a/doc/rfc/rfc9333.txt b/doc/rfc/rfc9333.txt
new file mode 100644
index 0000000..aa02d98
--- /dev/null
+++ b/doc/rfc/rfc9333.txt
@@ -0,0 +1,688 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        D. Migault
+Request for Comments: 9333                                      Ericsson
+Category: Informational                                      T. Guggemos
+ISSN: 2070-1721                                               LMU Munich
+                                                            January 2023
+
+
+            Minimal IP Encapsulating Security Payload (ESP)
+
+Abstract
+
+   This document describes the minimal properties that an IP
+   Encapsulating Security Payload (ESP) implementation needs to meet to
+   remain interoperable with the standard ESP as defined in RFC 4303.
+   Such a minimal version of ESP is not intended to become a replacement
+   of ESP in RFC 4303.  Instead, a minimal implementation is expected to
+   be optimized for constrained environments while remaining
+   interoperable with implementations of ESP.  In addition, this
+   document provides some considerations for implementing minimal ESP in
+   a constrained environment, such as limiting the number of flash
+   writes, handling frequent wakeup and sleep states, limiting wakeup
+   time, and reducing the use of random generation.
+
+   This document does not update or modify RFC 4303.  It provides a
+   compact description of how to implement the minimal version of that
+   protocol.  RFC 4303 remains the authoritative description.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   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 has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9333.
+
+Copyright Notice
+
+   Copyright (c) 2023 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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, as 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 are 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
+
+   ESP [RFC4303] is part of the IPsec protocol suite [RFC4301].  IPsec
+   is used to provide confidentiality, data origin authentication,
+   connectionless integrity, an anti-replay service, and limited Traffic
+   Flow Confidentiality (TFC) padding.
+
+   Figure 1 describes an ESP packet.  Currently, ESP is implemented in
+   the kernel of most major multipurpose Operating Systems (OSes).  ESP
+   is usually implemented with all of its features to fit the
+   multipurpose usage of these OSes, at the expense of resources and
+   with no considerations for code size.  Constrained devices are likely
+   to have their own implementation of ESP optimized and adapted to
+   their specific use, such as limiting the number of flash writes (for
+   each packet or across wake time), handling frequent wakeup and sleep
+   states, limiting wakeup time, and reducing the use of random
+   generation.  With the adoption of IPsec by Internet of Things (IoT)
+   devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC)
+   [EHC-DIET-ESP] [EHC-IKEv2], these ESP implementations MUST remain
+   interoperable with standard ESP implementations.  This document
+   describes the minimal properties an ESP implementation needs to meet
+   to remain interoperable with ESP [RFC4303].  In addition, this
+   document provides advice to implementers for implementing ESP within
+   constrained environments.  This document does not update or modify
+   [RFC4303].
+
+   For each field of the ESP packet represented in Figure 1, this
+   document provides recommendations and guidance for minimal
+   implementations.  The primary purpose of minimal ESP is to remain
+   interoperable with other nodes implementing ESP [RFC4303], while
+   limiting the standard 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 to index the Security Association
+   (SA).  As described in Section 4.1 of [RFC4301], nodes supporting
+   only unicast communications can index their SA using only the SPI.
+   Nodes supporting multicast communications also require the use of IP
+   addresses; thus, SA lookup needs to be performed using the longest
+   match.
+
+   For nodes supporting only unicast communications, indexing the SA
+   using only the SPI is RECOMMENDED.  The index may be based on the
+   full 32 bits of the SPI or a subset of these bits.  The node may
+   require a combination of the SPI as well as 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 to be used
+   internally and MUST NOT be sent over the wire.
+
+   [RFC4303] does not require the 32-bit SPI to be randomly generated,
+   although that is the RECOMMENDED way to generate SPIs as it provides
+   some privacy and security benefits and avoids correlation between ESP
+   communications.  To obtain a usable random 32-bit SPI, the node
+   generates a random 32-bit value and checks it does not fall within
+   the 0-255 range.  If the SPI has an acceptable value, it is used to
+   index the inbound session.  Otherwise, the generated value is
+   discarded, and the process repeats until a valid value is found.
+
+   Some constrained devices are less concerned with the privacy
+   properties associated with randomly generated SPIs.  Examples of such
+   devices might include sensors looking to reduce their code
+   complexity.  The use of a predictive function to generate the SPI
+   might be preferred over the generation and handling of random values.
+   An implementation of such predictable function could use the
+   combination of a fixed value and the memory address of the Security
+   Association Database (SAD) structure.  For every incoming packet, the
+   node will be able to point to the SAD structure directly from the SPI
+   value.  This avoids having a separate and additional binding and
+   lookup function for the SPI to its SAD entry for every incoming
+   packet.
+
+3.1.  Considerations for SPI Generation
+
+   SPIs that are not randomly generated over 32 bits may have privacy
+   and security concerns.  As a result, the use of alternative designs
+   requires careful security and privacy reviews.  This section provides
+   some considerations for the adoption of alternative designs.
+
+   The SPI value is only looked up for inbound traffic.  The SPI
+   negotiated with IKEv2 [RFC7296] or minimal IKEv2 [RFC7815] by a peer
+   is the value used by the remote peer when it sends traffic.  The main
+   advantage of using a rekeying mechanism is to enable a rekey, which
+   is performed by replacing an old SA with a new SA, both indexed with
+   distinct SPIs.  The SPI is only used for inbound traffic by the peer,
+   which allows each peer to manage the set of SPIs used for its inbound
+   traffic.  The necessary number of SPIs reflects the number of inbound
+   SAs as well as the ability to rekey those SAs.  Typically, rekeying
+   an SA is performed by creating a new SA (with a dedicated SPI) before
+   the old SA is deleted.  This results in an additional SA and the need
+   to support an additional SPI.  Similarly, the privacy concerns
+   associated with the generation of non-random SPIs is also limited to
+   the incoming traffic.
+
+   Alternatively, some constrained devices will not implement IKEv2 or
+   minimal IKEv2 and, as such, will not be able to manage a rollover
+   between two distinct SAs.  In addition, some of these constrained
+   devices are likely to have a limited number of SAs; for example, they
+   are likely to be indexed over 3 bytes only.  One possible way to
+   enable a rekeying mechanism with these devices is to use the SPI
+   where, for example, the first 3 bytes designates the SA while the
+   remaining byte indicates a rekey index.  SPI numbers can be used to
+   implement tracking the inbound SAs when rekeying is taking place.
+   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 such as "not yet rekeyed" or
+   "rekeyed 10 times".  If a constrained host uses a very limited number
+   of applications, eventually a single one, the SPI itself could
+   indicate what kind of traffic is transmitted (e.g., the kind of
+   application typically running).  This could also be correlated with
+   encrypted data size to further leak information to an observer on the
+   network.  In addition, use of 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 that
+   are used outdoors do not leak privacy-sensitive information, and most
+   of their traffic is expected to be outbound traffic.  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 to 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 to 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
+   avoid 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 are in a
+   sleep state most of the time and wake up only to perform a specific
+   operation before going back to sleep.  These devices have separate
+   hardware that allows them to wake up after a certain timeout and
+   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 that
+   are only written to stable storage at the creation of the SA.  Write
+   operations wear out the flash storage.  Write operations also slow
+   down the system significantly, as writing to flash is much slower
+   than reading from flash.  While these devices have internal clocks or
+   timers that might not be very accurate, they are good enough to
+   guarantee that each time the device wakes up from sleep, the time is
+   greater than what it was before the device 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
+   ensure that the serial numbers are still increasing and 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 characteristic to deliver packets out of order.  In an
+   environment where out-of-order packets are not possible, the window
+   size can be set to one.  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 will have 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 acknowledgement is of limited
+   interest and might not justify the implementation of an anti-replay
+   mechanism.  Receiving peers may also use an ESP anti-replay mechanism
+   adapted to a specific application.  Typically, when the sending peer
+   is using an SN based on time, anti-replay may be implemented by
+   discarding any packets that present an SN whose value is too much in
+   the past.  Such mechanisms may consider clock drifting in various
+   ways in addition to acceptable delay induced by the network to avoid
+   the anti-replay windows rejecting 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 received
+   time on the device is used to consider a packet to be 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 of 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
+   prevent 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 to prevent the SN from rolling 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.  Estimation of the maximum number of packets
+   to be sent by a node is not always predictable, and large margins
+   should be used, especially as nodes could be online for much more
+   time 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 is 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 is
+   not 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 used to a passive monitoring attacker.  Such information can
+   be used, for example, by an attacker if a vulnerability is known for
+   the specific device or application.  In addition, some applications
+   (such as health applications) could leak important privacy-oriented
+   information.
+
+   Constrained devices that have a limited battery lifetime may prefer
+   to avoid sending extra padding bytes.  In most cases, the payload
+   carried by these devices is quite small, and 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 to 30
+   bytes, the application could always send 32-byte responses to ensure
+   all traffic sent is of identical length.  To prevent leaking
+   information 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 is
+   happening, even if the sensor state did not change.
+
+6.  Next Header and "Dummy" Packets
+
+   ESP [RFC4303] defines the Next Header as a mandatory 8-bit field in
+   the packet.  The Next Header, only visible after decryption,
+   specifies the data contained in the payload.  In addition, the Next
+   Header may carry an indication on how to process the packet
+   [BEET-ESP].  The Next Header can point to a "dummy" packet, i.e., a
+   packet with the Next Header value set to 59, meaning "no next
+   header".  The data following "no next header" is unstructured "dummy"
+   data.  (Note that this document uses the term "dummy" for consistency
+   with [RFC4303].)
+
+   The ability to generate, receive, and ignore "dummy" packets is
+   required by [RFC4303].  An implementation can omit ever generating
+   and sending "dummy" packets.  For interoperability, a minimal ESP
+   implementation MUST be able to process and discard "dummy" packets
+   without indicating an error.
+
+   In constrained environments, sending "dummy" packets may have too
+   much impact on the device lifetime, in which case, "dummy" packets
+   should not be generated and sent.  On the other hand, constrained
+   devices running specific applications that would leak too much
+   information by not generating and sending "dummy" packets may
+   implement this functionality or even implement something similar at
+   the application layer.  Note also that similarly to padding and TFC
+   that can be used to hide some traffic characteristics (see
+   Section 5), "dummy" packets may also reveal some patterns that can be
+   used to identify the application.  For example, an application may
+   send "dummy" data to hide a traffic pattern.  Suppose such an
+   application sends a 1-byte data when a change occurs.  This results
+   in sending a packet notifying a change has occurred.  "Dummy" packets
+   may be used to prevent such information from being leaked by sending
+   a 1-byte packet every second when the information is not changed.
+   After an upgrade, the data becomes 2 bytes.  At that point, the
+   "dummy" packets do not hide anything, and having 1 byte regularly
+   versus 2 bytes makes even the identification of the application
+   version easier to identify.  This generally makes the use of "dummy"
+   packets more appropriate on high-speed links.
+
+   In some cases, devices are dedicated to a single application or a
+   single transport protocol.  In this case, the Next Header has a fixed
+   value.
+
+   Specific processing indications have not been standardized yet
+   [BEET-ESP] and are expected to result from an agreement between the
+   peers.  As a result, they SHOULD NOT be part of a minimal
+   implementation of ESP.
+
+7.  ICV
+
+   The ICV depends on the cryptographic suite used.  As detailed in
+   [RFC8221], authentication or authenticated encryption is RECOMMENDED,
+   and as such, the ICV field must be present with a size different from
+   zero.  Its length is defined by the security recommendations only.
+
+8.  Cryptographic Suites
+
+   The recommended algorithms to use are expected to evolve over time,
+   and implementers SHOULD follow the recommendations provided by
+   [RFC8221] and updates.
+
+   This section lists some of the criteria that may be considered to
+   select an appropriate cryptographic suite.  The list is not expected
+   to be exhaustive and may also evolve over time.
+
+   1.  Security: Security is the criteria that should be considered
+       first for the selection of encryption algorithm transforms.  The
+       security of encryption algorithm transforms is expected to evolve
+       over time, and it is of primary importance 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.  In the latter case,
+       Authenticated Encryption with Associated Data (AEAD) is
+       RECOMMENDED [RFC8221].
+
+   2.  Resilience to Nonce Reuse: Some transforms, including AES-GCM,
+       are vulnerable to nonce collision with a given key.  While the
+       generation of the nonce may prevent such collision during a
+       session, the mechanisms are unlikely to provide such protection
+       across sleep states or reboot.  This causes an issue for devices
+       that are configured using static keys (called "manual keying"),
+       and manual keying should not be used with these encryption
+       algorithms.  When the key is likely to be reused across reboots,
+       algorithms that are resistant to nonce misuse (for example, AES-
+       SIV [RFC5297], AES-GCM-SIV [RFC8452], and Deoxys-II [DeoxysII])
+       are RECOMMENDED.  Note, however, that none of these are currently
+       defined for use with ESP.
+
+   3.  Interoperability: Constrained devices usually only implement one
+       or very few different encryption algorithm transforms.  [RFC8221]
+       takes the life cycle of encryption algorithm transforms and
+       device manufacturing into consideration in its recommendations
+       for mandatory-to-implement (MTI) algorithms.
+
+   4.  Power Consumption and Cipher Suite Complexity: Complexity of the
+       encryption algorithm transform and the energy cost associated
+       with it are especially important considerations for devices that
+       have limited resources or are battery powered.  The battery life
+       might determine the lifetime of the entire device.  When choosing
+       a cryptographic function, reusing specific libraries or taking
+       advantage of hardware acceleration provided by the device should
+       be considered.  For example, if the device benefits from AES
+       hardware modules and uses ENCR_AES_CTR, it may prefer AUTH_AES-
+       XCBC for its authentication.  In addition, some devices may embed
+       radio modules with hardware acceleration for AES-CCM, in which
+       case, this transform may be preferred.
+
+   5.  Power Consumption and Bandwidth Consumption: Reducing the payload
+       sent may significantly reduce the energy consumption of the
+       device.  Encryption algorithm transforms with low overhead are
+       strongly preferred.  To reduce the overall payload size, one may,
+       for example:
+
+       *  Use counter-based ciphers without 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 are aligned to the
+          cipher block length -- 2 bytes for the ESP trailer.
+
+9.  IANA Considerations
+
+   This document has no IANA actions.
+
+10.  Security Considerations
+
+   The security considerations in [RFC4303] apply to this document as
+   well.  In addition, this document provides security recommendations
+   and guidance for the implementation choices for each ESP field.
+
+   The security of a communication provided by ESP is closely related to
+   the security associated with the management of that key.  This
+   usually includes mechanisms to prevent a nonce from repeating, for
+   example.  When a node is provisioned with a session key that is used
+   across reboot, the implementer MUST ensure that the mechanisms put in
+   place remain valid across reboot as well.
+
+   It is RECOMMENDED to use ESP in conjunction with key management
+   protocols such as, for example, IKEv2 [RFC7296] or minimal IKEv2
+   [RFC7815].  Such mechanisms are responsible for negotiating fresh
+   session keys as well as preventing a session key being 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 and that the key remains used 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].
+   In addition, [SP-800-90A-Rev-1] provides guidance on how to build
+   random generators based on deterministic random functions.
+
+11.  Privacy Considerations
+
+   Preventing the leakage of privacy-sensitive information is a hard
+   problem to solve and usually results in balancing the information
+   potentially being leaked to the cost associated with the counter
+   measures.  This problem is not inherent to the minimal ESP described
+   in this document and also concerns the use of ESP in general.
+
+   This document targets minimal implementations of ESP and, as such,
+   describes a minimalistic way to implement ESP.  In some cases, this
+   may result in potentially revealing privacy-sensitive pieces of
+   information.  This document describes these privacy implications so
+   the implementer can make the appropriate decisions given the
+   specificities of a given environment and deployment.
+
+   The main risk associated with privacy is the ability to identify an
+   application or a device by analyzing the traffic, which is designated
+   as "traffic shaping".  As discussed in Section 3, the use in a very
+   specific context of non-randomly generated SPIs might ease the
+   determination of the device or the application in some cases.
+   Similarly, padding provides limited capabilities to obfuscate the
+   traffic compared to those provided by TFC.  Such consequences on
+   privacy 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
+
+   [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
+
+   The authors would like 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.  In particular, Scott Fluhrer suggested including the rekey
+   index in the SPI.  Tero Kivinen also provided multiple clarifications
+   and examples of ESP deployment within constrained devices with their
+   associated optimizations.  Thomas Peyrin, Eric Thormarker, and Scott
+   Fluhrer suggested and clarified the use of transform resilient to
+   nonce misuse.  The authors would also like 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