[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 23-mrt-04, at 16:44, marcelo bagnulo wrote:
I am sorry, but i fail to understand what would be usage for such
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
all the different authentication mechanisms, i guess it will be more
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
provide a solution for this problem we will have to make our mind and
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.