RE: Security requirements for identification

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

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

Yep.

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

From the perspective of handling at least a narrow interpretation of
multi6 I think this is enough.
But it doesn't make the identifiers first class objects in the architecture;
it would be impossible to use them as the sole handle for referrals and 
perhaps also for rendez-vous (in Keith's definition of that term; "call me back
when you are done")

I think this means that we can use it to make transport protocols
and simple applications protocols unaware of multihoming, but richer
application protocols would need something else. Whether that means passing
around a list of locators to represent a peer, or do use a fqdn to designate
a peer (which requires work to avoid confusing with fqdns which designate
a service), or something else I don't know.

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

The FQDN could be viewed as an identifier for the service i.e.
consistent with current usage of fqdns.
You'd exchange the ephemeral identifier with a peer node thus you'd
presumably get an ID for that node (a stack name), and not an ID
for the service.
You would need to find out which of the locators refer to that identity
so that you don't try to redirect the traffic to go to a different node.
Perhaps that could also be exchanged as part of the handshake that exchanges
the emphemeral ids.

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

If it was "free" I think the more general problem would be the right one.
But designing and deploying a system capable of looking up identifiers
(with desirable properties; they would be flat or near-flat ids I think)
is clearly something which will take time.
In practice I think we need to figure out something which can be
incrementally deployed providing incremental multihoming benefits along the
way. If we can do this and maintain the ability add the lookup system
along the way it the lookup system wouldn't be a gating factor for deployment
of a solution to the multi6 connection rehoming problem.

   Erik