[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


El 09/07/2004, a las 17:56, Erik Nordmark escribió:

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.


Question: wouldn't this application also break when RFC3041 addresses are used? in particular when a new temporary address is used

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

ok, but in order to support RFC3041 addresses the host would need to dynamically update the DNS (creating a new record for its new temporary addresses), right? this would imply that multihomed hosts will need to support Dyn DNs or something similar right?

regards, marcelo


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