RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 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
Date Edited: 2022-06-13

Section .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

additional question: so for a notification concerning the IKE SA, the Protocol ID field still shall be zero?

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.

Status: Held for Document Update (4)

RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014

Source of RFC: ipsecme (sec)

Errata ID: 5056
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Michael Taylor
Date Reported: 2017-06-29
Held for Document Update by: Paul Wouters
Date Held: 2022-04-11

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.

Paul Wouters:

This comment is about the use of the word "proposal" which I agree is open to wrong interpretation. My suggestion would be:

Current:

Implementations that conform to this document MUST
ignore proposals that have configuration attribute type 5, the old
value for INTERNAL_ADDRESS_EXPIRY

Proposed:

Implementations that conform to this document MUST
process configuration attribute value 5 similar to
any other unknown Attribute Type.

It is mostly obvious that only the attribute type should be ignored, not the entire proposal. Therefor Held for Document update as it does not affect implementations but the wording should be improved in future versions of the document

Errata ID: 4387
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Yoav Nir
Date Reported: 2015-06-04
Held for Document Update by: Stephen Farrell
Date Held: 2015-06-04

Section 3.7 says:

   The Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.

It should say:

   The Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_SA_INIT response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.

Notes:

IKE_SA_INIT is mis-spelled as IKE_INIT_SA this one time.

Errata ID: 5247
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Andrew Cagney
Date Reported: 2018-01-30
Held for Document Update by: Paul Wouters
Date Held: 2022-04-11

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.

Paul Wouters:

This is about name for Protocol ID 0 to be seen as "NONE", versus giving it a better name. While I agree with the poster the writing could be improved, this change is not required for implementing the RFC. Thus moved to Held for Document Update where this text can then be improved upon.

Errata ID: 6779
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: warren.wang
Date Reported: 2021-12-08
Held for Document Update by: Benjamin Kaduk
Date Held: 2021-12-11

Section 1.1.1 says:

   In this scenario, neither endpoint of the IP connection implements
   IPsec, but network nodes between them protect traffic for part of the
   way.  Protection is transparent to the endpoints, and depends on
   ordinary routing to send packets through the tunnel endpoints for
   processing.  Each endpoint would announce the set of addresses
   "behind" it, and packets would be sent in tunnel mode where the inner
   IP header would contain the IP addresses of the actual endpoints.

It should say:

   In this scenario, neither endpoint of the IP connection implements
   IPsec, but network nodes between them protect traffic for part of the
   way.  Protection is transparent to the endpoints, and depends on
   ordinary routing to send packets through the tunnel endpoints for
   processing.  Each tunnel endpoint would announce the set of addresses
   "behind" it, and packets would be sent in tunnel mode where the inner
   IP header would contain the IP addresses of the actual endpoints.

Notes:

"Each tunnel endpoint" will make it easy to understand which entity is announcing the set of addresses.

Status: Rejected (1)

RFC 7296, "Internet Key Exchange Protocol Version 2 (IKEv2)", October 2014

Source of RFC: ipsecme (sec)

Errata ID: 4930
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2017-02-08
Rejected by: Paul Wouters
Date Rejected: 2022-04-11

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).
--VERIFIER NOTES--
The text is fine and clear as is.

Report New Errata



Advanced Search