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

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

Hello, Fernando.

I believe you have also seen Paul & Steve's responses to this thread and I'll respond in-line.

-----Original Message-----
From: Fernando Gont [mailto:[e-mail]] 
Sent: Tuesday, December 10, 2013 12:33 PM
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 prompt response! Please find my comments in-line...

On 12/10/2013 01:25 PM, Moriarty, Kathleen wrote:
> 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.

Both cases seem to "capture" traffic by installing more specific entries in the routing table (or replacing the existing ones) and employing e.g.
a tun device....

KM> OK, yes, an IPsec or an SSL Tunnel mode VPN are both subject to these issues.  It would be helpful to note that and include a description on the VPN types that apply.  It would also be helpful to narrow the scope to the areas where you would like this solution to apply (I believe, agents or software at the client system).


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

Actually, this came up as a result with my experience with TLS-based OpenVPN... but the issues are very similar with IPsec -- e.g. this I-D resulted in corresponding patches in the OpenBSD IPsec implementation.

KM> Thank you, I had tried searching for solutions that used TLS to route all traffic before sending my first message assuming someone had implemented a solution, but only found the use of IPsec over TCP 80 and 443, so I stand corrected.  I'll provide some text below with your request as I think it is important to address these points to fully explain where this is applicable for it to be useful.  If I had a hard time finding materials and knew what I was looking for ('interesting' uses of protocols), then others will also have a problem.

[....]
>> 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!

Please check the above. That said, for fairness sake, I'll love the input from others..

KM> I think you saw the response from Paul & Steve already.

And, in case we go forward with your proposed change, what are the specific changes you envision?

KM> In the introduction, please add in a description of split-tunneling along with the description of this issue as there are similarities.  

I recommend adding in a description of the types of VPNs for which this is applicable at the start of the second paragraph.  If you don't want to restrict the applicable types of VPN for this draft, listing the known applicable types as examples will be a very helpful stating point.  Something like the following could proceed the current text in that paragraph:

In some cases, VPNs solutions are designed to route traffic at the IP layer through to the destination gateway.  Typically, these solutions are agent-based, meaning that software is required on the client end point to establish the tunnel and manage access control or routing rules.  Split-tunneling is an example of a routing option typically provided that can be set on the gateway and pushed out to each of the attached clients.  When enabled, split-tunneling routes traffic destined for the network attached to the gateway through the VPN and all other traffic is routed directly to through the Internet or default route for the client.  The VPN gateway administrator may choose to enable split-tunneling if performance is a primary concern for end users Internet access.  The administrator may choose to prevent split-tunneling if they have security concerns such as information leakage or would prefer all client Internet traffic is screened for malware, for instance, as it passes through the corporate firewall to access the Internet.  Similarly, issues have been discovered with VPN solutions that route traffic at the IP layer when IPv6 is in use at the client.

<description of problem for routing at client with IPv4 and IPv6 - paragraph 2 of introduction>

<before the last paragraph of introduction>
Since this issue is specific to VPN solutions that route IP layer traffic, it may be applicable to the following types of VPN technologies:
    o IPsec VPN (include description)
    o SSL Tunnel VPN (include description and I recommend mentioning VPN Portal to make sure readers don't get confused)

 




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

This I-D boils down to "When thinking about securiing data transfer t a remote site, you must keep both IPv6 and IPv4 in mind".

I'm not sure I can see a real difference between what's the specific underlying technology you employ...

KM> I think this should be more clear now with Paul's response.  An agent vs. browser based VPNs are an important distinction as the solutions that route IP layer traffic use an agent and provide a point at which mitigation options should be provided (like split-tunneling).

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

With "VPN ateway" you're referring to a single VPN "client" that is tunneling traffic for all local nodes?

KM> Feel free to replace the term with something else.  When I use the term VPN Gateway, I am referring to the end-point that clients connect to establish the VPN session.  The network being accessed by the clients is on the other side of the gateway.  Typically, options can be set at the gateway, like the ability to prevent split-tunneling, so that a policy can be set for access to the network being accessed.  The configuration may get pushed to the agents or may also be checked through the connect process to ensure policy is met (NAC).


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

The only thing is that I can hear people complaining about the "disable IPv6" option... Although reality-wise, at times that the only option you have at hand (e.g., that's what I do when employing OpenVPN).

KM> Since it is one of the options, I agree that it should be listed.  If people disagree with that option and want to address this another way for their business requirements, that is fine too.  This draft is meant to raise awareness, provide options for software implementations to resolve the issue, resulting in options in software for operators to meet their policy needs.  Just like split-tunneling, operators/administrators will choose the options that work for their policy constraints.

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