Hosnieh, Quite a few times I have responded to your comments, and have even provided pointers to publicly-available papers that you seem to have ignored.
I disagree with your comments below... but cannot really invest more time in writing responses you'll ignore. This I-D improves at least two privacy related issues, with minimal effort and complexity. That's usually referred to as "engineering". As noted by others and myself in other messages, there are other aspects that might not even be addressable, or that might be undesirable to address for the general case. (e.g., from the pov of privacy you might want to use a new random address for every new flow... but that generally causes a lot of trouble and complexity). That's as much as I will add to this sub-thread. Thanks, Fernando On 04/29/2013 11:23 AM, Hosnieh Rafiee wrote: > Dear Mark > >> So privacy and security are relative, not absolute. I think this provides > better privacy compared to the use of MAC addresses for IIDs > > Unfortunately that answer is not exactly true. As I explained in my last > messages, it is really related to the lifetime of the router prefix. In > reality, if you do not change it within a short period of time, like when a > MAC address is used, then an attacker will be able to obtain enough > information about this node in order to prepare attacks against during the > time they use the same IID. Then later, the attacker will have the > opportunity to follow his victim when he goes to a new network using the > information he obtained earlier. This means that changing the IP address > now will be of no use . This is why I do not see how privacy is enhanced in > any way with this way of IID generation and I keep reiterating that what > this draft states about also providing privacy is not true. This draft is > just about the generation of IID in a manner not based on MAC addresses and > offers nothing of value concerning privacy issues. > > Privacy and security are relative, that is true. But the way he wants to > maintain privacy is like someone who hides his head in a hole hoping that > nobody will see him. I do not call this privacy. Privacy is relative when > you make as much effort as possible to keep the data confidential. If some > ingenious attackers can come up with new approaches to find your data, then > this is not your fault. I mean by this that if one wants to claim that he > has enhanced privacy, then he will have had to do everything possible to > prevent the currently known privacy attacks. But if you cannot accomplish > that in your solution, then you should not mislead readers by saying that > your solution does.. This is because privacy is like a bottle of water, > where your information is the water inside this bottle. It makes no > difference whether you do not close the tap or just don't close it as > tightly as you should (like this draft), The bottle will leak water, and for > some attackers even a few drops is all they need to initiate further attacks > which can result in much damage to the prey. So, if a draft claim to have > privacy, it cannot just say I will consider just this part of privacy not > others. This is why I suggested to him to just let the users decide on the > lifetime for their IP address when they want to install this feature. In > this case, he does not try to do anything about that bottle; the aim of the > draft is not about privacy but a randomized IID. That way no one will have > any expectations for privacy. So, what I am saying here is that having a > big title which alludes to privacy enhancements does not make sense. > > >> Can you define the "privacy" you don't think it has any effect on? > I have already answered this by what I said in my prior sentence. > > Best, > Hosnieh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- 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 --------------------------------------------------------------------
