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

Warren Kumari <> Mon, 25 October 2021 23:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BDFA3A040D for <>; Mon, 25 Oct 2021 16:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.855
X-Spam-Status: No, score=-0.855 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, 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 Yo7OfmHq_Sew for <>; Mon, 25 Oct 2021 16:12:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA48E3A0784 for <>; Mon, 25 Oct 2021 16:12:12 -0700 (PDT)
Received: by with SMTP id q13so25543230uaq.2 for <>; Mon, 25 Oct 2021 16:12:12 -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=5LqJCgONVCYPunSv58wiraD/YePQXOTM/wmPCedTo5k=; b=gYP4l5alOCP6DpyqIqMkKHrbzLkgUTjvF6jF1nlmd0EMVlh4yypvBcoiuD15jfcEaG 7jxOMdKXcxoGY/r3Mzytk0ATrv4XRL2dVy30hf536zGN49o1/8IR50UwEiYIj5dhtUoO 0+ZlifuIRPfSpNeQDnOwaUNTEX15boI591nms1l47+zAPLr184/QLzOIbo00nJHduJns 6uj98jehXVPoq6Y7y3ejKoIKscNE+lZITueYwTtQGkkJ7JK9azuUiO8bLkCCkGU3Urxn Dhp3+VVCnDga8W9JybNnPAPAQyoDw3O9EQUEmZAbYhl6YPUGPOZ/M1mqvSSjuO82Gbfl 7M0w==
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=5LqJCgONVCYPunSv58wiraD/YePQXOTM/wmPCedTo5k=; b=AbaP2yt91mFtIrl7nJxumghJeh85utKpzpA9FL0PJq9EfbWlfwzFStD0lRh/cxJfWo mAfOmtAIVD6V2myVWccW5C2lmHtmoWugUQmxeFy16V4P+D5nfTcG9zW9Cg27REvj5ZQT U1jPZX1wNsrEJAcbWsHwfbGHkbPs4gsne6uM+jurnUlVS4QAP0jxOQeyPPNZ0qyAHzky GCrYzYYvNnWbJ3DjIW8CPpIomiJceZS1+QNmccYw0/KgbQUG0eYcCXQLu1FEjnV0J9Iy XJXkBchthOnd8Ko7Qu3RwEvAqxG7L8R4CnwavVeAndHHJ2lJYT9muaNZ5Y5BQuWWv6gX oK4w==
X-Gm-Message-State: AOAM532Y9YTxgBIBPo/t0yoqw/iGDprgp8zN7I2DXQMV5aWEuimDzm53 2kpBeFaGXKtGhGooxb1x+mdeRyfUvW+2rXnlvHhEJQ==
X-Google-Smtp-Source: ABdhPJwnaGQsN8AZxfZ+p+X0VuJ6jmiiSUtFlVqn768hO7H/Pow5IKK2o54srsxpgwiP6GN/Qy541H8hoiLLDCJh8GY=
X-Received: by 2002:ab0:136d:: with SMTP id h42mr18496630uae.40.1635203528483; Mon, 25 Oct 2021 16:12:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <YXciHYMNa6KJUohp@Space.Net> <> <YXcl2iQMvZe8ggLs@Space.Net> <> <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Mon, 25 Oct 2021 19:11:32 -0400
Message-ID: <>
To: Andrew Alston <>
Cc: Gert Doering <>, Brian E Carpenter <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000737a8505cf357dc2"
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 23:12:32 -0000

On Mon, Oct 25, 2021 at 6:51 PM Andrew Alston <> wrote:

> I'm assuming that in this scenario your "Rogue host A" is one that has
> intentionally added to the SRH domain (either by allowing your new
> ether-type, or manually removing the "limited domain prefix filter")? If
> so, then yes, bad things happen. This seems largely the same as "I decided
> to add "Rogue host A" to my MPLS domain so it could MPLS", or I added
> "Rogue host A" to my IGP, because reasons...
> Making a host able to influence routing, whether it is part of
> something like MPLS, SR<something>, or in your IGP makes that host able to
> do bad things...
> See that’s the thing Warren – with MPLS – it’s a default fail-closed
Nod. It sounds like you think I'm disagreeing with you, which confuses me
some -- I think that we are both looking for a failed closed system.

> – with a prefix list that has to be applied to every interface – well –
> things get missed.
Yes. Hence my "by default it would be applied".

