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:rjsparks@xxxxxxxxxxx]
Sent: Monday, February 15, 2016 4:15 PM
To: Tomek Mrugalski <tomasz.mrugalski@xxxxxxxxx>; General Area Review Team <gen-art@xxxxxxxx>; ietf@xxxxxxxx; dhcwg@xxxxxxxx; draft-ietf-dhc-dhcpv6-privacy.all@xxxxxxxx
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