Skip to main content

Last Call Review of draft-ietf-trill-mtu-negotiation-05

Request Review of draft-ietf-trill-mtu-negotiation
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-06-28
Requested 2017-06-14
Authors Mingui Zhang , Xudong Zhang , Donald E. Eastlake 3rd , Radia Perlman , Somnath Chatterjee
I-D last updated 2017-06-29
Completed reviews Rtgdir Early review of -02 by Julien Meuric (diff)
Secdir Last Call review of -05 by Vincent Roca (diff)
Genart Last Call review of -05 by Brian E. Carpenter (diff)
Genart Telechat review of -06 by Brian E. Carpenter (diff)
Tsvart Telechat review of -06 by Magnus Westerlund (diff)
Assignment Reviewer Vincent Roca
State Completed
Review review-ietf-trill-mtu-negotiation-05-secdir-lc-roca-2017-06-29
Reviewed revision 05 (document currently at 08)
Result Has issues
Completed 2017-06-29

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: Ready with issues

This document introduces a new mechanism to assess a link level MTU for local
TRILL traffic, in addition to the campus level MTU. Therefore I have problems
when the authors explain in the Security Consider that there is no new security
issue: this claim should be detailed. For instance, what happens if an RBridge
misbehaves (deliberately or not) at the link level or at the campus level, and
tries to minimize the Lz (or Sz) size? Reporting an originatingL1LSPBufferSize
smaller than Sz seems to be sufficient at the campus level. What prevents or
mitigates it? This is just an example and I’m pretty sure other possibilities

Since I have the feeling that the « Security Considerations » sections of
[RFC6325] and [RFC7177] referenced by this document do not address this aspect,
I suggest the authors add a dedicated paragraph with the threats, counter
measures and mitigation techniques whenever appropriate.

Other comments (not security related):

** Introduction, second paragraph:
   The sentence "In other words, if this link..." does not paraphrase the
   previous sentence: - the first sentence is about a situation where Link MTU
   X >= campus Sz; - the sentence beginning with "In other words" discusses the
   opposite situation and introduces
     another property: "it will not be reported as part of the campus
     topology". I suggest changing the transition and perhaps the beginning of
     this paragraph that is not so clear to me.

   On the opposite, I find the first few introduction sentences of Section 2
   crystal clear on what is Ls and its relationship to Sz, unlike the


** Introduction: the references [RFC6325] and [RFC7177] that appear at the
start of the first two paragraphs are textual, not pointers to the appropriate

** Introduction: "By calculating a using Lz" => "and"