RE: Security requirements for identification

[Erik Nordmark <Erik.Nordmark@sun.com>]

> > So I hope the above illustrates that there isn't an inherent requirement
> > from the multi6 problem set to make the identifiers globally
> > unique or stable.
> 
> Actually what you are really doing is to use fqdn as permanent identifiers
> and the DNS as a rendez-vous system, so it provides you with the transient
> identifier and also with the locator.

Yes.

> I mean, if you want to establish a communication with someone you already
> know, you need a mean to express his identity, and that is a permanent
> identifier.

Terminology issue alert. It is presumably sufficient to express a name
(and there can be a many to one mapping from name to identity.)

> (the other option that i could think of are limited lifetime identifiers
> that overlap in time so that you can provide one and obtain the next one,
> which will be valid for the next period)
> However i think that we could focus on the case that atr least for some
> hosts, a permanent identifier is needed, or put it in another way, we can
> provide differents types of identifiers, but one of these types should be a
> permentent one.

Agreed.
But what does permanence mean?
I think we would all agree that having it be stable across changing ISP
connectivity, whether due to multihoming or renumbering, is a useful
characteristic.
Is it also useful to have it be independent of your fqdn so that if you forgot
to pay the registration fees or there is a domain name dispute, you would
still retain your IP level identifier?


> > But I don't think it is until you also look at other problems, like
> > identifiers that can be used by applications for rendez-vous and referral,
> > that the stability issue comes to the forefront.
> 
> But you need initial rendez vous if you want to provide a multi-homing
> solution that works, so it is part of the multi-homing problem

Not so fast. If you want to understand the space of epehemeral identifiers
you need to dive a bit deeper.
In that space the identifier might not be needed before communication
is established, but can actually be exchanged as part of establishing
the communication between two hosts.
A concrete example would using FQDNs to find an (initial, possibly not all 
working) set of locators and then exchanging the identifiers of the
endpoints by the peers communicating.
(There are of course several issues in here, such as needing the know
the identifiers in order to get things like TCP initial state established,
but it is still useful to understand that emphemeral identifier corner of
the design space.)


> > Turning things around, one could ask what the benefits would be of having
> > an identifier which 1) doesn't change when you change ISP and 2) doesn't
> > change due to some administrative mistake (like not renewing your domain
> > name with the registrar).
> >
> 
> Agree, i can see many benefits in those cases, but are those features
> essential to a multi-homing solution? or are they just a nice-to-have
> feature? Would you inlcude them in the MUST list of a loc/id split solution
> for multi-homing?

I think it is part of the tradeoffs in this space.
Having them be independent of your ISP(s) is probably something many want,
so perhaps we must make that.
If it is realatively inexpensive (in terms of complexity, overhead, deployment
constraints, etc) to make it independent of some "registry infrastructure"
that would be a useful thing.

Another tradeoffs with high-level visibility are:
 - whether the ID can be used as the solve information to initiate
communication
   with the entity.
   (one can envision solutions where one can verify that a peer using a
   ID is in fact the same entity that used it a long time ago, without
   being able to use the identifier itself to find the location of the
   entity.)

  Erik