wdiff draft-ietf-lwig-minimal-esp-10.txt draft-ietf-lwig-minimal-esp-11.txt

Light-Weight Implementation Guidance (lwig) D. Migault
Internet-Draft Ericsson
Intended status: Informational T. Guggemos
Expires: 10 October 25 November 2022 LMU Munich
8 April
24 May 2022

Minimal IP Encapsulating Security Payload (ESP)
draft-ietf-lwig-minimal-esp-10
draft-ietf-lwig-minimal-esp-11

Abstract

This document describes the minimal properties that an IP
Encapsulating Security Payload (ESP) implementation needs to meet to
remain interoperable with the standard RFC4303 ESP. Such a minimal
version of ESP is not intended to become a replacement of the RFC
4303 ESP. Instead, a minimal implementation is expected to be
optimized for constrained environment environments while remaining interoperable
with implementations of RFC 4303 ESP. In addition, this document
also provides some considerations to implement for implementing minimal ESP in a
constrained environment which includes limiting the number of flash
writes, handling frequent wakeup / sleep states, limiting wakeup
time, or and reducing the use of random generation.

This document does not update or modify RFC 4303, but 4303. It provides a
compact description of how to implement the minimal version of the that
protocol. RFC 4303 remains the authoritative description.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 10 October 25 November 2022.

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. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Security Parameter Index (SPI) (32 bit) . . . . . . . . . . . 4
3.1. Considerations over SPI generation . . . . . . . . . . . 5 4
4. Sequence Number(SN) (32 bit) . . . . . . . . . . . . . . . . 6
5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Next Header (8 bit) . . . . . . . . . and Dummy Packets . . . . . . . . . . . . 9
7. ICV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Cryptographic Suites . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 12
12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 13 12
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15

1. 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 [RFC2119]. BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

2. 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 (a form of partial
sequence integrity) 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 (OS). The ESP and
IPsec suite is
usually implemented in a complete way with all of its features to fit the multiple
purpose usage of these OSes. However, completeness of the IPsec
suite as well as multipurpose scope of these OSes is often performed OSes, at the expense of resources, or performance. As a result,
constrained resources and with no
considerations for code size. Constrained devices are likely to have
their own implementation of ESP optimized and adapted to their specificities
specific use, such as limiting the number of flash writes (for each
packet or across wake time), handling frequent wakeup and sleep
state, limiting wakeup time, or and reducing the use of random
generation. With the adoption of IPsec by IoT devices with minimal
IKEv2 [RFC7815] and ESP Header Compression (EHC) with
[I-D.mglt-ipsecme-diet-esp] or
[I-D.mglt-ipsecme-ikev2-diet-esp-extension], it becomes crucial that these ESP implementation designed for constrained devices
implementations MUST remain inter-
operable interoperable with the standard ESP implementation to avoid a fragmented
usage of ESP.
implementations. This document describes the minimal properties an
ESP implementation needs to meet to remain interoperable with
[RFC4303] ESP. In addition, this document also provides a set of options advise to
implement these properties under certain
implementers for implementing ESP within constrained environments.
This document does not update or modify RFC 4303, but provides a
compact description of how to implement the minimal version of the
protocol. RFC 4303 remains the authoritative description. 4303.

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 RFC 4303 ESP, 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

3. Security Parameter Index (SPI) (32 bit)

According to the [RFC4303],

[RFC4303] defines the SPI is as a mandatory 32 bits field and
is not allowed to be removed. field.

The SPI has a local significance to index the Security Association
(SA). From [RFC4301] section 4.1, nodes supporting only unicast
communications can index their SA only using only the SPI. On the other
hand, nodes Nodes
supporting multicast communications must also require to use the IP
addresses and thus SA lookup needs need to be performed using the longest
match.

For nodes supporting only unicast communications, this document
recommends it is RECOMMENDED
indexing the SA with using only the SPI only. SPI. The index may be based on the
full 32 bits of 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 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 it must not MUST NOT be sent on over the wire.

