Subject: [dhcwg] IETF-93 Follow Up - draft-ietf-dhc-stable-privacy-addresses (Respond by Aug 11, 2015)

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 29 Jul 2015 17:25:42 +0000

Hi:

At the DHC WG session at IETF-93 (Prague), we had a discussion about next steps for draft-ietf-dhc-stable-privacy-addresses. In particular, I (Bernie Volz) proposed we consider it a "dead WG" document (or possibly continue it as Informational). The consensus (hum) in the room was as follows:

-          Most felt (loudest hum) we should consider it a "dead WG" document.

-          A few (minor hum) were in favor of continuing work on it as an Information draft.

-          None (silent) were in favor of continuing work as is (standards track).
I had also asked this question to the mailing list a while back, and there was some discussion though no conclusive action as only a few people voiced an opinion.

While we don't yet have official minutes for the meeting, you can view the Etherpad notes and audio track by visiting https://tools.ietf.org/agenda/93/ and scrolling down to the DHC session (on Thursday afternoon) and clicking the appropriate links.

The WG chairs are required to confirm any consensus obtained from a session on the WG mailing list and that is the purpose of this email.

Thus, if you do NOT agree with the intended action to mark the document as "dead", please indicate so and specify why you feel this document is needed and whether to continue as Standards Track or Informational. Please respond on or before August 11th, 2015.

Thanks!

-          Bernie (& Tomek)

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 29 Jul 2015 19:45:11 +0200

On 29/07/15 19:25, Bernie Volz (volz) wrote:
> At the DHC WG session at IETF-93 (Prague), we had a discussion about
> next steps for draft-ietf-dhc-stable-privacy-addresses. In particular, I
> (Bernie Volz) proposed we consider it a “dead WG” document (or possibly
> continue it as Informational). The consensus (hum) in the room was as
> follows:
> 
> - Most felt (loudest hum) we should consider it a “dead WG” document.
> 
As a co-chair I confirm that it was my perception as well. The hum
indicated that people in the room strongly favored marking the doc as
dead WG document.

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.

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

Tomek

---

From: Fernando Gont <[email-masked]>
Date: Fri, 31 Jul 2015 15:34:48 +0200

Tomek,

> suggested that the algorithm specified is the only right way to do it.

Could you please point what's the offending text? -- i.e., the text that
claims that this is the only way to generate IIDs with DHCPv6?

> well.

It all depends on what you mean by privacy. Here were *aiming* to allow
to activity correlation within the same network. It's a goal, not a
flaw. If what bothers you is the use of "privacy" in the title, please
say so.

> The general consensus seems be that changing MAC addresses and all

Has anyone really assessed everything that could go wrong with
randomized MAC addresses?  -- THink of SAVI and other first-hop-secuity
mechanisms, issues with the ND cache, etc.

IMO, while probably desirable, I'd flag MAC address randomization as
"experimental" rather than "the way to go".

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 31 Jul 2015 16:02:33 +0200

Folks,

On 07/29/2015 07:25 PM, Bernie Volz (volz) wrote:
> 
> The WG chairs are required to confirm any consensus obtained from a
> session on the WG mailing list and that is the purpose of this email.
> 
> Thus, if you do NOT agree with the intended action to mark the document
> as “dead”, please indicate so and specify why you feel this document is
> needed and whether to continue as Standards Track or Informational.
> Please respond on or before August 11^th , 2015.

I must say, as I previously noted off-list, that I'm kind of puzzled
regarding they way we are proceeding with this document.

My concern is that rather than trying to get more folks to review and
collaborate, the first option seems to have been to try to drop the
document.

FWIW, this document became a wg item a while ago. Then eventually:

* Lorenzo raised concerns about technical aspects of the document (which
were addressed and/or clarified)

