Hi, > Yes, a man in the middle, might intercept the leaked > traffic but this traffic is a priori intended to resources only > accessible through the VPN.
I almost read the draft the same way. With the lead-off sentence being It is a very common practice for employees working at remote locations to establish a VPN connection with their office or home office. and not explicitly mentioning cybercafe until section 6, the "problem space" does initially seem to be accessing private networks. The next sentence didn't help This is typically done to gain access to some resources only available within the company's network, but also to secure the host's traffic against attackers that might be connected to the same remote location. because wherever I am is the local location. So I interpreted 'securing against attackers connected to the same remote location' as 'other VPN users'. Which didn't make a whole lot of sense, but RFCs all too often don't on my first reading :( If someone wants to argue that I need to work on my reading comprehension skills, yes, I probably do, but changing it to "attackers that might be connected to the same remote location (e.g. cybercafe)" would have immediately fixed the problem. It would also be helpful if the intro lead off with something along the lines of "employing the VPN for having some sort of confidentiality at least on the way out of the insecure network he's connecting to" (http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html) to prevent setting up the 'vpns are for accessing private resources' mental mind-map and explicitly putting 'insecure local network' into the problem space right at the beginning. Regards, Lee On 12/5/13, Martin Vigoureux <[email protected]> wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF Last Call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-opsec-vpn-leakages-02 > Reviewer: Martin Vigoureux > Review Date: 2013-12-05 > IETF LC End Date: 2013-12-16 > Intended Status: Informational > > Summary: > This document is basically ready for publication, but has nits that > should be considered prior to publication. > > Comments: > This document is short, focussed, and well written. > However it is unclear, beyond that fact that users do not know that > traffic is leaking from (rather not mapped onto) their VPN, what the > real issue is. Yes, a man in the middle, might intercept the leaked > traffic but this traffic is a priori intended to resources only > accessible through the VPN. So, knowing that the leaked traffic will not > reach the targeted destination, it is not clear which critical > information it may carry. I believe that it would be worth giving an > example. > Note that this relates to/extends a comment raised against > draft-gont-opsec-vpn-leakages-00 but which was apparently not addressed. > http://www.ietf.org/mail-archive/web/opsec/current/msg01135.html > > Minor Issues: > Abstract: > This document discusses some scenarios in which such VPN leakages > may occur, either as a side effect of enabling IPv6 on a local > network, or as a result of a deliberate attack from a local > attacker. > I believe this sentence does not exactly reflect the content of the > document. For the first part, I think it is not only because of enabling > IPv6 but because a site has both IPv4 and IPv6 support *and* a VPN > client has poor capabilities in handling securely (i.e., mapping on the > VPN) packets which use one of the two address families. > By the way this is said in section 4: > the resulting VPN traffic leakage is a side-effect of employing > IPv6-unaware VPN software in a dual-stacked host/network. > > Thanks > -m > _______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
