On 04/30/2013 12:38 PM, Hosnieh Rafiee wrote: > > No, absolute is too a big word to use but the definition of the > relative is also much different than when using it in reference to > security. Unlike security where you can provide relative security > through the protection of one protocol and then claim protection for > all the associated protocols, privacy is not like that.
Privacy is handled in the same way as security. Perfect privacy (as with perfect security) doesn't exist... and you usually must decide when putting even more effort on it doesn't make any more sense. > Because it > is related to all data that can be leaked at one time you have no way > or partly protecting privacy. "The same thing could be said about security, if that's your point: your whole system can be compromised at one time". -- Of course, that doesn't make any sense. > The problem with people who think his > approach provides privacy is that they compare the relative > definition of security with privacy. THis approach mitigate a number of privacy issues that arise from using traditional slaac addresses. In many cases, mitigating those is "good enough". >> Fernando argues that even small steps are worthwhile. The main >> question > seems to be if Fernando's draft has >enough privacy value in itself > apart from stable addressing that is not based on Ethernet >MAC > addresses. It does the following: * prevents leaking address patterns * prevents trivial host-tracking across networks. For *me*, that's more than enough. > I call his approach a method for generating an IID without the use of > MAC addresses, but it is not an approach for privacy! If your concern is the name, let's call this "Fernando's addresses" :-) or whatever -- the meat is in the mechanism, rather than the title. > Exposing a MAC > address alone, in the IP address, neither exposes privacy nor > protects privacy. When it comes to host-tracking, what matters is that the IID is constant across networs -- for instance, Windows' approach suffers the same problem. OTOH, embedding the MAC address in the IID possibly leaks address patterns of the local network. > This is the main problem with some people in this > group that think that not generating an IP address based on MAC will > really help in protecting their privacy. It does, but with certain > conditions that Fernando's draft doesn't explain. Not sure what "conditions" you're referring to. Could you please elaborate? > If I use the same > IID for a long period of time, say one month or so, what is the > difference between having my address generated using a MAC address or > based on Fernando's approach? Im not sure how many times I have repeated this already: traditional slaac addresses have IIDs that **are constant across networks**. This scheme results in addresses that have IIDs that **change across networks**. --That's a big different, isn't it? > My answer to that is that I see no > difference. Why you might ask? Well that is because there are two > scenarios in play here. In first scenario my node is not mobile and > remains in the same network forever. So my node expects that the > router prefix will be changed so that a new IP address can be > generated thus protecting his privacy. Why would you expect a *prefix* to change, if your node does not move, when an *address* is supposed to be topologically-dependent?? > But what happens when the > router prefix is not changed for a long time. The attacker will then > be able to gather enough information about this victim node to allow > him to do his dirty deeds. Privacy??! I see no privacy here. No matter how short-lived you make addresses, this will still be the case. FOr instance, with current tools and bandwidths, you do not need a node to be connected for more than a few seconds to have a penetration testing tool attempt what you refer to as "dirty deeds". > Now consider the second scenario where my node is mobile. The victim > node joins network A, generates its IP address, and remains on the > network for an X amount of time. Since the victim node is really only > temporary in that network, then it can use the Privacy Extension RFC > for generating its IP address as it does not need to have a fixed IP > address. How many times do I need to repeat that RFC4941 addresses are generated **in addition** to traditional slaac addresses? So, if you do privacy extensions, you're still doing the MAC-based addresses. And, the fact that youre a mobile node doesn't mean you don't need a stable address. > What is the benefit of having a fixed IP address when my > node is only temporary?? I myself see no benefit. He is just a > visitor on that network so why should it be important for him? Because while you're still in that network, some of the protocols you employ may need a stable address... and because you may not want your e.g. ssh sessions to break every X minutes. FWIW, I'm writing this email on a laptop, which is my mobile node. It tends to stay cnnected for a few hours at home, then for a few hours at my office, then for a few hours at some relative's home I'm visiting, etc. > Suppose that a staff member always uses network A for connecting his > laptop to the network. He then moves to network B and then returns to > network A. Each time he will be using the same IP address in network > A and the same will be true for network B. How difficult would it be > for the attacker to understand that this is the same node moving from > one network to another? Certainly not obvious/possible by just looking at the IPv6 address. -- and if you don't think so, please explain your attack vector. > So once again I see no privacy here, even for > mobile nodes. But what if he generated his address based on the > Privacy Extension RFC. In that case every time he joined network A > or network B, he would have new IP addresses (new IIDs) and it would > not be easy for the attacker to detect that it is the same node > making the moves. I'd just need to learn the fixed address, and then actively poll it at the two networks. > the title a bit more clearly. You wouldn't argue against listing the > privacy benefits this has over the traditional way of EUI64->based > SLAAC address assignment, I presume? > > Yes, If the IETF wants to have an optional approach for IID > generation then ""Stable non-IEEE-identifier-based Addresses" is a > viable means. However, I assume that resolving the current issue > using the current RFCs will be more helpful than having a new > document which could confuse users. This one has been beaten to death. Please read the intro of draft-ietf-6man-stable-privacy-addresses. > Finally, this approach does not have wide usage in the current > context. As others have also mentioned, if I need more management of > my IP addresses or need some fixed IP address on my node, then I > could easily configure the DHCP server. Since you don't control which networks employ DHCP, you cannot rely on that -- you don't really want to reveal your node's identity and become subject to host-tracking attacks when you connect to networks that employ SLAAC, do you? > I would configure for other > nodes and would configure my fixed nodes manually. I will not use > SLAAC, and if I want privacy and temporary addresses, then I will use > Privacy Extension RFC. If that RFC has any problems with generating > the IID then I would extend the algorithm for IID generation there, > without having something in between that does not have wide usage. It doesn't have any "problems". It fixes part of the problem. But the stable addresses still have room for improvements -- and thats what this document tries to do. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
