>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.
My point is that this is not true. Let's use a real life example. Suppose that someone knows the address of some place. Would it behoove him to do something bad against that place not really knowing what it is used for? No, it wouldn't, not really. But what if this unsigned building was actually a bank and the person in question is a bank robber? Then the plot thickens and the bank robber's interest is piqued. YES. The borders of privacy are different that those of security. If I only know the IP address of a node and nothing more, there is no real incentive to harm the privacy of this node. But when is this different? The answer would be when I could associate information obtained about this node with its IP address. This information could be obtained from the upper layers during the time this node has the same IP address. Now it makes sense. Your definition for privacy is just bound to layer 3. I refer to this definition as pertaining partly to security but not privacy because you do not want to leak patterns about this IP address. So what can happen if there is a leak? What will I be able to obtain solely from the pattern of this IP address? Will I be able to inflict damage to either privacy or security or both? My definition of privacy has to do with how IP layer is involved in allowing for the gathering of information about the node in order to do harm to its privacy. That is why, in my case, I feel that it is important to change the IID within the same network if I make the assumption that by staying in that network for a time period longer that x, without the router prefix changing, I will be vulnerable to compromise. >THis approach mitigate a number of privacy issues that arise from using traditional slaac addresses. In many cases, mitigating those is "good enough". I am not talking about the native SLAAC that generates the IID based on the MAC. I am talking about the so called solution for privacy, RFC 4941. The problem I can see with this RFC is that the lifetime of the IP address plays the key role. I tested a windows machine with different prefixes and I did not see any association of the IID with the MAC. Please explain where this association is? I will give you a real example from my test The MAC address is : 00:0c:29:fa:38:32 The IID generated in this windows machine is : 3007:efb7:125a:5c0 Several times I have suggested that you show this in your draft in order to solve the problem of RFC 4941. But if you say this is just a new approach for IID generation and my purpose is not privacy, then why you are talking about privacy in your document while you cannot really provide the users with the privacy they need? >It does the following: >* prevents leaking address patterns >* prevents trivial host-tracking across networks. They can still follow you via the information they obtained when you joined the first network and spent a long time there. So, it does not prove to be of much help. >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. First, it is not just the title. It is also your repeated reference to privacy in several places in your document. Second, the title should show the purpose of the draft and not mislead readers. >Not sure what "conditions" you're referring to. Could you please elaborate? The condition is related to the time you will remain using the same IID. If it is longer than x, where x depends on many factors such as how important the information of the users in this network is, how long it could take an attacker gather information about each individual users in this network, and so on. >This scheme results in addresses that have IIDs that **change across networks**. --That's a big different, isn't it? What if my node is to move to and from x different networks? If I generate the same IID as well, then I will be a good victim for the attacker. >Why would you expect a *prefix* to change, if your node does not move, when an *address* is supposed to be topologically-dependent?? Because privacy has to do with my information and not my IP address. I am not talking about security where the attacker knows my IP address which enables him to do certain attacks against me or my network. I am talking about the information that might leak during the time I am using the same IP address. >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". I think that you are confusing privacy with security. >How many times do I need to repeat that RFC4941 addresses are generated **in addition** to traditional slaac addresses? What it uses as a global address is a temporary one which is not based on traditional SLAAC or it tries to randomize the IID. >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. What I know is that you cannot start a new session with your old or expired IP address. But you can keep your current session with your old IP address (see section 3 RFC 4941). Did you really try to see if the current session is cut when using the current services? I have never experienced this. If you or others have ever experienced this, then this is a bad interpretation of RFC 4941 or a bad implementation. Now, when you move from one network to another, where the prefix changes completely and you have a new IP address, do you still keep the same session with your node? I do not think so, otherwise you should use Mobile IPv6 which is the solution here for mobility in IPv6. If your concern is this, then why don't you use mobile ipv6? In this protocol, when a completely new IP address is generated, it still maintains my session along with my old nodes. So now, what is the reason for having stable addresses when there is another solution for mobility in IPv6? >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. I have already answered this. The solution is the use mobile IPv6 and not stable addresses. >Certainly not obvious/possible by just looking at the IPv6 address. -- and if you don't think so, please explain your attack vector. This is what I am trying to tell you. The association of IP addresses to the information obtained from other layers is important and might put privacy at risk and not just hiding the "pattern" of your network. It has more to do with partial security than privacy. Thanks, Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