In the same way I manually add an interface to MPLS:
protocol {
   mpls {
       interface et-0/0/0.0;

I would manually add the interface to allow SRH:
protocol {
   srh {
   interface et-0/0/0;
(or perhaps something like "set interface et-0/0/0.0 family srh allow'", or

The solution would default to fail-closed -- there is a default "deny
$srh_prefix" on the interface and I manually permit it by telling the
device that the interface participates in SRH (or whatever other limited
domain protocols are defined to use space). The above example has some
syntactic sugar, but the actual implementation is simply that the device
allows packets from $limited_domain_prefix when you set this...

>   And these prefix lists would have be applied to every L3 interface – and
> again – I fear you’re going to have tcam problems if you try and apply an
> LPM filter to every interface on a massive device with thousands of
> interfaces.  You can’t apply filters in the way you would for CoPP – these
> become specific prefix filters.

I don't think that it is a specific prefix filter (or I'm misunderstanding
you) -- if you add the interface to the SRH limited domain, the filter
blocking the (well-known) prefix is removed. It's a single, well known

> I’m just convinced that’s either practical or it’s going to really work,.

I think that my proposal is largely the same as a different ether-type - it
is implemented as a default block ACL, which is removed when you add the
interface to the domain (instead of allowing a different ether-type).
Depending on implementation it may burn a single TCAM slot per interface,
but implementing it should be simple....

> Also – if you look at the scenario I sketched – that rogue doesn’t doesn’t
> just affect you – because if it changes the source of the inner packet and
> causes it to broadcast – the replies are going to affect things on a far
> wider basis – your routers just became amplifiers for an attack aimed
> externally.

Yes, we are in full agreement.

> You are right – the ether-type may have sailed – but as I said – so far –
> my tests indicate that a single host would allow you to launch far more
> damaging attacks in this scenario than it would if it couldn’t inject weird
> packets

Again, I fully agree.... which is why we don't want unexpected hosts to be
able to do this :-)


> Andrew
> Now - the inner packet is a v4 packet - it has a source set to random host
> attacker doesn’t like - and its destination is - which
> thanks to rfc919 will not forward - when that deencap happens - does the
> packet get dropped because it can't be forwarded - or does it get treated
> as a local broadcast. This is a rather undefined scenario - if however it
> DOES get treated as a local broadcast - well - then we have a really big
> problem - that’s called smurf-v2 (and even if doesn’t
> work - more specific broadcasts that are attached may well work). At this
> point - when the broadcast packet hits the hosts behind those broadcasts -
> they will reply to the spoofed source - this will follow stock standard
> routing outbound - and the protections we would normally use aren’t gonna
> work (the source of replies to the broadcast packets would be the hosts -
> they are permitted to send packets to the internet)
> Another scenario - sending to multicast addresses post de-encap - do we
> have a potential attack vector to poison ND?  Again - haven't had the time
> to test this.
> Same thing applies to a whole long list of other things - effectively - if
> you get one compromised host on the network that can inject a packet that
> will de-encap and act on the inner packet - with absolutely zero mechanisms
> for verification of what is in that inner packet or how to handle it - the
> list of possible problems is - extensive to say the last.  All I am saying
> is - we need to really step back and think - and I think this needs a
> veryyyyy close look - because in initial tests  I have done - and without
> the above additional tests - I can tell you my results are looking
> positively scary (and once I complete the full set I'll publish some
> scenarios and results with more detail)
> Andrew
> On 26/10/2021, 00:48, "v6ops on behalf of Gert Doering" <
> on behalf of> wrote:
>     Hi,
>     On Tue, Oct 26, 2021 at 10:44:32AM +1300, Brian E Carpenter wrote:
>     > On 26-Oct-21 10:31, Gert Doering wrote:
>     > > On Mon, Oct 25, 2021 at 05:20:51PM -0400, Warren Kumari wrote:
>     > >> I somewhat like the idea of having a well known prefix for
> "limited
>     > >> domains"
>     >
>     > fc00::/7 works well. RFC8994 is a worked example.
>     So how would that work for an ISP network trying to run SR6, protecting
>     its network from rogue hosts inside?  Without having GUAs on the SR6
>     routers that would happily decapsulate incoming SR6 packets, and
>     without violating lots of rules about "do not leak ULAs outside
>     your network" (traceroute and other ICMP errors)?
>     I lack imagination today...
>     Gert Doering
>             -- NetMaster
>     --
>     have you enabled IPv6 on something today...?
>     SpaceNet AG                      Vorstand: Sebastian v. Bomhard,
> Michael Emmer
>     Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A.
> Grundner-Culemann
>     D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>     Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
> _______________________________________________
> v6ops mailing list
> --
> The computing scientist’s main challenge is not to get confused by the
> complexities of his own making.
>   -- E. W. Dijkstra

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