RFC Errata
Found 2 records.
Status: Verified (1)
RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014
Source of RFC: ipsecme (sec)
Errata ID: 6667
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Qingyuan Gu
Date Reported: 2021-08-30
Verifier Name: Benjamin Kaduk
Date Verified: 2021-09-01
Section 3.3 says:
the different groups. For example, to propose ESP with (3DES or AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and two Transform Type 3 candidates (one for HMAC_MD5 and one for HMAC_SHA).
It should say:
the different groups. For example, to propose ESP with (3DES or AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for AES-CBC) and two Transform Type 3 candidates (one for HMAC_MD5 and one for HMAC_SHA).
Notes:
"AES" is misspelled as "AEC".
Status: Reported (1)
RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014
Source of RFC: ipsecme (sec)
Errata ID: 6940
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: warren.wang
Date Reported: 2022-04-21
Section 3.10 says:
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.
It should say:
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
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".)