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