Subject: Discussion of default-iids and MAC address randomization and RFC4941

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Apr 2016 08:23:52 -0300

Folks,

Hopefully I'll be able to use this during the 6man meeting, but in any
case, I've posted some summary slides regarding the default-iids
document and MAC address randomization.

They are available here:
https://www.gont.com.ar/talks/ietf95-draft-ietf-6man-default-iids-additional.pdf

FWIW, IMO this whole discussion boils down to:

* Stable addresses are currently required

* This document replaces the existing scheme for producing stable
addresses with one that mitigates the security/privacy implications of
the traditional scheme.

* The IETF can work on a separate document that e.g., proposes the use
of RFC4941-only. Obviously, if such document was pursued/standardized,
the recommendations here would not apply, since they simply apply to
stable addresses.  --- i.e., this document doesn't mandate stable
addresses (stable addresses are mandated elsewhere!). We're just
replacing the algorithm employed for stable addresses, when you actually
generate them (which is "always" nowadays, as RFC4941 calls for that).

*  It's important that the implications around randomized MAC addresses
when used with traditional SLAAC be clearly spelled out (see the posted
slideware).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Apr 2016 21:02:14 +0900

Fernando,

going on the record now because I won't be in BA.

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

> when used with traditional SLAAC be clearly spelled out (see the posted

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.
   - Wastes 18 bits of entropy: "wastes" how? What's the downside?
   - 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

---

From: Dave Thaler <[email-masked]>
Date: Wed, 6 Apr 2016 12:13:17 +0000

I agree with Lorenzo’s points and I can try to represent them in this discussion.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, April 6, 2016 9:02 AM
To: Fernando Gont <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Discussion of default-iids and MAC address randomization and RFC4941

Fernando,

On Wed, Apr 6, 2016 at 8:23 PM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
* Stable addresses are currently required

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.

  *   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.
  *   Wastes 18 bits of entropy: "wastes" how? What's the downside?
  *   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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 6 Apr 2016 14:29:36 +0200

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.

i.e., I'm not even arguing against your desire of rfc4941. For instance, i
understand that there are scenarios in which you may want to do that. But
what's interferring with thqt is the existing specs (e.g., rfc4941), and
not this document.

This document applies only when uou generate stable addresses. Nowadays,
tjat happens to be "always" because other documents mandate 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

Could you please point me a spec tjat explains how to recover from a DAD
collision in a protocol where the premise is giving you a unique identifier?

In the same way that if we were to add this to draft-gont-numeric-ids as an
example of doing things wrong after 30 years of experience with that,
nobody can say that nobody noted it.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 6 Apr 2016 12:36:19 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fernando Gont
> Sent: Wednesday, April 6, 2016 9:30 AM
> To: Lorenzo Colitti <[email-masked]>
> Cc: [email-masked]; Chairs 6man <6man-
> [email-masked]>; [email-masked]
> 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.

Disagree that you need to use the random mac address as the net_iface
parameter of RFC 7217.  That is *one* way to do it.  It's not the only way to do it.
draft-ietf-6lo-privacy-considerations-00 contains a longer analysis that I
haven't heard any problems with so far.

> what's interferring with thqt is the existing specs (e.g., rfc4941), and not this
> document.
> 
> >> *  It's important that the implications around randomized MAC
> >> addresses when used with traditional SLAAC be clearly spelled out
> >> (see the posted slideware).
> >
> >
> "Android" then it is only mostly false. If "we" = "Linux" it is almost certainly
> false unless the host is using binary-only drivers.
> 

The IETF doesn't "control' anything.  It creates standards and implementations
choose to implement them or not.   I think this is a red herring in this discussion
though.

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

None of those answer the question.  The 18 bits aren't used for entropy.
A claim that it's a "waste" is a subjective value judgement that
additional entropy is more valuable than other things you might get
from those bits.   That statement needs to be backed up with justification.
draft-ietf-6lo-privacy-considerations-00 section 2 for example has an
(I think) objective discussion of amount of entropy needed.   Once
you get over a certain threshold relative to link lifetime, extra entropy
becomes much less valuable and other considerations may be greater.

Dave

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 6 Apr 2016 11:10:09 -0400

On Wed, Apr 6, 2016 at 8:36 AM, Dave Thaler <[email-masked]> wrote:

> privacy
> requirement
> draft-ietf-6lo-privacy-considerations provides much needed guidance for
using
privacy addresses in the M2M domain where the desire to provide efficient
IPv6 header compression may be overriding, especially for link local
traffic.
For the record, I have submitted comments to the 6lo mailing list (twice)
that
raise issues with this draft and I look forward to the discussion being
joined in
the 6lo WG.

Kerry

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Apr 2016 08:27:32 +1200

Hi Fernando,

> mac addresses and use the randomized mac address as the net_iface parameter

As I think I've tried to say several times, you *really* need to add new text
at the beginning of the Introduction to take account of what Lorenzo has been saying.
You just start of with a bang '...which typically results in hosts configuring one or
more "stable" addresses' and you should really start off with the need for privacy,
the fact that RFC4941 is the recommended solution for privacy, but that there
is a long-standing need for stable addresses too. Maybe you also need to state
that RFC4941-only is a valid scenario (which is new, I think). Then state that
when stable addresses are needed, predictable and traceable stable addresses
are a Bad Thing. Then you can start talking about SLAAC...

Regards
    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>