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

["Bernie Volz (volz)" <[e-mail]>]

FYI:

>> - 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?
>No, just based on some of the traffic captures I saw. Would it sound better if "often" was replaced with "sometimes"?

From what I have seen, the interface-id is often just the interface's name (doesn't include the relay agent name).


Regarding section 4.1 (temporary addresses):

I would hope that client and server implementations aren't that broken too. Sure, RFC 3315 does allow renewing a temporary address, but I would not expect clients to generally do that. And similarly neither clients nor servers would normally place these temporary addresses into the DNS. (I don't think there needs to be a blanket prohibition against placing these in DNS [by clients]. For example, a client could add its temporary address for a short period to allow an incoming connection and then remove it after a short period.)

Also, RFC 4704 does have (in 5.4.  Domain Name and DNS Update Issues):

   A client SHOULD NOT perform DNS updates to AAAA RRs for its non-
   Global Unicast addresses [7] or temporary addresses [6].

Though there is no corresponding section in the DHCPv6 Server Behavior text

I think the 4.1 section could perhaps be re-written to say:

   Client implementations may mistakenly renew temporary addresses
   if they are not careful (i.e., by including the IA_TA with the same IAID
   in Renew or Rebind requests, rather than a new IAID - see [RFC3315]
   Section 22.5), thus forfeiting short liveness.

   And, [RFC4704] does not explicitly prohibit servers to update DNS for
   assigned temporary addresses.  However, this is not advised as
   publishing a client's IPv6 address in DNS that is publicly available is a
   major privacy breach.



For what it is worth, the server I work on has never done DNS Updates for temporary addresses - just for non-temporary if so configured. 

- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, November 25, 2015 10:17 AM
To: [e-mail]
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-privacy-01 - Respond by Sept. 22, 2015

On 15.09.2015 20:06, 神明達哉 wrote:
> 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.
Thanks for reviewing this draft. See my responses below:

> 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).
The reason why 4941 is mentioned in this context is that one of its goals is to hide client's LL address. Used together with LL address randomization it may give a false perception of LL address not being disclosed. That is not true if DUID was generated based on LL address.

I did update the text. Is it any better?

   A user may enable privacy extensions (which define
   how stateless addresses can use random information instead of IEEE
   identifiers, see [RFC4941] for details) and its equivalent for link-
   layer address randomization (several OSes provide such a capability)
   and get a false impression that the true link-layer address of his
   device is not disclosed.  It is likely that those privacy mechanisms
   were disabled during the first device boot.  Hence the original,
   unobfuscated link-layer address will likely end up being announced as
   client DUID, even if the link-layer address has changed (or even if
   being changed on a periodic basis).

> - 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.
Ok, removed.

> - 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?
No, just based on some of the traffic captures I saw. Would it sound better if "often" was replaced with "sometimes"?

> - 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.
But it *is* a protocol problem. Or at least a deficiency if you consider this from the privacy perspective. Conformant clients can renew temporary addresses. It's allowed by RFC3315. This is maybe not very thoughtful implementation, but it's certainly valid. This is explicitly allowed in 18.1.3 of RFC3315:

   If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no
   T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind
   message, respectively, at the client's discretion.

I'm open to suggestions how to reword this paragraph, but the major point it tries to make here is that 3315 allows renewing temporary addresses (which maybe is useful in some deployments, but I can't think of any at this moment), but the longliveness of the temporary address is a problem from privacy prespective.

> - 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.
Again, we may agree that from the privacy perspective it seems naive, but that doesn't change the fact that there are servers that do that.
Note that the goal of this draft is report potential privacy concerns, not try to assess how thoughtful the implementers were.

If you think we should update the text, maybe adding something like:

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

If that's not sufficient, can you propose a better text?

> - 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.
Would the following text address your comments:

  The client FQDN Option [RFC4704] used along with DNS Updates
  [RFC2136] defines a mechanism that ...

> Same comment applies to Section 5.7.
Ok, will correct both.

> - 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?
There are implementations that allow you to configure certain prefix (at least /64) and then append it with whatever IID the client used.
I'm not sure where they take the information from, perhaps they use least significant 64 bits from the source address? This approach is convenient for sysadmins to do MAC/IP matching, but it has serious flaws (privacy nightmare and also does not work sometimes depending on how the server obtained IID or MAC address). That's why I wouldn't want to describe this approach in detail as it may encourage people to do it more often. If you insist on adding a text for it, I can propose something.

> - 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
Am afraid so. Section 18.1.2 of RFC3315 (which describes sending Confirm
messages) has this text:

   The client includes IA options for all of the IAs
   assigned to the interface for which the Confirm message is being
   sent.

The text says IAs (which in my interpretation means both IA_TA and IA_NA). That's unfortunate, but apparently that's what the 3315 spec recommends.

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

Would updating the text to the following address your concern here:

   When DHCPv6 clients connect to a network, they attempt to obtain the
   same address they had used before they attached to the network.  They
   do this by putting the previously assigned address(es) in the IA
   Address Option(s) inside the IA_NA.  [RFC3315] also allows sending
   IA_TA in such case.  By observing these addresses, an attacker can
   identify the network the client had previously visited.

?

> - 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"?
Yes. Corrected.

> 
> 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?
http://dictionary.reference.com/browse/protocolar shows protocolar as adjective. But it's not a frequently used word, I admit. How about rephrasing the text as:

   There are a number of serious issues, both related to protocol and
   its implementations, that make temporary addresses nearly useless for
   their original goal.

>   - 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)
Will do.

Thanks a lot for your comments. I plan to publish updated -02 once I get your confirmation and address other outstanding comments from other reviewers.

Tomek

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg