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

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