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

[Fernando Gont <[e-mail]>]

Hello, Christian,

I've already applied some of your suggestions. But while going through
your feedback once again (to double-check), I had the following questions:


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.

You mean merging the two subsections? Changing the title of the
subsections? Something else?



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

What we have done so far is to say that you should regenerate the
addresses when attaching to a new (different) link. The details are left
rather unspecified -- although we do point to DNAv6 as a hint on how to
detect a different link.

Quick reconnection to the same link, as per the current spec, should not
cause changes.



> 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 most likely agree with you. Although one could also envision an
SMTP MTA that employs temporary addresses when relaying email.



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

I agree in that I'd like this to be discussed, and also that it should
be discussed 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.

You mean about this example, or about the reuse of an address in
different contexts?



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

I think this is stuff worth exploring, but that should be left for a
separate document. Once you start exploring it, you probably also need
to think about an API, and other details -- all of which would be really
out of the scope of this rfc4941bis which we're working on to address
flaws/shortcomings in rfc4941/implementations.


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

Point taken. WIll do.



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

My take is that 4941bis will address the default case where you have one
temp address per prefix. For cases such as the one you describe, much
more work is needed. e.g., APIs and associated semantics for requesting
a new address, removing the address, etc.




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

I think in that case, the appropriate thing is to generate a new one.

i.e., there's a difference between link down/up events (which should not
regenerate addresses), and roaming across networks (which, no matter how
fast you do it, should lead to new addresses)




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

Well, an MTA *might* want to use temporary addresses for relaying mail.
I'm not saying this does happen nowadays, but I see the value in it.

Thanks!

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