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

[Fernando Gont <[e-mail]>]

Hi, Mark,

Thanks so much for your feedback! Please find my comments in-line...


On 03/15/2017 05:19 PM, Mark Smith wrote:
> Hi,
> 
> Firstly, I really like this draft.

Thanks!



> Suggestions/comments:
> 
> 
> o  3.3.  Requirements for Temporary IPv6 Addresses
> 
> " Temporary addresses MUST have a limited lifetime, which should be
>        different for different addresses."
> 
> For clarity, I'd suggest adding:
> 
> "This includes when a node has different addresses from within the same prefix."
>
>
> just to be very clear that there is a requirement of individual
> addresses, and that it doesn't change if they happen to be from within
> the same prefix. (I assume this is the case?)

Will do. Actually, this scenario is probably the most important one,...
so it's better be crystal clear.



> "  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?



> "This is
>    in contrast with e.g. stable addresses [RFC7217], that do not have
>    have a limited lifetime."
> 
> I think this is technically not true, the standard IPv6 preferred and
> valid lifetimes could cause a stable address to expire, so in those
> terms stable addresses, as do all IPv6 addresses, have a "lifetime"
> which may be limited (static addresses could be considered an
> exception, however it is only convention that when they're configured
> they have a infinite preferred and valid lifetime.)
> 
> Perhaps this would be more accurate:
> 
> "This is in contrast with e.g. stable addresses [RFC7217], who's
> values do not change in response to a privacy event or the expiration
> of a timer, such as the address's preferred or valid lifetime."

You're right. The current text is not really accurate. We'll certainly
add something along these lines (what you've suggested)...



> "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. 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.



> "Besides, a node that generates an IPv6 address by embedding
>    a link-layer address in the IPv6 address will, when configuring
>    addresses for different prefixes, result in the same IID being used
>    for such prefixes, thus allowing the corresponding traffic to be
>    correlated."
> 
> An example of significance might be correlation between internal ULA
> address traffic and external GUA address traffic if the IIDs are
> shared and the foreign entity has managed to capture both. ULA would
> tend to have greater privacy expectations or semantics because they're
> not global addresses and not intended to be exposed to global parties.

This is certainly worth incorporating. Thanks!



> "The resulting Interface Identifier SHOULD be compared against the
>        reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
>        and against those Interface Identifiers already employed in an
>        address of the same network interface and the same network
>        prefix."
> 
> Also against addresses on different network interfaces attached to the
> same network. Perhaps this IID comparison should really be taking
> place across all addresses from within and across prefixes independent
> of interfaces?  Actually, I think that is really saying that there is
> no IID duplication across any of the addresses used by the host.

Agreed. We'll clarify this.



>  "The algorithm in [RFC7217] can be augmented for the generation of
>    temporary addresses.  The benefit of this would be that a node could
>    employ a single algorithm for generating stable and temporary
>    addresses, by employing appropriate parameters.
> 
>    Nodes would employ the following algorithm for generating the
>    temporary IID:"
> 
> A brief mention of what is changed verses RFC7217 before presenting
> the algorithm would be useful. It seems MAC_Address and Time are the
> differences?

Yes. Essentially "Time" is what makes the resulting address change over
time. For Temp address, the secret_key *could* be randomized e.g. upon
system bootstrap.



> 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...




> nits:
> 
> -  " a
>    node may want to use only Temporary address (e.g., a temporary
>    address)."
> 
> This text seemed a little confusing because it seemed the temporary
> address text was being repeated. I realised that the capital T
> "Temporary" was a special word, perhaps the parenthesis text is
> unnecessary here. e.g.
> 
> " a node may want to use only Temporary address ."

Oops, this is an editorial error. The original text (previous rev of the
I-D) was:

   While the use of stable addresses (only) or mixed stable and
   temporary addresses can be desirable in a number of scenarios, there
   are other scenarios in which, for security and privacy reasons, a
   node may want to use only non-stable address (e.g., a temporary
   address).

But when we changed the use of "non-stable" to "temporary", the
parenthesis remained. We'll fix this. Thanks!



> - In the terminology section, it might be worth quoting a few of the
> repeatedly used terms from RFC7721 for the convenience of the reader.
> "Temporary address" would be an example.

Agreed. We'll copy&paste, and provide a reference to the RFC7721.



> - Should "stable address" be capitalised throughout as it too is a
> term defined in RFC7721?
> 
> - With both "Temporary address" and "temporary address" terms both
> being used, it seems like there is some sort of difference between
> what these terms mean. It's not really obvious to me what that
> difference is. It would seem to me that "Temporary address" (and
> "Stable address") should always be being used, as their definitions in
> RFC7721 would seem to apply universally.

The I-D currently has inconsistent use of Capitalization for these
terms, I guess the "Capitalized" version is useful to indicate that
we're employing the term defined in RFC7721, rather than simply
referring to a property of the address? Thoughts?



> - "3.3. Requirements for Temporary IPv6 Addresses
> 
>    The requirements for temporary IPv6 addresses are as follows:"
> 
> -"t","+"T"
> 
> "The requirements for Temporary IPv6 addresses are as follows:"

Will do.

Thanks so much!

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