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

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> > 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.

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?

> Also, the attacker must know A's address in the first place. This isn't
> as trivial in IPv6 as it is in IPv4.

ok.

>
> > (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.
>

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?

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

> > 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.

Yes.

>
> [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.]
>

yes (but this is a problem for the send guys)
BEsides, the problem here is that the attacker may leave the subnet and
continue with the attack. This is aproblem because it is probably easier to
access to a physical media for a short time of period than staying there for
a while.

> > 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.
>

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

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.
Then i proposed that the state is renewed if when the client send a state
refresh request, the client obtains an ICMP unreachable message as reply ,
meaning that the path is down (so there is no attack going on). The problem
here is that the fault tolerance of your solution depends on ICMP messages,
which i didn't really liked. But if you accept that the security or the
fault tolerance of the solution depends on periodic exchange of signaling
messages, this could work.

Also keep in mind that there are other attacks that may also be interesting
to consider like stealing an unused IP address from a certain subnet. (i
don't know if this is important)

> 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.
>

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.

> Iljitsch
>