Re: Feedback on draft-gont-6man-stable-privacy-addresses-01

[Fernando Gont <[e-mail]>]

On 04/14/2012 02:36 AM, Karl Auer wrote:
> On Fri, 2012-04-13 at 15:29 +0200, Fernando Gont wrote:
>> "IPv6 implementations conforming to this specification MUST generate
>> interface identifiers using the algorithm specified in this section in
>> replacement of Modified EUI-64 format identifiers."
>> ?
> 
> While that is good, it would be clearer if it was expanded out to make
> the desired points separately:
> 
>    It is intended that the use of Modified-IEEE interface identifiers
>    be replaced wherever possible by the use of interface identifiers
>    generated as described in this specification.

Shouldn't it be specified with RFC 2119 language?



>    When generating interface identifiers, IPv6 implementations
>    conforming to this specification MUST use the algorithm specified
>    in this section.
> 
>    [I'm not sure this is necessary - it seems to be saying that
>    "conforming implementations have to conform"]

>From my pov, it means that all the algorithm is mandatory (nothing to
add or take out).



>    IPv6 implementations conforming to this specification MUST NOT use
>    Modified-IEEE format interface identifiers [see 4291 Appendix A] for
>    any purpose EXCEPT THAT link local addresses MAY be generated using
>    Modified-IEEE format interface identifiers.
> 
>    [remove everything from EXCEPT THAT onwards if that isn't what you
>    intended]

Yep. I think it would be better to have all IIDs generated with the
algorithm.



>    If for any reason the generation of an interface identifier
>    according to this specification fails, IPv6 implementations
>    conforming to this specification MUST NOT fall back to
>    using Modified-IEEE format interface identifiers.
> 
>    Interface identifiers other than Modified-IEEE interface identifiers
>    MAY be used in addition to interface identifiers generated according
>    to this specification.

Ok, I will add this.


>> It shouldn't be possible. The idea is that the secret key is set to a
>> random number (by default).
> 
> I still think you need a special value for "invalid secret key", so that
> any systems do not have any way to obtain random numbers can refuse to
> autoconfigure if the key is not set.

I'd like other to weigh in on this one. -- I don't think there's a need
for a "invalid secret key". The secret key is supposed to be
generated/selected at installation time. If for some reason such
secret_key cannot be randomly generated, the the OS can prompt the user
for one.


>>> 5: Duplicate address detection is not mentioned explicitly, but probably
>>> should be - what happens if a host does DAD and determines that its
>>> stable address is already in use?
>>
>> Address configuration fails.
> 
> That should be in the spec.

As noted, IIRC this is not clearly defined for traditional SLAAC,
either. So, should we be different in this respect?



>> That said, if deemed appropriate, one could include one additional byte,
>> "DAD" in the hash function, which is initialized to 0, and that is
>> incremented by 1 if the host wants to try a different address if/when
>> DAD fails.
>>
>> If we do that, the implementations should probably cache the resulting
>> address, such that it is stable. (otherwise the resulting address might
>> change if the same node was brought up while the node with the
>> conflicting address is off).
> 
> This may not be possible on systems with no onboard storage, and makes
> things much more complicated. I suggest that if DAD fails, then
> autoconfiguration should just fail (at least as regards stable
> addresses).

This is kind of the way DAD works with traditional SLAAC. However, I'm
not sure whether this is the right approach (to have address
configuration fail as a result of that), or whether it would be better
to have some "backup plan" (even if the address is not stored in on
non-volatile storage). For instance, the IIDs that you generate with
this scheme are not globally unique, and then, probabilistically
speaking, there could be collisions.


>> Actually, this algorithm could still be used with longer prefixes (i.e.,
>> fewer bits for the IID). So I'm not sure whether we should include this
>> requirement. e.g., if we were to eventually allow non-/64 autoconfigured
>> addresses, this algorithm could be use without any changes (while the
>> traditional MAC-based identifiers couldn't).
> 
> I like the 64-bit limitation. Either way it should be made explicit.

Is this made explicit in any RFC for traditional SLAAC addresses?



>> (Note that this is a different issue from item #1 above: Item #1 above
>> is about what you should do if you implement this spec, while the point
>> that I'm making in the previous paragraph is that you SHOULD implement
>> this spec).
> 
> I don't think a spec can mandate it's own use unless it obsoletes or
> updates a spec that mandates something. Your spec would have to update
> 4291, for example, replacing the whole modified-IEEE thing with your
> mechanism. That's a BIG step.

Well, that shouldn't be a big deal, and it would be a big advance. If we
were to pursue that path, it should be a "SHOULD", such that in specific
scenarios or circumstances nodes can still used the MAC-based addresses.



>> Additionally, I'd argue that in order to have such thing, then
>> 1) You'd need to manually configure your address each time you move from
>> one network to another (as with manual configuration requires you to set
>> the whole address, rather than just the IID bits), or,
> 
> No - you could just have a flag that says "the key is the interface
> identifier I want to use - verbatim". 

Sorry, what you put in the key would be used for setting the IID??


> Then that IID gets appended to
> whatever prefix happens along. Obviously this does NOT have the same
> anti-tracking qualities etc, but I can see it being useful. 

What's the use case you have in mind?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492