[LACNIC/Seguridad] Fwd: Re: Discussion of default-iids and MAC address randomization and RFC4941

[Fernando Gont]

Love it
---------- Mensaje reenviado ----------
De: Fernando Gont <fgont en si6networks.com>
Fecha: 6/4/2016 9:21
Asunto: Re: Discussion of default-iids and MAC address randomization and
RFC4941
Para: Lorenzo Colitti <lorenzo en google.com>
Cc: <draft-ietf-6man-default-iids en tools.ietf.org>, Chairs 6man <
6man-chairs en tools.ietf.org>, "6man en ietf.org" <6man en ietf.org>


El 6/4/2016 9:02, "Lorenzo Colitti" <lorenzo en google.com> escribió:
>
> Fernando,
>
> going on the record now because I won't be in BA.
>
> On Wed, Apr 6, 2016 at 8:23 PM, Fernando Gont <fernando en gont.com.ar>
wrote:
>>
>> * Stable addresses are currently required
>
>
> As should be clear by now, I disagree.
>
> Further, I think that unless that statement is heavily qualified and
applied only to specific use cases, there will need to be a substantial
privacy debate explaining how, even though "pervasive monitoring is an
attack", we are mandating that the IPv6 addresses on a given network be
stable for the life of the device. I think other parts of the IETF will
need to be involved in that debate as well.

Please check the slides I've attached. Stable addresses are not a
requirement of this document, but a requirement of existing specs.

This docunent applies *when* generqting stable addresses which, nowadays,
is always. If you don't want that, you keed to update rfc4941, or randomize
mac addresses and use the randomized mac address as the net_iface parameter
of RFC7217.

>> *  It's important that the implications around randomized MAC addresses
>> when used with traditional SLAAC be clearly spelled out (see the posted
>> slideware).
>
>
> There's a lot of FUD in that:
> We do not control whether MAC addr randomization algorithm is appropriate
or if it is actually possible. Not true - or rather, it's mostly not true.
The exact level of incorrectness depends on who "we" is. If "we" = "Apple",
then that statement is completely false. If "we" = "Windows" or "we" =
"Android" then it is only mostly false. If "we" = "Linux" it is almost
certainly false unless the host is using binary-only drivers.

We == ietf. This is not an android or mac devloping forum.

> Wastes 18 bits of entropy: "wastes" how? What's the downside?

Local/global bit, unicast/multicast bit, and 0xfffe. Talk to JC Zuñiga.

> Interoperability problems: depends heavily on the link layer. It's not
true that you can't recover from DAD failures using SLAAC, you can just
pick another number and try again.
> Of course, there's nothing new in my position, just like there's nothing
new in yours. I'd just like to make sure that nobody can later state that
the people who objected to the document are no longer objecting :-)
>
> Cheers,
> Lorenzo
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20160406/fd87eb44/attachment.html>