Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>

[Alissa Cooper <[e-mail]>]

Thanks for these comments. Responses are in-line.

> On May 13, 2016, at 10:55 AM, 神明達哉 <[e-mail]> wrote:
> 
> At Wed, 11 May 2016 20:19:01 -0700,
> Bob Hinden <[e-mail]> wrote:
> 
>>       Title           : Recommendation on Stable IPv6 Interface Identifiers
>>       Authors         : Fernando Gont
>>                         Alissa Cooper
>>                         Dave Thaler
>>                         Will Liu
>>    Filename        : draft-ietf-6man-default-iids-11.txt
>>    Pages           : 23
>>    Date            : 2016-04-27
>> 
>>        https://tools.ietf.org/html/draft-ietf-6man-default-iids-11
>> 
>> as a Proposed Standard.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 25 May 2016.
> 
> I've read version 11 of the document.  Personally I don't have a
> strong objection to publishing it, but, if I understand the past
> concerns correctly, I suspect this version don't fully address them.
> I also have one non-trivial point, which I would like to be address
> before publication.
> 
> If my understanding is correct, one major concern raised in the past
> was that some implementors may simply not see the need for the
> stability and just want to address the security/privacy issues in a
> different way (such as just using randomized link-layer addresses).  I
> don't have a strong opinion on this particular concern myself, but I
> see the point of such concerns.  If the intent of this document is not
> to refuse the concern (which I'm not sure about), the current tone
> still seems to be too normative.  Again, I'm not sure if the intent is
> to address the concern, but if it is, I think something like the
> following will be necessary:
> 
> - clarify that this recommendation is only for environments where
>  address stability is needed

The document says exactly this in the introduction:

The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address.  That is, this document does not
   change any existing recommendations concerning the use of temporary
   addresses as specified in [RFC4941 <https://tools.ietf.org/html/rfc4941>], nor does it introduce any new
   requirements regarding when stable addresses are to be configured.
   Thus, the recommendations in this document simply improve the
   security and privacy properties of stable addresses.

The two paragraphs prior to this one in the intro also serve to explain this. 

> - clarify that this document assumes "link layer addresses" are
>  something permanent, such as MAC addresses that don't change
>  throughout the lifetime of the node using the hardware

The document purposefully does not assume that. We clarified this in the latest update to the introduction:

More generally, the reuse of identifiers that have their own
   semantics or properties across different contexts or scopes can be
   detrimental for security and privacy
   [I-D.gont-predictable-numeric-ids <https://tools.ietf.org/html/draft-ietf-6man-default-iids-11#ref-I-D.gont-predictable-numeric-ids>].  In the case of traditional
   stable IPv6 IIDs, some of the security and privacy implications are
   dependent on the properties of the underlying link-layer addresses
   (e.g., whether the link-layer address is ephemeral or randomly
   generated), while other implications (e.g., reduction of the entropy
   of the IID) depend on the algorithm for generating the IID itself.
   In standardized recommendations for IPv6 IID generation meant to
   achieve particular security and privacy properties, it is therefore
   necessary to recommend against embedding link-layer addresses in IPv6
   IIDs.


> - update the requirement level and wording to existing RFCs.  For
>  example, replaced text for RFC2462 provided in Section 6.1
> 
>   The Interface Identifier [AARCH] for an Ethernet interface MUST be
>   generated as specified in [RFCXXXX].
> 
>  is probably too strong, since this would invalidate any
>  implementation that doesn't implement or use RFCXXXX.  The same
>  sense of comment applies to all similar changes.

I’m not sure what you mean by “invalidate,” but the recommendations in Section 3 around which schemes to employ or not employ are all SHOULD-level requirements, by design.

> 
> And, one other point I want to be addressed: in Section 4 it states:
> 
>   By default, DHCPv6 server implementations SHOULD NOT generate
>   predictable IPv6 addresses (such as IPv6 addresses where the IIDs are
>   consecutive small numbers).  [I-D.ietf-dhc-stable-privacy-addresses]
>   specifies one possible algorithm that could be employed to comply
>   with this requirement.  Another possible algorithm would be to select
>   a pseudo-random value chosen from a discrete uniform distribution,
>   while avoiding the reserved IPv6 Interface Identifiers [RFC5453]
>   [IANA-RESERVED-IID].
> 
> I suggest just removing the second sentence.
> ietf-dhc-stable-privacy-addresses is not a dhc wg item anymore due to
> some controversy, and it's not clear what will happen to its
> successor in the form of individual submission:
> draft-gont-dhcpv6-stable-privacy-addresses-01
> Since this sentence is only to show an example, just showing the
> "another possible algorithm" would suffice.

I’m fine with the above change.

> 
> Finally, one minor editorial nit: in section 6.14
> 
>   for instance, using a method described in [8], to autoconfigure one
>   or more global unicast addresses.
> 
> there should be a 'cut here' line after this text.

Good catch, thanks.

Alissa

> 
> --
> JINMEI, Tatuya
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------