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

[Donald Eastlake <[e-mail]>]

Hi Vincent,

See below at <dee>

>On Thu, Jun 29, 2017 at 3:38 PM, Vincent Roca <[e-mail]>
wrote:
>>Hi Donald,

>>...

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

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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

>>Other comments (not security related):

>>...

>>Cheers,

>>Vincent