Subject: [dhcwg] draft-ietf-dhc-stable-privacy-addresses discussion summary

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 3 Sep 2015 21:06:31 +0200

During DHC meeting in Prague, we had a discussion about the next steps
for draft-ietf-dhc-stable-privacy-addresses. This discussion was brought
up, because new opinions were voiced questioning the value of this work,
in particular in the light of other developments in the privacy area. A
number of possible ways forward - continue as is (std), continue as
informational, drop the work - was discussed. The consensus in the room
was to drop the work. A follow-up discussion on the mailing list
unfolded. It's now a high time to wrap up this topic, so here it goes.
After much deliberation, DHC chairs, after consulting with the
responsible AD, determined that there was a strong consensus to stop
working on draft-ietf-dhc-stable-privacy-addresses.

This is one of the toughest decisions we had to make, so I think
explaining the reasoning that led us to that decision is in order. We
feel that this solution is strongly supported by a very small number of
very active people, but the large majority of participants is against
it. There were number of arguments raised, and we'd like to summarize
the most important ones. Links to the specific discussions are included.

1. By definition, stable addresses allow for tracking over time, which
is the antinomy of privacy. This is the biggest, fundamental objection
that cannot be solved with any amount of edits. Details:
https://mailarchive.ietf.org/arch/msg/dhcwg/4zYHTadYZDJj97KIC83yS1u6O_0

2. It was claimed that "it offers a useful way to implement DHCPv6
Failover using a calculated technique rather than state-sharing". This
argument is not valid, because of possible Declines. Details:
https://mailarchive.ietf.org/arch/msg/dhcwg/wfpCAY_yZ_AdVbLnzKUIbU-MkbI

3. An issue was raised that the proposal implicitly assumes that
Declines will never happen. Addressing this would require updating
"stable" to "probabilistically stable". Details:
https://mailarchive.ietf.org/arch/msg/dhcwg/T800BcOIagprjjfxVLuLUSh8iUA

4. Given the recent focus on privacy in IETF, publishing this draft
would send a confusing message to implementors, especially in the
context of anonymity-profile work and related drafts that recommend
different approach to solving privacy issues. Details:
https://mailarchive.ietf.org/arch/msg/dhcwg/U1T77_xagStBpFoMyQJ3CJb2BhU

Several other smaller issues were raised, but they were not factored
into the assessment of the WG's willingness to continue the work.

The document will be marked dead and WG time will not be spent on it.
There are several other efforts aimed at improving privacy within DHCP
and we encourage WG participants to actively contribute to those drafts.
If you have questions about this decision, please contact the chairs or
the shepherding AD off-list.

Because of the increased concerns for privacy, we will look at the
3315bis work (draft-ietf-dhc-rfc3315bis) to see what we might want to
add about guidelines for server implementers in terms of address
generation techniques to assure privacy. We already have a ticket
related to privacy issues,
http://trac.tools.ietf.org/group/dhcpv6bis/ticket/145.

Bernie & Tomek
DHC co-chairs

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Sep 2015 21:43:32 -0300

Hi, Tomek,

I understand that a decision was made. That said, I have (for the
records) two main concerns, which can be summarized as follows:

* While I understand that there were more hums in favor of dropping the
I-D than in favor of keeping it, I would expect that a decision is
accompanied with a rationale. Particularly for folks that may be
participating remotely, it would be kind of curious to take a decision
one way or another without a proper rationale (please see below). I
guess "lack of participation" could have been one reason -- but the
reasons you cited seem to be technical objections on the I-D.

* I have responded to the technical issues that were raised on-list. And
I personally think that my responses clarify why those "issues"
shouldn't be considered as flaws in this I-D. So I wonder whether you
considered that my responses were just wrong (and hence the issues are
real), or whether my responses were not considered during the analysis
(or something else) -- please see below:

> https://mailarchive.ietf.org/arch/msg/dhcwg/4zYHTadYZDJj97KIC83yS1u6O_0

My response is here:
<https://mailarchive.ietf.org/arch/msg/dhcwg/5o2w-njCCxFJp1Omkiaal7KFRSw>

Short version of the answer: All addresses allow some degree of
tracking over time, because, for obvious reasons, you need some level of
stability for addresses being of any use.

For instance, the so called "temporary addresses" (RFC4941) allow for
tracking during the lifetime of such addresses (typically 1 day, IIRC).

And, if you plan to randomize the mac address on "network connect
events", then if your devices is connected for, say, one week, you'd
still not be randomizing your address often enough. And if you did
(e.g., randomize your mac address once per sec), your system would not
be usable at all.

> https://mailarchive.ietf.org/arch/msg/dhcwg/wfpCAY_yZ_AdVbLnzKUIbU-MkbI

The same argument applies even if you have a protocol for synchronizing
address leases.

How would you achieve address stability if the client always DECLINEs?

With this line of reasoning, failover is not possible, because you
always need some level of cooperation on the client side.

> https://mailarchive.ietf.org/arch/msg/dhcwg/T800BcOIagprjjfxVLuLUSh8iUA

Same as above.

This reference is misleading. Namely, the URL you cite claims:

> With my co-chair hat off, I think this draft could have been useful
> couple years ago. It defines an allocation strategy that could be
> beneficial in certain cases. Some modern DHCP servers allow multiple
> allocation strategies and this could have been one of them. The text
> suggested that the algorithm specified is the only right way to do it.
> It is not.

It doesn't claim that. And we discussed this already. The intent of this
I-D is that, if you enable it, you should employ it for all your
addresses. That's it. I don't see why that means that's the only
possible way to do things.

And then goes on to say:

> But my strongest objection to it is that privacy and stable do not mix
> well. The general consensus seems be that changing MAC addresses and all
> associated identifiers over time is the way to go. That's what the
> anonymity profile and other associated work in other WGs is proposing.

Before anyone can make such assertion, you need to analyze how
randomizing MAC addresses might break first hop security mitigations --
because for a number of FHS technniques, mac address randomization would
be flagged as an attack by them (and you'll probably end up in a DoS
scenario). -- I have raised this one a few times, already.

There are other aspects to assess, e.g., the impact of mac address
randomization on the neighbor cache, etc.

There could also be devices in which, for different reasons, MAC address
randomization is just not possible.

Finally, it says:

> Had we published this draft, it would be confusing for vendors what the
> recommendation for privacy is: randomize MAC addresses or go with stable
> privacy addresses. Based on that I'm in favor of dropping this work.

All the above said, for an enterprise scenario you don't want MAC
address randomization. -- but that doesn't mean that you want
predictable addressess... in which case
draft-ietf-dhc-stable-privacy-addresses is still a useful approach. --
i.e., there's no "one size fits all".

Thanks!

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