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

[Marcin Siodelski <[e-mail]>]

The previous email went out of the control for some reason. So, I resend 
it with the more complete answers. :-)

On 2015-03-24 11:32, Marcin Siodelski wrote:
>
>
> On 2015-03-24 11:01, Christian Huitema wrote:
>> 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?
>>
>
> Perhaps something like this.
>
> "This document describes the behavior of the DHCP clients configured to
> avoid the breach of their privacy by minimizing the amount of sensitive
> information sent to the DHCP servers."
>
> Not sure it is perfect though. But, it avoids making the impression that
> everything in here is optional.
>
>>> 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.
>>
>
> For the specific case of Parameter Request List... what about the case
> if the client is not interested in any options be returned? The minimum
> length of this option is 1 which means that the client includes it

I meant that client includes it if it desires at least one option.

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


Are we actually thinking that the clients using the techniques defined 
in the draft will be interested in the DNS updates?

If the answer is maybe, maybe that could be optional whether the client 
does it or not?.

I am also afraid that if the clients are going to derive the hostnames 
from the HW addresses we better define a common way for doing it. 
Otherwise, if different implementations use different encoding for the 
hostnames derived from HW addresses it may make it easy to identify what 
DHCP client implementation they are.

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

One the client sends the DHCPDISCOVER and it is offered an address, it 
puts the Requested IP Address option to ask for the offered address with 
the DHCPREQUEST.

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

I am not advocating to use the privacy techniques in conjunction with 
prefix delegation. What I am saying is that the applicability of the 
techniques described in the draft should be clear. For example: this 
draft is not applicable for prefix delegation (and why) or there is 
nothing to preclude the use of this with prefix delegation but currently 
we don't see use cases. Or something like that.

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

Marcin