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

[Tomek Mrugalski <[e-mail]>]

On 31/07/15 15:34, Fernando Gont wrote:
> Tomek,
> 
> On 07/29/2015 07:45 PM, Tomek Mrugalski wrote:
>>
>> 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.
> 
> 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?
I think that's the same text Erik mentioned in Prague at the mic.

Section 4, first paragraph:

   DHCPv6 server implementations conforming to this specification MUST
   generate non-temporary IPv6 addresses using the algorithm specified
   in this section.

Here's specific example. The implementation I'm working on has the
capability to support multiple allocation strategies: iterative, random
etc. Your proposal can be another one considered. The text above says
that if I implement your proposal, I must also drop support for all
other allocation strategies.

>> 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.
> 
> 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.
Authors of the dhcp privacy and anonymity profile drafts received
several comments, but they always could use more. By all means, if you
have anything to add, please comment on them.

> IMO, while probably desirable, I'd flag MAC address randomization as
> "experimental" rather than "the way to go".
Ok, maybe that was a bit inpricise statement. Let me rephrase. It seems
that at this time there's rough consensus that MAC based randomization
is the preferred solution for the privacy concerns raised in RFC7258,
draft-ietf-dhc-dhcp{v6}-privacy and other places.

Keep in mind that WG consensus is not something set in stone. People
change their minds over time. More analysis and better understanding of
a problem is available over time. New solutions are being proposed.
These all influence people decisions. Work that used to be appealing may
lose its appeal over time. Successful adoption call answers the question
whether a WG is willing to work on something, not a promise to publish
the draft no matter what. Drafts can be abandoned at any stage. It may
be disappointing when it happens, but it happens nevertheless.

Tomek