[secdir] sec-dir review of draft-ietf-mpls-rmr-12.txt
Derek Atkins <derek@ihtfp.com> Fri, 01 November 2019 18:42 UTC
Return-Path: <derek@ihtfp.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 EF57A120B17; Fri, 1 Nov 2019 11:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 j1U08ckNmc66; Fri, 1 Nov 2019 11:42:22 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0C3120E25; Fri, 1 Nov 2019 11:42:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4703EE2042; Fri, 1 Nov 2019 14:42:15 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 31012-09; Fri, 1 Nov 2019 14:42:14 -0400 (EDT)
Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 00BA2E2040; Fri, 1 Nov 2019 14:42:13 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1572633734; bh=oDH0lBHHCbtQeGthNSfK2fpoljYy8G+9JDeTe3jOcm0=; h=From:To:Cc:Subject:Date; b=WVqXJuFConJL29NATSmMje9ih3R+Yyfam5n/O2BkSu9t095UMhUi0qmtd4vh04Y3x OsizPKUcXcabsWMsCznkexgcxkUd3ArfYP0e93fRP9Rf4pSHdKxM641eVvWcPz184M cFrrhNG7wRynNyihI0LkFPBRCoGyQAZ62jBiOVWg=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id xA1Ig48I013149; Fri, 1 Nov 2019 14:42:04 -0400
From: Derek Atkins <derek@ihtfp.com>
To: iesg@ietf.org, secdir@ietf.org
Cc: mpls-chairs@ietf.org, luismiguel.contrerasmurillo@telefonica.com, kireeti.kompella@gmail.com
Date: Fri, 01 Nov 2019 14:42:04 -0400
Message-ID: <sjmimo3o2v7.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Ac4z7FXgC0FYjggidgx-djZjuyg>
Subject: [secdir] sec-dir review of draft-ietf-mpls-rmr-12.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 01 Nov 2019 18:42:26 -0000
Hi, 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to publish from a security analysis PoV, but I think this document Needs work. Details: * I feel that the issue of malicious code claiming a noce to be a Ring Master should be duplicated in the Security Considerations section. Specifically, a malicious node can bring down a ring. * I am wondering if the authors have looked at Radia Perlman's Spanning Tree Protocol when looking to detect loops/rings? The main difference I can see is that in STP the goal is to find and eliminate loops, whereas here the goal is to leverage loops for resiliancy. (NB: STP should also leverage loops for resliancy if a link goes down). If nothing else, STP should be referenced as an informational reference. * How does this protocol handle nodes with more than 2 links? For example, let's assume you have two rings that overlap by 2 nodes. For example: R0 . . . R1 . . R7 R2 Anti- | . Ring . | Clockwise | . . | Clockwise v . RID = 17 . v R6 R3 . . R5 . . . R4 . . R13 R8 Anti- | . Ring . | Clockwise | . . | Clockwise v . RID = 18? . v R12 R9 . . R11. . . R10 When R4 sends messages to R3 and R8, how are R3 and R8 supposed to know that they are in different rings? All I can imagine is that this only works if both R4 and R5 are specifically (and manually) configured, because I don't see how the promiscous mode discovery protocol described here would work. I feel the protocol, as described, is missing something. Perhaps the issue is that a node needs to hear the same RID from neighbors on two different links to know that it is a part of a ring. Also, it needs to ensure it never "sends back" a message. What I mean is that, assume R4 sends R8 a TLV saying R18/CW. R8 can then forward R18/CW to R9, but should not send (yet) R18/AC back to R4. Similarly, R5 sends to R13 R18/AC. Only once the two sets of announcements make their way around does the ring "form". At least, intuitively, I feel that's how it *should* work, but I don't feel this document actually captures this. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
- [secdir] sec-dir review of draft-ietf-mpls-rmr-12… Derek Atkins