While WireGuard makes every sense for an FPGA due to its minimal design, I wonder why there isn't much interest in using QUIC as a modern tunneling protocol, especially for corporate use cases. QUIC already provides an almost complete WireGuard-alternative via its datagrams that can be easily combined with TUN devices and custom authentication schemes (e.g. mTLS, bearer tokens obtained via OAuth2 and OIDC authentication, etc...) to build your own VPN. While I am not sure about performance, at least when compared to kernel-mode WireGuard, since QUIC is obviously a more complex state machine that's running in userspace and it depends on the implementation and optimizations offered by the OS (e.g. GRO/GSO), QUIC isn't just a yet another tunneling protocol, it actually offers lots of benefits such as working well with dynamic endpoints with DNS instead of just using static IP addrs, it uses modern TLSv1.3 and therefore it's compliant with FIPS for example, it uses AES which can be accelerated by the underlying hardware (e.g. AES-NI), it currently has implementations in almost every major programming language, it can work well in the future with proxies and load balancers, you can bring your own custom, more fine-grained authentication scheme (e.g. bearer tokens, mTLS, etc...), it masquerades as just another QUIC/HTTP3 traffic that's used by almost all major websites now and therefore less susceptible to dropping by any nodes in between, and other less obvious benefits such as congestion control and PMTUD.
Why would anyone want to use a complex kludge like QUIC and be at the mercy of broken TLS libraries, when Wireguard implementations are ~ 5k LOC and easily auditable?
Have all the bugs in OpenSSL over the years taught us nothing?
FWIW QUIC enforces TLS 1.3 and modern crypto. A lot smaller surface area and far fewer foot-guns. Combined with memory safe TLS implementations in Go and Rust I think it's fair to say things have changed since the heartbleed days.
> I think it's fair to say things have changed since the heartbleed days.
The Linux Foundation is still funding OpenSSL development after scathing review of the codebase[1], so I think it's fair to say things haven't changed a bit.
1: https://www.openbsd.org/papers/bsdcan14-libressl/
[dead]
QUIC allows identities to be signing keys, which are used to build public key infrastructure. You need to be able to sign things to do web-of-trust, or make arbitrary attestations.
Wireguard has a concept of identity as long term key pairs, but since the algorithm is based on Diffie-Hellman, and arriving at a shared secret ephemeral key, it's only useful for establishing active connections. The post-quantum version of Wireguard would use KEMs, which also don't work for general purpose PKI.
What we really need is a signature based handshake and simple VPN solution (like what Wireguard does for the Noise Protocol Framework), that a stream multiplexing protocol can be layered on top of. QUIC gets the layers right, in the right order (first encrypt, then deal with transport features), but annoyingly none of the QUIC implementations make it easy to take one layer without the other.
"Have all the bugs in OpenSSL over the years taught us nothing?"
TweetNaCL to the rescue.
I've recently spent a bunch of time working on a mesh networking project that employs CONNECT-IP over QUIC [1].
There's a lot of benefits for sure, mTLS being a huge one (particularly when combined with ACME). For general purpose, spoke and hub VPN's tunneling over QUIC is a no-brainer. Trivial to combine with JWT bearer tokens etc. It's a neat solution that should be used more widely.
However there are downsides, and those downsides are primarily performance related. For a bunch of reasons, some just including poorly optimized library code, others involving relatively high message parsing/framing/coalescing/fragmenting costs, and userspace UDP overheads. On fat pipes today you'll struggle to get more than a few gbits of throughput @ 1500 MTU (which is plenty for internet browsing for sure).
For fat pipes and hardware/FPGA acceleration use cases, google probably has the most mature approach here with their datacenter transport PSP [2]. Basically a stripped down per flow IPsec. In-kernel IPsec has gotten a lot faster and more scalable in recent years with multicore/multiqueue support [3]. Internal benchmarking still shows IPsec on linux absolutely dominating performance benchmarks (throughput and latency).
For the mesh project we ended up pivoting to a custom offload friendly, kernel bypass (AF_XDP) dataplane inspired by IPsec/PSP/Geneve.
I'm available for hire btw, if you've got an interesting networking project and need a remote Go/Rust developer (contract/freelance) feel free to reach out!
1. https://www.rfc-editor.org/rfc/rfc9484.html
2. https://cloud.google.com/blog/products/identity-security/ann...
3. https://netdevconf.info/0x17/docs/netdev-0x17-paper54-talk-s...
Is quic related to the Chrome implemented WebTransport? Seems pretty cool to have that in browser API.
Now that's an interesting, and wild, idea.
I don't believe you could implement RFC 9484 directly in the browser (missing capsule apis would make upgrading the connection not possible). Though WebTransport does support datagrams so you could very well implement something custom.
MASQUE[0] is the protocol for this. Cloudflare already uses masque instead of wireguard in their warp vpn.
[0]https://datatracker.ietf.org/wg/masque/about/
i was curious about this and did some digging around for an open source implementation. this is what i found: https://github.com/iselt/masque-vpn
The purpose of Wireguard is to be simple. The purpose of QUIC is to be compatible with legacy web junk. You don't use the second one unless you need the second one.
QUIC isn't really about the web, it's more of a TCP+TLS replacement on top of UDP. You can build your own custom L7 on top of QUIC.
QUIC uses Web PKI and TLS. TLS is not a simple protocol and the main reason to use it over something simpler is if you need it to be compatible with something else that already uses it, like HTTPS.
You can build a custom L7 on top of anything, really. I think my favorite was tcp/ip over printers and webcams.
The question is what does QUIC get you that UDP alone does not? I don't know the answer to that. Is it because firewalls understand it better than native wireguard over UDP packets?
Mostly because WireGuard (intentionally) didn't bother with obfuscation https://www.wireguard.com/known-limitations/
> WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard, with WireGuard focused on providing solid crypto with a simple implementation. It is quite possible to plug in various forms of obfuscation, however.
This comment https://news.ycombinator.com/item?id=45562302 goes into a practical example of QUIC being that "layer above WireGuard" which gets plugged in. Once you have that, one may naturally wonder "why not also have an alternative tunnelling protocol with <the additional things built into QUIC originally listed> without the need to also layer Wireguard under it?".
Many design decisions are in direct opposition to Wireguard's design. E.g. Wireguard (intentionally) has no AES and no user selectable ciphers (both intentionally), QUIC does. Wireguard has no obfuscation built in, QUIC does (+ the happy fact when you obfuscate traffic by using it then it looks like standard web traffic). Wireguard doesn't support custom authentication schemes, QUIC does. Both are a reasonable tunneling protocol design, just with different goals.
I think maybe it's easier for an adversarial network admin to block QUIC altogether.
The hope with QUIC is encrypted tunnels that look and smell like standard web traffic are probably first in the list of any allowed traffic tunneling methods. It works (surprisingly) a lot more often than hoping an adversarial network/security admin doesn't block known VPN protocols (even when they are put on 443). It also doesn't hurt that "normal" users (unknowingly) try to generate this traffic, so opening a QUIC connection on 443 and getting a failure makes you look like "every other user with a browser" instead of "an interesting note in the log".
I.e. the advantage here is any% + QUIC%, where QUIC% is the additional chances of getting through by looking and smelling like actual web traffic, not a promise of 100%.
QUIC could be allowed, but only if it can be decrypted by the adversarial admin.
If the data can't be decrypted (or doesn't look like plain text web traffic) by the adversarial network admin, the QUIC connection can just be blocked.
Work laptops typically have a root cert installed allowing the company to snoop on traffic. It's not unfeasible for a nation state to require one for all devices either.
Are you arguing "QUIC has no more of a chance of getting through than Wireguard" or "QUIC doesn't stop all forms of blocking from working"? Nobody will disagree with the latter, regardless of protocol, but I'm not sure I follow on what these points have to do with the former.
Blocking QUIC blocks a sizeable fraction of the web
Encryption and reliable transport.
You really don't want reliable transport as a feature of the tunnel unless you are _intimately_ familiar with what all of the tunneled traffic is already doing for reliable transport.
The net result of two reliable transports which are unaware of each other is awful.
I probably should have clarified that question.
What does QUIC get you that TCP over Wireguard over UDP does not?
Where is DNS on top of QUIC? Asking unironically.
There is actually. A way more interesting re-implementation of a popular L7 is SSH over QUIC. SSH has to implement its own mutual authentication and transport embedded in the protocol implementation since it operates on top of plaintext TCP, but with QUIC you can just offload the authentication (e.g. JWT bearer tokens issued by IdPs verified at L7 or automatically via mTLS x509 certs) and transport parts to QUIC and therefore have a much more minimal implementation.
I feel like fans of `mosh` would run with this.
“Offloading” authentication onto complex web tech isn’t really a feature unless you already need to be operating in the web space for some other reason.
It is already there. It is called DNS over HTTP/3 (DoH3).
That's DoQ, RFC 9250.
What legacy junk is QUIC compatible with? It doesn’t include anything HTTP-related at all. It’s just an encrypted transport layer.
It’s multi stream, reliable connections. WireGuard’s encryption over UDP is none of those things. WireGuard encryption is simpler and far more flexible, but also less capable.
The assumed mentality of “being flexible” is the very reason WireGuard was created to fight against in the first place, otherwise why bother? IPSec is already standardized and with wide-spread hardware implementation (both FPGA and ASIC) and flexible.
Mullvad offers exactly the combination of wireguard in QUIC for obsfucation and to make traffic look like Https -- https://mullvad.net/en/blog/introducing-quic-obfuscation-for...
WireGuard-over-QUIC does not make any sense to me, this lowers performance and possibly the inner WireGuard MTUs. You can just replace WireGuard with QUIC altogether if you just want obfuscation.
It's not about performance, of course. It's about looking like HTTPS, being impenetrable, separating the ad-hoc transport encryption and the Wireguard encryption which also works as authentication between endpoints, and also not being not TCP inside TCP.
You can just do that by using QUIC-based tunneling directly instead of using WireGuard-over-QUIC and basically stacking 2 state machines on top of one another.
TCP over Wireguard is two state machines stacked on each other. QUIC over Wireguard is the same thing. Yet, both seems to work pretty well.
I think I see your argument, in that it's similar to what sshuttle does to eliminate TCP over TCP through ssh. sshuttle doesn't prevent HOL blocking though.
TCP over WireGuard is unavoidable because that's the whole point of tunneling. But TCP over WireGuard over QUIC just doesn't make any sense, neither from performance nor from security perspective. Not to mention that with every additional tunneling layer you need to reduce the MTU (which is already a very restricted sub-1500 value without tunneling) of all inner tunnels.
> But TCP over WireGuard over QUIC just doesn't make any sense
Agreed, but that wasn't what I was saying. Read it carefully next time before downvoting.
If the argument is if wireguard is a state machine, well, TCP over wireguard is just fine. And that's exactly what I said.
Probably simplifies their clients and backends I'd imagine?
See also Obscura's approach of QUIC bridges to Mullvad as a privacy layer: https://obscura.net/blog/bootstrapping-trust/
Why are you taking from people their will to experiment and design new stuff? Are they using your money or time? Is this just out of grumpiness, envy, condescension or what?
I think with a comment like this you have absolutely no clue what is relevant for adoption.
Adoption is about offering something that is 1) correct 2) easy to install 3) has reasonable performance 4) stable.
Wireguard provides all of those. OpenVPN was not meeting criterium 1 even a few years ago and IMO, if it doesn't work after a decade of development, it's _never_ going to work.
Now, let's look at your comment, which is full of techno mumbo jumbo (don't worry, I know everything you talk about), doesn't even mention half of those.
I think an extremely naive, but popular position is that when someone comes out with some new tool that "works on their machine", that they assume that everyone else believes immediately that they are not just as stupid as everyone that came before them. This was even true for Wireguard, since Wireguard was _not_ bug free either. In fact, one could argue that Wireguard is still an amateur project despite it working stable for some of my systems.
The problem with software like Wireguard is that there is no incentive to actually make bug free software. If software always works and has all the required features, nobody will call the person or company associated with it anymore. When was the last time that the author of "grep" was recognized as a great programmer? Never. Now, I am not saying that grep is free of bugs, but I just took a fairly stable program as an example. An economy for software like SaaS has much better incentives in that regard (even though they often also do not reach bug free status). curl is also an excellent example of bug ridden software that an entire industry is using, while it is written by an amateur (that has no incentive whatsoever to produce something that doesn't need to have bugs fixed).
If humanity had somewhat more of a collective intelligence, a million people would come together and just all paid $100 to implement a wireguard replacement (possibly even using the same protocol) to perfection such that no new implementation would ever be needed and that would adapt to any hardware automatically. Instead we prefer to continue to fuck around with inferior shit all day long.
> When was the last time that the author of "grep" was recognized as a great programmer? Never.
Ken Thompson wrote grep, and he is definitely recognised as such.
man -T grep | grep 'Free Soft\|Thom'
Sure, he wrote _a_ version of grep, and probably the first, but who cares? "The" (sure, you might run some bsd grep) current version of grep certainly doesn't.No, he wrote grep. Before he wrote it there was no grep. And yes, he's recognized as a great programmer. With Multics, Unix, B, C, UTF-8 Plan9, Inferno and grep to his name (and probably others that I forgot) he has more than deserved that.
Future grep versions, including the FSF one, were all re-implementations.
Your statement in the GP is nonsensical.
I do not agree he was a great programmer. All of his programs are trivial from a computer science perspective.
In fact, you can quite easily check this by trying to let an LLM generate a program like grep. It can do that. Now, there also exist programs for which LLMs can't generate code, because it's too complex.
You have absolutely no idea what you are talking about. And that's fine but it is kind of adding a lot of noise and zero signal.
I have a research degree in computer science from one of the best universities on the planet, I have been using Unix systems for over 25 years, have been the go to person for billion dollar companies (you know the person they beg for help), and I don't know what I am talking about?
I have even used Plan9 and the silly editor.
I probably have forgotten more than you (or Thompson) has ever known.
Thompson is an amateur, because all of his programs are of "trust me, bro"-quality. Call me when Ken (and all the n00bs from that era) grows up and implements grep in Rocq.
Yes, so you say, and I'm the pope on alternate Sundays. Appeals to authority are meaningless without identity. Meanwhile, I highly doubt you are qualified to polish Thompson's shoes, all I see is an AC novelty account making dumb claims with hindsight. Anyway, enough with you, off to the ignore list.
I'm just saying this is incorrect:
> When was the last time that the author of "grep" was recognized as a great programmer? Never.
He is recognised as that. Your opinion on him is nothing to do with anything.
I think standards operate according to punctuated equilibrium so the market will only accept one new standard every ten years or so. I could imagine something like PQC causing a shift to QUIC in the future.
Quic is a corporate supported black hole. Corporations are anti-human. Its a wonder that there is still some freedom to make useful protocols on the internet and that people are nice enough to do that