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

> As someone who regularly deals with IPSec in conservative network environments, Wireguard can’t gain broad adoption soon enough, in my opinion.

As someone who does not do heavy NetOps, can you speak more about what's wrong with IPsec?




The over-summarized version is: IPSec is extensible and it's rather tedious to get every implementation to interoperate securely with every other implementation simultaneously (and in the correctly secure way).

While using IPSec between supported devices, in an ideally configured setup, yield slight but real benefits with respect to attack resistance, a practical comparison of the difficulty involved and possible configuration mistakes makes other solutions more robust and less likely to be used incorrectly.

This discussion covers most of the high level points, however it doesn't consider that Wireguard being adopted in 2020 and not 1995 means we've got 25 more years of public cryptography research and far more relevant defaults to include as the base of the standard.

https://crypto.stackexchange.com/questions/202/should-we-mac...

The answer here also provides some of the pitfalls of IPSec being more of a 'build your own crypto setup' than an off the shelf drop in solution.

https://crypto.stackexchange.com/questions/56354/ipsec-vs-ss...


The 1995 is a little unfair to the current IPsec: The complicated part of the protocol had a compatibility breaking & simplifying major revision in 2005 (IKEv2).

I think the main reason of the less than polished IPsec experience is that operating systems didn't really promote it as a out of the box working feature, but instead just offered APIs that were mainly used by corporate VPN product vendors who didn't really want interoperation except as a checkbox feature. The early interop hassles are just a symptom of lack of testing and effort - when vendors are motivated and actually everyone's implementation of a standardised protocol to interoperate they organise interoperation testing events etc and make sure their products ship with configurations that actually do interoperate in the real world.

Your linked StackOverflow answer muddies the water too much - IKE was always the official keying protocol[1]. Yes you can use lower level IPsec parts without it with manual keying if you are a masochist or have a very simple topology (like a 2-host tunnel with static IPs), but the other keying methods are fringe or academic.

[1] IKE was finished later than the lower level parts of IPsec, technically there was a period in the beginning when it didn't exist and you had only manual key setup


Well, the main advantage of WireGuard then seems to be it doesn't give you any options, so you're less likely to mess it up. Of course there is only one (two?) implementation(s) of it, so "interoperability" as such is not really a thing.

IPsec can be/is complicated because we learnt as we went with it, but given the correct settings, it can be/is secure.

So just like with SSL/TLS, it may be necessary to 'simply' introduce new RFCs to deprecate the Bad Way(s) of configuring it. Doing a quick search, there's a BCP RFC:

* https://tools.ietf.org/html/rfc5406

(I haven't really used either, so am just spit-balling here.)




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

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

Search: