Subject: [IPsec] [Technical Errata Reported] RFC7296 (5056)

From: RFC Errata System <[email-masked]>
Date: Thu, 29 Jun 2017 09:17:18 -0700 (PDT)

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

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

--------------------------------------
Type: Technical
Reported by: Michael Taylor <[email-masked]>

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.

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Jun 2017 17:10:59 +0300

RFC Errata System writes:
> 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. 

"proposal" in this context has normal meaning. The SA payload contains
Proposals (note capital P), i.e., the payload and substructures in
payloads are identified by the capital initial letter. Configuration
payloads of type CFG_REQUEST can be seen as being proposal (normal
English meaning). We do similar thing with Traffic Selectors (see
section 2.9, which do talk about propsals, but does not talk about
Proposals).

Also this text is from the RFC 5996, and it is from the section where
RFC 5996 talks about changes between RFC 4306 and RFC 5996.

I do not think there is any way to misunderstand that text, and we are
talking about the feature which was removed from the specification 7
years ago...

Check the RFC4718 Section 6.7 about the discussion about the
INTERNAL_ADDRESS_EXPIRY and why it was removed.

>    Transform ID does not completely specify the cryptographic

This is true, but this is not the only place where we can have
proposal. It is the only place where we have Proposal substructures...

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

The correct behavior is to ignore the INTERNAL_ADDRESS_EXPIRY
Configuration Attribute, and act as if it does not exists, just like
it should ignore all configuration payload types it does not know:

>From 3.15.1:

   	  	     Unrecognized or unsupported attributes
   MUST be ignored in both requests and responses.

I.e., as there is no Configuration type number 5 anymore, complient
implementations should simply skip over that attribute.

The text was there in RFC5996 for those old implementation which might
still implement INTERNAL_ADDRESS_EXPIRY, and it mandates them to
remove the code handling INTERNAL_ADDRESS_EXPIRY, as there is no
longer such configuration attribute type.
-- 
[email-masked]