HIP referrals (was Re: Some Comments on ID/Loc Separation Proposals)

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Margaret.Wasserman@nokia.com wrote:
> I have been analyzing a few of the proposal for ID/Loc separation
> (HIP, NOID and MAST) and I have some comments (attached).
...
> HIP Feedback
>
> Very well-developed proposal for end-to-end ID/Loc separation.
> No ID->Locator mapping mechanism, so no support for referrals.
>
> Specific Feedback:
>
>     - The lack of any ID->Locator mapping mechanism is a 
>       blocking problem for using HIP (as currently defined)
>       with anything but simple end-to-end applications.

The earlier versions of the HIP draft contained a mechanism
where a HIT would not be a 128 bit hash of the public key but
consist of a 64-bit, hierarchically assigned prefix and a
64-bit hash.  However, I removed this from the later versions
of drafts for the following reasons:

  - the proposed mechanism was tied to DNS, and we decided
    to move all DNS specific issues into a separate draft

  - we wanted to keep HIP as simple as possible, and having
    different types of HITs seemed unnecessary, especially
    when the mechanism was optioinal

  - ID->Locator mapping is not needed for simple end-to-end
    applications, and the majority of current applications do
    not need referrals

According to the current thinking, there are at least three
different options on how to support referrals in HIP:

  1. Re-introduce some structure to the HITs, and use a
     hierarchical lookup service (e.g. reverse DNS).

  2. Introduce a flat lookup service, e.g., based on DHTs.
     This looks like a researchy issue, which is likely
     to need more research before ready for engineering.

  3. Introduce a "social contract" to HIP where each HIP
     host acts as a temporary rendezvous point for all hosts
     that it has connections with.

While 3) is not a generic ID->locator mapping solution, it
looks like quite interesting anyway.  In particular, it seems
to be able to solve the common referral case where A has
connections with both B and C, and what to give B's ID to C so
that B and  C can start to communicate directly.

Here is a more specific example on how this might work:

   1. A opens a HIP association AB with B.
   2. A opens a HIP association AC with C.

   At this point A knows the locator sets for both B and C,
   but B and C know only the locator set of A.

   3. A sends B's ID to C.
   4. C tries to open a connection to B.

   At this point C has B's id, but it does not have B's locator
   set.  However, it has a HIP association with A, and therefore
   it may try to use A as a rendezvous server for B.

   [There are a number of open problems in the description above,
    I know.  But for the moment I'd like to focus only on the idea,
    hoping that the nasty details can be solved later.]

   4. C constructs an I1 packet and sents it to A, hoping that
      A knows where B is and will forward the packet to B.
   5. A receives the I1, and according to the "social contract"
      it passes the packet to B, whose locators it knows.
   6. B receives the I1, and replies directly back to C, thereby
      initiating the actual negotiation.

I don't think that it would be useful to define such an referral
mechanism quite yet, but it would certainly be interesting to
explore its limitations and implications (given the assumption
that it can be made to work in the first place).

--Pekka Nikander