Re: resend of no obj comments on draft-ietf-bfd-stability

Jeffrey Haas <jhaas@pfrc.org> Thu, 30 October 2025 13:31 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: rtg-bfd@mail2.ietf.org
Delivered-To: rtg-bfd@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7CFCB7EE5F2F; Thu, 30 Oct 2025 06:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
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_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXPBV2CRQ05C; Thu, 30 Oct 2025 06:31:37 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by mail2.ietf.org (Postfix) with ESMTP id F27277EE5EB5; Thu, 30 Oct 2025 06:31:06 -0700 (PDT)
Received: from smtpclient.apple (99-188-202-8.lightspeed.livnmi.sbcglobal.net [99.188.202.8]) by slice.pfrc.org (Postfix) with ESMTPSA id 4A5CA1E24F; Thu, 30 Oct 2025 09:31:06 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Subject: Re: resend of no obj comments on draft-ietf-bfd-stability
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <A0055037-520D-497D-B440-78E831D1DD2F@inkbridge.io>
Date: Thu, 30 Oct 2025 09:31:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6628BC12-050C-4439-9E35-DBB782318573@pfrc.org>
References: <CAGgd1OdMpTP=TYU0YcF2=+5FD69HENjPLLjwCzMbMU9DXKTsqg@mail.gmail.com> <319789E6-AD45-49EC-BAC0-02A37E325F8A@gmail.com> <CAGgd1OeJy1MwW=uxbwkFKx4e1+hCLYLniRXXu8DibbDh34Zehw@mail.gmail.com> <4E865F11-97DF-45A4-9C8B-EF8F6B54AC60@gmail.com> <ED65E795-5ACE-4A2E-915A-750E60900252@pfrc.org> <CAGgd1Of3yZtgGDiMcUvkXBsQYaw6eZhoQuDaGVPD4cPL_QOSTg@mail.gmail.com> <C8DD670E-1710-4BEA-8204-850A3E2C3AFD@pfrc.org> <CAGgd1OfnxwrC1gd3VG+nUx98PfDEco77HR+yv+hYsn10=_QEqw@mail.gmail.com> <A0055037-520D-497D-B440-78E831D1DD2F@inkbridge.io>
To: Alan DeKok <alan.dekok@inkbridge.io>, Deb Cooley <debcooley1@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.10)
Message-ID-Hash: 4QRMY3K37ZYTQDMIEONGDGI5PYNIKFBE
X-Message-ID-Hash: 4QRMY3K37ZYTQDMIEONGDGI5PYNIKFBE
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-bfd.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-bfd-stability@ietf.org, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, bfd-chairs@ietf.org, Ketan Talaulikar <ketant@cisco.com>, The IESG <iesg@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection" <rtg-bfd.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/KaoCtgpDT_RV9hw9ZDtz2sCwmTc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-bfd-owner@ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Subscribe: <mailto:rtg-bfd-join@ietf.org>
List-Unsubscribe: <mailto:rtg-bfd-leave@ietf.org>


> On Oct 30, 2025, at 8:56 AM, Alan DeKok <alan.dekok@inkbridge.io> wrote:
> 
> On Oct 29, 2025, at 5:34 PM, Deb Cooley <debcooley1@gmail.com> wrote:
>> 
>> Wait, let me attempt to rephrase this...  if you are using MD5, SHA-1 or whatever w/ sequence numbers, then it has to be meticulous.  That definitely does not come across in Section 6.  Here is my attempt to clarify the paragraph: 
>> ...
>> I will freely admit that the above is one hell of a long sentence... Feel free to fix that.  
> 
>  Perhaps inverting the sense would work:
> 
>  BFD has a number of operational modes which are subject to attacks.  Sessions using NULL authentication are vulnerable to trivial forgery.  Sessions using Simple Password authentication expose the password for all to see, and are also vulnerable to forgery.  Even packets using MD5 or SHA-1 authentication can be trivially replayed when a non-meticulous mode is used.  As such, when MD5 or SHA-1 pr any other authentication is used, it MUST be used in a Meticulous Keyed mode.  Authentication types that provide for meticulously increasing sequence numbers can also be used, such as Meticulous Keyed ISAAC for BFD Authentication [I-D.ietf-bfd-secure-sequence-numbers]."

I think that's moved from discussing why we need meticulous to support stability measurement and distracting us with other security properties.


Proposed:
Theory of Operation

This mechanism allows operators to measure the loss of BFD control packets.  A BFD authentication type carrying a meticulously increasing sequence number is required to support this loss measurement. Authentication types that provide for meticulously increasing sequence numbers include:

* Meticulously Keyed MD5 and SHA1, defined in RFC 5880.
* Meticulously Keyed ISAAC, defined in ietf-bfd-secure-sequence-numbers
* The NULL authentication mechanism, which does not provide for authentication but carries a meticulously increasing sequence number, defined in this document.

Other authentication types that provide for meticulously increasing sequence numbers appropriate for this mechanism may be defined in future specifications.

-- Jeff