Non-Standard Standards (SRv6)
Firstly a disclaimer — everything written below is written in my personal capacity and is in no way stated as representative of the views of any third party, be it a company or person, to whom I am associated. Furthermore, what is stated as below are observations made in a laboratory environment, and should there be any inaccuracies I am open to corrections by the vendors involved and will be happy to publish any corrections should it be proved that my conclusions are in any way inaccurate.
I’ve written a fair bit about SRv6 in various places, and why this standard and the associated standards are a horrific security mess. Today however, I need to talk about why SRv6 is a non-standard standard and why, if you choose to go this route, you are effectively locking yourself into a single vendor network, unless, you buy your edge from the one vendor that can actually do this.
So, here is the thing — SRv6 can run in two modes — with an SRH, or in “compresssed mode”, using what is known as either u-sid (or what they call NEXT behavior) or g-sid (what they call REPLACE behavior).
In our lab tests, only Juniper could actually do SRH header insertion at the edge. In a multitude of tests, we found that Cisco could process an SRH if it existed, but despite multiple test attempts on our part, it did not appear that Cisco could insert the SRH at the edge.
Juniper, cannot process u-sid or g-sid, and this is reasonable, since neither of these things have been standardised and as of right now, have not even been adopted as working group drafts by spring pending a document in the 6man working group which is being worked on.
Huawei, we did not test at the edge, but from observations it seems they only support the replace behavior (not supported by Cisco or Juniper).
The net result is, while vendors are out there trying to sell the world SRv6, and creating fancy documents about how this stuff works together and everyone that is running it, we now have a situation where you have 3 entirely different behaviours, and the companies who’s staff lead authored the documents that are being touted as “record speed standardisation”, do not seem to be able to actually be able to implement their own standards.
What this means is, if you wish to run SRv6, despite all its security holes, you have a few fairly limited options. You can lock yourself to a single vendor, and effectively enter the world of proprietary protocols and vendor lock-in. You can also make a choice to lock yourself to one vendor at the edge and one vendor in the core, to get some kinda inter-op going, but you’re locked if you do that either way.
Or as an alternative — you can avoid the security risks, and simply use SR-MPLS which makes so much more sense in my opinion.
My question is, what happened to the inter-op tests, what happened to the adoption draft, what happened to actually verifying stuff before we standardised it. By the very fact that at least one of these three vendors cannot insert SRH at the edge, this means the testing had to be done generating that SRH on third party gear that wasn’t even their own.
Wow — either we got very mislead — or something went very wrong. So the question is, where to from here? How do we get to a point where we avoid this mess in the future. Because now, we have the ultimate nightmare, effectively, a standard that is no-standard at all.
