Re: [trill] Routing directorate review of draft-ietf-trill-channel-tunnel

Donald Eastlake <d3e3e3@gmail.com> Mon, 13 June 2016 03:34 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 7D6EC12B040; Sun, 12 Jun 2016 20:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 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, HTML_MESSAGE=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 dFw7vxMA8L0o; Sun, 12 Jun 2016 20:34:26 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 BF54F12B03A; Sun, 12 Jun 2016 20:34:22 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id p204so189776370oih.3; Sun, 12 Jun 2016 20:34:22 -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=J6drFay9+IIw3NscdsoWJbjBdo93ZfkjOROWUBp354U=; b=UwnX89YsxYyZPdxBPysvWCZbkP7eKVdxCPIoz5GhR7J35urG5IeL5Ili77TApXAemu qPrb+iYJsAHPWsRTgpgKTSQh90DsfJeT8ZEN/PMe/4jAPD/QFdIaQxVoxRgLUiRVPC6Q 0bz7otaLAGWccvAI0JYNTtbkcwTYq3mXSfyZEBk1e95NXlIkp+jDGIQgqR58WjwD0aHn FlP3GL0tDOumHE55GS0J4Y+EfDErVSKjt2T2cGPJpDkd8Ex4Wk3R8qeyQqz1kahXa3Yx naJpUDa1A03R4DTBney07yKCZ057CVWkewovylk8LO8O9GVYpp3YJ6kT38bl6EvSc7sa bmaA==
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=J6drFay9+IIw3NscdsoWJbjBdo93ZfkjOROWUBp354U=; b=iLAuml3skN2zCZ+Ol48P9AByAOEWgjPI1E1BX8VlhHWPQKB/55h9Ig2mratLPs6R3Y U+5WryrQVt1gKFDQEn3LKeNUMW+ROiJKKkRu0jdvVt/sZe76vQGE3a/hWwdbzjn3RoZQ +gSoewIcHdJuKk4q3tAoJ7RHs6zqPRvip4chjM4aCntxk9oBL+VRMXaudfD+S9vmjzXe YziJpu89fSxHZU4NHBLp9jLwa8Fdgh9rd1TU4Vpba1qQoSTI4Ic09Zwz/NgorRh0rbEV ZVuhe5VCoGoI14nQ3b6Gy2ujDTUYxoYIQ2Kcv1ZKKGC/fc1HaaQrG0qIQzGtdH2wFWJX GnHQ==
X-Gm-Message-State: ALyK8tK1XEbIDQlno7fcJl19vRYBL67TRXYplLZCBOmmSIL9lykZzBSRaMUa7LH0p9vhqqwEHBJobygsrgOUaA==
X-Received: by 10.202.252.146 with SMTP id a140mr6329868oii.81.1465788862053; Sun, 12 Jun 2016 20:34:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.38.66 with HTTP; Sun, 12 Jun 2016 20:34:07 -0700 (PDT)
In-Reply-To: <BY2PR0201MB1910F7DE7A4E40E9920ADBB2847B0@BY2PR0201MB1910.namprd02.prod.outlook.com>
References: <BY2PR0201MB19103E57307C3C19AD96D85E84650@BY2PR0201MB1910.namprd02.prod.outlook.com> <CAF4+nEE5cSc19je42xqN6d3HQRKP1xTTJJ-0Ux_OcpexDsQf6g@mail.gmail.com> <BY2PR0201MB1910F7DE7A4E40E9920ADBB2847B0@BY2PR0201MB1910.namprd02.prod.outlook.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 12 Jun 2016 23:34:07 -0400
Message-ID: <CAF4+nEGX5c5WZ4dKKfvd0zumj59UUUJ47DWH72Y+CuHwzT_qKQ@mail.gmail.com>
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
Content-Type: multipart/alternative; boundary=001a11404a72704498053520907a
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/sk0BmCdlwC9RN2qs31PPZD_kUV0>
Cc: "<rtg-ads@ietf.org> \(rtg-ads@ietf.org\)" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "trill@ietf.org" <trill@ietf.org>, "draft-ietf-trill-channel-tunnel@ietf.org" <draft-ietf-trill-channel-tunnel@ietf.org>, "akatlas@gmail.com" <akatlas@gmail.com>
Subject: Re: [trill] Routing directorate review of draft-ietf-trill-channel-tunnel
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: Mon, 13 Jun 2016 03:34:28 -0000

