RE: Identifiers

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

> > 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.
>
> Obviously the first phase of the negotiation (where we do RR for the
> initial address) must be complete before surviving an outage is
> possible.

Agree

>
> > 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
>
> I don't see why this would be necessary.

Please see my reply to Brian about time shifted attacks an other similar
attacks.

>
> >> 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)
>
> Someone who can intercept your communication with Google can already
> reset the TCP session so you don't get to see your search results. Why
> would the capability to redirect those search results to another IP
> address be much worse than this?

well, this would be something like a DoS attack. i think that thinking that
you are communicating with google but in fact being in communication with
another malicious party is worse than DoS.
Some will claim that you can already do this by intercepting DNS queries,
but the point is that this sort of issues are being worked on, so we better
off if we don't add vulnerabilities, i guess.

>
> >> 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.
>
> You make it sound so easy.  :-)

Sorry, i didn't wanted to sound as if i was over simplifying the issue that
you were cosnidering, it is just that i didn't understand it properly.

>  The tricky part here is to make sure
> that communication between an upgraded host and a non upgraded host
> always works as before, while communication between two upgraded hosts
> uses the new capabilities. This makes it necessary to add some magic to
> determine the capabilities of the remote host, preferably without
> incurring any delays.

Agree.
How does the current proposals deal with this?
I guess that you can carry the new id in an extension header (optional
destiantion option for instance) and if the host is upgraded it will process
it and if not will just discard it and use the IP address.
The cost of this is the bit of the extension header in the first packet

>
> Being able to just start a session and then negotiate additional
> addresses later is a plus here.

I fully agree with this, but for other reasons, i guess.
I think this is a plus basically because you can avoid the additional cost
of negotiating and validating additional locators when you will not need
them, i think this was called delayed setup.
this is good for upgraded hosts.

> But we might be able to this by
> creating identifiers but allow the identifier space to overlap with the
> locator space. For instance, 2001:345::678 could be such a new
> identifier. Legacy hosts would simply put this value in the destination
> address. But upgraded host would execute some TBD id->loc mapping
> function and receive a set of locators. A further refinement would be
> for an upgraded host to first try to connect to the address directly in
> a backward compatible way and then negotiate additional addresses as
> per NOID/DHT. Only when this fails the id->loc database is consulted.
> (The id->loc database could also aid in securing the negotiation.)

This will depend on the nature of the id space that you use. Some
identifiers name space cannot be delegated in blocks like addresses (for
instance CBIDs)

>
> >> 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
>
> Because it's more work.

I mean, which is the additional work related to the namespace when you are
using a self generated statically unique CBID?


>
> >> 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.
>
> So what kind of identifiers would you like to see?

I think that CBIDs provide value to the architecture and enable clean
solutions for multiple problems.
I also think that any solution for preserving established communication will
imply the modification of all the hosts.
So if the solution requires such a high cost, it would be good to take the
most out of it.
I mean, i would rather add a functionality in all the hosts that is useful
in a general way, not just a patch to solve this particular problem.

Regards, marcelo


>
> Iljitsch
>