Re: [Last-Call] Artart last call review of draft-ietf-v6ops-dhcp-pd-per-device-06

[Jen Linkova <[e-mail]>]

Oh dear, I shouldn't have been sending any emails before my first coffee..

On Mon, Feb 19, 2024 at 12:15 AM Jen Linkova <[e-mail]> wrote:
> > The biggest detected problem is with privacy, where the risk of tracking seems
> > to be underplayed, with the recommendation being a weak "client might consider
> > implementing a mechanism similar to RFC 8981". Given that a fixed prefix per
> > client is near certain to be tracked as soon as it's deployed, I think the
> > recommendation should be "SHOULD (MUST?) reallocate prefixes on the same
> > schedule as is deployed for RFC 8981 addresses".
>
> Thank you, I agree we should have documented it in more detail.
> The most important things to remember are:
> - exactly the same problem exists for DHCPv6 IA_NA today.
> - to track the client, the observer needs to know if the device has
> its own prefix or not.
>
> The host behaviour is out of scope, the document intentionally focused
> on recommendations for nework administrators on how to configure the
> network.
> So we have rewritten the Security Considerations (not submitted yet),
> and now it looks like that:

Indeed I meant Privacy Considerations, and the new text will be:

"If an eavesdropper or information collector is aware that a given
client is using the proposed mechanism, then they may be able to track
the client based on its prefix. The privacy implications of this are
equivalent to the privacy implications of networks using stateful
DHCPv6 address assignment: in both cases, the IPv6 addresses are
determined by the server, either because the server assigns a full
128-bit address in a shared prefix, or because the server determines
what prefix is delegated to the client. Administrators deploying the
proposed mechanism can use similar methods to mitigate the impact as
the ones used today in networks that use stateful DHCPv6 address
assignment.

Networks that use the proposed mechanism instead of SLAAC or in
addition to SLAAC, SHOULD minimally:

Ensure that when a client requests a prefix, the prefix is randomly
assigned and not allocated deterministically.
Use short prefix lifetimes, to ensure that when a client disconnects
and reconnects it gets a different prefix.

To provide privacy roughly equivalent to SLAAC with temporary
addresses ([RFC8981]), the network SHOULD allow the client to have two
prefixes at the same time. This allows the client to rotate prefixes
using a mechanism similar to temporary addresses but that operates on
prefixes instead of on individual addresses. The prefix's lifetimes
SHOULD be short enough to allow the client to use a reasonable
rotation interval without using too much address space. For example,
if every 24 hours the the client asks for a new prefix and stops
renewing the old prefix, and the Valid Lifetime of delegated prefixes
is one hour, then the client will consume two prefixes for one hour
out of 24 hours, and thus will on average consume just under 1.05
prefixes.
"

-- 
Cheers, Jen Linkova