Hacker News new | past | comments | ask | show | jobs | submit login

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.




Your 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.


Great synopsis, thanks! I'm particularly excited by the last point - there's a genius to putting this in kernel space for exactly that reason.


A 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.


I 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.


I wasn't replying to you.


Yes, 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).


> 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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: