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

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Mar 2016 09:18:49 -0300

Ping?

On 03/07/2016 07:13 PM, Fernando Gont wrote:
> Folks,
> 
> Ping?
> 
> 
> On 02/17/2016 08:09 AM, Fernando Gont wrote:
>> Folks,
>>
>> 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.
>>
>> Thoughts?
>>
>> Thanks!
>>
>> Best regards,
>> Fernando
>>
>>
>>
>>
>> On 02/17/2016 08:03 AM, [email-masked] wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the IPv6 Maintenance of the IETF.
>>>
>>>         Title           : Recommendation on Stable IPv6 Interface Identifiers
>>>         Authors         : Fernando Gont
>>>                           Alissa Cooper
>>>                           Dave Thaler
>>>                           Will Liu
>>> 	Filename        : draft-ietf-6man-default-iids-10.txt
>>> 	Pages           : 22
>>> 	Date            : 2016-02-17
>>>
>>> Abstract:
>>>    This document changes the default Interface Identifier generation
>>>    scheme for SLAAC to that specified in RFC7217, and recommends against
>>>    embedding link-layer addresses in IPv6 Interface Identifiers.  It
>>>    formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492,
>>>    RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391,
>>>    RFC5072, and RFC5121, by removing the text in these RFCs that
>>>    required the IPv6 Interface Identifiers to be derived from the
>>>    underlying link-layer address, and replacing the aforementioned text
>>>    with a pointer to this document.  Additionally, this document updates
>>>    RFC3315 by specifying additional requirements on the generation of
>>>    Interface Identifiers used in Dynamic Host Configuration Protocol
>>>    version 6 (DHCPv6).  It also provides advice to system administrators
>>>    who employ manual configuration.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-6man-default-iids-10
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-default-iids-10
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [email-masked]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
> 
> 

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Mar 2016 22:19:19 +0900

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

I do not support the recommendation to use RFC7217 because doing so 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.

I-D.ietf-dhc-stable-privacy-addresses is in state dead and should be
removed.

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.

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

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.

Regards,
Lorenzo

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Mar 2016 12:31:47 -0300

On 03/17/2016 10:19 AM, Lorenzo Colitti wrote:
> On Wed, Feb 17, 2016 at 8:09 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 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.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Mar 2016 16:12:24 +1300

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

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

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

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.

> 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

---

From: [email-masked]
Date: Fri, 18 Mar 2016 09:57:23 +0100

> implement default for such cases.

+1.

text proposal?

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Mar 2016 20:31:16 +0900

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

I'm arguing against being overly prescriptive. There is no reason to
require that links must provide stable identifiers, and there are security
risks involved in doing so.

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

Absolutely, if you fix only half of it but you or other people claim or
think you've fixed all of it.

Example: I have personally met many security engineers who think that
DHCPv6 is more secure than SLAAC, even on networks that they *know* have no
layer 2 security and thus allow anyone to spoof anyone else's address and
create new addresses at will. That's a false sense of security.

> allow connectivity based on your MAC address.

Captive portals usually time out at most every 24 hours, often much much
less. And on many link layers (e.g., Ethernet) security via MAC addresses
is so bad that it's worse than no security at all.

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

Just like many devices may not be capable of implementing whatever you
propose in this document.

> keeping some vulnerable part blaming the layer bellow is simply flawed.

Also flawed is suggesting that we implement a function (privacy) in one
layer (the IP layer) when the lower layer  (the link layer) can implement
it better. HTTP doesn't implement congestion control control or packet
retransmissions, for example. It relies on the lower layer to do that.

> as explained in RFC7721, and it's our job to address them.

And we can best address all of those implications by taking a holistic view
of the threat and pushing for the solution that best counters it.

> would be a noop, and we wouldn't be publishing it, right?

Are we publishing it? I don't think we should. It's silly to force all that
work on implementations when we can solve more of the problem at a
different layer.

> if we want that to change, we need to update them.

Actually, the reality is that we don't need to update the specs at all. As
the draft itself points out, several platforms have already switched away
from using EUI-64 addresses. Those platforms did that of their own accord,
without needing us to publish an RFC to tell them to do it.

> should be replaced with RFC7217. Use of RFC4941 is orthogonal.

You're saying much, much more than that.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Mar 2016 09:17:50 -0300

On 03/18/2016 08:31 AM, Lorenzo Colitti wrote:
> On Fri, Mar 18, 2016 at 12:31 AM, Fernando Gont <[email-masked]
> require that links must provide stable identifiers, and there are
> security risks involved in doing so.

You're wrong.

See Brian's post for an explanation of stable addresses.

Regarding risks, there are risks in connecting to a network in the first
place. Since communication is typically two-way all addresses have some
level of stability. e.g., temporary addresses do allow network activity
correlation, albeit for a more reduced period of time.

> think you've fixed all of it.

You're wrong, again. For multiple reasons.

We're not fixing half of the problem. We're fixing as much as there is
to be fixed. See RFC7217 for the goals of the algorithm. We want
addresses that are stable within a network (for operational reasons),
but that are not predictable, and that change as you move from one
network to another.

> DHCPv6 is more secure than SLAAC, even on networks that they *know* have
> no layer 2 security and thus allow anyone to spoof anyone else's address
> and create new addresses at will. That's a false sense of security.

So.. what? You're telling me that because you talked to a guy that was
clueless, we shouldn't fix a known problem? You're not making any sense.

> layer (the IP layer) when the lower layer  (the link layer) can
> implement it better. HTTP doesn't implement congestion control control
> or packet retransmissions, for example. It relies on the lower layer to
> do that.

You're wrong.

We're not "implementing a function": addressing is already there
(actually, it's a key function of layer-3, and not of layer-2), and the
current specs require that you put your serial number in your address,
which is announced to the world.  In the context of RFC7258, that's
unacceptable.

Security 101 says that when you have a flaw, you address the flaw. It is
well known that keeping a flaw under the assumption that such flaw will
not become evident or triggered because of something that you assume
can/will happen somewhere else (e.g., lower layer) is completely flawed
reasoning, that leads to insecure systems.

I'm quite surprised you're even suggesting that.

> Actually, the reality is that we don't need to update the specs at all.
> As the draft itself points out, several platforms have already switched
> away from using EUI-64 addresses. Those platforms did that of their own
> accord, without needing us to publish an RFC to tell them to do it.

You're wrong, once more:

The scheme implemented by Microsoft Windows prevents address scanning,
but not host tracking.

And the scheme adopted by Linux is indeed specified in an RFC (RFC7217),
as you obviously know.

Some implementations have had to deviate from our specs because what
we're recommending has bad security/privacy implications. That's an
indication that we do better and update such specs as necessary, rather
than an argument for not doing so.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Mar 2016 21:24:23 +0900

> See Brian's post for an explanation of stable addresses.

His explanation was way more subtle and nuanced than this draft is.

> correlation, albeit for a more reduced period of time.

Well, if your point of view is that there are always risks and we just have
to accept that, then there's no point publishing this document because we
can just continue to use EUI-64 everywhere.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Mar 2016 10:14:09 -0300

On 03/18/2016 09:24 AM, Lorenzo Colitti wrote:
> On Fri, Mar 18, 2016 at 9:17 PM, Fernando Gont <[email-masked]

If there's something that is not clear, please ask for a clarification,
and we'll do our best.

> Well, if your point of view is that there are always risks and we just
> have to accept that, then there's no point publishing this document
> because we can just continue to use EUI-64 everywhere.

Please re-read what I wrote.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Mar 2016 22:52:55 +0900

> If there's something that is not clear, please ask for a clarification,

If you look at his text, it's carefully written to ensure it doesn't apply
in many situations and is targeted at a subset of use cases. Instead, the
draft just bluntly says "MUST support stable interface identifiers", period.

> Please re-read what I wrote.

Re-reading it didn't help. A stable address that never expires is way worse
for privacy than one that changes every day. There's just no way around
that.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Mar 2016 11:03:39 -0300

On 03/18/2016 10:52 AM, Lorenzo Colitti wrote:
> On Fri, Mar 18, 2016 at 10:14 PM, Fernando Gont <[email-masked]
> If you look at his text, it's carefully written to ensure it doesn't
> apply in many situations and is targeted at a subset of use cases.
> Instead, the draft just bluntly says "MUST support stable interface
> identifiers", period.

It's the other way around actually. RFC4941 specifies addresses that are
employed along stable addresses.

There is no spec proposal for employing RFC4941-only, since, in the
general case, you always want stable addresses (besides also possibly
wanting RFC4941).

> Re-reading it didn't help. A stable address that never expires is way
> worse for privacy than one that changes every day. There's just no way
> around that.

Again: use of RFC4941 is orthogonal to this document. We're improving
the properties of stable addresses, not saying that you shouldn't use
RFC4941. As noted above, use of RFC4941 is orthogonal.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Mar 2016 23:36:08 +0900

> general case, you always want stable addresses (besides also possibly

Actually, as a mobile host, I don't "always want stable addresses".
Actually, I *mostly don't* want stable addresses.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 19 Mar 2016 08:01:11 +1300

>> implement default for such cases.

I think that the text above can easily be modified to be the first sentence of the
Abstract and the Introduction.

There's a curious point about standards here - all standards are optional, so
"MUST" always means "if applying this standard, you MUST".

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 18 Mar 2016 13:15:58 -0300

On 03/18/2016 11:36 AM, Lorenzo Colitti wrote:
> On Fri, Mar 18, 2016 at 11:03 PM, Fernando Gont <[email-masked]

Stable for a day is not much of a difference than stable. Besides, you
don't need to use them -- indeed, nodes that employ privacy addresses
use those for outgoing connections.

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Mar 2016 14:04:54 +1100

> use those for outgoing connections.

Agree.

This is about replacing the existing default stable IID IPv6 address,
based on MAC address, with another type of stable IID IPv6 address,
that has better security properties. It retains the stability
attribute which is necessary or useful in a number of scenarios, e.g.,
servers, router interfaces or networks where they wish clients to have
stable IIDs (i.e., ones where if privacy addresses are enabled by
default by an OS, they'd switch them off).

Regarding mobile hosts, I'd certainly expect my Android device to keep
having a privacy address and to keep using them for outgoing
connections in preference to any of the addresses created stable IIDs
using RFC7217. That is also the preference codified in RFC6724 in Rule
7.

Perhaps Lorenzo's difference of opinion is because he's noticed a use
case for a temporary address only host, which would conflict with
SLAAC generating stable IID IPv6 addresses by default using RFC7217. I
don't think it is a conflict with this specific draft though - it is a
conflict with the SLAAC and related IPv6-over-foo RFCs, that have
always generated stable IID addresses, based on MAC address.

So I think this draft should be published to replace the existing MAC
based stable IIDs with RFC7217 based stable IIDs. There probably then
should be some separate work to say that:

o  SLAAC normally generates stable IID addresses by default, either
EUI-64 based or RFC7217 based (after this draft is an RFC)

o  even though privacy addresses can be added to the host and will be
used in preference to the stable IID addresses per RFC7217, there are
some use cases where there is no need for stable IID addresses at all
e.g., mobile host, which is a client or a temporary server only use
case

o  therefore, the generation of stable IID addresses by default by
SLAAC is still the default, but it is now an optional default, and
hosts with temporary only addresses are still a valid SLAAC
configuration

Regards,
Mark.

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 19 Mar 2016 04:29:04 -0700

> On Mar 18, 2016, at 8:04 PM, Mark Smith <[email-masked]> wrote:
> 

I like this approach, along with Brian’s suggestion. I have been uncomfortable with the idea that we’re in a sense leaving out of this draft the discussion of temporary addresses without being clear that we’re doing so.

Alissa

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Mar 2016 23:41:51 +1100

Slight correction, just to ensure no ambiguity,

>>>>    general case, you always want stable addresses (besides also possibly
<snip>

>> used in preference to the stable IID addresses per RFC7217,

actually per RFC6724,

>> there are

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 21 Mar 2016 15:21:04 +0900

Mark,

I think you're not actually getting the point here. Let me slightly correct
your wording.

> that has better security properties.

"better" -> "better, but not as good as MAC address randomization"

> It retains the stability attribute which is necessary or useful in a
> number of scenarios

"retains" -> "forces"

> case for a temporary address only host

My difference of opinion is that from the perspective of an implementer,
this documents prescribes useless work for no gain. Any platform that's
privacy-conscious will have to implement MAC address randomization
eventually, and if a platform has already implemented MAC address
randomization, implementing RFC7217 provides zero additional security
benefit.

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 21 Mar 2016 15:37:20 +0900

On Sat, Mar 19, 2016 at 1:15 AM, Fernando Gont <[email-masked]>
wrote:

> Stable for a day is not much of a difference than stable.

I'm sorry, but that's absurd. You can't maintain that a permanent address
is not much different from one that changes every day.

First of all that is completely against common sense. If you have common
sense, then, second - it is directly conflicting with existing IETF
standards in the form of RFC4941, whose only purpose is privacy, and which
suggests a default preferred lifetime of one day. Third - some of the
arguments that you use in section 1 to argue that embedding link-layer
addresses are bad are in fact *not* related to embedding the link-layer
address, they are related to having a *permanent identifier*. Example:
network activity correlation is easy using RFC7217 addresses - anyone who
has seen your address once (e.g., a server that you connected to) can track
you for the rest of time whenever you visit another server.

In case you are inclined to respond to some of the points above by saying
that we have RFC 4941-style temporary addresses, then you can't use that
argument until:

   1. You discuss in this draft how using RFC 4941 mitigates the privacy
   threats on which the draft's recommendations are based.
   2. You explain in this draft how RFC 4941 is not sufficient to eliminate
   those privacy threats, and how the recommendations in this document are
   sufficient to do so.

Regards,
Lorenzo

---

From: Mark Smith <[email-masked]>
Date: Mon, 21 Mar 2016 18:15:34 +1100

On 21 Mar 2016 17:21, "Lorenzo Colitti" <[email-masked]> wrote:
>
> Mark,
>
> I think you're not actually getting the point here. Let me slightly
correct your wording.
> "better" -> "better, but not as good as MAC address randomization"

Right, but as Fernando said, it's the layer below, and we can't rely on it
either being supported, effective (hello ARCnet :-) ) or enabled.

(I've had randomised MAC addresses generated at boot on my two desktops and
two laptops for at least a year, so I see value in them. However they do
confuse my TV though - it uses MAC addresses to uniquely identify DLNA
servers, so over time I get a list of dead servers with the same name.)

number of scenarios
> "retains" -> "forces"

Of course, RFC7217s as SLAAC defaults won't stop privacy addresses being
able to be used and preferred.

I find the idea of a privacy addresses only host interesting (link locals
might need a spec update because their lifetimes are infinite).

In a corporate or ISP environment I would prefer my MAC addresses not to be
randomised on my server and router interfaces, because vendor OUIs are
quite useful during troubleshooting, and they're private because they're
private to my  private links. However, if those devices IPv6 addresses can
leak externally, e.g. via traceroutes or mail headers, then I want RFC7217
addresses for them, rather than EUI-64 based.

Of course it wouldn't be that hard to do that manually, but I'm lazy and
error prone, automatically done out of the box overcomes my human frailties.

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Mar 2016 14:39:20 +0100

> "better" -> "better, but not as good as MAC address randomization"

MAC address randomization happens at layer-2. This is happening at
layer-3. Right now, the two of these are entangled, and that's a bad thing.

We need to fix the problem we have in layer-3, at layer-3. Keeping a
flaw at layer-3 based n the assumption that something (e.g., MAC addr
randomization) that you may have no control on (from the pov of layer-3)
will not happen is a really flawed security logic.

This is like saying: "I will not wear a helmet because I'll ride my bike
at a time there are no cars in the streets".

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Mar 2016 14:50:24 +0100

On 03/21/2016 07:37 AM, Lorenzo Colitti wrote:
> On Sat, Mar 19, 2016 at 1:15 AM, Fernando Gont <[email-masked]
> I'm sorry, but that's absurd. You can't maintain that a permanent
> address is not much different from one that changes every day.

What I'm saying is that if you're really concerned about network
activity correlation over time, then you should use throw away
addresses, one for each connection (good luck with that)... and even
then, that might not be enough because you could/would be tracked base
on the prefix.

> standards in the form of RFC4941, whose only purpose is privacy, and
> which suggests a default preferred lifetime of one day.

Huh? RFC4941 specifies temporary addresses that are employed along
stable addresses. We're improving such temporary addresses. Where's the
conflict?

> Third - some of
> the arguments that you use in section 1 to argue that embedding
> link-layer addresses are bad are in fact *not* related to embedding the
> link-layer address, they are related to having a *permanent identifier*.

They are related with overloading the IID. Please see:
<https://tools.ietf.org/html/draft-gont-predictable-numeric-ids-00>

You want to re-use in layer-3 an identifier that you got from layer-2,
in a different context, and in a different scope. That's really bad
security logic, asking for trouble.

> Example: network activity correlation is easy using RFC7217 addresses -
> anyone who has seen your address once (e.g., a server that you connected
> to) can track you for the rest of time whenever you visit another server.

RFC7217 allows correlation over time, not across networks. And we do
that by design. It's not a flaw of the system, but actually a design goal.

> In case you are inclined to respond to some of the points above by
> saying that we have RFC 4941-style temporary addresses, then you can't
> use that argument until:
> 

We have the whole RFC7721 for that. There's no need for this document to
rehash all such discussion. In fact, that'd be wrong.

>  2. You explain in this draft how RFC 4941 is not sufficient to
>     eliminate those privacy threats, and how the recommendations in this
>     document are sufficient to do so.

Again, please read RFC7721. Short version of the story: RFC4941 are
employed along stable addresses. RFC7217 is simply an improvement to
such stable addresses.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2016 10:37:24 +1300

Lorenzo,
> randomization, implementing RFC7217 provides zero additional security

That is absolutely not true for deployments in which MAC address
randomization is not allowed, which I expect will be the case in many
campus-style managed networks.

The implementation of RFC7217 is rather simple, isn't it? Anyway it appears
to have been done already for Linux:
http://roy.marples.name/projects/dhcpcd/info/8aa9dab00dc72c453aeccbde885ecce27a3d81ff

It's actually quite hard to switch off on Windows:
netsh int ipv6 set global randomizeidentifiers=disabled

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Mar 2016 07:43:44 +0900

> either being supported, effective (hello ARCnet :-) ) or enabled.
If that's the concern, then say that this is only necessary on platforms
that don't implement MAC address randomization. Because it isn't.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Mar 2016 07:49:01 +0900

> at a time there are no cars in the streets".

Oooh, fun! Can I play too? Here's mine: "it's like saying I will not wear a
bike helmet because I'm already wearing a motorcycle helmet".

Seriously: if you have MAC address randomization, RFC 7217 does nothing to
help privacy. I know you don't want to hear that, but it's true and nothing
you say will change it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Mar 2016 08:00:09 +0900

> campus-style managed networks.

Ah, I see. "We want the device to have privacy from the network, but only
if the network wants to allow it."

Please make it very clear that that is in fact the intent, then. Include
text in the draft that says that this is a position that is designed to
trade off privacy with network control and that this working group is
comfortable attempting to mandate such this policy in the strongest way
possible, by mandating it as a MUST in all IPv6-over-foo standards,
including ones already published, such that a compliant implementation
cannot choose to do something else.

Then we can have a proper debate about the privacy implications.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 21 Mar 2016 23:58:10 +0100

On 03/21/2016 11:49 PM, Lorenzo Colitti wrote:
> Oooh, fun! Can I play too? Here's mine: "it's like saying I will not
> wear a bike helmet because I'm already wearing a motorcycle helmet".
> 
> Seriously: if you have MAC address randomization, RFC 7217 does nothing
> to help privacy. I know you don't want to hear that, but it's true and
> nothing you say will change it.

Let me quote my previous email:

  We need to fix the problem we have in layer-3, at layer-3. keeping a
  flaw at layer-3 based n the assumption that something (e.g., MAC addr
  randomization) that you may have no control on (from the pov of layer-3)
  will not happen is a really flawed security logic.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 22 Mar 2016 00:01:32 +0100

On 03/21/2016 11:43 PM, Lorenzo Colitti wrote:
> On Mon, Mar 21, 2016 at 4:15 PM, Mark Smith <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Right, but as Fernando said, it's the layer below, and we can't rely
>     on it either being supported, effective (hello ARCnet :-) ) or enabled.
> 

The root of the problem in all this things is overloading identifiers in
ways that are not needed.

Keeping traditional SLLAC still overloads the IPv6 IID unnecessarily
with an ID from layer-2 that you shouldn't be embedding in layer-3.

That's the root of the problem. If you randomize MAC addresses then,
from the pov of IPv6, you're attacking the symtom, rather than the disease.

(Besides, that wastes 16 bits of entropy.)

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Mar 2016 08:03:17 +0900

>   randomization) that you may have no control on (from the pov of layer-3)

The implementers *do* have control over layer 2. They are the ones that set
hardware requirements, including the ability or non-ability of hardware to
do MAC address randomization.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 22 Mar 2016 00:10:13 +0100

On 03/22/2016 12:00 AM, Lorenzo Colitti wrote:
> On Tue, Mar 22, 2016 at 6:37 AM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Ah, I see. "We want the device to have privacy from the network, but
> only if the network wants to allow it."

Nobody is arguing against deployment of RFC4941.

Again we're simply improving the stable addresses that play along RFC4941.

> cannot choose to do something else.

IPV6-over-foo mandate embedding MAC aaddresses in layer-3 addresses,
which is a bad thing. And layer-2 addresses is not IETF's turf.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Mar 2016 08:14:30 +0900

> then, that might not be enough because you could/would be tracked base

"It's impossible to drive risk down to zero, so any level of risk is OK and
there is no need to decrease risk."

> stable addresses. We're improving such temporary addresses. Where's the

My point is that we have IETF consensus and a standards
track RFC recommending addresses change once a day for privacy reasons.
Saying that changing addresses once a day does not improve privacy
contradicts the existence of that standards track RFC.

> security logic, asking for trouble.

It's bad security logic if the identifier less secure than you can provide
yourself. But in this case it's more secure.

> that by design. It's not a flaw of the system, but actually a design goal.

Right. What I'm saying is that I disagree with that goal because I think
it's bad for privacy.

> rehash all such discussion. In fact, that'd be wrong.

And RFC 7721 section 3.1 backs me up. The privacy threat is not due to
reusing L2 identifier, but due to the fact that the L2 identifier is a
*long-lived* identifier:

The correlation made possible by IEEE-identifier-based IIDs
   is of particular concern since they last roughly for the lifetime of
   a device's network interface, allowing correlation on the order of
   years.

... which is roughly the same property (i.e., addresses never change) as
the RFC7217-by-default policy this draft advocates.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Mar 2016 08:16:14 +0900

> Again we're simply improving the stable addresses that play along RFC4941.

But you are arguing against MAC address randomization. That is bad for
privacy.

> which is a bad thing. And layer-2 addresses is not IETF's turf.

As an implementer, I really don't care whose turf is whose. I want the
solution that's best for my users.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 22 Mar 2016 00:34:44 +0100

On 03/22/2016 12:16 AM, Lorenzo Colitti wrote:
> But you are arguing against MAC address randomization. 

We're not. You're free to do whatever you want to do at layer-2.

What we're doing here is essentially disentangling what you do at
layer-2 with what we do at layer-3 -- because that's the right thing to
do, and because reusing I-Ds fro different layers, in different scopes,
etc.,, is known to have issues, including sec/privacy. Again, please
see: <https://tools.ietf.org/html/draft-gont-predictable-numeric-ids-00>.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 22 Mar 2016 00:47:55 +0100

> track RFC recommending addresses change once a day for privacy reasons.

That's false.

Please read RFC4941. It specifies addresses that are employed *along*
stable addresses NOT *in replacement of*.

> It's bad security logic if the identifier less secure than you can
> provide yourself. But in this case it's more secure.

No. It's bad logic. You don't reuse identifiers for contexts where they
are not meant for.

Besides, SLAAC as is wastes 16 bits of the IID - because since we
started reusing IDs that we shorter than what we needed, they had to be
padded (oxfffe).

> Right. What I'm saying is that I disagree with that goal because I think

Use RFC4941 for the outgoing connections, as it's usually the case.

> the RFC7217-by-default policy this draft advocates.

The privacy issue is because of that. The root of the problem is
overloaded IDs being reuse all over the place.

Again, please read
<https://tools.ietf.org/html/draft-gont-predictable-numeric-ids-00>.

And remember that RFC4941 is used along stable addreses, that
ipv6-over-foo mandate reuse of IDs (which is a bad thing), and that MAC
addr randomization: 1) may not be possible, and/or 2) May not be
desireable, 3) is nto standardized by the IETF...

Othewise I'm repeating myself once over and over again.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Mar 2016 13:34:04 +1300

On 22/03/2016 12:00, Lorenzo Colitti wrote:
> trade off privacy with network control

