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

[Andrew Alston <[e-mail]>]

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