Re: Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03

[Robert Sparks <[e-mail]>]

On 2/15/16 3:37 PM, Bernie Volz (volz) wrote:
> Perhaps we should get away from whether something is easy or difficult to implement or whether the algorithm may be more (or less) efficient.
>
> I think the point of this material is to ENCOURAGE random assignment rather than sequential to improve privacy- so keep it at that. Let implementers worry about how efficient an algorithm is?
Right - that's where I'm trying to get the document to go.
>
> - Bernie
>
> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]]
> Sent: Monday, February 15, 2016 4:15 PM
> To: Tomek Mrugalski <[e-mail]>; General Area Review Team <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
>
> Hi Tomek -
>
> Thanks for these edits. My points are all addressed, though I wish to push a little more on changing the focus of the following in the document:
>
> On 2/15/16 2:45 PM, Tomek Mrugalski wrote:
>
> <snip/>
>>> In section 4.3, the paragraph on Random allocation comments on the
>>> poor performance of a specific simplistic implementation of random
>>> selection. More efficient algorithms exist. But the discussion is
>>> mostly irrelevant to the document. Please simplify this paragraph to
>>> focus on the benefits of random allocation.
>> I somewhat disagree. First, there are more efficient algorithms known,
>> but they are not always used. This document is a analysis, so we tried
>> to provide an analysis of what's actually happening in actual
>> implementations. In an ideal world where privacy is the top priority
>> every implementation would use truly random allocation using hardware
>> entropy generators. Sadly, the reality of DHCP servers market is that
>> performance matters a lot. Lowered performance is a price for better
>> privacy. This fact directly affects DHCP server implementors, which
>> are the target audience for this document. These are my arguments why
>> the discussion about performance penalty is there and should stay in my opinion.
> Then I suggest this variation:
>
> "In deployed systems, address allocation strategies such as choosing the next sequentially available address are chosen over strategies such as pseudo-random allocation across the available address pool because the latter are more difficult to implement efficiently."
>
> To be very clear (and I do _not_ want to put this discussion in the document), an implementation could keep a structure (probably a
> linked-list) of blocks of unallocated addresses, and very efficiently select an address pseudo-randomly from the addresses in that structure, modifying the structure to make the next selection just as efficient (similarly modifying the structure when addresses are returned to the pool).
> This would not have the performance degradation that the simple strategy you currently discuss has.
> While they're entertaining, I think discussing _either_ way of approaching such a random selection algorithm distracts the reader from the point of understanding the privacy implications.
>>
> <snip/>
>
>
> RjS