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

[Fernando Gont <[e-mail]>]

Tomek,

On 08/03/2015 10:36 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.

It is not meant to do that. It is meant to say "if you're enabling
employing this technique, you must use it for all your DHCPv6 IIDs".

As you may see, if anything, there's room for improvement and tightening
up the text.. but I don't see why this should result in "let's knock
down this I-D" if it doesn't look perfect.



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

This is my comment: "I believe MAC address randomization is extremely
likely to break all sorts of first security techniques."



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

I repeat: Hsa anyone really thoroughly accessed whether this is going to
break FHS techniques currently employed?



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

THat's exactly the point. The technial comments I've seen so far from
LOrenzo are simply bogus. The part that you don't like from the I-D
simply needs to be clarified. And so far, this have been so far the
reasons to say "let's drop this"....


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

Yes, I'm aware of this 8I've participated in the IETF process for 10+
years). But what I see in this case is that some folks (e.g. Lorenzo)
are arguing to drp this without concrete ans sensible technical reasons.

I've elaborated on teh value, and on the issues raised by LOrenzo.
However, it seems that "the default is to drop", because of a hum taking
at the dhc meeting, when no ne uming really make a strong technical
point against this document. Thus, such action does not seem sensible to me.

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