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

[Christian Huitema <[e-mail]>]

On 3/29/2019 4:44 AM, Fernando Gont wrote:
> 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?

Sorry for not responding sooner -- busy time after coming back from Prague.

My personal preference would be to replace the entirety of 3.2 content,
including 3.2.1 and 3.2.2 by a much shorter text. Something like:

When a host needs to configure a randomized interface identifier, it
SHOULD obtain the required number of bits from a Pseudo-Random Number
Generator (PRNG) that meets the randomness requirements for security
expressed in [RFC4086]. If no adequate PNRG is available on the system,
the host MAY use a modified version of the algorithm specified in
[RFC7217], augmented to include in the hash input
a time and a counter that will guarantee different results at each
instantiation.


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

Generally, I would stick to the definition that a randomized IID is just
a random number, and not try to imply any structure or any generation
algorithm. It is OK to remember the time at which the address was
generated, and check whether the new network is the same as one that was
seen a short time ago: same network identity per DNA, same MAC address,
same prefix. In that case, hosts MAY choose to keep using the previously
generated address instead of creating a new one.

Clearly, this is just an optimization, so there should be a clear MAY.
There are also privacy risks in doing that, so there may be room for a
MUST statement, as in "don't do that if you are not really sure it is
the same network".

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

How about stating that servers that require a reverse mapping SHOULD NOT
use randomized addresses, or rather that this is completely out of scope?



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

I would probably just remove section 2, background, as it is very much
redundant with the problem statement.

I would also remove section 6, future work, as it is not needed by
implementers.

Shorter is better. Implementers are just going to read section 3 anyhow,
and ignore any superfluous text.


>
>
>
>> 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?
See proposal above.
>
>
>
>
>> 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?

Don't add more text. Te goal should be to tell simple messages:

1) One random address per node per prefix, and the IID is a random umber.

2) Generate a new random address when seeing a new prefix, or when
connecting to a new network.

3) Manage a lifetime that is short enough to provide privacy.

Everything else is superfluous.

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

As I said, if applications have such requirements, they should use a
stable address instead of a randomized one. I would declare the PTR
scenario out of scope, the general rule being that temporary addresses
don't need a PTR record. If systems insist on creating one, it should
link to a randomly generated name so as to not break privacy requirements.

-- Christian Huitema