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

From: Vincent Roca <[email-masked]>
Date: Thu, 29 Jun 2017 10:47:47 +0200

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.

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.

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.

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

Cheers,

  Vincent

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 29 Jun 2017 15:10:14 -0400

Hi Vincent,

Thanks for your review.

> add a dedicated paragraph with the threats, counter measures and mitigation techniques

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.

>      the transition and perhaps the beginning of this paragraph that is not so clear to me.

OK.

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

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

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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Vincent Roca <[email-masked]>
Date: Thu, 29 Jun 2017 21:38:19 +0200

Hi Donald,

> Thanks for your review.

You’re welcome.

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

Okay, do whatever you think is appropriate and clarify the threat model as well. 
If going down to Sz is the only threat, then this is not a big deal I agree. It just
needs to be clearly stated.

> reference to Section 2 added to the new paragraph 3.

Section 1 has a somewhat complex structure. It was my first time to TRILL,
and found it difficult to follow. But this comment is not part of the official
SECDIR review ;-)

Cheers,

  Vincent

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 29 Jun 2017 16:45:48 -0400

Hi Vincent,

See below at <dee>

>On Thu, Jun 29, 2017 at 3:38 PM, Vincent Roca <[email-masked]>

>>...

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

>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

Okay, do whatever you think is appropriate and clarify the threat model as
well.
If going down to Sz is the only threat, then this is not a big deal I
agree. It just
needs to be clearly stated.

<dee> How about the following for a revised Security Considerations
section?

   This document raises no significant new security issues for
   TRILL. In TRILL, RBridges are generally considered to be trusted
   devices. Protection against forged TRILL IS-IS PDUs, including
   forged Hellos containing originatingSNPBufferSize APP-subTLVs, can
   be obtained through IS-IS PDU cryptographic authentication
   [RFC5310]. The worst that an RBridge can do by reporting an
   erroneous originatingSNPBufferSize is reduce Lz to Sz and thus make
   unavailable the optimization of being able to use link MTUs that
   exceed the campus wide MTU for link local TRILL IS-IS PDUs.

   For general and adjacency related TRILL security considerations,
   see [RFC6325] and [RFC7177].

<dee>Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

>>...

---

From: Vincent Roca <[email-masked]>
Date: Thu, 29 Jun 2017 22:51:05 +0200

>    see [RFC6325] and [RFC7177].

From my point of view, it’s okay.
Thanks,

  Vincent

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 29 Jun 2017 22:31:44 -0400

OK. Thanks.

Donald