Re: Interoperability on RR BU Security?

> => I have a concern with your question: it suggests there can be only two
> BU security techniques...

I think the question is more general, but occurs as soon as there are two
ways of doing something. Perhaps its not so critical in this case, but I
think it needs some thought now, in case a general negotiation mechanism is
required later.

> About the answer, with preconfig keys or IPsec, they are established
before
> the route optimization itself so the choice is clear (and BTW there cannot
> be a bidding down attack too). But the question is still open for other
> techniques so we can ask an answer for any other proposal?
>

So does the MN have a list of IP addresses with which it can do preconfig
keys? Is there some kind of API used to insert these addresses into the
Mobile IP code if a key is negotiated? It seems like there's an assumption
here that the MN has some kind of knowledge ahead of time that comes from
some unspecified source. I have a hard time understanding how this could
work in general.

In other protocols where both peers have a choice about how to perform some
kind of security operation, there are (sometimes elaborate) negotation
protocols to determine which choice to use. And, if down the line (doesn't
have to be right now), the WG has some interest or intention of approving
other, perhaps radically improved RO security mechanisms, I believe it would
be wise to consider the interoperability issue now when we are about to
approve a second, before we end up with a collection of RO security
mechanisms and no way to decide which one to use in any particular case. Or,
even worse, a collection of incompatible negotiation mechanisms.

As another data point, we decided in SEND to standardize just one
cryptosuite, RSA. We got some mildly negative IESG comment back about this,
but in the case of SEND, the interoperability issue is pretty critical, and
any kind of negotation would be really needless overhead on a fairly low
level operation which, while not done often, is performance critical when
done. If at some point there's problems with RSA, SEND would have to be
revised and a new technique standardized, with RSA becoming like the current
insecure ND, but that's OK because all evidence points to RSA being
sufficient for the indefinite future (with a mild concern about key length
growth as attacker processor power grows).

The RO security case isn't quite the same, because we already know that RR
isn't quite as secure as we would like and its performance isn't quite as
good as we would like, but if we are going to standardize another method,
even preconfig keys, the I think we need to think about interoperability.

'Nuff said.

                   jak