Skip to main content

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 revision 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
I-D 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
Request Last Call review on draft-ietf-ipsecme-qr-ikev2 by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/t51j90-apJSrRRimcq9isuCcTnQ
Reviewed revision 09 (document currently at 11)
Result Almost ready
Completed 2019-12-13
review-ietf-ipsecme-qr-ikev2-09-genart-lc-holmberg-2019-12-13-00
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.