Allison Mankin <[EMAIL PROTECTED]> writes:
> To make it difficult to make educated guesses as to whether two
> different interface identifiers belong to the same node, the
> algorithm for generating alternate identifiers must include input
> that has an unpredictable component from the perspective of the
> outside entities that are collecting information. Picking identifiers
> from a pseudo-random sequence suffices, so long as the specific
> sequence cannot be determined by an outsider examining just the
> identifiers that appear in addresses or are otherwise readily
> available (e.g., a node's link-layer address).
>
> It's bad news if the node's link-layer address is "readily
> available" to arbitrary remote peers - the last parenthesis
> doesn't make sense in this draft about not embedding link-layer
> addresses in packet addresses....
If also non-anonymous adresses, based on the link-level address, are
used, som knowledge about the address are leaked.
For instance, consider a link with a few dozen nodes, each of them
having
(i) a globally unique addess, constructed as prefix + EUI-64,
(ii) link-level address, also based on the same EUI-64 id,
(iii) a bunch of anonymous addresses based on, say,
md5(EUI-64 + small counter), using the same prefix as the global
address
If you connect somewhere using an anonymous address, and the server
has a list of previously observed global addresses, the server can
lookup the global addresses that happened to match your prefix. Next,
the EUI-64 ids for the matching addresses are extracted, and a
reasonably small search will tell if any of those identifiers match
your anonymous address, and if so, which one.
There may also be other means of getting network-card addresses
(imagine a customer database listing the customers and serial numbers
of all purchased hardware).
Perhaps I'm missing something, but it seems wise to me not to assume
that link local addresses or network serial numbers and similar data
are secret.
You probably also don't want to assume that the "arbitrary remote
peer" isn't cooperating with other less arbitrary and more determined
peers.
/Niels
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
