Re: [trill] Kathleen Moriarty's No Objection on draft-ietf-trill-ia-appsubtlv-09: (with COMMENT)

Donald Eastlake <d3e3e3@gmail.com> Wed, 06 July 2016 17:31 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 648AB12D505; Wed, 6 Jul 2016 10:31:10 -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 DXLkByErAT-M; Wed, 6 Jul 2016 10:31:08 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 4784A12D0EB; Wed, 6 Jul 2016 10:31:08 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id s66so280015818oif.1; Wed, 06 Jul 2016 10:31:08 -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=x5OsVqEBgvBP5lrFGkqEIcnMnv+MSNeHa+ljnsfe2Ms=; b=OPEFLmAqSfX9Ll2a+VPTbIQh2T8gSxv/fNR9rS1z3hwaaHe/qQhhLVvwR68na40Eqi kMYdC9sGXDeiwN6BANY2C5sw29awI0Xa73DNJJ5T4ACqXNCRD/OZdw6dZrfeSU8F1jV2 K8s93Z7AB1cETr+AUDSj5q13k3ty3xr1TQZwfnmkI853hqQVsElc0HihPZDOzQnXAE2/ luYx/+535lO91EMp7yzDzefQPSSPsaExpN9HST43K02Di8iu/8zAwUIXX/Q4AkBVQuAt dt/k47Vatd5R66hmHxiAXDnL8BdVGgmOnLxrYlxYLUUmxD9T8/j1KIJ+H2E2y72nebqN RRgA==
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=x5OsVqEBgvBP5lrFGkqEIcnMnv+MSNeHa+ljnsfe2Ms=; b=ZkzBIU9VlMBHG5RyhWR9FjCRPJeZtztJJ4TGzFJtL/t9pNZeL6t6bnehv+3olQ+7oO pVVd5jFptM+mX9u5wA0J0uQxVSPPJbiEcSyelWEgVBDCU+1aJH4uNOo9ujKNBmuVu/XI JkgZksYrubQ3l2IrcRe4E/ayg+1U4efXrnlKRAP0azi7HbwSKq+oa0vrOYx+rXARoe7U pfHBXlCfNaLatGgq5Hhlfy6L3Y7eTLbiZUvDJFm0g+ycoobuqWlwSFmF/OlAKAZF+sXR +5yV+0eIRwVv9AK5tS8rnNZ0qIVmFUNLlNTQXcW6zhVcKoig24pVUgZKcCw8vC1FOqAD 7a9w==
X-Gm-Message-State: ALyK8tJzre5KhrWYss0FW3bSQwE+dAchimlEKwHe9/PuDPZxu+LSKyMg707sL/hitPfGWRj167d0NHPoS8AGUA==
X-Received: by 10.157.63.240 with SMTP id i45mr14537289ote.102.1467826266724; Wed, 06 Jul 2016 10:31:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.242 with HTTP; Wed, 6 Jul 2016 10:30:52 -0700 (PDT)
In-Reply-To: <20160706160822.26792.44487.idtracker@ietfa.amsl.com>
References: <20160706160822.26792.44487.idtracker@ietfa.amsl.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 06 Jul 2016 13:30:52 -0400
Message-ID: <CAF4+nEE1-RnFK6j8rjoNbkQ2jiwKGhd-QD8-u-gxTdb9-FEJVQ@mail.gmail.com>
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/-6IYsrLFmmkna-_LbsPkWCo6yXI>
Cc: draft-ietf-trill-ia-appsubtlv@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] Kathleen Moriarty's No Objection on draft-ietf-trill-ia-appsubtlv-09: (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:31:10 -0000

Hi Kathleen,

Thanks for your comment. See below.

On Wed, Jul 6, 2016 at 12:08 PM, Kathleen Moriarty
<Kathleen.Moriarty.ietf@gmail.com> wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-trill-ia-appsubtlv-09: No Objection
>
> ...
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> In the Security Considerations, I realize that this isn't the place for a
> recommendation on what to use for transport, but a pointer for the
> recommendation feels likes it's missing in the following text:
>
>    However, this document merely describes a
>    data format and does not provide any explicit mechanisms for securing
>    that information, other than a few simple consistency checks that
>    might detect some corrupted data. Security on the wire, or in
>    storage, for this data is to be providing by the transport or storage
>    used. For example, when transported with ESADI [RFC7357] or RBridge
>    Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel]
>    security mechanisms can be used, respectively.
>
> Also, there is a nit in the second sentence:
> s/providing/provided/

Thanks for pointing out the typo.

It seems to me that the text you quote does point to ESADI and the
Channel Tunnel draft. True, it gives them as "examples" rather than
recommendations... Saying that there should be a recommendation (or
pointer to a recommendation) of what "transport" to use seems very odd to
me. The information the IA APPsub-TLV is designed to hold is, for the
cases that motivated this document, part of some already established
transport system: either "link state" information (ESADI or perhaps
E-L1FS or E-L1CS FS-LSPs) or TRILL Pull Directory responses
(draft-ietf-trill-directory-assist-mechanisms). So I do not, for those
cases, see that you can reasonably recommends a "transport"; all you
can reasonably do is recommend the invocation of the existing security
mechanisms for the already in use transport.

Now, of course, there might be future uses not now anticipated. But
for those, it is not clear to me how to anticipate all the
non-security factors that would affect the choice of "transport". What
good would it do to say that, for example, "IPsec should be used for
transport in other cases" if it turns out the next case needed has end
end-points not identified by IP address and is really some different
paradigm like store-and-forward? If the next future use case happens
to be in a case where it is natural to use IPsec, then you should use
IPsec security. If it is as a MIME body part, then you should use MIME
security. It is is as a DNS RR, you should use DNSSEC/DNSPRIV. Saying
there should be "a recommendation on what to use for transport"
strikes as a bit like saying there should be a recommendation on what
to use for the transport of floating point numbers... But perhaps I
misunderstand you.

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