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

[Brian E Carpenter <[e-mail]>]

On 18/03/2016 04:31, Fernando Gont wrote:
> 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 think we need some careful wording here. I thought the intent
was that stacks MUST provide this mechanism (instead of a MAC-based
mechanism) as the default, with alternatives (such as manual
assignment or RFC4941) being configurable.

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

Indeed. What we are trying to fix is transparent mapping between
stable MAC addresses and IIDs.

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

And many campus or enterprise operators will have strong security arguments
for forbidding it. I see stable MAC addresses being around for ever in
many networks.

Not to say that the IETF can ignore randomized MACs, but we can't rely on
them either.

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

And that is the weakness in the current wording - you need to set the context
that the recommendation is for scenarios where RFC4941 does not apply,
that MAC addresses are not necessarily randomized, and that stable identifiers
are in fact operationally desirable. So this would be a mandatory to
implement default for such cases.

    Brian