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