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

Request Review of draft-ietf-trill-mtu-negotiation
Requested rev. 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 Eastlake, Radia Perlman, Somnath Chatterjee
Draft 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 Carpenter (diff)
Genart Telechat review of -06 by Brian 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 rev. 05 (document currently at 08)
Review result Has Issues
Review 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.


** 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"