Hi Hosnieh, On 8/13/13, Hosnieh Rafiee <[email protected]> wrote: > 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.
Yes, I think "might" is correct. I assert that not all stacks need the privacy and sometimes there is a tradeoff. My temperature measurement node at home with 2K of code space and 0.5Kb of RAM running IPv6 does not have the requirement for privacy. Servers running HTTP services do not have the requirement for privacy. The application of a standard is very wide, and such a broad stroke that is in the text is simply wrong. > >> 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? Not it does not. As I said - this may not be applicable for all of the hosts on the internet. > >> 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 . Your step 6 from http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-06 reads: 6. Take the 64 leftmost bits from the resulting output of step 5 (SHA2 digest) and set bits u and g (bits 7 and 8) to one and call this the IID. So it looks like it's the opposite of what you just said, or there is a hidden revision that I haven't seen :-) > >> 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. > If you have A and B taken from random generators, either they are random enough to not collide, or they aren't. The need to "make them more random" means you have a poor RNG assumption ? How poor ? What is the math that dictates the necessity to even mix something in ? > > 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. Clock skew? CPU cycles ? Your definition of timestamp, from the text: "3. Obtain the nodes' current time and convert it to a timestamp. The timestamp field consists of a 64-bit, unsigned integer field containing a timestamp whose value is computed from the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point" the timestamp is in *seconds*. Today's hosts are synced with NTP or similar, so this will be *trivially* predictable in my opinion. > 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. two times timestamp ? Then maybe the algorithm should be more generic and shorter: "take as many of random-looking elements that you can find on your host and a counter, feed them to a crypto hash function, take 64 bits of that and use as IID, increment the counter up to 3 until DAD stops failing and use that as an address till the next reboot" ? > > 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. I think we need to roll back and see again which problem we're solving. As I wrote you in my first reply - the problem of privacy for the clients is a *solved* problem, *today*. You then said it was to prevent scanning ? In case the node has no stable memory ? Putting it into a *short* (about 1/5th of the current size) abstract would help make the discussion better. > > 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? Your first step is: 1. Generate a 16 byte random number called modifier. To generate this modifier, implementations SHOULD use a random seed to aid in the randomization of this number. If your RNG is good enough, the buck stops there. guessing 16 random bytes is hard. > >> 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. Based on what ? It seems the entirety of the algorithm is trying to cater to the situation from here: http://xkcd.com/221/ If it is the case, what's the guarantee that the modifier is "really random" ? And if it is really random - why adding complexity by making it more random ? > 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? I see magic manipulations all over, I am not enough qualified to comment on that :-) I could reason more if I saw math that the assertions/logic are based on. > >> 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 If the node is compromised, this is *GAME OVER*. No, honestly. Your credit card and CVV are gone and attacker is buying the luxury goods with that, your email does not work anymore because the attacker has changed the passwords on there, your iDevices have been wiped clean. Do you give a beep about the address anymore ? ;-) > ...). 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. Based on the *real-world* implementations, they change the IID every time they reconnect to the network. Which is, let me repeat, the *real-world* "large scale privacy problem" is solved today with *existing* code. If you like, you can even see the demo for that - just ask someone with an iPhone on an IPv6 network to flip the airplane mode and back. Seriously, I think the best way forward is to rewrite the problem statement in a more conscise way so we can better argue about what problem is being solved. --a > > Thanks, > Best, > Hosnieh > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
