Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)

Donald Eastlake <d3e3e3@gmail.com> Thu, 02 March 2017 22:47 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6F91293F8; Thu, 2 Mar 2017 14:47:25 -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 18DMX_oxSN9Z; Thu, 2 Mar 2017 14:47:24 -0800 (PST)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 3FCEC128E18; Thu, 2 Mar 2017 14:47:24 -0800 (PST)
Received: by mail-io0-x22d.google.com with SMTP id 90so63970625ios.1; Thu, 02 Mar 2017 14:47:24 -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=ZMisJE+z6/m0xquq4TnPhAKCtEpXrAnM8vovurQeCyk=; b=i0ymLEv6OyX/GBGJTatY0ZiFUwTg1AyjsCa1dMXuzULPnaSN98MMwQwGbJfI4A1JBa Ar0kWBEi9llHSmu/ZvIT7eHPGQID9lT7nkYwhl253IsDiAQnYv0gYX/cQJg+FVMev6cw 9W8uuYngY9MxGkgP2CnbkKvMS1GbDyVH9XcT0PN4qcwejcPXFSOjEAB9NlINDjyUWlnH PhY4QJqB3EkSKsFDKAQO6rmHyrRPS99RKptEE96YBncvP/1C6+NS60DbsYLT/17vpU70 /q214gZpe1tgPRppBBu3XkkgiQC59iqkxpPFDywUi9q5oS+yAVji5KjZJYdGpVMODi2D ptSg==
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=ZMisJE+z6/m0xquq4TnPhAKCtEpXrAnM8vovurQeCyk=; b=GcouK8uxA3eMZMyDbJwUT9zix6q+dMiULi6MPe6j7IhbXBESOPEIdkr/Lnabht/5n2 nbRXXg5hSDXF8/PPz4/cvlNO6vl6pORu37t8E5T3P0ULc5e+3EmPsnV1o+cI7hxBeKcM X2xHrqkz0iLotX8UCBvZwj6hs3R94LlZvRyXjHAabm0jfSxUF3lmGsuRpZMLIqAP8IRa 8nv8LDdqsOH+4uhoOzRb8n/EkClh3ij+uIGhs2dqCNayOlXoxrQ8oRxaMtyb6CLYBuYs 0qkygzP3uODeg8ZphqC31VSOWo3vHqWyb66kqoXVNJTx69h6mLgk1LIq6S+pGzXok7b9 GNIA==
X-Gm-Message-State: AMke39mGnk1gAy6rKK2taXkyBZJovkJc7lP0ssOzlCXp2IQ0yK2tuQ+GGbZF4oERbjTuRzbRzC6a1YgS14edKQ==
X-Received: by 10.107.20.148 with SMTP id 142mr193952iou.12.1488494843540; Thu, 02 Mar 2017 14:47:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:47:07 -0800 (PST)
In-Reply-To: <148482836602.10328.15276840045846655138.idtracker@ietfa.amsl.com>
References: <148482836602.10328.15276840045846655138.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 2 Mar 2017 17:47:07 -0500
Message-ID: <CAF4+nEGFg2vmc-e3MUxgmr2pm4Xid+RM9jFue-0LEJ3unarvXQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/tR1AxBKxNw4MMBuHkn0O4UINKAg>
Cc: "trill-chairs@ietf.org" <trill-chairs@ietf.org>, draft-ietf-trill-directory-assist-mechanisms@ietf.org, The IESG <iesg@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-directory-assist-mechanisms-11: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 22:47:25 -0000

Hi Stephen,

Thanks for your comments. See below and version -12 just posted.

On Thu, Jan 19, 2017 at 7:19 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-trill-directory-assist-mechanisms-11: No Objection
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - 2.6: I wondered why this was useful. Is it for cases where
> the secondary push service is differently connected or is it
> in case the primary goes down? Might be good to say.

The reasons for multiple directory servers are resilience, increase
the bandwidth of directory services, and to make them more locally
available reducing network load. It seems likely that in many cases
the directory information would come from a data center orchestration
service which would have a co-located push directory that would be
used to populate other directories. It seems like you could equally
well ask why the DNS has primary and secondary servers and does zone
transfers to populate the secondary from a primary. People generally
find this sort of thing useful in multiple-server directory
applications.

> - section 6: what security mechanism differences are there
> between the push and pull cases? Why aren't those called out
> here?  Forcing the reader to delve into the various other
> security mechanism RFCs and figure this out themselves seems
> less good.

I don't see it that way. I believe that people will choose what
combination of Push, Pull, both, or no directory they are going to use
and the like based on their operational and efficiency needs. Then
they are going to evaluate, in the context of their network/use, how
important it is to add cryptographic security. So a pointer to the
security available for each type (Push or Pull) of message answers
most implementer needs. That being said, it seems reasonable to add
that IS-IS security, available for Push messages, provides only
authentication, while RBridge Channel security, available for Pull
messages, can also provide confidentiality.

> - section 6: apologies if I asked this before (in which case I
> forget the answer;-) but how fictional/real is the crypto
> stuff with TRILL in terms of the likelihood of it being
> actually used? I ask again, as if the crypto stuff is mostly
> fictional, then I think you ought note that here, given the
> attack surface that the directory function creates.

I'm not entirely sure what you mean by the "crypto stuff with TRILL".
TRILL is built on IS-IS and IS-IS security is quite widely implemented
and deployed. The Push directory message security uses this IS-IS
security and I would expect it to be available in almost all
implementations. On the other hand, TRILL security for RBridge Channel
messages, which can be used to secure Pull directory messages, was
only fairly recently standardized in RFC 7978 so it is less widely
implemented or deployed.

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