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

"Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com> Fri, 08 July 2011 20:03 UTC

Return-Path: <jeffrey.m.ahrenholz@boeing.com>
X-Original-To: hiprg@ietfa.amsl.com
Delivered-To: hiprg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2140321F8CA2 for <hiprg@ietfa.amsl.com>; Fri, 8 Jul 2011 13:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRfg+uJcG1lL for <hiprg@ietfa.amsl.com>; Fri, 8 Jul 2011 13:03:24 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 87D3621F8C93 for <hiprg@irtf.org>; Fri, 8 Jul 2011 13:03:24 -0700 (PDT)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (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 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 p68K3Le7007600; Fri, 8 Jul 2011 15:03:21 -0500 (CDT)
Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-av-01.boeing.com (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 XCH-NW-12V.nw.nos.boeing.com ([130.247.25.246]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Fri, 8 Jul 2011 13:03:20 -0700
From: "Ahrenholz, Jeffrey M" <jeffrey.m.ahrenholz@boeing.com>
To: Martin Stiemerling <Martin.Stiemerling@neclab.eu>, "hiprg@irtf.org" <hiprg@irtf.org>
Date: Fri, 08 Jul 2011 13:03:21 -0700
Thread-Topic: Review of draft-irtf-hiprg-dht-03
Thread-Index: AcwyWxDcoW/lGzJLR4m2SC8gbjhAjQLOERuw
Message-ID: <FD98F9C3CBABA74E89B5D4B5DE0263B9379DA34132@XCH-NW-12V.nw.nos.boeing.com>
References: <E84E7B8FF3F2314DA16E48EC89AB49F013A88AB5@Polydeuces.office.hd>
In-Reply-To: <E84E7B8FF3F2314DA16E48EC89AB49F013A88AB5@Polydeuces.office.hd>
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
Subject: Re: [hiprg] Review of draft-irtf-hiprg-dht-03
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/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: Fri, 08 Jul 2011 20:03:25 -0000

Martin,
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."

Fixed.

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

-Jeff