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

"Ahrenholz, Jeffrey M" <> Mon, 26 July 2010 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C10C53A6C68 for <>; Mon, 26 Jul 2010 10:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HG25uoEc6gPq for <>; Mon, 26 Jul 2010 10:38:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ACF973A6A53 for <>; Mon, 26 Jul 2010 10:37:58 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o6QHai1j007739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jul 2010 12:36:44 -0500 (CDT)
Received: from (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o6QHaiT3027653; Mon, 26 Jul 2010 12:36:44 -0500 (CDT)
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o6QHahwB027639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 26 Jul 2010 12:36:44 -0500 (CDT)
Received: from ([]) by ([]) with mapi; Mon, 26 Jul 2010 10:36:43 -0700
From: "Ahrenholz, Jeffrey M" <>
To: 'Ari Keranen' <>
Date: Mon, 26 Jul 2010 10:36:41 -0700
Thread-Topic: [hiprg] RG last call on the DHT draft
Thread-Index: Acsk7C2YjT82Qtd2STqEymmfnXRtVQH4MLbg
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [hiprg] RG last call on the DHT draft
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jul 2010 17:38:48 -0000


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.


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

>     The definitions below are taken from
>     <>.
> Should also some explaining text be taken from there since that user 
> guide doc may not be available later on?

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

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

added reference to Section 4

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

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

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

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:

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

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

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

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

> 3.2. HIP address lookup
>               [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).

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

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

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

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

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

> typo: pusblished


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

fixed this with added text in section 2

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

added to the IANA considerations section

> RFC 2119 language without the "terminology section". This 
> could also be 
> 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 
> still removed?

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

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

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