Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation
draft-ietf-lwig-ikev2-minimal-05

[Ballot comment]

I had a discuss ballot on this. I'd still like to see the algorithm-set
described here omit some of the lower security levels but I
accept that this has had review and/or that changes to BCP-like
text really ought be done in other places first. Sorry, for being
slow with getting the discussion closed.

[Ballot comment]
[Update: I am convinced that the standards track vs informational question was a red-herring, and therefore cleared the DISCUSS. I do still think that the current approach risks effectively forking the protocol. But I think I've made my point and leave it to the respective parties to do the Right Thing, whatever they see that to be.]

I question the choice of copying IKEv2 text forward into this document, at least without clearly marking (and citing) the copied text. What happens if 7296 gets updated or obsoleted? It seems like that would effectively fork the protocol. And since this draft does not seem to distinguish copied text from new text, I wonder if the other authors of 7296 should be considered authors of this document.

[Ballot discuss]

I'll be a yes ballot but I'd like to chat briefly if that's ok, just
to check the level of consensus behind the algorithm choices
documented here.  For example, is A.3.2 recommending that only
AES_CBC and AES-CCM_8 ought be implemented?  And would we still
recommend 1536 D-H and wouldn't 2048 by itself be sufficient?
Shouldn't you be clear about that kind of stuff? (I mean what algs
you're telling folks to implement in appendix A.)  Did the WG
discuss all those kinds of decision? (Or are they just what you
implemented?)

The reason this is a discuss is just so that we're clear about the
algorithm stuff - I suspect a bunch of folks will just do what this
document says (or have already) so ensuring these choices are good
ones that the WG actually thought about now is I think worthwhile.

[Ballot comment]

Would it be worth waiting on 25519 for this? Would the code-size and
CPU improvements be better than publishing now? I guess it could be
that the CPU improvement mightn't be as good on smaller CPUs (not
sure), but I just figured it'd be good to ask since work on 25519
for IPsec is under way and it should have some benefits. (I'm fine
though if the answer here is "no, not yet" in which case, there's no
need to even respond to me:-)

[Ballot comment]
Nit that I'm sure the RFC editor would have caught:
Last paragraph at the bottom of Page 4, so is repeated:
"Minimal implementations only need to support the role of initiator,
  so so it"

I'm fine with this being informational since it just describes a proof of concept implementation specific to lwig use cases of an existing standards track RFC.  It does explicitly state that the referenced RFC is normative and any updates to that RFC would likely not apply to this one unless an updated POC is done and that might mean a new draft (I suspect).

[Ballot discuss]
Apologies for changing to DISCUSS after my initial NO OBJECTION position, but I just realized an implication to my comment about copying the IKEv2 text:

The shepherd's write up says "[Informational] is the proper type of RFC because the document describes implementation recommendations for a proposed standard and is not a proposed standard in itself.". But this document does not merely make recommendations; it claims to stand alone as a full specification of everything needed  for a minimal implementation that works with IKEv2.  I'd like to discuss why this should not be standards track, as it's currently written.

[Ballot discuss]
Apologies for changing to DISCUSS after my initial NO OBJECTION position, but I just realized an implication to my comment about copying the IKEv2 text:

The shepherd's write up says "It is the proper type of RFC because the document describes implementation recommendations for a proposed standard and is not a proposed standard in itself.". But this document does not merely make recommendations; it claims to stand alone as a full specification of everything needed  for a minimal implementation that works with IKEv2.  I'd like to discuss why this should not be standards track, as it's currently written.

[Ballot discuss]
Apologies for changing to DISCUSS after my initial NO OBJECTION position, but I just realized an implication to my comment about copying the IKEv2 text:

The shepherd's write up says "It is the proper type of RFC because the document describes implementation recommendations for a proposed standard and is not a proposed standard in itself.". But this document does not merely make recommendations; it claims to stand alone as a full specification of everything needed to for a minimal implementation that works with IKEv2.  I'd like to discuss why this should not be standards track, as it's currently written.

[Ballot comment]
I question the choice of copying IKEv2 text forward into this document, at least without clearly marking (and citing) the copied text. What happens if 7296 gets updated or obsoleted? It seems like that would effectively fork the protocol. And since this draft does not seem to distinguish copied text from new text, I wonder if the other authors of 7296 should be considered authors of this document.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-lwig-ikev2-minimal-02, which is currently in Last Call, and has the following comments:

Although the IANA Considerations section states that this document doesn't have any actions for IANA, Appendix A.3.2 says that Appendix B of this document is the reference for Transform Type 4 - Diffie-Hellman Group Transform IDs 768-bit MODP  and 1024-bit MODP.

