Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy-01 - Respond by Sept. 22, 2015

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 2 Sep 2015 21:44:58 +0000

Hi all,

This message starts the DHC Working Group Last Call to advance draft-ietf-dhc-dhcpv6-privacy-01, Privacy considerations for DHCPv6, http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-01. This document's intended status is Informational. At present, there is no IPR file against this document.

This is a part of the WGLC of 3 documents (draft-ietf-dhc-dhcp-privacy-01,  draft-ietf-dhc-dhcpv6-privacy-01, and draft-ietf-dhc-anonymity-profile-03).

Please send your comments by September 22th, 2015. If you do not feel this  document should advance, please state your reasons why.

Bernie Volz is the assigned shepherd.

- Tomek & Bernie

---

From: 神明達哉 <[email-masked]>
Date: Tue, 15 Sep 2015 11:06:13 -0700

On Wed, Sep 2, 2015 at 2:44 PM, Bernie Volz (volz) <[email-masked]> wrote:

> This message starts the DHC Working Group Last Call to advance
> draft-ietf-dhc-dhcpv6-privacy-01, Privacy considerations for DHCPv6,
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-01. This document’s
> intended status is Informational. At present, there is no IPR file against
> this document.
[...]
> Please send your comments by September 22th, 2015. If you do not feel this
> document should advance, please state your reasons why.

I don't have a strong opinion on whether to advance it, but I
personally think it's premature to be published.  There are several
confusing points in the draft (see below for specific points), and if
I were to decide I'd first clarify these before sending it to the
IESG.

