Re: [IPsec] [Editorial Errata Reported] RFC7296 (6940)

[Tero Kivinen <[e-mail]>]

黯乡魂 writes:
> If the Protocol ID field of the notification is zero, how to tell it is
> concerning the IKE SA or none of any SA?

We do not have any notifications concerning IKE SA that would require
SPI to be transmitted in the SPI field. As the RFC7296 says:

       	  Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS, REKEY_SA, and
      CHILD_SA_NOT_FOUND.

and in all those cases the SPI is of SA concerning ESP or AH. The type
of notify will specify whether the notification payload is related to
the IKE SA or something else, and if it is related to the IKE SA the
SPIs can be found from the generic header, and are not repeated inside
the notification payload. I.e., the notifications for IKE SA are
transmitted inside the IKE SA that they belong to.

> I notice that RFC4306 section 3.10 gives a clear description:
> 
> "For IKE_SA notifications, this field MUST be one (1). For notifications
> concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3)
> to indicate ESP. For notifications that do not relate to an existing SA, this
> field MUST be sent as zero and MUST be ignored on receipt. All other values
> for this field are reserved to IANA for future assignment. "

This was not clear, and because of this in the RFC4718 (IKEv2
Clarifications and Implementation Guidelines) we had section 7.8 to
clarify this:

7.8.  Protocol ID/SPI Fields in Notify Payloads

   Section 3.10 says that the Protocol ID field in Notify payloads "For
   notifications that do not relate to an existing SA, this field MUST
   be sent as zero and MUST be ignored on receipt".  However, the
   specification does not clearly say which notifications are related to
   existing SAs and which are not.

   Since the main purpose of the Protocol ID field is to specify the
   type of the SPI, our interpretation is that the Protocol ID field
   should be non-zero only when the SPI field is non-empty.

   There are currently only two notifications where this is the case:
   INVALID_SELECTORS and REKEY_SA.

and then when we revised the RFC4306 to RFC5996 and then to RFC7296 we
incorporated this change to the main RFC. The current text is clear,
the protocol id is always zero if the SPI field is empty, the protocol
id only identifies the type of SPI inside the SPI field, the meaning
of the notification payload can be seen from the notify message type
field.

> 
> ------------------ Original ------------------
> From: "Tero Kivinen" <[e-mail]>;
> Date: Fri, Apr 22, 2022 03:55 PM
> To: "RFC Errata System"<[e-mail]>;
> Cc: "黯乡魂"<[e-mail]>;"charliekaufman"<[e-mail]>;
> "paul.hoffman"<[e-mail]>;"nir.ietf"<[e-mail]>;"pe"
> <[e-mail]>;"ipsec"<[e-mail]>;
> Subject: [Editorial Errata Reported] RFC7296 (6940)
> 
> RFC Errata System writes:
> > The following errata report has been submitted for RFC7296,
> > "Internet Key Exchange Protocol Version 2 (IKEv2)".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6940
> >
> > --------------------------------------
> > Type: Editorial
> > Reported by: warren.wang <[e-mail]>
> >
> > Section: 3.10
> >
> > Original Text
> > -------------
> > o SPI Size (1 octet) - Length in octets of the SPI as defined by the
> >  IPsec protocol ID or zero if no SPI is applicable. For a
> >  notification concerning the IKE SA, the SPI Size MUST be zero and
> >  the field must be empty.
> >
> >
> > Corrected Text
> > --------------
> > o SPI Size (1 octet) - Length in octets of the SPI as defined by the
> >  IPsec protocol ID or zero if no SPI is applicable. For a
> >  notification concerning the IKE SA, the SPI Size MUST be zero and
> >  the SPI field must be empty.
> >
> >
> > Notes
> > -----
> > the field must be empty -> the SPI field must be empty
> 
> This change is correct, and the errata can be verified.
> 
> > so for a notification concerning the IKE SA, the Protocol ID field
> > still shall be zero?(According to the last sentence of Protocol ID
> > section:"If the SPI field is empty, this field MUST be sent as zero
> > and MUST be ignored on receipt".)
> 
> Yes. For IKE SA notifications the SPI can be seen from the header,
> thus there is no point of repeating the SPIs in notify payload. The
> Protocol ID field of the notification payload indicates which type of
> SPI is inside the notification payload, thus if there is no SPI in
> there, then there is no point of having Protocol ID either.
> 
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party 
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
> > --------------------------------------
> > Title               : Internet Key Exchange Protocol Version 2 (IKEv2)
> > Publication Date    : October 2014
> > Author(s)           : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
> > Category            : INTERNET STANDARD
> > Source              : IP Security Maintenance and Extensions
> > Area                : Security
> > Stream              : IETF
> > Verifying Party     : IESG
> 
> --
> [e-mail]

-- 
[e-mail]