draft-ietf-lwig-minimal-esp-06.txt   draft-ietf-lwig-minimal-esp-07.txt 
Light-Weight Implementation Guidance (lwig) D.M. Migault Light-Weight Implementation Guidance (lwig) D.M. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T.G. Guggemos Intended status: Informational T.G. Guggemos
Expires: 27 January 2022 LMU Munich Expires: 1 April 2022 LMU Munich
26 July 2021 28 September 2021
Minimal ESP Minimal ESP
draft-ietf-lwig-minimal-esp-06 draft-ietf-lwig-minimal-esp-07
Abstract Abstract
This document describes a minimal implementation of the IP This document describes a minimal IP Encapsulation Security Payload
Encapsulation Security Payload (ESP) defined in RFC 4303. Its (ESP) defined in RFC 4303. Its purpose is to enable implementation
purpose is to enable implementation of ESP with a minimal set of of ESP with a minimal set of options to remain compatible with ESP as
options to remain compatible with ESP as described in RFC 4303. A described in RFC 4303. A minimal version of ESP is not intended to
minimal version of ESP is not intended to become a replacement of the become a replacement of the RFC 4303 ESP. Instead, a minimal
RFC 4303 ESP. Instead, a minimal implementation is expected to be implementation is expected to be optimized for constrained
optimized for constrained environment while remaining interoperable environment while remaining interoperable with implementations of RFC
with implementations of RFC 4303 ESP. Some constraints include 4303 ESP. In addition, this document also provides some
limiting the number of flash writes, handling frequent wakeup / sleep considerations to implement minimal ESP in a constrained environment
states, limiting wakeup time, or reducing the use of random which includes limiting the number of flash writes, handling frequent
generation. wakeup / sleep states, limiting wakeup time, or reducing the use of
random generation.
This document does not update or modify RFC 4303, but provides a This document does not update or modify RFC 4303, but provides a
compact description of how to implement the minimal version of the compact description of how to implement the minimal version of the
protocol. RFC 4303 remains the authoritative description. protocol. RFC 4303 remains the authoritative description.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 January 2022. This Internet-Draft will expire on 1 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 14 skipping to change at page 4, line 14
The SPI has a local significance to index the Security Association The SPI has a local significance to index the Security Association
(SA). From [RFC4301] section 4.1, nodes supporting only unicast (SA). From [RFC4301] section 4.1, nodes supporting only unicast
communications can index their SA only using the SPI. On the other communications can index their SA only using the SPI. On the other
hand, nodes supporting multicast communications must also use the IP hand, nodes supporting multicast communications must also use the IP
addresses and thus SA lookup needs to be performed using the longest addresses and thus SA lookup needs to be performed using the longest
match. match.
For nodes supporting only unicast communications, it is recommended For nodes supporting only unicast communications, it is recommended
to index SA with the SPI only. The index may be based on the full 32 to index SA with the SPI only. The index may be based on the full 32
bits of SPI or a subset of these bits. Some other local constraints bits of SPI or a subset of these bits. The node may require a
on the node may require a combination of the SPI as well as other combination of the SPI as well as other parameters (like the IP
parameters to index the SA. address) to index the SA.
Values 0-255 must not be used. As per section 2.1 of [RFC4303], Values 0-255 must not be used. As per section 2.1 of [RFC4303],
values 1-255 are reserved and 0 is only allowed to be used internally values 1-255 are reserved and 0 is only allowed to be used internally
and it must not be sent on the wire. and it must not be sent on the wire.
[RFC4303] does not require the SPI to be randomly generated over 32 [RFC4303] does not require the SPI to be randomly generated over 32
bits. However, this is the recommended way to generate SPIs as it bits. However, this is the recommended way to generate SPIs as it
provides some privacy benefits and avoids, for example, correlation provides some privacy benefits and avoids, for example, correlation
between ESP communications. To randomly generate a 32 bit SPI, the between ESP communications. To randomly generate a 32 bit SPI, the
node generates a random 32 bit valueand checks it does not fall in node generates a random 32 bit valueand checks it does not fall in
skipping to change at page 5, line 32 skipping to change at page 5, line 32
observer is likely to be able to determine the constrained devices of observer is likely to be able to determine the constrained devices of
the network. In some cases, these nodes may host a very limited the network. In some cases, these nodes may host a very limited
number of applications - typically a single application - in which number of applications - typically a single application - in which
case the SPI would provide some information related to the case the SPI would provide some information related to the
application of the user. In addition, the device or application may application of the user. In addition, the device or application may
be associated with some vulnerabilities, in which case specific SPI be associated with some vulnerabilities, in which case specific SPI
values may be used by an attacker to discover vulnerabilities. values may be used by an attacker to discover vulnerabilities.
While the use of randomly generated SPIs may reduce the leakage or While the use of randomly generated SPIs may reduce the leakage or
privacy of security related information by ESP itself, these privacy of security related information by ESP itself, these
information may also be leaked otherwise and a privacy analysis information may also be leaked otherwise. As a result, a privacy
should consider at least the type of information as well the traffic analysis should consider at least the type of information as well the
pattern. Typically, temperature sensors, wind sensors, used outdoors traffic pattern before determining non random SPI can be used.
do not leak privacy sensitive information and mosty of its traffic is Typically, temperature sensors, wind sensors, used outdoors do not
leak privacy sensitive information and mosty of its traffic is
expected to be outbound traffic. When used indoors, a sensor that expected to be outbound traffic. When used indoors, a sensor that
reports every minute an encrypted status of the door (closed or reports every minute an encrypted status of the door (closed or
opened) leaks truly little privacy sensitive information outside the opened) leaks truly little privacy sensitive information outside the
local network. local network.
3. Sequence Number(SN) (32 bit) 3. Sequence Number(SN) (32 bit)
According to [RFC4303], the Sequence Number (SN) is a mandatory 32 According to [RFC4303], the Sequence Number (SN) is a mandatory 32
bits field in the packet. bits field in the packet.
 End of changes. 6 change blocks. 
22 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/