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

[Fernando Gont <[e-mail]>]

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:


On 09/03/2015 04:06 PM, Tomek Mrugalski wrote:
> 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.

FWIW, I have responded to each of the claims you listed below:

> 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

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.



> 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

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.



> 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

Same as above.



> 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

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492