Subject: [IPsec] WG ADoption call for draft-pwouters-ikev1-ipsec-graveyard

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Mar 2021 16:21:39 +0200

This is the start of 2 week WG adoption call for this document ending
2021-03-22. Please send your reply about whether you support adopting
this document as WG document to this list.

This work is considered as maintenance of the IPsec, thus is covered
by the generic maintenance work.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Mar 2021 10:12:27 -0500 (EST)

On Mon, 8 Mar 2021, Tero Kivinen wrote:

> Subject: [IPsec] WG ADoption call for draft-pwouters-ikev1-ipsec-graveyard
> 

I support my own document for adoption of course, AND I have no IPR
on anything in this document (or any other document :)

Paul

---

From: Timothy Winters <[email-masked]>
Date: Tue, 9 Mar 2021 07:33:18 -0500

> on anything in this document (or any other document :)
I support adoption of this document as a working group document.

>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 11 Mar 2021 12:51:09 -0500

I support adoption.  I will definitely review.

Cheers,
spt

> On Mar 8, 2021, at 09:21, Tero Kivinen <[email-masked]> wrote:
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 12 Mar 2021 10:34:31 +0300

Hi,

I support adoption of this document.
FWIW, I also support Dan's comments regarding the draft.

Regards,
Valery.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Mar 2021 17:01:29 -0500

> this document as WG document to this list.

I support adoption.
I am frustrated with the WG because we've been talking about this for at
least two years (maybe four?): documents don't need to be perfect to be adopted.

So, just do it already.
Please plan to WGLC this before the next IETF.

I'd *like* section 3 to enumerate the claims clearer (Maybe just new
paragraphs).  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.
But, I'd rather publish it if adding such references is hard.

I think that the third paragraph (labelled IPsec) should be a new section
3.1.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Panwei (William)" <[email-masked]>
Date: Sun, 14 Mar 2021 12:57:14 +0000

Hi,

I support adoption of this draft.

Regards & Thanks!
Wei Pan

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Tero Kivinen
Sent: Monday, March 8, 2021 10:22 PM
To: [email-masked]
Subject: [IPsec] WG ADoption call for draft-pwouters-ikev1-ipsec-graveyard

This is the start of 2 week WG adoption call for this document ending 2021-03-22. Please send your reply about whether you support adopting this document as WG document to this list.

This work is considered as maintenance of the IPsec, thus is covered by the generic maintenance work.
--
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Sun, 14 Mar 2021 22:40:10 -0400 (EDT)

On Sat, 13 Mar 2021, Michael Richardson wrote:

> 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

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

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Mar 2021 11:20:08 -0400

> You mean a textual change? like split out more, or bullet points?

Yes.  I am imagine an argument between an operational person who wants to
authorization to upgrade/replace a gateway with the CFO.  This document is
his ammunition, so we need to make the CFO consider that the risks of
not updating exceed the risk of change.
Fundamentally, the CFO is risk averse, and thinks that "it ain't broken"

    > 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

agreed.

    > that stable over the years though.

That's okay, it's stable enough, and the form of the reference makes it clear
that there are issues.

    >> I think that the third paragraph (labelled IPsec) should be a new
    >> section 3.1.

    > should be listed too as we have a draft and had support in IKEv1 but

I want labelled IPsec to be a separate section so that it will have an HTML
link, and can be referenced easily in the government RFP that justifies the
upgrade.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide