Optimizing BFD Authentication
draft-ietf-bfd-optimizing-authentication-35

Update:  Many thanks for the hard work to resolve my discuss.  I will be interested in seeing the results of the experiment!  [Note: I'm leaving my original comments below, just for the record.]

Thanks to Stephen Farrell for their secdir review.  His comments are relevant.

General:  Please change 'strong authentication' to 'authentication' throughout the specification.  One can hardly call MD5 and SHA1 keyed hashes 'strong'. [Note:  while SHA-1 keyed hashes might not be currently deprecated, they are definitely on NIST's list to deprecate.]

Intro:  There is a link to MD5, but not to SHA-1?  I suggest:  https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf.

Intro:  Please add a little bit more explanation to remind the reader why these normally fast hashes are too slow/hard.  Please address both speed of the transmission and capability of the device performing the hashes.

Section 3, para 1:  Would one characterize 'Simple Password Authentication' as 'strong'?  or even 'adequate'?  Is there a reason it was left off the list of examples?  [Given there are only three options, it seems strange to use examples here.]

Section 3, para 4:  'as defined later in this document', which section is that?

Section 3, last para:  please ref which section in the specification this will be described.

Section 4, bullet list:  Why not list 'Simple Password Authentication', or 'NULL Auth'?  Are these not also less computationally intensive?  [assuming 'Simple Password Auth' was not listed because it isn't even 'adequate'.  And if NULL Authentication is ONLY suitable when the CPUs aren't capable of any processing, then that needs to be stated much more clearly in the stability draft.]

Section 4:  Please add a sentence about how other mechanisms might be added. [since this specification is not meant to be prescriptive with respect to the use of ISAAC.]

Section 5:  Do both sides (sender/receiver) calculate the timing of the Poll sequence? [to prevent the ability of the adversary to corrupt/block the Poll sequence messages]

Section 7:  Is the 'authentication present (A)' bit transmitted?  If so, where in Figure 1 is it?  Perhaps in the Opt. Mode?  If so, it would be easier to see if the same words were used in Para 1 as in the numbered list for Opt. Mode/Optimized Authentication Mode.

Section 7.2, para 2, Section 10.1, para 1:  If the goal is to allow other mechanisms, then the links to the ISAAC specification can be removed.  [Note:  there may be other places in the specification where this needs to be done.]

Section 7.2, para 3:  Do I understand this correctly?  If there is an issue switching from the original authentication mode to a 'computationally less intensive' mode, then the session is torn down?  That seems unfortunate.  If that isn't what this means, then perhaps revise.

Section 10:  Designating any of these mechanisms as 'strong' is disingenuous at best.  Please remove the word 'strong' from this specification.  Para 2 points out why this is true.  

Section 10:  Please add a sentence here which explains (justifies?) the level of authentication that is possible/practical for these systems.  Please address both speed of transmission and CPU capabilities.

Section 10:  Normally I would expect to see how the provision of symmetric keys (for keyed hashes, etc.) is accomplished. According to RFC 5880, keys are shipped across the network in the clear via the local/remote discriminator field.  This helps the attacker.  Please address this issue here, or point back to the relevant section in RFC 5880 where the mitigation is outlined.

Thanks for preparing this I-D, and amending the abstract.
I have the following comments which I hope will help revise this I-D.
 
### 1. Thank you to Marcus Ihlar for his TSV-ART review, see: https://datatracker.ietf.org/doc/review-ietf-bfd-optimizing-authentication-28-tsvart-lc-ihlar-2025-08-18/

As noted in the reviwe, could the editors please add a short discussion on loss and reauthentication 
in Section 5, or in an Operational Considerations section?

### 2. The I-D text ought to say why the document is experimental, please could you add to 
   the Introduction by citing the Appendix that explains this.

### 3. The I-D currently states: "All BFD Control Packets with the states AdminDown, Down, and Init
   require strong authentication." - could this be a RFC-2119 requirement? 
   Please consider making this a nomative case for this I-D , i.e. make this "REQUIRES", 
   or the REQUIRES in the following:
   "In addition to these requirements, BFD "significant changes" require
   strong authentication."

### 5. The I-D currently states:
   "When using the less computationally intensive authentication
   mechanism, BFD should periodically test the session using the strong
   authentication mechanism."
   - I'd agree, but I do think the text needs to explain why this is
   desirable, i.e. to justify why people SHOULD think seriously about
   enabling this test.

### 6. The I-D currently states:
   "Once
   enabled, every packet must have Authentication Bit set and the
   associated Authentication Type appended."
   - Please cit the section here, I could not be sure what was cited?

### 7. The I-D currently states:
  "As a security precaution, it mentions that
   authentication state be allowed to change at most once"
   Whereas, RFC 5880 use RFC-2119 text:
   "In order to avoid security risks, implementations using this method
   SHOULD only allow the authentication state to be changed at most once
   without some form of intervention."
   - Could this RFC 5880 text be quoted as-is, in the current I-D (with a reference?)
 
### NiTs
====

/It provides procedure where BFD state/It provides a procedure where BFD state/
/describes enabling and disabling/describe enabling and disabling/
/authentication state be allowed to change at most once/the authentication state be allowed to change at most once/

# Gunter Van de Velde, RTG AD, comments for draft-ietf-bfd-optimizing-authentication-32

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bfd-optimizing-authentication-32.txt

# for your convenience, please find some non-blocking COMMENTS

# I am missing an operational guidance section to help operators to operate optimized bfd.

# 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

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?

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

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.
"

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/

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/

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.
"

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

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 authenticating a limited subset of these packets, for example through a Poll sequence performed once per minute, substantially reduces system computational 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)

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?

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.

Kind Regards,
Gunter Van de Velde
RTG Area Director

Hi Mahesh, Ashesh, Ankur, Manav, and Jeffrey,

Thanks for the effort put into this specification. 

Thanks also to Jürgen Schönwälder for a review of an early version and to Jeff for the follow-up (especially the clarification about the struggle about the "performance" language). 

Please find below some few comments: 

# Confusing note

CURRENT:
   RFC XXXX, where XXXX is the number assigned to this document at the
   time of publication.

Please note that you are using RFC XXXX to refer to two distinct documents: 

         "RFC XXXX: Optimizing BFD Authentication.";

and

    "RFC XXXX: Meticulous Keyed ISAAC for BFD Authentication.";

# Redundant behavior

Section 3
   The contents of an Up packet MUST NOT change aside from the
   Authentication Section without strong authentication.

Vs.

Section 6:
   In this specification, the contents of an Up packet MUST NOT change
   aside from the Authentication Section without strong authentication.

Keep the normative language in one place.

# Not only for configuration but also for state reporting

Section 8.1

OLD: 
   The YANG 1.1 [RFC7950] model defined in this document augments the
   "ietf-bfd" module to configuration relevant to the management of
   the feature defined in this document.  

NEW:
   The YANG 1.1 [RFC7950] model defined in this document augments the
   "ietf-bfd" module to add data nodes relevant to the management of
   the feature defined in this document.  

# Add identities, not algos per se

Section 8.1

OLD:
   In particular, it adds crypto
   algorithms that are described in this model, and in Meticulous Keyed
   ISAAC for BFD Authentication [I-D.ietf-bfd-secure-sequence-numbers].

NEW:
In particular, it adds identities for crypto
   algorithms that are described in this model, and in Meticulous Keyed
   ISAAC for BFD Authentication [I-D.ietf-bfd-secure-sequence-numbers].

# Feature 

Consider this change in Section 8.1

OLD: 
   It adds a feature statement to enable optimized authentication.

NEW:
   It adds a feature to indicate optimized authentication.

# YANG terminology 

CURRENT:
   This YANG module imports YANG Key Chain [RFC8177], A YANG Data Model
   for Routing Management (NMDA version) [RFC8349], and YANG Data Model
   for Bidirectional Forwarding Detection (BFD) [RFC9314].

This should reason about importing the various modules, not data models. Please refer to 8407bis which says: 

“Likewise, "YANG module" should be used when using terms related to YANG module specifications (e.g., augmentation or deviation).“

# Consistency

Section 8.3 has:

CURRENT: prefix "bfdoa"; 

I suggest to be consistent with the pattern used so far for BFD (bfd-ip-mh, bfd-ip-sh, bfd-lag, etc.).

NEW: prefix bfd-oa;

# Feature Description

OLD:
       description
         "When enabled, this implementation supports optimized
          authentication as described in this document.";

NEW:
    description
      "Indicates that the implementation supports optimized
       authentication."; 

Please note also that the module will live outside the document. You may add a reference statement.

# Redundant default statement

OLD:
         default "60";
         description
           "Interval of time after which strong authentication
            should be utilized to prevent an on-path-attacker attack.
            Default is 1 minute.

NEW:
         default "60";
         description
           "Interval of time after which strong authentication
            should be utilized to prevent an on-path-attacker attack.

# Not maintained by IANA

OLD:
   name:         ietf-bfd-opt-auth
   namespace:    urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
   prefix:       bfdoa
   reference:    RFC XXXX

NEW:
   name:         ietf-bfd-opt-auth
   namespace:    urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
   prefix:       bfd-oa
   maintained by IANA? N
   reference:    RFC XXXX

# Security template

Please update 10.2 to follow the template in RFC8407bis.

Cheers,
Med

I support Deb's DISCUSS.

Note for a SHA1 reference, you can use RFC3174