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

Donald Eastlake <d3e3e3@gmail.com> Wed, 11 January 2017 18:56 UTC

Return-Path: <d3e3e3@gmail.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 19E73129D50 for <secdir@ietfa.amsl.com>; Wed, 11 Jan 2017 10:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ZkyoSfoTgiS2 for <secdir@ietfa.amsl.com>; Wed, 11 Jan 2017 10:56:38 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881F3129561 for <secdir@ietf.org>; Wed, 11 Jan 2017 10:56:38 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id j18so453907ioe.2 for <secdir@ietf.org>; Wed, 11 Jan 2017 10:56:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pBLx00tzIU4DVU476rswI7wZ6wdygva8vQ4aq7fOQ4I=; b=q6fZ6FfSHrweExJicNMXEtN3qkDET8ocwm/J9AR8LsxruQ8xCkg12inY6dVzF8GUYr Iaqz7nQw0+2/9Ynhpmxg06TFPtE8bkd694vpm758tvUEGWdGnHMPbpCf5a5zc3xrOFc9 r0rEFTk8Gs+OiR65IhA1LifjBaXSLx7WvuRYLF4q6yxU74ELDEfGpL7e7jkUySuGZzY6 2fS9mpLNSXDYE1zVYhwY0w+dg2qUy3jC97DX5yOK8muC9fuO44761a1eKb6v90CukIQ8 s27jnAVzdeDpcHHo5ZSVVvHqStY7QVnx6nqZvaRdyswC6KK55PhtdJCAhVSb6a9ZbGRI YtFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pBLx00tzIU4DVU476rswI7wZ6wdygva8vQ4aq7fOQ4I=; b=l/GFUKH1C9BJ5BeoYYd0XTIwDmfqiX8YflQha3NhCQTAiL/tD7vLVQyEoQEdq2IjsG 4sVYAhsyR5HOG2G3Q5pElwoth3fbs8Xjn9rtRJFrOwG++Gb4RUXPU/97SNt1ZBMSnvzN B9uexRZQA90RA4xOnHl03s0xQpwlewl9Q5vyjGynVoY5jCRBGR6Nkfq+zZoZFX+4f6vr 8PrliqCD9/tozgomRtW4+u20GPgrLCaDibEUTIF7ezWdy+SOHTPf5W9k6BSpHF2l0w29 vhwEr1C4LUZvjlq+BHusAWgeMcQF3mjR1rykdNRhoSsK+K5p5NPfLiS1/sc5myZfmEYk +KGw==
X-Gm-Message-State: AIkVDXLr4hdHkUiu+KecGm7PvRt7kEdeK0PoYbqv/mSuuQdSFS2yqhZjKE70tMWOwT+5JqA/NY48e6qNo7sh1g==
X-Received: by 10.107.141.80 with SMTP id p77mr7208253iod.97.1484160997611; Wed, 11 Jan 2017 10:56:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.41.72 with HTTP; Wed, 11 Jan 2017 10:56:22 -0800 (PST)
In-Reply-To: <4a04ae5b-f30c-303e-e035-aa3819c1f691@oracle.com>
References: <92774159-d56b-cc7f-b5cd-b8e17d038475@oracle.com> <10ed6c45-a8a7-e62e-78fb-62631442f4b9@oracle.com> <CAF4+nEGv95DatWkjrFnh9H9qhwtc0fz+OOs-TqZhxaLeiGovyw@mail.gmail.com> <4a04ae5b-f30c-303e-e035-aa3819c1f691@oracle.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 11 Jan 2017 13:56:22 -0500
Message-ID: <CAF4+nEEy6pqri=kA5U5EYYNPmfnMtEW3UKxvni2_wqVyktbZfw@mail.gmail.com>
To: Shawn M Emery <shawn.emery@oracle.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/xS4GLboBHLmSV2qfeNWrt8SuC-4>
Cc: draft-ietf-trill-rfc6439bis.all@tools.ietf.org, "secdir@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 <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: Wed, 11 Jan 2017 18:56:40 -0000

Hi Shawn,

A version -04 has been uploaded with these fixes.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com


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