Re: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers

[Erik Nordmark <Erik.Nordmark@sun.com>]

> Now, imho, this goals don't impose that we have to have different 
> identities for different interfaces, but that we need different 
> identities for different communications.
> The problem as usual, is how the wedge layer can find out which packets 
> belong to which communication.

That part is hard; mapping the communicating to the privacy requirements.

But it is also hard for the wedge leayer to know the beginning and end
of a session, which is also needed. For instance, an application session
might silently assume that multiple TCP connections (to the same peer, or
even to different peers) use the same IP address today to represent the host.
As a result, if such an application isn't modified for multihoming somehow,
it would assume that the same AID (application-visible identifier) is
representing the host for that set of connections.

But at the same time one might want to have different sessions (where
there isn't a need to present the same identifier to the peer)
explicitly use different identifiers for privacy reasons.

One can definitely create APIs by which the applications can express both
the privacy requirements for communication, and the set of communication
that must use the same identifier for the host.
But if we do that then the question is what the default settings should
be for (unmodified) applications which do not express anything using those
APIs.
Should we err on the side of privacy? Should we err on the side of
making as many unmodified applications as possible work by using the
same identifier all the time by default?

> Now, just to mix things a bit more, how would a solution like NOID 
> support the privacy requirements? Are the DNS times compatible with 
> this requirement?

draft-nordmark-multi6-noid-02 (which I submitted on Wed so it should be
in the I-D directory any day now) talks a bit more about this.
Briefly:
For a host to take advantage of itself (or its site) being multihomed
for rehoming, the host needs to have a FQDN and consistent forward and reverse
information for itself in the DNS.

For such a host to have multiple pseudonyms, this implies having multiple
FQDNs. (Such as host-2002-8192-56bb-9258-0-0-8192-5882.example.com i.e.
the FQDN doesn't have to provide any mnemonic meaning to a user.)

If the host doesn't need to take advantage of itself being multihomed,
but uses NOID to take advantage of the peer/server being multihomed,
then it doesn't need a FQDN. Hence it can have pseudonyms just using 
RFC 3041 temporary addresses.)

  Erik