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

Alexandre Petrescu <> Fri, 22 October 2021 06:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B7993A0875 for <>; Thu, 21 Oct 2021 23:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.667
X-Spam-Status: No, score=0.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mNx1F4iSp0xA for <>; Thu, 21 Oct 2021 23:02:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 975953A0874 for <>; Thu, 21 Oct 2021 23:02:12 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 19M629cj022523 for <>; Fri, 22 Oct 2021 08:02:09 +0200
Received: from (localhost []) by localhost (Postfix) with SMTP id 3FC83200D2D for <>; Fri, 22 Oct 2021 08:02:09 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 36942200CA6 for <>; Fri, 22 Oct 2021 08:02:09 +0200 (CEST)
Received: from [] ([]) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 19M628hd022407 for <>; Fri, 22 Oct 2021 08:02:08 +0200
References: <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Fri, 22 Oct 2021 08:02:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
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: Fri, 22 Oct 2021 06:02:20 -0000

Le 21/10/2021 à 19:08, Andrew Alston a écrit :
> Hi V6Ops,
> I thought I would raise the issues that follow here – and perhaps we can 
> look and if these issues are real – and if so – what the solutions are.
> During a close review of the compression proposals for SRv6 
> (CRH/G-Srv6/USID etc etc) I noticed some potential very real 
> vulnerabilities in SRv6 itself – which by extensions would affect srv6, 
> srv6 network programming and all the compression flavors – including CRH 
> on which I am a co-author.  Having raised these issues with my CRH 
> co-authors it was agreed that I raise these issues here so we could 
> discuss them.
> So a little background – SRrv6 is typically considered as something that 
> should run in the confines of a  “limited-domain” – the question I 
> started with is – can we actually define and maintain the boundaries of 
> a limited-domain – and if so – how.  The conclusion I came to was that 
> the concept of limited-domain in regards to SRv6 was an extremely fuzzy 
> thing.
> Now to understand this – we need first to look at the typical methods of 
> protecting things
>   * In the case of MPLS – we have what I will loosely refer to as a
>     “fail-closed” scenario – that is to say – unless MPLS is enabled
>     explicitly on an interface – ingress packets will not be processed –
>     this works because of a separate ether-type
>   * In the case of SR-MPLS – an identical situation occurs
>   * In the case of dodgy IGP traffic – again, we have a fail-closed scenario
>   * In the case of standard IPv6 – we have the option of utilizing BCP38
>     and ingress filtering – and the same thing in regards to IPv4.
> Now – lets examine SRv6 for a second.
> In a scenario of Host A (A linux box) with address 2001:db8:1:1::10/64 
>    utilizing a gateway of 2001:db8:1:1::fefe – packets from 
> 2001:db8:1:1::10 flowing towards that gateway would pass ingress filter 
> checks based on BCP38 since the source address was legitimate, unless we 
> explicitly filtered out where that packet could be destined for based on 
> its DA (More on this in a bit)

Is one of the points made the fact that BCP38 would not work with 
RFC8754?  Maybe an option is to update BCP38 or write another one titled 
"multi-version and multi-source IP ingress filtering", or simply an 
"IPv6 ingress filtering".  Or maybe an IPsec-enabled SRH.

Just some thoughts.


> Now, lets imagine for a second that Host A gets compromised – and an 
> attack encapsulates a packet that has an entirely different source 
> address – and whatever random DA address inside an SRH.  That SRH has a 
> SID list in it – be it via a direct SID or via compression mechanisms, 
> and a DA towards the SID itself.  The packet then routes – passing the 
> ingress checks – and landing up at the router with the first SID.  Since 
> this was the only SID in the list – the packet outer SRH is removed – 
> and the inner packet is forwarded to the FIB – and you just bypassed BCP38.
> In a similar mechanism, if the SRH states that the next protocol header 
> is an IPv4 packet – when the de-encapsulation happens at last SID – the 
> payload (the inner v4 packet) will then be forwarded via the FIB – and 
> off you go.
> Now, normally to protect against this as stated – an access list would 
> be placed on the networks borders to prevent encapsulated packets and 
> packets containing SID destinations from entering the network.  However 
> – if we consider the above scenario where the attack is coming from a 
> compromised server inside the traditional borders – we have a problem.  
> The application of access lists to every port containing a server is 
> also potentially unrealistic and unmaintainable (not to mention could 
> potentially on certain devices overload the TCAMs)
> We also have an even more potentially deadly issue – and this is 
> entirely theoretical at this point since I haven’t had time to really 
> investigate and test it with real code.  Let us presume in the above 
> that the same host A is compromised.  It encapsulates a packet with an 
> SRH – the internal packet is an Ipv4 packet – and its destined at a 
> broadcast address of an IP subnet that is bound to the same network as 
> the de-encapsulating router.  The source of the internal v4 packet is 
> spoofed – we’ve now managed to – through a use of the tunneling 
> mechanism, effectively created a version of an old tool called smurf – 
> in a manner that is going to be pretty hard to trace.
> Another potential scenario – would be for an attacker in host A to jit 
> some ebpf code – that matches – modifies and re-encapsulates incoming 
> return packets and retransmits then. Each time applying the same SRH.  
> The inner packet could be pretty much anything – so long as the internal 
> DA is set back to host A that is sending the packet.  The packet would 
> then flow out as an SRH encapsulated packet, the outer header would get 
> popped, the inner packet would flow back towards the original 
> compromised host, which would match it modify it re-encapsulate it and 
> start the loop again.  Doing this with ebpf and a kernel jit – would be 
> pretty difficult to spot if you didn’t know what you are doing because 
> you wouldn’t potentially see any obvious userland code.
> As a final thought – consider a hypervisor based system – that has 
> multiple VM’s on it – and the filtering implications of all of the above 
> – and the filtering becomes even more difficult to maintain and more 
> complex.
> Again – the filtering per every port that may contains a server or a 
> desktop – that may not be realistic – especially when we could be 
> running multiple ports that are handing out source addresses via RA – so 
> – how do we solve this – or is this a major flaw in srv6 itself – that 
> needs some other solution (give srv6 its own protocol code and 
> acknowledge that it isn’t ipv6 at all, allowing for a “fail-closed” 
> scenario maybe?)
> As an operator that runs extensive IPv6 – I’d really like to hear 
> thoughts and comments and potentially we can find a way to address these 
> issues.
> Thanks
> Andrew
> _______________________________________________
> v6ops mailing list