Re: I-D Action: draft-ietf-bfd-stability-11.txt

[Jeffrey Haas <[e-mail]>]

Authors,

Thanks for the refresh on the stability document as we work toward winding
up the authentication feature bundle.

A few comment from the update using the id-nits line numbering:

On Mon, Jan 22, 2024 at 04:50:53PM -0800, [e-mail] wrote:
> Internet-Draft draft-ietf-bfd-stability-11.txt is now available. It is a work
> item of the Bidirectional Forwarding Detection (BFD) WG of the IETF.
> 
>    Title:   BFD Stability
[...]
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/

126	4.  BFD Null-Authentication Type

128	   The functionality proposed for BFD stability measurement is achieved
129	   by appending an authentication section with the NULL Authentication
130	   type (as defined in Optimizing BFD Authentication
131	   [I-D.ietf-bfd-optimizing-authentication] ) to the BFD control packets
132	   that do not have authentication enabled.

This section is correct, but not wholly so.

Using the section below:

134	5.  Theory of Operation

136	   This mechanism allows operators to measure the loss of BFD control
137	   packets.

139	   When using MD5 or SHA authentication, BFD uses an authentication
140	   section that carries the Sequence Number.  However, if non-meticulous
141	   authentication is being used, or no authentication is in use, then
142	   the non-authenticated BFD control packets MUST include an
143	   authentication section with the NULL Authentication type.

These two sections together are trying to articulate the more fundamental
requirement: Meticulous authentication carries an increasing sequence number in
each BFD packet, regardless of the type.  When meticulous authentication is in
use, dropped packets can be detected by looking at the sequence numbers.

Thus, "no authentication" isn't a valid scenario, it's "minimally, use the NULL
auth type".  The same applies to simple password.  

Non-meticulous can't help us here.  There's thus the option with non-meticulous
is interspersing non-meticulous with a meticulous mode that is inexpensive
enough.  NULL is an option, as is Meticulous Keyed ISAAC.

The configuration requirement is thus similar to the discussion resolving in the
optimizing authentication thread.  There needs to be a "primary" authentication,
with a set of acceptable "secondary".  For optimizing authentication scenarios,
this is a "stronger" for startup and transitions, and a "weaker" mode.  For bfd
stability, it's the allowable mix such that the full mix is always meticulous.

155	   The first BFD authentication section with a non-zero sequence number,
156	   in a valid BFD control packet, processed by the receiver is used for
157	   bootstrapping the logic.  When using secure sequence numbers, if the
158	   expected values are pre-calculated, the value must be matched to
159	   detect lost packets as defined in BFD secure sequence numbers
160	   [I-D.ietf-bfd-secure-sequence-numbers].

The text covering secure sequence numbers is stale and no longer covers current
Meticulous Keyed ISAAC procedures.  I think you can fix this simply by dropping
that text.


-- Jeff