QUIC visions of OSI

New York Times Style Magazine had an article last week about the Italian town Ivrea, which you have probably never heard about.

Neither had I, 30+ years ago, when I got sent there as part of a project to migrate the European Parliament from OSI protocols to TCP/IP.

What ? You thought OSI protocols were only a theory ?

Nothing could be further from the truth.

One of the major reasons we are being bothered by Indian “Microsoft Support” all the time is that the global telephone network runs on Signalling System Number 7 (“SS7”) which is very much an OSI protocol.

Your electricity meter very likely talks DLMS(/COSEM), which is also an OSI protocol.

In both cases, it cost serious money to just get to read the relevant standards, which is why they could persist in this madness undisturbed for decades.

ITU-T finally saw the light a few years back, so now you can actually Read Q.700 if you do not belive me.

Anyway, back in Luxembourg in the tail end of the 1980’ies, the European parliament ran OSI protocols, and it sucked, and the more I dug into “The Red/Yellow/Blue Book”[1], there more obvious it was that these protocols were totally unsuitable for use on a local area network.

We proposed to migrate the European Parliament to use TCP/IP, and we did, which gave me a memorable year in Ivrea, but we could only do so on the explicit condition, imposed by the European Commission, that the parliament would migrate back, “…once the issues with the OSI protocols were sorted out.”

They never sorted them out, because the OSI protocols were designed and built by people who only considered communication between different buildings, cities, countries and continents, but not what happened inside each individual building [2].

Having seen the title of this rant, you can probably already see where I’m going with this, and you will be mostly right.

The good news is that IETF learned their lesson, so QUIC is not being rammed through and rubber-stamped the way HTTP/2 was, in fact, one could argue that IETF got their revenge by handing QUIC over to their arc-nemesis: The Transport Area.

I think that was a good thing, because pretty much all of my predictions about H2 came true, from the lack of benefits to the DoS exposure designed into it.

All those aliments came by because the people who pushed “H2 the protocol previously known as SPDY” only considered the world from the perspective of a huge company with geo-diverse datacenters for whom packet loss is something that happens to other people and congestion is solved by sending an email to Bandwidth Procurement.

But those concerns are precisely what the “dinosaurs” in the Transport Area care about and have studied and worked on for decades, so there is every reason to expect that QUIC will emerge from the Transport Area much better than it went in.

While I was pretty certain that H2 would be a fizzle, I have a much harder time seeing where QUIC will go.

On the positive side, QUIC is a much better protocol, and it looks like the kind of protocol we need in an increasingly mobile InterNet where IP numbers are an ephemeral property. This is the carrot, and it is a big and juicy one.

In the neutral area QUIC is not a simple protocol, it is a full transport protocol, which means loss detection, retransmission, congestion control and all that, but you do not get better than TCP without solving the problems TCP solved, and those are real and hard problems.

On the negative side, QUIC goes a long way to break through barriers of authority, both by putting it on top of UDP to get it through firewalls, but also by the very strong marriage to TLS1.3 which dials privacy up to 11: Everything but the first byte of a QUIC packet is encrypted.

Authorities are not going to like that, and I can easily see more autoritarian countries outright ban QUIC, and to make that ban stick, they may even transition from “allowed if not banned” to “banned if not allowed” firewalling.

Of couse QUIC would still be a thing if you are big enough to negotiate with G7-sized governments, and I would not be surprised if QUIC ends up being a feasible protocol only for companies which can point at the “job creation” their data-centers provide.

The rest of us will have to wait and see where that leaves us.

QUIC and Varnish

I can say with certainty that writing a QUIC implementation from scratch, including TLS 1.3 is out of the question, that is simply not happening.

That leaves basically three options:

  1. Pick up a TLS library, write our own QUIC

  2. Pick up a QUIC library and the TLS library it uses.

  3. Stick with “That belongs in a separate process in front of Varnish.”

The precondition for linking an TLS library to Varnishd, is that the private keys/certificates are still isolated in a different address space, these days known as “KeyLess TLS”.

The good news is that QUIC is designed to do precisely that [3] . The bad news is that as far as I can tell, none of the available QUIC implementations do it, at least not yet.

The actual selection of QUIC implementations we could adopt is very short, and since I am not very inclined to make Go or Rust a dependency for Varnish, it rapidly becomes even shorter.

Presently, The H2O projects quicly would probably be the most obvious candidate for us, but even that would be a lot of work, and there is a some room between where they have set their code quality bar, and where we have put ours.

However, opting to write our own QUIC instead of adopting one is a lot of work, not in the least for the necessary testing, so all else being equal, adopting sounds more feasible.

With number three we abdicate the ability to be “first line” if QUIC/H3 does become the new black, and it would be incumbent on us to make sure we work as well as possible with those “front burner” boxes using a richer PROXY protocol or maybe a “naked” QUIC, to maintain functionality.

One argument for staying out of the fray is that our “No TLS in Varnish” policy looks like it was the right decision.

While it is inconvenient for small sites to have to run two processes, as soon as sites grow, the feedback changes to appreciation for the decoupling for TLS from policy/caching, and once sites get even bigger, or more GDPR exposed, the ability to use diverse TLS offloaders is seen as a big benefit.

Finally, there is the little detail of testing: Varnishtest, which has its own VTest project now, will need to learn about HTTP3, QUIC and possibly TLS also.

And of course, when we ask the Varnish users, they say “Ohhh… they all sound delicious, can we have the buffet ?” :-)

phk

Footnotes