Thanks Fernando. Please see inline. On 12/22/13, 2:51 PM, "Fernando Gont" <[email protected]> wrote:
>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). I do not think this is the best approach. Here you are saying: “when we say VPN we actually mean this, so we will make statements about VPNs”. Instead, I’d suggest the more precise approach is to say “in this document we consider Foobar VPNs, so we will make statements about Foobar VPNs” (where Foobar is a modifier/qualifier of VPN, defined in the document). > > 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]. Additionally, this talks about a specific view from the user (it is not a provider provisioned VPN for example). So I’d define what it is and not what it is not. > > 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? It is necessary, in a one- or two-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. I think it doesn’t. The IETF has defined terminology and taxonomy for VPNs. For example: http://tools.ietf.org/html/rfc2764 http://tools.ietf.org/html/rfc3809 http://tools.ietf.org/html/rfc4026 for PP-VPNs, esp. S. 3, 3.10, 4 http://tools.ietf.org/html/rfc4110#section-1.5 And as you acknowledge it is a meta term (and an overused one); I’d talk about Foobar-VPNs, with narrow definitions. > > > >> 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). I agree client-based is not ideal ― esp. when there’s clientless SSL VPNs that might fit your scope. > >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? My experience is that the use of qualifiers helps and is a best practice. L3VPNs, L2VPNs, PPVPNs, IPsec-VPNs, etc. I’d prefer following the same model here, even when you might have to define a new term. > > > >> 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... In my opinion, that is better than saying “popular VPNs”. That does exclude L2TP, PPTP, etc., although those are potentially subject to the same vulnerabilities described in the doc. Thanks, ― Carlos. > >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
