Re: Comments on draft-ietf-bfd-unaffiliated-echo-05

Jeffrey Haas <jhaas@pfrc.org> Tue, 21 March 2023 17:04 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0864C14CF12; Tue, 21 Mar 2023 10:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM2aPZmQ1CWp; Tue, 21 Mar 2023 10:03:59 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 87292C14F73E; Tue, 21 Mar 2023 10:03:59 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id E39351E039; Tue, 21 Mar 2023 13:03:58 -0400 (EDT)
Date: Tue, 21 Mar 2023 13:03:58 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: draft-ietf-bfd-unaffiliated-echo@ietf.org, rtg-bfd@ietf.org
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-05
Message-ID: <20230321170358.GA3114@pfrc.org>
References: <20230321170257.GA32267@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20230321170257.GA32267@pfrc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/m2SJlfeNMZC_9uqlejyDGJqIMf8>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2023 17:04:01 -0000

[resend with correct draft address]

Authors,

Some comments on version -05:

16	Abstract

18	   Bidirectional Forwarding Detection (BFD) is a fault detection
19	   protocol that can quickly determine a communication failure between
20	   two forwarding engines.  This document proposes a use of the BFD Echo
21	   where the local system supports BFD but the neighboring system does
22	   not support BFD.

It would be good in the abstract to discuss the core idea of this mechanism:
BFD Async procedures can be executed over the BFD Echo port where the remote
system only loops packets back to the local system.

The procedures discussed below cover this, but it takes some time to understand
what the intent is.


73	1.  Introduction
[...]

86	   BFD defines Asynchronous and Demand modes to satisfy various
87	   deployment scenarios.  It also supports an Echo function to reduce
88	   the device requirement for BFD.  When the Echo function is activated,
89	   the local system sends BFD Echo packets and the remote system loops
90	   back the received Echo packets through the forwarding path.  If
91	   several consecutive BFD Echo packets are not received by the local
92	   system, then the BFD session is declared to be Down.

It would be appropriate to reference RFC 5880, section 5 here.  "The payload of
a BFD Echo packet is a local matter".  This draft, on the other hand, specifies
the contents of the Echo packets and what to do with them.

94	   When using BFD Echo function, there are two typical scenarios as
95	   below:

97	   *  Full BFD protocol capability with affiliated Echo function.  This
98	      scenario requires both the local device and the neighboring device
99	      to support the full BFD protocol.

101	   *  BFD Echo-Only method without full BFD protocol capability.  This
102	      scenario requires only the local device to support sending and
103	      demultiplexing BFD Control packets.

The bullet point above is a good place to discuss that the BFD Control packets
are sent over the BFD Echo port, but that the BFD Async procedures are used with
the modifications described in this document.


266	3.  Unaffiliated BFD Echo Procedures

[...]

288	   To rapidly detect any IP forwarding faults between device A and
289	   device B, a BFD Echo session MUST be created at device A, and the BFD

I would remove the "To rapidly detect" clause before the comma and replace it
with "For unaffiliated echo,".  The current wording seems to suggest this
procedure is the only way to detect forwarding faults.

Perhaps also change "session MUST be created" with "session is created".  

290	   Echo session MUST follow the BFD state machine defined in Section 6.2
291	   of [RFC5880], except that the received state is not sent but echoed
292	   from the remote system, and AdminDown state is ruled out because
293	   AdminDown effectively means removal of BFD Echo session.  In this

Perhaps:
"from the remote system.  BFD Unaffiliated Echo does not use the AdminDown
state."

293	   In this
294	   case, although BFD Echo packets are transmitted with destination UDP
295	   port 3785 as defined in [RFC5881], the BFD Echo packets sent by
296	   device A are BFD Control packets too,

Perhaps:
"BFD Control packets are transmitted and received as BFD Echo packets using
destination UDP port 3785, as defined in [RFC5881]."

296	   the looped BFD Echo packets
297	   back from device B would drive BFD state change at device A,
298	   substituting the BFD Control packets sent from the BFD peer.  Also
299	   note that when device A receives looped BFD Control packets, the
300	   validation procedures of [RFC5880] are used.

Perhaps:
"The procedures for BFD Async sessions are executed for the looped BFD Control
packets as per [RFC5880], including validation and authentication."

302	   Once a BFD Echo session is created at device A, it starts sending BFD
303	   Echo packets, which MUST include BFD Echo session demultiplexing
304	   fields, such as BFD "Your Discriminator" defined in [RFC5880] (BFD
305	   "My Discriminator" can be set to 0 to avoid confusion), except for

Why would My Discriminator be 0?  A local value should be chosen to distinguish
individual sessions.  This is for a few reasons:
- Demultiplexing for sessions that are Up should happen solely based on
  discriminators, if possible.
- RFC 5880, Section 6.8.6 says:
  :       If the My Discriminator field is zero, the packet MUST be
  :       discarded.


306	   BFD "Your Discriminator", device A can also use IP source address or
307	   UDP source port to demultiplex BFD Echo session, or there is only one
308	   BFD Echo session running at device A.

Perhaps:
Device A performs its initial demultiplexing of a BFD Unaffiliated session using
the source IP address or UDP source port.

