[secdir] Secdir Review of draft-ietf-manet-olsrv2-dat-metric-08

Dacheng <zhang_dacheng@hotmail.com> Sun, 15 November 2015 07:40 UTC

Return-Path: <zhang_dacheng@hotmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id F39651A8AA8; Sat, 14 Nov 2015 23:40:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RfKFiGjQBIy7; Sat, 14 Nov 2015 23:40:18 -0800 (PST)
Received: from BLU004-OMC4S4.hotmail.com (blu004-omc4s4.hotmail.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC001A8AA7; Sat, 14 Nov 2015 23:40:17 -0800 (PST)
Received: from BLU436-SMTP248 ([]) by BLU004-OMC4S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 14 Nov 2015 23:40:16 -0800
X-TMN: [2e+ocnsu/B28fLGpIEDfOZLBLV1fWfON]
X-Originating-Email: [zhang_dacheng@hotmail.com]
Message-ID: <BLU436-SMTP2489108BA79EA7032F2495A881F0@phx.gbl>
From: Dacheng <zhang_dacheng@hotmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DED9753D-033E-4365-A553-4030F532C8C0"
Date: Sun, 15 Nov 2015 15:40:00 +0800
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-OriginalArrivalTime: 15 Nov 2015 07:40:14.0926 (UTC) FILETIME=[DDDD4EE0:01D11F78]
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/H_o3MucJ1aE7xEg4Fjzmlp0UAcU>
Cc: draft-ietf-manet-olsrv2-dat-metric.all@ietf.org
Subject: [secdir] Secdir Review of draft-ietf-manet-olsrv2-dat-metric-08
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 15 Nov 2015 07:40:25 -0000

Dear all,

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 is about a new routing  metro for OLSRv2.

Technical questions/comments:

1) In this draft, “RFC5444 packet” can be found in many places. I didn’t find the definition of this term. Do you indicate this solution may need to process a packet which is not specified in OLSRv2?

2) There is a good security consideration section in RFC 7181. Since this draft is closely related to OLSRv2 (although this work does not specify any new message or TLV), it will be good to build the security considerations of this work based upon what has been discussed in RFC7181. For example, maybe the authors could say ’there will be some new security issues introduced by this work but not mentioned in RFC 7181, there will be some security issues if we only use the mandatory security mechanism specified in RFC7181, or our work does not introduce any additional security issues..

3) This question is about the last sentence in the security consideration—“The signature scheme described in [RFC7183] does not protect the additional sequence number of the DAT metric because it does only sign the RFC5444 messages, not the RFC5444 packet header.” First of all, there is no signature mechanism specified in RFC7183, only HMAC is used to protect the message integrity. In addition, the RFC7183 reuse the process specified in RFC7182 to generate hashes, and so it should be able to cover the message headers.   Open for discussion.


Section 2:

MAX(a,b) -> MAX(a, b)
Section 3:

The administrator should take care that link layer multicast transmission do not not have ->  The administrator should take care that link layer multicast transmission do not have
Section 4:

The routing decision of most operation systems don't take packet size into account. -> The routing decisions of most operation systems don't take packet size into account.
Section 7:
with a very slow or very fast linklayer -> with a very slow or very fast link layer