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

[Warren Kumari <[e-mail]>]

On Thu, Oct 21, 2021 at 1:08 PM Andrew Alston <Andrew.Alston=
[e-mail]> wrote:

> Hi V6Ops,
>
>
>
> I thought I would raise the issues that follow here – and perhaps we can
> look and if these issues are real – and if so – what the solutions are.
>
>
>
> During a close review of the compression proposals for SRv6
> (CRH/G-Srv6/USID etc etc) I noticed some potential very real
> vulnerabilities in SRv6 itself – which by extensions would affect srv6,
> srv6 network programming and all the compression flavors – including CRH on
> which I am a co-author.  Having raised these issues with my CRH co-authors
> it was agreed that I raise these issues here so we could discuss them.
>
>
>
> So a little background – SRrv6 is typically considered as something that
> should run in the confines of a  “limited-domain” – the question I started
> with is – can we actually define and maintain the boundaries of a
> limited-domain – and if so – how.  The conclusion I came to was that the
> concept of limited-domain in regards to SRv6 was an extremely fuzzy thing.
>
>
>
> Now to understand this – we need first to look at the typical methods of
> protecting things
>
>
>
>    - In the case of MPLS – we have what I will loosely refer to as a
>    “fail-closed” scenario – that is to say – unless MPLS is enabled explicitly
>    on an interface – ingress packets will not be processed – this works
>    because of a separate ether-type
>    - In the case of SR-MPLS – an identical situation occurs
>    - In the case of dodgy IGP traffic – again, we have a fail-closed
>    scenario
>    - In the case of standard IPv6 – we have the option of utilizing BCP38
>    and ingress filtering – and the same thing in regards to IPv4.
>
> <no hats>
Yes.

"RFC 8799 - Limited Domains and Internet Protocols" says:
"Domain boundaries that are defined administratively (e.g., by address
filtering rules in routers) are prone to leakage caused by human error,
especially if the limited domain traffic appears otherwise normal to the
boundary routers. In this case, the network operator needs to take active
steps to protect the boundary. This form of leakage is much less likely if
nodes must be explicitly configured to handle a given limited-domain
protocol, for example, by installing a specific protocol handler."

