Last Call Review of draft-ietf-trill-oam-mib-06
review-ietf-trill-oam-mib-06-secdir-lc-nir-2015-08-13-00

Hi.

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.

Yoav