Subject: Re: [OPSEC] Start of WGLC for draft-ietf-opsec-vpn-leakages

From: Merike Kaeo <[email-masked]>
Date: Fri, 12 Jul 2013 04:18:26 -0700

Overall I support this document as it's an issue that is very real and the VPN vendors need to fix their implementations to support IPv6.

Some comments below which are mostly to clarify text with exception to very last comment which may point to a correction needed in content.

1. Introduction

Add 'integrity' to the security services a VPN provides (in my personal view, this is more important than confidentiality…to ensure that none has altered the data in transit. I will note that 
this is the *most* misunderstood part of IPsec, that a VPN always means encryption.  It does not - an IPsec VPN can simply perform data integrity checks without encryption so that middle 
boxes could (if policy dictated) see contents of data en route to destination

So change the third sentence to:

"In some scenarios, it is even assumed that employing a VPN connection makes the use of insecure protocols (e.g. that transfer sensitive information in the clear and/or offer no protection 
from modification of traffic while in transit) acceptable, as the VPN provides security services (such as data confidentiality and/or integrity) for all communications made over the VPN."

2. IPv4 and IPv6 co-existence

For the sentence:
"While IPv6 is not backwards-compatible with IPv4, the two protocols are "glued" together by the Domain Name System (DNS)."

I would not use the term glue just to not confuse anyone who for whatever reason may be thinking 'glue record'.  Perhaps another word such as tied together may be better?

For the sentence:
"Thus, when a dual-stacked client application means to communicate with the aforementioned site, it can request both A and AAAA records, and use any of the available addresses."

Change 'aforementioned site' to "www.example.com" which I think is easier on the eyes.

3. Virtual Private Networks in IPv4/IPv6 dual-stack hosts/networks

Since you have already defined VPN in abstract, you don't need to use 'Virtual Private Network (VPN)' but can just use the acronym.  It is common to define an acronym at first use and then 
just use acronym in subsequent text.

Same comment as previously to replace 'the two protocols are glued together by the Domain Name System'  with 'the two protocols are tied together by the Domain Name System'.

4. VPN traffic-leakage in legitimate scenarios

When looking at title I had read it as 'it's OK to have VPN leakage' although of course the text describes VPN leakage in a non-attack scenario.  Maybe change title to 'Inadvertent VPN 
traffic-leakage in legitimate scenarios' or 'VPN traffic-leakage in non-attack scenarios' ?

I am wondering whether it wouldn't be useful to describe a real-world scenario such as Cameron wrote about.  Mostly since I expect a cellular environment that also uses wi-fi capabilities 
will be subject to this issue.

change 'with the aforementioned system' to 'with the intended destination'.  So sentence would be:

"Since the host will have both IPv4 and IPv6 connectivity, and the intended destination will have both A and AAAA DNS resource records, one of the possible outcomes is that the host will 
employ IPv6 to communicate with the intended destination."

also, next sentence I would like to again stress that VPNs are not only used for confidentiality but also for integrity so change sentence to:

"Since the VPN software does not support IPv6, the IPv6 traffic will not utilize the VPN connection, and will be have no integrity nor confidentiality protection from the source host to the 
final destination."

(I also changed 'not employ' to 'not utilize'  but use what term you think best)

Add the word VPN to the last sentence so that it is explicit that it is a side effect of employing IPv6-unaware VPN software (just for clarity).

6. Mitigations to VPN traffic-leakage vulnerabilities

For the first (1) and (2) I wasn't sure right away if it meant IPv6 is not supported or supported in the network but then realized it meant for the VPN client.  I would explicitly add 'If IPv6 is 
not supported in the VPN client', and 'If IPv6 is supported in the VPN client'.  Just for clarity.

In the sentence:

"If the VPN client is configured to only send a subset of IPv4 networks to the VPN tunnel (split-tunnel mode), then:"

would it be better to change the word 'networks' to 'traffic'?  

Also, from the (1) and (2) that follow it looks like the intent is that a subset of either IPv4 or IPv6 is meant to be sent over the VPN but if the VPN client does not support IPv6 then the 
traffic that requires VPN protection should all go via the IPv4 VPN.  So I am not sure that (1) is correct in disabling IPv6 support in all network interfaces.  I expect you can prefer the traffic 
to be VPN protected to utilize IPv4 while the traffic that can be non-secured and supports IPv6 can utilize the IPv6 connection. [obviously a complex configuration and I'd probably put in a 
statement somewhere that monitoring to ensure that traffic that is to be secured does indeed follow the VPN path is recommended].

OK, that's it from me :)

- merike