As I said several rounds earlier in this cage fight, there is indeed an
explanation missing in the Introduction to this draft about how it fits with
privacy addresses and network policy. Mostly, Lorenzo and Fernando seem to
be talking past each other because this text is lacking. Both of you are right,
I think.

> and that this working group is

If we're talking about a default choice of stable IID, orthogonal to the
decision to enable privacy addresses by default, I am very comfortable
that it's  within this WG's remit.

> Then we can have a proper debate about the privacy implications.

We had it already: https://tools.ietf.org/html/rfc7721#section-4.5

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Mar 2016 09:48:12 +0900

> We had it already: https://tools.ietf.org/html/rfc7721#section-4.5

Even if that section properly considered all the issues - which I contend
is not possible given that it's only 11 lines long - 7721 is an
informational RFC which makes no recommendations on this topic.

The bar for what this draft is proposing (MUST provide stable identifiers
by default, update all the IPv6-over-foo docs to require RFC7217) is much
higher.

---

From: Mark Smith <[email-masked]>
Date: Tue, 22 Mar 2016 11:51:20 +1100

> > Ah, I see. "We want the device to have privacy from the network, but
only
> privacy addresses and network policy.

That sort of text exists in the intro to RFC7217. Duplicating it or
summarising it in this draft shouldn't hurt.

Mostly, Lorenzo and Fernando seem to

---

From: Fernando Gont <[email-masked]>
Date: Tue, 22 Mar 2016 02:34:24 +0100

FWIW, I'll be incorporating the text suggested by Brian. If you have any
suggestions, please suggest sooner than later.

Thanks!

Cheers,
Fernando

On 03/22/2016 01:48 AM, Lorenzo Colitti wrote:
> On Tue, Mar 22, 2016 at 9:34 AM, Brian E Carpenter
> Even if that section properly considered all the issues - which I
> contend is not possible given that it's only 11 lines long - 7721 is an
> The bar for what this draft is proposing (MUST provide stable
> identifiers by default, update all the IPv6-over-foo docs to require
> RFC7217) is much higher.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 22 Mar 2016 07:07:00 -0400

> do MAC address randomization.

That is not always true though. I can think of a number of scenarios
where the hardware requirements are outside of the control of the
software developers (e.g., Linux).

Regards,
Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Mar 2016 20:51:22 +0900

> software developers (e.g., Linux).

Agreed, my statement is true for most but not all devices, though even on
Linux it should be feasible to implement MAC address randomization as long
as you have the driver source code.

What concerns me the most is that platforms that are already implementing
MAC address randomization, and that have strong privacy requirements,
should not be forced to implement RFC 7217, which from a privacy
perspective is inferior to EUI-64 with MAC address randomization.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 Mar 2016 08:08:12 +1300

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

> perspective is inferior to EUI-64 with MAC address randomization.

You're right, and that is part of the missing "applicability statement"
text in the draft. I'm looking forward to the next version...

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 23 Mar 2016 21:38:26 +0100

Hi, Alissa,

On 03/23/2016 05:44 AM, Alissa Cooper (alcoop) wrote:
> 
>> On Mar 21, 2016, at 6:34 PM, Fernando Gont <[email-masked]
> I took a crack at updated text for the introduction. If we can get
> agreement on that then the abstract can be fixed. I did not have the
> source so edited the text.
> 
> Edited
> text: https://github.com/coopdanger/default-iids/blob/master/draft-ietf-6man-default-iids-11.txt
> Diff: http://bit.ly/1MBj0Lb

