Hi,
I think document is mostly ready. Few observations:
- FWIW I think that Dan's efforts to make draft's language less speculative and
more concrete
are valid and should be reflected in the document.
- Is it OK that the intended status is Standards Track? Shouldn't it be BCP?
- The draft states that it updates RFC 7296, 8221, 8247. What in particular is
being updated?
I believe the recent IESG directives require a short explanation of what is
being updated
to be present in Abstract. In any case, it should be clearly indicated in
the body of the document.
Have I missed it?
- Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 in
every aspect." is a bit too vague.
I believe it's better to list security aspects where we believe IKEv2 is
superior:
* IKEv2 supports modern cryptographic primitives, including AEAD ciphers
* IKEv2 provides real defense against DoS (cookies, core spec) and DDoS
(puzzles, RFC 8019) attacks
* support for post-quantum crypto in IKEv2 is being developed
(draft-ietf-ipsecme-ikev2-multiple-ke)
* IKEv2 supports various authentication methods via integration with EAP
(core spec)
* an extension that allows build PAKE methods in IKEv2 exists (RFC 6467)
* did I forget something?
- Section 4.3. Formally RFC 6407 is not directly concerned with IKEv1.
This is an independent protocol developed by msec WG that was based on IKEv1.
I think more accurate language should be used to make this clear. For
example:
Group Domain of Interpretation (GDOI, RFC 6407) protocol based on IKEv1
defines the support for Multicast Group SAs.
I also think that reference to RFC 3740 should be remove (it doesn't even
mention IKE
in any substantial way). I'm not so sure about RFC 5374, but I'm inclining
to remove it too - it's mostly concerned with MCAS architecture and doesn't
define any concrete IKEv1 changes to support it. So, leave only RFC 6407.
- Section 5 lists deprecated algorithms. In my reading this list
is inconsistent with Section 7 (IANA Considerations) which lists
many more deprecated algorithms... So, I'm a bit puzzled
how to read this section.
- The draft currently has all its references as Normative.
I have no problems with this (except that RFC 3740 is Informational,
so should not be referenced as Normative in Standards Track and BCP
documents,
but I suggested to remove it anyway). My concern is that
referencing active drafts as Normative will lead to slow down
publication of this document until those drafts are published.
I don't think it's a major problem (we will have an incentive
to work harder on these drafts :-)), just should be noted.
Regards,
Valery.
> Hi, all.
>
> Although this draft is really new, having been submitted in April of this
> year, its predecessor draft has been
> under discussion since March of 2019.
>
> This begins a 2-week WGLC. Please read the draft and post comments to the
> list. Since this is rather new,
> short messages in the vein of “Yeah, this is good. Ship it”, but substantive
> comments are, of course, even
> more welcome.
>
> The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.
>
> Thanks
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
