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

Brian E Carpenter <> Mon, 25 October 2021 22:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34C533A0784 for <>; Mon, 25 Oct 2021 15:23:04 -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 IPHIWcfjqvH1 for <>; Mon, 25 Oct 2021 15:22:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 67B613A0EFC for <>; Mon, 25 Oct 2021 15:20:53 -0700 (PDT)
Received: by with SMTP id v16so3509426ple.9 for <>; Mon, 25 Oct 2021 15:20:53 -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=asHI2inWzu54O1K5vHBIaQA1SQmFsRDB1VhYTmRj8P8=; b=NP2jC6KDsfkhF8bvPK4rfVVlkDM3vWNVXPjXEsxZQLvlEyPl9LeMSdiZOkfu4jAS2f iiLW5tM+X678Up+MVgqYMggK3oHnxC2SUEFpSy2eWG1FfRbau9geCdY2tSwcivzETidi Ot0fCyTTqsiu91sTq9UBXA4NzPtGtdpmogbMOEQZryC5rCYUCHIFfG97ZI7BXiOVv6BP 5BzJVbkrPyYDLpc4mmtH8GLcS81aA0uYjUWwP5b4zRbp8Hta3rIo1/wpBjWtRzln0R+c Pj8fCaXPWecK4LOgAh4ELXG54MyLPOtE6eXTJfnCcZm/ve2DjvwmR9yHUUiA6fdwyUAW BCNg==
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=asHI2inWzu54O1K5vHBIaQA1SQmFsRDB1VhYTmRj8P8=; b=RUC/1EI0fIOvAHRv9j0lFvYTajE18sTFxAaG9GRJ718UhnuRb7TFd9mIRDt1WSuLb/ OZ3kITjhSppr5HAx7xbyuB6WJTD1OD0c1RugZgiBuh+nQYH6AQXXghb9tLjdYbZXPgbr LQhEP6e4mlZRO2goomm1lVt8bXPhvbWUqBpZYSJc/bkdnNXHDd6IbNlhtUETuk+aO0Qk l0iGZ77hlfplavWufuMhpRjS9kk72mZpNnkFBBe/uyay501doTga/qXJe2i96EY1hmh8 ZRSS9LLwAdDsDQe00RLDvyF9mR96qwRzdVPunfvi85dWezBK+TwjV6gp6kW1z988S7Dd CCCQ==
X-Gm-Message-State: AOAM533NRhKTkPsKg6QZ1zCCILMpTI6uAkpQDFgGym54CLh7rYAuik0t R8TOJ3U5eeKSBGTihq+vM+0u6lAO/9K0wA==
X-Google-Smtp-Source: ABdhPJyb1WPlKiIX8iyeItomuAkMz3uG/WcP3j7EfvzPe0ffxADGe4tTYKxRXH/ZbiE6/Pskir8G5g==
X-Received: by 2002:a17:902:ce8a:b0:140:5c8e:1ca6 with SMTP id f10-20020a170902ce8a00b001405c8e1ca6mr6326700plg.22.1635200449481; Mon, 25 Oct 2021 15:20:49 -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 n2sm4734301pjo.20.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Oct 2021 15:20:49 -0700 (PDT)
To: Andrew Alston <>, Gert Doering <>
Cc: "" <>
References: <> <> <> <> <YXciHYMNa6KJUohp@Space.Net> <> <YXcl2iQMvZe8ggLs@Space.Net> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Tue, 26 Oct 2021 11:20:44 +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 22:23:04 -0000

Yes. Rogue hosts *inside* the domain are always going to be a problem.
I don't see how a magic prefix can ever help with that.


On 26-Oct-21 11:12, Andrew Alston wrote:
> It would help to have a dedicated prefix - as a start - does it really solve the issue though.
> Imagine a device with a stack of cloud servers behind it - each server terminates on a separate sub-interface - and now you're trying to apply what is in effect an LPM filter to each and every interface (as compared to host based firewalling or other security mechanisms) - my question is then - how far will your tcam go - how practical is this in reality.
> This is as opposed to if there is a separate ether-type where an interface is either configured to process it or drop it on the floor.  So yes - 
the prefix filtering will help - but I suspect that you're gonna find many many scenarios where this actually doesn’t work - and all you need is *one* filter miss that has a compromised server behind it to have real problems.
> Something I haven't got around to fully testing yet - but let me throw out an interesting scenario on my list of tests to do.
> Rogue host A takes an IPv4 packet and encapsulates it in an SRH - the First sid in there is any v6 router you like on the path - the packet gets 
there - it get de-encapped - same as everything I've said before.  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