Re: [trill] Stephen Farrell's No Objection on draft-ietf-trill-channel-tunnel-10: (with COMMENT)

Donald Eastlake <d3e3e3@gmail.com> Wed, 06 July 2016 17:58 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 C6F0812D16F; Wed, 6 Jul 2016 10:58:37 -0700 (PDT)
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 bTU_DRXr1hPC; Wed, 6 Jul 2016 10:58:35 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 4C11A12D13B; Wed, 6 Jul 2016 10:58:35 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id r2so281375477oih.2; Wed, 06 Jul 2016 10:58:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GTSA2MvjR4p7RaYVQuy/jvjVeClV0B+fVBaMZKXHYww=; b=cg5hgP9R6eW5RRuoKU6emIfGhgAsgev+ddNGIN3mY8iR/pl/9ZpxQR5slH9+SeBl0R 9jTl4xQsyoJsNANMsPZjtjzVSlO11TVunv09pjuF+gkuFVa3Qm2+CBiTx64JpEq6nnDR QINKJ+MKqzdeCaIfMXH7C5KLDNMz1LMyhbiWc2AdQrAUL892jDw+FnJ5/IKWhLy17YnC cGVxjYdPob1LCtEBi1cVq3y59Sv4vSepXIZx0mTS+Yi9CPEtRaW5m5FI1GavMq5btvaS vH0VCytSXjiDJfTx03U5Lwc9LorjAT7HZoSU7vWVAUNJ5q6geBrgGG1jB0qK/ndX7gbw 37yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GTSA2MvjR4p7RaYVQuy/jvjVeClV0B+fVBaMZKXHYww=; b=dIJ6ra4ilNNwD9iZUWnneTM+cR6VfpOAW/JHjUg0JSrTQ9IyNQNklIRzOSBtU19D3i ZmX5xWVUdMRPRDmE7Pi3SATe0qroW4RuAfDARGEvi/RW6fnJfHpjBT25xA4bf1fcWEnX 0JuqdTG6/LNUkNAPQBmbvf+TN0fv62ICjG94jku4INxa6PaXLM470PZ9ZDzailF76bsx hUSxv08b9wFntlt0/BEP4mvQwBBdcnf9C0iyVzgpAiu23QB3ZY8HQzmmnDlhZgt4iTLb nyCKYkx/r2hp5NTarSFLxIJpHB/nrMyfiY34bz0fS8ZRzeM/9+f38TCOZKEK8Q3s9sNo 5WuQ==
X-Gm-Message-State: ALyK8tI0dv88sxfg74NpnL+/hUi+Cw7/f4l7p6X/RqlpVj5dX0pmaObblv0LmNDCTza5+zWGQx98GFe1IWP/Eg==
X-Received: by 10.157.47.103 with SMTP id h94mr11737402otb.170.1467827914474; Wed, 06 Jul 2016 10:58:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.242 with HTTP; Wed, 6 Jul 2016 10:58:20 -0700 (PDT)
In-Reply-To: <20160706153730.26828.14541.idtracker@ietfa.amsl.com>
References: <20160706153730.26828.14541.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 6 Jul 2016 13:58:20 -0400
Message-ID: <CAF4+nEFZmT4zxn5XOCJCg9QE-OVbJqoWYqWAHigt+Wr9E=kahw@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/9wH_0MH12CdFCSYyHYNcfZiJxjU>
Cc: draft-ietf-trill-channel-tunnel@ietf.org, "trill-chairs@ietf.org" <trill-chairs@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-channel-tunnel-10: (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: Wed, 06 Jul 2016 17:58:38 -0000

Hi Stephen,

Thanks for your comments. See below.

On Wed, Jul 6, 2016 at 11:37 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie>\ wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-trill-channel-tunnel-10: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - The write up for this and the other trill docs on this
> telechat talks about "directory services" but that's not
> mentioned in any of the drafts. Pointers to RFC7067 would
> probably have saved me a few minutes:-)

Yes, the main directory services draft is
draft-ietf-trill-directory-assist-mechanisms which is a fairly large
draft and, in my estimation, almost but not quite ready for IETF LC.
However, the security facility in the trill-channel-tunnel draft is
pretty general and is referenced (usually Informatively) by RFC 7783,
draft-ietf-trill-p2mp-bfd, draft-ietf-trill-address-flush, and
draft-ietf-trill-rfc6439bis as well as by the
trill-directory-assist-mechanisms draft.

How about adding a sentence at the end of the Introduction, something
like:

   It is anticipated that these facilities will be used in support of
   TRILL Pull Directory messages ([RFC7067], [DirectoryMechanisms])
   and to secure a variety of RBridge Channel messages including those
   describedmin [AddressFlush], [p2mpBFD], and [rfc6439bis].

> - That RFC5869 is not in the downref registry is odd.  I'd
> say we should just add it there. It's true though that I
> think this seems to be the first stds track doc with it as
> normative [1] but I figure it's safe to add with no new LC
> stuff.
>
>    [1] http://www.arkko.com/tools/allstats/citations-rfc5869.html
>
> (Apologies that there's no TLS for [1] :-)

Thanks.

> - 4.3: Can the verifier deterministically tell from the
> context that the keyid here refers to the derived key as
> defined in 4.1 and not to (what I guess is) a "bare" key as
> per RFC5310? Do you need to say that?

The document should probably say that for Extended RBridge Channel use
it always refers to a derived key.

> - 4.4 or section 7: Do we know that there are no issues with
> DTLS packets exceeding the MTU but where implementations
> won't work, perhaps with a cert chain. DTLS does support
> that, but do implementations that are likely to be used
> here? If not, maybe a warning is needed. Or, do you need to
> warn against cert based ciphersuites on the basis that
> nobody knows what to put in certs for trill? Given that you
> are (wisely) punting on group communication, maybe you could
> also say that only PSK ciphersuites are to be used here for
> now, and then also address cert based ciphersuites when you
> get around to figuring out group keying?

I don't know if there will be issues. I feel uncomfortable requiring
that only pre-shared key be used -- that seems very limiting. It is
true that certificates for this use in TRILL are likely to be part of
some proprietary/enterprise hierarchy within a data center or the
like... It seems reasonable to state explicitly that specification of
appropriate Certificate contents is out of scope for this document and
perhaps also say that it is anticipated that it will be covered in a
future document.

> - section 7, 3rd para: I do worry a bit about that, but
> you've called out the risk I guess. If it were possible to
> add more guidance as to how to defend in depth that'd be
> good I guess.

Well, other than making the wording a bit stronger, I'm not sure there
is much to do.

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