Subject: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 01 Feb 2016 06:24:13 -0800

The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Anonymity profile for DHCP clients'
  <draft-ietf-dhc-anonymity-profile-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2016-02-15. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   Some DHCP options carry unique identifiers.  These identifiers can
   enable device tracking even if the device administrator takes care of
   randomizing other potential identifications like link-layer addresses
   or IPv6 addresses.  The anonymity profile is designed for clients
   that wish to remain anonymous to the visited network.  The profile
   provides guidelines on the composition of DHCP or DHCPv6 requests,
   designed to minimize disclosure of identifying information.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2654/

---

From: 神明達哉 <[email-masked]>
Date: Fri, 12 Feb 2016 11:25:58 -0800

> beginning of the Subject line to allow automated sorting.

Brian Carpenter called for an attention to Section 4.5.2 of the draft:
https://mailarchive.ietf.org/arch/msg/ipv6/J_SnGxd2JunlpOeL4JprV03UA7s

so I'm responding to it.

4.5.2.  Prefix delegation

   The interaction between prefix delegation and anonymity require
   further study.  For now, the simple solution is to avoid using prefix
   delegation when striving for anonymity.  When using the anonymity
   profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of
   address assignment.

I'm not sure what Brian tried to indicate in his message, but at least
this section looks vague to me about the rationale for the "SHOULD
NOT".  It's not obvious to me how IA_PD is worse than IA_NA in terms
of privacy.  Is this a "SHOULD NOT" simply because the "interaction"
(is not yet fully understood and) requires further study?

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Feb 2016 20:47:36 +0000

Hi,

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of ????
> Sent: Friday, February 12, 2016 11:26 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Bernie Volz (volz); IETF-Announce; [email-masked]
> Subject: Re: [dhcwg] Last Call: <draft-ietf-dhc-anonymity-profile-06.txt> (Anonymity profile for DHCP clients) to Proposed Standard
> 

I don't have a strong opinion on the "SHOULD NOT" in this paragraph, but
it is very important that this guidance not be taken out of context. This
document is only about clients that wish to remain anonymous, which
does not apply to all use cases.

Thanks - Fred
[email-masked]
 
> --
> JINMEI, Tatuya
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 12 Feb 2016 14:08:55 -0800

On Friday, February 12, 2016 12:48 PM, Fred Templin wrote
> > From: dhcwg [mailto:[email-masked]] On Behalf Of ???? (> JINMEI,
Tatuya)
> >
> > Brian Carpenter called for an attention to Section 4.5.2 of the draft...
> > so I'm responding to it.
> >
> > 4.5.2.  Prefix delegation
> >

Yes, exactly that. There was some anxiety that prefix delegation requires
understanding to whom the prefix is delegated. There are also potential side
effects if prefix are reassigned quickly to random nodes. All that needs
further study before we can make a recommendation. We can certainly add a
bit of text to make that more clear.

> I don't have a strong opinion on the "SHOULD NOT" in this paragraph, but
it is
> very important that this guidance not be taken out of context. This
document
> is only about clients that wish to remain anonymous, which does not apply
to
> all use cases.

Yes. Also, we can add text explaining that once these problems are better
understood and the IETF agrees on the proper way to handle anonymous prefix
delegation, clients MAY use the agreed upon solution. Which is kind of
redundant, but if you guys prefer it that way, why not.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Feb 2016 11:15:43 +1300

> redundant, but if you guys prefer it that way, why not.

To be clear, I don't have a strong opinion on this; it simply seemed like
something the IPv6 community should be aware of before it ends up in an RFC.
I also noticed this morning that it might impact draft-ietf-v6ops-host-addr-availability.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 13 Feb 2016 08:37:13 +0100

> draft-ietf-v6ops-host-addr-availability.

+1 to the other comments here.

I see no reason why prefix delegation should be worse for anonymity than
address assignment. In fact, using prefix delegation instead of address
assignments provides benefits for anonymity against off-link attackers,
because delegating a prefix to a client allows that client to use many
different addresses (potentially, even a different address for every remote
host it connects to, or a different address for every new TCP connection).

As Brian says, there are many other reasons why a network would want to
provide a dedicated prefix to the host;
see draft-ietf-v6ops-host-addr-availability .

