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

[Fernando Gont <[e-mail]>]

Hello, Christian,

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

On 29/3/19 10:01, Christian Huitema wrote:
> 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.

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
> "quickly" reconnecting to the network that the node just left.

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"

?



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

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.



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

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



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

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?



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

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!



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

Indeed.


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

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?




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

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?




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

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


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

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492