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

Yoav Nir <> Mon, 10 August 2015 04:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D61A1A88F3; Sun, 9 Aug 2015 21:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hewcFjscYj6B; Sun, 9 Aug 2015 21:36:47 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E1171A88EC; Sun, 9 Aug 2015 21:36:46 -0700 (PDT)
Received: by wicja10 with SMTP id ja10so8678514wic.1; Sun, 09 Aug 2015 21:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:mime-version:to:from:subject:date:in-reply-to:references :content-type; bh=7QoSMiF2HN2kmBtlNYv8IIVYHfmBmFd1cj3cGv+72LQ=; b=swLtiko8+ScCJtQuzm9lHhthLhbfvF8Uklqg7J2L+DchjhyP9pyu56gQw6LVYcq6y8 Wo006eiyOY1XJrWrYozyDC82umdTZeeV/lKgbZ2VAJ3hdr9YvXjtbxc5/HEV4/ODZjOa LQTFM0qncgAtOJS/CwGPbBJgYuz+q/Iwu47qnqLW2WAP9riIvIVCegiDN82xdiO6uEzZ Ph/n0hCpGtkVFukFy2j6RE5kWJ+MgXz4sOXrrQbj1MWgooEx2wu/Q1w6y7a8JKaHi9Mw jA8YwwwDoAxPrO/M/MVnZxHCLkIxZAG/6cqTSUDFzhl7ClFuw8zrVxHAO3DieGpha1u/ kTIw==
X-Received: by with SMTP id ei6mr19589050wib.49.1439181405403; Sun, 09 Aug 2015 21:36:45 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id y13sm27385261wjq.26.2015. (version=SSLv3 cipher=RC4-SHA bits=128/128); Sun, 09 Aug 2015 21:36:44 -0700 (PDT)
Message-ID: <>
MIME-Version: 1.0
To: "Deepak Kumar (dekumar)" <>, secdir <>, The IESG <>, "" <>
From: Yoav Nir <>
Date: Mon, 10 Aug 2015 07:36:44 +0300
In-Reply-To: <>
References: <> <>
Content-Type: multipart/alternative; boundary="_3C4D5A7B-CB96-4244-B74B-D73BF7494ED8_"
Archived-At: <>
Subject: Re: [secdir] SecDir Review for draft-ietf-trill-oam-mib-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Aug 2015 04:36:49 -0000

Generally you wait to the end of IETF last call and then fix whatever nits you're going to fix. It's up to you, your shepherd (Donald), and your AD.

Contact info should be fixed because all authors need to confirm to the RFC editor that they are ok with the edits. But that is at least two months away.



Sent from my Windows Phone 

-----Original Message-----
From: "Deepak Kumar (dekumar)" <>
Sent: ‎8/‎10/‎2015 5:07
To: "Yoav Nir" <>; "secdir" <>; "The IESG" <>; "" <>
Subject: Re: SecDir Review for draft-ietf-trill-oam-mib-06

Hi Yoav,

Thanks for review and comments. Please advise if we need to fix the nits
and comments and upload new version as I am not sure about procedure of
fixing comments during last call.

Tissa has moved out of Cisco and working in another Company, I don¹t have
privy of his new contact so I will contact him to get new contact and
update the document also.


On 8/8/15, 2:18 PM, "Yoav Nir" <> wrote:

>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