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

[Fernando Gont <[e-mail]>]

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


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


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

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


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



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


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

Thoughts?

Thanks!

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