Hi, Martin! Thanks so much for your review! -- Please find my comments inline...
On 12/05/2013 01:09 PM, Martin Vigoureux wrote: > 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. The most basic scenario, as described in the I-D is this: You attend a conference and tunnel everything through the VPN (for security/privacy reasons). But then all your traffic goes in the clear... The implications are that the user can now be monitored wrt which istes he visits, etc., his location is leaked out, plaintext passwords come up in the clear, MITM attacks become possible, etc. > 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. This is what we currently have in the I-D, as an example, in the intro: ---- cut here ---- It is a very common practice for employees working at remote locations to establish a VPN connection with their office or home office. 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. The same is true for mobile nodes that establish VPN connections to secure their traffic while they roam from one network to another. In some scenarios, it is even assumed that employing a VPN connection makes the use of insecure protocols (e.g. that transfer sensitive information in the clear) acceptable, as the VPN provides security services (such as data integrity and/or confidentiality) for all communications made over the VPN. ---- cut here ---- Please let me know if you think this should be modified/augmented... and, if possible, provide advice regarding "how" that should be done. :-) > 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. Would this modification address your comment?: ---- cut here ---- This document discusses some scenarios in which such VPN leakages may occur as a result of employing IPv6-unaware software in networks that support IPv6 (either legitimately, or as a result of a deliberate attack from a local attacker). ---- cut here ---- 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
