Re: Some comments to the authors of draft-ietf-bfd-unsolicited

Jeffrey Haas <jhaas@pfrc.org> Wed, 02 March 2022 16:07 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 624653A0E63; Wed, 2 Mar 2022 08:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8ib_VXz6fOM; Wed, 2 Mar 2022 08:07:37 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 712E93A0CF8; Wed, 2 Mar 2022 08:07:37 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 5DA071E345; Wed, 2 Mar 2022 11:07:36 -0500 (EST)
Date: Wed, 02 Mar 2022 11:07:36 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Reshad Rahman <reshad@yahoo.com>, rtg-bfd WG <rtg-bfd@ietf.org>, "draft-ietf-bfd-unsolicited@ietf.org" <draft-ietf-bfd-unsolicited@ietf.org>
Subject: Re: Some comments to the authors of draft-ietf-bfd-unsolicited
Message-ID: <20220302160735.GF13378@pfrc.org>
References: <CA+RyBmX8oAQFqJMjVhcj_78wYfrvz+afnSoP2-VjWyfCEunqmQ@mail.gmail.com> <381777191.1553826.1645979075642@mail.yahoo.com> <CA+RyBmWerxKKS6FCyaeQApuGkVT0JehrFToPBDf-ebrLkCSLnw@mail.gmail.com> <682D13B3-A62E-4A0D-9192-2D0D5844B86B@pfrc.org> <CA+RyBmUsse6pB72PG9MBmyD0sUK07GzfsossqvpCVn3Xim6TmA@mail.gmail.com> <20220301123834.GA31482@pfrc.org> <CA+RyBmVx7U5SodPfTc5CHuL_sOtOzWeLAj2JDvspR5W+FMH+2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+RyBmVx7U5SodPfTc5CHuL_sOtOzWeLAj2JDvspR5W+FMH+2w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/0ube1aCOWdO6vNpiW6k6LZ71ISk>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Mar 2022 16:07:48 -0000

Greg,

On Tue, Mar 01, 2022 at 08:41:50AM -0800, Greg Mirsky wrote:
> In the unsolicited draft:
> - The passive side is not sending packets.
> - It is waiting for an incoming session.
> 
> In my understanding, that is already defined in Section 6.1 RFC 5880:
>    A system taking the
>    Passive role MUST NOT begin sending BFD packets for a particular
>    session until it has received a BFD packet for that session, and thus
>    has learned the remote system's discriminator value.
> If my understanding of RFC 5880 and the draft is correct, it appears that
> the draft does not define any new local behavior but re-tells what already
> has been defined in Section 6.1.

The authors largely made these points at various times over presentation and
working group discussion.  It was the motivation originally to start with 
INFORMATIONAL status.

>  Or the new behavior is that the passive
> role might be not only for the specified BFD session ("particular BFD
> session" in RFC 5880) but any yet unlearned BFD session? 

A "wildcard" session, yes.  

> But that, in my
> opinion, would require Security Considerations stepping up from
> recommendations to requirements, especially when the draft includes the
> multi-hop BFD scenario.

This feature is well deployed already.  Yes, from an IETF process
perspective, the main considerations here are security considerations.

I believe that as the authors update the text to explicitly call out that
multihop is a valid scenario that additional scrutiny of the security
considerations will be necessary.

-- Jeff