In the registry (http://www.iana.org/assignments/ikev2-parameters), the current reference for those two registrations is RFC 7296. Should we list this document as an additional reference, replace the references to RFC 7296 with references to this document, or disregard?

If the registry should remain untouched, should "Appendix B" be replaced with "RFC 7296"?

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Minimal IKEv2) to Informational RFC


The IESG has received a request from the Light-Weight Implementation
Guidance WG (lwig) to consider the following document:
- 'Minimal IKEv2'
  as Informational 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 2015-10-02. 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 describes minimal version of the Internet Key Exchange
  version 2 (IKEv2) protocol.  IKEv2 is a component of IPsec used for
  performing mutual authentication and establishing and maintaining
  Security Associations (SAs). IKEv2 includes several optional
  features, which are not needed in minimal implementations.  This
  document describes what is required from the minimal implementation,
  and also describes various optimizations which can be done.  The
  protocol described here is compliant with full IKEv2 with exception
  that this document describes mainly shared secret authentication
  (IKEv2 requires support for certificate authentication in addition to
  shared secret authentication).

  This document does not update or modify RFC 7296, but provides more
  compact description of the minimal version of the protocol.  If this
  document and RFC 7296 conflicts then RFC 7296 is the authoritative
  description.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/ballot/


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

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


i) Type of RFC Requested: Informational
ii) It is the proper type of RFC because the document describes implementation recommendations for a proposed standard and is not a proposed standard in itself.
iii) The type of RFC is indicated in the title page header


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

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.


The document describes a minimal profile of the Internet Key Exchange version 2 (IKEv2) protocol.  IKEv2 includes several optional features, which are not needed in minimal implementations.  The document describes what is required from a minimal implementation and also describes various optimizations which can be done.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?


There was nothing noteworthy in the WG process.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


The author and another party have independently produced prototype code according to the document (see https://www.iab.org/wp-content/IAB-uploads/2011/04/Kivinen.pdf). There are no reviewers worth a special mention.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


The Document Shepherd is Robert Cragie. The Responsible Area Director is Brian Haberman.


(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 reviewed the document and has one concern (detailed below), which does not require any action prior to publication.


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


The document has not had a particularly broad review given the subject material.


(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 the document is regarding a minimal implementation profile of IKEV2, it is recommended that it is reviewed by the security Area Director.


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


The Document Shepherd has some concerns regarding the amount of text copied from RFC 7296 and either used verbatim or with some modification. When discussed with the author, this was clearly intended and the author's preference, therefore the Document Shepherd does not require any action regarding this concern.


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


The authors have confirmed that there are no IPR disclosures required for full conformance with BCP 78 and BCP 79.


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


There are no IPR disclosures that reference the document.


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


It represents the concurrence of a few individuals. There was little discussion amongst the WG in general.


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


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


  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == The page length should not exceed 58 lines per page, but there was 32
    longer pages, the longest (page 2) being 60 lines

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (March 2015) is 170 days in the past.  Is this
    intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'CERTREQ' is mentioned on line 264, but not
    defined
'SAr1, KEr, Nr, [CERTREQ]...'

  == Missing Reference: 'IPSECARCH' is mentioned on line 517, but not
    defined
'in the protocol's specification.  For ESP and AH, [IPSECARCH]...'

  == Missing Reference: 'MD5' is mentioned on line 975, but not
    defined
'PRF_HMAC_MD5                1        (RFC2104), [MD5]...'

  == Missing Reference: 'SHA' is mentioned on line 976, but not
    defined
'PRF_HMAC_SHA1              2        (RFC2104), [SHA]...'

  == Missing Reference: 'ADDGROUP' is mentioned on line 997, but not
    defined
'2048-bit MODP      14        [ADDGROUP]...'

  == Missing Reference: 'IDNA' is mentioned on line 1135, but not defined
    'in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net"....'

  == Missing Reference: 'EAI' is mentioned on line 1140, but not
    defined
    'contain any terminators.  Because of [EAI], implementations wo...'

  == Missing Reference: 'PKCS1' is mentioned on line 1251, but not
    defined
'scheme specified in [PKCS1], see [RFC7296] Section 2.15 for...'

    Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--).


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


No formal review required.


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


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


Not applicable to an Informational RFC.


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


The publication of this document will not affect the status of any existing RFCs.


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


There are no IANA considerations.


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


There are no new IANA 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.


There are no parts of the document written in a formal language.