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

Brian E Carpenter <> Mon, 25 October 2021 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFB543A0AD7 for <>; Mon, 25 Oct 2021 14:38:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.428
X-Spam-Status: No, score=-5.428 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, NICE_REPLY_A=-3.33, 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 hUChehGLDBKH for <>; Mon, 25 Oct 2021 14:38:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03E563A0906 for <>; Mon, 25 Oct 2021 14:38:11 -0700 (PDT)
Received: by with SMTP id u12so5250440pjy.1 for <>; Mon, 25 Oct 2021 14:38:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1QR/uC6mC5zf6DCkr/XU5eJsIH1zlqHlI5guTUH5wv8=; b=KAsgLkxj2xJPfV/Ib99ppLtLWe9BSKDY1dS6vlnUXRuXHJIX9oziuGXR11VHKEyTIi Q1riOV58DuoQR8A46t5q1QCafVIRTS0o1IfvxK5/2mc8VSPfd6kXdAMc+w2byrviXzCW dh1+ymGcSBtnzr9ZpQmEFiz/z1/DAlev/uCe6jn1WrjSiOrasfCjUv//tuh2hH2SOdCj rBE4DXqUpSnS1JJZGcjlXQmPG2phzAqOdSWrZdgSX97Zs9XzseSZrMOR9zZ3YTP/7sjU om0fr+uaySSgtqSG+fRRlQin2n7Be3yyiYe0n7g4vY3Xw6KcEbnz7JOqz9Ph/ZeFfAfM 63XA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1QR/uC6mC5zf6DCkr/XU5eJsIH1zlqHlI5guTUH5wv8=; b=HkKeUHBV3203fuJY2s6rQG73zelvoZj8nPc4hMSlvMKbcLQT+J3QABTguQDJ1W7O3K LMtj6Pb3f33W2UnWs+DrrQrS5PxOQXV87MW1mErXAlAQYqapxjHWnPQx/GbuCI+d5r4J a6nsCQrW3HDOAjn+ZppniqPW1a5JVA9M2q7Ck+nO4huDvJZ/U4L9CwzVdo+Vw224G7ps 6uiH4MMVsnOhXbYLYbCTEmGgxFsb7JtWMn99r7lj4zGaDmj10ePN56iQXgjkLg+JXA/7 p8eYkoZXAC5e+c894D7jXcmL05RsGGbqMzL5YB7gZbpK0+OrmD0CVbhmKv90bkAtWMBf bhEg==
X-Gm-Message-State: AOAM532xaecdyvqQFUP9C7UjvXbc29kVYW6WqGCDs6DRFR5Oxz7sFAbS LTKPCjCXexwD889jAC041yKFdGCYQRlRIQ==
X-Google-Smtp-Source: ABdhPJx6FlM9oVU7FP9YCOmQJT5WsCcaDg7b9T5gAzqCccQMIkdegYcsXPxMn2NXc45v6oioqiU3kA==
X-Received: by 2002:a17:90b:4c0f:: with SMTP id na15mr17443352pjb.96.1635197889989; Mon, 25 Oct 2021 14:38:09 -0700 (PDT)
Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by with ESMTPSA id a20sm19565287pfn.136.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 14:38:09 -0700 (PDT)
To: Andrew Alston <>
Cc: Ole Troan <>, Warren Kumari <>, IPv6 Ops WG <>
References: <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Tue, 26 Oct 2021 10:38:04 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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:38:17 -0000


Segment routing and newtork programming are called out in RFC8799 section 
4 as an example, so yes.

I now realise that the sections 6 & 7 of that RFC should have covered leakage as well other aspects of the domain boundary. But the main argument there is: identify the interior nodes and boundary nodes explicitly. If you do that, you have chance at both protecting the domain from outside interference and protecting the outside from leakage. So I'd welcome the kind of WG you suggest.

    Brian Carpenter
    Thinking of the IETF standards process:

On 25-Oct-21 22:31, Andrew Alston wrote:
> So Brian,
> Let me ask you this – would you say that, in your opinion, that 
SRv6 falls into the definition of limited-domain as per that document.  I’m still going through it closely to make up my own mind – but I’m curious as to your perspective on this
> Andrew
> *From:* Brian Carpenter <>
> *Sent:* Monday, October 25, 2021 12:29 PM
> *To:* Andrew Alston <>
> *Cc:* Ole Troan <>rg>; Warren Kumari <>et>; IPv6 Ops WG <>
> *Subject:* Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?
> Andrew,
> 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.)
> Regards,
>      Brian Carpenter
>      (via tiny screen & keyboard)
> On Mon, 25 Oct 2021, 22:12 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
> <>
> <>