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

Dacheng <zhang_dacheng@hotmail.com> Mon, 23 November 2015 06:54 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76161B3129; Sun, 22 Nov 2015 22:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.184
X-Spam-Level:
X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, 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 9EKr4mQkvDhr; Sun, 22 Nov 2015 22:54:08 -0800 (PST)
Received: from BLU004-OMC4S1.hotmail.com (blu004-omc4s1.hotmail.com [65.55.111.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342ED1B30FF; Sun, 22 Nov 2015 22:54:08 -0800 (PST)
Received: from BLU436-SMTP244 ([65.55.111.136]) by BLU004-OMC4S1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 22 Nov 2015 22:54:06 -0800
X-TMN: [niBwG/hAJk5aePcV8+TYKLn/cRqyEuDH]
X-Originating-Email: [zhang_dacheng@hotmail.com]
Message-ID: <BLU436-SMTP244F0485378ADA75287E88B88070@phx.gbl>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FC4AAB1-B2E3-4A87-AB95-98E5B2E699FC"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Dacheng <zhang_dacheng@hotmail.com>
In-Reply-To: <564AF000.4080705@fkie.fraunhofer.de>
Date: Mon, 23 Nov 2015 14:53:50 +0800
References: <BLU436-SMTP2489108BA79EA7032F2495A881F0@phx.gbl> <564AF000.4080705@fkie.fraunhofer.de>
To: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
X-Mailer: Apple Mail (2.1878.6)
X-OriginalArrivalTime: 23 Nov 2015 06:54:04.0958 (UTC) FILETIME=[BE23BBE0:01D125BB]
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/TWTugzemZFLGmG5Thhn5SgMER6E>
Cc: draft-ietf-manet-olsrv2-dat-metric.all@ietf.org, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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: Mon, 23 Nov 2015 06:54:12 -0000

在 2015年11月17日,下午5:14,Henning Rogge <henning.rogge@fkie.fraunhofer.de> 写道:

> On 11/15/2015 08:40 AM, Dacheng wrote:
>> 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?
> 
> The header of the Terminology Section contains the following paragraph:
> 
>   The terminology introduced in [RFC5444], [RFC7181] and [RFC6130],
>   including the terms "packet", "message" and "TLV" are to be
>   interpreted as described therein.
> 
> Do you think this paragraph needs to be improved or extended?
Ok, I think ’a packet specified in RFC5444' looks better. But it is not a big problem.

> 
>> 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.
> 
> RFC7183 introduces a RFC5444 message level integrity protection extension for RFC7181 (OLSRv2), based on the ICV Message TLV defined in RFC7182 (see section 9.1 of RFC7182).
> 
> The ICV Message TLV does NOT protect the PACKET header fields of RFC5444 packets, including the RFC5444 packet sequence number.

I see and you are right. The only comment about this sentence is not to use “security mechanism” instead of “signature mechanism “ because only a HMAC mechanism is specified in RFC 7183.


> 
>> Editorial:
>> 
>> 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
> 
> Will be fixed in the next revision.
> 
> Henning Rogge
> 
> -- 
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Fraunhofer Straße 20, 53343 Wachtberg, Germany
> Telefon +49 228 9435-961,   Fax +49 228 9435 685
> mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de