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

[Warren Kumari <[e-mail]>]

On Mon, Oct 25, 2021 at 6:18 PM Andrew Alston <Andrew.Alston=
[e-mail]> wrote:

> It would help to have a dedicated prefix - as a start - does it really
> solve the issue though.
>

That depends on what we are meaning by "the issue" -- I think that it is
more "issues" :-)

What it does do is allow me to filter out *your* SRH traffic at my border
ingress (and also makes it easier for you to filter at egress) - this gets
us something that looks and behaves much more like an MPLS edge.

I fully agree that it doesn't protect against a compromised host that is
participating in the limited domain itself -- but, hopefully it does limit
some of the fallout from that to just within the domain itself. Sorry to
sound uncaring, but if you end up with a compromised server creating
malicious packets within your SRH domain, I'd much rather that they
only affect you and not me :-)
Having a crunchy edge may also help with determining what should actually
participate in the limited domain -- if you include a stack of cloud
servers participating in SRH, yes, they are now able send SRH packets. This
is a conscious decision that you've made -- it might be a perfectly fine
one, but you've intentionally extended the edge of the domain to include
this. In my ideal scenario, this prefix is by default filtered, and you'd
need to explicitly allow it on a per interface basis.


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


I much much prefer a separate ether-type -- but I suspect that that ship
has sailed.


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


I'm assuming that in this scenario your "Rogue host A" is one that has
intentionally added to the SRH domain (either by allowing your new
ether-type, or manually removing the "limited domain prefix filter")? If
so, then yes, bad things happen. This seems largely the same as "I decided
to add "Rogue host A" to my MPLS domain so it could MPLS", or I added
"Rogue host A" to my IGP, because reasons...
Making a host able to influence routing, whether it is part of
something like MPLS, SR<something>, or in your IGP makes that host able to
do bad things...

W


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


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra