[secdir] SecDir Review for draft-ietf-trill-oam-mib-06

Yoav Nir <ynir.ietf@gmail.com> Sat, 08 August 2015 21:18 UTC

Return-Path: <ynir.ietf@gmail.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 13C771A6F5D; Sat, 8 Aug 2015 14:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mGYuOyD1BVvn; Sat, 8 Aug 2015 14:18:07 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396FD1A6F33; Sat, 8 Aug 2015 14:18:07 -0700 (PDT)
Received: by wibhh20 with SMTP id hh20so105112423wib.0; Sat, 08 Aug 2015 14:18:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=gAtBYhXuWJJtC7Go6+qcNug21jN02uvxV3Uln+uwAU4=; b=VBcWs6cr+q0BiCYikbM4ct2arHM9iKA95niCjtA6+VeJxEUIlszEwKRA/UYx/cAWlJ 1fnLIknifxxgeWKK7ON0kdP/qQS7M5p9mRCFct1cSwSEMXmaH5ERECLEOzICTNRRWdHV Oyg6lEH014MUnT3RnbySWzBqjhxU77LiNLZ96M6fqMn6Ngu2yWR/DZx1XOumG5AGnLPB MJjVoMeTiN6gF/brCchiDAf4vdhH5k3S7bRaPOKtxl6Lu2orCDDrXrUa4mfdN/khi5Jt VfAtRTOxV36Pg7ribEY5BpnlG/NGM/RMsNgZMqQJ5uVcAPLqPmoknxh1RFSYIgsdJf1Z C1aQ==
X-Received: by with SMTP id b4mr10280379wiw.74.1439068685915; Sat, 08 Aug 2015 14:18:05 -0700 (PDT)
Received: from [] ([]) by smtp.gmail.com with ESMTPSA id fo1sm5482762wib.24.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Aug 2015 14:18:04 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <E79C135A-3020-4DE9-86A2-275AC76E7201@gmail.com>
Date: Sun, 09 Aug 2015 00:18:02 +0300
To: secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-trill-oam-mib.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
X-Mailer: Apple Mail (2.2102)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/p7sPxbLJNf1JNI5-PFsVBAIhjys>
Subject: [secdir] SecDir Review for draft-ietf-trill-oam-mib-06
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: Sat, 08 Aug 2015 21:18: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.

TL;DR: The document is ready with nits.

The document contains a MIB for operations, administration, and maintenance (OAM) of TRILL. As is common for such documents, 34 of its 45 pages is section 7 ("Definition of the TRILL OAM MIB module”). Being an expert on neither TRILL nor MIBs I have mostly skipped that section.

Usually with MIB documents, the security considerations for the protocol (several TRILL RFCs in this case) are in the protocol documents, while the security considerations for SNMP are in the SNMP document (RFC 3410). The MIB document only points data that is sensitive (in terms of privacy or information leakage), and data which is dangerous in the sense that falsified or modified data could lead to damage. 

In this document the Security Considerations section does a good job of explaining that modified data can lead to changes in routing and potentially to denial of service. The second paragraph is a little hand-wavy for my taste: 

   There are number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-create. Such objects may be
   considered sensitive or vulnerable in some network environments.

What network environment? Why in some but not in others? The third paragraph is similar:

   Some of the readable objects in this MIB module (objects with a MAC-
   ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.

The section concludes with text that looks very familiar from other MIB documents, basically saying that you should use SNMPv3 because it has protections whereas earlier versions don’t. It is also important to have proper access control rules. One nit is that the section says that the cryptographic mechanisms in SNMPv3 provide “privacy”. As of late we tend to use that word for the protection of information about humans, not so much about link status.

A few general nits:
 - In most documents that I see, the content of sections 1-4 is in a single section.
 - OAM is not expanded before first use.
 - The MODULE-IDENTITY has “TBD” for ORGANIZATION and authors’ names in CONTACT-INFO. looking at a few recent MIB documents, the working group is usually given as ORGANIZATION and its mailing list is given as contact info.