WireGuard Presentation at FOSDEM17 [video] | Hacker News Reader

WireGuard Presentation at FOSDEM17 [video]

wireguard.io

100 pointszx2c436 comments

The FOSDEM web site includes a synopsis of this talk [0], along with the video, slides (PDF) [1] and a "demo screencast" (MP4/video) [2].

It's a good talk and WireGuard is quite interesting. IPSec, OpenVPN, et al., are great but I definitely think there's a need for a high-performance, high-security, easy to configure VPN.

The demo is only two and a half minutes long, check it out.

Edit: Also found zx2c4's technical whitepaper, "WireGuard: Next Generation Kernel Network Tunnel". Just started to look over it but it appears to have all the juicy details.

[0]: https://fosdem.org/2017/schedule/event/wireguard/

[1]: https://fosdem.org/2017/schedule/event/wireguard/attachments...

[2]: https://fosdem.org/2017/schedule/event/wireguard/attachments...

[3]: https://www.wireguard.io/papers/wireguard.pdf

"IPSec, OpenVPN, et al., are great but I definitely think there's a need for a high-performance, high-security, easy to configure VPN"

I really like sshuttle.[1] Very simple - just point it at any host anywhere on the net that has an sshd running.

We (rsync.net) have recently sponsored some bug fixes and freebsd-specific improvements that allow --dns to work as well as generalized UDP tunneling. I'm testing it right now ...

[1] https://github.com/sshuttle/sshuttle

In lieu of the complexity for all other vpn implementations, we fall back on sshuttle consistently.

A long-time kernel developer happened to be sitting next to me, while I was listening to this talk at FOSDEM last weekend, and he politely pointed out after the talk (paraphrasing): "Hmm, I'm not quite convinced -- this lives in the Kernel, and if it's compromised, then it's game over."

PS: Day-21 of QEMU Advent Calendar 2016 was WireGuard (contributed by: Jason A. Donenfeld and Stefan Hajnoczi) -- http://www.qemu-advent-calendar.org/2016/#day-21 -- "This image runs iperf inside containers & prints out the performance statistics along with commands used to configure the VPN."

[Edit: I just noticed 'mtgx' has posed this question in this thread -- https://news.ycombinator.com/item?id=13600614]

I've been wondering the same thing. It seems many lament for it to be in the kernel, when many other vpn systems are addon packages.

I'm really thrilled with WireGuard. It's small, easy to audit, easy to setup, and it is using the Noise protocol which uses trusted cryptography primitives by DJB. I hope it can be merged into the mainline Linux kernel once it stabilizes.

i've read up on wireguard a week or so ago. it seems awesome. i've rarely been so excited about new software/protocol. the design philosophy feels so right.

a few months ago i concluded i needed a secure vpn to servers. ipsec seemed the better option. but i haven't set it up yet. it all seems so complicated for what i want to achieve: a simple secure tunnel between a few machines.

hopefully we'll get easy to use software for macos/windows. no idea how hard that is to create (i.e. adding tunnel types to these OS'es so you can easily add a tunnel and configure them).

Have a look at zerotier then. It's user space, so no kernel requirements. It's super simple: start up the servers and join a network you create on the website. All the traffic still goes directly if possible. Lots of clients available for popular platforms.

ZeroTier is cryptographically inferior to Wireguard, but also isn't really a VPN: it has centralized configuration and rendezvous. If you're running VPNs to get the US Netflix from your UK vacation, this is probably fine. If your VPN is how remote employees access your prod network, it is way less fine.

I think it's a bit unfair to judge ZeroTier in comparison to VPNs, because that's not strictly speaking what it's trying to be. I like overlay networks!

I agree about the cryptography part of course. But I'm not sure about other points. You can run your own directory nodes, rather than use the public ones, so in practice the model looks like OpenVPN replacement. Is there a reason apart from the cryptography part why you wouldn't want to use it for remote workers?

Sure, it does much more, and it's probably better to call it an SDN / overlay. But if you can call OpenVPN a VPN, then I think ZT can do VPN as well.

I actually would love to hear more about your perspective on the crypto used in Zerotier and why it shouldn't be used for remote workers and those sorts of things.

