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

Donald Eastlake <> Wed, 11 January 2017 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87559129441 for <>; Tue, 10 Jan 2017 17:04:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EXZDqOp24vFh for <>; Tue, 10 Jan 2017 17:04:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8563129428 for <>; Tue, 10 Jan 2017 17:04:14 -0800 (PST)
Received: by with SMTP id c20so86937870itb.0 for <>; Tue, 10 Jan 2017 17:04:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=unoFXmL9S2PVZ8j9ArIb3OPOj2frpLH66q5kU0Y4Hgk=; b=b8K0NF9vrw1dfghgmpE2bMZBXymujoEyHrsStlGx58Nl4UV4beehyYima8USytVKA7 ib/E0+uSKxS0ddEJ7AWo0nZ28wp1WS9IeO3+hPO7LBQxQoQEX3hmDmPX/sA+1hx20h9S UxFeVz7pprsVmtAXL6GfG8HtKdB5HilwCl3xBMHGJfBJ218gxqp+eiuU8obOVLcbHBea 1yyq7oAn1EUYbxyekj7byaZLv+H7Z8a1gEUJqJNVdZuB6IUGcBlQexR+10yegBDQ8cyl c9sJdfESvGcCYCwHu0vhwRmt4fjnyduAU08DULIdAzvRD4ZNcj7I6ldt2x82t9XXHnhc 0Xxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=unoFXmL9S2PVZ8j9ArIb3OPOj2frpLH66q5kU0Y4Hgk=; b=N4TAUQp9dwyFW1A+i16frvybFMR7QdmsSokWhThsEd6WRbGvCJItOrxAe9tOpC8cYW XjVFQNSaabZ4u5W8Oivw+8Ki5KCJ24A9YW+x5dpi2o7lnMBadDdb+3j8tIk16B0gm+yL NH+YXdeUvUofx0FXmTaH05bAle6EmjX6GpUGl5msxG9Ap5ELF1743DjnUgCsdcBPh84y DcvKZ62ovJ2zVrltxAfIjV1yntxlGkCbl34s+8CiC4bMitjZGQAAK7KwwTnUMdL7GGOa dSEv3DAhQ6PrekGygTixYVTazmbaUtrYhBMIaYM1cQ2RTvGPBa6Aj/z4o1xIL2YkF10d yB2w==
X-Gm-Message-State: AIkVDXIwmeTLgUCMAOEoJAMCm21a1ED162bB8jd4XrcN6+U7YXjgSGrCvlBuYi2u1jSwIN710EwvIg1hD3HjKw==
X-Received: by with SMTP id i67mr5811454itc.59.1484096654028; Tue, 10 Jan 2017 17:04:14 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 10 Jan 2017 17:03:58 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Tue, 10 Jan 2017 20:03:58 -0500
Message-ID: <>
To: Shawn M Emery <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc:, "" <>
Subject: Re: [secdir] Review of draft-ietf-trill-rfc6439bis-03
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: Wed, 11 Jan 2017 01:04:16 -0000

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.

>                                                                                           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.

> 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.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> Shawn.
> --
> _______________________________________________
> secdir mailing list
> wiki: