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

[Fernando Gont <[e-mail]>]

On 04/15/2012 01:20 AM, Christian Huitema wrote:
> 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.

If this is about a fixup for RFC4291 (kind of orthogonal to
draft-gont-6man-stable-privacy-addresses), then I'd argue that the only
requirement to be specified is that of uniqueness. If anything,
different algorithms would make trade-offs among aspects #1-4.



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

I think that the issue of how many addresses you generate is depending
of the addrsel policy. Gnerating addresses is "step 1". Address
selection (step #2) deals with selecting from the addresses generated in
the pervious step.



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

While in theory this is correct, in practice it isn't: Think about
virtual machines: most implementations use a fixed OUI, and randmize the
Ethernet address from there. Which means that you could have the SLAAC
addresses of two different VMs collide, even if they are supposedley
being generated with globally-unique identifiers.


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

The question here is whether this is something that should be dealt with
in each specific algorithm (e.g.,
draft-gont-6man-stable-privacy-addresses-01), or this is something that
should be algorithm-agnostic.

For example, the specification for the generation of tradicional MAC
addresses does not deal with this issue in detail -- and in practice,
implementations do not try a different address when DAD fails.

As noted to Karl in this thread, I'd probably deal with the potential
address collisions (i.e., DAD failures) within the algorithm, Just add a
one-byte or two-byte counter to the hash, that e.g. is initialized to 0,
and incremented each time DAD fails.


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

This could be trivially added as noted above (for instance, I asked
others to weigh in :-) ).

There's also the issue fo whether even in the presence of Ethernet, one
should include the Modified-EUI-64 as a paramenter to the hash function,
or whether one should rather use the interface index: in that case, we'd
gain an additiona benefit -- even for Ethernet, you could replace the
NIC, and the resulting address wouldn't change.

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