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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 22 October 2021 06:02 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7993A0875 for <v6ops@ietfa.amsl.com>; Thu, 21 Oct 2021 23:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.667
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNx1F4iSp0xA for <v6ops@ietfa.amsl.com>; Thu, 21 Oct 2021 23:02:12 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975953A0874 for <v6ops@ietf.org>; Thu, 21 Oct 2021 23:02:12 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 19M629cj022523 for <v6ops@ietf.org>; Fri, 22 Oct 2021 08:02:09 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3FC83200D2D for <v6ops@ietf.org>; Fri, 22 Oct 2021 08:02:09 +0200 (CEST)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 36942200CA6 for <v6ops@ietf.org>; Fri, 22 Oct 2021 08:02:09 +0200 (CEST)
Received: from [10.14.1.78] ([10.14.1.78]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 19M628hd022407 for <v6ops@ietf.org>; Fri, 22 Oct 2021 08:02:08 +0200
To: v6ops@ietf.org
References: <CB45220A-ECE6-492A-8A37-D189A71CDA2B@liquidtelecom.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <61f1f956-1ebd-3b62-078c-03d9f8fee42c@gmail.com>
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: <CB45220A-ECE6-492A-8A37-D189A71CDA2B@liquidtelecom.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Nh9t5uzSgcXS1Lv_9ZjzfNTXnhA>
Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=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.

Alex

> 
> 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>