Re: [secdir] Review of draft-ietf-manet-nhdp-11

Thomas Heide Clausen <thomas@thomasclausen.org> Tue, 23 March 2010 21:50 UTC

Return-Path: <thomas@thomasclausen.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE3C3A6BF4; Tue, 23 Mar 2010 14:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.131
X-Spam-Level: *
X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 5sjS8k+yjnXr; Tue, 23 Mar 2010 14:50:20 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id E4A203A6C45; Tue, 23 Mar 2010 14:50:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C40E032356B5; Tue, 23 Mar 2010 14:50:40 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [172.27.171.249] (207.88.181.2.ptr.us.xo.net [207.88.181.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 8D2913228088; Tue, 23 Mar 2010 14:50:40 -0700 (PDT)
Message-Id: <4112EE01-AEB6-435C-95DC-2EBAF5AA3E75@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Shawn M Emery <shawn.emery@oracle.com>
In-Reply-To: <4B9F2B36.3060700@oracle.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 23 Mar 2010 22:50:40 +0100
References: <4B9F2B36.3060700@oracle.com>
X-Mailer: Apple Mail (2.936)
X-Mailman-Approved-At: Tue, 23 Mar 2010 14:53:19 -0700
Cc: draft-ietf-manet-nhdp.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-manet-nhdp-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2010 21:50:21 -0000

Dear Shawn,

Thank you for your review.

We have updated the document to reflect your comments -- and thank you  
profoundly for the efforts that you have put in to helping us improve  
the document quality.

The updated document should be submitted to the repository shortly.

Sincerely,

Thomas

On Mar 16, 2010, at 07:54 AM, Shawn M Emery wrote:

>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> This draft describes a protocol for a one-hop and a symmetric two-hop
> neighborhood discovery for mobile ad hoc networks (MANETs).
>
> The security considerations section does exist and discusses the  
> various
> attack scenarios.  The first being HELLO messages that are correctly
> formatted, but malicious.  Preventing this scenario can be handled in
> different ways depending on the constraints in which the protocol is
> deployed; physical or proximity access, link-layer authentication,
> integrity checks, and confidentiality.
>
> Then the section suggests how to protect HELLO messages for this
> protocol by using the same mechanisms that RFC5444 outlines.  For
> integrity; using signatures in Message TLV or Packet TLVs.  For  
> privacy;
> using link-layer protection, IPsec, or encrypting the Value field and
> specifying the encrypted TLV type for the associated message.  It  
> might
> be helpful if they state something like this instead of just referring
> to 5444 for confidentiality.  Other than this, I believe that the
> section covers the possible issues and their respective solution.
>
> General comments:
>
> None.
>
> Editorial comments:
>
> 5.5. Parameter Change Constraints
>
> The first occurrence of L_time and NL_time should have their
> corresponding definition.
>
>
> 9.2. Removing an Interface
>
> s/router will longer participate/router will no longer participate/
>
>
> 9.3. Adding a Network Address to an Interface
>
> s/network address is removed/network address, is removed/
>
> --
> Shawn.
>