On 04/27/2013 04:20 PM, Hosnieh Rafiee wrote: > I do not think repeating what I explained before will be of much help. I > never received any responses from my last discussions with Fernando so I am > not going to continue that discourse.
>FWIW, I responded to your messages. However, most of them did not really >have to do with this document. Your answered but your response unfortunately could not address to my concerns. >If you are a single node on a givn network, changing your address >doesn't help much. I think, this is what should be taken into consideration based on the network policy and not something as a "standard" track. Again, I strongly disagree with you. Because you did not solve the privacy within the network and probably not between networks. I had an experiment within the small size network, my attacker node was not within the same network because I did not want to test privacy in layer 2 (MAC address). It was really easier to correlate the data to a node. >I never claimed this. And discussion gets a little bit weird when you >argue that people claimed things they didn't. Your first arguments were about the nodes which want to have a not changeable IP address within the network (during the time they have the same router prefix) and my response to this reason was, this is related to network administrator. If they really want to have a node with a fixed IP address, probably they want it to have a fixed IP address forever and not change after the router prefix changes. They thus set it manually. >If you read draft-ietf-6man-stable-privacy-addresses, you'll realize >that this method is not meant to be a substitution of RFC4941. We just >note that, in some scenarios, it might be good enough. I read both RFCs about IID generation and what I understood is you wanted to have something in between. But in my opinion, your draft does not solve the privacy otherwise we are also talking about a short lifetime for the router prefixes. Because as I explained in my last practical experiment, during the time you have the same IID, I can gather enough information about your node. It has a direct relationship with the lifetime of your IID. But when I could have about 50% information about your node, I have a chance to correlate your later connections with different router prefixes or probably I gathered enough information about the nodes that I am tracking and do not need to track them more after they have different router prefixes. What would be so helpful is you merged both RFCs and replace them instead of having something between that does not really help in privacy. > About having the same IID for some nodes, I think that this is really > related to the network policy and has nothing to do to with standards but Is > more a deployment issue. >We do care about deployment, don't we? What I meant is, standard should address to general issues but in your draft, except the IID generation algorithm, I do not see a general issue. Not having a fixed IID within the network or having it, is a network policy and not a standard document. The privacy is something that some people want to have it and some really do not. A standard document can explain to keep the lifetime of IID for a short period of time but it might not explain that It should be this or that and keep it like this or that. You can recommend them but not focus the whole purpose of your draft on this solution. If a standard document tries to explain everything in more detail then it ties the hands of network administrators. they will thus easily disable this feature in their nodes. There are currently thousands of RFCs that never been implemented or never been used. It is because many of them did not focus on the general solutions. In my opinion it is not a general solution to keep the lifetime of the IID like what you explained in your draft and again I consider it as an issue related to the network policy and not a standard document. So now the question is why we have to go in more detail like this and decide for the administrators about the lifetime of the IID when it is a simple things and related to the network policy? I ask others to judge and discuss about this... I am not going to continue. Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
