Re: Identifiers

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

[Catching up]

> Personally, I think the best choice would be to remain agnostic about 
> the identifier issue for now, but build our negotiation protocol such 
> that they can be added easily later. For now, we build a "no 
> identifier" type solution. Solving the problem of how a correspondent 
> proves ownership of an identifier can then be deferred until such time 
> that someone actually wants to extend the multi6 solution to support 
> identifiers. So the only thing we have to do now is make sure the 
> protocols are flexible enough to allow such extensions.

Thanks for bringing up this topic.
It definitely makes sense to think about it a bit.

I can see the feasibility of constructing a protocol which can carry
sets of locators and an identifier (which might be just the designated
locator the ULP is viewing as an identifier - what I called AID in some
drafts), with messages to change the set of locators over time.

What concerns me so far are two things: implications on the initial setup
and implications of different security mechanisms.

If a separate identifier is used this means that the initial setup must
appear before (or at the same time) as the first ULP packets are exchanged.
But if we just have a locator-agile mechanism without a new identifier space
it makes sense to allow a deferred exchange (and verification) of the locator
sets e.g. to avoid this cost when the connections are very short.
I don't have a good feeling for how complex it would be to design
a protocol which can do both immediate and deferred setup.

We've seen quite a range of security approaches proposed so far, and with
different approaches to prevent using the verification of the locators
as a new avenue for DoS attacks.
Will a scheme which introduces a new ID name space by necessity need
different security mechanisms? Will be immediate vs. deferred state
setup have implications on this?
Is there a common "message sequence" which can apply independently of
the actual security mechanism being used?
(The good news is that the notion of a lazy-evaluation of the locators
and ID->loc bindings seems to become common across the proposals. So perhaps
there is a common theme to be able to verify a peer locator before it is
used which might mean a more common "message sequence"?)

   Erik