[RFC4303] does not require the 32 bit SPI to be randomly generated over 32
bits. However, this generated,
although that is the recommended RECOMMENDED way to generate SPIs as it provides
some privacy and security benefits and avoids, for example, avoids correlation between ESP
communications. To randomly generate obtain a usable random 32 bit SPI, the node
generates a random 32 bit value and checks it does not fall in within
the 0-255 range. If the SPI has an acceptable value, it is used to
index the inbound session, otherwise session. Otherwise the SPI generated value is re-generated
discarded and the process repeats until an
acceptable a valid value is found.

However, some

Some constrained nodes may be devices are less concerned by with the privacy
properties associated to SPIs randomly generated. generated SPIs. Examples of such
nodes
devices might include sensors looking to reduce their code complexity,
in which case the
complexity. The use of a predictive function to generate the SPI
might be preferred over the generation and handling of random values.
An example implementation of such predictable function may consider could use the
combination of a fixed value and the memory address of the 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 between SPI and SAD entries that is involved lookup function for the SPI to
its SAD entry for every incoming packet.

3.1. Considerations over SPI generation

SPI

SPIs that are not randomly generated over 32 bits may lead to have privacy
and security concerns. As a result, the use of alternative designs
requires careful security and privacy reviews. This section provides
some considerations upon the adoption of alternative designs.

Note that

The SPI value is used only looked up for inbound traffic, as such the traffic. The SPI
negotiated with IKEv2 [RFC7296] or Minimal IKEv2 [RFC7815] by a peer, 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, that is
performed by replacing an old SA by a new SA, both indexed with
distinct SPIs. As the SPI is only used for inbound traffic by the
peer, this allows each peer to manage the set of SPIs used for its
inbound traffic. The necessary number of SPI reflects the number of
inbound SAs as well as the ability to rekey these SAs. Typically,
rekeying a 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 SPI non-random SPIs is also
limited to the incoming traffic.

When alternate designs are considered, it is likely that the number
of possible SPIs

Alternatively, some constrained devices will not implement IKEv2 or
Minimal IKEv2 and as such will not be limited. This limit should both consider
the able to manage a roll-over
between two distinct SAs. In addition, some of these constrained
devices are also likely to have a limited number of inbound SAs - possibly per IP addresses - as well as likely to
be indexed over 3 bytes only for example. One possible way to enable
a rekey mechanism with these devices is to use the ability SPI where for
example the node to rekey. first 3 bytes designates the SA while the remaining byte
indicates a rekey index. SPI numbers can typically be used to implement a key update with the SPI indicating
tracking the key inbound SAs when rekeying is being used.
For example, taking place. When
rekeying a SPI, the new SPI might be encoded with could use the Security Association
Database (SAD) entry on a subset of SPI bytes (for example 3 bytes),
while the remaining byte indicates to indicate the rekey
rekeying index.

The use of a smaller number small limited set of SPIs SPI numbers across communications
comes with privacy and security concerns. Typically, some Some specific values or
subset of SPI values may could reveal the models or manufacturer of the
node implementing ESP. This may raise some privacy issues It could also reveal some state such as an
observer is likely to be able to determine the "not
yet rekeyed" or "rekeyed 10 times". If a constrained devices of
the network. In some cases, these nodes may host uses a
very limited
number of applications - typically a single application - in which
case or even just one application, the SPI would provide some information related to the
application itself could
indicate what kind of traffic (eg the user. In addition, the device or kind of application may
be associated with some vulnerabilities, in which case specific SPI
values may typically
running) is transmitted. This could be used further correlated by an attacker
encrypted data size to discover vulnerabilities.

While further leak information to an observer on the
network. In addition, use of randomly generated SPIs may reduce the leakage specific hardcoded SPI numbers could
reveal a manufacturer or
privacy of security related information device version. If updated devices use
different SPI numbers, an attacker could locate vulnerable devices by ESP itself, these pieces
their use of information may also be leaked otherwise. As a result, a specific SPI numbers.

A privacy analysis should consider at least the type of information
as well the traffic pattern before determining a non random SPI can be used.
Typically, deciding whether non-random SPIs
are safe to use. Typically temperature sensors, wind sensors, used
outdoors may not leak privacy sensitive information and most of its
traffic is expected to be outbound traffic. When used indoors, a
sensor that reports every minute an encrypted status of the a door (closed or opened) may
every minute, might not leak truly little privacy 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 these
sensors are being used. If the risks associated to privacy and
security are acceptable, a randomized SPI is not
necessary. In any case, for such constrained sensors, it remains
better to have secure communications with non random non-randomized SPI as opposed
to no security. can be used.

