[Hipsec-rg] Issues in draft-ahrenholz-hiprg-dht-02.txt

bortzmeyer at nic.fr (Stephane Bortzmeyer) Mon, 21 January 2008 14:41 UTC

From: "bortzmeyer at nic.fr"
Date: Mon, 21 Jan 2008 15:41:29 +0100
Subject: [Hipsec-rg] Issues in draft-ahrenholz-hiprg-dht-02.txt
Message-ID: <20080121144129.GA10508@nic.fr>

[There is no address in the Internet-Draft for the
discussion. Therefore, I copy the HIP research group - but I'm not a
member - and the OpenDHT mailing list, where I am subscribed.]

The "HIP DHT Interface" Internet-Draft
(http://tools.ietf.org/html/draft-ahrenholz-hiprg-dht, I checked with
version 02) raises two issues for me.

One is the TTL. The Internet-Draft says things like "The ttl_sec field
used with address publish includes the time-to- live, the number of
seconds for which the entry will be stored by the DHT" or "The
name-to-HIT binding needs to be refreshed periodically before the TTL
expires" which seem to assume that OpenDHT will keep the value for the
duration of the TTL. Although it does not seem documented, I fear that
OpenDHT is free to remove the data *before* the TTL expires, if it
runs out of resources and that the TTL field in a put() is more an
indication than a firm request. May be the draft should warn
implementors that refreshing may have to be done more frequently?

Another issue is the risk of collisions between keys. Two HITs can be
identical (the RFCs on HIP probably cover the case) but, more
important, you may have a collision between a HIT and another,
unrelated key, in OpenDHT. This does not seem clearly documented but
experience indicates that OpenDHT keys are global, not
per-application, so if an unrelated application chooses a key which
collides with a HIT, the advice "when performing an address lookup,
the *last* HDRR in the DHT response list should be used and considered
to contain the current preferred address" is probably
dangerous. (There is apparently no way in OpenDHT to filter results
based on the application string.)