Re: "Recommendation on Temporary IPv6 Interface Identifiers" (revised I-D) (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-01.txt)

[Mark Smith <[e-mail]>]

Hi Fernando,

Sorry not to get back to you sooner.

Comments below, <snipping> bits I can't add to.


On 17 March 2017 at 03:35, Fernando Gont <[e-mail]> wrote:
> Hi, Mark,
>
> Thanks so much for your feedback! Please find my comments in-line...
>
>
<snip>
>
>> "  4.  The resulting interface identifiers MUST NOT embed layer-2
>>        identifiers (e.g.  MAC addresses)."
>>
>> perhaps add,
>>
>> "to prevent correlation between IPv6 IIDs and MAC addresses, when an
>> outside entity has been able to record both."
>
> Yes, there's also the fact that:
>
> 1) We cannot be assured that the randomization of the underlying MAC
> address is good enough
> 2) if the IIDs are 64-bit long, and the mac addresses are 48-bit long,
> you still need to randomize those remaining 16 bits... so there's no
> point in setting pieces of the IID differently
> 3) Another way to think about this is "compartmentalization": if you
> embed an ID from a layer below 8when you don't need to), if you screw up
> with how you generate it, the problem is exacerbated.
> 4) etc.
>
> I'm not sure whether to delve into all these details here, or just
> simply provide references to the reader, as we're currently doing. That
> is, the reuse of identifiers is well-covered in e.g.
> draft-gont-predictable-numeric-ids-00... and if we start to elaborate
> the reasons, the discussion will be incomplete or we will end up
> embedding such I-D into this one...
>
> Thoughts?
>
>

I don't think it is worth dealing with the details here either. Just a
simple "do this because of this broad/fundamental reason" should be
enough.

<snip>

>
>> "Having a variable maximum lifetime prevents
>>    an observer from synchronizing with the temporary address
>>    regeneration; that is, from being able to expect when address will be
>>    regenerated, and thus infer that one newly observed addresses is the
>>    result of regenerating a previously observed one."
>>
>> This draft seems to be going a bit further in this direction (in a
>> good way) than RFC4941 does (based on my brief reading of "3.5.
>> Regeneration of Randomized Interface Identifiers") RFC4941 seems to
>> have either host or interface universal values
>> (TEMP_PREFERRED_LIFETIME: 1day, TEMP_VALID_LIFETIME:1 week) for the
>> maximum lifetimes of temporary addresses. It looks to be focusing on
>> avoiding synchronised address changes across clients rather than
>> across addresses within a client.
>
> We're certainly going further than RFC4941: that's intentional.

OK. My interpretation was that the only change being made to RFC4941
was to drop the statement or a requirement that temporary addresses
were companions to stable addresses, rather than going further than
that.

> The goal
> of this requirement is to avoid the regeneration of a temporary address
> to become obvious to an observer -- because if it is obvious, there's no
> point in regenerating the temporary addresses.
>
>
>
>> "That is, a host that de-
>>    attaches from a network and subsequently re-attaches to a (possibly
>>    different) network should regenerate all of its temporary addresses."
>>
>> RFC4941 only very briefly deals with this scenario.
>
> IIRC, research had found that RFC4941 implementations were failing in
> this area.
>
>
>> I agree with doing
>> it, however I think there is a risk of a DoS on the link or similar if
>> an interface starts failing, and disconnects/re-connects rapidly. I
>> think there should be some prevention against this e.g., multiple
>> disconnects/connects within 3 seconds indicates the interface is
>> failing and regeneration of temporary addresses should not take place
>> if this occurs.
>
> I agree with you. There should certainly be some sort of limit. The
> specific value (e.g., multiple disconnects in X time) is less
> important... but the document should probably at least mention this and
> suggest some limit here.
>

Yes, I would see that as one of the further updates to RFC4941.

<snip>
<snip>
<snip>
>
>> Regarding using the MAC_Address,
>>
>> "Employing the MAC address in this expression (in replacement of the
>> Net_Iface parameter of the expression in RFC7217) means that the
>> re-generation of a randomized MAC address will result in a different
>> temporary address."
>>
>> it isn't clear to me whether randomised MAC addresses is a requirement
>> or a recommendation when using this algorithm. With it replacing
>> Net_Iface, it seems to be leaning towards a requirement.
>
> Your question/concern is certainly valid.
>
> Rationale: In RFC7217, you want a Net_Iface that is as stable as
> possible (and the MAC address might not be the best choice in such
> case). For temporary addresses, as long as Net_Iface uniquely identifies
> an interface, it's okay. You could certainly use anything (e.g., still
> use the interface name or interface index) for the generation of
> temporary addresses. However, if you use the MAC address, one property
> comes for free: if you happen to implement mac address randomization,
> you can be assured that whenever you regenerate an IPv6 address (after
> the mac address has been regenerated), the ipv6 address is going to change.
>
> FWIW, so far the I-D does not say much regarding whether you should do
> mac address randomization or not...
>

I think for the purposes of the algorithm, it would be good to state
whether randomised MACs are desirable or don't really matter.

<snip>

Regards,
Mark.