Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>

[神明達哉 <[e-mail]>]

At Tue, 17 May 2016 11:20:51 -0400,
Fernando Gont <[e-mail]> wrote:

> There are multiple reasons for which that is the wrong approach and/or
> incorrect.
>
> They are stated in the I-D as:
>    More generally, the reuse of identifiers that have their own
>    semantics or properties across different contexts or scopes can be
>    detrimental for security and privacy
>    [I-D.gont-predictable-numeric-ids].  In the case of traditional
>    stable IPv6 IIDs, some of the security and privacy implications are
>    dependent on the properties of the underlying link-layer addresses
>    (e.g., whether the link-layer address is ephemeral or randomly
>    generated), while other implications (e.g., reduction of the entropy
>    of the IID) depend on the algorithm for generating the IID itself.

I know there's this text, but it's too vague to me to interpret it as
this draft tries to reject the concern.  That's why I've been asking
the intent of the draft several times.  And this vagueness is the main
point of mine, rather than the specific claims themselves.  So I'm
not going to respond to each defense arguments for the claims, but
rather focusing on the higher level point: to me, the current form of
draft is vague about the following two points:

1. Whether it assumes (or introduces itself) that a stable address is
   required to be configured (banning non-stable only operation).
2. Whether the case where "link-layer addresses" are randomized is
   also covered by this draft (in that it prohibits embedding such
   addresses in IID)

According to the discussion in this thread, my latest understanding is
that the answer is "yes" to both points.  In that case, I'd then
request these points to be stated more explicitly and clearly in the
draft, and see clear wg consensus on these points.

I myself don't have a strong opinion (yet) on these points, but I see
some controversy in the wg.  For example, some responses in the latest
sub-thread on RFC4941 seem to indicate opinions on point #1 vary (and
some people even say RFC4941 does not necessarily require a public
address).  I also see that some people think that point #2 can be
loosened so that it only covers "permanent-and-predictable link-layer
addresses".  So I don't think we have a clear wg consensus on these
yet.  And, if this draft tries to achieve something that relies on
these points, IMO it can't pass the wg last call yet.


> > And, one other point I want to be addressed: in Section 4 it states:
> >
> >    By default, DHCPv6 server implementations SHOULD NOT generate
> >    predictable IPv6 addresses (such as IPv6 addresses where the IIDs are
> >    consecutive small numbers).  [I-D.ietf-dhc-stable-privacy-addresses]
> >    specifies one possible algorithm that could be employed to comply
> >    with this requirement.  Another possible algorithm would be to select
> >    a pseudo-random value chosen from a discrete uniform distribution,
> >    while avoiding the reserved IPv6 Interface Identifiers [RFC5453]
> >    [IANA-RESERVED-IID].
> >
> >  I suggest just removing the second sentence.
> >  ietf-dhc-stable-privacy-addresses is not a dhc wg item anymore due to
> >  some controversy, and it's not clear what will happen to its
> >  successor in the form of individual submission:
> >  draft-gont-dhcpv6-stable-privacy-addresses-01
> >  Since this sentence is only to show an example, just showing the
> >  "another possible algorithm" would suffice.
>
> I will check what the status of the corresponding draft-gont version of
> the I-D is. To the extent that is possible, I'd keep it, since
> ietf-dhc-stable-privacy-addresses leads to stable addresses, while a
> simple randomization scheme doesn't.

This logic seems awkward to me.  For
draft-gont-dhcpv6-stable-privacy-addresses-01 to be a better example
despite its uncertain future for that reason, I'd expect the stability
is also included in the updated text of RFC3315.  Otherwise, just
showing a simple randomization is a far better example since it
exactly meets the revised text.  I'd also note another recent trend in
dhc, where randomizing DUID may become a new norm as described in
RFC7844 (a standards track RFC).  Since the stability of
draft-gont-dhcpv6-stable-privacy-addresses depends on the stability of
DUID, the stability argument doesn't hold for client implementations
supporting and enabling RFC7844.

For all these reasons, I'd still suggest just removing the reference.
But if the idea of draft-gont-dhcpv6-stable-privacy-addresses is too
loved to be removed, my secondary suggestion is to move it to an
auxiliary example after the simple randomization, noting that it's
listed because it has an additional property of stability and that it
has a limitation that it's not compatible with RFC7844.

--
JINMEI, Tatuya