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

From: Christian Huitema <[email-masked]>
Date: Fri, 29 Mar 2019 10:01:37 +0100

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Mar 2019 12:44:13 +0100

Hello, Christian,

Thanks so much for your feedback! Comments in-line....

> generation as just an alternative PNRG.

This is how we intend it to be. Section 3.2 says:

3.2.  Generation of Randomized Interface Identifiers

   The following subsections specify some possible algorithms for
   generating temporary interface identifiers that comply with the
   requirements in [I-D.gont-6man-non-stable-iids].  The algorithm
   specified in Section 3.2.1 benefits from a Pseudo-Random Number
   Generator (PRNG) available on the system.  On the other hand, the
   algorithm specified in Section 3.2.2 allows for code reuse by nodes
   that implement [RFC7217].

Any changes we should apply here?

> 2) Discuss the temporary address life time 

You mean explain the tradeoffs between shorter vs longer lifetimes, or
something else?

> and what to do when

How about mentioning something along the lines of:

"A host may avoid the unnecessary regeneration of temporary addresses by
employing mechanism for detecting network attachment, such as DNA
[RFC6059]. An implementation may alternatively tie the generation of
temporary addresses to the underlying MAC address, such that when MAC
address randomization is employed, network-reattachments to the same
network only trigger temporary address regeneration if the underlying
MAC address has been regenerated"

?

> and that applications subject to address control should just use

Most of the discussion about DNS has to do with the common practice
employed in mailservers where the address of an incoming connection is
required to have a reverse mapping (a PTR record).

In that sense, I don't think the discussion can be simplified.

e.g., if you are on a mailserver, you'd need to disable temporary
addresses or somehow make sure that there's a reverse DNS record for
your temporary addresses -- otherways other servers might reject mail
from you.

> this would have to be done in a different draft.

Yes, I think this would be a good thing to discuss, but out of the scope
of this document.

> say something about this requirement.

Me, I'd probably remove as much text as possible, and include references
as needed. As you correctly note, the topic is quite big to cover
appropriately with anything more than just a small intro that points to
appropriate references.

Thoughts?

> motivation to a minimum, and concetrate on how to acquire

Me, I would keep the motivation to a minimum and concentrate on how to
acquire a temporary address -- and leave the options of "one address per
container" open.

As noted above, these would be nice to explore, but I think they are out
of the scope of *this* document.

> Typo "Peseudo-Random" in section 3.2.

Fixed. Thanks!

> a different way to build a PNRG. 

Indeed.

> In both cases, you get

For the most part, having the hash-based algorithm spelled out is useful
for two reasons:

* May be a hint to implementers that they can resuse the algorithm from
RFC7217
* May make it easy/evident how to tie temp address generation to other
events/properties, such as randomization of the underlying MAC address.

I will raise this one as a separate question to the working group.

Question, what you propose is to mention the hash-based approach, but
not with so many details? (.e.g, not elaborating on the arguments to the
hash function) Or something else?

> that requires a separate address context.

This, and the comment you made above about the discussion of lifetimes
would seem to warrant the incorporation of Section 5 of the document we
co-authored: https://tools.ietf.org/html/draft-gont-6man-non-stable-iids

Thoughts?

> in a new context and enabling tracking.

I'd say this should be implementation-dependent, and falls under:
   2.  The lifetime of an address MUST be further reduced when privacy-
       meaningful events (such as a node attaching to a new network)
       takes place.

of Section 5 of draft-gont-6man-non-stable-iids

> many other applications with that constraint.

There could be an argument for using temporary addresses in this case:
if you were to use temporary addresses, and your node did not allow
incoming connections on temporary address, then your node would not
necessarily become exposed just for relaying email -- i.e., the
temporary addresses, while known to the peer MTA, would be mostly
useless for attacking purposes.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492