Gunter,
> On Sep 8, 2025, at 7:39 AM, Gunter Van de Velde via Datatracker
> <nore...@ietf.org> wrote:
> # I am missing an operational guidance section to help operators to operate
> optimized bfd.
The operational consideration is "you select this mode in preference to another
mode".
>
> # comments
> # ========
>
> 17 Abstract
> 18
> 19 This document describes an experimental optimization to BFD
> 20 Authentication. It provides a procedure where BFD state
> transitions
> 21 require strong authentication and permits the majority of BFD
> Control
> 22 Packets to use a less computationally intensive authentication
> 23 mechanism. This enables BFD to scale better when there is a desire
> 24 to use strong authentication.
>
> GV> This draft seems to suggest updating the procedures of RFC5880. Should
> that
> not be mentioned in some form or embodiment within the abstract? demand mode
> changes
This is being published as experimental. As noted previously, figure out the
consensus among the IESG whether experiments get to update RFCs. I suspect the
answer is "no".
>
> 143 | significant | State change, a demand mode change (to |
> 144 | change | D bit) or a poll sequence change (P or |
> 145 | | F bit). Changes to BFD control packets |
> 146 | | that do not require a poll sequence, |
> 147 | | such as bfd.DetectMult are also |
> 148 | | considered as a significant change. |
>
> GV> The abstract mentions only state transitions, but with this definition of
> "significant change" there may be more included as just state change. Is my
> assumption correct?
The significant change is the normative procedure being protected. Defining
that requires a forward reference that has otherwise been problematic in
abstracts.
What text do you suggest instead to resolve that conflicting requirement
against forward references without pulling in the entirety of the description
of "significant change"?
Note that this point has already been thrashed about a bit. The muddled
clarity is the result of too many fingers in this pie.
>
> What i considered as state change:
> * Down → Init: When a system starts sending BFD packets to initiate a session.
> * Init → Up: When a system receives valid BFD packets from the remote peer and
> both sides agree on session parameters. * Up → Down: When a failure is
> detected
> (e.g., missing packets beyond the detection time threshold). * Up → Init: May
> occur during reinitialization or configuration changes.
>
> 162 BFD. For example, MD5 and SHA1 (Section 6.7 of [RFC5880]).
>
> GV> If the list is short, maybe display them all and not an example set
The list is currently complete. And, it is being left as an example because at
some point, stronger authentications could be used and this text must not
preclude others.
>
> 164 The intention of these optimized procedures is to permit strong
> 165 authentication for BFD state changes and utilize the less
> 166 computationally intensive authentication mechanisms to provide
> 167 protection for the session in the Up state while performing less
> 168 overall work. Such procedures will aid BFD session scaling without
> 169 compromising BFD session security.
>
> GV>
>
> "
> The optimized procedures are intended to enable the use of strong
> authentication for BFD state transitions while relying on less computationally
> intensive mechanisms to protect sessions in the Up state. This approach
> reduces
> overall processing requirements and facilitates BFD session scaling without
> reducing session security. "
I don't find this significantly clearer. Let's see what the RFC editor
suggests.
>
> 171 All BFD Control Packets with the states AdminDown, Down, and Init
> 172 MUST use strong authentication.
>
> GV> s/Packets with the states/Packets when in the state/
Accepted.
>
> 174 Once the BFD state machine has reached the Up state, it will
> continue
> 175 to send BFD Control Packets in the Up state for a period as
> discussed
> 176 in Section 7.2. If optimized authentication mechanisms are in use,
>
> GV> s/it will continue to send BFD Control Packets/it will continue to send
> computationally intensive BFD Control Packets/
Wrong verbiage, but accepting the point:
<t>Once the BFD state machine has reached the Up state, it will continue
- to send BFD Control Packets in the Up state for a period as discussed in
+ to send BFD Control Packets with strong authentication in the Up state
for a period as discussed in
>
> 180 The contents of an Up packet MUST NOT change aside from the
> 181 Authentication Section without strong authentication.
>
> GV>
>
> "
> The contents of an Up packet, other than the Authentication Section, MUST NOT
> change unless strong authentication is in use. "
Accepted.
>
> 233 This "strong reauthentication interval" for performing such
> periodic
> 234 tests using the strong authentication mechanism can be configured
> 235 depending on the capability of the system.
>
> GV> The description here does not suggest min or maximum interval. It would be
> operational interesting to have a suggested interval guideline, and an
> absolute
> minimum of these polls to do per second or minute to avoid security
> degradation
We're making this up and any number suggested will be one we have pulled from
the æther.
The fact that we're doing any reauth procedure is a bit of speculative duct
tape that if the underlying optimized mechanism, ISAAC in the example we're
working through, has weaknesses that we're bounding the period of time which
the compromised weaker mechanism can keep the session in the Up state.
In earlier versions of the document, we considered things without ANY
authentication at all during the optimized mode. We also considered earlier
versions of the NULL authentication covered in the bfd-stability draft until it
was determined that BFD sequence number behaviors exercised using the sequence
numbers for the NULL auth mechanism weakened the resilience of the protocol
more so than no authentication at all.
Where the discussion will inevitably head regarding the selected mechanism,
ISAAC, is "is this good enough". If it's trivial to break, then it's providing
not much more benefit than no authentication at all for the optimized
procedures. If it has some resistance to attack, it means it's better than no
authentication at all.
Again, this is a bit of speculative duct tape to help us if it's not "good
enough". The goal becomes "protect BFD vs. attacks using the cryptography
itself" (cpu exhaustion), which in the chosen protocol scenario is "keep BFD
Up". The attack becomes "keep BFD up when it's actually down". This would
require:
- A MITM attack that was able to suppress the strong authentication that would
knock the session to Down
- Spoofing the Up packets in the optimized mode
- ... and a protocol mechanism that doesn't have its own slower
keepalive/holdtime. Some protocols use BFD wholly in place of its own
mechanisms and those are the ones most vulnerable to this scenario. However,
if there's an active MITM attacker that can suppress packets with strong
authentication, the link is already deeply compromised.
>
> 237 Most packets transmitted on a BFD session are BFD Up packets.
> 238 Strongly authenticating a small subset of these packets with a Poll
> 239 sequence as described above, for example every one minute,
> 240 significantly reduces the computational demand for the system while
> 241 maintaining security of the session across the configured strong
> 242 reauthentication interval.
>
> GV>
>
> "
> Most packets transmitted in a BFD session are Up packets. Strongly
s/on/in/ accepted.
> authenticating a limited subset of these packets, for example through a Poll
s/small/limited/ accepted
adding "for example", rejected. The poll sequence is the necessary mechanism.
> sequence performed once per minute, substantially reduces system computational
Dropping the for example is also rejected. At the moment the closest thing
we're recommending for defaults is embodied in this example and a similar
default in the YANG.
Much like other magic intervals in BFD, many of these things will be
implementation dependent. For BFD itself,we did eventually end up with an RFC
documenting some common intervals, but even that was something that evolved
over time.
> load while preserving session security across the configured strong
> reauthentication interval. "
>
> 317 The values of the Optimized Authentication Mode field are:
> 318
> 319 1. When using the strong authentication type for optimized BFD
> Auth
> 320 Types.
> 321
> 322 2. When using the less computationally intensive authentication
> type
> 323 for optimized BFD Auth Types.
>
> GV> are these numerical values "1" and "2" set within the Opt. Mode field? or
> are both examples? (easy fix to clarify)
Yes, set in the Opt. Mode field. The intent is that the field's name is
Optimization Mode, but is shown in brief in the PDU diagram because of size.
>
> 329 7.1. Transmitting and Receiving Using Optimized Authentication
>
> GV> Would this be non-backward compatible, as rfc5880 assumes (i seem to
> remember) a single authentication type per session, and now with this
> experimental proposal we have multiple. Shoud the non-backward compatible
> property be called out in this section?
Not really. The actual Auth code is set to a constant value, which is what is
covered in RFC 5880. The Opt. Mode field is a detail of the optimization state
machinery for the authentication type.
FWIW, in prior versions of this proposal, the individual optimization modes
were encoded as distinct Auth Codes which lead to its own problems.
>
> 418 8.1. Data Model Overview
>
> GV> Some of the default values for this experimental draft are already defined
> in the YANG model. But for the purpose of making things easier to follow,
> wouldn’t it be helpful to also mention them explicitly in an operational
> guidance section? That way, readers working with optimized BFD don’t have to
> go
> digging through the model just to figure out what defaults they’re expected to
> use.
Aside from the exemplary reauth interval, what did you have in mind?
-- Jeff
>
> Kind Regards,
> Gunter Van de Velde
> RTG Area Director
>
>
