Subject: [hiprg] RG last call on the DHT draft

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 12 Jul 2010 09:55:49 -0700

All,
This is the last call for comments on the HIP DHT Interface (draft-irtf-hiprg-dht-00).
http://tools.ietf.org/html/draft-irtf-hiprg-dht-00

The last call expires on July 26, 2010.  Please provide your input by then.  The goal is to prepare this document for IRSG review for publication as an IRTF stream RFC.

Thanks,
Tom

---

From: Ari Keranen <[email-masked]>
Date: Fri, 16 Jul 2010 16:38:21 +0300

On 07/12/2010 07:55 PM, Henderson, Thomas R wrote:
> All, This is the last call for comments on the HIP DHT Interface
> (draft-irtf-hiprg-dht-00). 
> The last call expires on July 26, 2010.  Please provide your input by
> then.  The goal is to prepare this document for IRSG review for
> publication as an IRTF stream RFC.
> 

Here's some comments on the draft. I read it only up to section 4, but I 
can see if I have time later to read the remaining sections too.

Cheers,
Ari

---

Abbreviations in the title and abstract are not expanded.

2. The OpenDHT interface

    While the Bamboo
    project provides the actual software running on the servers, here we
    will refer only to OpenDHT, which uses a certain defined interface
    for the XML-RPC calls.

s/provides/provided/ ?

    The definitions below are taken from
    <http://opendht.org/users-guide.html>.

Should also some explaining text be taken from there since that user 
guide doc may not be available later on?

     The return code 3
     indicates "failure" and is used for a modified OpenDHT server that
                  performs signature and HIT verification.

I think this needs more details (or a reference to the section with more 
details).

      The server replies with an integer -- 0 for "success", 1 if it is
               "over capacity", and 2 indicating "try again".

What does "over capacity" imply? Try again later?

3.1. HIP name to HIT lookup

          put(SHA-1("name", HDRR([CERT]), [SHA-1(secret)])

I suppose there should be a closing parenthesis after "name". And same 
issue with rm?

By the way, why is SHA-1 of HDRR needed in remove? Some OpenDHT specific 
feature?

    If a certificate is included in this HIT record, the name used for
    the DHT key should be listed in the certificate.

Should define which certificate field should be used for the DHT key.

    The ttl_sec field specifies the number of seconds requested by the
    client that the entry should be stored by the DHT server, which is
    implementation dependent.

Could the TTL be also policy dependent?

3.2. HIP address lookup

          HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG) = get(HIT_KEY)
          put(HIT_KEY, HDRR(LOCATOR, SEQ, HOST_ID, [CERT], HIP_SIG),
              [SHA-1(secret)])
          rm(HIT_KEY, SHA-1(HDRR), secret)

These API descriptions are a bit hard to parse if you are not familiar 
with the syntax. Perhaps having a short paragraph after each operation 
would help (slightly edited second paragraph of this section would be OK 
for the get).

Wouldn't the HIT_KEY be better simply defined as "last 100 bits of the 
HIT appended with 60 zero bits"? The current text with RFC4843 
definitions seems a bit confusing for such a simple thing.

Overall, the definition of the "key" and HIT_KEY are somewhat confusing. 
The next table seems to imply that HIT_KEY simply the 100 bits but later 
in the section (after the tables) it is explained again.

    |                | pusblished contained in the LOCATOR    |         |

typo: pusblished

    The application and client_library fields are used for logging in
    OpenDHT.  The client_library may vary between different
    implementations, specifying the name of the XML-RPC library used or
    the application that directly makes XML-RPC calls.

This note would be better already in the (end of?) section 2 where the 
"application" and "client_library" are used the first time.

4. HDRR - the HIP DHT Resource Record

      HIP Header:
        Packet Type = 20 DHT Resource Record (this value is TBD)

