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

[Christian Huitema <[e-mail]>]

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