Hi Jonathan,

draft-ietf-trill-channel-tunnel-09 has been posted which I believe resolves
your comments. It also has other changes in the security portion.

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

On Wed, May 4, 2016 at 7:29 AM, Jonathan Hardwick <
Jonathan.Hardwick@metaswitch.com> wrote:

> Hi Donald,
>
> Thanks for the replies - I agree with the changes you propose.  Please see
> discussion below (look for [JEH]).
>
> Best regards
> Jon
>
> -----Original Message-----
> From: Donald Eastlake [mailto:d3e3e3@gmail.com]
> Sent: 01 May 2016 21:46
> To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
> Cc: <rtg-ads@ietf.org> (rtg-ads@ietf.org) <rtg-ads@ietf.org>rg>;
> akatlas@gmail.com; rtg-dir@ietf.org;
> draft-ietf-trill-channel-tunnel@ietf.org; trill@ietf.org
> Subject: Re: Routing directorate review of draft-ietf-trill-channel-tunnel
>
> On Thu, Apr 28, 2016 at 9:26 AM, Jonathan Hardwick <
> Jonathan.Hardwick@metaswitch.com> wrote:
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this
> > draft. The Routing Directorate seeks to review all routing or
> > routing-related drafts as they pass through IETF last call and IESG
> > review, and sometimes on special request. The purpose of the review is
> > to provide assistance to the Routing ADs. For more information about
> > the Routing Directorate, please see
> > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >
> > Although these comments are primarily for the use of the Routing ADs,
> > it would be helpful if you could consider them along with any other
> > IETF Last Call comments that you receive, and strive to resolve them
> > through discussion or by updating the draft.
> >
> > Best regards
> > Jon
> > ===
> >
> > Document: draft-ietf-trill-channel-tunnel
> > Reviewer: Jon Hardwick
> > Review Date: 28 April 2016
> > Intended Status: Standards Track
> >
> >
> > Summary
> >
> > I have some concerns about this document and recommend that the
> > Routing ADs discuss these issues further with the authors.
> >
> >
> > Comments
> >
> > The draft is overall well written and the specification is quite easy
> > to understand,
>
> Thanks.
>
> >                      but I found some of the terminology and rationale
> > to be confusing.  I would prefer to see this clarified before the
> > document is published as RFC.  Note that this is the first TRILL
> > document I’ve reviewed, so my context comes largely from mailing list
> > searches and the shepherd’s report.
> >
> >
> > Major Comments
> >
> > The motivations for this draft are quite obscure from the perspective
> > of the outsider J which makes it hard for me to evaluate the proposed
> > mechanism.
> >
> > I think the problems that the draft solves should be more clearly
> > spelled out.  From the introduction:
> >
> >    This document updates [RFC7178] and specifies extensions to RBridge
> >    Channel that provide two additional facilities as follows:
> >
> >       (1) A standard method to tunnel a variety of payload types by
> >           encapsulating them in an RBridge Channel message.
> >
> >       (2) A method to provide security facilities for RBridge Channel
> >           messages.
> >
> > I think that number (1) requires more explanation because the RBridge
> > channel already provides a standard method for a variety of payload
> > types to be transmitted without needing the current draft.
> > What tunneling capability is this draft adding?
>
> Good point.
>
> The RBridge Channel facility does provide a "protocol number" which is, in
> essence, the "type" of its payload. However, there are three limitations of
> RBridge Channel: (1) No security; (2) No way to leverage the many existing
> defined Ethertypes as a payload type; and
>
> [JEH] OK, now I understand (2), thank you.  I thought maybe you'd allocate
> Chanel protocol numbers to match Ethertypes as needed, though I now see
> that this would be quite tedious process-wise (not to mention that
> Ethertype has 4 additional bits). [/JEH]
>
> (3) RBridge Channel can only send typed messages either (3a) between
> RBridges in a campus and (3b) between end stations and RBridges on the same
> link. Earlier versions of this draft included mechanisms extensions in area
> 3, for example, for sending RBridge Channel messages between end stations
> and RBridges not on the same link; however, this added significant
> complexity and there appears to be no current need for such extensions so
> they were dropped, leaving only extensions in areas 1 and 2.
>
> [JEH] OK.  Number 3 does sound a bit more like tunnelling than 1 or 2.
> Helps to have the history, thanks. [/JEH]
>
> How about the following change on additional facility 1 in the draft:
>
> OLD
>       (1) A standard method to tunnel a variety of payload types by
>           encapsulating them in an RBridge Channel message.
> NEW
>       (1) A standard method to tunnel payloads whose type may be
>           indicated by Ethertype through encapsulation in RBridge  Channel
> messages.
>
> [JEH] Yes, looks good. [/JEH]
>
> > A significant amount of text in the draft discusses number (2), which
> > secures the channel payload, presumably to cover cases where the
> > payload has no in-built security mechanism.  This appears to be the
> > major purpose of the draft.  The draft achieves number (2) by adding a
> > security shim header between the RBridge channel header and the
> > payload.  One consideration in doing this is to remain backwards
> > compatible with RFC 7178, and it looks like the working group has
> > decided to achieve backwards compatibility by defining a new RBridge
> > channel protocol type called “channel tunnel” – where this effectively
> > means the RBridge channel payload contains an additional security shim
> > which in turn contains an identifier that determines the real payload
> > protocol type.
> >
> > I find the term “channel tunnel” misleading, as the draft does not
> > appear to add any additional tunnelling capability above and beyond
> > the tunnelling that can already be done using RFC 7178.  The draft
> > actually describes an RBridge channel with enhanced security, so a
> > term like “secure channel” would make more sense to me than “channel
> > tunnel”.
>
> OK, I understand why you think that term is misleading. While it seems
> quite reasonable to called the added fields a "shim", note that the
> facility currently called "Channel Tunnel" is quite closely integrated with
> the existing RFC 7178 RBridge Channel facility. For example, there is only
> one error reporting mechanism. Errors in the "Channel Tunnel" facility
> added by this draft are reported as if they were errors in the RBridge
> Channel messages to which the "shim" was added.
>
> I don't actually like your suggestion of "secure channel" as a new name.
> How about re-naming the facility being added by this draft as the "RBridge
> Channel Header Extension"?
>
> [JEH] OK, I like RBridge Channel Header Extension. [/JEH]
>
> I believe that RFC 7783 and only that RFC that references this draft using
> the term "Channel Tunnel" but this is a very minor informational passing
> reference. There are drafts in the publication requested state that
> reference this draft using the term "Channel Tunnel" but it seems that it
> would be relatively straightforward to change the name to "RBridge Channel
> Header Extension" or some other new name in those drafts and even easier to
> change it in drafts still under the control of the TRILL WG.
>
> [JEH] Thanks, this works for me. [/JEH]
>
> > Minor Comments
> >
> > Section 3.1 – “Any particular use of the Null Payload should specify
> > what VLAN or priority should be used when relevant.” – is unclear and
> > no context for this statement is given.  Should be used by what and
> > for what purpose?
>
> OK. How about:
>
>    Any particular use of the Null Payload should specify what VLAN or
>    FGL and what priority should be used in the inner data label of the
>    RBridge Channel message (or in an outer VLAN tag for the native
>    RBridge Channel message case) when those values are relevant.
>
> [JEH] Fine [/JEH]
>
> > Section 4.3 feels like a corollary to section 4.5 and so may be better
> > placed as a subsection of 4.5.
>
> The method of deriving keying material given in Section 4.3 is also used
> in DTLS security as mentioned in Section 4.6 so I think it should remain a
> separate section.
>
> [JEH] OK [/JEH]
>
> > Section 4.6 “The PType indicates the nature of the application_data.”
> > - is potentially open to misinterpretation.  At face value it sounds
> > like you are leaking some potentially sensitive information about the
> > “nature” of the encrypted payload.  I think all you are actually
> > saying is that it indicates whether the payload is an Ethertype, an
> > Ethernet frame etc.  Suggest instead “In this case, the PType value in
> > the RBridge Channel Tunnel Protocol Specific Data applies to the
> > decrypted application_data.”
>
> OK.
>
> > Section 5.2 “with a payload type (PType) indicating a nested RBridge
> > Channel message” – strictly all the PType can indicate is that the
> > payload is Ethertyped; on its own it cannot indicate a nested RBridge
> > Chanel message.  Suggest “and it contains a nested RBridge Chanel
> > message”.
>
> OK.
>
> > Section 6.2
> >
> > “Section xxx of [RFC 7178]” should be “Section 3.2 of [RFC 7178]”.
>
> Right. Sorry about that.
>
> > Don’t you also need a new IANA registry for the “Rbridge Channel Error
> > Subcodes” listed in table 5.2?
>
> My opinion is that, for the first document in which you specify a field
> and some values, it is a judgment call whether you should create an IANA
> registry or not.  If you expect multiple groups to start requesting values
> to multiple purposes, then creating a registry from the start is the way to
> go. On the other hand, if a field is internal to a particular protocol and
> you don't expect any new field values to be assigned until there is a
> significant extension of that protocol, I don't see any problem in
> deferring the registry creation to the second document. This is the second
> document assigning values for RBridge Channel Error Codes so it creates a
> registry for them. It does not create a registry for SubERR field values.
>
> [JEH] OK, just checking, and happy to defer to your judgment here. [/JEH]
>
> > Nits
> >
> > Section 3.2
> >
> > “as describe in” -> “as described in”
>
> OK.
>
> > Section 4
> >
> > “not to met” -> “not to meet”
>
> OK.
>
> > 2nd paragraph – this sentence is quite long and hard to parse.
>
> You're right. Looking at the sentence, it seems fairly easy to simplify
> and split into two sentences. How about the following
> replacement:
>
>    The Channel Tunnel DTLS based security specified in Section 4.6
>    below is intended for pairwise (known unicast) use. That is, the
>    case where the M bit in the TRILL Header is zero and any
>    Outer.MacDA is individually addressed.
>
> [JEH] Looks good. [/JEH]
>
> > Section 4.2 & Section 5.1
> >
> > “As show in” - > “As shown in”
>
> OK.
>
> > Section 4.3
> >
> > “The use Derived Material” -> “The use of the Derived Material”
>
> OK.
>
> > Does Derived Material really need to be capitalized in this section?
>
> Well, it is capitalized in the equation. Seems to me reasonable to
> capitalize in both cases to indicate that a specific type of Derived
> Material is being talked about.
>
> [JEH] OK. [/JEH]
>
> > Section 4.5
> >
> > “can reasonable be” -> “can reasonably be”
>
> OK.
>
> > Section 4.6
> >
> > “minimum MTU Sz” -> “minimum MTU size”
>
> Sz is a standard TRILL symbol widely used in TRILL documents and defined
> in Section 1.1 of this draft. I would prefer to make the following change
> in Section 4.6: "the TRILL campus wide minimum MTU Sz" -> "Sz".
>
> [JEH] OK - sorry, I missed the definition! [/JEH]
>
> > “Actual application_data sent with Channel Tunnel” -> “Actual
> > application_data sent within the Channel Tunnel”
>
> OK.
>
> > Why do you say “application_data” not “application data”?
>
> "application_data" is the name of the field type in DTLS.
>
> [JEH] OK. [/JEH]
>
> > Appendix Z should presumably be removed prior to IETF last call.
>
> While I'm not sure how much help it would be to IESG members or IETF
> participants in reviewing the draft, I don't see any reason for Appendix Z
> to be removed until RFC publication. But at least a notation asked the RFC
> Editor to delete it should be added.
>
> [JEH] OK - please add the RFC editor note. [/JEH]
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA  d3e3e3@gmail.com
>