Hola, Fernando! On 12/22/13, 12:56 AM, "Fernando Gont" <[email protected]> wrote:
>Hola, Carlos, > >Thanks so much for your feedback! Please find my responses in-line... AnytimeŠ please see inline. > >On 12/16/2013 05:20 PM, Carlos Pignataro (cpignata) wrote: >> Apologies for the lateness of these two small comments, and if it >> has been made before -- >> >> Looking only at the title and first sentence of the Abstract: >> >> --->8--- Virtual Private Network (VPN) traffic leakages in >> dual-stack hosts/networks >> >> Abstract >> >> 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 Virtual Private Network (VPN) products, may inadvertently >> result in VPN traffic leaks. --->8--- >> >> I have one concern and one small comment: >> >> First, "VPN" is a pseudo-technical term, or a meta-term. If I >> understand, this document refers to a very narrow slice of "VPNs" >> (not to L1VPNs, not to L2VPNs, not to MP-BGP/MPLS IP VPNs, not >> to...). The document seems to be (only?) focusing on >> client/concentrator VPNs, and within these ones the IPsec ones. >> Can we make this very explicit in the 1. title, 2. abstract, and >> even 3. a formal definition of scope? > >I'm currently working on a "Terminology" section which describes what >we mean by "VPN". This is a good start. > >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². 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. This is similar to the Cisco AnyConnect software client in my mac. Based on this, ³Client-based encryption-based VPNs²? 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). > >I realize that this might still be a bit unclear, though. If you have >any suggestions, please do let me know. I do think it¹s better, but not quite there yet. > > >> Second, are these "leakages" if the packets are not destined to go >> in the tunnel? I guess if the "traffic" (i.e., payload) is not sent >> on the IPsec tunnel, then it is leaked. But it is a bit >> borderline... > >We deem it as a "leakage" when traffic to some destination is expected >to go through the VPN, but doesn't. Trivial example: You employ e.g. >OpenVPN to send all your traffic through some VPN gateway (e.g., some >box at you office or home), but then connect to a dual-stacked >network. If the destination is IPv6-enabled, your traffic will leak >out of your VPN inadvertently. I agree with your perspective. Although it can be argued both ways, I do think it is totally fair to call it a leakage in this case. > >Thoughts? > >Thanks! Thanks, ‹ Carlos. > >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
