Re: [secdir] Secdir review of draft-ietf-manet-nhdp-olsrv2-tlv-extension-01

Thomas Clausen <thomas@thomasclausen.org> Mon, 10 February 2014 14:22 UTC

Return-Path: <thomas@thomasclausen.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9DD1A083F; Mon, 10 Feb 2014 06:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvUUE72bKDp0; Mon, 10 Feb 2014 06:22:53 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id B84021A0814; Mon, 10 Feb 2014 06:22:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EABD61BD3844; Mon, 10 Feb 2014 06:22:53 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E8A8D1BD383C; Mon, 10 Feb 2014 06:22:51 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Clausen <thomas@thomasclausen.org>
In-Reply-To: <21240.56492.25650.629460@fireball.kivinen.iki.fi>
Date: Mon, 10 Feb 2014 15:22:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B913257-5B91-40DE-B196-ACFFEB3C5CAD@thomasclausen.org>
References: <21240.56492.25650.629460@fireball.kivinen.iki.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.1827)
Cc: draft-ietf-manet-nhdp-olsrv2-tlv-extension.all@tools.ietf.org, The IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-manet-nhdp-olsrv2-tlv-extension-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 10 Feb 2014 14:22:55 -0000

Thank you, Tero, for your review. 

As the non-native English speaker among the authors, thank you for your catch on the is/are in the IANA section...I am afraid that I have to assume that the fault there lies with me....

Respectfully,

Thomas

On 10 Feb 2014, at 15:05, Tero Kivinen <kivinen@iki.fi> 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 document seems to fix some cases in the NHDP and OLSRv2 TLVs
> where the original document might have been considered saying that
> unknown values in the TLVs can be used as a reason to reject message.
> This document makes it clear how unknown values in the TLVs needs to
> be processed. This document also creates several IANA registries for
> the TLV values and changes couple of the TLV values from numbers to
> bitfields (the existing values were already allocated so that the
> numbers can be parsed as bitfield).
> 
> Security considerations section mentions that as this does not really
> change the current implementations, it more or less describes how new
> extensions should be processed with implementations it does not add
> any new security considerations. New extensions might of course add
> new security considerations but those should be addressed in the
> documents which make those extensions.
> 
> The document is ready with nits.
> 
> Some nits:
> 
> In the IANA considerations section the IANA is used both in singular
> and plural, i.e. it says both "IANA is requested" and "IANA are
> requested". This should be fixed to say "IANA is requested". 
> -- 
> kivinen@iki.fi