RFC Errata
Found 4 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 (3)
RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014
Source of RFC: ipsecme (sec)
Errata ID: 5056
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Taylor
Date Reported: 2017-06-29
Section 1.7 says:
This document removes discussion of the INTERNAL_ADDRESS_EXPIRY configuration attribute because its implementation was very problematic. Implementations that conform to this document MUST ignore proposals that have configuration attribute type 5, the old value for INTERNAL_ADDRESS_EXPIRY
It should say:
Unclear what it should be
Notes:
Configuration attribute 5, INTERNAL_ADDRESS_EXPIRY, is a type of attribute in a configuration payload. It is not an attribute in a proposal. As documented in Section 2.7 proposals are part of an SA payload.
An SA payload consists of one or more proposals. Each proposal
includes one protocol. Each protocol contains one or more transforms
-- each specifying a cryptographic algorithm. Each transform
contains zero or more attributes (attributes are needed only if the
Transform ID does not completely specify the cryptographic
algorithm).
So the correct behavior when one receives a *configuration* payload with INTERNAL_ADDRESS_EXPIRY cannot be to ignore a proposal. Was the intent to say that the configuration payload should be ignored? Was the intent to say that the configuration payload should be processed but the INTERNAL_ADDRESS_EXPIRY attribute ignored? Clearly these choices would result in radically different outcomes for the negotiation.
Errata ID: 4930
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2017-02-08
Section 3.16 says:
Note that since IKE passes an indication of initiator identity in the first message in the IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity requests. The initiator MAY, however, respond to such requests if it receives them.
Notes:
The last sentence of this section contains unnecessary repetition written above (the last sentence in description of Type field).
Errata ID: 5247
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Andrew Cagney
Date Reported: 2018-01-30
Section 3.10. says:
o Protocol ID (1 octet) - If this notification concerns an existing
SA whose SPI is given in the SPI field, this field indicates the
type of that SA. For notifications concerning Child SAs, this
field MUST contain either (2) to indicate AH or (3) to indicate
ESP. Of the notifications defined in this document, the SPI is
included only with INVALID_SELECTORS, REKEY_SA, and
CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be
sent as zero and MUST be ignored on receipt.
It should say:
o Protocol ID (1 octet) - If this notification concerns an existing
SA whose SPI is given in the SPI field, this field indicates the
type of that SA. For notifications concerning Child SAs, this
field MUST contain either (2) to indicate AH or (3) to indicate
ESP. Of the notifications defined in this document, the SPI is
included only with INVALID_SELECTORS, REKEY_SA, and
CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be
sent as zero to indicate NONE and MUST be ignored on receipt.
Notes:
If I assume that the 'Protocol ID' field in the notification payload is specified by:
Internet Key Exchange Version 2 (IKEv2) Parameters
IKEv2 Security Protocol Identifiers
then a notification is using the 'Reserved' value 0. Since the value is being used,
I think it would be better to give it a name. Other uses of 'Protocol ID' don't need
updating as they all explicitly list allowed values, and in no case is 0 allowed.