5 ms·
Would you please like to add some reasoning to make it easier for others to understand how you came to that conclusion? Why do you think that it seems like a v
by softwarelimits 10y ago
Would you please like to add some reasoning to make it easier for others to understand how you came to that conclusion?
Why do you think that it seems like a very good approach?
What information is your analysis based on?
And what is your competence that allows for a public verdict, if I may ask?
POTUS-style "it is very good" posts should not invade this discussion space.
- tptacek 10y agoYour comment would be just as informative if it ended after the first sentence. The presentation answers most of this: * An extremely small, auditable-in-an-afternoon codebase. The code is 1% as large as XFRM/StrongSwan IPSEC. * Designed from inception to eliminate memory corruption and state machine bug classes; for instance, all allocation is per-peer at-config static. * A simplified, modern crypto stack with no cipher agility and thus no downgrade attacks (and, again, an extremely small codebase) --- this also drastically simplifies configuration. * A DOS-resistant forward-secure protocol based on Trevor Perrin's NoiseIK. * Direct integration into the Linux networking stack, so that VPN tunnel interfaces appear to management tools just like other interfaces, and policy can be expressed using standard iptables and IP routing tools rather than poorly duplicated in the VPN software.
- drvdevd 10y agoGreat synopsis, thanks! I'm particularly excited by the last point - there's a genius to putting this in kernel space for exactly that reason.
- agwa 10y agoA VPN does not need to be in the kernel for that; userspace TUN/TAP VPNs can also take advantage of standard system tools for policy and management. The actual motivation for running in kernel space is performance.
- drvdevd 10y agoYes, I understand the performance gain. But the difference here with respect to management, presumably, would be that when this is loaded/compiled in the kernel, less userspace setup would be required -- correct? I'm assuming it would just show up like an available network device at boot. I need to watch the talk still. I know doing the same for TUN/TAP is not a leap really, but it's one more thing to have to consider. Also I have no idea what the performance implications of TUN/TAP are either (although I frequently use both, I've never measured it).
- agwa 10y ago> But the difference here with respect to management, presumably, would be that when this is loaded/compiled in the kernel, less userspace setup would be required -- correct? I'm assuming it would just show up like an available network device at boot. No, you have to explicitly add the interface with the wg command, much like you have to explicitly run a command that starts a TUN/TAP VPN. And once those commands are run, both WireGuard and TUN/TAP interfaces look just like normal interfaces and can be managed using standard tools. WireGuard could be implemented in user space and be just as easy to use and manage. The only benefit from running in kernel space is performance.
- tptacek 10y agoI didn't write "runs in kernel" as a benefit. I wrote "directly integrated with Linux networking stack". It's actually not the case that the other VPN alternatives integrate as seamlessly with Linux networking tools as Wireguard.
- agwa 10y agoI wasn't replying to you.