Bob, and Ole, Thanks so much for your detailed review! Please find my comments in-line....
On 12/20/2012 11:40 AM, Ole Troan wrote: > General comments: > -------------------------- > We do see the usefulness of a interface-id generation algorithm, that > results > in stable identifiers per IPv6 prefix, while not being derived from > link-layer > MAC addresses. > > The mechanism proposed could be viewed as an modification of temporary > addresses (RFC4941) I disagree. Could you please mention what's in RFC4941 that results in addresses that are stable within the same subnet, but different across subnets? > with lifetime handling as for SLAAC, or as an extension to CGA (RFC3972) > address generation where the public key is removed from the hash. Isn't the whole point of CGAs to have the hash be computed over the public key? > The method for generating "Stable privacy addresses" needs to be as well > specified as temporary addresses (RFC4941). > We do wonder if the method of generating these addresses could be a > modification of the algorithm in RFC4941, or if at least, larger parts of > the text in RFC4941 could be > references avoiding having to duplicate lots of text into this document. Hasn't this be discussed to death during the year? (particularly in the Paris IETF -> Vancouver IETF) time frame. For instance, as noted above, RFC 4941 addresses do not have the location-related properties of these addresses. > We do not believe the current revision of the document is ready to > advance to the IESG. > > Major points: > ----------------- > - Stable Privacy Enhanced Addresses (SPE Addresses) should not be a > replacement for the > algorithm specified in RFC2464. It is an alternative. Section 3 needs > modification. Good point. This wording is simply an error (text that remained from the time I meant these addresses to replace the RFC 2464 ones). > - The algorithm in the document is underspecified. > o It should specify the hash function. E.g. MD5 as RFC4941. Why should it? Put another way, is this needed for the algorithm to work? -- it's not. IMO, we might RECOMMEND some algorithm, or note that nodes MAY use this or that algorithm... But requiring a specific one seems like over-specifying the algorithm. > o It should handle reserved interface-ids (see 4941). Good point, will do. > o We suggest renaming the “secret key” to “modifier”. And add text > describing how to ‘maintain’ the modifier (section 3 of RFC3972). It is not a modifier... it is a *secret key*. And this is key (no pun intended :-) ) for the algorithm to behave as expected: if the key is known by the attacker, he could compute the IID himself. > o It would be useful to include an example algorithm as has been done > in some other documents. You mean as in RFC4941? Or a algorithm in pseudo-code? > o Not all implementations use interface indexes How do you identify interfaces without "indexes"/names of some form? > - Clarify what lifetimes these addresses have. You mean lifetimes in the sense of "same thing as tradtional slaac addresses" or lifetime in the sense of "the address will be stable as long as you don't change the secret key". > - Specify the default for DAD retries (IDGEN_RETRIES) Will do. > - Clarify the requirements for stable storage (compared to RFC2464) This is, to a large extent, optional. I guess we could get away with "hosts MAY..."? > Minor points: > ----------------- > Don't use the term "static addresses" as that implies static aka manual > configuration. > These addresses are not static in that sense. Good point. Will do. > Section 3, Last Paragraph: > The reference to Node Information Queries only applies if the attacker > is onlink. > Current text overstates the problem. Move to security considerations. > Addresses will > leak regardless, in other communication, email header etc. Ok. > 6. Security Considerations. > s/in replacement of/as an alternative to/ Good grief. Will do > Third bullet: > The bullet on host-scanning needs some justification. Can we get away with it by referencing draft-ietf-opsec-ipv6-host-scanning? > Fourth bullet: This is not a security issue. Which one? > Paragraph after bullets: > s/algorithm is meant to replace/meant to supplement/ Yup. Will fix this one, too. Thanks! ... and Merry Christmas! ;-) Best regards, -- 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 --------------------------------------------------------------------
