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

[Paul Hoffman <[e-mail]>]

<VPN Consortium diretor hat on>

On Dec 10, 2013, at 8:25 AM, Moriarty, Kathleen <[e-mail]> 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