[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Identifiers

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

Ok, basically you are proposing to use one of the available IP addresses as
the identifier used by ULP, and then eventually introduce a new namespace
for identifiers which may provide with enhanced features.

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

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. 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. 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. 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? 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
2. Introducing a new namespace would take much more time
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

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