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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sun, 24 Oct 2021 20:55:17 +0000

***Without any hat except for caring about security, IPv6, and innovation***

Thank you for correctly specifying that this concern applies generally to RFC 8547. I really appreciate your honesty.

But, I fail to understand whether the issue is limited to SRH or is actually applicable to any tunnel ? As you described, in any encapsulation mechanism, BCP38 will be applied on the outer header in the ‘underlay’ and the encapsulated packet will indeed traverse any network until the endpoint [1]. Therefore, to handle the case when one endpoint of the tunnel is compromised, the other endpoint should apply BCP38 on the decapsulated traffic based on the other side of the tunnel.

There are many well-known attacks (see RFC 6169 or section 2.7.2 of RFC 9099 for IPv6) on any tunnelling mechanism from sniffing to injection and others.

About the looping attacks, there is no amplification here as the compromised host needs to generate N packets to force the non-compromised tunnel endpoint to generate N (shorter) packets. The RFC 6324 describes a related attack by with amplification using ISATAP.

It is clear that tunnel endpoints (whether GRE, ISATAP, IPsec, or even SRH) should not trust blindly any packets and should only decapsulate valid packets (based at the minimum on source address and applying BCP38 and infrastructure ACL at their edge — if applicable). In the case of SRH[2] (or any RH actually even MIPv6 or RPL), this function should not be enabled by default and must be configured correctly.

The specific case of C-SID without any SRH (except a pseudo one) does not change the above reasoning.

Finally, the traversed nodes are simply forwarding IPv6 packets (whether they are UDP, TCP, RH-0, SRH, ….) without specific processing: they are not impacted at all (and as you wrote they should apply BCP38 on the outer header for basic sanity checks for other reasons).

Or am I missing something ?

Sincerely happy and curious to continue the discussion,

Regards

-éric

[1] after all, many VPNs encapsulate RFC 1918 traffic over the global Internet and BCP38 does not trigger on Internet routes for those VPNs

[2] see also section 7 of RFC 8754

From: v6ops <[email-masked]> on behalf of Andrew Alston <Andrew.Alston=[email-masked]>
Date: Thursday, 21 October 2021 at 19:09
To: "[email-masked]" <[email-masked]>
Subject: [v6ops] Security issues in RFC8754 and related/subsequent drafts?

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)

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Oct 2021 08:21:50 +0200

Hi,

On Sun, Oct 24, 2021 at 08:55:17PM +0000, Eric Vyncke (evyncke) wrote:
> But, I fail to understand whether the issue is limited to SRH or
> is actually applicable to any tunnel ? As you described, in any
> encapsulation mechanism, BCP38 will be applied on the outer header
> in the ???underlay??? and the encapsulated packet will indeed
> traverse any network until the endpoint [1]. Therefore, to handle
> the case when one endpoint of the tunnel is compromised, the other
> endpoint should apply BCP38 on the decapsulated traffic based on
> the other side of the tunnel.

It is applicable to any tunnel that will decapsulate packets from
arbitrary (outside) sources.

So, for example, a normal GRE tunnel would only accept packets from (outer) 
sources matching the configured "tunnel destination" peer address, and
you could configure BCP38 for the "inside" addresses (given that GRE
tunnels are usually presented as virtual interface with routes pointing
to it, and ACLs/BCP38 being applicable).

[..]
> About the looping attacks, there is no amplification here as the
> compromised host needs to generate N packets to force the non-compromised
> tunnel endpoint to generate N (shorter) packets. The RFC 6324
> describes a related attack by with amplification using ISATAP.

The looping attack is similar to what was described for RH0 - you send
one packet, but that packet traverses the target network multiple times,
pingponging between participating routers.

> It is clear that tunnel endpoints (whether GRE, ISATAP, IPsec,
> or even SRH) should not trust blindly any packets and should only
> decapsulate valid packets (based at the minimum on source address
> and applying BCP38 and infrastructure ACL at their edge ??? if
> applicable). In the case of SRH[2] (or any RH actually even MIPv6
> or RPL), this function should not be enabled by default and must
> be configured correctly.

So, if you turn on SR6 in your network, how would you protect said 
network against malicious hosts *in* your network?

Of course "not using SR6" or "block all EH from hosts" is a viable 
strategy, but might not be how the inventors intended things to be used...

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

---

From: Andrew Alston <[email-masked]>
Date: Mon, 25 Oct 2021 08:16:43 +0000

See Inline

I’m a little surprised that you would think I would do anything else – the problem is an srv6 problem – irrespective of tunneling mechanism – and there is absolutely no way to describe it outside of this.  I make an assumption here (correct me if I am wrong) that you are surprised based on my work on CRH – the reality is though – if the base (srv6) is as flawed as I believe it to be – and with the security holes I believe it to have, I would far rather see that work come to naught than for it to proceed while exposing the general internet.  If srv6 has to exist with all its flaws, then I still believe that the only way it will ever work is with a compression scheme, I just happen to believe that when srv6 is this flawed, it has to be fixed before we start stacking things on top of it – irrespective of it I have put effort into what we are stacking on top of it or not.

How do you propose to apply BCP38 to the decapsulated traffic when once the SRH is dropped and the inner packet is exposed – it is sent to the fib – and the decapsulation point may be anywhere on the network and not at all the final destination of the traffic.  I.E the packet post decapsulation keeps moving on the network – what’s the checkpoint?

“There are other attacks” has never been an excuse to create something with more attack vectors – and never will be.  That’s the equivalent of saying – because there are other buffer overflows in software we should forget any form of bounds checking.

The looping attack doesn’t create amplification as such – it creates a loop.  The amplification happens when you adjust the inner packet pre-decapsulation to point to things that amplify it (think multicast addresses, broadcast addresses in the case of an inner v4 packet etc)

Source verification in this particular case is entirely impractical – what you are proposing here is that every router carry an access list specifying every source host that can ever encapsulate an srv6 packet – and shoving the decapsulation of every packet through said LPM based access list – the performance hit trying to do that would be totally impractical and it simply wouldn’t work.

I think you’ve missed a fair bit 😊 See above.

Andrew

From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Andrew Alston <Andrew.Alston=[email-masked]<mailto:Andrew.Alston=[email-masked]>>
Date: Thursday, 21 October 2021 at 19:09
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [v6ops] Security issues in RFC8754 and related/subsequent drafts?

Hi V6Ops,

Thanks

Andrew

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 25 Oct 2021 12:00:46 +0000

Hello Gert,

Long time not see... I hope that all is well for you and your relatives

<still wearing not specific hat>

See below for EV> and I have elided some texts when we agree.

Regards

-éric

On 25/10/2021, 08:22, "Gert Doering" <[email-masked]> wrote:

...%<....%<.....

    [..]

EV> Of course RH-3 (RFC 6554) and RH-4 (RFC 8754) have the same issues as RH-0 and we all know that the RH-0 issue was documented a long time ago by RFC 5095. RPL & SRH are per design limited in a specific domain (and SRH can even have a HMAC TLV -- even if not protecting against a compromise SRH node)

EV> My reading of Andrew's original email is that the attack is different than the good old RH-0 attack: a compromised router A sends an encapsulated packet to B, which decapsulates and sends the decapsulated packet back to A, which is then re-encapsulated an so on... This is different than the RFC 5095 attack: an in-domain node must be compromised and there is only a x2 amplification by B sending the traffic to A. Of course, A could send its SRH with a convoluted route to 'burn' more bandwidth. But, honestly, if I 'pawned' a router, then I would rather attack the control plane than the data plane.

EV> it is clear that hosting VMs in your SRv6 'underlay' is probably not really wise ;-) 
EV> AFAIK, the SRv6 use cases are L[23]VPN or Data Center fabric. And in the case of MPLS-VPN, having a compromised P or PE router can also have devastating consequences. I.e., nothing really new under the Sun

EV> if a transit provider on the public Internet enables blindly RPL or SRH on her/his network, then this won't be really smart as well. The same applies for a vendor shipping routers/VM with RPL/SRH enabled by default.

EV> forwarding RH-3 or RH-4 on your network as long as the DA does not trigger any RH processing is perfectly fine of course (it takes 10 minutes to craft a SHR/RPL packet with scappy and send it anywhere and it will arrive at destination most probably)

    Gert Doering
            -- NetMaster