Hi, Ray, Please find my responses in-line...
On 09/07/2013 03:26 AM, Ray Hunter wrote: >>> 3. I think there should be some words on the quality requirements of >>> the PRF F(), and also any security impact of this being weak/ >>> predictable. >> >> mm.. should we really say more than "it is cryptographically secure", as >> already stated in the document? In my head, F() would be something like >> SHA-*.. but even MD5 would probably be good enough for this purpose. >> > I am thinking the opposite. Saying that "F MUST be cryptographically > secure" might be too onerous for embedded systems. Well, the whole point of this scheme is that the IID is not predictable by an attacker. So the properties of the function really matter. While there'e whole range of embedded devices, I think this kind of thing is not onerous these days. > But Appletalk Phase II Ethertalk networks settled down to stable address > assignments using just 8 bits for the NodeID even with say 100 nodes > sharing one layer2 link. OK there's little privacy, but you do have the > unique IIDs necessary for communication. I think the constraints and the requirements of that time were quite different (for instance, people used telnet for remote login at that time). >>> 4. Add something on backwards compatibility e.g. "An implementation >>> MAY avoid using RIDs with u=1 if the implementor is concerned about >>> backwards compatibility with older SLAAC implementations sharing the >>> same L2 link." Section 3 brushes this issue aside, but I still have >>> doubts. >> >> I have no issues with adding that. But truth is that since Windows has >> replaced the IEEE-identifier-derived IIDs with ones that use u=0. I >> don't think you really improve backwards compatibility by setting u=0. >> >> Thoughts? > This is possibly paranoia on my part (thinking manufacturing/ automotive > and 30 year product life cycles plus the 100BaseTX auto config debacle > that still hits operations regularly) Just as a clarification: we're talking about a 64-bit long field. You probably have more chances of getting into trouble due to MAC address duplication than as a result of this. And even then, you need to get the legacy device to bootstrap *second* in order for this scenario to be problematic. >>> 5. Add random delay before regenerating tentative addresses when >>> incrementing the DAD counter to avoid lock step behavior (section >>> 4). >> >> Next question is... "In what range"? 0..1 seconds? >> > Should probably be defined to be "between 0 and the DAD RetransTimer as > defined in RFC4862" > [yes, by default that's 0 .. 1] I'd probably specify a new variable rather than reference RetransTimer, since the latter has a different purpose. Thoughts? >>> The information on "Relationship to Other standards" should probably >>> be separate from the Introduction, with subsections for "Temporary >>> Addresses", "SLAAC" and "DHCPv6" . >> >> Ok. I will look at the intro, and move that other text to an Appendix. I >> will come back to you with a specific proposal. >> >> > Not sure it needs an appendix. I think it is just a question of adding > appropriate section breaks. Ok, I see. I'll split the current intro and move part of the current intro to a new section. > The reason I specifically mention RFC3572 is that MAPOS has to > synthesise an EUI64 address (by borrowing from another interface), > because HDLC interfaces do not include the concept of a "burned in > address" (section 3 of RFC3572) > > I think it would be very instructive to check if > stable-privacy-addresses are applicable to such link technologies that > have no native burned-in-address. Given that stable-privacy-addresses does not require the use of link-layer addresses, it certainly applies to those technologies (and probably is as "general" as you can get in this respect). >>> Nits ==== >>> >>> indentation of /Cryptographically Generated / >>> >>> indentation of / It should be noted that temporary addresses/ >>> >>> I understand that the indentation had some meaning, but it's lost >>> without the WG context. >> >> Oh... this are my parenthetical notes (borrowed in style from Rich >> Stevens) that everyone hates :-). -- is there any better way to do that? > plain vanilla text works for me. Ok, I'll do it. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
