Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts? Tue, 26 October 2021 07:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB2103A116C for <>; Tue, 26 Oct 2021 00:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JrvrLj2u16lu for <>; Tue, 26 Oct 2021 00:12:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BB613A1162 for <>; Tue, 26 Oct 2021 00:12:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 613C84E11AC9; Tue, 26 Oct 2021 07:12:54 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 5A326643E1AA; Tue, 26 Oct 2021 09:12:52 +0200 (CEST)
Message-Id: <>
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.\))
Date: Tue, 26 Oct 2021 09:12:51 +0200
In-Reply-To: <>
Cc: "" <>
To: Warren Kumari <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.