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

[Mark Smith <[e-mail]>]

The ULA address space is designed for this.

If a single /48 isn't big enough, generate another one.

However, that doesn't, nor will a new IANA /16 solve the leaks out of a
"controlled domain" problem.

Only the following solve that:

- a default free network (networks' default routes are what makes packets
try to leave by default (leak) if there is no matching local destination).
This won't solve the unauthorised host inside the network problem.

- authenticated packets such that unauthorised or unintended nodes cannot
send or receive them and successful process them i.e. AH at a minimum. That
solves the problem, however then you have the key management issue.

- a local network only protocol such as MPLS, limited to use within the
network, rather than a general purpose host-to-host/end-to-end global
internetworking protocol like IPv6. Not as good as the authenticated packet
option, however as long as hosts don't have this protocol enabled by
default it is better than the default free network option.

For a new IANA prefix to be assured closed, it would have to be null routed
in every router by default at the factory that could conceivably be used in
an SRv6 domain. The safest thing would be for this null route to be present
by default in literally every IPv6 router.

That sort of constraint hasn't worked 100% reliably with IPv6 Link-Local
addressed packets. They're supposed to be trapped on the link if they have
either an LLA source or destination address.

However, they are known to leak off when the DA is a GUA and the SA is a
LLA because router implementations aren't doing SA filtering. That can
happen fairly easily - if a host receives a GUA DNS resolver addresses, but
for some reason doesn't have a GUA SA to use, and has a defaultIPv6  router
(i.e. the RA doesn't have PIOs in it - and I've seen a broken residential
IPv6 CPE do this in the last couple of months) default address selection
says to fall back to using an LLA SA for all DNS queries to the GUA DA.


Regards,
Mark.


On Tue, 26 Oct 2021, 11:40 Andrew Alston, <Andrew.Alston=
[e-mail]> wrote:

> 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]> 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
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>