RE: Identifiers

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

> Yes. (Another way to look at the first part would be not having
> identifiers at all.)

Well, i subscribe more to Jari's view, where in this case one of the IP
addresses is the id, but never mind, i guess we understand what we are
talking about.

>
> > The question now is how do you provide security for this negotiation of
> > alternative addresses in this first stage?
>
> Since we have return routability there is no need to prove ownership of
> the first IP address.

I am afraid not. If there any value in the exercise of trying to use MIP for
multihoming, is that you can clearly understand the limitations of the
return routability check for the multihoming case.
Return routability procedure has an inherent problem when it is applied to
the multihoming scenario. the problem is that in multihoming, at a given
moment, the address is no longer reachable, so it is difficult to
distinguish an outage from and attack.
I mean, you the verification with RR is that you get there, but when an
outage occurs, by definition you can't get there, so RR seems a poor choice
when you will have to deal with outages.
Some patches can be made, as we have discussed with you regarding ODT, but i
am afraid that you end up with a fragile solution or with a not very secure
solution.

Please, note that when using RR it is not enough to verify the initial
address only at the beginning, you need to verify it periodically, if not,
you are susceptible to time shifted attacks

> Additional IP addresses can be checked against
> information provided over the first one, so we can be sure that all of
> them are used by the same host. However, a man in the middle between
> one end and the original address of the other hand can subvert this
> process in the absense of some kind of out of band security
> information.

Yes, i don't think that securing from MitM attacks is a requirement.

> My answer to this problem is that there is no need to
> create such an out of band system (storing info in the DNS, PKI,
> whatever), as long as we can make use of such a system when it's
> present.
>
> I think this makes sense because if you don't bother to use IPsec or
> TLS for a session, then the communication is subject to all kinds of
> nastiness from a man in the middle anyway, so protecting against
> session stealing isn't worth the trouble.

This is where i don't agree. I think we shouldn't do things worse than what
they already are (or at least not too much worse)

> On the other hand, if the
> communication is sensitive there will be IPsec/TLS anyway so having
> something in that case is redundant. We just need to make sure we can
> leverage the security information present in those protocols to secure
> our multihoming negotiations.
>
> > Well, whichever solution we adopt to preserve established
> > communication, i
> > guess that we have consensus that it will imply the upgrading of all
> > the
> > hosts, inside and outside the multihomed site to support it (modulo
> > proxies).
>
> Do you see any alternatives?

No,no.
I was just highlighting one of the few points where i think we have
cancerous.

> I believe geographic aggregation could be
> one, but I'm pretty much alone in that regard.
>
> > So, if we agree that a new id namespace provides value and that should
> > be
> > the final solution, why don't we just go for it and we require only one
> > upgrade to all the hosts in the Internet? (Actually this was your
> > argument a
> > while ago, i am just quoting it because i found it very valuable :-)
>
> Good point. But I can think of three reasons not to:
>
> 1. Without a new namespace we can make sessions compatible with
> existing TCP as long as no rehoming events are necessary

Well, i guess that if the other end is upgraded it doesn't matter, and if it
is not, the only option is to fall back to regular IP and not use the new
ids.

> 2. Introducing a new namespace would take much more time

Why? I guess that if the id is managed, perhaps, but there are other options

> 3. We don't know yet what kind of namespace we want, or even how many,
> so we probably need to keep our options open for adding even more
> anyway

Well, as is said, IMHO this is the problem that we should solve, and we
should make a decision on this.

Regards, marcelo

>
> I'm not claiming these arguments are definitive, however. One reason to
> create a new namespace would be that it should make referencing and
> then connecting to the entity referred much easier.
>
> Iljitsch
>
>