Early Review of draft-ietf-trill-channel-tunnel-07
review-ietf-trill-channel-tunnel-07-rtgdir-early-hardwick-2016-04-28-00

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

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

2

nd

 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.