Re: [dhcwg] Two approaches to DHCP privacy

Hi, Christian

Many thanks for pointing out the differences. Something that I want to make
it clear is that the "dhcpv6-sa" design does not include encryption as a
mandatory solution. The general idea is to build a trusted relationship
between client and server before standard DHCPv6 process. If they agree to
use encryption in the following communications, they could do. In the
current version, we mentioned encryption as an optional further solution
since we are not sure whether the WG has a requirement to add
confidentiality to the DHCPv6 transactions. If the requirement exists, we
could propose another document to define the encryption pattern. Thus, more
precisely, the current "dhcpv6-sa" addresses the scenario when the client
desires to find a trusted server.

As for your "anonymity" design, I read it briefly and will make a thorough
review later. I think minimizing data is always the best way. Here's one
question, do you think it is better to separate DHCPv4 part and DHCPv6 part?

Best Regards,
Linhui

2015-03-11 5:22 GMT+08:00 Christian Huitema <huitema@microsoft.com>:

> We know have two drafts addressing DHCP privacy:
> http://www.ietf.org/internet-drafts/draft-yiu-dhc-dhcpv6-sa-00.txt and
> http://www.ietf.org/internet-drafts/draft-huitema-dhc-anonymity-profile-01.txt
> .
>
> Just in case there is confusion, I want to point out that these two drafts
> are addressing different scenarios.
>
> The "dhcpv6-sa" draft proposes establishing a secure association between
> client and DHCPv6 server; use of encryption prevents leakage of information
> to third parties, and thus mitigates the corresponding privacy issues. Of
> course, the secure association provides full access to the information to
> both client and server. The secure association solution addresses the
> scenario when the client trusts the server.
>
> My "anonymity" draft addresses a different scenario, when the client is
> visiting an untrusted network and does not want to provide identifying data
> to anyone on that network, including to the server. The solution there is
> to "randomize" most of the data provided to the server, so it could not be
> used to track the client.
>
> Two different scenarios, two solutions.
>
> -- Christian Huitema
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>