[secdir] secdir review of draft-ietf-grow-bmp-15

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 08 September 2015 19:09 UTC

Return-Path: <hannes.tschofenig@arm.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 C487F1B37D3 for <secdir@ietfa.amsl.com>; Tue, 8 Sep 2015 12:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id asQ_YG-5UHQ0 for <secdir@ietfa.amsl.com>; Tue, 8 Sep 2015 12:09:07 -0700 (PDT)
Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9C01A03B3 for <secdir@ietf.org>; Tue, 8 Sep 2015 12:09:07 -0700 (PDT)
Received: from emea-cam-gw1.Emea.Arm.com (fw-tnat.cambridge.arm.com []) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-3-NxIXUxaETJGcflKAt8KzWg-1; Tue, 08 Sep 2015 20:09:04 +0100
Received: from EMEA-CAM-GW3.Emea.Arm.com ( by emea-cam-gw1.Emea.Arm.com ( with Microsoft SMTP Server (TLS) id; Tue, 8 Sep 2015 20:09:04 +0100
Received: from george.Emea.Arm.com ([fe80::4c19:a8f:5c9a:76df]) by EMEA-CAM-GW3.Emea.Arm.com ([::1]) with mapi; Tue, 8 Sep 2015 20:09:04 +0100
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-grow-bmp.all@tools.ietf.org" <draft-ietf-grow-bmp.all@tools.ietf.org>
Date: Tue, 8 Sep 2015 20:09:03 +0100
Thread-Topic: secdir review of draft-ietf-grow-bmp-15
Thread-Index: AdDqUD9qseDkdNQRSWGnERO0j8rnww==
Message-ID: <F01D8B85CFF58440B2A13965FBA90CA4014D8EB3EDD2@GEORGE.Emea.Arm.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
acceptlanguage: en-US, en-GB
MIME-Version: 1.0
X-MC-Unique: NxIXUxaETJGcflKAt8KzWg-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/9S8Pe-8f7m2Ok4VevBvp1dOEj-U>
Subject: [secdir] secdir review of draft-ietf-grow-bmp-15
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: Tue, 08 Sep 2015 19:09:09 -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.

I am not an expert in this field and cannot judge whether the designed protocol makes sense. The content did, however, look complete to me.

The security consideration section talks about different security threats and focused on confidentiality protection quite a bit (but  dismisses it in the end). I would think that authentication and integrity are probably more important in this context. I suspect that a monitoring station will react on information it receives (somehow) and false information could potentially be a problem. How likely is it that an attacker injects false information that will then the processed by a monitoring station (which could be located anywhere)?

Currently, it appears that no specific security solution is mandatory to implement. There are only examples listed, such as IPsec and TCP-AO. (For IPsec I guess you would also use IKEv2 as a key management?) Would it be useful to have one security mechanism mandatory to implement?

The sentence "Implementations of this protocol SHOULD require manual configuration of the monitored and monitoring devices." feels a bit out of context in the security consideration section. I would delete it from the security consideration section or, alternatively, what it implies in terms of security.

The term 'transport' for a security protocol appears incorrect. For example, instead of writing "... users of this protocol should consider using some type of transport that provides mutual authentication, data integrity, and transport protection, ... " you could write "... users of this protocol should consider using a security protocol that provides mutual authentication, data integrity, and confidentiality protection, ... ".

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782