[RTG-DIR] Rtgdir last call review of draft-ietf-mpls-bfd-directed-26

Andrew Alston via Datatracker <noreply@ietf.org> Thu, 04 April 2024 04:56 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FD1C15107A; Wed, 3 Apr 2024 21:56:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Andrew Alston via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-mpls-bfd-directed.all@ietf.org, last-call@ietf.org, mpls@ietf.org, rtg-ads@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171220661785.52439.11310530719909954079@ietfa.amsl.com>
Reply-To: Andrew Alston <andrew-ietf@liquid.tech>
Date: Wed, 03 Apr 2024 21:56:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/MJRLygkN8f6s98qrQmWN2mxToDI>
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-mpls-bfd-directed-26
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2024 04:56:57 -0000

Reviewer: Andrew Alston
Review result: Has Issues

RtgDir Last Call review: draft-ietf-mpls-bfd-directed


I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document: draft-ietf-mpls-bfd-directed-26
Reviewer: Andrew Alston
Review Date: 04-04-2024
IETF LC End Date: 16-04-2024
Intended Status: Experimental


I have some minor concerns about this document that I think should be resolved
before publication.


The draft itself was well written and clear.  I found no major issues in either
the text of the draft or it's content, beyond the two issues noted below

Major Issues:

In Section 3.1 the BFD Reverse Path field TLV Type and Length fields are both 2
octets (16bits) in length.  The document goes on to state that the Reverse path
field contains none, one, or more sub-TLV's. It further states that these
sub-TLV types may be any sub-TLV type defined for TLV Type 1, 16 or 21 in the
MPLS LSP Ping Parameters registry.

There is no limitation on the length that can be specified in the length field.

This raises the possibility that a length could be used - with stacked
sub-TLV's in the reverse path, to create a very large packet, which could
potentially create a denial of service issue / MTU issue on the path. I've
discussed this with the authors prior to sending this review (and my thanks to
them for their timely responses to my queries) and it is proposed that an
update to the first paragraph of the Operational Considerations section of the
documented be updated from:

When an explicit path is set either as Static or RSVP-TE LSP,
corresponding sub-TLVs, defined in [RFC7110], MAY be used to identify
the explicit reverse path for the BFD session.

When an explicit path is set etierhet as Static or RSVP-TE LSP,
corresponding sub-TLVs, defined in [RFC7110], MAY be used to identify
the explicit reverse path for the BFD session.  If a particular set of
sub-TLVs composes the Return Path TLV [RFC7110] and does not increase
the length of the Maximum Transmission Unit for the given LSP,
that set can be safely used in the BFD Reverse Path TLV.

The second issue - which is related - concerns a potential denial of service
vector in the supplied path lengths.

Should a path defined by these sub-TLV's be of extreme length, irrespective of
it being valid or not, there is a concern that the receiving router, on
attempting to do path matching to the reverse path, could be vulnerable to
resource saturation.  By way of illustration, the document states that any
sub-TLV in the LSP ping parameters registry for types 1, 16 and 21 may be used.
 By specifying a length of 8192 and utilsing sub-TLV 14 (Generic IPv4 Prefix as
specified in RFC8029), a path of 2048 elements could be constructed.  It's
unclear how a receiving router would handle the processing of this. Similar
scenarios can occur when paths are specified in terms of IPv4 IGP-Prefix
Segment ID's which can be stacked.

Effectively, there is a concern that through the use of long paths - valid or
not valid - it may be possible to create resource starvation on the receiving
router by spamming these packets.  This is slightly mitigated by the fact that
these packets will be inside a limited domain, however, that does not mitigate
the concern should said limited domain be compromised to allow for such

Minor Issues:

No minor issues found.