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

Paul Wouters <paul@nohats.ca> Mon, 15 March 2021 02:40 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4263E3A10AA for <ipsec@ietfa.amsl.com>; Sun, 14 Mar 2021 19:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb7Tli0OaJAb for <ipsec@ietfa.amsl.com>; Sun, 14 Mar 2021 19:40:15 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8419A3A10A9 for <ipsec@ietf.org>; Sun, 14 Mar 2021 19:40:15 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DzLHc53lhz1JB; Mon, 15 Mar 2021 03:40:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1615776012; bh=srZElMH0bMFum3oyDyl+uxCDms9eOB/eB5hxA6VD2Xw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cUfYrtsokE3oKlsE5O00M+bHrGC5twhs0vHpS/5tAuQLTkvS5EThac7hY/v4r6rbn endp0AX1DNbMBiGUfsmO6iMpgiIcnfeFSIq8L7ySSLprIVOUkqB+wxUlkdxY49ide2 j9fiMt61UGhnYOlFLHf9DROiLq17DKMH1WxM3zFA=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oxDzJWwCd-5r; Mon, 15 Mar 2021 03:40:11 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 15 Mar 2021 03:40:11 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 431C66029B62; Sun, 14 Mar 2021 22:40:10 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3A5D81E8DA5; Sun, 14 Mar 2021 22:40:10 -0400 (EDT)
Date: Sun, 14 Mar 2021 22:40:10 -0400
From: Paul Wouters <paul@nohats.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
cc: Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org
In-Reply-To: <1508626.1615672889@dooku>
Message-ID: <f5f5630-3f52-d9e4-71be-6a1853918ec8@nohats.ca>
References: <24646.13043.855619.794128@fireball.acr.fi> <1508626.1615672889@dooku>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/tqR-my_6aF825y18hkaqZlVhsvA>
Subject: Re: [IPsec] WG ADoption call for draft-pwouters-ikev1-ipsec-graveyard
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Mar 2021 02:40:20 -0000

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