Subject: [IPsec] [Errata Held for Document Update] RFC7296 (5056)

From: RFC Errata System <[email-masked]>
Date: Sun, 10 Apr 2022 17:06:13 -0700 (PDT)

The following errata report has been held for document update 
for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5056

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Michael Taylor <[email-masked]>
Date Reported: 2017-06-29
Held by: Paul Wouters (IESG)

Section: 1.7

Original Text
-------------
   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 

Corrected Text
--------------
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

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