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

[Alissa Cooper <[e-mail]>]

Hi Lorenzo,

> On May 13, 2016, at 6:55 PM, Lorenzo Colitti <[e-mail]> wrote:
> 
> I continue to oppose this document.
> 
> This draft says that existing address generation mechanisms are bad for privacy, and proceeds to change them. But there is nothing wrong with the existing address generation mechanisms as if the link-layer addresses are not stable, (e.g., random MAC addresses), and a growing body of IETF work 
> 
> This draft forbids implementations from using existing address generation mechanisms using random MAC addresses,

The draft does not forbid anything. It has two MUST-level requirements: that mechanisms be defined, and that those mechanisms meet certain requirements. The other requirements in the draft are SHOULD/SHOULD NOT-level requirements, about what nodes should and shouldn’t do. IIRC there was a bunch of discussion early on about the normative strength of these requirements and landed on SHOULD/SHOULD NOT rather than MUST/MUST NOT purposefully because there were known exception cases.

> which is a perfectly valid way to address the privacy problem this draft is purportedly solving, and is an approach standardized in other IETF work, for example, https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-08#section-2.1 <https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-08#section-2.1> (now in RFC editor queue).
> 
> Here are several examples of how this draft forbids using address generation mechanisms with random MAC addresses.
> 
>    The recommendations in this document apply only in cases where
>    implementations otherwise would have configured a stable IPv6 IID
>    containing a link layer address.
> ...
>    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.
> ...
>    By default, nodes SHOULD NOT employ IPv6 address generation schemes
>    that embed the underlying link-layer address in the IID.

I disagree that any of the text above forbids anything, certainly not normatively.

> 
> These statements should not say "link-layer address". They should say "stable link-layer-address" or "non-ephemeral link-layer-address" or "link-layer address that are not known to be ephemeral".
> 
> Worse, consider this normative text:
> 
>    The entire text of Section 4 of [RFC2464] is replaced with the
>    following text:
> 
>    ---------------- cut here -------------- cut here ----------------
>    The Interface Identifier [AARCH] for an Ethernet interface MUST be
>    generated as specified in [RFCXXXX].
> 
> This explicitly prohibits an implementation from taking a random MAC address and forming an EUI-64 address out of it.

Again, because the contents of Section 3 do not prohibit anything, I don’t see how this could be interpreted to prohibit anything.

Alissa

> 
> On Fri, May 13, 2016 at 5:43 AM, Brian E Carpenter <[e-mail] <mailto:[e-mail]>> wrote:
> With the clarifying references to RFC4941, I think this document is
> in good shape and ready to be advanced.
> 
>     Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail] <mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------