Re: [Hipsec-rg] Some comments on draft-ahrenholz-hiprg-dht-01

From: Henderson, Thomas R <thomas.r.henderson(at)boeing.com>
Date: Thu Aug 09 2007 - 10:58:05 EDT

 

>
> > Maybe this draft should cover options 1-3 (or 1-2?) (with
> mention of the
> > other options), with the goal of using OpenDHT for
> interoperability and
> > easy deployment. I need to look at the drafts Philip referenced.
>
> I agree that there should be a separate draft on HIP-aware OpenDHT.
> Therefore, I'd include only options 1 and 2 in the current, "legacy"
> opendht draft and leave rest of the options for a separate draft.
>

I do not think it hurts to mention option 3 also because server side signature verification is transparent to clients. But I agree that doing more than that starts to affect interoperability with legacy OpenDHT servers and could be left for a separate draft.

Two other items I think are important to resolve are the technique to avoid all of the HITs from being stored on the same server due to the ORCHID prefix (this is mentioned in Jeff's draft but not really defined), and server robustness issues.

For the latter, I am imagining that there will be cases where a given host updating its own records, or an initiator trying to resolve the HIT of the peer host, cannot reach the particular DHT server responsible for the portion of the key space of interest. There are a couple of solutions that come to mind. First, implementations could use several well-known DHTs simultaneously (possibly some deployed by HIP research projects). An alternate approach for robustness within the same DHT might be to allow a host to store its records at well-known offsets to its primary key location (such as (key space)/2 away)-- since the DHT key size is larger than the HIT size, this is possible. The cost would be additional queries into the DHT in the case where the record simply doesn't exist in the DHT, and additional load per host on the DHT itself. It might be worthwhile to experiment with such a technique and see whether it is ever useful in the field (or whether DHT availability is good enough to obviate this), but to do so would require that the implementations agree to populate and search an alternate key location or alternate DHTs, and keep and share statistics on their experiences.

Tom

---

Hipsec-rg mailing list
Hipsec-rg@listserv.cybertrust.com
https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg Received on Thu Aug 9 10:58:34 2007