黯乡魂 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" <kivi...@iki.fi>; > Date: Fri, Apr 22, 2022 03:55 PM > To: "RFC Errata System"<rfc-edi...@rfc-editor.org>; > Cc: "黯乡魂"<648936...@qq.com>;"charliekaufman"<charliekauf...@outlook.com>; > "paul.hoffman"<paul.hoff...@vpnc.org>;"nir.ietf"<nir.i...@gmail.com>;"pe" > <p...@iki.fi>;"ipsec"<ipsec@ietf.org>; > 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 <648936...@qq.com> > > > > 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 > > -- > kivi...@iki.fi -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec