apenwarr
Joined 19 years ago
Karma
1,645
Submissions
271
Member since
Mar 12
Recent submissions
Comment · 1 month ago
(Tailscale cofounder) Yes, that’s most of it. Most packet-level optimizations are necessarily platform specific and this post was mostly about the linux dataplane.
That said, the architectural multiqueue improvements and memory optimizations are useful starting points to build on for every platform.
Comment · 1 month ago
(Tailscale cofounder) Nothing to announce yet, but yes, we absolutely do sponsor wireguard, with money and with code.
Comment · 1 month ago
(Tailscale cofounder) Many years ago I made a VPN for experimental purposes that kept IPsec’s data plane but abandoned IKE. It’s actually a pretty good arrangement and might be applicable here.
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.
Comment · 1 month ago
(Tailscale cofounder) I’m a little more optimistic; wireguard was always going to need a v2 eventually, that’s just the nature of cryptography. It’ll always be simpler than IPsec as long as it avoids live negotiation (you need to specify your suite up front for each node you talk to; v1 and v2 are the only suites) and continues to go over UDP instead of IPsec’s “it’s a different transport protocol!” madness.
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.
Comment · 1 month ago
(Tailscale cofounder) That’s a good callout on DoH support, thanks.
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.)
Comment · 1 month ago
(Tailscale cofounder) I see a few comments here that using kernel wireguard would make it faster; it’s not really that simple. In fact, for a while (and we wrote a blog post about it), our optimizations made wireguard-go faster than kernel wireguard because it was better optimized. They adopted some of those improvements and now we’re on to the next order of magnitude together.
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.)
Comment · 3 months ago
Is your theory that "any competent security review" will find every security hole in a product? Because that sure would be great if it were true. Unfortunately it does not match my experience.
Comment · 3 months ago
(Tailscale CEO) I don't know what to tell you. The problems that are found internally, or via security reviews and pentests we pay for, are ones that we fix before releasing. They don't need bulletins.
Bugs that are found by other people are found, by definition, after release. They are therefore more likely to need a bulletin.
Comment · 3 months ago
(Tailscale CEO) You have posted here multiple times that "none of the code has had a security audit" and that the SOC2 audit "is not the same thing."
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
Comment · 7 months ago
I’m glad you liked it!
Comment · 7 months ago
Japanese manufacturing addressed this too! There’s a whole branch of Deming’s work around supply chains and how it’s often worth working with “more expensive” suppliers when their quality is consistently high, because compensating for low quality inputs to your own work is far more expensive.
Comment · 8 months ago
(Tailscale founder here) Two main differences: first, every DERP server used by your tailnet must be accessible by every node on your tailnet at all times, otherwise you get hard-to-debug netsplits. That's a very high bar to maintain so we've historically recommended you don't try. In contrast, peer relays are "if a given pair of nodes can connect through any of the relays, go for it" so deploying one is always a performance and reliability improvement.
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.
Comment · 9 months ago
[Tailscale CEO here] I see a lot of comments asking why Tailscale would branch away from our "core product" and build this thing that seems unrelated at first. One answer is that just about every single Tailscale customer (or homelab user!) is dipping their toes into AI right now, and they often come to us and ask how to integrate their stuff into Tailscale. Aperture is our answer to that.
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).
Comment · 1 year ago
(I'm a Tailscale employee) The recent versions of the Tailscale k8s operator actually used a pre-release of the Services feature to do exactly that. So, not much difference. The official Services release is making that functionality available for more use cases (and generally better documented and user friendly).
[ my public key: https://keybase.io/apenwarr; my proof: https://keybase.io/apenwarr/sigs/EjJsGCvgKWL6wCC8dycY6DvZLm9WLJHhkj9VZiylF2g ]