QUIC, Quinn & Crust: an update

This is a repost of a Medium post. Please feel free to support the original article with claps.

Quinn. quic-p2p. You may have seen these two words pop up in our weekly dev updates for the past couple of weeks, so we thought it was about time we explained to you, in some more detail, what is going on.

We’ll start off with a super quick glossary.

  • QUIC (Quick UDP Internet Connections) is a specification. QUIC is the solution to a number of transport and application layer problems. Whilst it’s very similar to TCP and TLS, it’s implemented on top of UDP.
  • Quinn is the crate we’re adopting QUIC from.

QUIC: A Brief History

So where did QUIC come from? While we may not agree with their surveillance capitalistic practices, QUIC originated at Google — but stay with us. It was an experimental network protocol designed by Jim Roskind who worked at Google at the time. They deployed it across Chrome, YouTube and Search as well as other services to allow them to observe the protocol in action. However, the version that Google developed is very different to how it looks today. From the wire format of the packets, to the handshake and the mapping of HTTP, QUIC grew organically thanks to open collaboration and a shared goal by many developers of making the Internet faster and more secure.

How the SAFE Network Uses QUIC

Originally, MaidSafe did not intend to build a network library. We developed Crust, an open-source library that enabled computers to connect to each other on a peer-to-peer network, because nothing existed with the features we needed. Never content to stand still, we looked at other libraries (such as uTP) but found that they all lacked our vision of a fully-secured networking library.

We then identified that we could achieve the same objectives by using open source code based on the QUIC specifications. The Quinn crate is an open-source implementation of QUIC that has been developed in Rust (the programming language of choice for the backend of the SAFE Network). We made the decision to replace Crust with QUIC. We’ve named our library quic-p2p because we wanted the name to be self-explanatory (we’re using the QUIC protocol to code our p2p library). Plus it’s pretty catchy, don’t you think?

So why have we moved from Crust to quic-p2p?

Crust was built upon TCP and provided the basis for all additional protocol engineering. QUIC is different. It’s a fully-formed, single protocol so there is no requirement for any additional protocol engineering. Secondly, its ready…almost. It’s been adopted by the IETF and whilst that standard may evolve over time, any future changes won’t affect the functionality that it already has today that we’ll be relying on. Plus our ambition is to get to full launch as speedily as possible which means we’re more than happy to utilise existing solutions; this is open development and open source at its best. QUIC is also fast, can setup connections cheaper than TCP and can accept hole punched (UDP) sockets. And last but not least, QUIC already has functionality that we were building into Crust. So why wouldn’t we grab the opportunity to build on work that solves our problems?

So is Quinn better for the SAFE Network than Crust?

In a word — yes. There are three main advantages;

  1. Encryption : QUIC sits upon UDP protocol and it’s encrypted by default. Crust would previously have dealt with this by encrypting before sending anything through TCP (because TCP isn’t encrypted itself). However in the new world, QUIC has encryption with built-in TLS certificates — so encryption is free.
  2. Multi-streaming : Another issue with TCP is head-of-the-queue blocking . In other words, whatever arrives first in the queue gets delivered first. An application treats a stream of bytes sent via a TCP connection essentially as FIFO. For example, if you send 1GB of data and then 1KB data, they’ll be received sequentially, biggest first. So this means subsequent smaller data can be left sitting in the pipes, held up until that first packet is received. QUIC does things differently. On the same pipe, you can open a stream and send different data down different channels simultaneously, so there’s no head-of-the-queue blocking. In Crust, we emulated this by using our chunking algorithm and priority queues. By adopting Quinn, we no longer need these things.
  3. IETF Approval : While QUIC is a living standard (in the sense that it is not finalised), it was adopted by the IETF in 2016. The standardisation of this provides added credibility for SAFE newcomers. While Crust was built on TCP (which of course is an IETF standard), the additions we built on top weren’t specifically addressed by the IETF.


There are many other benefits (such as prevention of IP spoofing, stateless retries etc.) that QUIC brings with it. Being a modern protocol, the specification has considered the shortfalls of the existing mechanisms studied over decades and addressed those issues in QUIC. And even better, we’re one of the first to actively use this protocol.

So there we have it. While Crust was the right solution for us to pursue until now, we’re hungry enough to understand that if better solutions exist that let us get the Network ready for you faster, without any compromises, we should take that opportunity and grab it with both hands. The move towards fully encrypted, secured private communications built on the efforts of a global community gives us solid foundations to build the SAFE Network.


Great that this provides so much to help speed up network launch!
Will it potentially delay Fleming?


