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

From: Peter Gutmann <[email-masked]>
Date: Wed, 18 Mar 2015 03:40:17 +0000

Aaron Zauner <[email-masked]> writes:

>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. 

That's the impression I got from folks who have to deploy IPsec solutions,
there seem to be two approaches:

1. Use all gear from the same vendor, configured identically.

2. If you can't manage that, budget lots of time to get things working, and
   bring along something like OpenSWAN and a lot of debugging tools (to quote
   their docs, "Configuration is normally the easy portion of setting up an
   ipsec tunnel, it's normally the debugging that takes up the majority of
   time. Particularly if dealing with heterogeneous peers").  Get things up
   and running, typically in some lowest-common-denominator mode, and never
   touch it again in case it breaks.

>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 pretty much a given when you have to use approach #2, unfortunately.

>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.

Yup.  It's great if you're being paid by the hour, but then again so is
digging ditches.

>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?

Or just "Use OpenVPN".  It's not the perfect solution, but most of the time it
just works.  Want to use an Android phone to check email on your corporate
server?  Use OpenVPN.  iPhone to monitor your home alarm?  OpenVPN.  Two PCs
to talk to each other privately?  OpenVPN.

Peter.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 18 Mar 2015 19:59:57 +0100

Hi Peter,

> That's pretty much a given when you have to use approach #2, unfortunately.

Yes, but that's not only the implementers fault, it's certainly an issue
with the protocol if almost every implementation happens to be
non-interoperable unless you configure every single setting in the same
way and pray that it works (it probably won't anyway).

> Yup.  It's great if you're being paid by the hour, but then again so is

Nah it's not. I guess I only commented on this thread because I
currently have a customer engagement with opensource IPsec stacks. And
to support a lot of client operating systems. I've pretty much told them
by now that I'm not comfortable recommending anything that uses IPSec
currently. Mostly because you'll end up with a common denominator of
IKEv1 in Aggressive Mode. Even then using PSK is more of an issue than
PKIX - but how are you going to manage enduser devices where you do not
have any deployment influence? Customers will get pissed if they need to
look up how to install a certificate to use a tunnel from their mobile
phone.

> to talk to each other privately?  OpenVPN.

That does require installing additional apps on many plattforms.
StrongSWAN seems to have similar apps for mobile devices. A good
security protocol should not need an AppStore, I guess :)

OpenVPN is also not a TLS-only "VPN". An OpenVPN developer told me that
recent releases do duplexing (mentioned earlier): TLS is used for a
control channel while the data channel is AES-CBC encrypt-then-mac.

Aaron

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Mar 2015 13:21:31 +0200

> way and pray that it works (it probably won't anyway).

Actually it is implementors fault, as they use obsoleted IKEv1
protocol. IKEv2 obsoleted IKEv1 in 2005, but now ten years later,
people are still using old version. IKEv2 fixed lots of issues in
IKEv1, especially in the configuration end, for example making things
like lifetimes local matter, so user does not need to configure or
care about them, and they will not cause interoperability issues. Also
things like you must use aggressive mode with road warriors with
pre-shared keys went away, and the IP-address assignment and EAP in
the base standard there is no need for non-interable versions of xauth
and cfg-mode.

The problem is that with all its problems the IKEv1 still works "well"
enough, that even if implementors implement IKEv2 they do not turn it
on by default, i.e. they usually first try IKEv1. This means those
implementations do not benefit from features provided by IKEv2.

> look up how to install a certificate to use a tunnel from their mobile

How about proposing using non-obsoleted protocol, instead of proposing
protocol that was obsoleted more than ten years ago? If the
implementation you plan to use only supports IKEv1, then you know it
has not been updated in last ten years, thus most likely it is not
secure anymore.
-- 
[email-masked]

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 24 Mar 2015 03:28:58 +0100

Hi Tero,

> implementations do not benefit from features provided by IKEv2.

I don't disagree, see previous mails and below. That being said,
it's still unclear to me why something like IKEv1 has been proposed
and standardized at all, but that was long before my time. Protocol
upgrades are a big issue throughout working groups and
implementations.

> has not been updated in last ten years, thus most likely it is not

This certainly wasn't my proposal. The issue I see is that a lot of
operating systems (not appliances) will default to IKEv1 or only
support IKEv1 (in the case of Apple). Thus the common denominator is
still IKEv1. I'd be happy to help design products that support
IKEv2. As is (i.e. without shipping a seperate application to
endusers) there's no real way to do that -- at least that I'm aware
of.

(We're going off-topic here, I'd suggest off-list CCs)

Aaron