[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: evaluation of draft-van-beijnum-multi6-odt-00.txt

On 9-jan-04, at 15:40, marcelo bagnulo wrote:

This with the address verification that you also use, would be similar to
the return routability procedure of MIPv6, right?

I'm not sure.

If there is no encryption of the actual data over an insecure link,
then I don't see how the data is sufficiently sensitive that the
redirection attack that is possible with clear-text keys is a show
stopper.

Well, if you consider mipv6 route optimization security design, current IP
provides an intermediate level of security, where traffic is not encrypted
but communications cannot be so easily redirected. I think this is the goal
for multihoming security: not to do worse than current ip security. I am
afraid that the security of this draft is worse than current ip security.

In theory, you're right. But in practice, things are different. I see three classes of traffic over insecure links:

1. Sensitive data that is encrypted using IPsec/SSL/SSH or what have you
2. Sensitive data that isn't encrypted
3. Non-sensitive data

1. already solves the PKI problem in some way or another. If we can find a way to tap in to that solution and use it to create session keys we have bullet proof redirection protection. So I think this situation is addressed.

2. is insane; trying to salvage anything here is useless.

So that leaves 3. An attacker can redirect traffic to another address for which he can see the traffic (so not to arbitrary addresses) which is a bad thing, but for the "real" client the effect is pretty much the same as when the attacker had sent a TCP RST: the real client doesn't see any data anymore. The fact that the dat is now delivered to the attacker isn't of great importance due to the non-sensitive nature of the data.

Put it in another way: the security of this solution would be similar than
using MIPv6 with inifinity BCE lifetime. MIP has an additional benefit that
it is already standarized and code is available, so why deploy a solution
tha has similar limitations?

But MIPv6 also has some huge disadvantages, for instance the 24 byte per packet overhead. We've already concluded that using MIPv6 for multihoming without any changes won't fly. If your point is that using MIP interactions is easier and no less effective and efficient than designing something new then that's certainly something we can explore, as long as we have a very clear picture of where we want to go. Just diving into MIPv6 with the idea that it can solve multihoming with some tweaks would be a very bad idea. The two facts that MIPv6 still isn't an RFC and that the draft is 172 pages speak for themselves.

Anyone any idea whether MIPv6 (with route optimization) can be implemented in a middlebox?