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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 15 March 2021 15:20 UTC

Return-Path: <mcr+ietf@sandelman.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 7F3053A13C2 for <ipsec@ietfa.amsl.com>; Mon, 15 Mar 2021 08:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ndEOnXXGnnxG for <ipsec@ietfa.amsl.com>; Mon, 15 Mar 2021 08:20:12 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8803A13BE for <ipsec@ietf.org>; Mon, 15 Mar 2021 08:20:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A71A2389A5; Mon, 15 Mar 2021 11:25:34 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id b0qAWffd9L1Y; Mon, 15 Mar 2021 11:25:31 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 377B5389A2; Mon, 15 Mar 2021 11:25:31 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5531A1C0; Mon, 15 Mar 2021 11:20:08 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Paul Wouters <paul@nohats.ca>, Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org
In-Reply-To: <f5f5630-3f52-d9e4-71be-6a1853918ec8@nohats.ca>
References: <24646.13043.855619.794128@fireball.acr.fi> <1508626.1615672889@dooku> <f5f5630-3f52-d9e4-71be-6a1853918ec8@nohats.ca>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 15 Mar 2021 11:20:08 -0400
Message-ID: <27800.1615821608@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Gw8JIAfRdwXh_zEgUgXm6D0ykYQ>
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 15:20:14 -0000

Paul Wouters <paul@nohats.ca> wrote:
    > 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?

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"

    > 	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

agreed.

    > 	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.

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.

    > 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.

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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide