On Sat, 13 Mar 2021, Michael Richardson wrote:
I'd *like* section 3 to enumerate the claims clearer (Maybe just new
paragraphs).
You mean a textual change? like split out more, or bullet points?
Pretty much each sentence is a claim, and I think that they
should point to references. That will make it much more impactful a
document in my opinion.
Ahh, so that part is content. So let's split up that first paragraph
(the last two paragraphs just reference IKEv2 replacement RFCs)
IKEv1 is deprecated. Systems running IKEv1 should be upgraded and
reconfigured to run IKEv2.
This is basically the conclusion of the claims below.
Systems that support IKEv1 but not IKEv2 are most likely also
unsuitable candidates for continued operation.
I know from vendors I've talked to that they froze their IKEv1 stacks. I
can't enumerate those in an RFC though. I think only the opensource
stacks are still fixing IKEv1 stuff or enhancing it (usually it is to
improve interoperability).
Such unsupported systems have a much higher chance of containing an
implementation vulnerability that will never be patched.
That's a logical conclusion from being frozen, but I'll admit the draft
didn't mention the freezing of IKEv1 stacks. We could mention it.
IKEv1 systems can be abused for packet amplification attacks.
This could be clarified, or reference CVE-2016-5361. CVE links aren't
that stable over the years though.
IKEv1 systems most likely do not support modern algorithms such as
AES-GCM or CHACHA20_POLY1305 and quite often only support or have been
configured to use the very weak Diffie-Hellman Groups 2 and 5.
(and I just helped migrate a Bell Canada IKEv1 3des-sha1-dh2 setup just last
week
to IKEv2)
In my (pretty elaborate) experience, people tend to not use DH14 for
IKEv1. CHACHA20_POLY1305 is not defined for IKEv1 or IKEv1-ESP. AES-GCM
is only defined for IKEv1-ESP, not IKEv1 itself. So running IKEv1 means
you are running IKE as a non-AEAD. Often at best with AES-CBC because
AES-GCM is not implemented. But again, I can't really give you
references for this.
IKEv1 systems should be upgraded or replaced by IKEv2 systems.
Repeat of the conclusion.
But, I'd rather publish it if adding such references is hard.
If you have text of references, please share.
I think that the third paragraph (labelled IPsec) should be a new section
3.1.
We can make PPK and Labeled IPsec their own sections, but I don't see
why you would do labeled ipsec but not PPK. also, I guess Group IKE
should be listed too as we have a draft and had support in IKEv1 but
not in IKEv2.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
