Subject: [Lwip] Martin Duke's No Objection on draft-ietf-lwig-minimal-esp-08: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 04 Apr 2022 10:42:22 -0700

Martin Duke 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:
----------------------------------------------------------------------

Thanks to Bob Briscoe for the TSVART review.

Sec 2.1. I find it odd that a node implementing IPSec is overburdened by
generating a random number, but this is not my domain.

Sec 3. Bob and the authors had an interesting discussion on time-based SN and
replay windows. It seems to me that the best way to do this would be for the
receiver to keep a replay window of some number of packets rather than SNs. The
receiver would then store the last, say, 10 packet SNs regardless of how many
SNs that covered. This would avoid all the issues with the sender skipping many
SNs.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 5 Apr 2022 22:06:38 -0400

Hi Martin,

Thanks for the review, please find my comment below.

Yours,
Daniel

On Mon, Apr 4, 2022 at 1:42 PM Martin Duke via Datatracker <[email-masked]>
wrote:

> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

This is the other way around: even a node that is unable to generate values
can protect its communication with IPsec.

Sec 3. Bob and the authors had an interesting discussion on time-based SN
> and
> The use of time provided the advantage of not maintaining states for every
packet. Keeping that 10 packet state ends up in maintaining state for every
packet sent/received. It could be useful if state maintenance is not an
issue for that node which connects nodes with state constraints.

>
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>

-- 
Daniel Migault
Ericsson