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

[Andrew Alston <[e-mail]>]

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 – with a prefix list that has to be applied to every interface – well – things get missed.  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’m just convinced that’s either practical or it’s going to really work,.  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.



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



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<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]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops<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