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

[Warren Kumari <[e-mail]>]

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

> 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...
>
>
>
> See that’s the thing Warren – with MPLS – it’s a default fail-closed
>
Nod. It sounds like you think I'm disagreeing with you, which confuses me
some -- I think that we are both looking for a failed closed system.

> – with a prefix list that has to be applied to every interface – well –
> things get missed.
>
Yes. Hence my "by default it would be applied".

In the same way I manually add an interface to MPLS:
protocol {
   mpls {
       interface et-0/0/0.0;
   }
}

I would manually add the interface to allow SRH:
protocol {
   srh {
   interface et-0/0/0;
   }
}
(or perhaps something like "set interface et-0/0/0.0 family srh allow'", or
whatever).

The solution would default to fail-closed -- there is a default "deny
$srh_prefix" on the interface and I manually permit it by telling the
device that the interface participates in SRH (or whatever other limited
domain protocols are defined to use space). The above example has some
syntactic sugar, but the actual implementation is simply that the device
allows packets from $limited_domain_prefix when you set this...



>   And these prefix lists would have be applied to every L3 interface – and
> again – I fear you’re going to have tcam problems if you try and apply an
> LPM filter to every interface on a massive device with thousands of
> interfaces.  You can’t apply filters in the way you would for CoPP – these
> become specific prefix filters.
>

I don't think that it is a specific prefix filter (or I'm misunderstanding
you) -- if you add the interface to the SRH limited domain, the filter
blocking the (well-known) prefix is removed. It's a single, well known
prefix.



> I’m just convinced that’s either practical or it’s going to really work,.
>

I think that my proposal is largely the same as a different ether-type - it
is implemented as a default block ACL, which is removed when you add the
interface to the domain (instead of allowing a different ether-type).
Depending on implementation it may burn a single TCAM slot per interface,
but implementing it should be simple....

> Also – if you look at the scenario I sketched – that rogue doesn’t doesn’t
> just affect you – because if it changes the source of the inner packet and
> causes it to broadcast – the replies are going to affect things on a far
> wider basis – your routers just became amplifiers for an attack aimed
> externally.
>

Yes, we are in full agreement.

>
>
> You are right – the ether-type may have sailed – but as I said – so far –
> my tests indicate that a single host would allow you to launch far more
> damaging attacks in this scenario than it would if it couldn’t inject weird
> packets
>

Again, I fully agree.... which is why we don't want unexpected hosts to be
able to do this :-)

W


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


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