4. Sequence Number(SN) (32 bit)

According to [RFC4303], the

The Sequence Number (SN) in [RFC4303] is a mandatory 32 bits 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: if packet B is sent after packet A, then SN of
packet B is strictly greater higher than the SN of packet A.

Some constrained devices may establish communication with specific
devices, like a specific gateway, or nodes similar to them. As a
result, the sender may know
devices where it is known whether or not the receiver peer implements anti-
replay protection or not. Even though the sender may know the
receiver does not implement anti-replay protection, protection. As per [RFC4303], the sender must MUST still implement an always
a strictly increasing function to generate the SN.

Usually, SN

The RECOMMENDED way for multipurpose ESP implementation is generated by incrementing to
increment a counter for each packet sent. A However, a constrained
device may avoid maintaining this context and use another source that
is known to always increase. Typically, constrained nodes using devices use
802.15.4 Time Slotted Channel Hopping (TSCH),
whose (TSCH). This communication is
heavily dependent on time, time. A contrained device can take advantage of their
this clock mechanism to generate the SN. A lot of IoT devices are in
a sleep state most of the time and wake up and are only awake to perform a specific
operation before going back to sleep. They These devices do have separate
hardware that allows them to wake up after a certain timeout, timeout and
most likely
typically also timers that start running when the device was booted
up, so they might have a concept of time with certain granularity.
This requires to store any information in a stable storage - such as
flash memory - that can be restored across sleeps. Storing
information associated with the SA such as SN requires some read and
writing
write operation on a stable storage after each packet is sent as
opposed to a SPI number or cryptographic keys that are only written
to stable storage at the creation of the SA. Such Write operations are likely to wear
out the flash, and flash storage. Write operations also slow down the system greatly,
significantly, as writing to flash is not as fast as reading.
Their much slower than reading from
flash. While these devices have internal clocks/timers clocks or timers that might
not be very accurate, but they
should be these are good enough to know guarantee that each
time they wake the device wakes up from sleep that their time is greater than
what it was last time they woke up. 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. Of course, one
should only consider use of a clock SN on flash. In addition
to generate SNs if the
application will inherently time value, a RAM based counter can be used to ensure that no two if
the device sends multiple packets with a given over an SA are sent with within one wake up
period, that the same time value. serial numbers are still increasing and unique.
Note however that standard receivers are generally configured with
incrementing counters and, if not appropriately configured, the use
of a significantly larger SN
difference may than the previous packet can result in the
that packet out falling outside of the receiver's windows and peer's receiver window which could
cause that packet being to be discarded.

For inbound traffic, this document recommends it is RECOMMENDED that receivers
implements anti-replay protection, and the implement anti-
replay protection. The size of the window depends should depend on the ability
property of the network to deliver packets out of order. As a
result, in In an
environment where out of order packets is are not possible possible, the window
size can be set to one. However, while recommended, there
are no requirements An ESP implementation may choose to not
implement an anti-replay protection mechanism
implemented by IPsec. Similarly to the SN the protection. An implementation of anti anti-
replay protection may require the device to write the received SN for
every packet, which may in some cases come with packet to stable storage. This will have the same drawbacks issues as
those exposed for
discussed earlier with the SN. As a result, some Some constrained device
implementations may drop a
non required anti replay protection especially when the necessary
resource involved overcomes the benefit of the mechanism. These
resources need also choose to balance that absence of not implement the optional anti-replay mechanism,
may lead to unnecessary integrity check operations that might be
significantly more expensive as well.
protection. A typical example might consider an IoT device such as a
temperature sensor that is sending a temperature measurement every 60
seconds, and that receives an acknowledgment from the receiver. In
such cases, the ability to spoof and replay an acknowledgement is of
limited interest and might not justify the implementation of an anti anti-
replay mechanism. Receiving peers may also use ESP anti-replay
mechanism adapted to a specific application. Typically, when the
sending peer is using SN based on time, anti-replay may be
implemented by discarding any packets that present a SN whose value
is too much in the past. Note
that such 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. When a packet It could accept any SN as long as it is
received at a regular time interval, some variant of time based
mechanisms may not even use the value of higher than the SN, but instead
previously received SN. Another mechanism could be used where only
consider
the receiving received time of on the device is used to consider a packet as
valid, without looking at the packet. SN at all.

The SN can be encoded over represented as a 32 bits bit number, or as a 64 bits - bit number,
known as Extended Sequence Number (ESN). As per [RFC4303], the support
of ESN is not
mandatory. The determination of the mandatory and its use of is negotiated via IKEv2
[RFC7296]. A ESN is based on 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
largest possible value a SN can take over a session. When from rolling over. This assumes the SN is incremented by 1
for each packet, the number of packets sent over the
lifetime of a session may be considered. However, when packet. When the SN is incremented differently - such as
when time is used - the maximum
value SN rekeying needs to be considered instead. Note that happen based on how the limit of
messages being sent SN is primarily determined by the security
associated with the key rather than
incremented to prevent the SN. 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 challenging predicatable and as such large margins should be considered
cautiously
used espcially as nodes could be online for much more time than
expected. Even for constrained devices, this document recommends implementing it is RECOMMENDED to
implement some rekey mechanisms (see Section 10).

5. Padding

The purpose of padding

Padding is required to respect keep the 32 bit alignment of ESP or ESP. It is also
required for some encryption transforms that need a specific block
size expected by an encryption transform - of input, such as AES-CBC for
example. ENCR_AES_CBC. ESP must have at least one specifies padding byte in the
Pad Length that
indicates the padding length. ESP padding bytes are generated byte, followed by a
succession of unsigned bytes starting with 1, 2, 3 with the last byte
set up to Pad Length, where Pad Length designates the length 255 bytes of the
padding bytes. padding.

Checking the padding structure is not mandatory, so the constrained
device
devices may omit such checks, however, in order to interoperate with
existing these checks on received ESP implementations, it must build the packets. For outgoing
ESP packets, padding bytes must be applied as
recommended required by ESP.

In some situation the padding bytes may take a fixed value. This
would typically be the case when the Data Payload is of fixed size.

ESP [RFC4303] also additionally provides Traffic Flow Confidentiality
(TFC) as a way to perform padding to hide traffic characteristics, which differs
from respecting a 32 bit alignment. characteristics.
TFC is not mandatory and must be is negotiated with the SA management protocol.
protocol, such as IKEv2. TFC has not been widely
adopted implemented but it is
not widely deployed for standard ESP traffic. One possible reason is that it
requires to shape the traffic according to one traffic pattern that
needs to be maintained. This It is likely NOT RECOMMENDED to require extra processing
as well as providing
implement TFC for a "well recognized" traffic shape which could
end up being counterproductive. As such, this document does not
recommend that minimal ESP implementation supports TFC. ESP.

As a result, consequence, communication protection that was relying relies on TFC will would
be more sensitive to traffic shaping. patterns without TFC. This could expose the can leak
application information as well as the devices manifacturor or model of the
device used to a passive monitoring attacker. Such information could can
be used used, for example, by the an attacker in case a vulnerability is
disclosed on known
for the specific device. device or application. In addition, some
application use - such as health applications - may also reveal could leak important
privacy oriented information.

Some constrained nodes

Constrained devices that have limited battery lifetime may also prefer avoiding to
avoid sending extra padding bytes. However, the same nodes
may also be very specific to an application and device. As a result,
they are also likely to be the main target for traffic shaping. In most cases, the payload
carried by these nodes devices is quite small, and the standard padding
mechanism may also can be used as an alternative to
TFC, with a sufficient tradeoff between the required energy to send
additional payload and the exposure to traffic shaping attacks. In
addition, the TFC. Alternatively, any
information leaked by leak based on the traffic shaping may size - or presence - of the packet can
also be addressed by at the application level. For example, it level, before the packet is preferred
encrypted with ESP. If application packets vary between 1 to
have 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 sending some changed state, such as "temperature
changed" or "door opened", an application could send this information
at regular time interval, rather than when a specific event is happening. Typically, a
happening, even if the sensor
monitoring the temperature, or a door is expected to send regularly
the information - i.e. the temperature of the room or whether the
door is closed or open) instead of only sending the information when
the temperature has raised or when the door is being opened. state did not change.

6. Next Header (8 bit)

According to [RFC4303], and Dummy Packets

ESP [RFC4303] defines the Next Header is as a mandatory 8 bits field in
the packet. The Next header header, only visible after decryption,
specifies the data contained in the
payload as well as dummy packet, i.e. packets with the Next Header
with a value 59 meaning "no next header". payload. In addition, the Next
Header may also carry an indication on how to process the packet
[I-D.nikander-esp-beet-mode]. The Next Header can point to a dummy
packet, i.e. packets with the Next Header value set to 59 meaning "no
next header". The data following to "no next header" is unstructured
dummy data.

The ability to generate and to 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 MUST be able to process and discard dummy packets
without indicating an error. Note that such
recommendation only applies for nodes receiving packets, and that
nodes designed to only send data might not implement this capability.

As the generation of dummy packets is subject to local management and
based on a per-SA basis, a minimal ESP implementation may not
generate such dummy packet. Specifically, in

In constrained environment environments, sending dummy packets may have too much
impact on the device lifetime, and in which case dummy packets should not
be avoided. generated and sent. On the other hand, constrained
nodes 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 dedicated used
to specific applications, in which case, hide some traffic pattern characteristics (see Section 5), dummy packet
may expose the application or also reveal some patterns that can be used to identify the type of node.
application. For
these nodes, not sending example, an application may send dummy data to hide
some traffic pattern. Suppose such such application sends a 1 byte
data when a change occurs. This results in sending a packet
notifying a change has occurred. Dummy packet may have some privacy
implication that needs be used to prevent
such information to be measured. However, for leaked by sending a 1 byte packet every second
when the same reasons
exposed in Section 5 traffic shaping at information is not changed. After an upgrade the data
becomes two bytes. At that point, the IPsec layer may also
introduce some traffic pattern, dummy packets do not hide
anything and on constrained devices having 1 byte regularly versus 2 bytes make even the
application is probably
identification of the most appropriated layer application, version easier to limit identify. This
generaly makes the risk use of leaking information by traffic shaping. dummy packets more appropriated on high
speed links.

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

Specific processing indications have not been standardized yet
[I-D.nikander-esp-beet-mode] and is expected to result from an
agreement between the peers. As a result, it should not SHOULD NOT be part of a
minimal implementation of ESP.

7. ICV

The ICV depends on the cryptographic suite used. Currently,
[RFC8221] only recommends cryptographic suites with an ICV which
makes the ICV a mandatory field. As detailed in
[RFC8221] authentication or authenticated encryption are recommended 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 cryptographic suites implemented are an important component of
ESP. The recommended algorithms to use are expected to evolve over time
and implementers should SHOULD follow the recommendations provided by
[RFC8221] and updates.

This section lists some of the criteria that may be considered to
select the 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 transform. 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 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 (AEAD) is RECOMMENDED [RFC8221].

2. Resilience to nonce re-use: Some transforms -including AES-GCM -
are very sensitive 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 a key. these encryption
algorithms. When the key is likely to be re-used across reboots,
algorithms that are nonce misuse resistant such as, for example,
AES-SIV [RFC5297], AES-GCM-SIV [RFC8452] or Deoxys-II [DeoxysII]
are RECOMMENDED. Note however that currently none of them has these are
yet been defined for use with ESP.

3. Interoperability: Interoperability considers the encryption
algorithm transforms shared with the other nodes. Note that it
is not because an constrained devices usually only implement one
or very few different encryption algorithm transform is widely
deployed that it is secured. As a result, security should not be
weakened for interoperability. transforms. [RFC8221] and successors consider
takes the life cycle of encryption algorithm transforms sufficiently
long to provide interoperability. Constrained devices may have
limited interoperability requirements which makes possible to
reduces the number of encryption algorithm transforms to
implement. and
device manufactoring into consideration in its recommendations
for mandatory-to-implement ("MTI") algorithms.

