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

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

On 12-jan-04, at 19:24, marcelo bagnulo wrote:

How does the ODT mechanism knows about existent connections? I mean, ODT is
a IP layer mechanism right, so it is not aware if there is a communication
or if packets are just echo requests. To be more precise, wouldn't a ping do
the trick?

Depends on the implementation, I guess. I think in a host implementation, the ODT state would be coupled with the transport state because there is overlap here (when to failover and so on). It would be possible to implement ODT without looking below IP at all, but that could have negative side effects. For instance, I believe it makes sense to leave ICMP alone and not tunnel it.


Note that the mapping state is passive in ODT: the attacker also has to
get the victim to failover from the regular address to the fake one.

Perhaps i am not understanding this correctly. what happens if the attacker
continues to send pings, from time to time with the source address set to C?

In other proposals the idea was to use the source address in incoming packets as a strong hint for the destination address in outgoing packets. Since ODT requires that all addresses be verified before use, such a hint isn't required so the attacker must come out as the best choice in the verification procedure. But during this verification procedure, the fact that the host sitting at the original address sends back errors should make this attack non-trivial.

The general question is how does the ODT end knows which is the actual
address that it has to use?

Send packets to all destination addresses (possibly from all source addresses, creating a "ping bomb" of significant size) and see what comes back and how soon.

It depends on whether the attacker can make the victim failover to the
negotiated backup addresses. This could be remedied by sending a probe
to the "real" address after a while and/or when a new session is
initiated. The real host will then send back an error since the state
referenced in the probe doesn't match its own state.

Yes, i porposed the same solution for mip :-)

Well it must be a good idea then. (-:

But Pekka N. didn't like it (as far as i remember), becuase the security of
the host is based on the fact that the error message is not filtered.
Considering the wide adoption of ICMP filtering this may be a a problem.

Ok. I had a very nice rebuttal here, namely that all ODT interactions (including errors) use the ODT extension header so this shouldn't be an issue. (Problems are of course possible when either all packets containing the ODT header or packets containing the ODT header but not any ULP are filtered.)

Unfortunately, this doesn't solve the problem, since the host that is impersonated may not implement ODT so error messsages aren't forthcoming.

I think this means that the only way to be secure is for all new sessions to use the "real" address for at least a few packets. This of course makes initiating new sessions after a failure problematic, especially in cases where the full set of remote addresses is no longer available, such as after a referral.

While it would be insane to defend the opposite, I think this is a trap
we should avoid falling into. The safety features that are appropriate
for an airplane aren't automatically justified in a car, or the other
way around. Let's focus on the level of protection that is appropriate
for what we're trying to build here, now and in the forseeable future,
regardless of whether a certain class of attack is possible with single
homed IP.

Just to clarify this, I am not claiming that we shouldn't provide additional
security if we can, but that we shouldn't provide less.

Redirection attacks at the IP level aren't possible in current IP. Any kind of rehoming allows for the possibility of redirection attacks. If we mandate that mobility/multihoming must not allow any new attacks, this means the countermeasures against these attacks must be bullet proof. I think this is raising the bar too high: if people are stupid enough to use insecure links without crypto AND enable protocols that break current expectations, they shouldn't be surprised if they see new attacks. Obviously such attacks shouldn't be possible when using reasonably secure links or IPsec.

In other words: we accept that we have to use plastic knives when eating our in-flight meals, but just because metal knives are unacceptable in airplanes, doesn't mean they shouldn't be available elsewhere.