Re: [dhcwg] A few points about draft-huitema-dhc-anonymity-profile-01.txt

[Christian Huitema <[e-mail]>]

On Tuesday, March 24, at 2015 10:44 AM, Marcin Siodelski wrote:
> 
> IMHO, this draft well summarizes the privacy issues mitigation for
> DHCPv4 and DHCPv6. I have read this top to bottom and have had a couple
> of questions.
> 
> I assume that since this document updates the RFC4361 the intended
> status should be modified from "Informational" to "Standards Track"?

Yes. Sorry. Blame my poor practice of XML2RFC...

> Assuming that the answer to the above is "yes", I think that the use of
> word "guidelines" is inappropriate in a few places in the text. For
> example in the abstract:
> 
> "The profile provides guidelines on the composition of DHCP or DHCPv6
> requests, designed to minimize disclosure of identifying information."
> 
>  From the overall tone of the text, if a client chooses to be anonymous
> it must adhere to this doc rather than treat it as a guideline. No?

Maybe. Do you have suggestion for better text?

> In section "3. Anonymity Profile for DHCPv4" I'd suggest revising the
> use of MUST/SHOULD for specific options vs RF2131. For example: in most
> cases the Parameter Request List option is something that client MAY
> include, rather than MUST. I see no reason for this draft to mandate the
> use of PRL.

The issue there is "implementation profiling." It would be better if all implementations did about the same thing, so they be hard to recognize. 

> Isn't it to strong to say that client MUST use client identifier, as
> opposed to only use chaddr?

Again, that goes to implementation profiling. 

> Why is this mandated to use the Host Name?

It would be OK to just not send a name at all, but I am concerned with side effects. 

> For the DHCPREQUEST case the use of Requested IP address option is a
> MUST for certain client states. These cases should be explicitly listed
> here and the use of Requested IP address option should not be discouraged.

That is the case when the client already have an IP address provisioned on the same network, correct? I thought that was covered.

> In section: "4.3. Address assignment options" it is explicitly said that
> IA_NA or IA_TA can be used for obtaining addresses and there is no
> mention of IA_PD. The document should probably have a line or two about
> the applicability of this method to prefix delegation. Personally, I
> don't see many of the use cases here, but probably worth to clarify?

I did not consider this as a viable option. That would be an "anonymous mobile router."

> About section "5. Management considerations". I don't know how to apply
> this in practice:
> 
> "Implementers should be careful to only use the anonymity profile when
> privacy trumps management considerations."
> 
> The implementers may have very little knowledge about the particular
> environment where the DHCP client being implemented will be used. I also
> assume that it is more the configuration knob on a device which turns
> the anonymity on or off. So, I would not push this responsibility on the
> implementers. Unless, I misunderstood who the implementers are in this case.
> 
> Similarly, the following sentence:
> 
> "Servers dealing with clients using this profile who want to honour
> the client’s wishes, ought minimise logging because that may assist
> the client."
> 
> seems to advise the impossible, because the goal is that the server is
> NOT notified whether the clients are in the anonymity state or not. See
> section 2.5. Does it intend to say that certain DHCP deployments (e.g.
> public network at the airport) should assume that clients may use the
> anonymity profile and assist the clients?

Maybe I should just drop the entire section 5. Maybe...

Thanks for the detailed comments

-- Christian Huitema