Return-Path: 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 D2A6212955E for ; Thu, 12 Jan 2017 16:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 D_lCG0QroNtn for ; Thu, 12 Jan 2017 16:22:15 -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 E1A11129554 for ; Thu, 12 Jan 2017 16:22:14 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0D0MB7D020665 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jan 2017 00:22:12 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v0D0MB22015466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jan 2017 00:22:11 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v0D0M962005231; Fri, 13 Jan 2017 00:22:10 GMT Received: from [10.154.98.66] (/10.154.98.66) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Jan 2017 16:22:09 -0800 From: Shawn M Emery To: Donald Eastlake References: <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com> <10ed6c45-a8a7-e62e-78fb-62631442f4b9@oracle.com> <4a04ae5b-f30c-303e-e035-aa3819c1f691@oracle.com> Message-ID: Date: Thu, 12 Jan 2017 17:24:48 -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: Content-Type: multipart/alternative; boundary="------------A336AD94DB98670C636C415D" X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: draft-ietf-trill-rfc6439bis.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:22:17 -0000 This is a multi-part message in MIME format. --------------A336AD94DB98670C636C415D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 01/11/17 11:56 AM, Donald Eastlake wrote: > Hi Shawn, > > A version -04 has been uploaded with these fixes. I have just one suggested update, provided that the update is an accurate statement: OLD: As such, they are securable through the addition to those PDUs Authentication TLVs [RFC5310] in the same way as Hellos or other IS-IS PDUs. NEW: Therefore, they are securable through the addition of Authentication TLVs [RFC5310] in the same way as Hellos or other IS-IS PDUs. and one editorial: s/It this case/In this case/ The rest of the changes looks good to me. Thanks, Shawn. -- > On Wed, Jan 11, 2017 at 12:22 AM, Shawn M Emery wrote: >> On 01/10/17 06:03 PM, Donald Eastlake wrote: >>> Hi Shawn, >>> >>> Thanks for your comments. See below. >>> >>> On Mon, Jan 9, 2017 at 12:11 AM, Shawn M Emery >>> 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. >>>> >>>> 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? >>> That reference is out of date. draft-ietf-trill-channel-tunnel has >>> issued as RFC 7978. That should be updated and I agree that this >>> should be a normative reference. >> Thanks. >> >>>> 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? >>> "Channel Tunnel", although left in the draft name for convenience, was >>> basically changed to RBridge Header Extension. This is a way to add a >>> layer of header to RBridge Channel messages (specified in RFC 7178) to >>> secure their content. The Authentication TLV is an IS-IS TLV and >>> including that TLV in an IS-IS PDU can be used to secure the content >>> of the PDU. Some text can be added to clarify this. >> Ah, I see. Yes, clarifying text would be helpful for the nascent reader. >> >>>> 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/ >>> Thanks for spotting those. We'll fix them. >> No problem. >> >> Regards, >> >> Shawn. >> -- --------------A336AD94DB98670C636C415D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 01/11/17 11:56 AM, Donald Eastlake wrote:
Hi Shawn,

A version -04 has been uploaded with these fixes.

I have just one suggested update, provided that the update is an accurate statement:

OLD:
As such, they are securable through the addition to those PDUs Authentication TLVs [RFC5310] in the same way as Hellos or other IS-IS PDUs.

NEW:
Therefore, they are securable through the addition of Authentication TLVs [RFC5310] in the same way as Hellos or other IS-IS PDUs.

and one editorial:

s/It this case/In this case/

The rest of the changes looks good to me.

Thanks,

Shawn.
-- 
On Wed, Jan 11, 2017 at 12:22 AM, Shawn M Emery <shawn.emery@oracle.com> wrote:

On 01/10/17 06:03 PM, Donald Eastlake wrote:

Hi Shawn,

Thanks for your comments. See below.

On Mon, Jan 9, 2017 at 12:11 AM, Shawn M Emery <shawn.emery@oracle.com>
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.

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?

That reference is out of date. draft-ietf-trill-channel-tunnel has
issued as RFC 7978. That should be updated and I agree that this
should be a normative reference.

Thanks.


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?

"Channel Tunnel", although left in the draft name for convenience, was
basically changed to RBridge Header Extension. This is a way to add a
layer of header to RBridge Channel messages (specified in RFC 7178) to
secure their content. The Authentication TLV is an IS-IS TLV and
including that TLV in an IS-IS PDU can be used to secure the content
of the PDU. Some text can be added to clarify this.

Ah, I see.  Yes, clarifying text would be helpful for the nascent reader.


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/

Thanks for spotting those. We'll fix them.

No problem.

Regards,

Shawn.
--

--------------A336AD94DB98670C636C415D--