I would instead say something like:

====
The anonymity properties of DHCPv6 Prefix Delegation, which use IA_PD
identity associations, are similar to those of of DHCPv6 address assignment
using IA_NA identity associations.

Because current host OS implementations do not typically request prefixes,
clients that wish to use DHCPv6 PD - just like clients that wish to use any
DHCP or DHCPv6 option that is not currently widely used - should recognize
that doing so will serve as a form of fingerprinting unless or until client
use of DHCPv6 PD becomes more widespread.
====

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 16 Feb 2016 11:53:07 +0900

On Mon, Feb 1, 2016 at 11:24 PM, The IESG <[email-masked]> wrote:

> [email-masked] mailing lists by 2016-02-15.

Christian et al., thanks for taking on this work. But I think an important
point here is missing.

It seems to me that fundamental design of DHCP relies on the client blindly
broadcasting information to anyone that happens to be on link, or on the
path between relay and server. This information is both explicit - e.g.,
previous IP addresses assigned, hostnames, etc. - and implicit - e.g., via
implementation behaviour and unique combinations of options.

It's true that this profile mitigates the amount of information that can be
collected. But in IPv6 we have other configuration methods - such as SLAAC
- that broadcast way less information than stateless DHCPv6, which in turn
broadcasts less information than stateless DHCPv6.

This document should recognize that at least on IPv6-only networks, it is
an option not to use DHCP at all, and that option has substantial privacy
benefits that are in many cases above what this profile can provide.

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 15 Feb 2016 21:26:16 -0800

On Monday, February 15, 2016 6:53 PM, Lorenzo Colitti wrote:
>
> It's true that this profile mitigates the amount of information that can be collected. 
> But in IPv6 we have other configuration methods - such as SLAAC - that broadcast 
> way less information than stateless DHCPv6, which in turn broadcasts less information 
> than stateless DHCPv6.
>
> This document should recognize that at least on IPv6-only networks, it is an option 
> not to use DHCP at all, and that option has substantial privacy benefits that are in 
> many cases above what this profile can provide.

Well, section 4 of draft-ietf-dhc-anonymity-profile-07 says:

   The choice between the stateful and stateless scenarios depends on
   flag and prefix options published by the "Router Advertisement"
   messages of local routers, as specified in [RFC4861].  When these
   options enable stateless address configuration hosts using the
   anonymity profile SHOULD choose it over stateful address
   configuration, because stateless configuration requires fewer	
   information disclosures than stateful configuration.

That seems pretty close from what you want, at least as far as "stateful DHCPv6" is concerned.

-- Christian Huitema

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 16 Feb 2016 16:37:59 +0900

> That seems pretty close from what you want, at least as far as "stateful

Urg. That statement is pretty hard to understand. In fact, I misunderstood
it for a full 10 minutes until someone explained it to me. I think I
understand it now, and if my understanding is indeed correct, then I would
suggest you clarify it as follows:

   When these options enable stateless address configuration (i.e., when
   the A flag in a Prefix Information Option is set to 1) hosts using the
   anonymity profile SHOULD perform Stateless Address Configuration
   and SHOULD NOT use stateful DHCPv6, because stateless configuration
   requires fewer information disclosures than stateful configuration.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 16 Feb 2016 07:29:19 -0500

> That seems pretty close from what you want, at least as far as "stateful DHCPv6" is concerned.

I would agree that the above text covers what I interpret as Lorenzo's
concern.

Regards,
Brian

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 16 Feb 2016 10:13:49 -0800

On Friday, February 12, 2016 11:26 AM, JINMEI, Tatuya wrote:
> I'm not sure what Brian tried to indicate in his message, but at least this
> section looks vague to me about the rationale for the "SHOULD NOT".  It's
> not obvious to me how IA_PD is worse than IA_NA in terms of privacy.  Is this
> a "SHOULD NOT" simply because the "interaction"

This section was rewritten in draft-07, following the feedback received during IETF last call. Basically, we stopped being lazy and actually did the study. And took a lot of the text that Lorenzo provided.

-- Christian Huitema

---

From: 神明達哉 <[email-masked]>
Date: Tue, 16 Feb 2016 10:25:57 -0800

