An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)
draft-nir-ipsecme-erx-11

[Ballot discuss]
Consistent with my Discuss position on draft-ietf-tcpm-initcwnd,
I object to an Experimental document listing itself as updating
a PS document.

I realize there are precedents for Experimental docs updating PS
docs.  However, in this case, I would be happier with "is an experiment
based on" metadata.  Lacking that option, I would like to see
the "Updates" metadata dropped from this document.  And,
of course, if the experiment is successful and a PS spec
based on this doc is published, it would update RFC 5996.

[Ballot comment]
Not my area of expertise, so I'm going to simply not object on the document itself. However, please take a look at the below and fix.

There are 6 occurrences of MUST per 2119. 5 of them seem obviously wrong:

Section 3:

  The IDi payload MUST have ID Type ID_RFC822_ADDR and the data field
  MUST contain the same value as the KeyName-NAI TLV in the
  EAP_Initiate/Re-auth message.
 
Section 4:

  o  Protocol ID (1 octet) MUST be zero, as this message is related to
      an IKE SA.
  o  SPI Size (1 octet) MUST be zero, in conformance with section 3.10
      of RFC 5996.
  o  ERX Notify Message Type (2 octets) - MUST be xxxxx, the value
      assigned for ERX.  TBA by IANA.

Ask yourself in each case: What would happen if an implementation chose not to do what you say is something that they MUST do? If the answer is, "They wouldn't be implementing the protocol", then the MUST is not being used correctly; you should instead use "will". If the answer is, "They would be implementing the protocol if they did something different, but they fail to interoperate", then the MUST would be correct. In each of the 5 cases above, I cannot figure out how the MUST is justified.

The only other MUST is in section 3.1:

  Section 3.16 of RFC 5996 enumerates the EAP codes in EAP messages
  which are carried in EAP payloads.  The enumeration goes only to 4.
  It is not clear whether that list is supposed to be exhaustive or
  not.

  To clarify, an implementation conforming to this specification MUST
  accept and transmit EAP messages with at least the codes for Initiate
  and Finish (5 and 6) from RFC 6696, in addition to the four codes
  enumerated in RFC 5996.

Here, the MUST would be appropriate if you are changing 5996, but if so, you have worded this poorly: Change "an implementation conforming to this specification" to "an implementation of IKEv2". You are saying that *any* IKEv2 EAP implementation MUST handle all 6. If you are not saying that, then the MUST is wrong and should be changed to "will".

[Ballot comment]
Not my area of expertise, so I'm going to simply not object on the document itself. However, please take a look at the below and fix.

There are 6 occurrences of MUST per 2119. 5 of them seem obviously wrong:

Section 3:

  The IDi payload MUST have ID Type ID_RFC822_ADDR and the data field
  MUST contain the same value as the KeyName-NAI TLV in the
  EAP_Initiate/Re-auth message.
 
Section 4:

  o  Protocol ID (1 octet) MUST be zero, as this message is related to
      an IKE SA.
  o  SPI Size (1 octet) MUST be zero, in conformance with section 3.10
      of RFC 5996.
  o  ERX Notify Message Type (2 octets) - MUST be xxxxx, the value
      assigned for ERX.  TBA by IANA.

Ask yourself in each case: What would happen if an implementation chose not to do what you say is something that the MUST do? If the answer is, "They wouldn't be implementing the protocol", then the MUST is not being used correctly; you should instead use "will". If the answer is, "They would be implementing the protocol if they did something different, but they fail to interoperate", then the MUST would be correct. In each of the 5 cases above, I cannot figure out how the MUST is justified.

The only other MUST is in section 3.1:

  Section 3.16 of RFC 5996 enumerates the EAP codes in EAP messages
  which are carried in EAP payloads.  The enumeration goes only to 4.
  It is not clear whether that list is supposed to be exhaustive or
  not.

  To clarify, an implementation conforming to this specification MUST
  accept and transmit EAP messages with at least the codes for Initiate
  and Finish (5 and 6) from RFC 6696, in addition to the four codes
  enumerated in RFC 5996.

Here, the MUST would be appropriate if you are changing 5996, but if so, you have worded this poorly: Change "an implementation conforming to this specification" to "an implementation of IKEv2". You are saying that *any* IKEv2 EAP implementation MUST handle all 6. If you are not saying that, then the MUST is wrong and should be changed to "will".

For the record, I screwed up.  I forgot that this draft had already been through IETF LC once and there was no need to redo IETF LC.  I asked the IESG Secretary to retract the 2nd IETF LC and they did so.  Sorry for any confusion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (An IKEv2 Extension for Supporting ERP) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'An IKEv2 Extension for Supporting ERP'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document updates the IKEv2 protocol, described in RFC 5996.
  This extension allows an IKE Security Association (SA) to be created
  and authenticated using the EAP Re-authentication Protocol extension
  as described in RFC 6696.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ballot/


No IPR declarations have been submitted directly on this I-D.

IANA has reviewed draft-nir-ipsecme-erx-07 and has the following comments:

IANA understands that, upon approval of this document, there is a single
action which IANA must complete.

In the IKEv2 Notify Message Types - Status Types subregistry of the Internet Key
Exchange Version 2 (IKEv2) Parameters registry located at:

http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xml

IANA will assign a new IKEv2 notify message type as follows:

Value: [ tbd ]
NOTIFY MESSAGES - STATUS TYPES: ERX_SUPPORTED
Reference: [ RFC-to-be ]

IANA understands that, upon approval of this document, this is
the only IANA action required to be completed.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (An IKEv2 Extension for Supporting ERP) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'An IKEv2 Extension for Supporting ERP'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document updates the IKEv2 protocol, described in RFC 5996.
  This extension allows an IKE Security Association (SA) to be created
  and authenticated using the EAP Re-authentication Protocol extension
  as described in RFC 6696.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Shepherd Writeup

Document: draft-nir-ipsecme-erx-07

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

Experimental RFC. This is appropriate since the proposed protocol has
not been implemented yet.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This document describes an extension to the IKEv2 protocol that allows
an IKE Security Association (SA) to be created and authenticated using
the EAP Re-authentication Protocol extension (ERP, RFC 6696).

Working Group Summary:

This is not the product of any working group.

Document Quality:

There are no known implementations of the protocol, nor are we aware of
vendor plans in this regard. The document has been lightly reviewed by
both the HOKEY and the IPsecME working groups.

Personnel:

Yaron Sheffer is the document shepherd. Sean Turner is the responsible
AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

The document shepherd has read the document thoroughly, as well as
several previous versions.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I have previously indicated to the authors that the level of review this
document has seen does not warrant publication in the Standards Track.
Indeed they have now chosen to publish it as Experimental.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

As noted, the documented has seen some limited review in the HOKEY group
(AAA) and in the IPsecME group (security).

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No such issues.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, both authors confirmed so. No such disclosures are required.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No such disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

This is not a WG document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No such issues.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The automated tool produces 2 comments. Both of them are bogus - the "IP
address" is in fact a section number.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No relevant formal criteria.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No such issues.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None such.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

This document will update RFC 5996 (IKEv2) in a small way (see Sec.
3.1). Arguably, since use of this protocol is indicated by a
notification, even this "updates 5996" is unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document defines a single code point, and reasonably so.

The IANA expert for the registry (Tero Kivinen) has reviewed the request
and has no objections to the request.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No such sections.