Comment by apenwarr
15 hours 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.)
Hey why do you hard code certain android apps to be excluded from Tailscale with split tunneling without giving users any way to disable split tunneling for these apps? It doesn't matter how you think VPN does or does not affect these apps, it's really awful anti-user behavior.
I haven't heard of this behavior before. Could you elaborate or link to some evidence of it?
I think it is the opposite google allows some apps from opting out of VPN.
AFAIK any app can opt out of VPN by binding to the wifi/cellphone interface directly, bypassing the OS's routing tables. You need to enable "block connections without VPN" to prevent any leaks.
I don’t trust or want tools from giant for profit corporations because there’s always some bullshit, and usually by the time you figure it out you’re out time or money. Never used Tailscale and this is a perfect example of my policy working. Notice the no response, they know what they’re doing and they don’t care.
Layer 2 VPN is where it’s at anyway. I want to be on my LAN not managing one device or app at a time, I never got the wireguard hype.
> Layer 2 VPN is where it’s at anyway. I want to be on my LAN not managing one device or app at a time, I never got the wireguard hype.
You can do that though? Tailscale can as well. A device can advertise subnets, and can route them through tailscale, so you just need a single node in a LAN.
1 reply →
> Notice the no response, they know what they’re doing and they don’t care.
I was with you in principle until this part. You gave them ~30 minutes before claiming "no answer".
3 replies →
Wireguard with PQ won't be Wireguard, anymore. It'll just be a rehash of IKE+IPsec. What made Wireguard better was the very simple handshake and minimal state, but no PQ algorithms can support that simplicity because the keys are too large and/or not as simple to use as ECC.
Might as well switch to IPsec. Everything is already in place, including hardware acceleration. But most people won't, and we'll live in a world with duck-tape hacks built around a compromised Wireguard-ish layer.
I don't think this really follows. Negotiation would be problematic, but you can just version the protocols and do WireGuard v1 and WireGuard v2, with v2 in a PQ configuration. As long as the configuration about which to use is static, you're not running up against the IPSEC problem.
I don't think there's anything necessarily complicated about MLKEM that would make this too difficult.
Switching to IPSEC loses you other WireGuard benefits; the wins don't end at "just one carefully curated set of cryptography primitives", but extend into things like DoS prevention and a design that admits to processing incoming frames without dynamic allocation.
(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.
Considering how core Wireguard is to the whole Tailscale value proposition, are they funding the future of that V2 roadmap on the open source side? If the answer is "no", and because the security world isn't going to stay put (particularly with AI math advancements happening lately are accelerating medium term risk), then one has to assume Tailscale is working on it's own in-house "V2" equivalent protocol for post-quantum support to enable that vision? I doubt you're doing nothing.
1 reply →
IPSec suffers from the "it can do everything" syndrome.
Storytime: 15 years ago I co-founded a startup to build easy-to-use infrastructure management for AWS. At that time, it did not have cross-region VPC peering or routing, so you couldn't easily and safely have apps that communicate between regions.
So I started working on creating an overlay network. My idea was to use IPsec, it even has an RFC that documents its kernel interface. So that when a host wants to send a packet to the secure network, the kernel goes to my userspace daemon, that in turn goes to the central server that provides it the key for the given host pair.
And it turned out that the interface lacked a crucial part - on-demand key negotiation for incoming packets. It had this for _outgoing_ packets, but not incoming. The only sane way to make it work was to create a proactively updated database of all the hosts.
Well, I did that. It also did not work (tm). I found so many issues with broken MTU handling, broken NAT traversal, etc.
I eventually gave up on that idea and started working on a simple TUN/TAP-based overlay. I almost made everything work, but our startup got acquired by AWS, and this line of work was abandoned.
But then consider ipsec being backdoored by the NSA. As it came out of the Snowden leaks.
IPsec is a terrible fit. Tailscale uses a control plane for peer & key distribution and renders almost all of the complexity in the IPsec protocol useless.
(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.
2 replies →
Any chance the Apple TV can get a performance boost? Specially as an exit node. It always gives very little bandwidth. Thank you!
Apple TV has an OS level issue where it will kill apps that do too much background activity at random, the Tailscale guys can’t really change that.
> But, wireguard also needs to update to support post-quantum
It's quantum-resistant if you define a PSK. You still have to distribute the key out of band, but you already have to do that anyways for the public keys of the peers.
Why do public keys need to be distributed out of band?
Because the public key is the identity in the Wireguard protocol. If Alice and Bob want to communicate with each other over Wireguard, then Alice has to know Bob's public key, and Bob has to know Alice's public key. If they don't already know each other's public keys, then that information has to be exchanged in a secure manner at least once, in order to prevent nosy Mallory from impersonating one of them. How can Alice and Bob exchange their public keys securely? Not with Wireguard, because they'd need to already know each other's public keys for that! So they need to use some other secure mechanism as a bootstrap. Hence, out of band distribution.
In practice, Alice and Bob will often be two machines that are under control of the same entity, and that entity will transfer the key material from a third machine to the Alice and Bob machines over SSH or HTTPS. In those cases, the out of band mechanism is "SSH/HTTPS via trusted relay machine".
1 reply →
I always thought that just kernel mode makes it better.
Didn't know that WG can't use hardware crypto accelerators. I hope it will someday
It's only half the story. WireGuard uses chacha20-poly1305 and certain implementations can still achieve 100Gbps. Hardware acceleration is the path to 400Gbps and power efficiency though.
1) Besides marketing, I see no reason that Tailscale needs to concern itself with the WireGuard protocol spec at all. Tailscale is already incompatible.
2) Tailscale's control plane model for peer distribution avoids every concern affecting IPsec in regard to protocol negotiation security and compatibility.
TL;DR, diverging from WireGuard & supporting AES (via protocol negotiation with hardware acceleration), would be relatively painless.
(someone who went on rabbit hole trip through tsnet) It's not very visible (and not really user-accessible) but Tailscale supports connecting arbitrary wireguard peers into the network, and it's how mullvad integration works IIRC - got confirmation on twitter I think from apenwarr.
So yes, tailscale is compatible with wireguard, it's just not exposed by any of the major coordination servers other than mullvad integration in tailscale.com, but the clients will happily consume information about wireguard peers that do not run tailscale at all.
> Tailscale supports connecting arbitrary wireguard peers into the network
Now screaming internally because every router I've had that's supported Wireguard I wish I could have just joined into a tailnet directly for subnet routing... and I can't find anything else that just plays nice either.
> diverging from WireGuard
You lose the formally-verified cryptography guarantees underpinning WireGuard & its implementation, though. That's a bigger tradeoff: https://www.wireguard.com/protocol/
Replacing ChaCha20 with AES-GCM does not change the cryptographic guarantees of the WireGuard protocol whatsoever.
2 replies →
> 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
Has hardware-offload (for AES et al) got faster still, or that keeping CPU busy in the data path for 100gbps workloads is not ideal, or something else? The WireGuard website claims ChaPoly is at least as fast as hardware-accelerated AES. And that it can be further sped up with SIMD.
https://news.ycombinator.com/item?id=35567268).
Thanks.
> Has hardware-offload (for AES et al) got faster still, or that keeping CPU busy in the data path for 100gbps workloads is not ideal, or something else?
What is referred to by the term "hardware-offload"? For NICs:
> ConnectX NICs offload and accelerate encryption/decryption at speeds up to 400Gb/s.
* https://www.nvidia.com/en-us/networking/ethernet-adapters/
There have been MACsec implementations at 800Gb/s for several years:
* https://www.rambus.com/blogs/rambus-launches-800g-macsec-mul...
* https://semiengineering.com/the-evolution-of-ethernet-to-800...
And 1.6T/3.2T as well:
* https://www.rambus.com/security/protocol-engines/macsec-ip-3...
> The WireGuard website claims ChaPoly is at least as fast as hardware-accelerated AES.
I haven’t used WireGuard but I have easily doubled OpenSSH performance by switching back to AES.