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

Greg Mirsky <> Thu, 04 April 2024 17:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A91EDC1519A4; Thu, 4 Apr 2024 10:05:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PolfwtigwAoF; Thu, 4 Apr 2024 10:05:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 900A7C14CE4B; Thu, 4 Apr 2024 10:05:08 -0700 (PDT)
Received: by with SMTP id 006d021491bc7-5a4b35ff84eso705477eaf.2; Thu, 04 Apr 2024 10:05:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1712250307; x=1712855107;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=c5sp1eKMdfe+CZ9Hhd4Vacvnrt2YncONHmetHu7LTMY=; b=fL9Iyaia7IzEXmnbiH065qHfM/1oTqvNN+ena/JkXbfLmG86lGXcbMa+9r+p4ZOLch bLptjn6Kh/TApfoiuC1i/J42cdHUz1+LeP/MBxyumE/AIs4MInwXS9xIVSRvnxB/tRIj AupLC+1OsBgAQVZo+hzeoGfpn3xKthBDnrFF3ZNQpq0STYdXOD54NMREBW0rzKiRF1ID 01ri70CgdR0LjgAHm2DCJ8q06IdjNbox/Cje12OrHNT2hVWItfD8cUFXu8TudpfbtMcX eg6mKoIzJ0rffs38IKnGr9Bj39VEaHMfakE2+cCpNoFGkJt85yXnZHBCsocWAjl9n/p+ f3Og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1712250307; x=1712855107; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c5sp1eKMdfe+CZ9Hhd4Vacvnrt2YncONHmetHu7LTMY=; b=ZVAG19yHXY6GFz8JplgqOMRGd6+pfKRObzrMck2UWMdsNvGKIPOcJoNXwNzma4mUD1 To+aRggPTy/K42YPKZ975ILVSlMdkIuAHNQyrW9aBfcQgO7t/h03/+ZAoV1CbSeXVM1f rp2T/utyWAUC7XBw2yaklK8mXfcx1JVXdF1nMVw8xP0+9r91YxhHnXGgbj7pzg2v6KGL Dk7MjzZ+EwTOUMxgKD3lphzG8SaBub8wMlkA4QS7rMX5kfIky0kdQ9Tr8E6K6Z7YPWsZ km/ji56Qn5hKl/8nbwrmS0VQRNuTCcO91iW37YJ4DEBqgzd0IY7RXtlxrmjoxokaGUeE Ftww==
X-Forwarded-Encrypted: i=1; AJvYcCU0ZAr9KcBlnsbxfUiYen6HZXX9nKAI8/21GqPQXQtChJgqfeBEs8SgXLRsgq4ih/Rs22jwsKz8Wui4VfiBTCHRFXVVKt+3PJVs3bEWJJFCZ359f2GAzBaJuHuiWMVeHr4L4GSUnMchFbHubhV5lYddEAvtpLveIocaHBCe9a137vGbzyynWk6lSgQtJH9w
X-Gm-Message-State: AOJu0YxAwbTxq8e3+ofNH0wpcgucG37/7Yv6Rf0DYWOUtwqm40PTzVjq p4QX6hlVRWyg90svVFiHs1V6X7bKhMKjl0t2IWVbMVc9GJaOKGvUF+6PYe15kZIcfg/M7bge9Sx WQR6WUe4uRwkYQuGGnatdTQMMjz7sRuwLAJA=
X-Google-Smtp-Source: AGHT+IF7/PTm3X66/b3O1oMHCGdNe79oxYPJ7XPMLK0YiOnGmxTrQBvM/wFOkLaMAbe+h1MAEgq05I/O7wiWCjHI20w=
X-Received: by 2002:a05:6358:59a5:b0:181:6575:1b22 with SMTP id c37-20020a05635859a500b0018165751b22mr3175527rwf.6.1712250307016; Thu, 04 Apr 2024 10:05:07 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Thu, 04 Apr 2024 10:04:56 -0700
Message-ID: <>
To: Andrew Alston <>
Content-Type: multipart/alternative; boundary="00000000000051021e0615485724"
Archived-At: <>
Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-mpls-bfd-directed-26
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Apr 2024 17:05:15 -0000

Hi Andrew,
thank you for your thorough review and constructive comments. As we
discussed, the new working version includes the update addressing your
first question. Please find my notes in response to the second scenario
below under the GIM>> tag.


On Wed, Apr 3, 2024 at 9:57 PM Andrew Alston via Datatracker <> wrote:

> Reviewer: Andrew Alston
> Review result: Has Issues
> RtgDir Last Call review: draft-ietf-mpls-bfd-directed
> Hello,
> 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
> Summary:
> I have some minor concerns about this document that I think should be
> resolved
> before publication.
> Comments:
> 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
> transmission.
GIM>> Thank you for bringing this scenario to our attention. Should note
that the use of the BFD Reverse Path TLV in LSP Ping in SR-MPLS is
considered in more details in draft-ietf-spring-bfd
<>. There, the use
of Non-FEC TLV is recommended for the SR-MPLS environment. For the scenario
that you describe, it seems like the receiver of the MPLS Echo Request
message will evaluate the reverse path constructed based on sub-TLVs and
determine whether it can support it. If the path is deemed invalid, then
the MPLS Echo Reply message will include the Return Code defined in Section
   *  "Failed to establish the BFD session.  The specified reverse path
      was not found" (TBD4).  When a specified reverse path is
      unavailable, the egress BFD peer sends an Echo Reply with the
      return code set to "Failed to establish the BFD session.  The
      specified reverse path was not found" to the ingress BFD peer
      Section 3.1.

What are your thoughts?

> Minor Issues:
> No minor issues found.