Hi Andrew, Thanks for your comments. See my response as follow:
> "prudent" and "best" are things that will change overtime. I can see the value in > publishing some algorithm to generate IID, and maybe the more of these we > have - the better. > That section is related to the use of word "might" for the use of RFC 4086 in order to pick up a random number. > I see it harmful in marking the core IPv6 specs updated with this algorithm - > even http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ > does not do that. The old version of draft was not like that but I changed it to apply Fernando's comment. How about change it like before : The node must not generate its public address based on any algorithm that uses MAC address. It "MIGHT" generate it based on [stableaddresses] document. Does it address your concern? > Now, beyond the philosophical-political comments, a couple of things on the > "meat": > > 1) http://tools.ietf.org/html/draft-ietf-6man-ug-02 - is in the WGLC. > This seems to me that step 6 of algorithm needs to go. I did not mention it because that draft relaxed the usage of those bits. So, I thought it would be useful to use all those bits for IID. I can add a reference to that document . > 2) the algorithm components > > R1=(modifier(16 bytes)||timestamp(8 bytes)|| router prefix) > > it looks to me that it is functionally equivalent of just taking a hash of 16 > random bytes and using that as an interface ID ? If I added router prefix , It is only for more randomization and decrease the chance of pick up the same value for other network. It is true that prefix is well known, but timestamp and modifier is not known. Why the additional > components ? They're trivially guessable (even remotely) and are the same for > the nodes on the segment, so they do not add much in terms of entropy. Timestamp : you have to consider clock skew and the CPU cycles so not easily guessable. Modifier: this value is added in case we have the same vendors as you also mentioned. The seed can be any value. One can pick up timestamp. But then based on seed you pick up another number. It is not guessable as well. You have to consider that the attacker is not in the same local link as the node. If he is, he can harm user's privacy based on layer 2 and no need to look for the IP address of this node. Otherwise we have another mechanism to also change the MAC address! Which is out of the scope of this document which talks on layer 3 privacy. However, I think it is currently have a good randomization (because of my reasons) but I also can apply a simple step to increase the randomization, i.e., use any permutation of the s. where s=(modifier||timestamp||prefix) and || is the sign for concatenation. As a result, the node will pick up any different orders of s array of bytes and so the attacker needs to guess on 32 bits and not 16 or 24 bits. Any thoughts? > 3) DAD > > If, after 3 tries, it receives the same > result, it will consider this an attack and will start using that IP > address. > > Uh. So if I have a mass of devices on the segment from the same vendor who > made a poor implementation of this algorithm there is a plausible race > condition where they might start using the same address ? > No, the probability of two nodes pick up the same modifier is really low. Especially if we give a chance for 3 tries. Although they starts at the same time and we say their clock is completely synchronize but the modifier change this value. Any thoughts? > 4) stable storage. > > If I read it right, I think the node still must have at least enough storage to keep > a single IID. If we are talking this a replacement of EUI64, then, again, why not > take a random 64bit value, store that, and just use either that value alone for > the IID ? That is almost the same as my algorithm with a small different step, i.e., you also use stable storage to keep a value while I think there is no need to do so. (they use also a hash function on the concatenation of "history" and EUI-64.). My reason is, as I explained off list, this will increase the chance for the attacker to guess next value generated by the node in case the node is compromised and the attacker access the history once (virus or ...). But using my algorithm, the attacker needs to try different values and he might not have enough time it is because based on that RFC, the node will keep its IID maximum for a week and in most cases for a day. This means an attacker need to try different guessed values in a week (2^24) for the inputs of SHA256 hash function. Thanks, Best, Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
