Fernando, As we have seemed to reach a stalemate in this discussion, I see no need for continuing it. I tried to explain everything in my last emails and I see no point in reiterating it here. I offered you a different approach which I feel would allow you to continue with an RFC. you might want to investigate this.
Thank you, Hosnieh -----Original Message----- From: Fernando Gont [mailto:[email protected]] Sent: Donnerstag, 20. Dezember 2012 22:29 To: Rafiee, Hosnieh Cc: Fernando Gont ([email protected]); Bob Hinden ([email protected]); [email protected] Subject: Re: Chairs review: draft-ietf-6man-stable-privacy-addresses-01 Hosnieh, On 12/20/2012 06:06 PM, Rafiee, Hosnieh wrote: > Now the question is whether or not you are using the "lifetime" for > this IID or IP. If you are, then it is the same procedure as that for > the RFC privacy extension. The lifetime advertised in RA messages? - Of course. >>Nobody has even suggested this. For instance, if these addresses had a >>lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the >>first place. > I understand that you did not use a lifetime for the address where the > privacy, within the network, is questionable! I said that, if you are > really concerned about privacy, then you would need to set the > lifetime for your address, even within the same subnet. This addresses are *stable*. As noted in RFC4941, you usually need some stable address, even if you do RFC4941. > When you use the same, so called stable addresses, in the same subnet, > it means that you generate the same address and use the same address > forever within that subnet. Now the question is, if your address > ,according to your draft, does not change, what privacy protection is > afforded within the network here? You cannot be tracked across networks. > The second question: usually when, for privacy reasons, ISPs change > their addresses they also change the prefixes. So as you say you > generate new address for the new prefix, what is the stability of the > address? If the prefix changes, then from an IP-layer point of view, you're connected to a different network. > For the Second concern, let's go back to the privacy extension RFC. As > I mentioned in a prior email, the second approach is to use CGA or > DHCPv6. But they did not explain how to do this. They mentioned CGA as > a way for generating a random IID but did not mention it as a > security option. So one might consider extending that section to > include an explanation as to how to use the second approach in that > RFC. For example, suggest using the CGA generation algorithm (as you > are using it with another name!) and since the address does not need > to be verified, then there is no need to set a sec value or add CGA > options to the options in SEND. Well, yeah... at which point, that's not CGAs anymore. ;-) > Another suggestion might that there is no need for the other node to > process verification because security is not an issue. >> * In 3972, there's no secret. Hence, the attacker might be able to compute >> the IID himself (assuming the algorithm and the input parameters are known). > Not true as I pointed out before. >>Where? The Last two emails > As I pointed out before, one can make improvements to the privacy > extension RFC and explain the second approach, in more detail for the RFC4941 produces random addresses. Period. It's a different scheme, with different objetives. > use of the same algorithm in CGA as was used (the same as sec value 0, > i.e., you just run the hash algorithm once on the concatenation of a > random number, subnet prefix and etc) and skip the verification > mechanism since no verification is needed. At which point you should strip most of the CGA document, since most of its contents is related with something else. i.e., we can play the game of "how could I tweak/strech this or that RFC so that we get to the same behavior".. but I'm not sure whatd be the benefit of that. >> As noted above, many deployments turn off privacy addresses. > I do not think this is a good reason in this case because they can > also do the same thing using your draft proposal and never implement > it, or disable it! The reasons for which they disable RFC4941 do not apply to draft-ietf-6man-stable-privacy-addresses. >>A.1.3. Revealing the identity of devices performing server-like > > Functions > > Some devices need to have a fix IP address and these are usually set > by an administrator manually or a fixed range of IP address for the > devices being used. This is what happens in large networks. In small > networks, like home networks, usually the name of the devices are > used. For some servers or server functioning devices, privacy is not > important because they should be available and well known in that > network. So for those well-known devices, privacy does not make sense. That doesn't mean they should be easily discoverable from the public Internet or the like. > Finally, in your draft you do not completely address the privacy issue. > When the same network is used to connect different places, then your > node becomes vulnerable to tracking. What I think is, as long as you > think about stability, that you need to also forget about privacy. Huh? If you connect to two different subnets, the prefix is different, and hence the resulting IID is different. > And > if you decide to be concerned with privacy, then you need to use a > lifetime for your address. This is again like the privacy extension > RFC, RFC4941 addresses are generated **in addition** to the traditional slaac addresses. RFC4941 does nothing to mitigate the implications of traditional slaac addresses. And that's what this i-d is meant to do. Thanks, -- Fernando Gont e-mail: [email protected] || [email protected] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
