Fernando, >> 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?
an _extension_ to RFC4941. two options come to mind, include the prefix in the hash used in 4941 for these addresses, or just use the 4941 algorithm with RA lifetimes, and require that the node stores the resulting addresses. that nodes should remember the address they used on previous links is already covered in RFC 4862 I believe. the latter mechanism doesn't work well for nodes without persistent storage though. >> 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 suggestion was you can achieve stable privacy addresses also as an extension of the text in RFC3972. >> 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. see above. we think the method must be as well specified as the 4941 method is, that may result in some redundant text, which is why we suggested if you had looked at making it an extension instead of a entirely separate document. (note that this was a question, I don't know the right answer). >> 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. could you use similar text as 4941? there might actually be some benefit in two nodes given the same secret key/modifier creates the same address(?) > >> 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. could it not be some unique number the implementation has? serial number, MAC address, etc? if it has to be a secret key, and it has to be provisioned, then mightn't you as well use 3972 addresses? >> 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? as in 4941. >> o Not all implementations use interface indexes > > How do you identify interfaces without "indexes"/names of some form? in IOS we do pass pointers around. ;-) well, we do have indexes and names too. >> - 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". an address cannot have a longer lifetime than the lifetimes advertised in RAs of course. could you say something along the lines of: Stable Privacy Addresses have the same lifetime properties as SLAAC addresses [4862] and expire as described in section 5.5.3 of 4862. >> - 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..."? wouldn't you behave differently, e.g. if the node has no persistent storage for a secret key? >> 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? yes, that would probably work. >> Fourth bullet: This is not a security issue. > > Which one? must have meant third bullet. >> Paragraph after bullets: >> s/algorithm is meant to replace/meant to supplement/ > > Yup. Will fix this one, too. > > Thanks! ... and Merry Christmas! ;-) thanks, and to you too! off on holiday now! best regards, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
