Re: [secdir] SECDIR review of draft-ietf-trill-directory-assist-mechanisms

Donald Eastlake <> Thu, 02 March 2017 22:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7564D128874; Thu, 2 Mar 2017 14:49:11 -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 YhzqPlgZ8yYC; Thu, 2 Mar 2017 14:49:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A989127601; Thu, 2 Mar 2017 14:49:10 -0800 (PST)
Received: by with SMTP id h10so2867792ith.1; Thu, 02 Mar 2017 14:49:10 -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=8ksP5qmfS93SQlu/z+M7uPet7APj5+aKkSV7tJKI3A8=; b=qxB9WRmnfYrI5JvjZNv49hTzhAstzzFSy2TdJ7PposkPB60INcOfwtnlbrw08xevzM d82oZpOgjs7LG5/+jO/MtM25LtOGGushEcmxDSv37TAnq+kZTOeRJa9ywFP7x/E2LKV6 s06QtWLYtiICv6ISFeKbJVZ4NY84a24ZEu4X0YH9S6V9U2YfW6YRhlddO+joeq4loSq7 3E5U5KSqTOPsDo1r5Eh2ZfC22SIm6nV7HpvbZFyjqDzVkd9yfgHs1qTahMOFQmNZncFw l9S/8A1/W1qghiIKALaEZnBxSzPHndAYJHOk4eXvRzqbw4lxUrFSn8e/qHRT2ot8DekJ +yRA==
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=8ksP5qmfS93SQlu/z+M7uPet7APj5+aKkSV7tJKI3A8=; b=erY/pFqmbkQgr6XBXUtI6E2GvnKbaMo0lj1n55Ike1unSBFyqAbe682FXmjNk8l602 AU2dCSqcl6phnXrgwWjV5kfsJkURKslESyNviq0sGY9lrIQt6BjCk2XKTXmDaYMKyFsw /8Tm4pWbfg72fEfjE+NpaX8gZ597RN7nTygcPvF/VB4eFkIDuYc3UpPv8My/MVjxzBpf fjWN2zvE59MmZiQXoreMHkYjz4HvEJbPPmJkmB5cyJhYj1qspex9b5a/podJkjiYtNPW Ms8qWlynops9vlZey6e9Npxc4ltSXCwai7J4XQNdUcp4fEGsd6vxQeLJLsP/zUtrypru FG5w==
X-Gm-Message-State: AMke39m+dHYKdakaHNubwGfu3aogNIA84jcqypnX0WxC4gpWT9ltY6DHDWH/NaUyIsbcO65sw0DKvwRmL9xJmw==
X-Received: by with SMTP id e70mr195904ite.14.1488494949403; Thu, 02 Mar 2017 14:49:09 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 2 Mar 2017 14:48:53 -0800 (PST)
In-Reply-To: <>
References: <>
From: Donald Eastlake <>
Date: Thu, 2 Mar 2017 17:48:53 -0500
Message-ID: <>
To: Daniel Franke <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc:, "" <>, "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-trill-directory-assist-mechanisms
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: Thu, 02 Mar 2017 22:49:11 -0000

Hi Daniel,

Thanks for your comments. See below.

On Tue, Jan 17, 2017 at 12:52 PM, Daniel Franke <> 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.
> I believe this document is READY WITH NITS. I'm satisfied with its
> normative content but the Security Considerations section could use
> a bit of elaboration.


> I had never heard of TRILL prior to being assigned this review and
> the tree of normative references is a bit daunting, so these comments
> will necessarily be based only on an extremely high-level view of
> the system.
> draft-ietf-trill-directory-assist-mechanisms proposes to augment
> TRILL by adding directory servers which cache information about network
> topology, allowing RBridges to sometimes shortcut the usual learning
> algorithm that they would use to discover this information.
> Here are the fundamental points which the Security Considerations
> section either addresses or ought to address:
> 1. There are three relevant security goals:
>    a. Availability: packets should reach their intended destination
>    b. Confidentiality: packets should not reach unintended destinations
>    c. Privacy: metadata concerning network presence should not be
>       shared more widely than necessary
> 2. Access control to directory servers can be enforced using
>    pre-existing cryptographic mechanisms specified in RFCs 5304, 5310,
>    and 7978.

Well, actually access to directory server messages.

> 3. Principals authorized (duly or otherwise) to read directory data
>    can violate privacy.


> 4. Principals authorized to modify directory data can violate
>    availability and confidentiality.


> 5. Directory servers must therefore take care to implement and enforce
>    access control policies which are not overly permissive.
> The current text of the Security Considerations section directly
> addresses points 1a, 1b, 2, and 4. The paragraph added in version 11 of
> the draft obliquely implies points 1c and 3 but I wish they'd be
> stated more explicitly. But the major omission is point 5: what does
> a correct authorization predicate look like? What sort of access must
> necessarily be authorized in order for protocol execution to succeed?
> What sort of access generally ought *not* be authorized?

The -12 version just posted is intended to resolve these comments.

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