At Tue, 16 Feb 2016 10:13:49 -0800,

> This section was rewritten in draft-07, following the feedback received during IETF last call. Basically, we stopped being lazy and actually did the study. And took a lot of the text that Lorenzo p…

I didn't intend to make my comment as a blocking issue for the last
call, but just to be clear: The revised section 4.5.2 of rev 07 looks
good to me.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 22 Feb 2016 11:17:50 +0900

> I would agree that the above text covers what I interpret as Lorenzo's

My concern is not with the intent, it's with the wording.

The business of this draft is to provide guidance to implementers. I am an
implementer: I wrote the DHCP client currently used in a host OS, and while
said OS does not yet support DHCPv6, I am likely to involved with that as
well if/when that happens. So I am squarely in the target audience for this
document - but as has become clear from this thread, I did not understand
the text correctly, even though I was actually paying attention It took a
specific response from Christian and an explanation from a colleague before
I actually understood what the implications were for host behaviour. We
should try to ensure other implementers do not misunderstand the text like
I did, by making it clearer.

Let me suggest text again:

   When these options enable stateless address configuration (i.e., when
   the A flag in a Prefix Information Option is set to 1) hosts using the
   anonymity profile SHOULD perform stateless address configuration
   and SHOULD NOT use stateful DHCPv6, because stateless configuration

I don't see how that text is different from the text that's already in the
draft, except it actually provides clear guidance. Why not use it?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 22 Feb 2016 15:32:54 +0900

> draft, except it actually provides clear guidance. Why not use it?

Christian pointed out that this text has been revised in -08. When I read
the new text, "When these options enable stateless address configuration
hosts using the anonymity profile SHOULD use stateless address
configuration instead of stateful address configuration", as an implementer
I know what to do. Thank you.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2016 19:18:06 -0300

On 02/21/2016 11:17 PM, Lorenzo Colitti wrote:
> I don't see how that text is different from the text that's already in
> the draft, except it actually provides clear guidance. Why not use it?

The above text (or any similar text already in the I-D) suggests that
this document should be updating RFC4862. Because it is not only
specifying that to do when you do DHCPv6, but also whether to do
SLAAC/DHCPv6 in the fist place.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Feb 2016 08:51:45 +0900

> SLAAC/DHCPv6 in the fist place.

I don't see why. I don't recall a statement in RFC 4862 specifying whether
hosts should use one or the other.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2016 21:08:37 -0300

On 02/22/2016 08:51 PM, Lorenzo Colitti wrote:
> On Tue, Feb 23, 2016 at 7:18 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I don't see why. I don't recall a statement in RFC 4862 specifying
> whether hosts should use one or the other.

But the authors are making such statement here. i.e., if you are going
to implement SLAAC/DHCPv6, then this statement affects your
implementation. Hence, an appropriate tag should be included (i.e., such
that if I look at RFC4862 or RFC3315, it's clear that I should look at
this document, too).

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Feb 2016 09:35:32 +0900

> that if I look at RFC4862 or RFC3315, it's clear that I should look at

I still don't see why this document needs to formally "updates: RFC 4862"
if it doesn't affect any text in it.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 23 Feb 2016 01:35:50 -0800

On Monday, February 22, 2016 4:36 PM, Lorenzo Colitti wrote:
> On Tue, Feb 23, 2016 at 9:08 AM, Fernando Gont <[email-masked]> wrote:
> ...
> I still don't see why this document needs to formally "updates: RFC 4862" if it doesn't affect any > text in it.

We actually had an extensive discussion on a related topic, whether to state that the document was "updating RFC 4361." We concluded that no, it wasn't, using precisely the test that Lorenzo mentions. The consensus was that an RFC can only update another one if it replaces some of the original text. You have to be able to say something like "in section X of RFC Y, replace the sentence so and so by this and that," or "add this paragraph." 

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2016 07:59:47 -0300

On 02/22/2016 09:35 PM, Lorenzo Colitti wrote:
> On Tue, Feb 23, 2016 at 9:08 AM, Fernando Gont <[email-masked]
> I still don't see why this document needs to formally "updates: RFC
> 4862" if it doesn't affect any text in it.

