iscoelho

Not true. There are plenty of userspace TCP stacks in production today, just like there are also userspace IPsec stacks. UDP is also an option if TCP is too complex for your tastes.

Endianness of a nonce in cryptography does not matter and the rest of your statements are nonsensical.

You used AI to write that, didn't you? Please don't do that, it's disrespectful.

By that logic, we should avoid TCP as the Linux kernel implementation has had plenty of CVEs. Thankfully our expert critical thinking helps us acknowledge that as silly.

That is not true unfortunately. io_uring only avoids the userspace copy/switch. There are many other copies in the Linux userspace network stack.

Replacing ChaCha20 with AES-GCM does not change the cryptographic guarantees of the WireGuard protocol whatsoever.

Yes, I agree, IPsec's complexity is definitely why client implementations are so universally finicky. That complexity is not needed by Tailscale.

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.

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.

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.

You're correct, kernel isn't faster by default. With that said, the following is true:

1) the WireGuard kernel implementation, despite not even being zero-copy, exceeds the performance of the userspace implementation

2) implementations utilizing the userspace network stack have a maximum potential performance (context switch + memcpy is very slow, and that affects UDP disproportionately). It's the wrong approach for meaningful improvement.

Tailscale's netstack is barely even WireGuard and they aren't compatible whatsoever. It's all marketing at this point.

So it's not that simple: it's impossible for Tailscale to use any existing kernel or accelerated WireGuard implementation. They could derive inspiration, but a kernel module for Linux won't fix Windows & Mac. With that said, I feel they have enough funding to maintain a few platforms (:

Power usage is also very reasonable! 400GE switches and routers pull a ridiculous amount of power.

"there was a correction issue" is downplaying it. Etcd is truly the worst example of Raft.

Etcd corruption and loss of quorum is extremely common in practice and the GitHub issues sit for years. The design is simple, the performance is modest, yet it still has still never been reliable, despite being marketed as so. I can't speak to whether this is specifically due to their Raft implementation, but I'd argue the entire codebase is over-engineered and questionable.