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

[Alexandre Petrescu <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>