Re: [saag] looking to hold a TLS VPN side meeting at IETF 92

[Paul Wouters <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 03/17/2015 06:13 PM, Aaron Zauner wrote:

> IPSec might (!) work well if you use one vendor throughout your network,

That's a somewhat obsoleted viewpoint. While I think that is correct for IKEv1 and all the proprietary bold-on solutions, I do not see as many issues with
IKEv2. Although for large scale solutions, there tends to be a strong vendor-lock but mostly in the management/gui aspects of having many devices (not endusers)

> solutions. Because IPSec is such an overly complicated protocol there's not much security in the clients that are available throughout enduser operating
> system.

I'm not sure what you mean here. With the exception of group PreShared Keys and in particular Aggressive Mode IKEv1, yes that's broken and should not be used.
But it _has_ been obsoleted for almost a decade now.

 Apple, for example, uses racoon (a NetBSD client) for
> IPSec. It only supports IKEv1 in Aggressive Mode. That's a pretty big userbase that is forced to use an insecure protocol.

It does support IKEv2 in the latest iOS, but the provisioning is so locked up that people haven't made it work yet

It does suppor IKEv1 with certificates, which is _not_ insecure, even in Aggressive Mode.

On the other side, there is Android which has locked up their IPsec stack even more. It cannot be at all provisioned, so VPN providers that want something
that doesn't require the user to input a profile manually just choose to ship openvpn bundled in their app. This is not the fault of IPsec, but of Google. Users
having a plethora of TLS/UDP based VPNs installed with less core integration into the OS is a suboptimal solution.

> Besides a couple of commercial and seldomly used FOSS software implementations nobody really implements all authentication subprotocols.

Where do you base your "seldom" on? Possibly you are thinking of Windows VPN clients, which is another story of a failed OS vendor. In this case, Microsoft
waited 5+ years to allow anything but L2TP+IPsec based VPNs to be used by non-administrative users, so anything not using L2TP needed administrative rights
which users often did not have (Or a third party client for XAUTH support)

 I rarely see companies that configure IPSec for their
> users (if they do, most hate it and constantly have problems with that decision)

I do not see that. IPsec/IKE configured VPNs do not cause additional problems. The days of ESPinUDP on port 4500 being blocked are long gone.

> even different product-cycles of a given vendor, you might run into interoperability problems. I don't know of a single network engineer that enjoys
> deploying IPSec.

That's mostly because the Cisco command line is worse than juggling with swiss army knives with all blades extended.


> I don't really see a need for a new standard as I also think that everything that is needed for a TLS VPN is already specified. Maybe a BCP document on how
> to properly use and implement TLS VPNs would make more sense?

TLS VPNs, at least those using TCP, are trivially DOS'ed. Most implementations, because they are userland, require lots of tun devices, custom routing or
bridging, and back and forth of packet data between userland and kernel. It's a band-aid.

People are quick to say IPsec/IKE is too complicated and hard. Yet the TLS protocol is more and more mimicking IKE, and IKE or IPsec hasn't seen anything
close to the vast amount of crypto attacks as we've seen in TLS. On top of that, many TLS VPNs have their own huge problems related to things like environment
variable passing, etc.

As for those still think IPsec is too hard to configure, according to http://www.theguardian.com/technology/2015/jan/09/why-netflix-wont-block-vpn-users there
are 30 million people using a VPN to access netflix. With the apple vs android split, that's about 15 million end users who are using IPsec just fine.


All of this is unrelated to what is apparently the NSA's motivation of wanting two different VPN technologies at once for a "defence in depth" mode. While I
can see why one would want to put TLS under IPsec, I think most of those issues are being addressed in TLS 1.3. If the NSA doesn't want to trust a single
cipher, then I'd rather see a different chaining of ciphers :P

Paul





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJVGYT7AAoJEISzragz8T5uKAAIAJTfj9mLjoIcDW7oY3aHsQaP
Ge7n/NRtyKtJ0vFbi398quBvGt50aXIbUK0AVID2h783KMyX7DA/iBk7Uc5plR+K
PCJXRCsN6UHE/WYbhtoenZEysD5yq2jikbI+SCW6ejKXJoTnfQM7KbuxLo5KJYwK
uH5WnVVEE/KSxUe0zn13o/CtOuhiISGQBGE/fSIy9ED5Ud51AOJrZbjEVh15HZsT
a1naMnu99048AR29pMcoxNL+LJB8gmXBT/UKvLymoNgJtqzvVvRSOzgtb9ftofG9
/5YtSd5IVvqlBf7oNxgZ63S4ciO0CyYDLYNNOZ/uV6r9zB8QM6oqcDi+00F9QsY=
=e7AU
-----END PGP SIGNATURE-----