Subject: Advantages and disadvantages of using CB64 type of identifiers

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 1 Jul 2004 12:25:01 +0200

Erik wrote:

> So we need to add that to the list of things to trade off.

i have tried to compile the advantages and disadvantages of cb64 type 
of ids

Advantages and disadvantages of using CB64 type of identifiers

Advantages:
- The AID is a routable address, so apps can handle them without 
modification
   - referrals and call backs
   - long lived sessions can recover when the state is lost in the 
multi6 layer
- It is possible to use the reverse DNS to discover alternative locators
- they are crypto in nature, so "strong" authentication is achieved

Disadvantages
- fixed 64 bit iid/prefix boundary
    - in particular the lower 64 bits cannot be used for subneting
- are 64 bits long enough defense against future hash collision attacks?
    - an attacker creates a public key with the same hash of the iid of 
the target
- source locator rewriting by edge routers is precluded
- changes in the prefix implies changes in the identifiers
   - so when the mh site changes isps it will need
     to renumber both its locators and its identifiers
- in order to be able to use the reverse dns to discover the full set 
of locators, the reverse dns tree has to be fully populated, which may 
be challenging in as hoc environments.

any others?

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 1 Jul 2004 15:08:14 -0700 (PDT)

>      to renumber both its locators and its identifiers

Hmm - this assumes that the IID is different for each prefix.

My understanding is that SeND chose different IIDs for different prefixes
but that might be overkill. If the IID is not a function of the prefix
it would enable redirection by a resourceful attacker
by precomputing 2^64 public/private keys that hash to all 2^64 IIDs.
If the content of the packets are encrypted the redirection would not
provide access to the content; it could only be used for DoS or for
gathering the content for cryptoanalysis.

A while back Jari Arkko computed the amount of space needed to store
2^64 precomputed keys, and the storage space was a few buildings the size
of the former world trade center buildings I think.

An organization which is willing to spend that much resources today on
redirecting packets can probably do it more efficiently by gaining access
to links within or between large ISPs.

So the question is whether we believe that the cost of the precomputation
and storage would drop so much over 20 years that this would become one
of the more attractive ways to DoS or gather data for cryptoanalysis.

   Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 2 Jul 2004 13:04:44 +0200

> Hmm - this assumes that the IID is different for each prefix.

or for the set of prefixes that are configured in the mh site. But 
bottom line is that when a prefix is added or removed, iids have to 
change.

> but that might be overkill.

that would be great news

>  If the IID is not a function of the prefix

i don't quite follow this...

i mean, if the iid is used by apps to provide some form of 
authentication/authorization, having a public key that matches with the 
iid may enable to impersonate the real owner of the iid, right?
and since the iids are crypto, one may assume that apps may want to use 
to authentication, i guess.
But this may depend on the details, i guess.

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 2 Jul 2004 07:02:58 -0700 (PDT)

> But this may depend on the details, i guess.

If the upper layers, the application itself, TLS, and IPsec,
*only* use the AID as the identifier (and not a certificate name with a PKI,
or a longer hash of the same public key that was used to generate the CGA)
then this would be a concern.

But I suspect that even opportunistic IPsec would rely on having e.g. the
full public keys in the DNS or something similar.

Hence hash collisions would only be useful for redirecting the encrypted
content.

   Erik