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

[Andrew Alston <[e-mail]>]

Thanks Warren for the clarifications – I think we’re pretty much aligned, just my misreading of certain things – apologies for that.

The idea of a fixed prefix that is a default fail-closed in the way you proposed is certainly a major step in the right direction and I like that idea – it would address a LOT of my concerns.  By doing this we could also potentially avoid interface-specific filters and dependent on implementation not send up blowing up the tcams.

I think – the other thing we could consider is saying that we get potentially a /16 worth of space for this – and strongly suggest that to make up the first 48 bits we then append the asn in the next 32 bits – if you did this – you open the door to inter-domain controlled srv6 between operators – but without the risk of duplicate addressing etc.

So yeah – this is certainly worth considering

Andrew


From: Warren Kumari <[e-mail]>
Date: Tuesday, 26 October 2021 at 02:12
To: Andrew Alston <[e-mail]>
Cc: Gert Doering <[e-mail]>, Brian E Carpenter <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [v6ops] Security issues in RFC8754 and related/subsequent drafts?



On Mon, Oct 25, 2021 at 6:51 PM Andrew Alston <[e-mail]<mailto:[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<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


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