Just a note to say that we’ve had a request to publish our Medium posts here on the forum as well because not everyone enjoys that particular platform. I’ll tag that at the top of the OP as well.


Should really publish pertinent information across all platforms you’re active on simultaneously to maximise potential views, not wait for the community to ask for each individual platform. Here, medium, twitter, reddit etc should all have the content pushed out on upon release.


Quite the opposite actually, it has some things we would have had to design for Fleming (and were), most importantly head of line blocking (multiplexed channels) and handling many connections on a single socket (we were designing a tcp live/active model that was really “bending” the protocol). So it is faster and more standards based, nice all round really.

[edit I should have said our crate is ready for publish right now, just a couple of tests/tweaks to be done, so the code is done and tested locally, we need to test on a testnet as well though)


Is it wrong to be most excited about this part? :joy:


So repository quic-p2p will replace crust? And TCP connections won’t be possible anymore? So in case a connection isn’t externally reachable and if UDP hole punching (I also see hole punching as TODO in the quic-p2p README.md) isn’t possible, you can’t try TCP hole punching anymore?
TCP hole punching was one of the things tested in the Crust tests.
Has hole punching less added value with quic compared to crust? If so, why exactly?
Not that I think that hole punching has a high priority (at the moment). I just want to have a better understanding of things.


It’s assumed that hole punching over UDP is easier than over TCP. In that QUIC is also advantageous.

The data below, for example, is from this Whitepaper


Yes hole punching over UDP seems to be easier than over TCP. But you have even a higher percentage if you can try TCP if UDP fails (or the other way around), like was done in the Crust tests I think.
I’ve also some reading extra to do concerning QUIC, e.g. https://blog.cloudflare.com/the-road-to-quic/ (the NAT chapter).


QUIC solves a lot of problems we have to solve manually (and were doing so) with TCP. Since the Net is expected to move more and more in favour of QUIC, UDP allowance is bound to see a surge if not already.

Well if Google will use it it’s already going to be ubiquitous :stuck_out_tongue: - plus just this morning I got from @dirvine that FB have open-src’d their QUIC impl - while I’ve I haven’t had a chance to see it yet here’s the link - think it’s C++.

Some of the rest of the benefits are already covered in the article I think.


SONM also uses QUIC

They have/had something called Double NAT penetration. for TCP, which is ‘hacky’ (I assume that is not good).


more sexy than hacky :smiley:


Really pleased by this. Seems better than maintaining a bespoke communications library.

QUIC has encryption with built-in TLS certificates — so encryption is free.

Presumably this isn’t tied to the existing web certificate authority infrastructure?

Am I right to assume SAFE will use QUIC for encryption but not for verification of identity through certificate chains?


No, this previously was an issue for us and our TLS relationship. Now it is much more secure and we can use our own ca if needed, we currently do not need certificates and probably never will (in terms of x509 things like valid-from valid-to etc.) but we can use routing for a safe CA that is either certs or just signature chaining of the keys themselves.

Yes, quin-p2p/crust verifies from known last contact or routing tell us what key the node should have at the network layer (so routing based validation if you like, at least for nodes, for clients we don’t need/use this). Routing then has a totally different set of keys and cryptography which allows us to separate these 2 much better now. Crust sometimes confused those keys, but not now.


What are the reasons to not base the new impl on libp2p?

1 Like

We did approach them for things like encrypt by default, hole punching/NAT traversal and bootstrap cache. Initially looked OK but they have settled on those being additional modules and not core principles. So that meant we would need to wrap libp2p and add all that ourselves, quic outdoes libp2p in many aspects (for us) and is easier to adopt.


I wonder if it is okay to trust TLS, it makes me a bit queasy to think about that.

The reason:

And that is the lastest of a very long list of attacks on TLS.


Barring protocol downgrades is essential if using 1.3 properly IMHO. For us we can as the nodes have no need to downgrade and if they did then all those 1.2 attacks are back in place. I think it is better we see these attacks and constant attacks. I fought against TLS previously for SAFE, bu t1.3 does make a big change to that. Having many eyes on the protocol certainly helps as these past attacks showed. However 1.3 does seem secure, but if you allow downgrading then you would be in trouble. It is hard for web services to force 1.3, but easy for us.


Well, okay even if RSA is not going to be supported at all and there is no possibility of cross-ciphersuit and no cross-protocol attacks in the Safe version of QUIC (as we have the luxury of building a whole network from zero and we can choose exactly which cipher to use and ban anything else)

What about the replayability and the lack of forward secrecy of 0-RTT?
Is that functionality going to be disabled?


At the moment it is not enabled, if it can be secured then that is great, but for now it is not enabled.