[dhcwg] Review of the draft-ietf-dhc-anonymity-profile-01

[Marcin Siodelski <[e-mail]>]

Here are a few points about the version -01 of the draft.

3. Anonymity Profile for DHCPv4
The normative language for messages should be cleaned up. For example:
in some cases the "Message Type" MUST be included, in other cases it
SHOULD be included.

Also requiring a MUST for the Hostname option in DISCOVER goes against
the text elsewhere, which says that:

"DHCP clients SHOULD avoid sending the host name option"

On this last one. I suggest updating this wording to:

"DHCP client SHOULD NOT send the host name option" as the current text
sounds ambiguous.

3.2. Requested IP address option
There is the case of the INIT-REBOOT client's state when the client
remembers its previous address. Shouldn't the text explicitly discourage
sending the DHCPREQUEST in the INIT-REBOOT state, in favor of the 4-way
exchange to obtain a new address.

I presume that there may be some cases when the client reboots and
determines that it has been attached to the same network a previously,
in which case it may be fine to request the same address as previously.
But, when working in the "per-connection randomization mode", the reboot
should constitute randomization of the MAC address and thus 4-way
exchange. No?

3.5. Host Name Option and 3.6. Client FQDN option

"When obfuscating the host name, DHCP clients SHOULD construct a
 randomized host name by computing a secure hash of a local secret and
 of the link layer address that will be used in the underlying
 connection, and then use as the name the hexadecimal representation
 of the first 6 bytes of the hash.  This procedure ensures that the
 random name will not reveal the underlying link layer address."

Aren't you afraid that sending the fixed-length hostname is a pattern
that my disclose my desire for the privacy?

Perhaps if many clients do the same thing, the fact that they follow the
certain pattern doesn't harm because you can't distinguish them from
each other?

If so, it may matter if there are only a few privacy-concerned clients
which can be distinguished from the crowd.

Maybe some considerations of this kind should be included in this
section? And this is not necessarily to say that the proposed algorithm
is wrong.

4.4.1. Obtain temporary addresses
I am not certain that I understand how the randomization of IAID and
obtaining new address helps improving the privacy of the client in the
context of this draft.

The scenario described assumes that the client having an address
requests another address, using the randomized IAID. If the client holds
the same DUID and hasn't randomized its "MAC" address at this point, the
two addresses can be easily correlated. If the client continues, and
sends the Release message it only confirms that this particular client
has replaced its address.

Perhaps, I miss the context of this section.

5. Operational Considerations

"Implementers should be careful to only use the anonymity profile when
privacy trumps management considerations."

How does the implementor know when the privacy trumps the management
considerations? I presume that "privacy mode" is rather an option in the
device which is under user's control. Implementors simply provide means
to enable or disable privacy on the device.

Marcin