[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 []) by mail2.ihtfp.org (Postfix) with ESMTP id 4703EE2042; Fri, 1 Nov 2019 14:42:15 -0400 (EDT)
Received: from mail2.ihtfp.org ([]) by localhost (mail2.ihtfp.org []) (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 []) (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


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.


* Ready to publish from a security analysis PoV, but I think this
  document Needs work.


* 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 Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant