rfc9333xml2.original.xml   rfc9333.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc rfcedstyle="yes"?> <!DOCTYPE rfc [
<?rfc toc="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocindent="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc sortrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc strict="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>
<rfc category="info" docName="draft-ietf-lwig-minimal-esp-12" ipr="trust200902"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="9333" category="info" do
<front> cName="draft-ietf-lwig-minimal-esp-12" ipr="trust200902" obsoletes="" updates=""
<title abbrev="Minimal ESP">Minimal IP Encapsulating Security Payload (ESP)< submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" sortRefs
/title> ="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.15.0 -->
<front>
<title abbrev="Minimal IP ESP">Minimal IP Encapsulating Security Payload (ES
P)</title>
<seriesInfo name="RFC" value="9333"/>
<author surname="Migault" initials="D." fullname="Daniel Migault"> <author surname="Migault" initials="D." fullname="Daniel Migault">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>8400 boulevard Decarie</street> <street>8275 Rte Transcanadienne</street>
<city>Montreal, QC H4P 2N2</city> <city>Saint-Laurent</city>
<region>QC</region>
<code>H4S 0B6</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>daniel.migault@ericsson.com</email> <email>daniel.migault@ericsson.com</email>
</address> </address>
</author> </author>
<author surname="Guggemos" initials="T." fullname="Tobias Guggemos"> <author surname="Guggemos" initials="T." fullname="Tobias Guggemos">
<organization>LMU Munich</organization> <organization>LMU Munich</organization>
<address> <address>
<postal> <postal>
<street>MNM-Team</street> <street>MNM-Team</street>
<street>Oettingenstr. 67</street> <street>Oettingenstr. 67</street>
<city>80538 Munich</city> <city>80538 Munich</city>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>guggemos@mnm-team.org</email> <email>guggemos@mnm-team.org</email>
</address> </address>
</author> </author>
<date /> <date year="2022" month="December" />
<area>INTERNET</area> <area>Internet</area>
<workgroup>Light-Weight Implementation Guidance (lwig)</workgroup> <workgroup>Light-Weight Implementation Guidance (lwig)</workgroup>
<abstract>
<t>
This document describes the minimal properties that an IP Encapsulating Security
Payload (ESP) implementation needs to meet to remain interoperable with the sta
ndard RFC4303 ESP.
<!-- This document describes a minimal IP Encapsulation Security Payload (ESP) d
efined in RFC 4303. Its purpose is to enable implementation of ESP with a minima
l set of options to remain compatible with ESP as described in RFC 4303. -->
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 en
vironments while remaining interoperable with implementations of RFC 4303 ESP.
In addition, this document also provides some considerations for implementing mi
nimal ESP in a constrained environment which includes limiting the number of fla
sh writes, handling frequent wakeup / sleep states, limiting wakeup time, and re
ducing the use of random generation. </t>
<t> This document does not update or modify RFC 4303. It provides a compact desc <abstract>
ription of how to implement the minimal version of that protocol. <t>
This document describes the minimal properties that an IP Encapsulating Security
Payload (ESP) implementation needs to meet to remain interoperable with the sta
ndard 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 en
vironments 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 th
e use of random generation. </t>
<t> This document does not update or modify RFC 4303. It provides a compac
t description of how to implement the minimal version of that protocol.
RFC 4303 remains the authoritative description.</t> RFC 4303 remains the authoritative description.</t>
</abstract>
</front>
<middle>
</abstract> <section numbered="true" toc="default">
</front> <name>Introduction</name>
<t>ESP <xref target="RFC4303" format="default"/> is part of the IPsec prot
<middle> ocol suite <xref target="RFC4301" format="default"/>.
IPsec is used to provide confidentiality, data origin authentication, connection
<section title="Requirements notation"> less integrity, an anti-replay service, and limited Traffic Flow Confidentiality
(TFC) padding.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", <t><xref target="fig-esp-description" format="default"/> describes an ESP
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d packet.
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <x Currently, ESP is implemented in the kernel of most major multipurpose Operating
ref target="RFC8174"/> when, and only when, they appear in all capitals, as show Systems (OSes).
n here.</t> ESP is usually implemented with all of its features to fit the multipurpose usag
e of these OSes, at the expense of resources and with no considerations for code
</section> size.
Constrained devices are likely to have their own implementation of ESP optimized
<section title="Introduction"> 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
<t>ESP <xref target="RFC4303"/> is part of the IPsec protocol suite <xref targe , limiting wakeup time, and reducing the use of random generation.
t="RFC4301"/>. With the adoption of IPsec by Internet of Things (IoT) devices with minimal IKEv
IPsec is used to provide confidentiality, data origin authentication, connection 2 <xref target="RFC7815" format="default"/> and ESP Header Compression (EHC) <xr
less integrity, an anti-replay service and limited traffic flow confidentiality ef target="I-D.mglt-ipsecme-diet-esp" format="default"/> <xref target="I-D.mglt-
(TFC) padding.</t> ipsecme-ikev2-diet-esp-extension" format="default"/>, these ESP implementations
<bcp14>MUST</bcp14> remain interoperable with standard ESP implementations.
<t><xref target="fig-esp-description"/> describes an ESP Packet. This document describes the minimal properties an ESP implementation needs to me
Currently, ESP is implemented in the kernel of most major multipurpose Operating et to remain interoperable with ESP <xref target="RFC4303" format="default"/>.
Systems (OS). In addition, this document provides advice to implementers for implementing ESP
ESP is usually implemented with all of its features to fit the multiple purpose within constrained environments.
usage of these OSes, at the expense of resources and with no considerations for This document does not update or modify <xref target="RFC4303" format="default"/
code size. >.</t>
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 state,
limiting wakeup time, and reducing the use of random generation.
With the adoption of IPsec by IoT devices with minimal IKEv2 <xref target="RFC78
15"/> and ESP Header Compression (EHC) with <xref target="I-D.mglt-ipsecme-diet-
esp"/> or <xref target="I-D.mglt-ipsecme-ikev2-diet-esp-extension"/>, these ESP
implementations MUST remain interoperable with standard ESP implementations.
This document describes the minimal properties an ESP implementation needs to me
et to remain interoperable with <xref target="RFC4303"/> ESP.
In addition, this document also provides advise to implementers for implementing
ESP within constrained environments.
This document does not update or modify RFC 4303.</t>
<t> For each field of the ESP packet represented in <xref target="fig-esp-descri <t>For each field of the ESP packet represented in <xref target="fig-esp-descrip
ption"/> this document provides recommendations and guidance for minimal impleme tion" format="default"/>, this document provides recommendations and guidance fo
ntations. r minimal implementations.
The primary purpose of Minimal ESP is to remain interoperable with other nodes i The primary purpose of minimal ESP is to remain interoperable with other nodes i
mplementing RFC 4303 ESP, while limiting the standard complexity of the implemen mplementing ESP <xref target="RFC4303" format="default"/>, while limiting the st
tation. andard complexity of the implementation.
</t> </t>
<figure anchor="fig-esp-description" title="ESP Packet Description"> <figure anchor="fig-esp-description">
<artwork><![CDATA[ <name>ESP Packet Description</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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. | Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered | Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^ | Payload Data* (variable) | | ^
~ ~ | | ~ ~ | |
| | |Conf. | | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered* | | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v | | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) | | Integrity Check Value (ICV) (variable) |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</section>
</section> <section numbered="true" toc="default">
<name>Requirements Notation</name>
<section anchor="sec-spi" title="Security Parameter Index (SPI) (32 bit)"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<!-- what is the spi / definition --> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<t> <xref target="RFC4303"/> defines the SPI as a mandatory 32 bits field. </t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="sec-spi" numbered="true" toc="default">
<name>Security Parameters Index (SPI)</name>
<t> The SPI has a local significance to index the Security Association (SA). <t> <xref target="RFC4303" format="default"/> defines the SPI as a mandatory 32-
From <xref target="RFC4301"/> section 4.1, nodes supporting only unicast communi bit field. </t>
cations can index their SA using only the SPI.
Nodes supporting multicast communications also require to use the IP addresses a
nd thus SA lookup need to be performed using the longest match. </t>
<t> For nodes supporting only unicast communications, it is RECOMMENDED indexing <t> The SPI has local significance to index the Security Association (SA).
the SA using only the SPI. As described in <xref target="RFC4301" sectionFormat="of" section="4.1"/>, nodes
The index may be based on the full 32 bits of SPI or a subset of these bits. 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.
</t>
<t> For nodes supporting only unicast communications, indexing the SA usin
g only the SPI is <bcp14>RECOMMENDED</bcp14>.
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.</t> The node may require a combination of the SPI as well as other parameters (like the IP address) to index the SA.</t>
<t> Values 0-255 <bcp14>MUST NOT</bcp14> be used.
As per <xref target="RFC4303" sectionFormat="of" section="2.1"/>, values 1-255 a
re reserved, and 0 is only allowed to be used internally and <bcp14>MUST NOT</bc
p14> be sent over the wire. </t>
<t> Values 0-255 MUST NOT be used. <t> <xref target="RFC4303" format="default"/> does not require the 32-bit SPI to
As per section 2.1 of <xref target="RFC4303"/>, values 1-255 are reserved and 0 be randomly generated, although that is the <bcp14>RECOMMENDED</bcp14> way to g
is only allowed to be used internally and it MUST NOT be sent over the wire. </t enerate SPIs as it provides some privacy and security benefits and avoids correl
> ation between ESP communications.
To obtain a usable random 32-bit SPI, the node generates a random 32-bit value a
<!-- generation of the spi --> nd checks it does not fall within the 0-255 range.
<t> <xref target="RFC4303"/> does not require the 32 bit SPI to be randomly gene
rated, 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 a
nd 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. 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. Otherwise, the generated value is discarded, and the process repeats until a val id value is found.
</t> </t>
<t>Some constrained devices are less concerned with the privacy properties
<t>Some constrained devices are less concerned with the privacy properties assoc associated with randomly generated SPIs.
iated to randomly generated SPIs.
Examples of such devices might include sensors looking to reduce their code comp lexity. Examples of such devices might include sensors looking to reduce their code comp lexity.
The use of a predictive function to generate the SPI might be preferred over the generation and handling of random values. 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 fi xed value and the memory address of the SAD structure. An implementation of such predictable function could use the combination of a fi xed value and the memory address of the Security Association Database (SAD) stru cture.
For every incoming packet, the node will be able to point to the SAD structure d irectly from the SPI value. For every incoming packet, the node will be able to point to the SAD structure d irectly 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. This avoids having a separate and additional binding and lookup function for the SPI to its SAD entry for every incoming packet.
</t> </t>
<!-- privacy / security implication for non random SPIs --> <section numbered="true" toc="default">
<name>Considerations for SPI Generation</name>
<section title="Considerations over SPI generation"> <t>SPIs that are not randomly generated over 32 bits may have privacy an
d security concerns.
<t>SPIs that are not randomly generated over 32 bits may have privacy and securi
ty concerns.
As a result, the use of alternative designs requires careful security and privac y reviews. As a result, the use of alternative designs requires careful security and privac y reviews.
This section provides some considerations upon the adoption of alternative desig ns. </t> This section provides some considerations for the adoption of alternative design s. </t>
<t>The SPI value is only looked up for inbound traffic. <t>The SPI value is only looked up for inbound traffic.
The SPI negotiated with IKEv2 <xref target="RFC7296"/> or Minimal IKEv2 <xref ta The SPI negotiated with IKEv2 <xref target="RFC7296" format="default"/> or minim
rget="RFC7815"/> by a peer is the value used by the remote peer when it sends tr al IKEv2 <xref target="RFC7815" format="default"/> by a peer is the value used b
affic. y the remote peer when it sends traffic.
The main advantage of using a rekeying mechanism is to enable a rekey, that is p The main advantage of using a rekeying mechanism is to enable a rekey, which is
erformed by replacing an old SA by a new SA, both indexed with distinct SPIs. performed by replacing an old SA with a new SA, both indexed with distinct SPIs.
As the SPI is only used for inbound traffic by the peer, this allows each peer t The SPI is only used for inbound traffic by the peer, which allows each peer to
o manage the set of SPIs used for its inbound traffic. 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 ab The necessary number of SPIs reflects the number of inbound SAs as well as the a
ility to rekey these SAs. Typically, rekeying a SA is performed by creating a ne bility to rekey those SAs. Typically, rekeying an SA is performed by creating a
w SA (with a dedicated SPI) before the old SA is deleted. This results in an add new SA (with a dedicated SPI) before the old SA is deleted. This results in an a
itional SA and the need to support an additional SPI. dditional SA and the need to support an additional SPI.
Similarly, the privacy concerns associated with the generation of non-random SPI s is also limited to the incoming traffic. </t> Similarly, the privacy concerns associated with the generation of non-random SPI s is also limited to the incoming traffic. </t>
<!--Alternate designs that take less resources than fully random SPI's are likel
y using a limited list of possible SPIs.
This limit should take into account the number of inbound SAs - possibly per IP
addresses - as well as the requirement for rekeying which would briefly require
2 inbound SPIs to co-exist as the new SA is setup before the old SA is torn down
.
<t> <t>
Alternatively, some constrained devices will not implement IKEv2 or Minimal IKEv Alternatively, some constrained devices will not implement IKEv2 or minimal IKEv
2 and as such will not be able to manage a roll-over between two distinct SAs. I 2 and, as such, will not be able to manage a rollover between two distinct SAs.
n addition, some of these constrained devices are also likely to have a limited In addition, some of these constrained devices are likely to have a limited numb
number of SAs - likely to be indexed over 3 bytes only for example. One possible er of SAs; for example, they are likely to be indexed over 3 bytes only. One pos
way to enable a rekey mechanism with these devices is to use the SPI where for sible way to enable a rekeying mechanism with these devices is to use the SPI wh
example the first 3 bytes designates the SA while the remaining byte indicates a ere, for example, the first 3 bytes designates the SA while the remaining byte i
rekey index. ndicates a rekey index.
SPI numbers can be used to implement tracking the inbound SAs when rekeying is t SPI numbers can be used to implement tracking the inbound SAs when rekeying is t
aking place. When rekeying a SPI, the new SPI could use the SPI bytes to indicat aking place. When rekeying an SPI, the new SPI could use the SPI bytes to indica
e the rekeying index. te the rekeying index.
</t> </t>
<t>The use of a small limited set of SPI numbers across communications comes wit <t>The use of a small, limited set of SPI numbers across communications comes
h privacy and security concerns. with privacy and security concerns. Some specific values or subsets of SPI
Some specific values or subset of SPI values could reveal the models or manufact values could reveal the model or manufacturer of the node implementing ESP or
urer of the node implementing ESP. It could also reveal some state such as "not reveal a state such as "not yet rekeyed" or "rekeyed 10 times". If a
yet rekeyed" or "rekeyed 10 times". constrained host uses a very limited number of applications, eventually a
If a constrained host uses a very limited or even just one application, the SPI single one, the SPI itself could indicate what kind of traffic is transmitted
itself could indicate what kind of traffic (eg the kind of application typically (e.g., the kind of application typically running). This could also be
running) is transmitted. This could be further correlated by encrypted data siz correlated with encrypted data size to further leak information to an observer
e to further leak information to an observer on the network. on the network. In addition, use of specific hardcoded SPI numbers could
In addition, use of specific hardcoded SPI numbers could reveal a manufacturer o reveal a manufacturer or device version. If updated devices use different SPI
r device version. If updated devices use different SPI numbers, an attacker coul numbers, an attacker could locate vulnerable devices by their use of specific
d locate vulnerable devices by their use of specific SPI numbers. SPI numbers.
</t> </t>
<t> <t>
A privacy analysis should consider at least the type of information as well the A privacy analysis should consider at least the type of information as well as t
traffic pattern before deciding whether non-random SPIs are safe to use. he traffic pattern before deciding whether non-random SPIs are safe to use.
Typically temperature sensors, wind sensors, used outdoors may not leak privacy Typically, temperature and wind sensors that are used outdoors do not leak priva
sensitive information and most of its traffic is expected to be outbound traffic cy-sensitive information, and most of their traffic is expected to be outbound t
. raffic.
When used indoors, a sensor that reports an encrypted status of a door (closed o When used indoors, a sensor that reports an encrypted status of a door (closed o
r opened) every minute, might not leak sensitive information outside the local n r opened) every minute might not leak sensitive information outside the local ne
etwork. twork.
In these examples, the privacy aspect of the information itself might be limited 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 . 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 o of it may also have some limited security consequences. Of course, this depends
n the context these sensors are being used. If the risks associated to privacy a on the context in which these sensors are being used. If the risks associated to
nd security are acceptable, a non-randomized SPI can be used. privacy and security are acceptable, a non-randomized SPI can be used.
</t> </t>
</section>
</section>
<section anchor="sec-sn" numbered="true" toc="default">
<name>Sequence Number (SN)</name>
<t> The Sequence Number (SN) in <xref target="RFC4303" format="default"/>
is a mandatory 32-bit field in the packet. </t>
<t> 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 foll
owing: if packet B is sent after packet A, then the SN of packet B is higher tha
n the SN of packet A. </t>
<t>Some constrained devices may establish communication with specific devi
ces where it is known whether or not the peer implements anti-replay protection.
As per <xref target="RFC4303" format="default"/>, the sender <bcp14>MUST</bcp14>
still implement a strictly increasing function to generate the SN. </t>
</section> <t>
It is <bcp14>RECOMMENDED</bcp14> that multipurpose ESP implementations
</section> increment a counter for each packet sent. However, a constrained device may
avoid maintaining this context and use another source that is known to
<section anchor="sec-sn" title="Sequence Number(SN) (32 bit)"> always increase. Typically, constrained devices use 802.15.4 Time Slotted
Channel Hopping (TSCH). This communication is heavily dependent on time. A
<t> The Sequence Number (SN) in <xref target="RFC4303"/> is a mandatory 32 bits constrained device can take advantage of this clock mechanism to generate
field in the packet. </t> 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
<t> The SN is set by the sender so the receiver can implement anti-replay protec devices have separate hardware that allows them to wake up after a certain
tion. timeout and typically also have timers that start running when the device is
The SN is derived from any strictly increasing function that guarantees: if pack booted up, so they might have a concept of time with certain granularity.
et B is sent after packet A, then SN of packet B is higher than the SN of packet This requires devices to store any information in stable storage that can be
A. </t> restored across sleeps (e.g., flash memory). Storing information associated
with the SA (such as the SN) requires some read and write operations on
<t>Some constrained devices may establish communication with specific devices wh stable storage after each packet is sent as opposed to an SPI number or
ere it is known whether or not the peer implements anti-replay protection. cryptographic keys that are only written to stable storage at the creation
As per <xref target="RFC4303"/>, the sender MUST still implement a strictly incr of the SA. Write operations wear out the flash storage. Write operations
easing function to generate the SN. </t> 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
<t>The RECOMMENDED way for multipurpose ESP implementation is to increment a cou that might not be very accurate, they are good enough to guarantee that each
nter for each packet sent. time the device wakes up from sleep, the time is greater than what it was
However, a constrained device may avoid maintaining this context and use another before the device went to sleep. Using time for the SN would guarantee a
source that is known to always increase. strictly increasing function and avoid storing any additional values or
Typically, constrained devices use 802.15.4 Time Slotted Channel Hopping (TSCH). context related to the SN on flash. In addition to the time value, a
This communication is heavily dependent on time. RAM-based counter can be used to ensure that the serial numbers are still
A contrained device can take advantage of this clock mechanism to generate the S increasing and unique if the device sends multiple packets over an SA within
N. one wakeup period.
A lot of IoT devices are in a sleep state most of the time and wake up only to p
erform a specific operation before going back to sleep.
These devices do have separate hardware that allows them to wake up after a cert
ain timeout and typically also timers that start running when the device was boo
ted 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 memor
y - that can be restored across sleeps.
Storing information associated with the SA such as SN requires some read and wri
te operation on a stable storage after each packet is sent as opposed to a SPI n
umber or cryptographic keys that are only written to stable storage at the creat
ion 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 accura
te, these are good enough to guarantee that each time the device wakes up from s
leep that their 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 s
toring 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 if
the device sends multiple packets over an SA within one wake up period, that th
e serial numbers are still increasing and unique.
</t> </t>
<!-- <t>For inbound traffic, it is <bcp14>RECOMMENDED</bcp14> that receivers
implement anti-replay protection. The size of the window should depend on the
Note that standard receivers are generally configured with incrementing counters network characteristic to deliver packets out of order. In an environment
and, if not appropriately configured, the use of a significantly larger SN than where out-of-order packets are not possible, the window size can be set to
the previous packet can result in that packet falling outside of the peer's rec one. An ESP implementation may choose to not implement anti-replay
eiver window which could cause that packet to be discarded. </t> protection. An implementation of anti-replay protection may require the
device to write the received SN for every packet to stable storage. This will
As a result, using time based SN should only be used when it is known have the same issues as discussed earlier with the SN. Some constrained
that the remote peer supports this or when it is known that anti-replay device implementations may choose to not implement the optional anti-replay
windows are disabled.</t> protection. A typical example is an IoT device such as a temperature sensor
that sends a temperature measurement every 60 seconds and receives an
<t>For inbound traffic, it is RECOMMENDED that receivers implement anti-replay p acknowledgment from the receiver. In a case like this, the ability to spoof
rotection. and replay an acknowledgement is of limited interest and might not justify the
The size of the window should depend on the property of the network to deliver p implementation of an anti-replay mechanism. Receiving peers may also use an
ackets out of order. ESP anti-replay mechanism adapted to a specific application. Typically, when
In an environment where out of order packets are not possible, the window size c the sending peer is using an SN based on time, anti-replay may be implemented
an be set to one. by discarding any packets that present an SN whose value is too much in the
An ESP implementation may choose to not implement an anti-replay protection. past. Such mechanisms may consider clock drifting in various ways in addition
An implementation of anti-replay protection may require the device to write the to acceptable delay induced by the network to avoid the anti-replay windows
received SN for every packet to stable storage. rejecting legitimate packets. Receiving peers could accept any SN as long as it
This will have the same issues as discussed earlier with the SN. is higher
Some constrained device implementations may choose to not implement the optional than the previously received SN. Another mechanism could be used where only
anti-replay protection. the received time on the device is used to consider a packet to be valid,
A typical example might consider an IoT device such as a temperature sensor that without looking at the SN at all.
is sending a temperature measurement every 60 seconds, and that receives an ack
nowledgment 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-replay mechanism.
Receiving peers may also use ESP anti-replay mechanism adapted to a specific app
lication.
Typically, when the sending peer is using SN based on time, anti-replay may be i
mplemented by discarding any packets that present a SN whose value is too much i
n the past.
Such mechanisms may consider clock drifting in various ways in addition to accep
table delay induced by the network to avoid the anti replay windows rejecting le
gitimate packets.
It 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 us
ed to consider a packet as valid, without looking at the SN at all.
</t> </t>
<t>The SN can be represented as a 32 bit number, or as a 64 bit number, known as <t>The SN can be represented as a 32-bit number or as a 64-bit number, kno
Extended Sequence Number (ESN). wn as an "Extended Sequence Number (ESN)".
As per <xref target="RFC4303"/>, support of ESN is not mandatory and its use is As per <xref target="RFC4303" format="default"/>, support of ESN is not mandator
negotiated via IKEv2 <xref target="RFC7296"/>. y, and its use is negotiated via IKEv2 <xref target="RFC7296" format="default"/>
A 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. An ESN is used for high-speed links to ensure there can be more than 2<sup>32</s
up> packets before the SA needs to be rekeyed to prevent the SN from rolling ove
r.
This assumes the SN is incremented by 1 for each packet. This assumes the SN is incremented by 1 for each packet.
When the SN is incremented differently - such as when time is used - rekeying ne When the SN is incremented differently -- such as when time is used -- rekeying
eds to happen based on how the SN is incremented to prevent the SN from rolling needs to happen based on how the SN is incremented to prevent the SN from rollin
over. g over.
The security of all data protected under a given key decreases slightly with eac The security of all data protected under a given key decreases slightly with eac
h message and a node must ensure the limit is not reached - even though the SN w h message, and a node must ensure the limit is not reached, even though the SN w
ould permit it. ould permit it.
Estimation of the maximum number of packets to be sent by a node is not always p Estimation of the maximum number of packets to be sent by a node is not always p
redicatable and large margins should be used espcially as nodes could be online redictable, and large margins should be used, especially as nodes could be onlin
for much more time than expected. e for much more time than expected.
Even for constrained devices, it is RECOMMENDED to implement some rekey mechanis Even for constrained devices, it is <bcp14>RECOMMENDED</bcp14> to implement some
ms (see <xref target="sec-security-considerations"/>). rekeying mechanisms (see <xref target="sec-security-considerations" format="def
ault"/>).
</t> </t>
</section>
</section> <section anchor="sec-padding" numbered="true" toc="default">
<name>Padding</name>
<section anchor="sec-padding" title="Padding"> <t> Padding is required to keep the 32-bit alignment of ESP.
<t> Padding is required to keep the 32 bit alignment of ESP.
It is also required for some encryption transforms that need a specific block si ze of input, such as ENCR_AES_CBC. It is also required for some encryption transforms that need a specific block si ze of input, such as ENCR_AES_CBC.
ESP specifies padding in the Pad Length byte, followed by up to 255 bytes of pad ding. ESP specifies padding in the Pad Length byte, followed by up to 255 bytes of pad ding.
</t> </t>
<t> Checking the padding structure is not mandatory, so constrained device
<t> Checking the padding structure is not mandatory, so constrained devices may s may omit these checks on received ESP packets.
omit these checks on received ESP packets.
For outgoing ESP packets, padding must be applied as required by ESP. </t> For outgoing ESP packets, padding must be applied as required by ESP. </t>
<t> In some situation the padding bytes may take a fixed value. <t> In some situations, the padding bytes may take a fixed value.
This would typically be the case when the Data Payload is of fixed size. </t> This would typically be the case when the Payload Data is of fixed size. </t>
<t>ESP <xref target="RFC4303" format="default"/> additionally provides Tra
<t>ESP <xref target="RFC4303"/> additionally provides Traffic Flow Confidentiali ffic Flow Confidentiality (TFC) as a way to perform padding to hide traffic char
ty (TFC) as a way to perform padding to hide traffic characteristics. acteristics.
TFC is not mandatory and is negotiated with the SA management protocol, such as IKEv2. 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. TFC has been widely implemented, but it is not widely deployed for ESP traffic.
It is NOT RECOMMENDED to implement TFC for a minimal ESP. </t> It is <bcp14>NOT RECOMMENDED</bcp14> to implement TFC for minimal ESP. </t>
<t>As a consequence, communication protection that relies on TFC would be more s
ensitive to traffic patterns without TFC.
This can leak application information as well as the manifacturor or model of th
e device used to a passive monitoring attacker.
Such information can be used, for example, by an attacker in case a vulnerabilit
y is known for the specific device or application.
In addition, some application use - such as health applications - could leak imp
ortant privacy oriented information.</t>
<t>Constrained devices that have limited battery lifetime may prefer to avoid se <t>As a consequence, communication protection that relies on TFC would be more
nding extra padding bytes. 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.
</t>
<t>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 stan dard padding mechanism can be used as an alternative to TFC. In most cases, the payload carried by these devices is quite small, and the stan dard padding mechanism can be used as an alternative to TFC.
Alternatively, any information leak based on the size - or presence - of the pac Alternatively, any information leak based on the size -- or presence -- of the p
ket can also be addressed at the application level, before the packet is encrypt acket can also be addressed at the application level before the packet is encryp
ed with ESP. ted with ESP.
If application packets vary between 1 to 30 bytes, the application could always 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. 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 To prevent leaking information that a sensor changed state, such as "temperature
changed" or "door opened", an application could send this information at regula changed" or "door opened", an application could send this information at regula
r time interval, rather than when a specific event is happening, even if the sen r time intervals, rather than when a specific event is happening, even if the se
sor state did not change. nsor state did not change.
</t> </t>
</section> </section>
<section anchor="sec-nh" numbered="true" toc="default">
<section anchor="sec-nh" title="Next Header (8 bit) and Dummy Packets"> <name>Next Header and "Dummy" Packets</name>
<t>ESP <xref target="RFC4303" format="default"/> defines the Next Header a
<t>ESP <xref target="RFC4303"/> defines the Next Header as a mandatory 8 bits fi s a mandatory 8-bit field in the packet.
eld in the packet. The Next Header, only visible after decryption, specifies the data contained in
The Next header, only visible after decryption, specifies the data contained in the payload.
the payload. In addition, the Next Header may carry an indication on how to process the packe
In addition, the Next Header may also carry an indication on how to process the t <xref target="I-D.nikander-esp-beet-mode" format="default"/>.
packet <xref target="I-D.nikander-esp-beet-mode"/>. The Next Header can point to a "dummy" packet, i.e., a packet with the Next Head
The Next Header can point to a dummy packet, i.e. packets with the Next Header v er value set to 59, meaning "no next header".
alue set to 59 meaning "no next header". The data following "no next header" is unstructured "dummy" data. (Note that thi
The data following to "no next header" is unstructured dummy data. s document uses the term “dummy” for consistency with <xref target="RFC4303" for
mat="default"/>.)
</t> </t>
<t>The ability to generate, receive, and ignore "dummy" packets is require
<t>The ability to generate and to receive and ignore dummy packets is required b d by <xref target="RFC4303" format="default"/>.
y <xref target="RFC4303"/>. An implementation can omit ever generating and sending "dummy" packets.
An implementation can omit ever generating and sending dummy packets. For interoperability, a minimal ESP implementation <bcp14>MUST</bcp14> be able t
For interoperability, a minimal ESP implementation MUST be able to process and d o process and discard "dummy" packets without indicating an error.
iscard dummy packets without indicating an error.
</t> </t>
<t>
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.
<t> On the other hand, constrained devices running specific applications that would
In constrained environments, sending dummy packets may have too much impact on t leak too much information by not generating and sending "dummy" packets may impl
he device lifetime, in which case dummy packets should not be generated and sent ement 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 traffi
On the other hand, Constrained devices running specific applications that would c characteristics (see <xref target="sec-padding" format="default"/>), "dummy" p
leak too much information by not generating and sending dummy packets may implem ackets may also reveal some patterns that can be used to identify the applicatio
ent this functionality or even implement something similar at the application la n.
yer. For example, an application may send "dummy" data to hide a traffic pattern. Sup
Note also that similarly to padding and TFC that can be used to hide some traffi pose such an application sends a 1-byte data when a change occurs.
c characteristics (see <xref target="sec-padding"/>), dummy packet may also reve
al some patterns that can be used to identify the application.
For example, an application may send dummy data to hide some traffic pattern. Su
ppose such such application sends a 1 byte data when a change occurs.
This results in sending a packet notifying a change has occurred. This results in sending a packet notifying a change has occurred.
Dummy packet may be used to prevent such information to be leaked by sending a 1 "Dummy" packets may be used to prevent such information from being leaked by sen
byte packet every second when the information is not changed. ding a 1-byte packet every second when the information is not changed.
After an upgrade the data becomes two bytes. At that point, the dummy packets d After an upgrade, the data becomes 2 bytes. At that point, the "dummy" packets
o not hide anything and having 1 byte regularly versus 2 bytes make even the ide do not hide anything, and having 1 byte regularly versus 2 bytes makes even the
ntification of the application, version easier to identify. identification of the application version easier to identify.
This generaly makes the use of dummy packets more appropriated on high speed lin This generally makes the use of "dummy" packets more appropriate on high-speed l
ks. inks.
</t> </t>
<!--
Constrained devices running specific applications that would leak too much infor
mation by not generating and sending dummy packets could implement this function
ality instead at the application layer.
<t> In some cases, devices are dedicated to a single application or a single tra
nsport protocol, in which case, the Next Header has a fixed value.</t>
<t>Specific processing indications have not been standardized yet <xref target="
I-D.nikander-esp-beet-mode"/> and is expected to result from an agreement betwee
n the peers.
As a result, it SHOULD NOT be part of a minimal implementation of ESP. </t>
</section>
<section anchor="sec-icv" title="ICV">
<t>The ICV depends on the cryptographic suite used. <t> In some cases, devices are dedicated to a single application or a single tra
As detailed in <xref target="RFC8221"/> authentication or authenticated encrypti nsport protocol. In this case, the Next Header has a fixed value.</t>
on are RECOMMENDED and as such the ICV field must be present with a size differe <t>Specific processing indications have not been standardized yet <xref ta
nt from zero. rget="I-D.nikander-esp-beet-mode" format="default"/> and are expected to result
from an agreement between the peers.
As a result, they <bcp14>SHOULD NOT</bcp14> be part of a minimal implementation
of ESP. </t>
</section>
<section anchor="sec-icv" numbered="true" toc="default">
<name>ICV</name>
<t>The ICV depends on the cryptographic suite used.
As detailed in <xref target="RFC8221" format="default"/>, authentication or auth
enticated encryption is <bcp14>RECOMMENDED</bcp14>, and as such, the ICV field m
ust be present with a size different from zero.
Its length is defined by the security recommendations only. </t> Its length is defined by the security recommendations only. </t>
</section>
</section> <section anchor="sec-encr" numbered="true" toc="default">
<name>Cryptographic Suites</name>
<section anchor="sec-encr" title="Cryptographic Suites"> <t> The recommended algorithms to use are expected to evolve over time, an
d implementers <bcp14>SHOULD</bcp14> follow the recommendations provided by <xre
<t> The recommended algorithms to use are expected to evolve over time and imple f target="RFC8221" format="default"/> and updates.
menters SHOULD follow the recommendations provided by <xref target="RFC8221"/> a
nd updates.
</t>
<t> 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: </t>
<t><list style="numbers">
<t> Security: Security is the criteria that should be considered first for the s
election 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 reco
mmendations.
The chosen encryption algorithm MUST NOT be vulnerable or weak (see <xref target
="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 <xref target=
"RFC8221"/>.</t>
<t>Resilience to nonce re-use: Some transforms -including AES-GCM - are vulnerab
le to nonce collision with a given key.
While the generation of the nonce may prevent such collision during a session, t
he mechanisms are unlikely to provide such protection across sleep states or reb
oot.
This causes an issue for devices that are configured using static keys (called m
anual keying) and manual keying should not be used with these encryption algorit
hms.
When the key is likely to be re-used across reboots, algorithms that are nonce m
isuse resistant such as, for example, AES-SIV <xref target="RFC5297"/>, AES-GCM-
SIV <xref target="RFC8452"/> or Deoxys-II <xref target="DeoxysII"/> are RECOMMEN
DED.
Note however that currently none of these are yet defined for use with ESP.
</t>
<t> Interoperability: constrained devices usually only implement one or very few
different encryption algorithm transforms.
<xref target="RFC8221"/> takes the life cycle of encryption algorithm transforms
and device manufactoring into consideration in its recommendations for mandator
y-to-implement ("MTI") algorithms.
</t> </t>
<t> This section lists some of the criteria that may be considered to sele
ct an appropriate cryptographic suite.
The list is not expected to be exhaustive and may also evolve over time. </t>
<ol spacing="normal" type="1">
<t> Power Consumption and Cipher Suite Complexity: Complexity of the encryption <li>Security: Security is the criteria that should be considered first
algorithm transform and the energy cost associated with it are especially import for the selection of encryption algorithm transforms. The security of
ant considerations for devices that have limited resources or are battery powere encryption algorithm transforms is expected to evolve over time, and
d. it is of primary importance to follow up-to-date security guidance and
The battery life might determine the lifetime of the entire device. recommendations. The chosen encryption algorithm <bcp14>MUST
The choice of a cryptographic function should consider re-using specific librari NOT</bcp14> be vulnerable or weak (see <xref target="RFC8221"
es or to take advantage of hardware acceleration provided by the device. format="default"/> for outdated ciphers). ESP can be used to
For example, if the device benefits from AES hardware modules and uses ENCR_AES_ authenticate only (ENCR_NULL) or to encrypt the communication. In the
CTR, it may prefer AUTH_AES-XCBC for its authentication. latter case, Authenticated Encryption with Associated Data (AEAD) is
In addition, some devices may also embed radio modules with hardware acceleratio <bcp14>RECOMMENDED</bcp14> <xref target="RFC8221"
n for AES-CCM, in which case, this transform may be preferred.</t> format="default"/>.</li>
<t> Power Consumption and Bandwidth Consumption: Reducing the payload sent may s
ignificantly 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:
<list style="numbers">
<t> Use of counter-based ciphers without fixed block length (e.g. AES-CTR, or Ch
aCha20-Poly1305).</t>
<t>Use of ciphers with capability of using implicit IVs <xref target="RFC8750"/>
.</t>
<t>Use of ciphers recommended for IoT <xref target="RFC8221"/>.</t>
<t> Avoid Padding by sending payload data which are aligned to the cipher block
length - 2 for the ESP trailer.</t>
</list></t>
</list></t>
</section>
<section title="IANA Considerations">
<t>There are no IANA consideration for this document.</t>
</section>
<section anchor="sec-security-considerations" title="Security Considerations">
<t> Security Considerations are those of <xref target="RFC4303"/>. <li>Resilience to Nonce Reuse: Some transforms, including AES-GCM,
In addition, this document provided security recommendations and guidance over t are vulnerable to nonce collision with a given key. While the
he implementation choices for each ESP field. </t> 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 non
ce misuse
(for example, AES-SIV <xref target="RFC5297"
format="default"/>, AES-GCM-SIV <xref target="RFC8452"
format="default"/>, and Deoxys-II <xref target="DeoxysII"
format="default"/>) are <bcp14>RECOMMENDED</bcp14>. Note, however,
that none of these are currently defined for use with
ESP.</li>
<li>Interoperability: Constrained devices usually only implement one
or very few different encryption algorithm transforms. <xref
target="RFC8221" format="default"/> takes the life cycle of encryption
algorithm transforms and device manufacturing into consideration in
its recommendations for mandatory-to-implement (MTI)
algorithms.</li>
<t>The security of a communication provided by ESP is closely related to the sec <li>Power Consumption and Cipher Suite Complexity: Complexity of the
urity associated with the management of that key. 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 cons
idered. 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.</li>
<li><t>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:</t>
<ul spacing="normal">
<li>Use counter-based ciphers without fixed block length
(e.g., AES-CTR or ChaCha20-Poly1305).</li>
<li>Use ciphers capable of using implicit
Initialization Vectors (IVs) <xref target="RFC8750"
format="default"/>.</li>
<li>Use ciphers recommended for IoT <xref target="RFC8221"
format="default"/>.</li>
<li> Avoid padding by sending payload data that are
aligned to the cipher block length -- 2 bytes for the ESP trailer.</
li>
</ul>
</li>
</ol>
</section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="sec-security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t> The security considerations in <xref target="RFC4303" format="default"
/> apply to this document as well.
In addition, this document provides security recommendations and guidance for th
e implementation choices for each ESP field. </t>
<t>The security of a communication provided by ESP is closely related to t
he security associated with the management of that key.
This usually includes mechanisms to prevent a nonce from repeating, for example. 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 im plementer MUST ensure that the mechanisms put in place remain valid across reboo t as well. When a node is provisioned with a session key that is used across reboot, the im plementer <bcp14>MUST</bcp14> ensure that the mechanisms put in place remain val id across reboot as well.
</t> </t>
<t>It is <bcp14>RECOMMENDED</bcp14> to use ESP in conjunction with key man
agement protocols such as, for example, IKEv2 <xref target="RFC7296" format="def
ault"/> or minimal IKEv2 <xref target="RFC7815" format="default"/>.
Such mechanisms are responsible for negotiating fresh session keys as well as pr
eventing a session key being used beyond its lifetime.
<t>It is RECOMMENDED to use ESP in conjunction with key management protocols suc When such mechanisms cannot be implemented, such as when the session key is prov
h as for example IKEv2 <xref target="RFC7296"/> or minimal IKEv2 <xref target="R isioned, the device <bcp14>MUST</bcp14> ensure that keys are not used beyond the
FC7815"/>. ir lifetime and that the key remains used in compliance with all security requir
Such mechanisms are responsible for negotiating fresh session keys as well as pr ements across reboots (e.g., conditions on counters and nonces remain valid).
event a session key being use beyond its lifetime.
When such mechanisms cannot be implemented, such as when the the session key is
provisioned, the device MUST ensure that keys are not used beyond their lifetime
and that the the key remains used in compliance will all security requirements
across reboots - e.g. conditions on counters and nonces remains valid.
</t> </t>
<t>When a device generates its own key or when random values such as nonce
<t>When a device generates its own key or when random value such as nonces are g s are generated, the random generation <bcp14>MUST</bcp14> follow <xref target="
enerated, the random generation MUST follow <xref target="RFC4086"/>. RFC4086" format="default"/>.
In addition, <xref target="SP-800-90A-Rev-1"/> provides guidance on how to build In addition, <xref target="SP-800-90A-Rev-1" format="default"/> provides guidanc
random generators based on deterministic random functions. e on how to build random generators based on deterministic random functions.
</t> </t>
</section>
</section> <section anchor="sec-privacy-considerations" numbered="true" toc="default">
<name>Privacy Considerations</name>
<section anchor="sec-privacy-considerations" title="Privacy Considerations"> <t>Preventing the leakage of privacy-sensitive information is a hard probl
em to solve and usually results in balancing the information potentially being l
<t>Preventing the leakage of privacy sensitive information is a hard problem to eaked to the cost associated with the counter measures.
solve and usually result in balancing the information potentially being leaked t
o the cost associated with the counter measures.
This problem is not inherent to the minimal ESP described in this document and a lso concerns the use of ESP in general. </t> This problem is not inherent to the minimal ESP described in this document and a lso concerns the use of ESP in general. </t>
<t>This document targets minimal implementations of ESP and, as such, desc
ribes 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 t
he appropriate decisions given the specificities of a given environment and depl
oyment. </t>
<t>The main risk associated with privacy is the ability to identify an app
lication or a device by analyzing the traffic, which is designated as "traffic s
haping".
As discussed in <xref target="sec-spi" format="default"/>, the use in a very spe
cific 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 compar
ed to those provided by TFC. Such consequences on privacy are detailed in <xref
target="sec-padding" format="default"/>. </t>
</section>
</middle>
<back>
<t>This document targets minimal implementations of ESP and as such describes so <displayreference target="I-D.mglt-ipsecme-diet-esp" to="EHC-DIET-ESP"/>
me minimalistic way to implement ESP. <displayreference target="I-D.mglt-ipsecme-ikev2-diet-esp-extension" to="EHC-IKE
In some cases, this may result in potentially revealing privacy sensitive pieces v2"/>
of information. <displayreference target="I-D.nikander-esp-beet-mode" to="BEET-ESP"/>
This document describes these privacy implications so the implementer can take t
he appropriate decisions given the specificities of a given environment and depl
oyment. </t>
<t>The main risks associated with privacy is the ability to identify an applicat
ion or a device by analyzing the traffic which is designated as traffic shaping.
As discussed in <xref target="sec-spi"/>, the use in some very specific context
of non randomly generated SPI might in some cases ease the determination of the
device or the application.
Similarly, padding provides limited capabilities to obfuscate the traffic compar
ed to those provided by TFC. Such consequence on privacy as detailed in <xref ta
rget="sec-padding"/>. </t>
</section>
<section title="Acknowledgment">
<t> The authors would like to thank Daniel Palomares, Scott Fluhrer, Tero Kivine <references>
n, Valery Smyslov, Yoav Nir, Michael Richardson, Thomas Peyrin, Eric Thormarker, <name>References</name>
Nancy Cam-Winget and Bob Briscoe for their valuable comments. <references>
In particular Scott Fluhrer suggested including the rekey index in the SPI. <name>Normative References</name>
Tero Kivinen also provided multiple clarifications and examples of deployment ES <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
P within constrained devices with their associated optimizations. 119.xml"/>
Thomas Peyrin Eric Thormarker and Scott Fluhrer suggested and clarified the use <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
of transform resilient to nonce misuse. 086.xml"/>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
303.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
815.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
221.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
750.xml"/>
</references>
<references>
<name>Informative References</name>
</section> <!-- [draft-nikander-esp-beet-mode] IESG state Expired. -->
</middle> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-nikande r-esp-beet-mode.xml"/>
<back> <!-- [draft-mglt-ipsecme-diet-esp] IESG state I-D Exists. -->
<references title="Normative References"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-mglt-ip secme-diet-esp.xml"/>
<?rfc include="reference.RFC.2119.xml"?> <!-- [draft-mglt-ipsecme-ikev2-diet-esp-extension] IESG state I-D Exists. -->
<!--<?rfc include="reference.RFC.3602.xml"?>-->
<!--<?rfc include="reference.RFC.3686.xml"?>-->
<!--<?rfc include="reference.RFC.4106.xml"?>-->
<?rfc include="reference.RFC.4086.xml"?>
<?rfc include="reference.RFC.4301.xml"?>
<?rfc include="reference.RFC.4303.xml"?>
<!--<?rfc include="reference.RFC.4309.xml"?>-->
<?rfc include="reference.RFC.7296.xml"?>
<?rfc include="reference.RFC.7815.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.8221.xml"?>
<!--<?rfc include="reference.RFC.8247.xml"?>-->
<?rfc include="reference.RFC.8750.xml"?>
</references> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-mglt-ip secme-ikev2-diet-esp-extension.xml"/>
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
452.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
297.xml"/>
<?rfc include="reference.I-D.nikander-esp-beet-mode.xml"?> <reference anchor="SP-800-90A-Rev-1" target="https://csrc.nist.gov/publi
<?rfc include="reference.I-D.mglt-ipsecme-diet-esp.xml"?> cations/detail/sp/800-90a/rev-1/final">
<?rfc include="reference.I-D.mglt-ipsecme-ikev2-diet-esp-extension.xml"?> <front>
<?rfc include="reference.RFC.8452.xml"?> <title>Recommendation for Random Number Generation Using Determinist
<?rfc include="reference.RFC.5297.xml"?> ic Random Bit Generators</title>
<reference anchor="SP-800-90A-Rev-1" target="https://csrc.nist.gov/publications/ <author initials="E." surname="Barker" fullname="Elaine Barker">
detail/sp/800-90a/rev-1/final"> <organization>NIST</organization>
<front>
<title>Recommendation for Random Number Generation Using Deterministic Rando
m Bit Generators</title>
<author initials="E. B." surname="Elain" fullname="Elaine Barker">
<organization >NIST</organization>
</author> </author>
<author initials="J. K." surname="Kelsey" fullname="John Kelsey"> <author initials="J." surname="Kelsey" fullname="John Kelsey">
<organization >NIST</organization> <organization>NIST</organization>
</author> </author>
<date month="" year="" /> <date month="June" year="2015"/>
</front>
</front> <seriesInfo name="NIST SP" value="800-90A Rev 1"/>
</reference> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-90Ar1"/>
</reference>
<reference anchor="DeoxysII" target="https://competitions.cr.yp.to/round3/deoxys <reference anchor="DeoxysII" target="https://competitions.cr.yp.to/round
v141.pdf"> 3/deoxysv141.pdf">
<front> <front>
<title>Deoxys v1.41</title> <title>Deoxys v1.41</title>
<author initials="J. J." surname="Jeremy" fullname="Jeremy Jean"> <author initials="J." surname="Jean" fullname="Jérémy Jean">
<organization >Nanyang Technological University, Singapore</orga <organization>ANSSI, Paris, France `&amp;' Nanyang Technological U
nization> niversity, Singapore</organization>
</author> </author>
<author initials="I. N." surname="Ivica" fullname="Ivica Nikolic"> <author initials="I." surname="Nikolić" fullname="Ivica Nikolić">
<organization >Nanyang Technological University, Singapore</orga <organization>Nanyang Technological University, Singapore</organiz
nization> ation>
</author> </author>
<author initials="T. P." surname="Thomas" fullname="Thomas Peyrin"> <author initials="T." surname="Peyrin" fullname="Thomas Peyrin">
<organization >Nanyang Technological University, Singapore</orga <organization>Nanyang Technological University, Singapore</organiz
nization> ation>
</author> </author>
<author initials="Y. S." surname="Yannick" fullname="Yannick Seurin"> <author initials="Y." surname="Seurin" fullname="Yannick Seurin">
<organization >ANSSI, Paris, France</organization> <organization>ANSSI, Paris, France</organization>
</author> </author>
<date month="October" year="2016"/>
<date month="October" year="2016" /> </front>
</front> </reference>
</references>
</reference> </references>
<section numbered="false" toc="default">
</references> <name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Daniel
Palomares"/>, <contact fullname="Scott Fluhrer"/>, <contact
fullname="Tero Kivinen"/>, <contact fullname="Valery Smyslov"/>,
<contact fullname="Yoav Nir"/>, <contact fullname="Michael
Richardson"/>, <contact fullname="Thomas Peyrin"/>, <contact
fullname="Eric Thormarker"/>, <contact fullname="Nancy Cam-Winget"/>, and
<contact fullname="Bob Briscoe"/> for their valuable comments. In
particular, <contact fullname="Scott Fluhrer"/> suggested including the
rekey index in the SPI. <contact fullname="Tero Kivinen"/> also
provided multiple clarifications and examples of ESP deployment within
constrained devices with their associated optimizations.
<contact fullname="Thomas Peyrin"/>, <contact fullname="Eric Thormarker"/>, and
<contact fullname="Scott Fluhrer"/> suggested and clarified the use of
transform resilient to nonce misuse. The authors would also like to thank <conta
ct fullname="Mohit Sethi"/> for his support as the LWIG Working Group Chair.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 74 change blocks. 
597 lines changed or deleted 568 lines changed or added

This html diff was produced by rfcdiff 1.48.