Re: default-iids ready for WGLC? (Re: I-D Action: draft-ietf-6man-default-iids-10.txt)

[Fernando Gont <[e-mail]>]

On 03/17/2016 10:19 AM, Lorenzo Colitti wrote:
> On Wed, Feb 17, 2016 at 8:09 PM, Fernando Gont <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     This rev addresses the feedback received on-list, mostly y Alex, Brian,
>     and Ray.
> 
>     I personally think that this one should be ready for WGLC.
> 
> 
> I have various objections to this document.
> 
> First: I don't see why the document require that the link layers MUST
> provide stable identifiers. What if a link layer or a host does not want
> a stable identifier? What about privacy threats?

Are you are arguing in favor of RFC4941-only, o what?



> I do not support the recommendation to use RFC7217 because doing so
> creates a false sense of security.

So... fixing a bug/hole creates a false sense of security?



> RFC 7217 and similar schemes provide
> protection against some threats but not others. Randomizing the
> link-layer provides much better protection, and is what other parts of
> the IETF are moving towards - see for example
> draft-ietf-dhc-anonymity-profile, which pretty much takes MAC address
> randomization as a given.

MAC address randomization is going to break many of the security
controls currently employed. -- including simple captive portals that
allow connectivity based on your MAC address.

Besides, many devices may not even be capable of doing MAC address
randomization.

Besides, MAC addresses are IEEE's turf, not IETF's. And, the logic of
keeping some vulnerable part blaming the layer bellow is simply flawed.

The traditional SLAAC addresses have security and privacy implications,
as explained in RFC7721, and it's our job to address them.


> In various places, the document talks about "the interface identifier".
> This does not match reality because most IPv6 hosts have more than one
> IPv6 address formed using more than one IID.

"the interface identifier [of the ipv6 address in question]".



> I don't see how it's useful or constructive to suddenly declare billions
> of implementations no longer compliant with specs that have been current
> for nearly 20 years (e.g., RFC2464 is from 1998).

Firstly, some implementations that have cared about sec/priv have been
"non-compliant" for years.

Secondly, an update obviously means that implementations need to be
updated to comply with the newly published specs. Otherwise the new spe
would be a noop, and we wouldn't be publishing it, right?



> Instead of a sweeping update to lots of IPv6-over-foo documents, I'd
> much rather see a best current practice that suggests that hosts do
> something sane to address this sort of threat. "Something sane" should
> probably be MAC address randomization, but could also be
> RFC7217+RFC4941, etc.

Embedding the MAC address in the IID is part of such specs. Obviously,
if we want that to change, we need to update them.

Besides, what we're saying here is that the traditional SLAAC addresses
should be replaced with RFC7217. Use of RFC4941 is orthogonal.

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