Hi Fernando, Sorry for the delayed response.
> Agreed. But the I-D is not implying this attack scenario. -- Please do > let me know if you think this is not clear, and, in such case, where/how > I could improve the I-D. What might help is to make the scope a bit more explicit by providing the example you just gave me - """the vulnerability being discussed does not really imply that the attacker is able to get access to some resources he'd otherwise not have access to, but rather that there's a traffic leakage. e.g., if the client employs some insecure protocol (e.g., that sends user and password in the clear), he may think it's okay to use it over a VPN. But with this attack, that user/pass could end up appearing in the clear on the local network.""" Something as simple as the above text in either Section 1. or Section 4. might really help. Thanks, KK On Sun, Oct 21, 2012 at 4:07 PM, Fernando Gont <[email protected]>wrote: > Hi, KK, > > Thanks so much for your feedback! -- Please find my comments inline... > > On 10/21/2012 04:30 PM, KK wrote: > > Some minor editorial nits and a question... > > > > Section 1. > > > > "Section 2 provides some background about IPv6 and IPv4 > > co-existence, summarizing how IPv4 and IPv4 interact on a typical > > dual-stacked network" > > > > I think you meant IPv4 and IPv6 here > [....] > > Yep -- I will fix this and the other reported nits. > > > > > Let's say user Bob wants to access his files from a file server on his > > enterprise network while enjoying a latte from a cafe. He pulls up his > > vpn client, establishes a secure connection and tries to connect to > > filer1.example.com <http://filer1.example.com>. To me, the use of a VPN > > client implies that the server is not publicly accessible over the > > Internet. > > Agreed. But the vulnerability being discussed does not really imply that > the attacker is able to get access to some resources he'd otherwise not > have access to, but rather that there's a traffic leakage. > > e.g., if the client employs some insecure protocol (e.g., that sends > user and password in the clear), he may think it's okay to use it over a > VPN. But with this attack, that user/pass could end up appearing in the > clear on the local network. > > Another example: the user might be employing some protocol that does not > include confidentiality services (e.g., MSN) -- but the user thinks > that's still okay, since he's using that protocol over a VPN. But then > the corresponding traffic might be sent on the local network, in the clear. > > > > > Now, he gets back an A and AAAA record for filer1.example.com > > <http://filer1.example.com>. Typically, that name would resolve to IPvX > > addresses that are only accessible from within the network. Common > > security best practices regardless of IPv4 or IPv6 would suggest that > > you achieve this by either applying appropriate filtering policies to > > prevent access from the outside world and/or only advertising prefixes > > that you want global reachability to/from. > > Agreed. But the I-D is not implying this attack scenario. -- Please do > let me know if you think this is not clear, and, in such case, where/how > I could improve the I-D. > > > > > outside world. Granted, there is still the potential of one-way > > communication attempts going out in clear text on Bob's LAN at the cafe > > and subject to interception. > > Exactly. This attack scenario, along with the case in which the client > is employing the VPN for having some sort of confidentiality at least on > the way out of the insecure network he's connecting to, are the > scenarios that this I-D is discussing. > > > > > So my question is, is the premise here that the network behind the VPN > > head end globally routable without any filtering mechanisms in place? If > > that's the case then yes, VPN leakage here can be severe and detrimental. > > Nope. For instance, the I-D is not supposed to discuss such kind of > scenario, but rather the other two attack scenarios I've mentioned above. > > 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
