That said, the architectural multiqueue improvements and memory optimizations are useful starting points to build on for every platform.

My implementation relied on the extremely finicky Linux kernel IPsec and would never have worked in userspace macOS or windows. But yes, a Tailscale control plane with a per-node switchable data plane, one of which is IPsec with PQC, is a real option that would work.

By locking down the control plane it becomes incompatible with classic IPsec, but also avoids most of the security gotchas that plagued IPsec.

Things like Google’s PSP already achieve that while still being hardware acceleratable: https://github.com/google/psp

Post-quantum negotiation will kinda suck but you don’t have to sacrifice everything.

That said, note that if you run your own DNS server on your tailnet, the regular UDP DNS is automatically private because it’s carried over Tailscale. That’s the most common setup for non-SaaS DNS servers. DoH doesn’t really add anything in that arrangement. (And it’s more fiddly because you need to get and refresh a TLS cert.)

For really high bandwidth cases, things like DPDK are the long term best choice and are primarily userspace, for good reasons. Kernel mode is not the pure benefit it once was (if it ever was).

Separately, wireguard itself has a problem that the crypto suite it uses is not supported by hardware accelerators. So if we want to get into the hundreds of gigabits range, we will possibly need to switch packet formats entirely. (But, wireguard also needs to update to support post-quantum so maybe they’ll fix both problems at the same time and we can join in.)

Bugs that are found by other people are found, by definition, after release. They are therefore more likely to need a bulletin.

It's true that those two audits aren't the same thing. However, the SOC2 auditor confirms, in the published report, that Tailscale has regular and ongoing security audits including penetration tests and many kinds of code reviews.

The security audit report, which you perhaps imagine to be a long list of vulnerabilities... doesn't look like that. It says we don't have a long list of vulnerabilities. The security bulletins are all here: https://tailscale.com/security-bulletins

Secondly, peer relays support UDP while DERP is TCP-only. That would be fixable by simply improving the DERP protocol, but as we explored that option, we decided to implement the Peer Relay layer instead as a more complete solution.

A separate goal I have personally: demonstrate that anyone can build really neat stuff directly on top of the "Tailscale platform." One of my rules for the Aperture team was, you're not allowed to change core Tailscale, you have to build entirely on top as if you were some partner company. So this is a demo of how anybody can make pretty slick, easy-to-use, and yet highly secure stuff by building on Tailscale (the open source packages, or the commercial product, or both).

Alas, the "apps and OSes are all willing to use IPv6" problem is a persistent one, so we have to make IPv4 work too.

To answer the question in another thread, node sharing also works with UDP. (Funnel is TCP-only due to the vagaries of IP addresses and TLS certificates when facing the outside world, sigh.)