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

[Andrew Alston <[e-mail]>]

> Is one of the points made the fact that BCP38 would not work with 
> RFC8754? Maybe an option is to update BCP38 or write another one titled 
> "multi-version and multi-source IP ingress filtering", or simply an 
> "IPv6 ingress filtering". Or maybe an IPsec-enabled SRH.

The issue is not really BCP38 itself - BCP38 is fine - the issue here is dynamic de-encapsulation.

Effectively - anything that can cause an arbitrary transit node to de-encapsulate and forward.  Once you can get a packet encapsulated, sent onto the network, and de-encapsulated by a random router, which then takes that internal packet and forwards it - unless you can read deeply enough into the packet to understand the internal packet and filter it, and have some seriously magic sauce that allows every transit node to know what to do with every internal packet - you have a problem.

Normally in a tunnel situation - the tunnel is de-encapsulated at specific configured points with specific behavior - in the SRv6 case - the moment it hits the first sid, the outer header is stripped and the internal - whatever it is - is forwarded via the FIB, and I know of no possible way to actively filter against that inner packet.  This is particularly true when no matter how deep you can look into the packet - another header can always be added to screw with this.

For example:

Lets consider I have a host of 2001:db8:30:30::10.

I craft an internal IPv6 packet with source 2001:db8:10:10::2 and destination address 2001:db8:20:20::2 

Now lets assume that we're using compression and my locator block is 2001:db8:30:: and I'm using a 16 bit SID of 5

I encapsulate that packet with an SRH with SA of the original host address (2001:db8:30:30::10) and DA 2001:db8:30:5:: and set it up so that’s the only sid.
The node sid 5 is at - will de-encap and forward - BCP38 fails at this point because the source passes the check - and the node where the de-encap occurs doesn't care, its gonna de-encap and forward regardless.

So - lets then take this a step further - and say I have fancy hardware that can look PAST an SRH - or a v6 header - and I still wanna be nasty.

I can craft a packet such that the outer header sends to 2001:db8:30:5::, the next header is again an SRH, and that sends to 2001:db8:30:6::, the next header is again an SRH, it sends to 2001:db8:30:5::, and then it de-encaps. 

My de-encap happens at the same place - but there is no way that I could ever look deep enough into the packet to see the *REAL* packet that’s gonna end up flowing after that de-encap - because no matter how deep you go - I can keep stacking headers.

The argument is going to come that - I can just filter for anything with an SRH - except, firstly, this assumes that every edge device I plug servers into can match and filter SRH - and I can point to plenty of ipv6 devices deployed out in the field out here that would have issues here, second, it assumes that there is sufficient tcam space to apply interface specific filters to every interface I may have a server in - this is no longer just "edge of the network" specific - because every in effect host because an "edge" for the purposes of this, and thirdly, it assumes that there is an SRH at all.

In the case of there NOT being an SRH - I have to start filtering on the locator block - that’s an LPM filter on every port/sub-interface that is not using SRv6.  There is no fail closed here as there would be with something like MPLS or anything with its own ether-type that has to be explicitly enabled.  Then, if we extend this scenario into the cloud.  You can end up in a situation where you have thousands of vlans facing a cloud stack - each of those will need a filter to protect, and there can never be a situation where one host is permitted to talk SRv6 that finds itself off an interface that contains other hosts that aren't - because you can't selectively filter in any realistic manner (Try doing SA/DA filter combinations across a few thousand interfaces with interface specific filters - see how long your tcams last)

Effectively - in very simple summary - when you make your "trusted" edge this wide - where every server on the network is a potential threat to inject packets the network is going to blindly act on - things get unmaintainable fast unless you have a default fail-closed scenario - that does not exist here.  We went through similar with normal source routing - we went through similar with RH0 - but here - we have created a way to effectively embed packets - have them flow onto the network - de-encapsulate them with zero real control - and forward them.  That, from an operator perspective, is a nightmare.

Andrew