[no hats] I don’t want to start (or resume) a religious holy war about uppercase MUSTs, but they’re usually about protocol compliance. What people should (not SHOULD) do with their systems is not subject to requirements language, because the IETF does not engineer administrators. What? You are not compliant with RFC xxxx if you didn’t upgrade your systems already?
I could understand a statement that Product yyyy is not compliant with RFC xxxx because it still offers IKEv1, but I don’t like non-compliant administrators. Not that I’m advocating to add that statement to the draft. I think it’s fine as it is: just offering advice that systems should be upgraded. Yoav > On 29 Jun 2021, at 17:21, Daniel Migault <mglt.i...@gmail.com> wrote: > > 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 > <mailto: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 <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> > > > -- > Daniel Migault > Ericsson > _______________________________________________ > 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
