Re: identity persistence and comparison issues

Iljitsch van Beijnum wrote:
> On 14 jun 2004, at 12:12, Joe Touch wrote:
> 
>>     a) are two IDs comparable within the same app over time?
>>         i.e., can an ID change? if so, can the old ID be used?
> 
> 
>>     b) can two IDs on different apps on the same node be compared?
> 
> 
>>     c) can two IDs on different nodes be compared?
> 
> 
> During the meeting there was some talk about per-session identifiers. 
> Wouldn't such identifiers be pretty much useless?

They're used in HIP, e.g.

> 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? 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".

The name of the endpoint (A) that you talk to isn't the same as the name 
used for forwarding (B), which may not be the same as any of the 
multiple endpoint addresses (C1...CN).

The one I'm referring to is B. A might be a DNS name or current 'well 
known' IP address used to bootstrap the communication.

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

A FQDN has always been mappable to multiple IP addresses. If two IP 
addresses are identical, it is still the case that they either point to 
the same host or something that emulates one 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.

When load balancers break the 'same host or equivalent' they can 'break 
the Internet' (e.g., arbitrary protocols can break).

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

A must be tied to a single host or something that emulates such, for the 
reasons above.

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

Changing A is like renumbering now; a slow, out-of-band operation that 
requires resynchronization (e.g., of the DNS). Changing B is more of an 
opportunity than a liability...

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFA0IXeE5f5cImnZrsRAoH4AJ4sWYZJlFWC2rtNd85cj9+YT/JGGgCcDyov
feKkgAZ+SgkZ5voD4988JOk=
=pGgx
-----END PGP SIGNATURE-----