Re: [secdir] Secdir review of draft-ietf-trill-mtu-negotiation-05
Donald Eastlake <d3e3e3@gmail.com> Thu, 29 June 2017 20:46 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7BB12EAE4; Thu, 29 Jun 2017 13:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXbinwuzafl5; Thu, 29 Jun 2017 13:46:04 -0700 (PDT)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC4412EAC4; Thu, 29 Jun 2017 13:46:04 -0700 (PDT)
Received: by mail-it0-x22b.google.com with SMTP id m68so51945161ith.1; Thu, 29 Jun 2017 13:46:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M/L0OrHL//SLvjhPVBQjVWHH7kZikwebuV5dCGhoeE4=; b=eg2OcwRuqg0lINjPDTiexW/U1u745ZazELmmzRQv4FYVxMmW0fufylK8P/yAbgOrPr x7gbqfeoV1WFlN6jfM11lVax+MaWYpkcIT6+qtIiYeDr2hJS2uuiUDd554ZZ4Guqwfka seK4TaIsb/m07saOacopYhxoHoCrUSLUkQvIWh0cAtqDjJhPVndCIhNabUPBQzuBYnDu A98u9Bi8P8kuOtV2/YB/djBLgdWQzfInBHzcvOz+QGQUB2MD/dzHVzM0ooZcvuvtGoa3 3xLt4nFMwQMBLxNsWtOjYlCB1ojGvKpSDxB4Ygg9v/mZmoxW/mv+BlZj/6EIJV11UyJj tKDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M/L0OrHL//SLvjhPVBQjVWHH7kZikwebuV5dCGhoeE4=; b=CD5+JMkdO9HlEjvM4VBqVKNyKx7EDOejkLED0Q8YY0GB2fmwrJAqYyDeLzPmoOySI4 bBKSH1JX00zZRUQJWIENsn/01x6Yn1lLCQJz8Lm1FU3kkR9ZQlnT0JQkdsgwHfCiJOD5 PloNbXQCax6gjuQt5ONGqJOTuOT6GzAlwSdCDG50xaLE37xKV16CElZOFW+o7Qnr2FK4 yNOMx80TDS+OR8j+DFDV1EQRfl0dY4phjiINWliyz9+ybUgE1gyiEGUEXYhoij41WMFA K5JiXSy3DFFj2PsYPI6k63mYaWlnFx5pf6R+qjAy3vADrBBUXkt76QSJMKMMsGU3Kiud DoOg==
X-Gm-Message-State: AKS2vOx+t2PVy3tDcNjMjWt8HHj36tAv5SjyL5c/AfEXCg+Us4uNLc2e UmaU4gvIZGM5bo1G5RJ05z6lqu8AXS2uz1s=
X-Received: by 10.36.3.11 with SMTP id e11mr4160193ite.79.1498769163582; Thu, 29 Jun 2017 13:46:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.221 with HTTP; Thu, 29 Jun 2017 13:45:48 -0700 (PDT)
In-Reply-To: <935C94F4-DC5C-47C3-BE71-5939BD3E11B9@inria.fr>
References: <C9487779-64F7-4BB2-AA29-0828108AD4A8@inria.fr> <CAF4+nEF3JaeCHeE-QL=Ew87KjY5oNyrrJYY78_NYO29jwJ-JAA@mail.gmail.com> <935C94F4-DC5C-47C3-BE71-5939BD3E11B9@inria.fr>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 29 Jun 2017 16:45:48 -0400
Message-ID: <CAF4+nEHVRsN7j2RxSHsGuu4c7vjQ4+-FX9qtjv1BOozW3v4cKA@mail.gmail.com>
To: Vincent Roca <vincent.roca@inria.fr>
Cc: IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-trill-mtu-negotiation.all@ietf.org
Content-Type: multipart/alternative; boundary="001a1147dbec98cd5105531f63d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/FXSTPIwBwFurAfYsRNPhQb-hy58>
Subject: Re: [secdir] Secdir review of draft-ietf-trill-mtu-negotiation-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jun 2017 20:46:06 -0000
Hi Vincent, See below at <dee> >On Thu, Jun 29, 2017 at 3:38 PM, Vincent Roca <vincent.roca@inria.fr> 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 +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>Other comments (not security related): >>... >>Cheers, >>Vincent
- [secdir] Secdir review of draft-ietf-trill-mtu-ne… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-trill-mt… Donald Eastlake
- Re: [secdir] Secdir review of draft-ietf-trill-mt… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-trill-mt… Donald Eastlake
- Re: [secdir] Secdir review of draft-ietf-trill-mt… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-trill-mt… Donald Eastlake