* A few folks noted their skepticism regarding the value of this
document. I've noted a few times that the value is:

    1) It is a calculated technique for DHCPv6 failover (as pointed
       in RFC7031, but never specified elsewhere).

    2) Also useful in the case of CPEs that cannot maintain a lease
       database.

    3) At the same time, it specifies an algorithm for randomizing
       the IIDs.

       Steps 2-5 in Section 4 of draft-ietf-dhc-stable-privacy-
       addresses need to be performed no matter what the source of
       the random IID is (whether the hash that we employ in our
       document, or simply "random()").

       I wouldn't be surprised at all if implementations fail to
       perform some or all of steps 2-5 above if we simply provide a
       vague "just set the IID to a random value if you want to avoid
       privacy issues".

And I haven't seen anyone contending these points (other than making
rather vague comments regarding the value that this document may bring).

* My understanding before the meeting was that the main concern was that
there wasn't many people involved in discussing/progressing the I-D. So
I'd have rather seen a call for participation than a call for dropping
the I-D.

* Besides, having this document been adopted as a wg item last year, I'd
say that the onus of providing reasons regarding what to do with this
document should be on the folks arguing to drop it, rather than on folks
that may want to keep this document alive.

Thanks,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 31 Jul 2015 14:28:32 +0000

WG: Please respond to the question at hand - if you do not indicate YOUR support for this work continuing, we will be forced to drop this as a WG work item.

Fernando:

We obviously assume that the authors are in favor of advancing your work.

But we haven't yet seen sufficient support for continuing this work. And unless we do, there's little point in doing so as it obviously does not have WG consensus to move forward.

Actually, my proposal to drop this work was to assure that if people felt it was important, they WOULD respond. Just asking a vague "do you support this work" tends to get little response.

Anyway, we will wait until the follow up period expires and make a decision then based on the feedback from the IETF-93 meeting and comments on the mailing list.

If there isn't sufficient support in the WG, we will mark the document as a "dead" WG document; and you can always continue the work as an individual submission to the IETF.

- Bernie

---

From: 神明達哉 <[email-masked]>
Date: Fri, 31 Jul 2015 08:12:17 -0700

At Fri, 31 Jul 2015 16:02:33 +0200,

>     3) At the same time, it specifies an algorithm for randomizing
[...]
> rather vague comments regarding the value that this document may bring).

FWIW, I provided a feedback on a previous call regarding the next
step of this draft several months ago:
https://mailarchive.ietf.org/arch/msg/dhcwg/PfFh1IsHvWa_0sEZsBpvrs6Qnjs

In short, I did see some value in the proposal, but didn't see it very
strong.  So I had no problem with dropping it while I wouldn't be
opposed to it publishing either if others wanted so.  As far as I
notice there's been nothing that can change my position.  That's why
I didn't explicitly respond to the call this time.

> that may want to keep this document alive.

Personally, I don't buy this argument as a general procedural matter.
If a wg adoption meant such a strong obligation for wg members I'd
rather raise the bar for the adoption in the first place.  My general
understanding is that it's actually author's (or other supporters, if
any) responsibility to keep the wg interested; if the author fails in
it, the wg is always free to drop the proposal (and IMO that's a good
balance to not raise the bar for adoption too high).

--
JINMEI, Tatuya

---

From: Christian Huitema <[email-masked]>
Date: Fri, 31 Jul 2015 19:34:06 +0000

On Friday, July 31, 2015 6:35 AM, Fernando Gont wrote:
> ...
> It all depends on what you mean by privacy. Here were *aiming* to allow to
> activity correlation within the same network. It's a goal, not a flaw. If what
> bothers you is the use of "privacy" in the title, please say so.

By definition, stable addresses allow for tracking over time, which is the antinomy of privacy.

> > 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.
> 
> Has anyone really assessed everything that could go wrong with randomized
> MAC addresses?  -- THink of SAVI and other first-hop-secuity mechanisms, issues
> with the ND cache, etc.

There are certainly environments where administrators will require users to give up privacy so the network can be controlled more efficiently. But it is very obvious that if you want privacy, you do not want to use stable identifiers.

That's particularly true for the identifiers used at the MAC layer of wireless networks. They can be monitored by just listening to the airwaves. Keeping them constant implies "stable tracking." But it is also true for identifiers embedded in IPv6 addresses.

-- Christian Huitema