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

[jeffrey.m.ahrenholz at boeing.com (Ahrenholz, Jeffrey M)]

Stephane,
Thanks for your comments. Responses inline below...

> -----Original Message-----
> From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] 
> Sent: Monday, January 21, 2008 6:41 AM
> To: Ahrenholz, Jeffrey M
> Cc: opendht-users at opendht.org; hipsec-rg at listserv.cybertrust.com
> Subject: Issues in draft-ahrenholz-hiprg-dht-02.txt
> 
> [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.]

Yes, discussion for this draft usually occurs on the hipsec-rg list.

> 
> 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?

This is a good point, I will update the draft to mention that the TTL is
only a hint, and a host may want to update its published values
periodically, per policy, more frequently than the stated TTL.

> 
> 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.)

I didn't know that the application string provides no separation. The
signature and Host Identity in the HDRR will need to be verified by the
client before using it, so that is one protection. Maybe each HDRR
should contain a monotonically increasing counter (like the SEQ
UPDATE_ID in the HIP UPDATE packet) and the client should use the HDRR
that has the greatest counter value. This would also help against an
attack using replayed PUT packets.

-Jeff