Re: Identifiers

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 23-mrt-04, at 16:44, marcelo bagnulo wrote:

> > Thoughts?

> I am sorry, but i fail to understand what would be usage for such 
> protocol.
> I mean, until you provide the security features, we cannot deploy the
> protocol, since it would be unsafe to adopt it, so what's the point on
> having it defined?

Well a winter coat isn't much use in the summer but things change.  :-)

> Moreover, if you try to define a protocol that is general enough to 
> support
> all the different authentication mechanisms, i guess it will be more 
> complex
> that a protocol that actually relies on a defined mechanism.
> I agree that the issues right now w.r.t. preserving established
> communications is about choosing a security mechanism, so IMHO if we 
> want to
> provide a solution for this problem we will have to make our mind and 
> decide
> something on how to do this.

I agree, in order to build something that's usable we need to select 
one way of doing this, and standardize and implement this way of doing 
it. And a good way to do this would be taking working sessions and 
negotiate alternative addresses for them, without the use of an 
explicit identifier. However...

> But, perhaps i misunderstood your proposal?

What I'm saying is that even though it may not make sense to have full 
blown identifiers _today_, it's probably a good idea to recognize that 
we'll want to have them in the future, and make sure the actual 
multihoming protocol we're going to build now can be easily adapted to 
support identifiers. This means that there must be unused or option 
fields in the messages that can be used to extend the protocol in a 
backward compatible way. Another important issue is that when 
identifiers are used, all negotiation must precede the actual 
communication, so we should build our protocol that it allows this if 
at all possible.