Subject: [Dhcpv6bis] [dhcpv6bis] #145 (XML 3315): Add privacy considerations?

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 01 Apr 2015 20:35:55 -0000

#145: Add privacy considerations?

 We should consider adding a privacy considerations section. Perhaps this
 should just reference the draft-ietf-dhc-dhcpv6-privacy and draft-huitema-
 dhc-anonymity-profile (or their successor) documents.

-- 
----------------------------+----------------------------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task            |     Status:  new
 Priority:  P1 blocker      |  Milestone:  C awaiting consensus
Component:  XML 3315        |   Keywords:
 Due Date:                  |
----------------------------+----------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/145>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 08 Apr 2015 21:40:39 -0000

Comment (by [email-masked]):

 Christian Huitema (on 4/8/2015) wrote:

 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.

-- 
----------------------------+-----------------------------------
 Reporter:  [email-masked]  |       Owner:
     Type:  task            |      Status:  new
 Priority:  P1 blocker      |   Milestone:  C awaiting consensus
Component:  XML 3315        |  Resolution:
 Keywords:                  |    Due Date:
----------------------------+-----------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/145#comment:1>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>