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

["Mankamana Mishra (mankamis)" <[e-mail]>]

Hi Christian
Thanks for reviewing it.  For comment

“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?
”



  *   In terms of implementation, yes, the total number of flex algo can depend on the hardware resources available. But these constraints are true for any technology so I do not think we need to write it in draft explicitly.
  *   Same comment for the data plane and config issue too.
  *   This draft has been implemented and deployed too. But there is no problem deploying as the specification is defined today.





Please let me know if you have any questions.



Mankamana


From: Christian Huitema via Datatracker <[e-mail]>
Date: Thursday, May 2, 2024 at 10:42 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Secdir early review of draft-ietf-mpls-mldp-multi-topology-05
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?