I've been a user for quite a while and it's been really nice (and generally I've really only had trouble using Zerotier on really locked down wifi networks), but given their Technical FAQ info it sounds pretty convincing to a lay non-security-expert person that it is relatively secure: https://www.zerotier.com/tech_faq.shtml#security

As far as using it for remote workers, in comparison to how our current VPN option at work functions (currently a SonicWall Firewall/VPN) it definitely seems to work more easily/consistently so it's been something I've wanted to share so we can try out (but if there are big security issues with doing so I'm sure myself and others would love to get your thoughts on Zerotier in particular).

Thanks!

> hopefully we'll get easy to use software for macos/windows

This is certainly in the works. A fella is working on a Go implementation right now that will be cross platform.

This looks excellent!

I read the presentation and it looks like the designer did an excellent job handling all of the factors.

I also really like the work done to simplify the human interface. This is also important for security and is often lacking.

This feels like the introduction of ssh. I think this has the potential to become an important tool in everyone's toolbox.

I will read more about this tonight!

WireGuard does seem like a very good approach to an easily configurable, high performance, high security VPN.

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.

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.

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.

I have to say this for wireguard, they're doing really well at PR.

We're still doing pretty well with bonding multiple OpenVPN links to get multi-processor performance at FastMail:

https://blog.fastmail.com/2016/12/19/secure-datacentre-inter...

But I'm sure we'll look at wireguard again at some point, but while the website says this: "WireGuard is not yet complete. You should not rely on this code." I'll stick with being conservative and using what we already know and trust.

Previously covered 7 months ago at https://news.ycombinator.com/item?id=11994265

The author answered questions there.

Also 4 days ago for its FOSDEM presentation: https://news.ycombinator.com/item?id=13569420

Anyone know if they've implemented DMVPN yet?

edit: sounds like nope; only progress is a high-level description of how WireGuard might provide equivalent functionality: https://lists.zx2c4.com/pipermail/wireguard/2016-December/00...

Candidly: it seems weird to me that anyone would prioritize something like DMVPN over escaping the IPSEC ecosystem as soon as possible. IPSEC --- including Cisco's IPSEC products --- is terrifying.

So I've caught flack for choosing an OpenSSH "native" VPN (where it sets up TUN/TAP for you on both ends, etc..) over IPSec before.

While I'm sure it's probably lower performance, if you've ever done more than just plug and play some Cisco IPSec stuff (e.g. manually implement IPsec on Linux), it is terrifying in its complexity, IMO, for something you depend upon so critcially.

It's not just a performance problem. OpenSSH's VPN works by encapsulating either IP packets (tun) or Ethernet frames (tap) in TCP. Now you suffer from head of line blocking and nested congestion control. If you want an easy to use userspace VPN use OpenVPN. It may be bloated, but it works a lot better than IP over TCP can ever work.

Hasn anyone implemented IP over QUIC in any VPN product yet?

FYI, from the OP's linked discussion:

DMVPN capability would be outstanding and would make WireGuard much more useful in a AWS VPN situation

I was thinking that IETF IRONbis over WireGuard could be a good solution to the DMVPN use case. But someone would have to care enough to start coding.

How good/bad of an idea is a kernel-level VPN?

ipsec/ike2/isakmp are implemented in kernel afaik, with userspace tools to control them and they're used pretty heavily in commercial scenarios(for office to office vpn or vpn into cloud tenancy etc). OpenVPN/Tinc etc are userspace and seem to be popular for consumers as they require less coupling and relatively easy to setup.

In terms of whether that's good or bad, it depends on your requirements and what's optimal to you. If you think about the problems in OpenSSL, which backs OpenVPN, then that's been a fairly large attack surface vector. Compare that to ipsec/ike2 kernel related vectors and weigh up the setup/learning/deployment costs of both.

IPSec is in the kernel. IKE is outside in userland. IKE tends to be the parts that get compromised often and IPSec in itself is pretty simple.

Putting control planes in the kernel is the worrying part IMHO.

Probably about as good/bad as kernel-level filesystems.

Security wise? Doesn't matter. WireGuard does not add any meaningful attack surface, and you'd be pretty screwed anyway if your non-kernel-level VPN server got hacked.

Performance wise? If you want it to be usable it's pretty necessary.

Reply on news.ycombinator.com