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

Re: cb64

Hi Iljitsch,

El 30/06/2004, a las 10:24, Iljitsch van Beijnum escribió:

On 29-jun-04, at 10:43, Erik Nordmark wrote:

But the protocol can still defer the public key operations until the first
locator change as far as I can tell.

But then this locator change wouldn't be protected by the key, so what's the point of having it? To provide proof that the third locator belongs to the same entity as the second locator?


We are considering cb64, which is some form of cga, so the iid of the locator is derived from a hash of the public key (and some other stuff)
So, when only a single locator is being used, you are essentially in the current single address situation so there is no need to add any security.
You need additional security when you add a new alternative locator.
As you mention, you need some way to prove that the new locator belongs to the owner of the initial address (which is being used as ULP identifier)
In order to do that, when you send the new locator, you send the public key (pk) and some form of signed string (in order to prove that you have the private key associated with pk)

So, the receiver verifies that the iid of the initial address matches with the hash of the public key, so you link pk with the ULP id.
Then by verifying that the signed string can be deciphered with the pk, you know that the new locator was added by the owner of the ULP id

Of course you still need to ping the locator in order to avoid flooding, but this is another story

I think it's essential to exchange _something_ that allows the other side to recognize its correspondent after a rehoming event before such a rehoming event happens (for the first time). Still, this doesn't have to be a very heavy-weight thing: transmitting some kind of hash would be enough, later this hash value can be used to authenticate a full key or hash chain.

yes, the hash is contained in the initial address, since it is a cga

A good way to do this is would probably be in an extension header or end-to-end option in one of the early packets (not in the first one because it will delay session establishment if a firewall rejects the packet with the option,

it is already contained in address field

regards, marcelo


and we don't want to create state before return routability is established to avoid being too easily DoSable).