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

David Harrington <ietfdbh@comcast.net> Fri, 24 October 2014 14:57 UTC

Return-Path: <ietfdbh@comcast.net>
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 702D81A1A00 for <secdir@ietfa.amsl.com>; Fri, 24 Oct 2014 07:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 4HC-L-hpRuKv for <secdir@ietfa.amsl.com>; Fri, 24 Oct 2014 07:57:41 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24D91A19F5 for <secdir@ietf.org>; Fri, 24 Oct 2014 07:57:40 -0700 (PDT)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-08v.sys.comcast.net with comcast id 72xD1p0032JGN3p012xfs7; Fri, 24 Oct 2014 14:57:39 +0000
Received: from [IPv6:2601:6:6f00:495:d4bd:240f:d0d:8ae5] ([IPv6:2601:6:6f00:495:d4bd:240f:d0d:8ae5]) by resomta-ch2-10v.sys.comcast.net with comcast id 72xb1p00C4s0ioS012xcaQ; Fri, 24 Oct 2014 14:57:39 +0000
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset=windows-1252
From: David Harrington <ietfdbh@comcast.net>
In-Reply-To: <09a201cfef81$51aac740$f50055c0$@juniper.net>
Date: Fri, 24 Oct 2014 10:57:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <19FF9B70-0C5C-4202-B546-11870A1858BD@comcast.net>
References: <D06FB0C8.253DE%carl@redhoundsoftware.com> <09a201cfef81$51aac740$f50055c0$@juniper.net>
To: afarrel@juniper.net
X-Mailer: Apple Mail (2.1878.6)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414162659; bh=kDhzu+sdWL9CK3O83C17R2z7Z+z4VZQvaJXHqTN3gU8=; h=Received:Received:Subject:Mime-Version:Content-Type:From:Date: Message-Id:To; b=k0pa8hUpwQXu6VZRZ3G2DLK3+TcZ+9M2WS/5XqLP56oPF56HzzeRlxYM453M0MhYH nkKICAYj3JqZIc9bZjTJ26msh2YPDBTcFt00D2eS0tilfydbOw27whcGYpdvfhxHFB 2KiNd15NLr/EGc/dV5GUgRZvEmDc/NnAbZ51noMtrVGV0DVJqCHt2ya9i3AUiP8+7d 7KMzNXtOvO4P8FNSGb1Hr6damRAyoySmLGZrD/Ap7ojEkKLCdj6hMMGQGNVtyAu1AT qXmjGsTu24bfRrV3h+hdmpEVZ131S+lU4whW9SnviwWy+yB9UQN0W8VV3aJqmLnSyZ njKxtlDZJ4Iqg==
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/enIE75QVQWn0JOJFBeOdkCceXEA
Cc: 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
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 14:57:43 -0000

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