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 <furry13@xxxxxxxxx> 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
