about Wedgelayer 3.5 / Fat IP approaches

Hi,

Among the multiple approaches that have been included within the 
Wedgelayer 3.5 / Fat IP class, we can find very different mechanisms 
imho. I I think that additional discussion is needed to understand 
which one of the different approaches (not particular solution, but 
general approach) would better fulfill our needs. the goal of this 
message is then, to provide my opinion of some of the benefits and 
limitations of each approach in order to foster discussion of this 
topic.

So, as is see it the approaches included within the Wedgelayer 3.5 / 
Fat IP class use the following types of ULP identifiers:
- 128 bit long CBIDs (HIP, SIM)
- CGAs (cb64)
- Locators (i.e. the use a locators as the ULP id) (NOID, ODT)
- ephemeral ids (WIMP, MAST?)


Each approach use different mechanisms to prove identifier ownership:

- 128 CBID and CGAs use the crypto nature of the id to prove it
- When using locators as ids, there seems to me that there are two 
proposals:
       - a reachability test i.e. exchanging cookies . imho this 
approach is
         not good enough, since in order to prevent time shifted 
attacks, you
         need to exchange cookies periodically, which is opposed to the 
fault
         tolerance requirement
       - a third trusted party (i.e. the DNS) which informs about the 
locators
         assigned to and identifier, meaning that the endpoint that is 
reachable
         at the given locator(s) is the owner of the identifier
- when using ephemeral ids, the requirement to prove id ownership is 
weaker, and only a mechanism to verify that the same endpoint is at 
different locators is needed. This can be achieved using different 
crypto mechanisms and pbk and hash chains are proposed. However, only 
the initiator can use ephemeral ids, in the case of the receiver, a 
third trusted party (i.e. the dns) is used to link the id and the 
locator, so that the initiator knows that the endpoint reachable at 
these locators is the owner of the id


In addition different approaches use different mechanisms to verify 
that an endpoint is authorized to use a given locator:

- 128 CBID, CGAs use a reachability test i.e. verifying through a 
challenge response mechanism that the identifier owner is reachable at 
the claimed locator
- the locator approach use a third trusted party (i.e. the DNS) to 
discover which locators are bound to an identifier
- The ephemeral id approach uses both mechanisms described above

Each solution imposes different amount of additional cost to a 
communication. I  guess that the cost can be measured with respect to 
the following parameters: processing, overhead

- 128 CBID, CGAs and ephemeral ids impose different degree of crypto 
which requires processing by the end nodes. Locator based need no 
crypto so no additional cost is imposed. However, i kind of agree that 
it can be assumed that the required crypto operations will be performed 
rarely, so probably this cost is acceptable.

- All proposals require additional packet exchange and while i have not 
yet compiled the amount of packets required per each proposal, i kind 
of recall that most proposals impose more or less the same amount of 
additional packets (i really not sure about this, so i would really 
appreciate if someone could correct me here)


A tricky issue that has appeared repeatedly during last discussion 
would be the referrals and call back support

- 128 CBID and ephemeral ids approaches don't seem to provide a proper 
support for referrals and call backs, since is not possible to obtain 
an locator set from the id

- locator based and CGAs will use a "valid" locator as an id, so this 
locator can be used when making referrals. IMHO, this is as good as it 
is possible to get. I  mean, a mh capable node can pass a referral to a 
non mh capable node. In this case, the non mh capable node only can 
handle a single locator, so no need to have multiple ones (well, 
perhaps having one that certainly works could help). If the node that 
receives the referral is also mh capable, it can use a mapping service 
(like the reverse DNS) to obtain the rest of the locators. Both CGas 
and locator based approach could provide such support, i guess



Finally, imho an important aspect is the applicability scope of the 
proposed solution. imho approaches that introduce a new crypto based 
identifier namespace (128 CBID, cgas) have an applicability scope that 
is broader that just multihoming, since they can be used to support 
mobility, and imho they are providing useful tools to achieve a more 
secure internet. OTOH, the other solutions are basically focused on the 
multihoming problem and their applicability scope is limited to 
multihoming ( i can't see other aspects of the Internet that could be 
improved by the adoption of such solutions)


Regards, marcelo