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

Fernando Gont <> Fri, 04 September 2015 00:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DF75D1B40C1 for <>; Thu, 3 Sep 2015 17:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wV-JMlZJSGwW for <>; Thu, 3 Sep 2015 17:50:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D79A51B40B0 for <>; Thu, 3 Sep 2015 17:50:06 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <>) id 1ZXfBa-0007QM-JR; Fri, 04 Sep 2015 02:48:59 +0200
From: Fernando Gont <>
To: Tomek Mrugalski <>, dhcwg <>
References: <> <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 03 Sep 2015 21:43:32 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dhcwg] draft-ietf-dhc-stable-privacy-addresses discussion summary
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Sep 2015 00:50:12 -0000

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:

My response is here:

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:

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:

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:

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


Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492