Re: [secdir] Secdir review of draft-ietf-trill-mtu-negotiation-05

[Donald Eastlake <[e-mail]>]

Hi Vincent,

Thanks for your review.

On Thu, Jun 29, 2017 at 4:47 AM, Vincent Roca <[e-mail]> wrote:
> Hello,
>
> 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
> exist.
>
> 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.

I have no problem with saying a bit more about this.

However, I reject the idea that this document needs to fill all the
gaps you see in all the Security Consideration sections of TRILL RFCs
on which it is dependent. The goal of this document is to allow TRILL,
for link local IS-IS PDUs, to make us of a link MTU (Lz) that is
higher than the campus wide MTU (Sz). With regard to this feature, the
worst that a misbehaved RBridge could do would be to constrain Lz to
be equal to Sz which really isn't a bit deal.

In TRILL, RBridges are trusted devices and there are just all kinds of
ways they can screw things up by advertising false or malicious
information.

As I say, I have no problem with adding a couple of sentences clarifying this.

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

OK.

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

Well, Section 1 is more of a general introduction about the topic of
TRILL MTU while Section 2 is more specifically about the link local
MTU feature. I think perhaps that paragraph 2 should be split right
after the sentence currently beginning with "In other words," and a
reference to Section 2 added to the new paragraph 3.

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

Sounds like an IETF tools bug to me.

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

Fixed in version -06.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Cheers,
>
>   Vincent