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

From: Marcin Siodelski <[email-masked]>
Date: Tue, 24 Mar 2015 10:43:55 -0500

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

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?

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.

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

Why is this mandated to use the Host Name?

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.

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?

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?

Marcin

---

From: Christian Huitema <[email-masked]>
Date: Tue, 24 Mar 2015 16:01:34 +0000

> status should be modified from "Informational" to "Standards Track"?

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

> it must adhere to this doc rather than treat it as a guideline. No?

Maybe. Do you have suggestion for better text?

> include, rather than MUST. I see no reason for this draft to mandate the

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

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

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

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

> anonymity profile and assist the clients?

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

Thanks for the detailed comments

-- Christian Huitema

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 24 Mar 2015 15:46:24 -0500

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

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

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.

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

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

Marcin