Subject: Re: [hiprg] draft-ahrenholz-hiprg-dht-05

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 2 Nov 2009 09:28:52 -0800

> Well, I'm not so sure the OpenDHT interface is ideal for this sort of
> application, but it is reasonably simple, and there is software out
> there that has been written to use it.  It's good for getting started
> with.

what is the ideal interface?
...that would be a great discussion for this list.

> In the introduction, mentioning that OpenLookup is not a DHT might
> avoid some misunderstandings.  Maybe something like this: "OpenLookup,
> while not a DHT, is another deployment of open source software
> compatible with the OpenDHT interface."

OK, good point, will add such text.

> Near the end of Section 3.1, the text incorrectly indicates that
> OpenDHT does not promise to honor the time-to-live.  I'll quote from
> "OpenDHT: A Public DHT Service and Its Uses"
> (http://opendht.org/f230-rhea.pdf):

this text about TTL was added due to concerns voiced by Stephane Bortzmeyer:
http://www.ietf.org/mail-archive/web/hiprg/current/msg00473.html

I don't know whether or not the server honors the TTL under heavy load. From that 2005 paper you quoted clearly they intended the TTL to be guaranteed. It seems that the server is supposed to return the "over capacity" code in that situation. I'd be fine with removing that text, it is only one or two sentences.

> Finally, the first paragraph of Section 6 incorrectly assumes that get
> operations return values in the order in which they were put into the
> DHT:
...
> Actually, the ordering of the returned values is determined by a
> cursor based on just the value and the secret hash.  That's how
> placemarks work.
> 
> Ken
> 

we may need to include something like the SEQ TLV in the HDRR, so that each record has an update id; then clients may retrieve all available values and use the most recent one

-Jeff

---

From: Ken Rimey <[email-masked]>
Date: Tue, 3 Nov 2009 21:19:54 +0200

> ...we may need to include something like the SEQ TLV in the HDRR,
> so that each record has an update id; then clients may retrieve all
> available values and use the most recent one

A better interface (I won't dare to say ideal) would handle this on the
server side, so the client only sees the most recent update.

Another desirable thing, as made clear in the draft, would be for the
server to do the checking of signatures.

The following is not a sales pitch.  :-)

OpenLookup actually implements an interface like this for a second
datastore, separate from the OpenDHT-compatible store.  The data
model is a single-valued mapping from principal-label pairs to values
(where the label is analogous to the OpenDHT key).

The interface is based on HTTP, but not XML-RPC.

Instead of a sequence number, it simply uses the expiration time
to determine precedence between updates.

For HIP, unfortunately, the OpenLookup code would have to be
hacked to name principals using just the middle 100 bits of the
SHA-1 hash.

The interface also allows for queries, where the principal is a
wildcard.  This is useful for use cases like storing a name-to-HIT
mapping.  (I have doubts about such multivalued mappings being
viable in the real world, however.)

Ken

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 9 Nov 2009 12:20:43 -0800

Tom,

Thanks for your comments, all should be addressed by draft-ahrenholz-hiprg-dht-06.

> Oleg Ponomarev's draft (draft-ponomarev-hip-hit2ip-04.txt) 
> suggests that DNS could be used in some situations, so maybe 
> this statement needs to be relaxed, and a reference added.

relaxed that statement and referenced Oleg's draft

> 2) In section 3, regarding the HIT lookup service, should we 
> allow somehow for the possible extension that a user could 
> put a name record that also had a certificate that bound the 
> name to a HIT?  This may allow security to be introduced into 
> this service, such as:  1) when the server authenticates the 
> put() based on certificate, or 2) when the client 
> authenticates the name-to-HIT binding based on certificate retrieved.

changed the HIT lookup service to use a HDRR with optional CERT TLV

> 3) is it possible for a put() to fail?  If so, how should an 
> implementation handle that event?

added a failure code for the case when HIT verification fails; the other OpenDHT return codes are also covered in the draft
 
> 4) Section 4:  "Note that this HDRR format is different than 
> the HIP RR used by the Domain Name System as defined in 
> [RFC5205]."  It may be helpful to mention here that the 
> reason it is different is that it is a different record from 
> a functional point of view:  in DNS, the query key is a FQDN, 
> and the return value is a HIT, while here, the query key is a HIT.

added this clarification text

> 5) Should the reader of this HDRR verify that the SRC HIT and 
> DST HIT values are correct, and discard if not, or be 
> permissive about these values?

yes, SRC HIT must match HIT_KEY and HI, and DST HIT is NULL

> 6) In the last paragraph of section 4, it starts to describe 
> HIP-aware DHT behavior, but then says that it is out of 
> scope.  What would be required to go ahead and specify the 
> HIP aware interface in this draft?  In this case, the put() 
> may fail (see #3 above) and this failure would need to be 
> conveyed to the client somehow.  Is there anything else 
> required to extend the scope to also allow for HIP-aware DHT servers? 

added such text to the latest draft
for the put(HIT, HDRR), the server verifies that the HIT and SIGNATURE match the include HOST_ID; the server can also verify the optional certificate for the name lookup

> 7) Section 5's title could probably just be simplified to 
> read "Use Cases"

fixed

-Jeff

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 9 Nov 2009 12:20:31 -0800

> server to do the checking of signatures.

I added the SEQ TLV to the HDRR used to store LOCATORs in the DHT. Also I added text about server-side verification of the signature. This is in the new draft-ahrenholz-hiprg-dht-06.

-Jeff