Review of draft-ietf-6man-rfc4941bis-01

[Christian Huitema <[e-mail]>]

This is my review of draft-ietf-6man-rfc4941bis-01, as promised in the
WG session.

I think the draft is almost ready, but I would like to see a couple of
changes:

1) Simplify the IID generation spec by treating the "hash based"
generation as just an alternative PNRG.

2) Discuss the temporary address life time and what to do when
"quickly" reconnecting to the network that the node just left.

3) Simplify the discussion of the DNS reverse tree by just stating
that temporary addresses should not be registered in that tree,
and that applications subject to address control should just use
static address.

I would also like to discuss the use case of "different temporary
addresses for different application contexts", but I suspect
this would have to be done in a different draft.

Detailed comments follow.

Section 2.1 discusses a list of ways users and devices can be tracked.
I assume this is intended to motivate the need for temporary addresses,
but I when reading it I was wandering how much text we really need here.
For example, there is a discussion of web cookies, but no discussion
of other tracking techniques such as finger printing. But then, there
is no way to provide an extensive list of such tracking methods, you
would need to write a book. The real point is that addresses allow
"chained tracking": tracker uses a cookie to link a newly appearing
address to an existing identity; the address now becomes a tracked
address; tracker now uses the tracked address to correlate activities.
Defeating that requires frequent address rotation. Maybe we should
say something about this requirement.

Section 2.2 discusses the use of the same address in multiple
contexts, when the same node is used as client and as server.
Then, there are p2p connections such as web RTC, which have
properties of clients or servers. The consequence there is the
need for multiple temporary addresses per host, so as to not need
sharing an address between multiple contexts. This leads to "one
address per service", or maybe "one address per container".

Do we really want to discuss that, or should we just keep the
motivation to a minimum, and concetrate on how to acquire
temporary addresses?

Typo "Peseudo-Random" in section 3.2.

I am not sure that we need to distinguish between generating
IID with a PRNG (section 3.2.1) and with a hash function
(section 3.2.2). At some level, the hash function is just
a different way to build a PNRG. In both cases, you get
a random string of bits, and then you have to use DAD and
test for uniqueness. But then, if my purpose is to use a
hash function as a PNRG, then hash(random secret, counter++)
would work just as well as the complex generation presented
in 3.2.1. My suggestion is to combine the two sections, and
present the hash as just an alternative way to obtain random
numbers, e.g. on devices that do not have access to a good
PRNG.

Section 3.3 discusses generation of temporary addresses.
The trigger event appears to be, learning a new prefix
in a new RA. That's fine, but that's not the only case:
another trigger could be, bringing up an application
that requires a separate address context.

Section 3.3 discusses the life time of addresses. There is
a related question of intermittent connectivity. Suppose
a node oscillates between two access points A and B.
Should it get a new set of addresses each time it goes
back to A, or just reuse the address it was using a few
seconds before? This relates to address life time, and to
connection strategies. It also has potential implications,
e.g. rogue RA triggering hosts to reuse an old address
in a new context and enabling tracking.

Section 4 describes the potential need for registration of
a PTR record for the temporary address. That seems really
counter productive. I wonder about the statement that
"Some servers refuse to grant access to clients for which no
DNS name exists." Isn't it the case that applications in
that category should just use the non-temporary address?
SMTP MTA for example may want to do that; I don't know
many other applications with that constraint.

-- Christian Huitema