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

Shawn M Emery <shawn.emery@sun.com> Tue, 16 March 2010 07:01 UTC

Return-Path: <shawn.emery@sun.com>
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 2743B3A6876 for <secdir@core3.amsl.com>; Tue, 16 Mar 2010 00:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 n55MMBGow29r for <secdir@core3.amsl.com>; Tue, 16 Mar 2010 00:01:27 -0700 (PDT)
Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id EC6433A62C1 for <secdir@ietf.org>; Tue, 16 Mar 2010 00:01:26 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2G71Rr0002295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <secdir@ietf.org>; Tue, 16 Mar 2010 07:01:29 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2G6d3Sc015274 for <secdir@ietf.org>; Tue, 16 Mar 2010 07:01:26 GMT
Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 88900041268722839; Tue, 16 Mar 2010 00:00:39 -0700
Received: from [10.7.250.239] (/10.7.250.239) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Mar 2010 00:00:39 -0700
Message-ID: <4B9F2C96.1090403@sun.com>
Date: Tue, 16 Mar 2010 01:00:38 -0600
From: Shawn M Emery <shawn.emery@sun.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0
MIME-Version: 1.0
To: secdir@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsmt353.oracle.com [141.146.40.153]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A0B020B.4B9F2CC7.0108,ss=1,fgs=0
Subject: [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, 16 Mar 2010 07:01:27 -0000

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.