Re: Can a BFD session change its source port to facilitate auto recovery

Alan DeKok <aland@deployingradius.com> Wed, 22 March 2023 21:51 UTC

Return-Path: <aland@deployingradius.com>
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 11416C14CE55 for <rtg-bfd@ietfa.amsl.com>; Wed, 22 Mar 2023 14:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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 P28t7hMkl52j for <rtg-bfd@ietfa.amsl.com>; Wed, 22 Mar 2023 14:51:36 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D95CC14CE4B for <rtg-bfd@ietf.org>; Wed, 22 Mar 2023 14:51:34 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 6696C669; Wed, 22 Mar 2023 21:51:32 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: Can a BFD session change its source port to facilitate auto recovery
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAL9v8R0Nv6VrdU3gdk8uJ+_K_tehGLXQSor_gBeYq90Tf4WL=Q@mail.gmail.com>
Date: Wed, 22 Mar 2023 17:51:30 -0400
Cc: rtg-bfd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE89E7C7-377D-4ECC-8F1C-5A373D7D992B@deployingradius.com>
References: <CAL9v8R0Nv6VrdU3gdk8uJ+_K_tehGLXQSor_gBeYq90Tf4WL=Q@mail.gmail.com>
To: Abhinav Srivastava <absrivas@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/7so_6rvdUMlCe-QKXZK3VuhZrQc>
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: Wed, 22 Mar 2023 21:51:38 -0000

On Mar 22, 2023, at 5:35 PM, Abhinav Srivastava <absrivas@gmail.com> wrote:
> I needed clarification around whether source port can be changed for a BFD session in case of multi hop BFD.   The ability to change BFD source port when BFD session goes down helps BFD session to recover if its stuck on a network path where there is some intermittent but significant packet loss.

  RFC 5883 is silent on the subject of source ports, and defers instead to RFC 5881.

> In such cases, normally without BFD, end to end application traffic would eventually settle down on a good path as applications typically change source port after experiencing disconnection or failures.  But if BFD is being used to monitor some part of a path which is experiencing significant but not 100% packet loss, it will start causing next hop list of associated static route or the associated BGP sessions to start flapping forever, as BFD packets would be stuck to that partial lossy path forever (until BFD session is deleted and recreated by admin action).  This may also hinder the typical application recovery strategy of changing source port on failure.

  Sure, that makes sense.

> Ability to dynamically change BFD source port can help BFD recover in such cases.  Is this something that is allowed as per RFC?  The RFC5881, section 4 (for single hop) case states that –
> 
> “The source port MUST be in the range 49152 through 65535. The same UDP source port number MUST be used for all BFD Control packets associated with a particular session”

  That seems clear: changing source ports is not allowed.

  From a practical point of view, I'm not sure what the issue is.  If the packets are authenticated, then it doesn't really matter what the source port is.

  e.g. there may be a NAT between the two peers.  Due to various NAT magic, packets coming from the NAT may change source port.  This can happen when the NAT reboots (quickly), while the peers are still up.

  You are free to ignore the requirements of the RFCs at any time.  However, doing so may result in interoperability issues, security issues, etc.

  If there seems to be a strong need for allowing changing the source port associated with a particular session, you can also submit an Internet-Draft to the WG which proposes that change.

  Alan DeKok.