On 12/22/2013 04:21 PM, Carlos Pignataro (cpignata) wrote:
>>
>> I'm currently working on a "Terminology" section which describes what
>> we mean by "VPN".
>
> This is a good start.
FWIW, this is what we hae at the time of this writing (still subject to
comments and edits);
---- cut here ----
When employing the term VPN (or its acronym, "VPN"), this document
refers to IPsec-based or TLS-based tunnels, where traffic is
encapsulated and sent from a client to a middle-box, to access
multiple network services (potentially emplying different transport
and/or application protocols).
Our use of the term "Virtual Private Networks" excludes the so-called
SSL/TLS VPN portals (a front-end provided by the middlebox to add
security to a normally-unsecured site). Further discussion of SSL-
based VPNs can be found in [SSL-VPNs].
We note that, in addition to the general case of "send all traffic
through the VPN", this document additionally considers the so-called
"split-tunnel" case, where some subset of the traffic is sent through
the VPN, while other traffic is send to its intended destination with
a direct routing path (i.e., without employing the VPN tunnel). We
note that 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.
---- cut here ----
Where:
[SSL-VPNs]
Hoffman, P., "SSL VPNs: An IETF Perspective", IETF 72,
SAAG Meeting., 2008,
<http://www.ietf.org/proceedings/72/slides/saag-4.pdf>.
>> Regarding the title... I'm not sure it's easy to come up with
>> something simple that makes this clear (particularly when, as you
>> correctly state, "VPN" is kind of a meta-term)... Do you have any
>> suggestions for some alternative title?
>
> I think that, for the title, saying ³VPN traffic leakages² is too generic
> to be accurate, and you need to qualify ³VPN².
Is that possible in a one-liner?
> The document seems to hint at the type of VPNs in scope. Although this
> would be more clear after the terminology section, basically the document
> covers VPNs that are:
> 1. Hub-and-Spoke (I.e., client-based in a client-gateway model) VPNs, as
> opposed to Mesh VPNs (MPLS BGP VPNs).
> 2. Encryption-based VPNs (given the mentions of ³in the clear²), as
> opposed to simply tunneling.
Please see if the above text clarifies this point.
> This is similar to the Cisco AnyConnect software client in my mac.
>
> Based on this, ³Client-based encryption-based VPNs²?
Client-based would seem to still lead to ambiguity. Also, some parts of
the I-D notes that some VPNs may not employ encryption 8even when for
the most part we focus on VPNs that do encryption).
My take is that one way or another we'll ahve to live with a generic
title which makes sense when one defines the terminology... thoughts?
> Again, maybe it will be more clear after the terminology section.
>
>>
>> wrt to the Abstract, how about changing it to:
>>
>> ---- cut here ----
>> The subtle way in which the IPv6 and IPv4 protocols co-exist in
>> typical networks, together with the lack of proper IPv6 support in
>> popular SSL-based or IPsec-based Virtual Private Network (VPN)
>> products, may inadvertently result in VPN traffic leaks.
>> [...]
>> ---- cut here ----
>>
>> ?
>
> I think this covers one of the qualities (SSL-based or IPsec-based) but
> not the other (client-based vs. full mesh).
How about "...popular client-based (whether SSL or IPsec) Virtual
Private Network..."? -- Although I'd like to check with Paul Hoffman et
al before applying...
Further suggestions welcome ;-)
Thanks!
Best regards,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
