Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

Jared Mauch <jared@puck.nether.net> Fri, 07 December 2018 21:29 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1237130FF2; Fri, 7 Dec 2018 13:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Yv08BazSEjYl; Fri, 7 Dec 2018 13:29:26 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276B0130FEE; Fri, 7 Dec 2018 13:29:26 -0800 (PST)
Received: from [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1] (unknown [IPv6:2603:3015:3606:cbe1:d96:a9a:20d2:74d1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 1B7555406C7; Fri, 7 Dec 2018 16:29:23 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <c498a79a-f852-f22c-fd17-098cc8f8ebc6@strayalpha.com>
Date: Fri, 07 Dec 2018 16:29:22 -0500
Cc: Ole Troan <otroan@employees.org>, tsv-art <tsv-art@ietf.org>, opsec wg mailing list <opsec@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, ietf <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC22609C-DE99-4541-9E68-8AFF046393E3@puck.nether.net>
References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <C929A8B9-D65C-4EF7-9707-2238AE389BE3@strayalpha.com> <CAL9jLaY4h75KK4Bh-kZC6-5fJupaNdUfm1gK2Dg99jBntMCEyQ@mail.gmail.com> <C47149DC-CAF2-449F-8E18-A0572BBF4746@strayalpha.com> <CAL9jLaYfysKm7qrG=+jq7zV=5ODnSX-tAhBAiTU7SzYF-YmcGw@mail.gma il.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <e5198c02-ebc6-ee3e-96cb-fd2831164f41@gmail.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com> <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com> <E008EA4B-74D3-4251-BFB8-B88F544B2A99@strayalpha.com> <260f1445-0690-691b-5aea-83b7a 43bfdcb@gmail.com> <39A24B3F-1332-4A9B-AAF3-0E9B896F7906@strayalpha.com> <19869497-A363-460F-9348-B40141F7600E@employees.org> <C291DE84-AE40-4938-8851-AF4588714656@strayalpha.com> <2A867D05-8DF5-496F-974D-EBA509E2BFA8@employees.org> <c498a79a-f852-f22c-fd17-098cc8f8ebc6@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/fKcAqg7s7MG-abln1MvRD_8NAXM>
Subject: Re: [OPSEC] HbH flags [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 21:29:28 -0000


> On Dec 6, 2018, at 10:35 AM, Joe Touch <touch@strayalpha.com> wrote:
> 
> OK, all,
> 
> So let's try it this way:
> 
> - standards people on this list claim that 8200 already allows silently
> ignoring HBH options
> 
> - ops people on this list claim that most routers already do this
> 
> So if you accept the items above, then why exactly is this document
> needed at all? The standards already support it and operators already do it.
> 
> It clearly isn't needed, just as clearly as it isn't driven by security
> issues.

I think many of us have PTSD from trying to talk about reasonable defaults and the failure to explicitly state why some of these things are bad and deprecating them continues to burn us to this day.  (Unrelated but perhaps relevant is some of us can’t get our vendors to clean up the garbage they sold us or our customers/peers/partners so we are bearing these costs on a daily basis).

> So I would conclude that whether we agree on the logical path, we have
> come to the same conclusion - drop this doc and move on.

I’ll let someone else decide that, chairs/ADs etc.  I think the question of additional work of eliminating these things so vendors don’t feel the need to implement them is fair work.

- jared