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

["Moriarty, Kathleen" <[e-mail]>]

Hi Fernando,

Thank you for the quick response! I'll answer in-line and do think it will be important to address TLS vs. IPsec tunnels separately and will explain my reasoning to help you improve the draft.


-----Original Message-----
From: Fernando Gont [mailto:[e-mail]] 
Sent: Tuesday, December 10, 2013 2:54 AM
To: Moriarty, Kathleen; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Sec-Dir review of draft-ietf-opsec-vpn-leakages-02

Hi, Kathleen,

Thanks so much for your feedback! Please find my comments in-line...

On 12/09/2013 07:21 PM, Moriarty, Kathleen wrote:
> The reference to VPN, never distinguishes if the document is referring 
> to an IPSec or TLS VPN.

That's intentional. At the end of the day, what you use to tunnel your packets  does not really affect the underlying issues.

KM> IPsec and TLS VPNs operate on different levels of the stack, 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.  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.

A TLS VPN 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.

This can get a little confusing as vendors like Cisco developed methods to transport IPsec traffic over TCP ports 80 and 443, but are still IPsec.  Other vendors may have used similar approaches to get around firewall issues (Cisco Tunnel Control Protocol or cTCP), but the protocol is still IPsec and traffic is still routed through the gateway allowing for the options you have specified in the draft as opposed to application level traffic to specific services using HTTP/TLS for the VPN.


> I suspect IPSec from the document,
> but making this clear would be helpful to the reader.  TLS has become 
> popular when providing restricted access and may be just an encrypted 
> session to a particular service as opposed to a full VPN with routed 
> traffic using IPSec.  Unfortunately, language has blurred here, mostly 
> because of marketing, so clarity would be helpful to avoid possible 
> confusion for the reader.

As noted above, this is actually intentional, and I'd personally leave this "as is" -- put please let me know what you think.

KM> See above, thanks!



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

> Is the draft intended for developers/implementers or operational 
> teams/VPN users -- or both?

Both.

KM> OK, great, you may want to call out the specific recommendations for each, state when it applies to both, or state that all options apply to developers/implementers, operational teams, and VPN end users.


> The proposed fixes could be done by the VPN software or operators 
> could disable interfaces, the former would obviously be preferred and 
> the abstract mentions products, so you may want to repeat that 
> preference later in the document.

So far, the I-D proposes that the fixes should be implemented by the VPN client. ONly the "Security Considerations" section mentions "disabling IPv6" as a mitigation (i.e., "last resort" thing).

KM> I would suggest that you add in a statement then to make the objective clear that the recommendations are for improvements in the VPN client to prevent this issue and may involve configuration settings on the VPN gateway that could apply out to all clients if they get updated over time.

I guess possible options are:

1) Leaving the I-D "as is", or,

2) Have a "Mitigations" section where the current Section 6 ("Mitigations to VPN traffic-leakage vulnerabilities") is incorporated as subsection 6.1 (and possibly renamed "Fixing VPN client software"), and then adding another subsection entitled "Operational mitigations" or the like, essentially discussing manually disabling IPv6 on the local system.

I'm inclined to "1)", but nevertheless open to "2)".

KM> If you want to target all user groups as stated above, then I think #2 is the only option.  If you want to restrict the draft to developers and VPN client configuration options, then you can leave this part of the draft as-is and add that statement.

Thank you,
Kathleen

Thoughts?

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492