On 12/21/2012 08:20 AM, Ole Troan wrote: >>> 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.
IMO, that's stretching things too much. IMO, *stable-privacy-addresses have nothing to do with RFC 4941. That said, this was already discussed at the Paris IETF timeframe, and the wg had agreed on the current approach. IMHO, I'd expect that we focus on the current I-D, than rehash 8+months-settled discussions. Particularly at this point in time. > two options come to mind, include the prefix in the hash used in 4941 for > these addresses, The only thing that stable-privacy-addresses have in commong with RFC4941 is that they employ a hash function. But lots of things use hashes these days. Also, then we should have argued that rfc4941 should have been published as an extension to CGAs (or the other way around... whatever came first). -- which would have certainly not been sensible to do. > or just use the 4941 algorithm with RA lifetimes, and require that the node > stores the resulting addresses. That's, of course, a non-starter. >>> 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. Same as above applies. Also, you don't want an implementer to go through 30 pages, understand that stuff, and then say "now forget about these 28 pages, forget about the whole public key thing [etc].. and focus on this expression" >>> 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, Can you clearly state why? -- IMO, RFC4941 is overspecified. Some device might choose to do MD5. Some other might choose to do SHA-1... some embedded device other might want to use a crappy function just to avoid using IEEE OUIs. We should specify additional requirements when that affects interoperability. Adding additional requirements n terms of crypto algorithms seems unnecessary to me. > 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). I disagree with that approach. For instance, the "algorithm" vils down to: 1) If you hae recorded an address for this network, use it. 2) Compute the IID for this entwork 3) Chec for special addresses, and go back to 4 if wrong 4) Do DAD, and go back to 2 if it fails. >>> - 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(?) IMO, the drawbacks outweigh the benefits. If we require an algorithm, we're stuck with that algorithm forever (because if we ever change it, the "the same secret key/modifier creates the same address" argument is void). OTOH, if we don't require any specific algorithm, implemenrarions are free to use whatever fits them, and make their own decisions when it comes to tradeoffs in security, processing power, simplicity to implement, etc. That aside, ass a vendor you're free to employ the same algorithm in all your products, such that if one box gets replaced by another one, you get the same address. >>> 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? A secret key is a value that is... secret. Whether its randmly generated, provided by the admin, or whatever, is irrelevant. The reason why this parameter is called secret key is because that's its most important property... and if the secret key is not secret, then the benefits of the algorithm are gone. So the only sensible change here would kind of be s/secret/SECRET/ to stress this fact. > >>> 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. I've sketched it above. Please let me know if that one addresses your concerns. > >>> 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. ;-) Then you do have interface indexes. The relevant spec doesn't require any specific form of indexes.. they could be names, numbers, pinters, or whatever you want, since that doesn't affect interoperability with other implementations. (which is yet another example of the "rationale" I've applied here when not overspecifying stable-privacy-addresses). > well, we do have indexes and names too. All implementations have (of some form or another). >>> - 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. Will do. (this was implicit, anyway, since we're just generating IIDs for slaac in a different way, but *not* changing slaac itself). >>> - Specify the default for DAD retries (IDGEN_RETRIES) >> >> Will do. Actually... why should we specify this. IMO, we should just say "Do DAD". And whatever that means should apply. >>> - 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? The only difference is the obvious one: if you do have stable storage, before generating an address you should look whether you have an address for this network in stable storage. And when you configure an address, you should store it in stable storage. Period. Me, I don't expect any implementations use stable storage for this. Thanks! 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 --------------------------------------------------------------------
