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

From: Peter Gutmann <[email-masked]>
Date: Mon, 16 Mar 2015 01:46:22 +0000

Yoav Nir <[email-masked]> writes:

>The thing is that standardizing a protocol is only good where
>interoperability is required, so that one vendor’s client works with another
>vendor’s server. This is important in many applications, but hasn’t been in
>remote access VPNs, for which SSL is one technology.

What would be achieved by creating yet another new standard (insert obligatory
XKCD reference) in this area though?  If you want (allegedly) interoperable
VPN technology you've got IPsec.  If you want something that doesn't suck
quite as badly, you've got either OpenVPN or (admittedly) vendor-specific SSL
VPNs, although hopefully at least built around DTLS.  What fraction of
whatever's left will be served by yet another VPN standard, and will anyone
care enough to make it worthwhile?

(Just trying to see what actual problem is being solved here).

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Mar 2015 06:19:53 +0200

> On Mar 16, 2015, at 3:46 AM, Peter Gutmann <[email-masked]> wrote:
> 

There’s usually little benefit in getting CompanyA’s client working with CompanyB’s server when both are VPN vendors. One potential benefit is what we have with L2TP: that OS vendors can bundle the client, so no installation is necessary. Another potential benefit is that a standard allows open source projects and 3rd party vendors to implement a client for the less popular client platforms that the VPN vendors can’t be bothered with.

While there have been TLS VPNs built around DTLS, they offer little benefit over IPsec VPNs. The great feature of TLS VPNs is that they work over TCP port 443, and thus fool stupid firewalls into allowing this traffic to pass. The firewall policy of “allow TCP ports 80 and 443; allow DNS; block everything else” is all too common in hotels, restaurants and airports.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 16 Mar 2015 10:44:46 +0200

I fully agree with Yoav re: TLS VPNs. Having said that, standards have 
another benefit in addition to interoperability. A security protocol 
standard ensures the customer (which is typically an enterprise) that 
the protocol is at least minimally secure.

Thanks,
	Yaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 16 Mar 2015 11:22:53 +0100

On Mon, Mar 16, 2015 at 5:19 AM, Yoav Nir <[email-masked]> wrote:
> There's usually little benefit in getting CompanyA's client working with CompanyB's server when both are VPN vendors. One potential benefit is what we have with L2TP: that OS vendors can bundle the client, so no installation is necessary. Another potential benefit is that a standard allows open source projects and 3rd party vendors to implement a client for the less popular client platforms that the VPN vendors can't be bothered with.
> While there have been TLS VPNs built around DTLS, they offer little benefit over IPsec VPNs. The great feature of TLS VPNs is that they work over TCP port 443, and thus fool stupid firewalls into allowing this traffic to pass. The firewall policy of "allow TCP ports 80 and 443; allow DNS; block everything else" is all too common in hotels, restaurants and airports.

I question the "offer little benefit over IPSec". I've seen this
argument more than a decade ago, and still the majority of VPNs in use
are user-space VPNs based on SSL. The last sentence may actually
capture the benefit... it simply works :)

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 Mar 2015 13:24:31 +0200

> On Mar 16, 2015, at 12:22 PM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 

I don’t have the numbers about the prevalence of IPsec VPNs (including L2TP) vs SSL VPNs. But please note that those “user-space VPNs based on SSL” are based on TLS over TCP, not DTLS. DTLS is a UDP connection over a weird port (443 is a weird port for UDP) that is at least as likely as UDP port 4500 to be blocked by middleboxes)

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 16 Mar 2015 13:19:24 +0100

On Mon, Mar 16, 2015 at 12:24 PM, Yoav Nir <[email-masked]> wrote:
> I don't have the numbers about the prevalence of IPsec VPNs (including L2TP) vs SSL VPNs. But please note that those "user-space VPNs based on SSL" are based on TLS over TCP, not DTLS. DTLS is a UDP connection over a weird port (443 is a weird port for UDP) that is at least as likely as UDP port 4500 to be blocked by middleboxes)

In openconnect we use a protocol which is very close to the cisco
anyconnect. That is based on TLS and DTLS. The openconnect client also
supports the Juniper SSL VPN, which is based on TLS and ESP packets
over UDP. Both seem to work pretty well over middle boxes. The
advantage they have is that they don't require the UDP session, if it
doesn't work they simply use the TCP channel.

regards,
Nikos

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Mar 2015 16:30:08 -0400

On Sun, Mar 15, 2015 at 9:46 PM, Peter Gutmann <[email-masked]>
wrote:

> VPN technology you've got IPsec.

IPSec and SSL VPNs are very different things. SSL VPNs work through NAT by
design. IPSEC was originally designed to make NAT work as badly as possible
leading to a host of vendor hacks to make it workable.

Every platform I use has IPSEC built in. No company I have ever worked for
has ever used the built in clients. Instead they always want me to download
some piece of crud that does not work reliably and has a UI designed by an
imbecile.

> If you want something that doesn't suck

Where was it said that there would be another standard rather than a
description of the SSL VPNs that exist? I didn't see it.

OpenVPN is as far as I know currently a product rather than a
specification. Making it a standard and pushing the client part into the
vendor supported part of the stack would be a huge win.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 17 Mar 2015 23:13:58 +0100

Hi,

> capture the benefit... it simply works :)

+1.

IPSec might (!) work well if you use one vendor throughout your network,
pretty much the same thing as some have argued with vendor SSL/TLS VPN
solutions. Because IPSec is such an overly complicated protocol there's
not much security in the clients that are available throughout enduser
operating system. 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.

Besides a couple of commercial and seldomly used FOSS software
implementations nobody really implements all authentication
subprotocols. I rarely see companies that configure IPSec for their
users (if they do, most hate it and constantly have problems with that
decision), most do use AnyConnect or OpenVPN. That is, of course, for
roadwarrior and site-access setups. IPSec works pretty well for
site-to-site setups; then -- again -- if you use different vendors, or
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.

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?

Aaron

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Mar 2015 13:16:44 -0400

> 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