Re: [secdir] secdir review of draft-ietf-pce-pcep-mib-10

Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> Fri, 24 October 2014 15:41 UTC

Return-Path: <Jonathan.Hardwick@metaswitch.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 0D1DA1A1A91; Fri, 24 Oct 2014 08:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 krVR9_0gA8pA; Fri, 24 Oct 2014 08:41:35 -0700 (PDT)
Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4EB1A1A87; Fri, 24 Oct 2014 08:41:07 -0700 (PDT)
Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 24 Oct 2014 16:41:01 +0100
Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%12]) with mapi id 14.03.0195.001; Fri, 24 Oct 2014 16:41:05 +0100
From: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
To: David Harrington <ietfdbh@comcast.net>, "afarrel@juniper.net" <afarrel@juniper.net>
Thread-Topic: [secdir] secdir review of draft-ietf-pce-pcep-mib-10
Thread-Index: AQHP734WKIaVKfF//UO6MsVBo/g09pw/EuEAgAAzC4CAABv6sA==
Date: Fri, 24 Oct 2014 15:41:05 +0000
Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBAFDCFE577@ENFICSMBX1.datcon.co.uk>
References: <D06FB0C8.253DE%carl@redhoundsoftware.com> <09a201cfef81$51aac740$f50055c0$@juniper.net> <19FF9B70-0C5C-4202-B546-11870A1858BD@comcast.net>
In-Reply-To: <19FF9B70-0C5C-4202-B546-11870A1858BD@comcast.net>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.18.4.11]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Kh_57Cikn5-_4XQWATMH-ervwag
X-Mailman-Approved-At: Fri, 24 Oct 2014 08:42:36 -0700
Cc: "draft-ietf-pce-pcep-mib.all@tools.ietf.org" <draft-ietf-pce-pcep-mib.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-pce-pcep-mib-10
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: Fri, 24 Oct 2014 15:41:37 -0000

David

Thanks for pointing this out. The deviation from the boilerplate text seems to have been accidental - I will fix the document to use the boilerplate text verbatim.

Adrian - there will be a new version of the document uploaded shortly.

Cheers
Jon


-----Original Message-----
From: David Harrington [mailto:ietfdbh@comcast.net] 
Sent: 24 October 2014 15:58
To: afarrel@juniper.net
Cc: Carl Wallace; draft-ietf-pce-pcep-mib.all@tools.ietf.org; iesg@ietf.org; secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-pce-pcep-mib-10

Hi,

I'm a MIB Doctor, not an AD.
But I'll respond anyway.

The text in the boilerplate went through a long negotiation process balancing interoperability, SNMP best current practices, and security best current practices.
The boilerplate represents the result - the best current practices related to interoperable security for SNMP and the MIB.
The boilerplate text should NOT be modified on a MIB-module by MIB-module basis.

The document being reviewed changed the boilerplate, changing SHOULD implement SNMPv3 into MUST implement SNMPv3. 
While desirable, that is actually incorrect for interoperability reasons.
Theoretically, MIB modules are independent of the protocol carrying the data defined in the module.
MIB modules should always be independent of the SNMP version that carries the data. So this MIB module, if correctly designed, should also work using SNMPv1/v2 or (maybe some time in the future) an SNMPv4.
This MIB module should also be able to be used with Netconf, using the MIB-to-YANG conversion standard.
So changing the SHOULD implement SNMPv3 to MUST implement SNMPv3 is incorrect, because SNMPv3 is NOT REQUIRED for this MIB module to work.

The best way for a document to address the security requirements for a MIB module, is to use the boilerplate verbatim, modifying only those places where it calls for a list of the sensitive objects, and the reasons why they are considered sensitive.

David Harrington
ietfdbh@comcast.net



On Oct 24, 2014, at 7:54 AM, Adrian Farrel <afarrel@juniper.net>; wrote:

> Sec and Ops ADs...
> 
> Could you please interpret this review by Carl in the context of the "best current advice" and boilerplate for MIB modules.
> 
> Thanks,
> Adrian
> 
>> -----Original Message-----
>> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Carl Wallace
>> Sent: 24 October 2014 12:31
>> To: draft-ietf-pce-pcep-mib.all@tools.ietf.org
>> Cc: iesg@ietf.org; secdir@ietf.org
>> Subject: secdir review of draft-ietf-pce-pcep-mib-10
>> 
>> 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 describes a MIB that "describes managed objects for modeling
>> of Path Computation Element communications Protocol (PCEP) for
>> communications between a Path Computation Client (PCC) and a Path
>> Computation Element (PCE), or between two PCEs".
>> 
>> I am not a MIB guy and did not review the definitions.  The security
>> considerations section mostly addresses SNMP related considerations in
>> general via references to other specs.  This seems fine.  The only minor
>> nit here is the following:
>> 
>> 	Implementations MUST provide the security features described by the
>> SNMPv3 framework (see [RFC3410]), including full support for
>> authentication and privacy via the User-based Security Model (USM)
>> [RFC3414] with the AES cipher algorithm [RFC3826].
>> 
>> RFC3410 only defines support for use of CBC-DES.  If support for AES is
>> intended instead of DES, that should be noted more strongly here.  The
>> requirement for "full support" of RFC3414 could be misinterpreted.
> 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview