On 4/26/14, 9:44 AM, Carlos Pignataro (cpignata) wrote: > Hi, > > I do not think that "L3 VPN" appropriately qualifies the type of "VPN > Leakages" described in this document. It seems to me that "split tunnel AF > bug" describes it better. One definition of "L3VPN" is at > https://tools.ietf.org/html/rfc4031#section-3.1 > > It would also be interesting to ask the L3VPN WG about it. > > Please find a couple more comments inline on the Abstract. > > On Apr 24, 2014, at 6:11 AM, [email protected] wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Operational Security Capabilities for IP >> Network Infrastructure Working Group of the IETF. >> >> Title : Layer-3 Virtual Private Network (VPN) tunnel >> traffic leakages in dual- stack hosts/networks >> Author : Fernando Gont >> Filename : draft-ietf-opsec-vpn-leakages-05.txt >> Pages : 10 >> Date : 2014-04-24 >> >> 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) tunnel products, may > > I believe that "lack of proper IPv6 support in popular VPN tunnel products" > needs to be either substantiated or dropped. Also, it's not clear to me what > is "proper support" versus (perhaps) "improper support".
I disagree and i think the comments from present and past implementers (myself included) corroborate this assertion. naming specific products doesn't actually serve a useful purpose. >> inadvertently result in VPN tunnel traffic leaks. That is, traffic >> meant to be transferred over an encrypted and integrity protected VPN >> tunnel > > The title says "L3VPN Tunnels", but in general L3VPN Tunnels do not imply > encryption. IP-in-IP, GRE, and L2TPv3 can create L3VPN tunnels without > encryption or integrity protection. > >> may leak out of such tunnel and be sent in the clear on the >> local network towards the final destination. This document discusses >> some scenarios in which such VPN tunnel traffic leakages may occur as >> a result of employing IPv6-unaware VPN software. > > This paragraph seems closer to describing the actual problem: "IPv6 unaware > tunnel encapsulation" -- it seems to me that this is not a "VPN" problem. > > Lastly, please note that there are instances where the demultiplexing of IPv6 > from IPv4 before tunnel encapsulation is a deliberate action: > http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/l2tpv29s.html#wp1276833 > > Thanks, > > Carlos. > >> Additionally, this >> document offers possible mitigations for this issue. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-opsec-vpn-leakages-05 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-vpn-leakages-05 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> OPSEC mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsec > > _______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
