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, internet-dra...@ietf.org 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
