RE: Persistent or opportunistic IDs

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Geoff,

thanks for the clarification.
some comments below...


> My comments in the RIPE meeting were drawn from the text I used
> in Section 4.7 of draft-huston-multi6-architectures-00.txt, In particular
> the last paragraph of that section.
>
> I was struck by the difference between 'absolute' uniqueness (and the
> implication
> that when you have such absolute uniqueness you also can support
> persistence
> and reference and resolution) and relative uniqueness (where the identity
> uniqueness is constrained temporally to the lifetime of a session
> (olr group
> of sessions) and constrained in terms of a spatial realm, where
> the possibility
> of identity collision  is admitted in a broader context). This
> classification also
> has some implications regarding the cost of uniqueness and the
> relative level
> of overhead in managing a long-lived unique token space and opportunistic
> (probably
> self-generated) identity token values.
>
> I'm not sure I'm truly in a position to offer comment from my perspective
> as to which is
> 'better' than the other - there are aspects of value in persistence,
> resolveability and
> referential capability in structured unique identity spaces, and
> there are
> aspects of
> value in terms of overhead and efficiency in terms of protocol behaviour
> and dependencies as well as reduced dependence on infrastructure
> activities
> that
> paint a value picture for opportunistic identity spaces.

Ok. In previous discussions i think we use to use the terms ephemeral
identifiers versus stable identifiers to make that distinction.
Most of the proposals use some sort of stable identifiers that can be placed
in the DNS or some other directory.
I guess that one of the difficulties when using ephemeral identifiers is
that since they are ephemeral by nature, the initiating host does not know
the identifier of the other end a priori, so how do the apps use to initiate
the communication?
I mean, suppose that an app wants to communicate with another node, so it
decides to start a communication. If stable identifiers are available, the
app will open a socket (or equivalent) with the stable identifier and
somewhere lower in the stack a conversion from identifier to locator is
done.
However, if ephemeral identifiers are used, the initiating node does not
know which is the identifier to be used until the other node is contacted.
This means, that for instance, when the app asks the resolver for a FQDN,
the resolver would need to contact the other end, negotiate an ephemeral
identifier and the present it to the application, so it can start the
communication. This is indeed more complex than using stable identifiers.
However, the cool thing about ephemeral identifiers IMHO, is that you don't
have to protect them so much as you do with stable identifiers. I mean, if a
ephemeral identifier is stolen, it will only affect a limited group of
communications of that host. OTOH if a stable identifier is stolen, the
complete identity of the host is stolen. So a solution with ephemeral
identifiers probably will require less security measures than one with
stable identifiers, perhaps something like return routability would be
enough for ephemeral ids?
In any case, i am not aware of any proposal that explain in detail how
ephemeral identifiers could be used, so I guess that Brian comments apply
also here, we would need a proof of concept for this too.

An interesting middle ground is provided by WIMP, because if i understand
correctly, they use a stable identifier of the target host (the hash of the
FQDN) but they use an ephemeral identifier for the initiating host. In this
case the endpoint has multiple ephemeral identifiers and a well known stable
identifier for incoming communications.


>
> My suspicion that we will need to come to some closure at some point as to
> where the ideal point might lie in the context of multi6, and in the
> context of
> an evolving IPv6 architecture, but its way to early to call the
> question -- in my view. At this stage its still the careful work of
> attempting to
> assemble useful characteristics here, so the essential question I
> have, as
> the draft
> author, is where the draft needs further (or less) consideration and text.

I guess that this depends on how much do you want to include about security
considerations in this draft. I mean, there is no mention to crypto based
identifiers in the draft, which is an important identifier name space. But,
if you include this you probably will have to mention something about
security, i guess.
The same goes for security implications of using ephemeral identifiers, as
IMHO one of the benefits of using ephemeral ids is about security, as
described above.

Regards, marcelo

>
> thanks,
>
>     Geoff
>
>
>
>