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

Brian Carpenter <> Mon, 25 October 2021 09:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4AE73A0908 for <>; Mon, 25 Oct 2021 02:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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 eiXX5GZ7L1V6 for <>; Mon, 25 Oct 2021 02:29:06 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AB1B3A08F9 for <>; Mon, 25 Oct 2021 02:29:06 -0700 (PDT)
Received: by with SMTP id 65so6688386ljf.9 for <>; Mon, 25 Oct 2021 02:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C21hAfkjOIPHaQWU5jbhbMOdLL4HixnsI32KdRb5Yf0=; b=FtMkjjeK5SAY7Ev1tIe8hrLxz/aU92UwGjW7JUqLL+gdrsfDtOqmZFWU3Ir1nHYyu4 PEWtXy0G51QWyz3xDzrREM3WQj2Pj1+/yccHhr/P+QobiK8xnNVV6q/u0pN1pue5bTob 53xAuwk/2ydsD1GVCbGN8RfRXfmMapviCTR/T80K7IdQrFApHE5RIt/unXG59ZUxqMeC r+pKMKsXNdSlwlWVg9Vz+MVdggFrDSvjD/iwweiwqwh4NQL46Dosww90fKgBmJvfd5x3 xviPNWaRZJBw2FXaJhrLaZ0NbNc7coybuxBSVaJncnc6BaD6MU0LqJcWCE5+kaMD9Lvf ZwFg==
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=C21hAfkjOIPHaQWU5jbhbMOdLL4HixnsI32KdRb5Yf0=; b=SuiwWr7l7qSoGEZ40AaMfiP7EHuA+4QRF9jRrcXbMsjTsVKX2R9XUUVxOMZwbN9VcC l+V341Cvti/k+xCrnnmuJ1sqpOctdzVatw76+08NAruWKWJlBTXrPblaTeonAsH5PH5V y0MQaC5tOjN2ZFZdJZpNSV1AzmBTApasVbUwQegFo4HOUKYzpMZgPMXeQmyaQPugbuMb w4ICkwoY0Fpn3YieilKdZQtfISedEDKZFW+2uhhCAaEfQapG5pDx/qUMYJv6wN084jq9 hifA5gIFMYmgjDFN6p0EKGKOhQsD50IBpluJTOtZz485eBoplu9WpcTqR4D8xyrfHpqg dqtw==
X-Gm-Message-State: AOAM531u1YkHyhZgelR7ZeWaubQQ1njR78m/TQjkJHW0L/tcmfN3NPzv kPYFEUqLcVxD2vxHX3L2W8FYr5KL9WRH5x1uSiU=
X-Google-Smtp-Source: ABdhPJxL5LFjf/I+eAhgvyALNTK/vhsaxaAN7qnMN1WoRvvPi55luxxZFVMdV6CDnENI5hCR2tAMDHnOzqu8xGm75gU=
X-Received: by 2002:a2e:9641:: with SMTP id z1mr18494402ljh.66.1635154143145; Mon, 25 Oct 2021 02:29:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Brian Carpenter <>
Date: Mon, 25 Oct 2021 22:28:50 +1300
Message-ID: <>
To: Andrew Alston <>
Cc: Ole Troan <>, Warren Kumari <>, IPv6 Ops WG <>
Content-Type: multipart/alternative; boundary="000000000000daf28c05cf29fde4"
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 09:29:12 -0000

That's what
is getting at. We need more precision indeed, and that requirements list
was intended as a starting point. (We also have an example: RFC8994.)

    Brian Carpenter
    (via tiny screen & keyboard)

On Mon, 25 Oct 2021, 22:12 Andrew Alston, <Andrew.Alston=> wrote:

> Ole,
> My problem here is that "limited domain" has become a vague and obscure
> term used to justify the violation of pretty much anything.
> Furthermore - I would argue that in the case of srv6 - the concept of
> domain boundary has become so obscure and so vague as to be meaningless.
> When limited domain used to have limited edge devices connecting to other
> networks - you could kinda get away with this - when your limited domain is
> now extended into a hybrid server/network world - and your domain edge is
> so vague and fuzzy as to encompass pretty much every port on the network -
> then the concept of limited domain is, in my view as an operator,
> meaningless.
> I actually think it would be interesting to potentially form another
> working group in the IETF - to specifically look at the operational impact
> of ideas being proposed but on a "localized" basis - so while GROW is
> chartered to look at the impact of things on the wider internet - perhaps
> we need to start thinking about something that can analyze the impact of
> proposals from the perspective of a "limited domain" - inside that domain -
> and perhaps this could also be the place where we define what a "limited
> domain" really means - and what the boundaries of this really mean.
> Might be something worth considering...
> Andrew
> -----Original Message-----
> From: v6ops <> On Behalf Of
> Sent: Monday, October 25, 2021 12:05 PM
> To: Warren Kumari <>
> Cc:
> Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent
> drafts?
> 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
> _______________________________________________
> v6ops mailing list