[Lwip] Éric Vyncke's No Objection on draft-ietf-lwig-minimal-esp-08: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Mon, 04 April 2022 08:06 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: lwip@ietf.org
Delivered-To: lwip@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D07163A1F7C; Mon, 4 Apr 2022 01:06:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lwig-minimal-esp@ietf.org, lwig-chairs@ietf.org, lwip@ietf.org, mohit.m.sethi@ericsson.com, mohit.m.sethi@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <164905961681.6351.3328842176658363565@ietfa.amsl.com>
Date: Mon, 04 Apr 2022 01:06:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/nUy5UVoGc4j23-y7kb6Fwgup_MQ>
Subject: [Lwip] Éric Vyncke's No Objection on draft-ietf-lwig-minimal-esp-08: (with COMMENT)
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Apr 2022 08:06:59 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-lwig-minimal-esp-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Mohit Sethi for the shepherd's write-up including the
difficulties to reach WG consensus, I only regret the absence of justification
for the intended status.

I hope that this helps to improve the document,

Regards,

-éric

## Section 2

"SA lookup needs to be performed using the longest match", I will let the SEC
ADs to raise this point if required, but my understanding of IPsec is that it
is not a "longest match" but a "full match on IP SA & SPI".

"the combination of a fixed value and the memory address of the SAD structure",
should the 'fixed value' be changed on every reboot/reset of the IPsec code ?

Please expand "SAD" on first use.

## Section 2.1

The first paragraphs indicate that local SPI is for inbound traffic, but the
last paragraph appears to be about outbound traffic from sensors. Unsure how to
reconciliate the two parts of this section.

Probably just editorial in this informational document, but I wonder how to
reconciliate the two proposed alternatives for SPI generation:

- section 2 use a 'low grade' random SPI

- section 2.1 use a combo of SAD + rekey index

## Section 3

When using time for sequence number (I like the idea BTW), what measures should
be taken to handle the 32-bit rollover ?

Unsure whether I agree with the text around disabling anti-reply even for a IoT
device, especially for actuators. The text has
  "These resources need also to balance that absence of anti-replay mechanism,
   may lead to unnecessary integrity check operations that might be
   significantly more expensive as well."

which appears too lenient IMHO.

# NITS

s/32 bits field/32-bit field/

## Section 2

s/ valueand checks/ value and checks/