This should probably be added to the IANA considerations section.

    The Responder
    HIT (Receiver's HIT, DST HIT) MUST be NULL (all zeroes) since the
    data is intended for any host.

RFC 2119 language without the "terminology section". This could also be 
problematic considering the informational status of the draft.

---

From: Ari Keranen <[email-masked]>
Date: Mon, 19 Jul 2010 14:02:31 +0300

Hi,

Here's some more comments on the rest of the DHT draft.

    The only other TLV used with the HIT lookup service is an optional
    CERT parameter containing a certificate for validating the name that
    is used as the DHT key.

Missing a reference to the CERT draft.

    The HOST_ID parameter and HIP_SIGNATURE parameter MUST be used with
    the HDRR so that HIP clients receiving the record can validate the
    sender and the included LOCATOR parameter.
[...]
    The client that receives the HDRR from the DHT response MUST perform
    the signature and HIT_KEY verification.

More instances of RFC 2119 language.

5. Use cases

    Also, when there is a change in
    preferred address, usually associated with sending UPDATE packets
    with included locator parameters, the host should update its HDRR
    with the DHT.  The old HDRR should be removed using the rm operation,
    if a secret value was used in the put.

If a secret value was not used, shouldn't the old HDRR be still removed?

    Addresses from the private address space should not be published to
    the DHT.  If the host is located behind a NAT, for example, the host
    could publish the address of its RVS to the DHT if that is how it is
    reachable.

Abbreviations are not expanded (RVS, and perhaps NAT too) and missing a 
reference to the RVS RFC. Since we're talking about NATs, could also 
mention HIP relay and RFC 5770.

Cheers,
Ari

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 26 Jul 2010 10:36:41 -0700

Ari,

Thanks for your comments! 

Below I've replied inline about some changes made based on your review. This covers comments from both of your emails.

-Jeff

> Abbreviations in the title and abstract are not expanded.

fixed - expanded DHT and HIT

> s/provides/provided/ ?

could go either way (Bamboo still exists but OpenDHT does not) but I changed to "provided"

> guide doc may not be available later on?

yes, I've added some explanatory text about the different fields

> I think this needs more details (or a reference to the 
> section with more details).

added reference to Section 4

> What does "over capacity" imply? Try again later?

I added text from the OpenDHT users guide to explain these.

> I suppose there should be a closing parenthesis after "name". 
> And same issue with rm?

yes, good catch! fixed

> By the way, why is SHA-1 of HDRR needed in remove? Some 
> OpenDHT specific feature?

yes it is strange, this is dictated by OpenDHT; the remove is stored persistently by the DHT, some reasoning is available at the end of this FAQ: http://opendht.org/faq.html

> Should define which certificate field should be used for the DHT key.

added text about using the CN field of the DN of X.509.v3 certificate

> Could the TTL be also policy dependent?

yes, good point! added text "implementation or policy dependent"

> would help (slightly edited second paragraph of this section 

I added some introductory text about the syntax. I mention that the DHT operation is described in greater detail following the summarized notation.

> definitions seems a bit confusing for such a simple thing.

yes, good point, I simplified this definition per your suggestion

> in the section (after the tables) it is explained again.

I removed all references to "100-bit HIT_KEY" and stuck with the one definition of HIT_KEY

> typo: pusblished

fixed

> "application" and "client_library" are used the first time.

fixed this with added text in section 2

> This should probably be added to the IANA considerations section.

added to the IANA considerations section

> problematic considering the informational status of the draft.

I dropped this RFC 2119 language

> Missing a reference to the CERT draft.

added references to the CERT draft

> More instances of RFC 2119 language.

I dropped this RFC 2119 language

> If a secret value was not used, shouldn't the old HDRR be 

the HDRR cannot be removed without a secret value (OpenDHT protocol limitation)

> mention HIP relay and RFC 5770.

expanded RVS and added reference to RFC 5204. Even though a NATted host is mentioned, I don't feel we need to discuss RFC 5770 here, since it is supposed to be a simple example

---

From: Ari Keranen <[email-masked]>
Date: Thu, 29 Jul 2010 14:20:51 +0200

Hi Jeff,

I haven't yet checked out the updated version, but based on your answer 
the fixes look good - thanks!

Regarding the use of RFC 2119 language, actually I think you should keep 
it (and in fact increase the use of it) and this document should be made 
Experimental instead of Informational (I commented on this also during 
the RG meeting).

Cheers,
Ari

26.7.2010 19:36, Ahrenholz, Jeffrey M kirjoitti:
[...]
> the HDRR cannot be removed without a secret value (OpenDHT protocol

OK, so this part was actually describing normative behavior for a host? 
It was not clear to me; I would consider rephrasing.