Subject: [saag] On numeric identifiers (Fwd: Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>)

From: Fernando Gont <[email-masked]>
Date: Tue, 17 May 2016 11:58:38 -0400

Folks,

FYI.

At the last privsec and saag meetings we did a presentation on
predictable numeric identifiers (draft-gont-predictable-numeric-ids).

And we essentially noted how this is a problem that has persisted for
30+ years, despite efforts (e.g. Bellovin and others) to fix some
instances of these.

Year 2016, I read this argument in favor of embedding a link-layer
address in the IPv6 IID (wasting 18 bits of entropy (0xfffe thing),
using a layer-2 identifier for a ayer-3 scope, etc., etc.).

The fact that people keep pushing this sort of flawed logic should give
you yet another datapoint regarding the motivation for writing
draft-gont-predictable-numeric-ids. (and could also be considered an
invitation to weigh in in the corresponding discussion :-) ).

Thanks,
Fernando

-------- Forwarded Message --------
Subject: 	Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>
Date: 	Sat, 14 May 2016 10:55:26 +0900
From: 	Lorenzo Colitti <[email-masked]>
To: 	Brian E Carpenter <[email-masked]>
CC: 	IETF IPv6 Mailing List <[email-masked]>

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, 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
<[email-masked] <mailto:[email-masked]>> 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
    [email-masked] <mailto:[email-masked]>
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------