I thought the purpose of the draft was to be able to say "look at this document it says you MUST switch to IKEv2 if you want to remain IPsec interoperable. I am suprised I do not see the MUST in question. I am fine whatever chair/co-authors are fine with.
Yours, Daniel On Tue, Jun 29, 2021 at 2:00 PM Yoav Nir <ynir.i...@gmail.com> wrote: > [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> 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 > > > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
