Philipp, I didn't really want to continue this debate as I have repeatedly stated my views in my past responses, but if you like, I will once again explain it from my point of view.
>you seem to argue that privacy can only be mentioned if the protection is absolute. 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. Because it is related to all data that can be leaked at one time you have no way or partly protecting privacy. The problem with people who think his approach provides privacy is that they compare the relative definition of security with privacy. It is not comparable! >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. I call his approach a method for generating an IID without the use of MAC addresses, but it is not an approach for privacy! Exposing a MAC address alone, in the IP address, neither exposes privacy nor protects privacy. 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. 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? 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. 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. 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. 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? 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? 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. This shows that there is already a solution for my mobile node, so why should I use the procedures outlined in this draft?? >Windows resorted to use some random identifier instead of EUI64 addresses by default in order not to leak the MAC address. This draft just proposes a similar algorithm for stable autoconfiguration. >The title says "privacy-enhanced", maybe "Stable non-IEEE-identifier-based Addresses" >(with a cuter title made up by a native speaker) would explain the goal in 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. 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. 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. I hope you and others who have the same questions receive the response. Best, Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
