Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

["Bernie Volz (volz)" <[e-mail]>]

There is already some text in draft-ietf-dhc-dhcpv6-privacy, section 4.3, on DHCP server allocation strategies, so it the question is whether that is sufficient or whether perhaps something is needed in the draft-huitema-dhc-anonymity-profile ... though I think that is more focused on the client. If there was existing text, the 3315bis document can refer to it in the Security/Privacy Considerations section. Note that I suspect that these privacy documents will be RFCs long before 3315bis will be.

I think your text is fine. And, it is recorded in the ticket on this issue, http://trac.tools.ietf.org/group/dhcpv6bis/ticket/145.

I also think your conclusion is fine :).

- Bernie

-----Original Message-----
From: Christian Huitema [mailto:[e-mail]] 
Sent: Wednesday, April 08, 2015 5:32 PM
To: Fernando Gont; Lorenzo Colitti
Cc: [e-mail]; Bernie Volz (volz); Ted Lemon
Subject: RE: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

To comment further on this discussion between Fernando and Lorenzo

> On 04/08/2015 09:45 AM, Lorenzo Colitti wrote:
> > On Wed, Apr 8, 2015 at 9:28 PM, Fernando Gont <[e-mail] 
> > <mailto:[e-mail]>> wrote:
> >
> >     ...
> >     The intent is that if you're going to use this scheme, for leasing
> >     addreses, you use this scheme for all prefixes: at the end of the day,
> >     if *one* of your addresses is predictable, that's enough for the
> >     attacker to track you or scan you.
> >
> >
> > No, it's not enough. The attacker can only track or scan you if you 
> > use a stupid algorithm to generate the IIDs. Yours is not stupid, 
> > but neither are many others such as "random". You can perfectly well 
> > use random assignment on some subnets and your algorithm on other subnets.

I think there is value in having some part of the DHCPv6 spec specify the "don't be stupid" logic. My personal preference would be to add the list of privacy attacks in the "security considerations" of DHCPv6bis. Something like:

Some address allocation schemes are known to be harmful, because they facilitate scanning, allow for information leakage, or fail to maintain the address stability required by many applications. In particular:
* Assigning addresses using some kind of sequential algorithm (prefix::1, prefix:2, prefix::3,...) greatly facilitate scanning of the network;
* Deriving the IID part of addresses from the link layer address of the client exposes information about the client hardware and enables tracking the client across multiple subnets;
* Using memory-less random allocation schemes fails to maintain enough stability for many applications; The algorithm presented in [RFC7217] provides a solution to this problem for nodes using IPv6 Stateless Address Autoconfiguration. Similar algorithms could be used by DHCPv6 servers to avoid the aforementioned issues.

If we added that to the main DHCPv6 spec, there would be no need for a separate RFC presenting a variant of the 7217 algorithm.

-- Christian Huitema