Last Call Review of draft-ietf-ipsecme-qr-ikev2-09
review-ietf-ipsecme-qr-ikev2-09-genart-lc-holmberg-2019-12-13-00

Request Review of draft-ietf-ipsecme-qr-ikev2
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-12-25
Requested 2019-12-11
Authors Scott Fluhrer, Panos Kampanakis, David McGrew, Valery Smyslov
Draft last updated 2019-12-13
Completed reviews Secdir Last Call review of -09 by Watson Ladd (diff)
Genart Last Call review of -09 by Christer Holmberg (diff)
Assignment Reviewer Christer Holmberg
State Completed
Review review-ietf-ipsecme-qr-ikev2-09-genart-lc-holmberg-2019-12-13
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/t51j90-apJSrRRimcq9isuCcTnQ
Reviewed rev. 09 (document currently at 11)
Review result Almost Ready
Review completed: 2019-12-13

Review
review-ietf-ipsecme-qr-ikev2-09-genart-lc-holmberg-2019-12-13

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ipsecme-qr-ikev2-09
Reviewer: Christer Holmberg
Review Date: 2019-12-13
IETF LC End Date: 2019-12-25
IESG Telechat date: Not scheduled for a telechat

Summary: The document is well-written, and almost ready for publication. However, I have a couple of minor comments that I would like the authors to address.

Major issues: None

Minor issues:


Q1:

The Security Considerations lists IKEv2/IPSec algorithms that are not considered quantum-resistant. However, that is not mentioned anywhere else. I think it would be good to mention that in the Abstract and/or Introduction.


Q2:

Section 3 says:

   "If the responder does not support this specification or does not have
   any PPK configured, then it ignores the received notification and
   continues with the IKEv2 protocol as normal."

I assume the ignoring of a non-supported notification and continuing with normal IKEv2 is part of the IKEv2 specification. If so, I suggest to say add something like:

", as described in RFCXXXX."


Nits/editorial comments:


Q3:

The Security Considerations talk about the Grover's algorithm. Please add a reference.