4. Power Consumption and Cipher Suite Complexity: Complexity of the
encryption algorithm transform or and the energy cost associated
with it are especially considered when important considerations for devices that
have limited resources or are using some batteries, in which case the battery determines
the powered. The battery life
might determine the lifetime of the entire device. The choice of
a cryptographic function
may should consider re-using specific
libraries or to take advantage of hardware acceleration provided
by the device. For example, if the device benefits from AES
hardware modules and uses AES-CTR, ENCR_AES_CTR, it may prefer AUTH_AES-XCBC AUTH_AES-
XCBC for its authentication. In addition, some devices may also
embed radio modules with hardware acceleration for AES-CCM, in
which case, this mode transform may be preferred.

5. Power Consumption and Bandwidth Consumption: Similarly to the
encryption algorithm transform complexity, reducing Reducing the payload
sent,
sent may significantly reduce the energy consumption of the
device. As a result, encryption Encryption algorithm transforms with low overhead may be considered. are
strongly preferred. To reduce the overall payload size one may,
for example:

1. Use of counter-based ciphers without fixed block length (e.g.
AES-CTR, or ChaCha20-Poly1305).

2. Use of ciphers with capability of using implicit IVs
[RFC8750].

3. Use of ciphers recommended for IoT [RFC8221].

4. Avoid Padding by sending payload data which are aligned to
the cipher block length - 2 for the ESP trailer.

9. IANA Considerations

There are no IANA consideration for this document.

10. Security Considerations

Security considerations Considerations are those of [RFC4303]. In addition, this
document provided security recommendations and guidance over 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 MUST ensure that the mechanisms put in
place remain valid across reboot as well.

This document recommends

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 prevent a session key being use beyond its
lifetime. When such mechanisms cannot be implemented and implemented, such as when
the the session key is, for example, is provisioned, the nodes must device MUST ensure that keys
are not used beyond their lifetime and that the appropriate use
of the key remains used
in compliance will all security requirements across reboots - e.g.
conditions on counters and nonces remains valid.

When a node device generates its own key or when random value such as
nonces are generated, the random generation must MUST follow [RFC4086].
In addition, [SP-800-90A-Rev-1] provides appropriated 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 result 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 some minimalistic way to implement ESP. In some cases,
this may result in potentially exposing revealing privacy sensitive pieces of
information. This document describes these privacy implications so
the designer implementer can take the appropriate decisions given the
specificities of a given environment and deployment.

The main risks 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 some very
specific context of non randomly generated SPI might in some cases
ease the determination of the device of or the application. Similarly,
padding provides limited capabilities to obfuscate the traffic
compared to those provided by TFC. Such consequence on privacy as
detailed in Section 5.

12. Acknowledgment

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 provided also provided multiple clarifications
and examples of deployment ESP 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.

13. References

13.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>.

13.2. Informative References

[DeoxysII] Jeremy, J. J., Ivica, I. N., Thomas, T. P., and Y. S.
Yannick, "Deoxys v1.41", October 2016,
<https://competitions.cr.yp.to/round3/deoxysv141.pdf>.

[I-D.mglt-ipsecme-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-07, 11 March
2019, draft-mglt-ipsecme-diet-esp-08, 13 May
2022, <https://www.ietf.org/archive/id/draft-mglt-ipsecme-
diet-esp-07.txt>.
diet-esp-08.txt>.

[I-D.mglt-ipsecme-ikev2-diet-esp-extension]
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-01, 26
June 2018, draft-mglt-ipsecme-ikev2-diet-esp-extension-02, 13
May 2022, <https://www.ietf.org/archive/id/draft-mglt-
ipsecme-ikev2-diet-esp-extension-01.txt>.
ipsecme-ikev2-diet-esp-extension-02.txt>.

[I-D.nikander-esp-beet-mode]
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://www.ietf.org/archive/id/draft-nikander-esp-beet-
mode-09.txt>.

[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]
Elain, E. B. and J. K. Kelsey, "Recommendation for Random
Number Generation Using Deterministic Random Bit
Generators", <https://csrc.nist.gov/publications/detail/
sp/800-90a/rev-1/final>.

Authors' Addresses

Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
Email: daniel.migault@ericsson.com

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