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

Warren Kumari <> Mon, 25 October 2021 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E48B43A09E9 for <>; Mon, 25 Oct 2021 14:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nneLiaDj10Hw for <>; Mon, 25 Oct 2021 14:21:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFA4F3A0029 for <>; Mon, 25 Oct 2021 14:21:28 -0700 (PDT)
Received: by with SMTP id e5so17936474uam.11 for <>; Mon, 25 Oct 2021 14:21:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SLadrMetuUuNvAF+O2MKIcmVvp0+K9QdxY9XZuLPCsg=; b=bmnQd3Hhwd4uXCeB8rW89DZx9yYbpQASiFV+i2UR4gX6+XrieFfbu+E3mWDT0eDn/W LdQ8KszzUzUCMGHkqNVzF5xaWnZUmhW0HwxhksR2olSCR9C62uV9+itfHRN4w/xUwuJe cfTanjGujK3pZi8XpyQyKaepYTjfI+JxyP2avQDB6ZxKjIVNScVVj2uvx8YSjuKltQbp TXbNHJckOL/ZQy8l4weR1ut3YbFrt4cofnSjqCAbDIqVAfjNVjyMTaJoI+AnRugA2zXC z5fDcMLYEZozC9giRILKrzGgXUSsBELj5VidrjZFK0Zz1wXStw8BBto6peEcCw4RKcr5 wnkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SLadrMetuUuNvAF+O2MKIcmVvp0+K9QdxY9XZuLPCsg=; b=Po/cFFeXdrc3LULV1km/jl7I3J57TaS9a+WnO6NcXWnu5fyHMywz1bF8P2q9A8xH8M JTwztlCRg62jXLampSz9CGWFDexxjcmUIMbOqJmOgMejW3YyzVhBIxTeYrMHOpR0kZ3L bHQWoy4gSUNhEF3PcQL5k+ejUpx9Z8cUe5z+FrZ4+6N5VtcThZmJSugc4DRx3EBSbwgY +a6rZJl00piAvLVewR8rkvQVa9MJarCgLVmmNaiLIPSww2cDr57lc1yiUQIu3/oxGBfa 4tBFeQnLF7zqGExvgeV7GPSL+nBJMojtgjmP6MJLzYmXAtxqN3JrPiVFJnaszOB77WiI G2UA==
X-Gm-Message-State: AOAM532mGH8gSJa0HvgIxnwTHBPucSL6EuyUj8yTRvBWBSjyGAFoRspk DOsBx+dW9ziqk1D5bANm31TGayI7dL6v92Vlc8lqGXRuWYeiVdjL
X-Google-Smtp-Source: ABdhPJydmGJFu59s+0cqjaINgQFKKm8QeriR8bmBKFJugRqt/0TPgrAzzijYRzuGmwOy+hjEInodVz0VZUK4qGoxa9c=
X-Received: by 2002:ab0:4adc:: with SMTP id t28mr17886797uae.4.1635196886775; Mon, 25 Oct 2021 14:21:26 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Mon, 25 Oct 2021 17:20:51 -0400
Message-ID: <>
To: Ole Troan <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000093161005cf33f12d"
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: Mon, 25 Oct 2021 21:21:55 -0000

On Mon, Oct 25, 2021 at 5:04 AM <> wrote:

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

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

This is similar to e.g MPLS - I have to manually enable MPLS on an
interface ('set protocols mpls interface et-0/0/0') before the border of my
limited domain extends out the interface, and my neighbor has to enable it
on their side too. We *can* both choose to do so, but if we don't, the
domain doesn't cross the border. Without requiring explicit configuration
it isn't really a "limited domain", it's just a "domain".

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

Filters get missed sometimes, both ingress and egress. Yes, I can filter
towards my limited domain prefix -- but this only protects *my SRH limited
domain*. I'm also likely to want to protect my customers (who cannot be
trusted to always filter perfectly), if I have an enterprise portion I have
to know whatever prefixes they decide to use and update my filters, etc.
The limited part of "limited domain" implies that it has a clear border
(and also that whatever you do within the privacy of your domain is your
own business!); having a soft border fails the "limited" sniff test.

I somewhat like the idea of having a well known prefix for "limited
domains" - if everyone used $prefix, we could default to filtering it on
external links, and, just like MPLS/OSPF/IS-IS/<whatever>, consciously
decide to allow it between consenting adults. This is far from perfect --
it requires more routes in my IGP, etc, but it's better than nothing.


> Cheers,
> Ole

The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra