Follow up: Just a mistake... not 32 bits... 32 bytes! Everything in my last email is bytes and not bits... :-) I just got confused...
> > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
