Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02

"Moriarty, Kathleen" <kathleen.moriarty@emc.com> Tue, 10 December 2013 18:29 UTC

Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDDC1AE171; Tue, 10 Dec 2013 10:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dHOQKVy_M6e; Tue, 10 Dec 2013 10:29:40 -0800 (PST)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 815ED1AE052; Tue, 10 Dec 2013 10:29:40 -0800 (PST)
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBAITRKY019177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Dec 2013 13:29:27 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rBAITRKY019177
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386700168; bh=nokH4RrC/gv45TDDt6ZibPTQFac=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=ODVcM1o7KN8KGyaVl/K5uChiaqOp6yxnVesH6FSpIg9JnPZHgp6eNoRvxcQpuF3tT +doyfBcgGtzcEqSvsZPHjwFzuzOTi9fKqnpBBkBfKBQu3fWjYjpIY5pTJGb+gZdKP4 5eoXFbyPNcaCCmaSCNbKDzYjvLjhSNEYWZpd7y98=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com rBAITRKY019177
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor); Tue, 10 Dec 2013 13:29:06 -0500
Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.222.70.234]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rBAIT45U023487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 13:29:04 -0500
Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub13.corp.emc.com ([128.222.70.234]) with mapi; Tue, 10 Dec 2013 13:29:03 -0500
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" <draft-ietf-opsec-vpn-leakages.all@tools.ietf.org>
Date: Tue, 10 Dec 2013 13:29:02 -0500
Thread-Topic: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02
Thread-Index: Ac71zDm4sVLZBpOjR1WErQbKMNdTvQABTpSA
Message-ID: <F5063677821E3B4F81ACFB7905573F2406541F2311@MX15A.corp.emc.com>
References: <F5063677821E3B4F81ACFB7905573F240653E7FF01@MX15A.corp.emc.com> <52A6C883.2080709@si6networks.com> <F5063677821E3B4F81ACFB7905573F2406541F22C3@MX15A.corp.emc.com> <69CF2337-AB98-4FE2-954B-748FAEB4401D@vpnc.org>
In-Reply-To: <69CF2337-AB98-4FE2-954B-748FAEB4401D@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: public, GIS Solicitation
Cc: Fernando Gont <fgont@si6networks.com>, "iesg@ietf.org" <iesg@ietf.org>, secdir <secdir@ietf.org>
Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 18:29:43 -0000

Thanks for the additional input Paul.  I am adding Fernando back to the discussion as well since these distinctions are important and your summary could be helpful to him.

Fernando - in the description, adding in the SSL Tunnel mode, which also uses a client or an agent in a similar way to the IPsec VPN would be important.  I had actually done a search to find out if there was usage of TLS/SSL to enable routing of traffic and didn't see anything, thanks Paul!  I had previously configured the IPsec over TCP port 80/443 in the past, so I was able to confirm that easily.  Documentation that covers VPN options from a few sources did not cover the SSL Tunnel mode, which I think makes it more important to ensure this background is included as well as how it may apply to the draft (any time you are routing traffic in a VPN).

I'll respond to your (Fernando) message a little later as I have to do my day job for a bit.  :-)

Thank you,
Kathleen

-----Original Message-----
From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Paul Hoffman
Sent: Tuesday, December 10, 2013 12:17 PM
To: draft-ietf-opsec-vpn-leakages.all@tools.ietf.org
Cc: iesg@ietf.org; secdir
Subject: Re: [secdir] Sec-Dir review of draft-ietf-opsec-vpn-leakages-02

<VPN Consortium diretor hat on>

On Dec 10, 2013, at 8:25 AM, Moriarty, Kathleen <kathleen.moriarty@emc.com> wrote:

> KM> IPsec and TLS VPNs operate on different levels of the stack

That really depends on what you mean by "TLS VPN" (more commonly still called "SSL VPNs"). There are two architecturally different technologies that both are called "SSL VPNs":

- An SSL VPN portal is a front-end provided by the middlebox to add security to a normally-unsecured site. A portal does not require any changes to the browser: you connect to the portal just as you would any https: URL.

