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

Donald Eastlake <d3e3e3@gmail.com> Sat, 06 August 2016 03:48 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 9EFA112D636; Fri, 5 Aug 2016 20:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.151
X-Spam-Level:
X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 7S08G0IUJ-tc; Fri, 5 Aug 2016 20:48:04 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 D05D812B039; Fri, 5 Aug 2016 20:48:03 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id i31so65443992uai.2; Fri, 05 Aug 2016 20:48:03 -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=QoOJux129+5B8pCMmUzy0CljVhJMIlQxvqocV2v91W4=; b=SmbvO7ylLAspyXisvl3b17XSLx1mDX64QgvRLku+ykDGTFt+3MpiSx6iXGo8DQOZiq l/3BPh63+MaTPnt3V+9Vc5OoV3V15Kno4M6BgnheBXoHoNsFagL6OdMgO67kPuGliUol hi018eR4uv2H1PFAoAKht5yXNMiIpy1KxqO2T2m4r1+ktNSImNlZqOW18Pc3jGwIyMXt rFB4DOULf0Oopkv00vRgGlrpsZ1C6eNCgaeiiT8pWe/Ysgp/VZe9nzWJyjoQoYPoj9en AMwOzph2JkLNtrn8YxcJm+20awsOnWrzrx04L50d/tV9/zlbfp++SyAn1j3Yyd5uEmVK hQig==
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=QoOJux129+5B8pCMmUzy0CljVhJMIlQxvqocV2v91W4=; b=fE2wQLrwZv8qE/3NAQx6ZkRD3zYnJgLLfJejs0nYmVsKlldePw+Gafnn7CjMuYE15z USOrSQ740789ygozdjSZHXA9b5+xORx5lrGljIVJT/Q5OJjl6NPoYLmXZFT6IZehJ47O MnA5MOUGe9XoKaQWj22cMOgCrdZZWWB2prQyCEdg7bVpPgm5Oyb+SbbDlaQ90w0f1tJG mVQ10N0a/MFPaxfAEj+DF0Dw7V5xmMdM9kG0i6csYzJ786lNRwlyEkfKOcFOxJPBL/ql ix3VNRv2rhmaTzgWffD1+iiX+VeNOlDHpQeopTFPoptibzdi7LVTPFtmuGwgr4yXRU/K g42Q==
X-Gm-Message-State: AEkoouvSTIi4B7cj/eE0OgYLWT2M3IInHPDt7g/tlC55ZIcuQCEWIkQjIprOEarQ3nhjorLxcZM0ON95DB69cQ==
X-Received: by 10.159.37.101 with SMTP id 92mr11522119uaz.109.1470455282953; Fri, 05 Aug 2016 20:48:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.104.2 with HTTP; Fri, 5 Aug 2016 20:47:47 -0700 (PDT)
In-Reply-To: <577D6523.7030801@cs.tcd.ie>
References: <20160706153730.26828.14541.idtracker@ietfa.amsl.com> <CAF4+nEFZmT4zxn5XOCJCg9QE-OVbJqoWYqWAHigt+Wr9E=kahw@mail.gmail.com> <577D6523.7030801@cs.tcd.ie>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 5 Aug 2016 23:47:47 -0400
Message-ID: <CAF4+nEFLr=xvFi51Tzmc+EQaqn-c71Joo-ZrY+0uBAFR-STRPA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=94eb2c123f1ccc776305395f0cd7
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/oSy6OT613mZBUHHiNBL-LdloSgw>
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: Sat, 06 Aug 2016 03:48:05 -0000

Hi Stephen,

Version -11 has been posted which is intended to improve the draft in light
of your COMMENT.

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

On Wed, Jul 6, 2016 at 4:08 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>;
wrote:

>
> Hi Donald,
>
> On 06/07/16 18:58, Donald Eastlake wrote:
> > 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'd be fine, but isn't needed if the intended reader (!= me;-)
> would know it already.
>
> >
> >> - 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.
>
> Tend to agree.
>
> >
> >> - 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.
>
> Fair point.
>
> > 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.
>
> If you don't de-scope cert based schemes here then I think that does
> create a need for some guidance about certs. That might be something
> also needed for DTLS uses in IoT though, so good to check with those
> folks (e.g. Hannes or Carsten) before/as doing that. (And we may need
> an OtherName for a MAC address if there's not already one, which I
> forget;-)
>
> So yeah for now saying something like you suggest seems good.
>
> >
> >> - 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.
>
> Yep.
>
> Cheers,
> S.
>
> >
> > Thanks,
> > Donald
> > ===============================
> >  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> >  155 Beaver Street, Milford, MA 01757 USA
> >  d3e3e3@gmail.com
> >
>
>