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

[Warren Kumari <[e-mail]>]

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

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

Yes. I'm **certainly** not disagreeing that it's far from perfect....


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

Yup. Allowing a host to participate in making routing decisions (whether
that is participating in an IGP, or allowing it to steer its own traffic
and encap/decap) makes the host privileged. I'm trying to make it so that
it's harder for unprivileged things to accidentally (or maliciously) become
part of the privileged 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 - 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