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 <paul.wout...@aiven.io> 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 <p...@nohats.ca> > To: Daniel Migault <mglt.i...@gmail.com> > 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
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
