Re: [dhcwg] Comments on draft-ietf-dhc-anonymity-profile-02.txt

[Christian Huitema <[e-mail]>]

On Wednesday, August 26, 2015 7:36 PM, Bernie Volz wrote:
> 
> In preparation for a (hopefully soon) WGLC, I did a more thorough review of
> this document. Comments are "inline" below (BV>). While many of the
> findings are minor nits, there are a few more significant issues as well. Though
> nothing that shouldn't be difficult to correct. And, feel free to push back if you
> don't agree with some comments.

Thanks. I will fix the nits, and some of the issues. For the others, text below.

> Abstract
> 
>    Some DHCP options carry unique identifiers.  These identifiers can
>    enable device tracking even if the device administrator takes care of
>    randomizing other potential identifications like link-layer addresses
>    or IPv6 addresses.  The anonymity profile is designed for clients
> BV> Should it just be IP addresses? DHCPv4 can lease addresses too in the
> INIT-REBOOT phase.

This is not about leases, just the fact that MAC and IPv6 addresses can easily leak metadata if we are not careful, but even if we are careful with that we need to also be careful with DHCP.

>    that wish to remain anonymous to the visited network.  The profile
>    provides guidelines on the composition of DHCP or DHCPv6 requests,
>    designed to minimize disclosure of identifying information.  This
>    draft updates RFC4361.
> BV> We need to review whether this updates RFC4361 is correct. There is not
> explicit "change this to that" text so it isn't really an "updates" in the strict
> sense. It is just to change its use for privacy, but then this would also update
> RFC 2131 and 3315? So is it really appropriate?

You are probably right. We are not suggesting any specific update to 4361.
> 
> 2.5.  No anonymity profile identification
> ...
>    anonymity is a bit like walking around with a Guy Fawkes mask.  When
> BV> Show this have some kind of reference for the international audience or
> do you think it is globally clear?

I don't think that's really necessary, given the wide publicity around "Anonymous."

> 
> 2.7.  What about privacy for DHCP servers
> 
>    The server part will be covered by the general mitigation work going
>    on in DHCP working group, following the analyses presented in
>    [I-D.ietf-dhc-dhcp-privacy] and [I-D.ietf-dhc-dhcpv6-privacy].
> BV> Isn't this part of this work? Perhaps we say it is a topic for further
> work/study?
> 
> 3.  Anonymity profile for DHCPv4
> 
> ...
> BV> Also there is a general question (may impact 3.4) of why these clients
> even include a client-identifier option? It isn't required so perhaps one option
> is for them not to include it. That way, no value must be derived?

Maybe. I am a bit concerned with interop issues. Does anybody have a strong opinion?

> 3.1.  Client IP address field
> 
>    Four bytes in the header of the DHCP messages carry the "Client IP
>    address" (ciaddr) as defined in [RFC2131].  In DHCP, this field is
>    used by the clients to indicate the address that they used
>    previously, so that as much as possible the server can allocate them
>    the same address.
> 
> BV> I'm not sure what cases this is to cover - perhaps just normal
> DHCPREQUEST for renew, since for INIT-REBOOT, RFC 2131 has:
> 
> For RFC 2131:
> 
>    o DHCPREQUEST generated during INIT-REBOOT state:
> 
>       'server identifier' MUST NOT be filled in, 'requested IP address'
>       option MUST be filled in with client's notion of its previously
>       assigned address. 'ciaddr' MUST be zero. The client is seeking to
>       verify a previously allocated, cached configuration. Server SHOULD
>       send a DHCPNAK message to the client if the 'requested IP address'
>       is incorrect, or is on the wrong network.
> BV> END

Can we get a concurring advice here?

> ...
> 3.4.  Client Identifier Option
> ...
> BV> Also, see above as to why even send this at all?
> BV> Note that if a client is dual stack and doing DHCPv4 and DHCPv6, it may
> be best that the 4361 requirement to send is used as then it would be possible
> to correlate the client's V4 and V6 address. But that can also be a privacy risk?
> Should this be discussed?

Sounds reasonable. Any proposed text?

> BV> New section between 3.4 and 3.5 to include the PRL similar to ORO text in
> 3.5? Kind of odd that the Parameter Request List isn't mentioned at all for
> DHCPv4 where there exists a fairly extensive fingerprinting database (mostly
> based on the PRL).

Yes, we should consider that. 

> 4.  Anonymity profile for DHCPv6
> ...
 
> 4.2.  Client Identifier DHCPv6 Option
> ...
>    tracking and profiling.  Three DUID formats are specified: Link-layer
>    address plus time, Vendor-assigned unique ID based on Enterprise
>    Number, Link-layer address.
> BV> There is a 4th type, DUID-UUID defined in RFC 6355. Probably not a good
> idea to use this for privacy?

Will add a reference for completeness, but you are correct, it is not a good idea for privacy.

>    cases the link-layer address is based on MAC.  The first three octets
>    are composed of the OUI (Organizationally Unique Identifier) that is
>    expected to have a value assigned to a real organization.  See
>    [IEEE-OUI] for currently assigned values.  Using a value that is
>    unassigned may disclose the fact that a DUID is randomized.  Using a
>    value that belongs to a third party may have legal implications.
> BV> I don't understand what the value of these last sentences is? It mentions
> the OUI but so what should someone do? What about the other octets??

You are right, we can simplify the text.

> 4.4.1.  Obtain temporary addresses
> 
>    [RFC3315] defines a special container (IA_TA) for requesting
>    temporary addresses.  This is a good mechanism in principle, but
>    there are a number of issues associated with it.  First of all, this
>    is not widely used feature.  Thus clients cannot count on it to be
> BV> is not a widely used feature?
>    always available.  Secondly, [RFC3315] does not specify any renewal
>    mechanisms for temporary addresses.  Therefore the support for
> BV> Yes it does. See RFC 3315, page 76 2nd paragraph?

OK, will fix.

> 6.  Security Considerations
> BV> This is a bit light, but don't have any real recommendations - might
> reference RFC 2131 and 3315, but that might not help that much? I guess we'll
> see what the IESG or other reviewers say?

Yes...

> Finally, be sure to run id-nits!!!

Will do.
 
Thanks for the review.

-- Christian Huitema