Subject: cb64

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 28 Jun 2004 19:30:03 +0200

Hi Erik,

I have been re reading the cb64 draft, and i was wondering about the 
fact that the IID is independent of the prefix. This was discarded in 
SeND AFAIK in order to prevent dictionary attacks. Do you think that 
cb64 should adopt a similar protection against these attacks?
In this case, the iid would differ among locators, and probably it 
would be needed to change the id used. Perhaps the id could be the 
public key rather than its hash (as in hip)
I don't know how much this change would affect the defined protocol. In 
particular you would need to exchange the public key beforehand, which 
is not currently required. this would add overhead when no additional 
locator is needed, i am afraid.

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jun 2004 01:43:33 -0700 (PDT)

> cb64 should adopt a similar protection against these attacks?

If we decide to pursue this approach further, this should definitely be
looked at carefully.

> public key rather than its hash (as in hip)

ok. But this id would still be internal to the multihoming sublayer.

> locator is needed, i am afraid.

I don't see why one would need to pass the key earlier.
One would have to change how the context is identified on reception
from using the IID+flow label to only using the flow label
(which limits each host to 1 million contexts; unless we carry an explicit
larger contex tag in the packet as in SIM).

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

   Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Jun 2004 10:24:12 +0200

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

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. 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, and we don't want to 
create state before return routability is established to avoid being 
too easily DoSable).

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Jun 2004 11:02:29 +0200

Hi Iljitsch,

> 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

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jun 2004 07:36:25 -0700 (PDT)

> belongs to the same entity as the second locator?

In cb64 as it was written it accepts the first peer locator
(the one used to setup the state) on the faith of the return routability
check implicit in establishing the state. When there is a locator change
the peer have to prove itself using the CGA property i.e. public key crypto.

My point is that having different IIDs for the different prefixes
does not require a change to this way of doing things.

> a rehoming event happens (for the first time). 

Yes, which is why my email said that the context would need to be identified
at the receiver using only the flow label (compared to cb64 as written which
uses flow label + IID).

This *might* increase the desire to have something more than the 20 flow label
bits identify the context, which would push us into having an extension header
with a larger context tag. But I'm far from convinced this is required.

    Erik