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

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

> Ok, simple scenario: an ODT-enabled host opens a TCP session towards a
> host it hasn't communicated with recently. The first TCP SYN packet
> then gets an ODT header that has two functions:
>
> 1. Signal to the other side that we support ODT
> 2. Set up a shared secret that can be used to authenticate subsequent
> packets

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

[....]

> > Then you say that this key can be protected using IPsec, but in this
> > case
> > how is the IPSec SA established between two generic nodes on the
> > internet
> > (where no previous interaction can be assumed)
>
> Add PKI and stir.  :-)
>
> I'm not really joking, though. If the communication is sensitive, some
> kind of encryption must be used, so on some level this problem must
> have been solved anyway. That's why I want to see if we can do some
> layer violating and use SSL/TLS (maybe even SSH?) state to get ODT keys
> across in a more secure manner.
>
> 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.

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?

Regards, marcelo

>