Re: [hiprg] Review of draft-irtf-hiprg-dht-03

"Ahrenholz, Jeffrey M" <> Fri, 08 July 2011 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2140321F8CA2 for <>; Fri, 8 Jul 2011 13:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jRfg+uJcG1lL for <>; Fri, 8 Jul 2011 13:03:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 87D3621F8C93 for <>; Fri, 8 Jul 2011 13:03:24 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p68K3Mjf025216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Jul 2011 13:03:23 -0700 (PDT)
Received: from (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p68K3Le7007600; Fri, 8 Jul 2011 15:03:21 -0500 (CDT)
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p68K3L4f007576 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 8 Jul 2011 15:03:21 -0500 (CDT)
Received: from ([]) by ([]) with mapi; Fri, 8 Jul 2011 13:03:20 -0700
From: "Ahrenholz, Jeffrey M" <>
To: Martin Stiemerling <>, "" <>
Date: Fri, 8 Jul 2011 13:03:21 -0700
Thread-Topic: Review of draft-irtf-hiprg-dht-03
Thread-Index: AcwyWxDcoW/lGzJLR4m2SC8gbjhAjQLOERuw
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
Subject: Re: [hiprg] Review of draft-irtf-hiprg-dht-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2011 20:03:25 -0000

Thanks for your review. I've posted a -04 revision with changes mentioned here. Comments inline below.

> I would swap the Section 3 and Section 4. Section 3 is
> relying on the knowledge about what the HDRRs are, but
> all of this is introduced in Section 4. 

Done: sections 3 and 4 are swapped, with a little introductory text (moved from the lookup section) at the beginning of the HDRR section.

> - Section 3, page 8, first paragraph on that page:
> How often should a HIP peer check whether the name to HIT
> binding is still valid? The text only says that a check 
> if needed, but there is no hint to the frequency, e.g.,
> years, days, hours, minutes, seconds (?)

OK, I've added this sentence:
" For example,
  local policy may specify checking the name-to-HIT binding on a daily
  basis, while the address record is updated hourly for active peers."

Usually I keep HITs tied to a specific name for a long time (years), are there other thoughts on reasonable frequencies?  

> - Section 4, page 15, last paragraph:
> This proposed server side checking could be source of a 
> denial of service attack, as the DHT server would need 
> to do some processing on its own. I would either remove 
> this or document it well in the security section. 

I added a paragraph to the security considerations section. Is it enough? Any other thoughts on techniques the server should use to mitigate DoS?

> - Section 6, page 18, 4th paragraph:
> This latency considerations neglect the processing impact
> of the DHT itself. DHTs are not the fastest lookup mechanism
> in the world. This should also be documented as an impacting factor. 
I re-worded this paragraph to include DHT slowness as impacting the latency.

> - Section 1, first paragraph:
> "DHTs are also designed to support frequently updating"
> What is frequently in this case? I would understand frequently in 
> the range of seconds, but this may not be true for DHTs. DHTs can
> be updated more frequently than a DNS based approach and that is 
> what you are probably trying to say here.

Yes, more frequently than DNS, fixed.

> - Section 2, 3rd paragraph, 1st sentence:
> " OpenDHT stores values using (hash) keys." 
> This is incomplete. I would suggest to write
> "OpenDHT stores values and indexes those by using (hash) keys."


> - Appendix A:
> Please add a note that this appendix should be removed by 
> the RFC editor (assuming that this is the intention).

OK, added the note to the appendix title.