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

[Andrew Alston <[e-mail]>]

Except Brian,

Normally – a single rogue host because of other protections can’t do near this level of damage – because they can’t send packets that can get decapped in the middle of the network with no way to define what happens post decap with the inner packet.  Normally you could apply a whole range of measures to ensure that a single host may be able to send a stream of packets to some host – at that point – it gets found and stopped.  In this case – that rogue host now has the abiity to inject packets practically anywhere on the network that cause attacks to happen against external hosts – and good luck tracing it.

The ”magic” prefix lets you filter which hosts can send to SRH SID’s – but as I said – it’s far from perfect – because there are still a host of issues with that.  But – lets also be serious – the level of damage a single rogue host could do in these scenarios is wayyyyyy beyond what it could do if it couldn’t cause the decap and act on <insert random router anywhere in the domain>

Andrew


From: Brian E Carpenter <[e-mail]>
Date: Tuesday, 26 October 2021 at 01:20
To: Andrew Alston <[e-mail]>, Gert Doering <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?

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.

Regards
Brian

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 255.255.255.255<http://255.255.255.255> - 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 255.255.255.255<http://255.255.255.255> 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" <[e-mail] on behalf of [e-mail]> 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: [phone] USt-IdNr.: DE813185279
>