Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?

otroan@employees.org Mon, 25 October 2021 09:04 UTC

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586913A08C0 for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 02:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 cN814C_Zuyb4 for <v6ops@ietfa.amsl.com>; Mon, 25 Oct 2021 02:04:56 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C12643A08CC for <v6ops@ietf.org>; Mon, 25 Oct 2021 02:04:56 -0700 (PDT)
Received: from astfgl.hanazo.no (ti0389q160-5225.bb.online.no [95.34.0.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 8E1234E11B56; Mon, 25 Oct 2021 09:04:55 +0000 (UTC)
Received: from smtpclient.apple (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 810A5642A1DC; Mon, 25 Oct 2021 11:04:53 +0200 (CEST)
From: otroan@employees.org
Message-Id: <1F31CC6F-8471-4B50-AE3F-9E5FC76BB447@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_B7D501FB-0B14-492D-8416-9095B21C63C8"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 25 Oct 2021 11:04:53 +0200
In-Reply-To: <CAHw9_iJy_OjSwRDRx5cbB6yhau7XzNUKTi49sHhi0CnmRARQUA@mail.gmail.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
To: Warren Kumari <warren@kumari.net>
References: <CB45220A-ECE6-492A-8A37-D189A71CDA2B@liquidtelecom.com> <CAHw9_iJy_OjSwRDRx5cbB6yhau7XzNUKTi49sHhi0CnmRARQUA@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ZQqQ97e8EWcnon-_iJp6rYj34J8>
Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Oct 2021 09:04:58 -0000

Warren,

> The way I see this playing out is operators quickly moving along the lines of:
> If I'm expected to filter "RH type 4 (SRH)" on all of my external interfaces in case someone else decides to run SRH, what else should I filter? Clearly 5 and 6 (CRH-16/32)... and 7, 8, ... 255.
> I need to be ready *before* you enable $insert_new_protocol_here, so the only sensible thing for me to do is filter all RH/43. Oh, and I don't know what sort of new uses there might be for Hop-by-Hop that might affect me, so I should clearly just filter all protocol 0 (perhaps in the future I might allow specific ones... maybe). HIP? I don't use that, but I might in the future, and I certainly don't have time to follow all of the new things being proposed in the IETF/by vendors, so obviously I should filter that everywhere...
> Actually, why am I bothering to write this long filter list? I'll just allow TCP and UDP, and call it done...
> 
> (When I started writing the above I thought I would need to add a "Warning: Hyperbole ahead" marker -- but I'm no longer sure that that's the case).

Proposal for a principle: "If Internet traffic is carried across a limited domain, the technology used in the limited domain must not hinder end to end transparency."

You are welcome to suggest more concise ways of saying that.

In the above example, filtering packets with the SRH RH type _and_ destined towards your own limited domain prefix would adhere to that.

Cheers,
Ole