RFC4861/RFC4862 say that when M=1 you do SLAAC. Here you are saying that
if you have a PIO with A=1, you should not do DHCPv6. That's an update
to the existing specs.

I'm not saying the above is good or bad, but that's an update, and
deserves a corresponding "update tag".

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2016 08:06:25 -0300

On 02/23/2016 06:35 AM, Christian Huitema wrote:
>> On Tue, Feb 23, 2016 at 9:08 AM, Fernando Gont
>> <[email-masked]> wrote: ...
>>> But the authors are making such statement here. i.e., if you are
>>> going to implement SLAAC/DHCPv6, then this statement affects
>>> your implementation. Hence, an appropriate tag should be included
>>> (i.e., such that if I look at RFC4862 or RFC3315, it's clear that
>>> I should look at this document, too).
>> 
>> 4862" if it doesn't affect any > text in it.
> 
> We actually had an extensive discussion on a related topic, whether
> to state that the document was "updating RFC 4361." We concluded that
> no, it wasn't, using precisely the test that Lorenzo mentions. The
> consensus was that an RFC can only update another one if it replaces
> some of the original text. You have to be able to say something like
> "in section X of RFC Y, replace the sentence so and so by this and
> that," or "add this paragraph."

Please see my response to Lorenzo.

Essentially, Lorenzo is saying that even if M=1, if you have a PIO with
A=1 you SHOULD do SLAAC and SHOULD NOT do DHCPv6. That's an update to
the existing specs.

Similarly, your text says:

That's actually the contrary of what the specs say today: if M=1 you do
DHCPv6, not SLAAC.

I'm not arguing that what you propose is incorrect. I'm just saying
that, procedurally speaking, you're updating SLAAC. Hence your document
should have an appropriate "Update" tag, and note in the abstract the
specs it is updating.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Feb 2016 21:45:17 +0900

> if you have a PIO with A=1, you should not do DHCPv6. That's an update

Cite RFC4861/4862 text or your statement is unsupported and unactionable.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Feb 2016 21:47:03 +0900

> That's actually the contrary of what the specs say today: if M=1 you do

I don't see any statement in 4861 that says that. Per 4861, M=1 means
"DHCPv6 is available", not "nodes should do DHCPv6". Relevant text:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Feb 2016 12:50:01 +0000

> On 23 Feb 2016, at 12:47, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Tue, Feb 23, 2016 at 8:06 PM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
> I don't see any statement in 4861 that says that. Per 4861, M=1 means "DHCPv6 is available", not "nodes should do DHCPv6". Relevant text:
> 
>                      Dynamic Host Configuration Protocol [DHCPv6]

I agree. It’s always just been a hint, no more, no less. And it’s been discussed many times...

Tim

---

From: Brian Haberman <[email-masked]>
Date: Tue, 23 Feb 2016 08:18:27 -0500

All,

> I agree. It’s always just been a hint, no more, no less. And it’s been discussed many times...

As shepherding AD, I believe the consensus is that there is not a need
to have this document update RFC 4861/4862.

Regards,
Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2016 10:34:19 -0300

>                      Dynamic Host Configuration Protocol [DHCPv6].

This is the first one I found:

   Moreover, information
   may also be obtained through other dynamic means like DHCPv6.  Hosts
   accept the union of all received information; the receipt of a Router
   Advertisement MUST NOT invalidate all information received in a
   previous advertisement or from another source.

If you want, take this as a "may". But your text says SHOULD NOT, and
may != SHOULD NOT.

Besides, what if say, there's different address information available
via RA vs DHCPv6? --the text I cited above suggests that you accept the
union, but you suggest that you accept only the info provided by the RAs.

Again, I don't disagree (per se) with the proposal to do SLAAC rather
than DHCPv6 . But, I just think the behavior being suggested differs
from what we currently have -- hence the suggested "Update".

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Feb 2016 22:45:34 +0900

>    previous advertisement or from another source.

This text is also unaffected by the current draft. The draft says that the
host should decide whether or not to do DHCPv6 based on the information in
Router Advertisements. That does not contradict RFC 4861: since DHCPv6
requires an explicit request from the host before anything happens,
choosing *not to start* DHCPv6 does not "invalidate" anything obtained from
DHCPv6. If DHCPv6 was not started, then the host will have received nothing
from DHCPv6, and there is nothing to invalidate.

