Subject: [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03

From: Robert Sparks <[email-masked]>
Date: Tue, 2 Feb 2016 10:38:59 -0600

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dhc-dhcpv6-privacy-03
Reviewer: Robert Sparks
Review Date: 2Feb2015
IETF LC End Date:4Feb2015
IESG Telechat date: Not yet scheduled

Summary: Ready with nits that should be addressed before publication

The reference to ietf-6man-ivp6-address-generation-privacy should be 
normative, and when this document is pointing to it because it is 
discussing a field carrying a generated address, it should be more 
explicit about why it's making the reference.

In section 4.3 the paragraph on Hash allocation should note that even a 
well implemented hash does not mitigate the threat of correlation over time.

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.

Should section 5.3 also call out mapping IP addresses into geolocation?

Why doesn't section 5.5 also talk about things like MAC addresses?

Section 5.6 could probably borrow words from RFC7258 - it should at 
least reference it (currently there is only a reference from the 
introduction.)

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 15 Feb 2016 21:45:44 +0100

On 02.02.2016 17:38, Robert Sparks wrote:
> Document: draft-ietf-dhc-dhcpv6-privacy-03 Reviewer: Robert Sparks 
> Review Date: 2Feb2015 IETF LC End Date:4Feb2015 IESG Telechat date:
> Not yet scheduled
> 
Thanks for your thorough review. I did my best to address your comments.
The soon to be published -04 is available here:

https://github.com/dhcwg/privacy/blob/master/draft-ietf-dhc-dhcpv6-privacy-04.txt

You can see the diff here:
https://github.com/dhcwg/privacy/commit/11d08e981fc503d11f31938af05316b7e881bfd6
(scroll down to draft-ietf-dhc-dhcpv6-privacy.xml to see the actual
changes).

> explicit about why it's making the reference.
It is normative now. Every reference to this I-D mentions specific
section (See Section 3.2 of ...) and explains that the reference was
made to point to an extended description of each type of attacks. If
this is not sufficient, can you point to specific section or text that
requires further improvement?

> In section 4.3 the paragraph on Hash allocation should note that even
> a well implemented hash does not mitigate the threat of correlation
> over time.
Added. Also added an explanation about the performance. See my response
below why I think it's appropriate.

> 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.

But I think I see your point. The performance aspect was raised only in
random allocation, so it may be mis-interpreted as a way to discredit
random strategy. It is not. I added similar discussion to hash
allocation and added a bit of clarification text. Hopefully it is not
biased in any direction.

BTW This strategy is called random, but the text now explains that it's
really pseudo-random. I can envision a way to hook a hardware random
number generator to a device running DHCP server, but I never heard
about such a solution. Therefore I think pseudo-random is the right word
to use here.

Please let me know if the updated text is satisfactory for you. If not,
I'd love to know which part requires further work.

> Should section 5.3 also call out mapping IP addresses into
Added a paragraph. I'm not a geolocation expert by any stretch of
imagination, so please correct me if I got it wrong. In general, any
global address assigned by DHCP (or SLAAC for that matter) is
susceptible to the geolocation procedures and the text now clearly
mentions that.

> Why doesn't section 5.5 also talk about things like MAC addresses?
Because there are no MAC addresses in DHCPv6, at least not in the
general case. This is a common surprise, so I added a clarification text
that tries explains it, without going into too much details (it's a
broad topic). Please let me know if the text is sufficient or you want
me work on it further.

> least reference it (currently there is only a reference from the 
Good point. It now borrows heavily and references RFC7258.

Also updated one out of date reference.

Thanks a lot for your review and comments.

Tomek

---

From: Robert Sparks <[email-masked]>
Date: Mon, 15 Feb 2016 15:15:18 -0600

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/>
> 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 15 Feb 2016 21:37:01 +0000

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?

- Bernie

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Monday, February 15, 2016 4:15 PM
To: Tomek Mrugalski <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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:

<snip/>
> 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.

"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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 15 Feb 2016 16:10:19 -0600

> 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.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Feb 2016 06:39:12 -0300

Bernie,

On 02/15/2016 06: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?

There are a number of operational and security/privacy considerations
that depend on the actual algorithm that you employ.

I'm not sure what you mean by "random". IID=random() everytime an
address has to be leased? -- or do you really mean "unpredictable"?.

At the end of the day, what you want is to specify desired properties.

Besides, assignment of sequential addresses should be banned. They have
always been a bad idea (see
<https://tools.ietf.org/html/draft-gont-predictable-protocol-ids>) and
they shouldn't even be considered an option.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 16 Feb 2016 16:35:33 +0100

On 15.02.2016 23:10, Robert Sparks 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.
>>

This document doesn't encourage anything. It's an analysis and that is
clearly stated in the abstract. Anyway, it seems that people prefer the
performance text to disappear, so it's now gone.

In fact, this topic may be a material for another draft altogether.
Those two drafts (dhcp-privacy and dhcpv6-privacy) analysed the
situation mostly from the client perspective and dhc-anonymity-profile
attempts to address the issues raised on the client side. The whole
paragraph about allocation strategy is just an attempt to cover aspects
that, while implemented on the server side, still affect the client. I
suppose we could consider a draft that would provide similar
recommendations for privacy conscious DHCP server. It's not immediately
clear whether there's enough topics for a separate draft, but this
remains to be seen.

Anyway, I just uploaded -04 that hopefully is acceptable. It does not
contain the performance discussion. The direct link is:
https://www.ietf.org/id/draft-ietf-dhc-dhcpv6-privacy-04.txt

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 16 Feb 2016 16:41:42 +0000

Technically unpredictable is probably a better term, but random implies that. I'll leave it to the authors to determine the best language. (I'm ok with what the 04 draft now says.)

- Bernie

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Tuesday, February 16, 2016 4:39 AM
To: Bernie Volz (volz) <[email-masked]>; Robert Sparks <[email-masked]>; Tomek Mrugalski <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03

Bernie,

> implementers worry about how efficient an algorithm is?

There are a number of operational and security/privacy considerations that depend on the actual algorithm that you employ.

I'm not sure what you mean by "random". IID=random() everytime an address has to be leased? -- or do you really mean "unpredictable"?.

Besides, assignment of sequential addresses should be banned. They have always been a bad idea (see
<https://tools.ietf.org/html/draft-gont-predictable-protocol-ids>) and they shouldn't even be considered an option.

Thanks,

---

From: Robert Sparks <[email-masked]>
Date: Tue, 16 Feb 2016 14:47:53 -0600

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-dhc-dhcpv6-privacy-04
Reviewer: Robert Sparks
Review Date: 16Feb2015
IETF LC End Date: past
IESG Telechat date: 18Feb2015

Summary: Ready for publication as an Informational RFC

All of the nits from my LC review have been addressed. Thanks!

RjS

On 2/2/16 10:38 AM, Robert Sparks wrote:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Feb 2016 15:37:56 +0200

Thanks Robert & Tomek!

Jari