There are a number of protocols which naturally have the concept of domain
baked into them - you've listed some, but there are also things which
primarily are L2 based, like RA and VRRP and similar. Apart from those,
much of it seems to come down to "what is the default behavior for the
protocol on the interface" - things like MPLS or (generally) OSPF need an
intentional act to extend the edge of the domain, and also generally need
the sender and receiver to both take an action. If I accidentally enable
OSPF on an interface towards you, you are likely not harmed because you are
not going to be willing to form an adjacency unless you have also done a
stupid on the matching interface. The fact that "failure" also requires a
chain (each interface/similar along a path needs config with helps with
this too, as does things like authentication (which is often/usually used
to prevent "Ooops" instead of malicious attacks).

It feels to me like the concept of limited-domains is sometimes used like a
magic incantation to avoid having to answer some of the interoperability
and security questions and concerns. Saying that a protocol should (or
SHOULD or MUST) only be used in a limited domain doesn't actually enforce
that it will not leak. I also do not think that it is reasonable that the
protection / filtering to enforce limited domains should require the
(potential) recipient to have to change their filtering stance; I should
not have to change my filtering policy to protect *my* network against
*you* accidentally forgetting a filter at the edge of your network.

If we do expect potential recipients to have to update filters, there are 2
failure modes:
1: the recipient doesn't (or misses an interface), and bad things happen or
2: we end up in the "default-deny" mode, where networks block all packets
except those that they explicitly allow. This ossifies the network and
makes deploying new things impossible.
Networks that experience breakage of the first type will quickly move to
the second option...

Ed's suggestion below ("All router’s ports should have RH type 4 (SRH)
filtered out by default.") is already heading down this path.

The way I see this playing out is operators quickly moving along the lines
of:
If I'm expected to filter "RH type 4 (SRH)" on all of my external
interfaces in case someone else decides to run SRH, what else should I
filter? Clearly 5 and 6 (CRH-16/32)... and 7, 8, ... 255.
I need to be ready *before* you enable $insert_new_protocol_here, so the
only sensible thing for me to do is filter all RH/43. Oh, and I don't know
what sort of new uses there might be for Hop-by-Hop that might affect me,
so I should clearly just filter all protocol 0 (perhaps in the future I
might allow specific ones... maybe). HIP? I don't use that, but I might in
the future, and I certainly don't have time to follow all of the new things
being proposed in the IETF/by vendors, so obviously I should filter that
everywhere...
Actually, why am I bothering to write this long filter list? I'll just
allow TCP and UDP, and call it done...

(When I started writing the above I thought I would need to add a "Warning:
Hyperbole ahead" marker -- but I'm no longer sure that that's the case).


This path leads us to an ossified IPv6, and no ability to deploy new
protocols. We need a solution where the border of limited-domains is clear,
and automatic - and where the things touching the outside border don't need
to actively protect themselves from failures of the border protection,
W
</no hats>



>
>
> Now – lets examine SRv6 for a second.
>
>
>
> In a scenario of Host A (A linux box) with address 2001:db8:1:1::10/64
>   utilizing a gateway of 2001:db8:1:1::fefe – packets from 2001:db8:1:1::10
> flowing towards that gateway would pass ingress filter checks based on
> BCP38 since the source address was legitimate, unless we explicitly
> filtered out where that packet could be destined for based on its DA (More
> on this in a bit)
>
>
>
> Now, lets imagine for a second that Host A gets compromised – and an
> attack encapsulates a packet that has an entirely different source address
> – and whatever random DA address inside an SRH.  That SRH has a SID list in
> it – be it via a direct SID or via compression mechanisms, and a DA towards
> the SID itself.  The packet then routes – passing the ingress checks – and
> landing up at the router with the first SID.  Since this was the only SID
> in the list – the packet outer SRH is removed – and the inner packet is
> forwarded to the FIB – and you just bypassed BCP38.
>
>
>
> In a similar mechanism, if the SRH states that the next protocol header is
> an IPv4 packet – when the de-encapsulation happens at last SID – the
> payload (the inner v4 packet) will then be forwarded via the FIB – and off
> you go.
>
>
>
> Now, normally to protect against this as stated – an access list would be
> placed on the networks borders to prevent encapsulated packets and packets
> containing SID destinations from entering the network.  However – if we
> consider the above scenario where the attack is coming from a compromised
> server inside the traditional borders – we have a problem.  The application
> of access lists to every port containing a server is also potentially
> unrealistic and unmaintainable (not to mention could potentially on certain
> devices overload the TCAMs)
>
>
>
> We also have an even more potentially deadly issue – and this is entirely
> theoretical at this point since I haven’t had time to really investigate
> and test it with real code.  Let us presume in the above that the same host
> A is compromised.  It encapsulates a packet with an SRH – the internal
> packet is an Ipv4 packet – and its destined at a broadcast address of an IP
> subnet that is bound to the same network as the de-encapsulating router.
> The source of the internal v4 packet is spoofed – we’ve now managed to –
> through a use of the tunneling mechanism, effectively created a version of
> an old tool called smurf – in a manner that is going to be pretty hard to
> trace.
>
>
>
> Another potential scenario – would be for an attacker in host A to jit
> some ebpf code – that matches – modifies and re-encapsulates incoming
> return packets and retransmits then. Each time applying the same SRH.  The
> inner packet could be pretty much anything – so long as the internal DA is
> set back to host A that is sending the packet.  The packet would then flow
> out as an SRH encapsulated packet, the outer header would get popped, the
> inner packet would flow back towards the original compromised host, which
> would match it modify it re-encapsulate it and start the loop again.  Doing
> this with ebpf and a kernel jit – would be pretty difficult to spot if you
> didn’t know what you are doing because you wouldn’t potentially see any
> obvious userland code.
>
>
>
> As a final thought – consider a hypervisor based system – that has
> multiple VM’s on it – and the filtering implications of all of the above –
> and the filtering becomes even more difficult to maintain and more complex.
>
>
>
> Again – the filtering per every port that may contains a server or a
> desktop – that may not be realistic – especially when we could be running
> multiple ports that are handing out source addresses via RA – so – how do
> we solve this – or is this a major flaw in srv6 itself – that needs some
> other solution (give srv6 its own protocol code and acknowledge that it
> isn’t ipv6 at all, allowing for a “fail-closed” scenario maybe?)
>
>
>
> As an operator that runs extensive IPv6 – I’d really like to hear thoughts
> and comments and potentially we can find a way to address these issues.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
>
>
>
>
>
> _______________________________________________
> 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