Re: identity persistence and comparison issues

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Iljitsch,

> During the meeting there was some talk about per-session identifiers. 
> Wouldn't such identifiers be pretty much useless?
>
> What I want from an identifier is be able to set up sessions towwards 
> it, the same way I can now with a FQDN or IP address. If this isn't 
> possible, what use are these identifiers?

As i see it, there are two ends involved in a communication, the 
initiator of the communication and the responder.

The responder of course has to have a stable id through which the 
initiator has to be capable to establish a communication with.

I mean, the responder needs a stable id that it is known by the 
initiator in order to make initial contact.

Now, the initiator may not need to have such a stable identifier, since 
the initiator does not receive communications. what the initiator needs 
is an identifier that is stable during the communication lifetime so, 
if the locator change, the identifier is maintained so it is the 
communication.

So there are different requirements imposed to the intitator's 
identifier and the responder's identifier

The responder's identifier has to be stable and known a priori so it 
can be used to make initial contact
The intitiator's identifier has to be preserved during the 
communication lifetime and does not need to be known a priori (in the 
general case)

Clearly and option would be to provide stable identifiers both to 
initiators and responders, but the issue here is that the security 
required  by a stable identifier is likely to be more expensive than 
the security required by a ephemeral identifier. SO why would you 
provide additional (costly) features when they are not needed?


>  In this situation an identifierless solution would be better. And if 
> there are ephemeral values that are used internally somewhere, we 
> should probably avoid calling them "identifiers".

Well, i usually make the difference between ephemeral ids vs. stable 
ids.
ephemeral ids are valid during a communication lifetime
stable ids are more long lived and can be used for initial contact

regards, marcelo

> In the good old days it would have been possible to presume that if 
> two FQDN or IP address values are identical, they point to the same 
> host. However, in these days of load balancers this is no longer true, 
> although it's usually safe to make this assumption in applications 
> because the different hosts would be providing the same service.
>
> In the design team # 1 we had some discussions on the FQDN <-> ID <-> 
> locator relationship and I think we agreed that the ID should be tied 
> to a single host, even if the FQDN is shared between more than one 
> host.
>
> Obviously it must be possible to change identifiers. This means it 
> must be possible to have more than one at the same time or operators 
> will revolt. Another reason to have more than one ID at one point in 
> time is for privacy reasons, this would be similar to RFC 3041.