308	   Device A would send BFD Echo
309	   packets with IP destination address destined for itself, such as the
310	   IP address of interface 1 of device A.  All BFD Echo packets for the
311	   session MUST be sent with a Time to Live (TTL) or Hop Limit value of
312	   255.

You need to mention the receive procedures as well here.  Sent with 255,
received with either 255 or 254.  Cite RFC 5082.


314	   Within the BFD Echo packet, the "Desired Min TX Interval" and

This is a BFD Control packet carried via BFD Echo.

315	   "Required Min RX Interval" defined in [RFC5880] may be populated with
316	   one second,

I'd suggest being more normative here:
"SHOULD be populated with a value of 1 second (1,000,000 microseconds)."

316	   which however has no real application and would be
317	   ignored by the receiver.

Perhaps:
These values, however, are ignored and not used to calculate the Detection Time.

319	   Considering that the BFD peer device B wouldn't advertise "Required
320	   Min Echo RX Interval" as defined in [RFC5880],

I'd suggest being more normative here.  Perhaps:
"The Required Min Echo RX Interval MUST be set to zero."


320	   the transmission
321	   interval for sending BFD Echo packets MUST be provisioned at device
322	   A,

Perhaps:
"The transmission interval for BFD Unaffiliated Echo packets in the Up state
MUST be provisioned on device A."

322	   how to make sure the BFD peer device B is willing and able to loop
323	   back BFD Echo packets sent with the provisioned transmission interval
324	   is outside the scope of this document.

Perhaps:
"The method for provisioning device B to loop back BFD Echo packets is outside
the scope of this document."

Start a new paragraph here.

324	   Similar to what's specified
325	   in [RFC5880], the BFD Echo session begins with the periodic, slow

BFD Unaffiliated Echo session

326	   transmission of BFD Echo packets, the slow transmission rate SHOULD

"packets. The slow"

327	   be no less then one second per packet, until the session is Up, after
328	   that the provisioned transmission interval is applied, and reverting
329	   back to the slow rate once the session goes Down.

"Up.  Afterwards, the provisioned transmission interval is used.  When the BFD
Unaffiliated Echo session goes Down, the slow transmission rate is resumed."

329	   Considering that
330	   the BFD peer wouldn't advertise "Detect Mult" as defined in
331	   [RFC5880], the "Detect Mult" for calculating the Detection Time MUST
332	   be provisioned at device A, the Detection Time at device A is equal
333	   to the provisioned "Detect Mult" multiplied by the provisioned
334	   transmission interval.

Your intent here is that the "Detect Mult" value is irrelevant since the BFD
Unaffiliated Echo session can make its own choices as to what criteria it uses
to determine that a session is Down.  You're also trying to discuss the intended
Detection Time.

I think you have two choices here:
1. Permit the BFD Unaffiliated Echo implementation make completely local choices
about the number of lost Echo packets and expected time between the packets.  If
so, suggest that the Detect Mult is set to a known value (e.g. 0).  Maybe offer
some advice about measuring time for the loss of packets.

2. Set a Detect Mult value and use existing text (e.g. RFC 5880, Section 6.8.5)
to discuss that the loss of N packets in that Detect Mult is what is used to
declare the session down.  This likely permits easier debugging of the feature
by observing the packets.  

There is still the challenge of calculating when a packet is lost or not.  In
the absence of negotiated timers, the value you're trying to observe is the
round-trip time for an Echo packet.  If the RTT is unknown, how do you figure
that out?  Your Detection Time becomes (Detect Mult * RTT), perhaps with jitter
considerations.

336	4.  Unaffiliated BFD Echo Applicability

338	   Some devices that would benefit from the use of BFD may be unable to
339	   support the full BFD protocol.  Examples of such devices include
340	   servers running virtual machines, or Internet of Things (IoT)
341	   devices. 

Break into new paragraph.

341	   The Unaffiliated BFD Echo can be used when two devices are

"Unaffiliated BFD Echo can" (drop leading The)

342	   connected and only one of them supports the BFD protocol, and the
343	   other is capable of looping BFD Echo packets.

345	5.  Security Considerations

347	   All Security Considerations from [RFC5880] and [RFC5881] apply.

349	   Note that the Unaffiliated BFD Echo prevents the use of Unicast
350	   Reverse Path Forwarding (URPF) [RFC3704] [RFC8704] in strict mode.

Perhaps:
"Unaffiliated BFD Echo requires the remote device to loop BFD Echo packets.
In order provide this service, the remove device cannot make use of 
of Unicast Reverse Path Forwarding (URPF) [RFC3704] [RFC8704] in strict mode."

358	   In order to mitigate the potential reflector attack by the remote
359	   attackers, or infinite loop of the BFD Echo packets, it's RECOMMENDED
360	   to put two requirements on the device looping BFD Echo packets, the
361	   first one is that a packet SHOULD NOT be looped unless it has a TTL
362	   or Hop Limit value of 255, and the second one is that a packet being
363	   looped MUST NOT reset the TTL or Hop Limit value to 255, and MUST use
364	   a TTL or Hop Limit value of 254.

Please cite RFC 5082 here.

-- Jeff