Hi, Thank you for the comments. Please find an updated version of the minimal ESP implementation with all comment received. We believed we addressed them all.
We believe the draft had sufficient reviews for adoption in LWIG. The diff with the old version can be found here: https://www.ietf.org/rfcdiff?url2=draft-mglt-lwig-minimal-esp-05 Please find a detailed description of the comment addressed: - A) Clarifying the purpose of a minimal implementation (Tero, Scott) - B) SPI: (Scott, Daniel) - C) Padding: (Scott, Yoav and Tero) - D) Next Header: (Scott, Tero) - E) ICV (Valery, other people in the WG) Comments are always welcome, please find a detailed description of the update. Yours, Daniel A) Clarifying the purpose of a minimal implementation: Comments from Tero and Scott: The scope of the minimal version should be clarified, so the reader is not upset some options are missing. We believe the current text address this purpose: """ This document describes a minimal implementation of the IP Encapsulation Security Payload (ESP) described in RFC 4303. Its purpose is to enable implementation of ESP with a minimal set of options that makes the minimal implementation 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 primary purpose of Minimal ESP is to remain interoperable with other nodes implementing RFC 4303 ESP, while limiting the standard complexity of the implementation. """ B) SPI: Comment from Scott, Daniel The text in draft version 04 represented what has been discussed on the ML. We included some recommendation on how to index the SA with the SPI. We also presented different lookups for anycast and multicast nodes. The draft details how to avoid generating random SPI, and instead use fix SPI. We added some text to avoid the current explanation as being interpreted as there is no need for random generators. """ The use of fix SPI should not be considered as a way to avoid strong random generators. Such generator will be required in order to provide strong cryptographic protection. 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. """ C) Padding: Comment from Scott, Yoav and Tero The current Padding section has been consequently updated. - Padding has been mentioned as mandatory - TFC has been mentioned as not being implemented in a minimal version. """ 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. """ The following text has been added regarding TFC: """ ESP <<RFC4303>> 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. As a result, TFC is not expected to be supported by a minimal ESP implementation. On the other hand, disabling TFC should be carefully measured and understood as it exposes the node 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. """ D) Next Header: Comments from Scott, Tero The Next Header section has been updated by specifying better position the minimal implementation regarding the dummy packet as well as the BEET mode. The ability to reject dummy packet has been added as being mandatory for a minimal implementation. The following text has been added: According to <<RFC4303>>, 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 <<I-D.nikander-esp-beet-mode>>. The ability to generate and receive dummy packet is required by <<RFC4303>>. 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. 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 <<I-D.nikander-esp-beet-mode>> 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. E) ICV Comment from Valery, other people in the WG The previous text gave the impression that the ICV was optional. I believe the following text clarifies the concern. """ The ICV depends on the crypto-suite used. Currently recommended <<I-D.ietf-ipsecme-rfc7321bis>> only recommend crypto-suites with an ICV which makes the ICV a mandatory field. """ -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, May 16, 2017 3:54 PM To: Tobias Guggemos <[email protected]>; Daniel Migault <[email protected]> Subject: New Version Notification for draft-mglt-lwig-minimal-esp-05.txt A new version of I-D, draft-mglt-lwig-minimal-esp-05.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-lwig-minimal-esp Revision: 05 Title: Minimal ESP Document date: 2017-05-15 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-05.txt Status: https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/ Htmlized: https://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-lwig-minimal-esp-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-lwig-minimal-esp-05 Abstract: This document describes a minimal implementation of the IP Encapsulation Security Payload (ESP) described in RFC 4303. Its purpose is to enable implementation of ESP with a minimal set of options that makes the minimal implementation 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. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
