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

[Brian E Carpenter <[e-mail]>]

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  - 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 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
>