RE: Feedback on draft-gont-6man-stable-privacy-addresses-01

[Christian Huitema <[e-mail]>]

I agree with Fred that we only need to specify "please somehow get a suitable 64 bit number."  There are a couple of requirements that have to be met -- or at least considered:

1) Uniqueness: the number must be unique within the scope of the subnet.
2) Non traceability: the number should be different for different subnet, so hosts cannot be readily traced as they move to different locations.
3) Privacy: the number should vary over time, to make it harder for Internet services to correlate sessions started by the same host.
4) Stability: the number should remain stable over time, so administrators can more easily manage which host is using what network service.

Of course, stability and privacy are contradictory, so there must be a way for arbitraging that. That's the big issue to be dealt with by the specification of privacy addresses, i.e. whatever successor we write for RFC 3484. The arbitration will be resolving about how often host generate addresses, how many addresses they generate, and under what circumstances do they use one or the other. Let's assume for now that we just want to generate addresses once per subnet.

In principle, there are two ways to meet the unique per subnet requirement: use a number that is guaranteed to be unique by design; or use a large random number that is unlikely to collide with an existing allocation. The problem of course is that random numbers will sometime collide. It may be a low probability event, but it will eventually happen. In fact, even the "unique by design" numbers like EUI64 can collide occasionally, if some management error occurred. That's why we do DAD. So, we have another requirement in the address allocation:

5) Retry: host must be able to detect potential collisions and retry, i.e. generate a different random number.

Fernando's algorithm has several advantages. It uses a hash of a pre-allocated random number, and thus mitigates the issue of weak random number generators in some hosts. It incorporates the subnet prefix, and thus meets the "non-traceability" requirement. But Fernando's algorithm has no provision for "retry", and thus misses a key requirement. So, instead of Fernando's specification, I suggest that we define the algorithm's input as:

   RID = F(Prefix, Modified_EUI64,  Network_ID, secret_key, salt) 

Where prefix , Modified_EUI64, network ID and secret key are defined as per Fernando's proposal, and "salt" is a long integer, typically set to the number of retries used to generate the 64 bit ID.

Of course, if we can support retries, we can also support privacy addresses -- the private address can be generated with just a gratuitous retry, a modified salt. In fact, with that formulation, we can be very close to the format defined in SEND (RFC 3972) -- just replace the "secret key" by the public key of the host. So we have a chance of unifying CGA, privacy addresses, and stable random addresses.

-- Christian Huitema