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

From: 神明達哉 <[email-masked]>
Date: Tue, 1 Dec 2015 10:33:59 -0800

At Wed, 25 Nov 2015 16:17:17 +0100,
Tomek Mrugalski <[email-masked]> wrote:

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

Not really...my point in the comment is that whether or not RFC4941
(or RFC7217 for that matter) is used "during the first device boot",
it's irrelevant to the risk of exposing the original L2 address in
DUID, so '*those* privacy mechanisms were disabled' sounds awkward.

But I guess I now understand how you reached the text.  On top of the
understanding I still don't see the need for mentioning RFC4941 (and
it could be rather confusing), so my primary suggestion is to simply
remove it and only talk about L2 address randomization.  But if it's
so important to refer to RFC4941 some way, my suggestion would be
something like this:

   It is important to understand DUID lifecycle.  Clients and servers
   are expected to generate their DUID once (during first operation) and
   store it in a non-volatile storage or use the same deterministic
   algorithm to generate the same DUID value again.  This means that
   most implementations will use the available link-layer address during
   its first boot.  Even if the administrator enables link-layer address
   randomization, it is likely that it was 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).  The exposure of the original link-layer address
   in DUID will also undermine other privacy extensions such as
   [RFC4941].

> > - 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"?

It's not really important, I was just curious, so I'd basically leave
it to you.  But if it's not critical to say that's the majority case,
weakening would be prudent.

> > - 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? [...] 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.

Hmm, okay.  I don't remember whether I checked the RFC3315 text when I
wrote the comment, but I probably overlooked it anyway.

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

I still don't know if "many client implementations" behave that way (I
don't even know so many client implementations that support IA_TA in
the first place), but I now see your point.  As you said, that's
actually rather a protocol problem, so I'd suggest revising the text
that way, i.e, noting RFC3315 allows that behavior but it will forfeit
the shortliveness of IA_TA.

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

With better understanding the context, I guess I'm now okay with the
original text.  But mentioning that there are such implementations
wouldn't do harm either.

> > - 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.  [...]
> Would the following text address your comments:
>
>   The client FQDN Option [RFC4704] used along with DNS Updates
>   [RFC2136] defines a mechanism that ...

Yes.

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

So you mean by "IID" the Interface Identifier of an IPv6 address.
Without further explanations like the one you provided here, I suspect
this is difficult to understand for other readers, too.  Also,
re-reading it, "MAC address" may also be a bit confusing since it's
not necessarily visible for the server if the message is forwarded via
a relay agent.  If it mainly talks about some existing implementations
(that you don't know its internal details), I'd explain some more
details and only talk about observable behavior, e.g.,

    Identifier-based allocation - some server implementations use a
    fixed identifier for a specific client, seemingly taken from the
    client's MAC address when available or some lower bits of client's
    source IPv6 address.

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

I guess so, but I'd personally weaken the tone about what [RFC3315]
allows:

    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).  [RFC3315] does not
    exclude IA_TA in such a case, so it is possible that a client
    implementation includes an address contained in an IA_TA for the
    Confirm message.  By observing these addresses, an attacker can
    identify the network the client had previously visited.

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

Works for me.

--
JINMEI, Tatuya

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 17 Dec 2015 22:08:14 +0100

>    in DUID will also undermine other privacy extensions such as
Thanks a lot. Updated the text as suggested.

> weakening would be prudent.
Replaced with sometimes. As a fun fact I'll mention the strangest
interface-id I ever saw was this: ISAM133|288|ipv6|nt:vp:1:110
I have no idea what type of device inserted it. So while I agree that
often it's just an interface name, but there are stranger things being
put in the interface-id.

> the shortliveness of IA_TA.
Updated the text as Bernie suggested, with a small addition at the end:

   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.
   [RFC4704] does not explicitly prohibit servers to update DNS for
   assigned temporary addresses and there are implementations that can
   be configured to do that.

I think it better reflects the fact that renewing temporary addresses is
technically conformant, but it's a bad thing to do.

>>   [RFC2136] defines a mechanism that ...
Updated.

>     client's MAC address when available or some lower bits of client's
Thanks for proposing this text. Updated as suggested.

>     identify the network the client had previously visited.
Thanks. Updated as suggested.

>>    its implementations, that make temporary addresses nearly useless for
Updated.

Thank you a lot for your suggestions. All the text mentioned will be
published in upcoming -02.

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 17 Dec 2015 22:15:01 +0100

On 30.11.2015 20:36, Bernie Volz (volz) wrote:
> 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
> [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.
For what it is worth, I saw this behavior many years ago, so hopefully
it's now corrected.

Tomek