Subject: [RTG-DIR] Routing directorate review of draft-ietf-trill-channel-tunnel

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 28 Apr 2016 13:26:00 +0000

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, 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 ☺ 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 tunnelling capability is this draft adding?

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”.

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?

Section 4.3 feels like a corollary to section 4.5 and so may be better placed as a subsection of 4.5.

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.”

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”.

Section 6.2
“Section xxx of [RFC 7178]” should be “Section 3.2 of [RFC 7178]”.
Don’t you also need a new IANA registry for the “Rbridge Channel Error Subcodes” listed in table 5.2?

Nits
Section 3.2
“as describe in” -> “as described in”

Section 4
“not to met” -> “not to meet”
2nd paragraph – this sentence is quite long and hard to parse.

Section 4.2 & Section 5.1
“As show in” - > “As shown in”

Section 4.3
“The use Derived Material” -> “The use of the Derived Material”
Does Derived Material really need to be capitalised in this section?

Section 4.5
“can reasonable be” -> “can reasonably be”

Section 4.6
“minimum MTU Sz” -> “minimum MTU size”
“Actual application_data sent with Channel Tunnel” -> “Actual application_data sent within the Channel Tunnel”
Why do you say “application_data” not “application data”?

Appendix Z should presumably be removed prior to IETF last call.