Also, as someone who is not a privacy expert, I don't know for sure if
there are missing important points (while I can make comments on
what's currently written).  It would be nice if someone with this
expertise can explicitly comment on that point (rather than interpret
silence as acceptance).

Specific comments on the draft:

- Section 3.1

   Even if the administrator enables privacy extensions
   (see [RFC4941]) and its equivalent for link-layer address
   randomization, it is likely that those privacy mechanisms were
   disabled during the first device boot.

I don't understand how RFC4941 is relevant in this context (I
understand the relevance of LL addr randomization).  Elaboration? (or
if it's not really relevant I suggest just removing it).

- Section 3.2

   Client ID is an example of DUID.

I don't understand this sentence.  First off, RFC3315 barely defines
"Client ID(entifier)" while it defines "DUID" or "Client ID Option".
If you mean the DUID field value of client ID option by "Client ID",
this sentence sounds too obvious to me.  It's not a big deal, but I
suggest just removing this sentence as I don't think it helps readers
and can rather confuse them.

- Section 3.11.2

   it is often a text string that includes the
   relay agent name followed by interface name.

What does "often" mean?  Does this mean the vast majority of relay
implementations behave this way?  If so, is it based on a survey of
implementations?

- Section 4.1

   Many client implementations
   renew those addresses during a renewal procedure initiated by other
   resources (non-temporary addresses or prefixes), thus forfeiting
   shortliveness.

What does this 'many' mean?  Specifically how many implementation out
of which behave this way?  Regardless of exactly how many, this
behavior rather seems to be an implementation bug, since, as the draft
itself states, it would forfeit the point of temporary addresses.  If
that's what this draft tries to point out, I think it should state
it's an implementation defect to be fixed more clearly.  Right now it
could rather read this is a protocol problem.

- Section 4.1

   Second, [RFC4704] allows servers to update DNS for
   assigned temporary addresses.  Publishing client's IPv6 address in
   DNS that is publicly available is a major privacy breach.

Similar to the previous point, if a server performs dynamic DNS
update for a temporary address it assigns to a client (corresponding
to IA_TA), it seems to me that the server implementation is just too
naive.  And, like the previous point, currently the draft doesn't seem
to read it's an implementation problem.

- Section 4.2

   DNS Updates [RFC4704] defines a mechanism that allows both clients
   and server to insert into DNS domain information about clients.  Both

"DNS Updates [RFC4704]" looks confusing/misleading to me.  I believe
the term "DNS Updates" generally refers to the protocol defined in
RFC2136.  If this "DNS Updates" is intended to mean the protocol
described in RFC4704 (I think that's the intent from the context), I
suggest using some other term than "DNS Updates".  If it actually
means the protocol defined in RFC2136, it should refer to RFC2136, not
RFC4704.

Same comment applies to Section 5.7.

- Section 4.3

   Identifier-based allocation - a server may choose to allocate an
   address that is based on one of available identifiers, e.g.  IID or
   MAC address.

  What does this "IID" mean?  Interface Identifier?  If so, I don't
  understand it.  Or perhaps DUID?

- Section 5.4

   They
   do this by putting the previously assigned address(es) in the IA
   Address Option(s) inside the IA_NA, IA_TA.

Is a client really supposed to include IA_TA?  Or is this about
specific implementations?  Either way this behavior seems to be simply
broken.  If it talks about (a defect of) specific implementation, it
may be worth noting, but I think it should be clearly separated from
the case of IA_NA and described as an implementation defect.

- Section 7

   As such, no dedicated section about this is needed.

This sounds awkward to me since Section 7 is actually a "dedicated
section about" privacy.  Guessing author's intent, perhaps this should
be "no dedicated discussion"?

Editorial nits:
  - Section 1: s/or/of/ or s/or/for/ (?)

   The privacy or DHCP servers and relay agents are

  - Section 4.1

   There are number of serious issues, both protocolar and
   implementational, that make them nearly useless for their original

  The term "protocolar" is not in my usual dictionaries...is it some
  kind of jargon that I yet to learn, or is it just a typo?

  - I've found other several trivial typos and grammar errors, but I
    won't bother to list all of them here.  The authors might want to
    run another cycle of proofread before finally submitting it to the
    IESG (or with RFC editor)

--
JINMEI, Tatuya

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 22 Sep 2015 19:38:30 +0200

I have read this document and I support advancing it. However, I found a
bunch of typos, which I am not listing here because it will be more
efficient if authors just run the spell check and easily locate them
themselves.

There are also some typos which wouldn't be picked by the spell checker
because they make existing words. However they cause various grammatical
and logical errors. It seems that authors may have neglected to do the
final proof reading of the whole text, because these errors are easy to
spot.

There are also additional issues which may, to some extent, overlap with
Jinmei's comments.

3. Identifiers in DHCPv6
Almost all sections belonging to section 3. (apart from the one
discussing DUID) describe *options* carrying some identifiers. So it
would be more appropriate to update the introductory text for section 3
to say:

"In DHCPv6, there are many options which include identification
information or can be used to extract the identification information
about the client. This section enumerates various options and
identifiers conveyed in them, which can be used to disclose client
identification."

and rename the section 3 to "DHCPv6 options carrying identifiers"

3.2. Client ID Option

The section title should be "Client Identifier Option" because this is
the actual name of this option.

What does it mean "Client ID is an example of DUID"? I thought that
"Client Identifier option is used to convey the DUID".

3.3. IA_NA, IA_TA... and co.

OLD:
"The IA Address option is used to specify IPv6 addresses ...."

NEW:
"The IA Address option is used to convey IPv6 addresses ..."

OLD:
" To differentiate between instances of the same type of IA containers,
   each IA_NA, IA_TA and IA_PD options have an IAID field that is unique
   for each client/option type pair. "

NEW:
" To differentiate between instances of the same type of IA containers
for a client, each IA option includes the IAID field with a unique value
for a given IA type".

3.8. Civic Location Option

OLD:
"DHCPv6 servers use the Civic Location option [RFC4776] to delivery of
   location information"

NEW:
"DHCPv6 servers use the Civic Location option [RFC4776] to deliver the
   location information.."

3.9. Coordinate based location

I don't know what this intends to say:
"After the relevant DHCPv6 exchanges have taken place, the location
   information is stored on the end device rather than somewhere else,
   where retrieving it might be difficult in practice."

- what is "end device"?
- what is "somewhere else" ?
- retrieving? You mean it is hard to breach privacy of the client using
this information because it is stored on the device running the DHCP client?

I think this section may try to convey a valid information but is
heavily unclear as stated.

3.10. Client System Architecture Type Option

"The Client System Architecture Type option [RFC5970] is used by
   DHCPv6 client to send a list of supported architecture types to the
   DHCPv6 server.  It is used to provide configuration information for a
   node that must be booted using the network rather than from local
   storage."

The part starting from

"It is used to provide configuration information..."

is wrong because the options providing configuration information for a
node (server to client) are different options, e.g. OPTION_BOOTFILE_URL.

I think I understand what you're trying to say, but you don't say what
you mean.

OLD:
"3.11.1. Subscriber ID"

NEW:
"3.11.1. Subscriber-ID Option"

OLD:
"3.11.2. Interface-ID"

NEW:
"3.11.2. Interface-ID Option"

OLD:
"3.11.3. Remote ID"

NEW:
"3.11.3. Remote-ID Option"

"4.  Existing Mechanisms That Affect Privacy
   This section describes available DHCPv6 mechanisms that one can use
   to protect or enhance one's privacy."

Is this really true? I thought the purpose of the document was to
describe the privacy issues related to the DHCPv6 protocol as it stands
with no attempt to provide any mitigation strategies.

If the purpose of the document is also to provide some recommendations
for the clients (or rather clients' implementors) to avoid some
operations leading to privacy breaching (without changing the protocol)
it should be clearly stated in the introduction. Currently the
introduction only states that this documents enumerates various
identifiers which can be used to obtain identification information about
the clients.

After reading section 4 I actually don't see any mitigation strategies
provided. So, the introductory text in  this section is wrong.

Marcin

On 02.09.2015 23:44, Bernie Volz (volz) wrote:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-privacy-01. This
> document’s intended status is Informational. At present, there is no IPR
> file against this document.
> 
>  
> 
> This is a part of the WGLC of 3 documents
> (draft-ietf-dhc-dhcp-privacy-01,  draft-ietf-dhc-dhcpv6-privacy-01, and
> draft-ietf-dhc-anonymity-profile-03).
> 
>  
> 
> Please send your comments by September 22th, 2015. If you do not feel
> this  document should advance, please state your reasons why.
> 
>  
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>