Hi, Mikael, Thanks so much for your feedback! -- Please find my comments in-line...
On 08/20/2013 05:32 AM, Mikael Abrahamsson wrote: >> draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd) > > -------------------------------------------------------------------- > NIT: > > F(): > A pseudorandom function (PRF) that is not computable from the > outside (without knowledge of the secret key), which should > produce an output of at least 64 bits.The PRF could be > implemented as a cryptographic hash of the concatenation of > each of the function parameters. > > Missing space in the middle line. Will fix this in the next rev. > ------------------------------------------------------------------- > > secret_key: > A secret key that is not known by the attacker. The secret > key MUST be initialized at operating system installation time > to a pseudo-random number (see [RFC4086] for randomness > requirements for security). An implementation MAY provide the > means for the the system administrator to change or display > the secret key. > > I think the text here should be that i MUST be initialized when the > functionality is enabled (or equivalent). I see you point. I guess something like "...initialized when this method is installed (e.g. at operating system installation time)" would do? > ------------------------------------------------------------------- > > There are numerous references to DAD. Isn't DAD attacks handled in other > documents that can be referenced, does this document really need to > outline this behaviour, perhaps even in conflict with other documents? I > don't remember where I read about this though, perhaps someone else > knows? It was discussed in SAVI anyway. This document discusses how to recover from DAD failures -- *this* is not discussed elsewhere. > I think it would be good to reference SAVI-WG documents on first-hop > security instead of writing new text on the subject. Where, specifically? > People seem to like > SEND, but I see send as hard to deploy in most scenarios because one > entity doesn't control both router and device. +1 -- and there's the PKI issue, etc. > Network_ID mentions SSID. What if I have an ethernet Interface and I > move my computer around, should it identify a new set of /64 network > address and/or gateway MAC address as a new network as well? I think > some text on this would be good guidance for implementors. That's left unspecified, since it might be tricky: there's might be more than one local router, for redundancy purposes -- but since it's the same network, you'd want your addresses to be stable. That's why in the SSID example we use the SSID, and not the router's MAC address or the like. Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
