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