Minimal ESPEricsson8400 boulevard DecarieMontreal, QC H4P 2N2Canadadaniel.migault@ericsson.comLMU MunichMNM-TeamOettingenstr. 6780538 MunichBavariaGermanyguggemos@mnm-team.org
INTERNET
Light-Weight Implementation Guidance (lwig)This document describes a minimal implementation of the IP
Encapsulation Security Payload (ESP) defined in RFC 4303. Its purpose is
to enable implementation of ESP with a minimal set of options to remain
compatible with ESP as described in RFC 4303. A minimal version of ESP
is not intended to become a replacement of the RFC 4303 ESP, but instead
to enable a limited implementation to interoperate with implementations
of RFC 4303 ESP. This document describes what is required from RFC 4303 ESP as well
as various ways to optimize compliance with RFC 4303 ESP. This document does not update or modify RFC 4303, but provides a
compact description of how to implement the minimal version of the
protocol. If this document and RFC 4303 conflicts then RFC 4303 is the
authoritative description. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
ESP is part of the IPsec suite protocol
. 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. describes an ESP Packet.
Currently ESP is implemented in the kernel of major multi purpose
Operating Systems (OS). The ESP and IPsec suite is usually implemented
in a complete way to fit multiple purpose usage of these OS. However,
completeness of the IPsec suite as well as multi purpose scope of these
OS is often performed at the expense of resources, or a lack of
performance. As a result, constraint devices are likely to have their
own implementation of ESP optimized and adapted to their specificities.
With the adoption of IPsec by IoT devices with minimal IKEv2 and ESP Header Compression (EHC) with or , it becomes crucial
that ESP implementation designed for constraint devices remain
inter-operable with the standard ESP implementation to avoid a
fragmented usage of ESP. This document describes the the minimal
properties and ESP implementation needs to meet. For each field of the ESP packet represented in 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.
According to the , the SPI is a mandatory 32
bits field and is not allowed to be removed. The SPI has a local significance to index the Security Association
(SA). From section 4.1, nodes supporting only
unicast communications can index their SA only using the SPI. On the
other hand, nodes supporting multicast communications must also use the
IP addresses and thus SA lookup needs to be performed using the longest
match. For nodes supporting only unicast communications, it is RECOMMENDED
to index SA with the SPI only. Some other local constraints on the node
may require a combination of the SPI as well as other parameters to
index the SA. It is RECOMMENDED to randomly generate the SPI indexing each inbound
session. A random generation provides a stateless way to generate the
SPIs, while keeping the probability of collision between SPIs relatively
low. In case of collision, the SPI is simply re-generated. However, for some constraint nodes, generating a random SPI may
consume to much resource, in which case SPI can be generated using
predictable functions or even a fix value. In fact, the SPI does not
need to be random. Generating non random SPI MAY lead to privacy and
security concerns. As a result, this alternative should be considered
for devices that would be strongly impacted by the generation of a
random SPI and after understanding the privacy and security impact of
generating non random SPI. When a constraint node uses fix value for SPIs, it imposes some
limitations on the number of inbound SA. This limitation can be
alleviate by how the SA look up is performed. When fix SPI are used, it
is RECOMMENDED the constraint node has as many SPI values as ESP session
per host IP address, and that SA lookup includes the IP addresses. Note that SPI value is used only for inbound traffic, as such the
SPI negotiated with IKEv2 or by a peer, is the value used by the remote peer when
its sends traffic. As SPI are only used for inbound traffic by the peer,
this allows each peer to manage the set of SPIs used for its inbound
traffic. The use of fix SPI MUST NOT be considered as a way to avoid strong
random generators. Such generator will be required in order to provide
strong cryptographic protection and follow the randomness requirements
for security described in . Instead, the use of
a fix SPI should only considered as a way to overcome the resource
limitations of the node, when this is feasible. The use of a limited number of fix SPI or non random SPIs come with
security or privacy drawbacks. Typically, a passive attacker may derive
information such as the number of constraint devices connecting the
remote peer, and in conjunction with data rate, the attacker may
eventually determine the application the constraint device is associated
to. If the SPI is fixed by a manufacturer or by some software
application, the SPI may leak in an obvious way the type of sensor, the
application involved or the model of the constraint device. When
identification of the application or the hardware is associated to
privacy, the SPI MUST be randomly generated. However, one needs to
realize that in this case this is likely to be sufficient and a
thorough privacy analysis is required. More specifically, traffic
pattern MAY leak sufficient information in itself. In other words,
privacy leakage is a complex and the use of random SPI is unlikely to be
sufficient.As the general recommendation is to randomly generate the SPI,
constraint device that will use a limited number of fix SPI are expected
to be very constraint devices with very limited capabilities, where the
use of randomly generated SPI may prevent them to implement IPsec. In
this case the ability to provision non random SPI enables these devices
to secure their communications. These devices, due to there limitations,
are expected to provide limited information and how the use of non random
SPI impacts privacy requires further analysis. Typically temperature
sensors, wind sensors, used outdoor do not leak privacy sensitive
information. When used indoor, the privacy information is stored in the
encrypted data and as such does not leak privacy.As far as security is concerned, revealing the type of application
or model of the constraint device could be used to identify the
vulnerabilities the constraint device is subject to. This is especially
sensitive for constraint devices where patches or software updates will
be challenging to operate. As a result, these devices may remain
vulnerable for relatively long period. In addition, predictable SPI
enable an attacker to forge packets with a valid SPI. Such packet will
not be rejected due to an SPI mismatch, but instead after the signature
check which requires more resource and thus make DoS more efficient,
especially for devices powered by batteries. Values 0-255 SHOULD NOT be used. Values 1-255 are reserved and 0 is
only allowed to be used internal and it MUST NOT be send on the wire.
mentions : "The SPI is an arbitrary 32-bit value that is used by a receiver to
identify the SA to which an incoming packet is bound. The SPI field is
mandatory. [...]" "For a unicast SA, the SPI can be used by itself to specify an SA,
or it may be used in conjunction with the IPsec protocol type (in this
case ESP). Because the SPI value is generated by the receiver for a
unicast SA, whether the value is sufficient to identify an SA by itself
or whether it must be used in conjunction with the IPsec protocol value
is a local matter. This mechanism for mapping inbound traffic to unicast
SAs MUST be supported by all ESP implementations." According to , the Sequence Number (SN) 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 then the SN of packet A. Some constraint devices may establish communication with specific
devices, like a specific gateway, or nodes similar to them. As a result,
the sender may know whereas the receiver implements anti-replay
protection or not. Even though the sender may know the receiver does not
implement anti replay protection, the sender MUST implement a always
increasing function to generate the SN. Usually, SN is generated by incrementing a counter for each packet
sent. A constraint device may avoid maintaining this context and use
another source that is known to always increase. Typically, constraint
nodes using 802.15.4 Time Slotted Channel Hopping (TSCH), whose
communication is heavily dependent on time, can take advantage of their
clock to generate the SN. This would guarantee a strictly increasing
function, and avoid storing any additional values or context related to
the SN. When the use of a clock is considered, one should take care that
packets associated to a given SA are not sent with the same time value.
For inbound traffic, it is RECOMMENDED to provide a anti-replay
protection,and the size of the window depends on the ability of the
network to deliver packet out of order. As a result, in environment
where out of order packets is not possible the window size can be set to
one. However, while RECOMMENDED, there is no requirements to implement
an anti replay protection mechanism implemented by IPsec. A node MAY
drop anti-replay protection provided by IPsec, and instead implement its
own internal mechanism. mentions : "This unsigned 32-bit field contains a counter value that increases
by one for each packet sent, i.e., a per-SA packet sequence number. For
a unicast SA or a single-sender multicast SA, the sender MUST increment
this field for every transmitted packet. Sharing an SA among multiple
senders is permitted, though generally not recommended. [...] The field
is mandatory and MUST always be present even if the receiver does not
elect to enable the anti-replay service for a specific SA." The purpose of padding is to respect the 32 bit alignment of ESP.
ESP MUST have at least one padding byte Pad Length that indicates the
padding length. ESP padding bytes are generated by a succession of
unsigned bytes starting with 1, 2, 3 with the last byte set to Pad
Length, where Pad Length designates the length of the padding bytes.
Checking the padding structure is not mandatory, so the constraint
device may not proceed to such checks, however, in order to interoperate
with existing ESP implementations, it MUST build the padding bytes as
recommended by ESP. In some situation the padding bytes may take a fix value. This would
typically be the case when the Data Payload is of fix size. mentions :"If Padding bytes are needed but the encryption algorithm does not
specify the padding contents, then the following default processing MUST
be used. The Padding bytes are initialized with a series of (unsigned,
1-byte) integer values. The first padding byte appended to the plaintext
is numbered 1, with subsequent padding bytes making up a monotonically
increasing sequence: 1, 2, 3, .... When this padding scheme is employed,
the receiver SHOULD inspect the Padding field. (This scheme was selected
because of its relative simplicity, ease of implementation in hardware,
and because it offers limited protection against certain forms of "cut
and paste" attacks in the absence of other integrity measures, if the
receiver checks the padding values upon decryption.)"ESP also provides Traffic Flow
Confidentiality (TFC) as a way to perform padding to hide traffic
characteristics, which differs from respecting a 32 bit alignment. TFC
is not mandatory and MUST be negotiated with the SA management protocol.
TFC has not yet being widely adopted 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 is likely to
require extra processing as well as providing a "well recognized"
traffic shape which could end up being counterproductive. As such TFC
is not expected to be supported by a minimal ESP implementation.As a result, TFC cannot not be enabled with minimal, and
communication protection that were relying on TFC will be more sensitive
to traffic shaping. This could expose the application as well as the
devices used to a passive monitoring attacker. Such information could be
used by the attacker in case a vulnerability is disclosed on the
specific device. In addition, some application use - such as health
applications - may also reveal important privacy oriented
informations.Some constraint nodes that have limited battery life time may also
prefer avoiding 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 is quite small, and the
standard padding mechanism may also be used as an alternative to TFC,
with a sufficient trade off between the require energy to send
additional payload and the exposure to traffic shaping attacks. In
addition, the information leaked by the traffic shaping may also be
addressed by the application level. For example, it is preferred to have
a sensor sending some information at regular time interval, rather when
an specific event is happening. Typically a 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. According to , the Next Header is a mandatory
8 bits field in the packet. Next header is intended to specify the data
contained in the payload as well as dummy packet. In addition, the Next
Header may also carry an indication on how to process the packet . The ability to generate and receive dummy packet is required by
. For interoperability, it is RECOMMENDED a
minimal ESP implementation discards dummy packets. Note that such
recommendation only applies for nodes receiving packets, and that nodes
designed to only send data may 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. More especially, in constraint environment
sending dummy packets may have too much impact on the device life time,
and so may be avoided. On the other hand, constraint nodes may be
dedicated to specific applications, in which case, traffic pattern may
expose the application or the type of node. For these nodes, not sending
dummy packet may have some privacy implication that needs to be
measured. However, for the same reasons exposed in traffic shaping at the IPsec layer may also
introduce some traffic pattern, and on constraint devices the
application is probably the most appropriated layer to limit the risk of
leaking information by traffic shaping. In some cases, devices are dedicated to a single application or a
single transport protocol, in which case, the Next Header has a fix
value.Specific processing indications have not been standardized yet and is expected to result from an
agreement between the peers. As a result, it is not expected to be part
of a minimal implementation of ESP. mentions : "The Next Header is a mandatory, 8-bit field that identifies the type
of data contained in the Payload Data field, e.g., an IPv4 or IPv6
packet, or a next layer header and data. [...] the protocol value 59
(which means "no next header") MUST be used to designate a "dummy"
packet. A transmitter MUST be capable of generating dummy packets
marked with this value in the next protocol field, and a receiver MUST
be prepared to discard such packets, without indicating an error."The ICV depends on the crypto-suite used. Currently recommended
only recommend crypto-suites with an ICV which
makes the ICV a mandatory field. As detailed in we recommend to use
authentication, the ICV field is expected to be present that is to say
with a size different from zero. This makes it a mandatory field which
size is defined by the security recommendations only. mentions :"The Integrity Check Value is a variable-length field computed over
the ESP header, Payload, and ESP trailer fields. Implicit ESP trailer
fields (integrity padding and high-order ESN bits, if applicable) are
included in the ICV computation. The ICV field is optional. It is
present only if the integrity service is selected and is provided by
either a separate integrity algorithm or a combined mode algorithm that
uses an ICV. The length of the field is specified by the integrity
algorithm selected and associated with the SA. The integrity algorithm
specification MUST specify the length of the ICV and the comparison
rules and processing steps for validation." The cryptographic suites implemented are an important component of
ESP. The recommended suites to use are expect to evolve over time and
implementer SHOULD follow the recommendations provided by and updates. Recommendations are provided for
standard nodes as well as constraint nodes. This section lists some of the criteria that may be considered. The
list is not expected to be exhaustive and may also evolve overtime. As a
result, the list is provided as indicative: Security: Security is the criteria that should be considered first
for the selection of cipher suites. The security of cipher suites is
expected to evolve over time, and it is of primary importance to follow
up-to-date security guidances and recommendations. The chosen cipher
suites MUST NOT be known vulnerable or weak (see for outdated ciphers). ESP can be used to
authenticate only or to encrypt the communication. In the later case,
authenticated encryption must always be considered . Interoperability: Interoperability considers the cipher suites
shared with the other nodes. Note that it is not because a cipher suite
is widely deployed that is secured. As a result, security SHOULD NOT be
weaken for interoperability. and successors
consider the life cycle of cipher suites sufficiently long to provide
interoperability. Constraint devices may have limited interoperability
requirements which makes possible to reduces the number of cipher suites
to implement. Power Consumption and Cipher Suite Complexity: Complexity of the
cipher suite or the energy associated to it are especially considered
when devices have limited resources or are using some batteries, in
which case the battery determines the life of the device. The choice of
a cryptographic function may 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, it may prefer 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 may be preferred. Power Consumption and Bandwidth Consumption: Similarly to the cipher
suite complexity, reducing the payload sent, may significantly reduce
the energy consumption of the device. As a result, cipher suites with
low overhead may be considered. To reduce the overall payload size one
may for example:
Use of counter-based ciphers without fixed block length (e.g.
AES-CTR, or ChaCha20-Poly1305).Use of ciphers with capability of using implicit IVs .Use of ciphers recommended for IoT . Avoid Padding by sending payload data which are aligned to the
cipher block length - 2 for the ESP trailer.There are no IANA consideration for this document. Security considerations are those of . In
addition, this document provided security recommendations an guidances
over the implementation choices for each fields. The authors would like to thank Daniel Palomares, Scott Fluhrer,
Tero Kivinen, Valery Smyslov, Yoav Nir, Michael Richardson for their
valuable comments.
[RFC Editor: This section is to be removed before publication]
-00: First version published.
-01: Clarified description
-02: Clarified description