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

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

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

Well, actually the attacker could do the oposite.
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.

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

During an inactivity period, the Attacker initates the communication with A
and pretends to have address B (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.

Now the attacker leaves the place and goes to its usual address C, where he
waits

Considering that the state mapping B to C is indefinite, 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?
If so, don't you think this is security risk?

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

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

Regards, marcelo

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