[secdir] Review of draft-ietf-trill-rfc6439bis-03

Shawn M Emery <shawn.emery@oracle.com> Mon, 09 January 2017 05:08 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95388129A8F for <secdir@ietfa.amsl.com>; Sun, 8 Jan 2017 21:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 86t98C_m0mKP for <secdir@ietfa.amsl.com>; Sun, 8 Jan 2017 21:08:31 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C621295BA for <secdir@ietf.org>; Sun, 8 Jan 2017 21:08:31 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0958UUL014126 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Jan 2017 05:08:30 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v0958Tq5027321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Jan 2017 05:08:29 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v0958ToL026933; Mon, 9 Jan 2017 05:08:29 GMT
Received: from [10.154.169.77] (/10.154.169.77) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 Jan 2017 21:08:29 -0800
References: <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com>
From: Shawn M Emery <shawn.emery@oracle.com>
To: "secdir@ietf.org" <secdir@ietf.org>
X-Forwarded-Message-Id: <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com>
Message-ID: <10ed6c45-a8a7-e62e-78fb-62631442f4b9@oracle.com>
Date: Sun, 08 Jan 2017 22:11:09 -0700
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/1w6dvTa5raGr6CNAika7U3bYbkk>
Cc: draft-ietf-trill-rfc6439bis.all@tools.ietf.org
Subject: [secdir] Review of draft-ietf-trill-rfc6439bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 09 Jan 2017 05:08:32 -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.

This draft updates the Appointed Forwarders mechanism (RFC 6439);
which supports multiple TRILL switches that handle native traffic
to and from end stations on a single link.

The security considerations section does exist and states that this
update does not change the security properties of the TRILL base
protocol.  The section goes on to state that the Port-Shutdown message
SHOULD be secured through the Tunnel Channel protocol (which is in draft
state).  Was this intended to be a normative reference?  The section quickly
finishes with a reference to Authentication TLVs as a way to secure E-LICS
FS-LSPs traffic.  I'm not a TRILL expert and therefore find it difficult to
distinguish between the usage of Tunnel Channels and Authentication TLVs for
securing Port Shutdown messaging.  Could you please clarify?

General comments:

None.

Editorial comments:

s/the need to "inhibition"/the need for "inhibition"/
s/forarding/forwarding/
s/two optimization/two optimizations/
s/messages are build/messages are built/

Shawn.
--