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

"Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com> Mon, 26 July 2010 17:38 UTC

Return-Path: <jeffrey.m.ahrenholz@boeing.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10C53A6C68 for <hiprg@core3.amsl.com>; Mon, 26 Jul 2010 10:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG25uoEc6gPq for <hiprg@core3.amsl.com>; Mon, 26 Jul 2010 10:38:13 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id ACF973A6A53 for <hiprg@irtf.org>; Mon, 26 Jul 2010 10:37:58 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (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 stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o6QHaiT3027653; Mon, 26 Jul 2010 12:36:44 -0500 (CDT)
Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (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 XCH-NW-12V.nw.nos.boeing.com ([130.247.25.248]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Mon, 26 Jul 2010 10:36:43 -0700
From: "Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com>
To: "'Ari Keranen'" <ari.keranen@nomadiclab.com>
Date: Mon, 26 Jul 2010 10:36:41 -0700
Thread-Topic: [hiprg] RG last call on the DHT draft
Thread-Index: Acsk7C2YjT82Qtd2STqEymmfnXRtVQH4MLbg
Message-ID: <FD98F9C3CBABA74E89B5D4B5DE0263B93795DA0F37@XCH-NW-12V.nw.nos.boeing.com>
References: <7CC566635CFE364D87DC5803D4712A6C4CE9716436@XCH-NW-10V.nw.nos.boeing.com> <4C4060CD.4040306@nomadiclab.com>
In-Reply-To: <4C4060CD.4040306@nomadiclab.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hiprg@irtf.org" <hiprg@irtf.org>
Subject: Re: [hiprg] RG last call on the DHT draft
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jul 2010 17:38:48 -0000

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"

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

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: http://opendht.org/faq.html

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

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

fixed

> 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