Re: HIP and PKI reqs [RE: Identifier/locator recap]

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Mon, 17 Mar 2003, Pekka Nikander wrote:

> > The problem I see with HIP is that you can't initiate a session with
> > just the identifier to identify the host you want to communicate with.

> You are right.  More work is needed.  As I wrote, someone
> should work out the details how to utilize DHTs, perhaps
> in conjunction with DNS.  Or something similar.

As I said, I'm not up to speed with DHT but I can envision something
like this: the address space is spread out as a flat one-dimensional
space, where everyone who has a prefix points to a number of others
higher and lower (For instance, x + 1, x + 2, x + 4, x + 8 for higher
and so on). Then you can do something close to a binary search by
jumping up and down through the address space from server to server in
ever smaller jumps.

This could work extremely well except for one tiny problem: what if some
nodes don't cooperate and don't follow the protocol?

> > Now that would be fine if it were possible to feed this identifier to a
> > lookup engine and get back something you _can_ use to initiate a
> > session. But this isn't possible either.

> I would say that _currently_ such a mechanism does not exist.
> But I would *not* say that it is not _possible_.  The fact
> that such a solution does not currently exist does not make
> it impossible to create one.

This is essentially the same old problem: looking up entries in huge
piles of data that lacks a hierarchical structure simply doesn't scale.

Maybe this is already in there (I can't remember the latest HIP
identifier structure, but it's no longer 127 bits of fingerprint, AFAIK)
but just in case: why don't you shrink the fingerprint part to 64 or 80
bits. Then you can use the high 48 or 64 bits in a DNS-compatible
manner.

> > So effectively the HIP
> > identifier serves no identifying purpose.

> I couldn't understand that.  Could you please explain?

It's like pointing to something in a dark room. The action seems valid
but the result is disappointing.  :-)

With today's FQDNs and IP addresses there is a fairly simple
relationship: each can map to the other. With FQDNs, HIP identifiers and
locators this gets a bit complicated. I really think the FQDN is the
actual identifier here, not the HIP id. (But I don't think it serves
much of a purpose to duke this out.)

> > Note that I'm not anti-HIP. I'm sure there are problems that can be
> > solved by HIP. But it can't be a general solution for multihoming as it
> > only moves the problem to a different area.

> So you want me to come up with a completely worked out solution?

Could you?  :-)

> More seriously, personally I believe that HIP has large potential
> for end-host multi-homing.  Much more than the ID->locator
> mapping I see the crypto overhead (Diffie-Hellman) as a problem.
> There are also lots of other details to be worked out, with time.
> Furthermore, HIP is definitely not a solution for doing large site
> multi-homing, other solutions are needed for that.

Agree. HIP is good if you're on a single host and need the security. We
still need other stuff.