Re: [dhcwg] Alissa Cooper's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)

[Christian Huitema <[e-mail]>]

On Wednesday, February 17, 2016 1:02 PM, Alissa Cooper wrote:
> ...
> 
> This document seems to use the term "link-layer address randomization" to
> describe the situation where a link-layer address is randomly generated AND
> changes over time. While this seems the likely way that such addresses may
> be standardized in the future, it's not guaranteed. An address could be
> randomly generated (or otherwise semantically opaque, e.g. not containing
> an OUI) but permanent for the life of the device/interface, in which case the
> privacy benefits of what is specified in this draft are not the same. Therefore
> I think it's worth explicitly stating the interpretation of "random address" that
> is being used here.

Would you add something to section 2.1, MAC address Randomization hypotheses?

> = Section 1 =
> 
> s/Reports surfaced recently/There have been reports/

OK.

> = Section 2 =
> 
> Would be good to update the references to work going on in IEEE 802.1.
> Also there were experiments at multiple IEEE and IETF meetings.

Yes, will add a reference to the IEEE work.

> = Section 3 =
> 
> Section 3.1 says:
> 
> "The client willing to protect its privacy SHOULD limit the subset of
>    options sent in messages to the subset listed in the following
>    sections."
> 
> Then all the subsections discuss specific options and considerations for using
> them, except 3.9, which basically says "don't use these." I would assume
> there are a bunch of other options that clients definitely shouldn't use if they
> want to maintain anonymity (I was thinking of 123 and 144, geolocation). So
> why are only the PXE options mentioned here, when the text in 3.1 seemed
> to be saying that clients should avoid all other options not mentioned?

The real requirement is "do not advertise unique identifiers or previously assigned parameters." We scrutinized the options that did that, and PXE is one of them. And we limit the list of options and values that can be inserted in client messages. But we do not limit the number of options that can be requested by the clients.

The draft does not preclude adding request codes in the Parameter Request List. RFC 6225 says "DHCPv4 clients request the DHCPv4 server to send GeoConf Option 123, GeoLoc Option 144, or both via inclusion of the Parameter Request List option." That's fine. The client is not disclosing anything, except its willingness to read the information provided by the server. 

The main issue is that the geoloc option values can be sent back by the server in clear text, and thus monitored. Monitoring just the local link will reveal the location of the local link, which is not that big a deal. Monitoring happens between a proxy and a centralized server is of course more "interesting." But the anonymity profile provides a mitigation against both: sure, the monitor can read the geoloc information; but since the device is anonymous, the monitor does not know who travelled at that location.

-- Christian Huitema