Re: [trill] Routing directorate review of draft-ietf-trill-channel-tunnel
Donald Eastlake <d3e3e3@gmail.com> Wed, 04 May 2016 16:05 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 AD9C912D992; Wed, 4 May 2016 09:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 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, 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 zUAGMgQgh7Ni; Wed, 4 May 2016 09:05:34 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 68CDA12DAB8; Wed, 4 May 2016 08:57:54 -0700 (PDT)
Received: by mail-ob0-x229.google.com with SMTP id x1so22814505obt.0; Wed, 04 May 2016 08:57:54 -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=68tuZO4L8Lbn/BSZPvIh1isEkH8tyl0m0DIFzHlH5MQ=; b=xn7vxPS8fnCGy6I0vloOcW89aMvFSmU4i703w+jabrOsg+yaEADkV8kcVZCZ2Tv2Sv +XM1odDrs21W0qjcWOO8iwGL2ZUPztOPL5iMvZwqrUwYRGX0Je8BbSy9/38lDS5I3Cvu /YmjkaseQFiORCeLPVyoMbE/JhZGFIQN//7VCGy4vbN4Li9QhezRzHiU5AEcnosnPZXw KhvNebAqRxsxX3xYx4bEpr9dOYmFvBRXNMwqP812I9IPDsqRzeiyktDvMMRAAJlIydC7 uSnUuKxPO5SpKEXl7Tq1bk1p4Y0QEszYowJA/c+5IFfvf64dhcJSCQ07++7r47Mg7jxB WUxQ==
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=68tuZO4L8Lbn/BSZPvIh1isEkH8tyl0m0DIFzHlH5MQ=; b=QOwH0WPzui1zGgeJI/8MMK+hOe0jmw3wINY8KTH4WwJobP+Em6N2glqTKn0jTCBLTU oOfDoPtt38TyrmBSSEnB19vowCHeOwLlY+cL79EOOFtUfQDu64cYw391fBo8UFGNmyuE urW5JUy+nYnBLUUJ6bVBnRARmpppOwBCtC9SNkbWOeyamf5oVpgNBtYi9/iXsodXoanr ilD06YUB6dzCMS/HZyBGHSdN9nB3HDuHfLtwTPTBkW4FJ5ZEIqrxQYmW1uPMHx8EyoPz O0cVH+UUV6MCeYWVXfHc7kdyi1x/3+sUEO1EZ/bLVh1LyuuAW6GK/y4QIf3gz2v20+zQ Pm3A==
X-Gm-Message-State: AOPr4FWLrln6J75wpJlf/NpFaodPbfMR05UUgE0kgOfBLcf9vzjMHefYntgdoes54vwGjaMhc7OPzMhWgCiGPA==
X-Received: by 10.182.162.36 with SMTP id xx4mr4455637obb.74.1462377473807; Wed, 04 May 2016 08:57:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.22.216 with HTTP; Wed, 4 May 2016 08:57:39 -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: Wed, 04 May 2016 11:57:39 -0400
Message-ID: <CAF4+nEEqD=jSPJy5UNK3L2o6HYZov5pi=FED_4qThA3DfyxzvQ@mail.gmail.com>
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
Content-Type: multipart/alternative; boundary="e89a8f83a4fbda98cf0532064991"
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/ezXr_zyyDWrPc7a-KHLRNGtJiHw>
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: Wed, 04 May 2016 16:05:40 -0000
Hi Jonathan, Thanks for agreeing that the suggested changes resolve our comments. I think they are pretty much editorial/clarification so I'll go ahead and post a revision incorporating them. 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>; > 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 >
- [trill] Routing directorate review of draft-ietf-… Jonathan Hardwick
- Re: [trill] Routing directorate review of draft-i… Donald Eastlake
- Re: [trill] Routing directorate review of draft-i… Jonathan Hardwick
- Re: [trill] Routing directorate review of draft-i… Donald Eastlake
- Re: [trill] Routing directorate review of draft-i… Alia Atlas
- Re: [trill] Routing directorate review of draft-i… Donald Eastlake
- Re: [trill] Routing directorate review of draft-i… Jonathan Hardwick