Re: Identifiers

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 24-mrt-04, at 17:39, marcelo bagnulo wrote:

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

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

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

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

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

Being able to just start a session and then negotiate additional 
addresses later is a plus here. 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.)

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

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

Iljitsch