> union, but you suggest that you accept only the info provided by the RAs.

The draft doesn't say that the host shouldn't accept information provided
by DHCPv6. It says that the host shouldn't request such information if it
has all it needs from something else.

> from what we currently have -- hence the suggested "Update".

The behaviour that we currently have is due to what implementations chose
to do, not to what standards track RFCs say.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2016 11:13:49 -0300

On 02/23/2016 10:45 AM, Lorenzo Colitti wrote:
> The draft doesn't say that the host shouldn't accept information
> provided by DHCPv6. It says that the host shouldn't request such
> information if it has all it needs from something else.

Say you only receive a ULA/64 in the RA. Is that "all you needed"?
(particularly if there was a GUA available via DHCPv6)

> The behaviour that we currently have is due to what implementations
> chose to do, not to what standards track RFCs say.

... what implementations chose to do, within ambiguity in the specs. See
draft-ietf-v6ops-dhcpv6-slaac-problem-06.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 23 Feb 2016 23:30:34 +0900

I don't see what question that has to do with whether this document updates
RFC 4861 or not. Happy to discuss that question in another thread, but not
here. (The "all you needed" words aren't even in the draft - they are mine).

---

From: 神明達哉 <[email-masked]>
Date: Tue, 23 Feb 2016 09:35:55 -0800

At Tue, 23 Feb 2016 12:50:01 +0000,

> I agree. It’s always just been a hint, no more, no less. And it’s been discussed many times...

+1.  I understand it may look subtle and could be confusing probably
because it was a kind of compromise as we could reach consensus on how
M/A flags should actually work.  But, however it looks, I'm pretty
sure that the intent of RFC4861 is that we do NOT say "if M=1 you do
DHCPv6", and that was intentional.  Let alone RFC4862 (for which I
happen to be a document editor): it even removed references to the M/O
flags:

   o  Removed the text regarding the M and O flags, considering the
      maturity of implementations and operational experiences.
      ManagedFlag and OtherConfigFlag were removed accordingly.  (Note
      that this change does not mean the use of these flags is
      deprecated.)

As such, I don't see the need for adding the "update: RFC 4682" mark
because of the proposed text.  (I don't have a particular opinion on
the text itself, btw).

--
JINMEI, Tatuya

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Feb 2016 18:28:58 +0000

> deserves a corresponding "update tag".

FWIW, I've no opinion here but please be aware that different working
definitions of the "updates" relationship are concurrently in use in
different bits of the IETF. For some, it means "you really need to
read this" for others its "a new implementer of the old thing really
needs to also include the new code" and those aren't always the same.
There are probably other not-unreasonable meanings one could come up
with too. I'd not get hung up on it generally myself.

S.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2016 15:36:24 -0300

Stephen,

> with too. I'd not get hung up on it generally myself.

Thanks for the note, and I agree with your view.

That said... isn't this an indication that we should converge on
*something* regarding the meaning of "updates"? (i.e., it should be
clear what it means, and what rules should be applied when deciding when
a "Updates" tag is warranted or not)

Cheers,

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Feb 2016 18:44:14 +0000

Hiya,

> a "Updates" tag is warranted or not)

In theory, yes. I don't find it to be something that I'd prioritise
myself. I suspect attempts to "fix" this would open a can of worms
about the general semantics of relationships between RFCs and would
likely end up being very hard to get done, and with not much benefit
at the end.

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Feb 2016 08:02:40 +1300

> likely end up being very hard to get done, and with not much benefit

It's clear that there is a problem with "updates", "obsoletes", "normative
reference" and "informative reference" being the only clearly defined
relationships between documents. Sometimes you just need to read a group
of documents with none of these relationships to get the whole picture.

We have a draft solution:
https://tools.ietf.org/html/draft-klensin-isdbis-00

    Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 23 Feb 2016 17:38:03 -0600

Hi, Brian,

> https://tools.ietf.org/html/draft-klensin-isdbis-00

I remember ISDs, and liked them when we discussed them back in the mists of
history.

I agree that we do try from time to time to use the mechanisms we've got,
to accomplish some of the things ISDs would accomplish.

Spencer