[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 17:13, marcelo bagnulo wrote:

The attacker could generate some malicious state in the victims machine so
that when the victim wants to initiate a communication will send the traffic
to the attacker. So now the attacker can impersonate the server and send
back modified answers for instance.

Ok. It took me a while to realize we're not talking about attacks that are possible because of insecure links anymore.

For example, you have a host A that is running ODP. The host is not
communicationg with anyone.

Supose now that there is a very well known server, that A usually connects
to, for instance a newspaper web page, that have address B.

Supose that there is an attacker that has an address C

Ok.

During an inactivity period, the Attacker initates the communication with A
and pretends to have address B

Hm, but in this case A must accept an incoming connection of some type. Also, the attacker must know A's address in the first place. This isn't as trivial in IPv6 as it is in IPv4.

(receiving packets containing keys sent from
A to B, the attacker can achieve that if he is in the same lan than A). Now
it generates some ODT state in A mapping the address B (of the server) to
its own address C.

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.

Considering that the state mapping B to C is indefinite,

By "indefinite" I don't mean "lasts forever", but rather that there isn't a fixed timeout. Obviously implementations will want to remove this state at some point, with a logical moment being shortly after the last session that matched the mapping entry has stopped. (I should probably explain this in the draft.)

However, this doesn't effect the possibility of an attack much as an attacker can simply keep the state fresh by sending packets from time to time.

[Aside: a similar attack is possible if the atacker is present on the victim's subnet: the attacker can advertise the address block of the server it wants to impersonate as on-link and then simply answer neighbor solicitations. Not even any sniffing capability necessary in this case.]

later on when the user of arrives and tries to contact B it will be actually sending packets to C.

Would this attack be possible with ODP?

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.

If the real address isn't reachable, then the attacking host still gets to play dice, but that's possible today too (in many cases): it can fake replies from the real host without having to worry about the real host getting in the way.

Or we could separate the state for outgoing sessions from the state for incoming sessions. But this leads to interesting conundrums when host X contacts Y and then Y sets up a new session back to X.

If so, don't you think this is security risk?

Sure.

My personal opinion about MIPv6 is that it is unsuitable for multihoming
support becuase the required modifications would introduce inacceptable
security risks as the one described above.
However, i folks think that those security risks are acceptable, i think it
would be interesting to consider it, because the available code and
implementations.

It's unfortunate that we haven't been able to get a dialog going with any mobility people because there is substantial overlap here, which can be very good (reuse of (semi-)existing stuff) or very bad (multihoming and mobility solutions getting in each other's way).

But for now, i would focus the discussion on which is the
desired level of security. IMHO a multihoming solution shouldn't introduce
new security issues to the internet that is it should be as secure as fixed
single homed ip

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.

Iljitsch