- An SSL VPN tunnel encapsulates traffic from a client to the middlebox. In essence, an SSL VPN tunnel acts just like an IPsec client and server, but is instead running TLS for encryption and some unspecified, proprietary mumbly thing for encapsulation and routing. In order to do this, the SSL VPN needs to push a proprietary plug-in / add-in / application to the browser.

The current SSL VPN market is split into two factions. Low-end SSL VPN boxes do just SSL VPN tunnels and not portals; many of these tunnel clients only work with IE as a browser. The middle- and high-end SSL boxes all do both portal and tunnel mode, with the tunnel clients working in many different browsers; the administrator decides which mode to use for particular destinations. Many (but definitely not all) of the latter boxes offer both IPsec and SSL VPNs; those that do usually have them in the same admin GUI.

Please note that I am *not* defending the amount of confusion sown by mixing the two very different architectures under one name. SSL VPN tunnel clients were originally created because IPsec clients were too complicated, and these could just be pushed down with a single click in a browser. Now these clients are often *more complicated* that IPsec clients because they interact with browsers and operating systems in more odd ways. For example, one company whom I work with uses a popular SSL VPN system in tunnel mode. But I can't reach them now because they have not updated the tunnel client to work with Windows 8 (much less 8.1) because the client the vendor messed up that client and it no longer works with XP. So this company has a company-wide rule that you cannot upgrade to Windows 8 until the vendor fixes the SSL VPN client, although the vendor says it already has. (The Mac client has never worked reliably.) Yay for progress. 

> , hence the issue you seek to address will be handled differently in each case.  The use cases you describe are very specific to IPsec VPN tunnels in that IPsec VPNs are intended to route all traffic from the client endpoint that has an installed agent to a VPN gateway.  

...and so are SSL VPN tunnels.

> This provides an opportunity for controls to be managed through that application as well as on the client endpoint.  If you think about the split-tunneling example, this is a common configuration option for an IPsec VPN tunnel.

...and usually (but, unfortunately, not always) for SSL VPN tunnels.

> A TLS VPN

*in portal mode*

> is typically application specific, wrapping the specific TCP protocols, like HTTP to provide access to specific services on a network.  TLS VPNs are used when you want to restrict access and only provide remote users to very specific services on the network.  TLS VPN services don't require an agent and the policy is typically more liberal from organizations allowing access from anywhere via this access method.  All other traffic on the system may be routed directly to the destination, whether it is IPv4, IPv6, or even other service level (HTTP) destination addresses.
> 
> For these reasons, I think it is important to distinguish the type of VPN considered in the draft as it seems to be applicable to IPsec only.

...as well as the quite common SSL VPNs in tunnel mode.

>> I would recommend introducing the comparison of slit-tunneling 
>> earlier in the document as this is a similar issue (IPv6 getting 
>> routed separately from the VPN traffic), although split-tunneling is 
>> an intentional configuration option.
> 
> Could you please clarify what you have in mind?
> 
> KM> Split-tunneling allows you to route traffic that is destined for the network you connect to with the VPN through the VPN and other traffic to reach its destination with a direct routing path.  If you think about the IPv4 vs. IPv6 traffic, you are in a similar situation if the IPv6 traffic is not intended for the network on the other end of the VPN.  Many organizations will prevent split-tunneling in their VPN configurations if they would like to make sure the users data goes through a gateway with protections (malware detection, URL filtering, etc.), but others are more interested in performance of the user's access or the ability for researchers to have options to access sites they may not be able to through the gateway (I led security for a research organization in the past and there are valid reasons that would surprise some for this usage).
> 
> Providing an up-front description could be helpful to the reader.

+1. Split tunneling (destined for the inside network / destined for the Internet) confuses many security admins, and layering IPv4 / IPv6 on top is also confusing, but it is definitely worth trying to explain. Just don't make it IPsec specific, because some SSL VPN vendors use exactly the same logic in the SSL VPNs as they do in the IPsec VPNs.

--Paul Hoffman
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview