Re: [Lwip] [IPsec] Paul Wouters' Discuss on draft-ietf-lwig-minimal-esp-08: (with DISCUSS and COMMENT)

[Daniel Migault <[e-mail]>]

Hi Paul,

Looking at the history, my latest comments were sent on april 25, and
following your email of may 24, I published the version 11 [1] that
reflected the april changes. (This version should have been published
earlier but was stalled into the data tracker.) So considering the latest
version published, please see my response inline to your comments.

[1] https://www.ietf.org/archive/id/draft-ietf-lwig-minimal-esp-11.txt

Yours,
Daniel


On Mon, Jul 18, 2022 at 3:31 PM Paul Wouters <[e-mail]> wrote:

> On Mon, 18 Jul 2022, Daniel Migault wrote:
>
> > My reading of the datatracker is that the document in IESG
> Evaluation::AD Followup for 117 days. I do not see any follow-up with the
> following email from
> > may 25 with the latest changes and believe all concerns have been
> addressed. I am wondering what prevents the document from being sent to the
> RFC queue
> > and if there is anything expected from my side.
>
> See my last email to you:
>
>         Date: Tue, 24 May 2022 11:27:28
>         From: Paul Wouters <[e-mail]>
>         To: Daniel Migault <[e-mail]>
>         Subject: draft-ietf-lwig-minimal-esp
>
>
>         Hi Daniel,
>
>         Just a reminder that draft-ietf-lwig-minimal-esp is waiting on
> actions
>         on your end to resolve the DISCUSS items. While discussing in
> github is
>         useful, in the end the changes do need to go into a new draft
> version
>         for the DISCUSS holders to evaluate them.
>
>         I think the biggest unresolved issue is the SPI one with using
> just a
>         few bytes and the "indexing" that I still do not understand.
>
>         Paul
>
>
> The limited SPI numbers and rekeying is still not clear to me.
> We exchanged a few emails but that did not result in me understanding
> this.
>

I am happy to understand what is unclear. I suppose the text you are
referring to is the one below - extracted from version 11.

   Alternatively, some constrained devices will not implement IKEv2 or
   Minimal IKEv2 and as such will not be able to manage a roll-over
   between two distinct SAs.  In addition, some of these constrained
   devices are also likely to have a limited number of SAs - likely to
   be indexed over 3 bytes only for example.  One possible way to enable
   a rekey mechanism with these devices is to use the SPI where for
   example the first 3 bytes designates the SA while the remaining byte
   indicates a rekey index.  SPI numbers can be used to implement
   tracking the inbound SAs when rekeying is taking place.  When
   rekeying a SPI, the new SPI could use the SPI bytes to indicate the
   rekeying index.


> The sequence number discussion mentions the issue of packets falling
> out of the receive window. We talked about an IKE option/notify to
> signal this and during that discussion it also came to light that this
> protocol is going to be used without IKEv2. This leaves an
> interoprability unaddressed.
>
>

I do not see any mention of IKE option and SN, but maybe you can refresh my
memory. The only IKE option discussion I recall of is an option you propose
to request the other peer not to send dummy packets - which is primarily
out of scope of minimal esp and whose usefulness remains to be proven.



> And since this protocol is also meant to run without IKEv2, there is
> an issue of only recommending AEAD algorithms that rely on IKEv2 for
> its security properties.
>

I do not see the issue associated with AEAD, so can you be a bit more
explicit. I do not see what is being provisioned via IKE that cannot be
provisioned via other means.
In addition, I do not see this as an issue if we were mandating AEAD. This
is not the case. The document recommends the use of AEAD  as a general
purpose. I think this is relevant and does not prevent specific cases of
not using AEAD. What text would you like to see ?


> Section 6 talks about Dummy packets but the labeling of the header
> is a bit misleading into thinking the Next Header behaviour is
> modified. I had suggested the section to be renamed.
>
>
The current title is "6. Next Header (8 bit) and Dummy Packets". The
section has been renamed, and I do not see what more needs to be done.


> > Please find my response to your comments. The current version of the
> file integrates the language changes as well as changes to address the
> concerns
> > of this thread:
> >
> >
> https://github.com/mglt/draft-mglt-lwig-minimal-esp/commit/d7710c19802bdce4c978d71ad303b739e1406f1e
>
> We ended up discussing this in email, but that did not end in my
> understanding. Also, the above commit did not actually make it
> into the draft yet. It is very hard as AD to keep track of changes
> that are not in the actual datatracker.
>

The changes have been implemented here:
 https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/


> Paul



-- 
Daniel Migault
Ericsson