RE: Security requirements for identification

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

Hi Erik,

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

Good point.
I guess that we can try to be a bit more precise about this:

As you mention, there are multiple times that i don't really need to know
the identifier of the end-point that i want to communicate to, but what i
want is the identifier of the service that i want to contact (is this what
you meant?)

So in this case, the fqdn act as a service identifier. So if i have a
permanent service identifier (i.e. a fqdn), it is enough to have ephemeral
end-points identifier, since when i want to establish a communication with a
given service i just look for the currently valid ephermeral endpoint
identifier.

The next question then is whether this is enough... I mean can we just live
with ephemeral endpoint identifiers and stable service identifiers?

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

Not so sure, i mean, you are using the fqdn to make the initial contact, so
the fqdn is an permanent identifier. You can consider that the fqdn is a
service identifier. Ok, then when contact the other end through the locators
that you have obtained through the DNS, you will exchange a ephemeral
identifier, but this ephemeral identifier is a *service* ephemeral
identifier, isn't it? i mean you know that a service is at given location
and then you exchange an identifier to be sure that you always talk to the
same entity, this would be a service identifier, i guess.

So the point is, you can use a fqdn as a service or endpoint stable
identifier and then exchange service or endpoint ephemeral identifiers, but
you always need the stable identifier to make initial contact, so you can
express who do you want to talk to.

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

Been re-reading JNC's Endpoints and Endpoint's Names where there is a great
compilation of many relevant characteristics of the endpoint identifer,
where most of these are included somehow, and the point is that there are
many aspects to consider.

So my question is whether we should focus on providing a multi-homing
solution based on the loc/id split or we should design a loc/id split that
covers as many as possible of the apsects related with the overloaded model
of identifiers in current IP, such as the ones that you mention or the ones
covered in JNC's paper.
Clearly the second option seems the wise thing to do, but there are many
operational issues here, such the time requiered for this (during this time
we will not provide a multi-homing solution which seems to be a pressing
issue right now), the appropriate forum for this (not only because of the
formal issues related to this, but more because of the people that should be
involved and whose opinions are relevant for this, may not be here).
So perhaps the practical thing to do is to provide a multi-homing solution
now, focusing only on multi-homing problems.

Regards, marcelo

>
>   Erik
>