I believe that the first sentence of section 3 says it all. ship it! I still have some minor comments, though these may have already been discussed. There are no normative MUST to upgrade ( and in general very little normative language). Shouldn't we have for example: Systems running IKEv1 should be upgraded and reconfigured to run IKEv2.
moved to : Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2. There are overall very little number of SHOULD/MUST but maybe that is an editorial choice. Yours, Daniel Yours, Daniel On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins <dhark...@lounge.org> wrote: > > Hi, > > On 6/28/21 1:23 AM, Valery Smyslov wrote: > > 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. > > You know, that was bugging me too. "in every aspect" is laying it on > a bit thick. IKEv1 > has a security proof. The much maligned PSK mode authenticates the key > as well as the > exchange which is better than what IKEv2 does (and why IKEv1 did not > need an update to do > PQC). So saying it's less secure "in every aspect" just isn't true. But > I couldn't figure > out a better way to say it.... > > > 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? > > But this is great! I agree that such a brief summary of the superior > features > would be better than a factually challenged "in every aspect" statement. > > regards, > > Dan. > > -- > "The object of life is not to be on the side of the majority, but to > escape finding oneself in the ranks of the insane." -- Marcus Aurelius > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
