[secdir] Secdir early review of draft-ietf-mpls-mldp-multi-topology-05

Christian Huitema via Datatracker <noreply@ietf.org> Fri, 03 May 2024 05:42 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7E1C14F693; Thu, 2 May 2024 22:42:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christian Huitema via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-mpls-mldp-multi-topology.all@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171471494247.48444.5882617286909060303@ietfa.amsl.com>
Reply-To: Christian Huitema <huitema@huitema.net>
Date: Thu, 02 May 2024 22:42:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Zjb3-S1U4uOzBzdqEh1ln6ereI4>
Subject: [secdir] Secdir early review of draft-ietf-mpls-mldp-multi-topology-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
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, 03 May 2024 05:42:23 -0000

Reviewer: Christian Huitema
Review result: Ready

I have reviewed this document following a request from the routing Area
director to the security directorate. This is an early review, for the benefit
of the security area director, the transport area director, and the document
authors.

Multi topology routing using MPLS. As I understand it from my 10,000ft high
point of view, within a graph of routers and links, instead of just computing a
single set of forwarding tables with a single routing metric such as "shortest
path", MTR allows for computing multiple such forwarding tables, each using
specific metrics and possibly specific constraints. Each set of forwarding
tables and selected paths is regarded as a topology.

The multiple topologies can be computed using the Multi-Topology Routing (MTR)
extensions to IGP such as OSPF or IS-IS, or the MTR extensions to the Label
Distribution Protocol (LDP). The draft is concerned with creating such
topologies using MPLS, starting with point to multipoint or multipoint to
multipoint MTR graphs established with Multipoint LDP (mLDP).

The flexible algorithm (FA, RFC9350) is used to create sub-topologies from
existing topologies, by applying constraints. The draft goes no defining the
protocol elements to add such functions to LDP, defining topologies for IPv4 or
IPv6, ensuring support for multipoint, or defining how to use Label Switched
Path (LSP) Ping to test the topologies.

Such drafts may be easy to read when people are very familiar with the current
work in the routing area. For me, they were a bit of a stretch. I would
probably need much more time than assigned to this review to fully understand
how the various mechanisms interoperate, beyond the 10,000ft view mentioned
earlier. My high level summary would be that this draft defines an extension,
so simple mechanisms like LDP can now be used to create a variety of
topologies. The classic risks with extensions are resource exhaustion and the
difficulty to manage the increased complexity.

The security section says that "This extension to mLDP does not introduce any
new security considerations beyond that already apply to the base LDP
specification [RFC5036], base mLDP specification [RFC6388], and MPLS security
framework [RFC5920]."

That may very well be true, but I would encourage the authors to examine at
least two risks: creating multiple topologies create additional work in the
"control plane", thus potential resource exhaustion if trying to support too
many topologies; traffic carried by multiple topologies may end up competing
for finite data plane resource, thus risking local overload. I am speculating,
but have the authors studied the corresponding failure modes? How hard is it
for configuration mistakes or adversarial actions to exploit such failure modes?