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

[Mark Smith <[e-mail]>]

On 14 May 2016 11:56 AM, "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
>

The thing wrong with "solving" a layer 3 problem at layer 2 is that it
makes the effectiveness of the layer 3 outcome entirely dependent on the
attributes of another layer. It's fundamentally a layer violation.

I think we have layers to try to minimise or avoid these dependencies.
Having a layer 3 privacy solution to this layer 3 privacy problem means
that it doesn't matter if the layer 2 privacy is terrible or not.

I don't think this draft is forbidding layer 2 privacy at all - it is
forbidding relying on it at layer 3, because it can't and I don't think
should be relied on.

Regards,
Mark.

> This draft forbids implementations from using existing address generation
mechanisms using random MAC addresses, 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
(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.
>
> 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.
>
> On Fri, May 13, 2016 at 5:43 AM, Brian E Carpenter <
[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]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>