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

[Fernando Gont <[e-mail]>]

Lorenzo,

On 05/13/2016 09:55 PM, Lorenzo Colitti wrote:
> 
> 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 

Yes, there is *a lot* wrong about that. Actually, the fact that we've
been embedding MAC addresses in the IID is the reason why we're having
this discussion.

Please read: draft-gont-predictable-numeric-ids for a discussion of why
embedding MAC addresses in the IID is bad.

Among others (and besides the reasons Brian already mentioned):

* Attempts to ignore a flaw, relying on something that we do not
control, and that the host may not control
  + e.g. we do not control whether MAC addr randomization algorithm is
appropriate or if it is actually possible to randomize it
  + it may be impossible for the node to randomize the MAC address

* Wastes 18 bits of entropy

* May lead to interoperability issues



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

It is not, as noted above. And I'm puzzled that after 30+ years of
improper numeric ids (draft-gont-predictable-numeric-ids), you keep
insisting on this.




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

Would "apply only in cases where implementations otherwise would embed a
link-layer address in the IID, as for traditional SLAAC addresses"?


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

Yes, this is intended. And too bad that you seem to keep pushing a
flawed scheme.


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

No. It says what it is meant to say. Please read:
draft-gont-predictable-numeric-ids



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

Exactly: you don't reuse identifiers in different layers, for different
scopes, etc. That's a horrible thing to do security&privacy-wise. I'm
glad that, at the very least, you're on record for proposing that and
that I'm on record for noting this is a bad idea. -- so that none can
say "we didn't know this could happen" when s* happens.

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