[Cryptography] WireGuard

[Paul Wouters]

On Wed, 5 Sep 2018, Jerry Leichter wrote:

> The real question isn't whether all these things are potentially useful, it's whether people actually do use them.

Yes, they use them.

> The takeup of IPSec is pretty small.

You are very wrong. IPsec was already in massive use before openvpn,
before anyconnect, and before all Windows/Mac products moved to
IKEv2/IPsec, and even more so now those products have.

Google is the only vendor betting it all on TLS and neglecting Android's
VPN capabilities. All modern Windows, Mac, Iphones etc, all use IKEv2
with IPsec (if they aren't still running old/oudated openvpn)

> There was a potential really interesting use case just a little while back:  When you're using containers, you generally run them on an overlay network that only the containers have access to.  There was an IPsec implementation for Docker which made that overlay network secure completely transparently - kind of the perfect use case.  Unfortunately, for reasons having nothing to do with IPsec - the overlay network implementation had all kinds of problems - it was very unreliable.  Meanwhile, Kubernetes seems to have taken on the mantel of "the way containers are done" - and no one seems to be interested in implementing an IPsec overlay network for it, at least the last time I looked.  What instead seems to win - what *always* seems to win - is TLS-based VPN's.  Five years (more?) ago, you could actually find IPsec-based VPN's.  Those faded, too (though, again, not so much because of IPsec itself as that the use of a separate protocols rather than TCP or UDP lead to endless problems 
 with cheap routers).

While TLS for single service containers is a good strategy, deployment
of entire VMs, clouds, etc is happening with IPsec using the Geneve
Protocol.

https://tools.ietf.org/html/draft-ietf-nvo3-geneve-07

Also SDWAN is deploying IPsec (with or without IKE).

https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-02
http://www.prosdn.com/amazing-world-of-network-overlays/

Everyone is making products that use virtual networks to move containers
and hosts through cloud or container providers that use IPsec.  Then we
have existing standards like DMVPN (aka FlexVPN) that is based on IKEv2 +
IPsec. And we have MPLS being replaced or wrapped in IPsec due to NSA's
"remove SSL here ;)"

And lets talk about all the VPN services that offer IPsec to protect
phones (hotspot shield, symantec vpn (formerly surfeasy), etc) that use
IPsec (even if it is mostly to bypass geo-strictions and not really for
security or privacy). Hundred thousands are connected using IPsec at
any time (which was very visible recently due to DNSSEC query for
trust anchors landing at the root nameservers, so it could be counted)

IoT is another huge deployment where we are seeing IPsec can be tweaked
for low power, low traffic usage with the ESP modifications for implicit
IV and diet ESP. This will be a standard feature of sensors etc.

IPsec has never seen more deployment than right now (even excluding
the netflix users). You can even trace this in the amount of interest /
participation in the IETF IPsecME working group.

So the idea that IPsec is dying is hopeful thinking at best :)

> The market has spoken, and the demand seems to be for Remote Access VPN's built on top of, not beside, TCP/UDP.

There has been a need to break out of administrative barriers and broken
networks, which a typical IETF protocol does not attempt by design. That
was the sole reason for SSL-VPNs coming into existence. That is now
dying because IKEv2/IPsec supports this now via RFC 8229 which is being
implemented for Linux as we speak.

https://tools.ietf.org/html/rfc8229

>  WireGuard addresses that market.  Whether it will succeed in displacing existing VPN's, I have no idea - but IPsec's additional features are not going to help it, any more than they have in the last two decades.

You seem to be moving in very different echo chammbers compared to me :)

Paul