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

otroan@employees.org Tue, 26 October 2021 07:12 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 CB2103A116C for <v6ops@ietfa.amsl.com>; Tue, 26 Oct 2021 00:12:59 -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 JrvrLj2u16lu for <v6ops@ietfa.amsl.com>; Tue, 26 Oct 2021 00:12:55 -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 4BB613A1162 for <v6ops@ietf.org>; Tue, 26 Oct 2021 00:12:55 -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 613C84E11AC9; Tue, 26 Oct 2021 07:12:54 +0000 (UTC)
Received: from smtpclient.apple (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 5A326643E1AA; Tue, 26 Oct 2021 09:12:52 +0200 (CEST)
From: otroan@employees.org
Message-Id: <F5708354-86B5-4FB6-BA38-1F9FD602D9D5@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_AA537CA9-8B4B-4B4B-A3CA-BB042EA686F4"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 26 Oct 2021 09:12:51 +0200
In-Reply-To: <CAHw9_iKU5--mFq3swhSbGJHV9Y5H52cKcgeF=nBf1rqZeBMRJQ@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> <1F31CC6F-8471-4B50-AE3F-9E5FC76BB447@employees.org> <CAHw9_iKU5--mFq3swhSbGJHV9Y5H52cKcgeF=nBf1rqZeBMRJQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_Mc92HsJ8Ja50S4Cr0UFy5p5qec>
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: Tue, 26 Oct 2021 07:13:00 -0000

> > 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."
> 
> <no hats/>
> 
> I must admit I'm having a hard time parsing the last part of the sentence. I think it is more:
> "A limited domain must default to fail closed, and require explicit configuration to open it."

It means: an operator's implementation of a limited domain should not impede anyone transitting that network to use the same mechanism.

O.