Thanks for crafting this text.

Specific comments:

>    The security and privacy drawbacks of embedding a link-layer address in an
>    IPv6 IID are to a great extent dependent upon the properties of the
>    link-layer address itself -- whether it is a globally unique and permanent
>    IEEE identifier that embeds an OUI, whether it is ephemeral and randomly
>    generated, or whether it has other properties.

This is true to some extent. But embedding a layer-2 identifier in a
layer-3 address is wrong in the first place (see
<https://tools.ietf.org/id/draft-gont-predictable-numeric-ids-00.txt>).
Here we're trying to find specific cases (e.g., randomized MAC
addresses) for which embedding them in the IID is "less wrong", rather
than tackling the problem right-away.

For instance, even with randomized MAC addresses, you're wasting 16 bits
of entropy, just because, since you based the IIDs on MAC addresses, and
MAC addresses are 48bit (and not 64 bits), you need to pad them with
0xfffe to make them a 64-bit number.

Embedding MAC addresses in the IID is a bad idea.

I'm perfectly fine with folks randomizing MAC addresses if they want.
But that's not an excuse for embedding a MAC address in the IID.

>    Implementors of IPv6 stacks
>    are not necessarily able to control how link layer addresses get
>    generated, and therefore IPv6 implementations cannot rely on underlying
>    link layer addresses having any particular set of security or privacy
>    properties. Providing standardized recommendations for IPv6 IID generation
>    meant to achieve particular security and privacy properties therefore
>    requires that IPv6 IIDs not embed link-layer addresses.

Besides, as noted above, embedding MAC addresses already wastes 16-bits
of entropy.

>    As a result of the aforementioned issues, in cases where SLAAC is used to
>    generate a stable IPv6 address, this document changes the default
>    Interface Identifier generation scheme for SLAAC to that specified in
>    [RFC7217], and recommends against embedding link-layer addresses in IPv6
>    Interface Identifiers, such that the aforementioned issues are mitigated.

I'd pobably say "the traditional slaac..." rather than "in cases where
SLAAC is used to generate a stable IPv6 address". Otherwise, the text
seems to assume that there are cases where you don't do traditional
(stable) slaac, and that is not really the case: RFC4941 specifies
temporary addresses along stable addresses. So, unless we're planning to
update RFC4941, you always generate stable addresses. -- for instance, I
know of no platform that allows you to employ RFC4941-only.

>     In a variety of cases addresses that remain stable, either permanently or
>     for the duration of a host's connection to a single subnet,

I'd rephrase as:

  " In a variety of cases, addresses that remain stable within the
    same subnet..."

>      are viewed as
>     desirable. For example, stable addresses may be viewed as beneficial for
>     network management, event logging, enforcement of access control,
>     provision of quality of service, or for servers or routing interfaces.

s/servers or routing interfaces/server or router interfaces/

>     The recommendations in this document apply only in cases where
>     implementations otherwise would have configured a stable IPv6 IID
>     containing a link layer address.

I'd rephrase as:

    The recommendations in this document apply only to the generation
    of stable addresses with SLAAC, and is orthogonal to the temporary
    addresses specified in RFC4941.

(we also address cases where there might not really be a real hardware
address, but rather a similar identifier of sorts).

>     This document does not change any
>     existing recommendations concerning the use of "temporary addresses" as
>     specified in RFC4941. Temporary addresses are typically configured in
>     conjunction with stable addresses;

This is not incorrect, but RFC4941 actually specifies temporary
addresses to be used along stable addresses.

>     hosts that configure both a stable
>     address with a link layer address embedded and temporary addresses may
>     still be susceptible to the attacks discussed in [RFC7721].

This would seem to hint that there are cases where stable addresses are
not configured... but please see my note above regarding RFC4941.

>     The
>     recommendations in this document aim to provide mitigations in such
>     cases by improving the properties of the stable address. However in cases 
>     where temporary addresses can be supported in
>     isolation, without the need to configure a stable address, the
>     recommendations in this document do not apply.

I think this is saying more than there is to say. This document is about
stable addresses. As such, applies to stable addresses and not about
anything else. Doing RFC4941-only would require an update to such spec.
And even if we did such an update, that would be orthogonal to this doc.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 23 Mar 2016 22:02:37 +0100

On 03/22/2016 12:51 PM, Lorenzo Colitti wrote:
> On Tue, Mar 22, 2016 at 8:07 PM, Brian Haberman
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Agreed, my statement is true for most but not all devices, though even
> on Linux it should be feasible to implement MAC address randomization as
> long as you have the driver source code.
> 
> What concerns me the most is that platforms that are already
> implementing MAC address randomization, and that have strong privacy
> requirements, should not be forced to implement RFC 7217, which from a
> privacy perspective is inferior to EUI-64 with MAC address randomization.

