On Thu, May 2, 2024 at 2:28 AM Murray Kucherawy via Datatracker < nore...@ietf.org> wrote:
> > I realize there's terminology imported from elsewhere, but it would be > helpful > (and cheap) to expand things like "SA" on first use anyway. > Done > In Section 6, "it is there for" should be "it is therefore". > Fixed. > In Section 3: > > The SA_RESOURCE_INFO notify payload MAY > be empty or MAY contain some identifying data. This identifying data > SHOULD be a unique identifier within all the Child SAs with the same > TS payloads and the peer MUST only use it for debugging purposes. > > So it MAY be empty; if it's not empty, it SHOULD be unique, and it MUST > only be > used for debugging. Two things are odd about this: > > (a) What if it's not unique? What's the interoperability benefit to > uniqueness? (i.e., why is this "SHOULD"?) > I will charge you everyime I am debugging this and finding out you are confusing me with non-unique SA identifiers. I will also be very sad. Don't make me sad. > (b) The MUST doesn't seem to have anything to do with interoperability. > > Lastly, a minor point but I found this peculiar. Section 5 contains two > instances of: > > * SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0. > > Is this reserved for future use? Otherwise, I don't know why this isn't > just > "MUST be 0" or "ignored; assume 0 always". > Notify payloads are defined in RFC7296. Notifies related to IKE have no (child) protocol or SPI associated with them. For example, to delete a specific Child SA, the Delete notify has protocol (eg ESP) and SPI (eg 0x3332543543) so those can be passed to the kernel for finding and deleting. Paul
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