That has nothing to do with this document. If that's your concern, then
you're calling for an update to RFC4941, such that you do both random
link-layer addresses and temporary addresses with no stable addresses.

However, I'd say that you can probably get away with what you want,
while doing RFC7217, even without doing RFC4941: use your randomized MAC
address as the Net_Iface parameter, and your address will change as
often as your MAC address. From the point of view of achiving a stable
address, I'd say you chose the wrong surce of Net_Iface ;-), but it'll
get what you want...

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Mar 2016 10:10:12 +1300

Hi Fernando,
On 24/03/2016 09:38, Fernando Gont wrote:

...
> But that's not an excuse for embedding a MAC address in the IID.

OK... OK... but we don't need to say any of that in the current draft.
(Of course there were good practical reasons at the time why XNS, Novell,
CLNP/DECnet Phase V and IPv6.0 embedded MAC addresses.) I think Alissa's
text is fine.

> Besides, as noted above, embedding MAC addresses already wastes 16-bits

It's worth a footnote.

> know of no platform that allows you to employ RFC4941-only.

That's true, but what information does "traditional" add? SLAAC is SLAAC and we
aren't changing it.

> anything else. Doing RFC4941-only would require an update to such spec.

Actually, not. An implementor could simply decide to do that. RFC 4941
doesn't say SLAAC must be used. It says that it does "not result in any
changes to the basic behavior of addresses generated via stateless address
autoconfiguration". If there are no such addresses, and no addresses
from DHCPv6, Alissa's text would apply.

Regards
     Brian

---

From: Christian Huitema <[email-masked]>
Date: Fri, 25 Mar 2016 01:10:14 +0000

> you're calling for an update to RFC4941, such that you do both random link-
> layer addresses and temporary addresses with no stable addresses.
> 
> However, I'd say that you can probably get away with what you want, while
> doing RFC7217, even without doing RFC4941: use your randomized MAC
> address as the Net_Iface parameter, and your address will change as often
> as your MAC address. From the point of view of achiving a stable address, I'd
> say you chose the wrong surce of Net_Iface ;-), but it'll get what you want...

I am reading this discussion just now. I think that the issue is with the requirements stated in section, or precisely with what is not stated there. The first requirement stated is about stability, "The resulting Interface Identifiers remain stable for each prefix used with SLAAC within each subnet for the same network interface." That requires that when a mobile node visits a particular subnet, it should obtain exactly the same IID. 

Well, the practice of MAC Address Randomization goes against that. When a user decides to randomize the MAC address used on a particular link, the user expects that during the next visit to the link, after randomization, the interface will obtain a different address. Failing that would allow tracking through IID, and negate the privacy value of the randomization.

As Lorenzo points out, the simple solution is to use the randomized MAC address as the Net_Iface parameter specified for RFC7217. As far as I can tell, at least one stack is doing exactly that today.

Note that this is unrelated to whether IT admins allow randomized addresses, or whether a specific hardware supports it. If randomization is forbidden or unavailable, of course it will not be used and the address will not change. And the users will be easy to track.

-- Christian Huitema

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 25 Mar 2016 12:32:34 -0700

> On Mar 24, 2016, at 6:10 PM, Christian Huitema <[email-masked]> wrote:
> 

Thinking this through, I think part of the difficulty with this kind of document is the gap between what is standardized and what is implemented. What we have today, from a standards perspective is:

(1) a bunch of specs that normatively specify embedding in an IID a MAC address as presently specified by IEEE 802 

(2) RFC 4941 which specifies a method for temporary address generation but indicates that such addresses can/should be generated alongside a MAC-based address

(3) RFC 7217 which specifies a method for generating a random address that stays stable per-subnet

Aside from what has been standardized, it sounds like what we also have are MAC addresses getting randomized more commonly, use of the method in 7217 to generate addresses that do not necessarily remain stable per subnet, and perhaps use of 4941 temporary addresses in isolation, without a stable address also configured.

If we want to replace (1) with something better from a security/privacy perspective, we have limited choices if we want to point to an existing standard. If we do not care about pointing to an existing standard, we could just list what the requirements are, and have all the specs that fall under (1) be updated to use some (unspecified) mechanisms that meet those requirements. Or we could first standardize mechanisms to cover all the cases that the requirements would cover, and then point to those mechanisms.

Personally I think requirements 2-4 in Sec. 3 of default-iids represent the minimum change that is worth updating all the specs that fall under (1). Adding a requirement or changing requirement 2 to speak to an address change per network connection/disconnection rather than per subnet would be reasonable if we decide to ditch requirement 1. From this discussion it sounds like adding a requirement against direct embedding of a link layer address in an IID may also be a good addition.

Alissa