RFC 9986

Meticulous Keyed ISAAC for Bidirectional Forwarding Detection (BFD) Optimized Authentication

📅 published June 2026, from ietf

RFC 9986 📜🎀

Meticulous Keyed ISAAC for Bidirectional Forwarding Detection (BFD) Optimized Authentication

Okay bestie, this one was written by A. DeKok (InkBridge Networks), M. Jethanandani (Arrcus), S. Agarwal (Arrcus, Inc.), A. Mishra (Aalyria Technologies), and J. Haas (HPE) 🧑‍💻. It's an IETF document from June 2026 with ISSN 2070-1721, and its category is Experimental 🧪, so it's not on the Standards Track. The title block doesn't list anything it obsoletes or updates ✨.

Abstract 🦋

This doc describes a BFD Optimized Authentication Mode called Meticulous Keyed ISAAC Authentication 💖. It can authenticate some BFD packets while using less CPU time than MD5 or SHA-1 🏃‍♀️💨. The catch is that the security goes down a bit 💀. It can't be used to signal state changes, but it can keep a session chilling in the Up state 🌸.

Status of This Memo 📋

This is not an Internet Standards Track spec. It's published for examination, experimental implementation, and evaluation 🔬. It defines an Experimental Protocol for the Internet community and it's a product of the IETF. It reflects IETF consensus, got public review, and was approved by the IESG 🫶. Not every IESG-approved doc is a candidate for an Internet Standard, so check Section 2 of RFC 7841 for the details 👀.

For status info, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9986 ✨.

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date 📑. Please actually read them, because they explain your rights and restrictions 🙈. Any Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License says 💅.

Table of Contents 🗺️

1.  Introduction
  1.1.  Meticulous Keying
  1.2.  Requirements Language
2.  Experimental Extensions to RFC 5880
3.  Architecture of the Auth Type Method
  3.1.  Rationale for ISAAC and Operational Overview
4.  Meticulous Keyed ISAAC Authentication Types
  4.1.  Meticulous Keyed ISAAC Authentication, ISAAC Format
  4.2.  Meticulous Keyed ISAAC Authentication, MD5 Format
  4.3.  Meticulous Keyed ISAAC Authentication, SHA-1 Format
5.  New State Variables for Meticulous Keyed ISAAC Authentications
6.  Procedures for BFD Authentication Using Meticulous Keyed ISAAC,
        MD5, or SHA-1 Formats
7.  Procedures for BFD Authentication Using Meticulous Keyed ISAAC,
        ISAAC Format
  7.1.  Transmission using Meticulous Keyed ISAAC Authentication,
        ISAAC Format
  7.2.  Receipt using Meticulous Keyed ISAAC Authentication, ISAAC
        Format
8.  Secret Key
9.  Transition to Using ISAAC
10. Seeding ISAAC
  10.1.  Sender Variable Initialization
  10.2.  Receiver Variable Initialization
11. Operation
  11.1.  Page Flipping
  11.2.  Multiple Keys
12. Transition Away from Using ISAAC
13. The YANG Module
14. IANA Considerations
  14.1.  BFD Auth Types
  14.2.  IETF XML Registry
  14.3.  The YANG Module Names Registry
15. Security Considerations
  15.1.  Protocol Security Considerations
    15.1.1.  Spoofing
    15.1.2.  Reuse of Keys
    15.1.3.  Random Number Considerations
  15.2.  YANG Security Considerations
16. References
  16.1.  Normative References
  16.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction 🌈

Okay so, BFD (Section 6.7 of [RFC5880]) already has a bunch of auth mechanisms, including Simple Password and a few methods built on MD5 and SHA-1 hashes 🔐. The good part about cryptographic hashes is that they're secure. The not-so-good part is that they're expensive and slow on resource-constrained hardware 🥲.

When BFD packets aren't authenticated, an attacker can forge, modify, and/or replay packets on a link 😱. That causes some chaos: people can end up thinking a link is down when it's up, or thinking it's up when it's actually down 🙃.

[RFC9985] defines procedures for scaling BFD authentication better. It splits the work between heavier authentication used for significant changes and lighter authentication that just checks the session is still Up 🧠✨. See [RFC9985] for the general performance and security considerations 📚.

This document defines BFD Optimized Authentication Modes using the existing MD5 (Section 6.7.3 of [RFC5880]) and SHA-1 (Section 6.7.4 of [RFC5880]) mechanisms for the heavier work 💪. It also defines how to use a mechanism called ISAAC [ISAAC] for the lighter work 🦋.

ISAAC needs only a few CPU operations per generated 32-bit number, can take a large secret key as a seed, and has an extremely long cycle length 🤯. Those properties make it ideal for BFD, honestly iconic 👑.

ISAAC+ [ISAAC-Plus] documents some cryptanalysis of ISAAC 🕵️‍♀️. That analysis looked at an issue with initial seeding, and the method in this doc includes recommendations to deal with that attack 🛡️.

1.1. Meticulous Keying 💜

[RFC5880] uses the terms "meticulous keyed" and "meticulous keying" without defining them 🤷‍♀️. You can figure out what they mean by looking at the definition of the sequence number in [RFC5880] (Section 4.3):

|  The sequence number for this packet.  For Keyed MD5
|  Authentication, this value is incremented occasionally.  For
|  Meticulous Keyed MD5 Authentication, this value is incremented for
|  each successive packet transmitted for a session.  This provides
|  protection against replay attacks.

So here's the tea ☕: "meticulous" means the sequence number goes up on every new packet that gets sent 📈. "Keyed" means the packets are authenticated with a secret key or keys that both sender and receiver know 🗝️. Put together, "meticulous keyed" is the BFD Authentication type where every packet sent has a sequence number exactly one greater than the one before it, and can be authenticated 🫶.

1.2. Requirements Language 📏

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💅

2. Experimental Extensions to RFC 5880 🧪

This doc describes an experimental extension to BFD [RFC5880] ✨. The goal is to learn more about what happens when the authentication method in this document gets used 🔍.

This document is classified as Experimental and is not part of the IETF Standards Track 🚧. Implementations based on it should not be considered compliant with BFD [RFC5880], and they should not assume interoperability with other implementations that follow this document 🙅‍♀️.

Some of the state variables in Section 6.8.1 of [RFC5880] are tied to the auth type used for a particular session 🔗. The definitions in [RFC5880] are specific to Keyed MD5 or SHA-1 Authentication, though, and that limits how useful they are for new auth types 😤. So this document uses a relaxed definition for the following BFD state variables. They're no longer limited to MD5 and SHA-1 and extend to the mechanism defined here instead 💖:

  • bfd.RcvAuthSeq
  • bfd.XmitAuthSeq
  • bfd.AuthSeqKnown

3. Architecture of the Auth Type Method 🏗️

This document specifies two Optimized BFD [RFC9985] Authentication Modes 👑:

  • For the heavier authentication mechanisms, the existing MD5 (Section 6.7.3 of [RFC5880]) and SHA-1 (Section 6.7.4 of [RFC5880]) mechanisms get reused, with small PDU changes so they can carry the Optimization Mode encoding. Those changes are documented in Sections 4.2 and 4.3, respectively 🧩.
  • For the lighter authentication mode, this document defines the Meticulous Keyed ISAAC Authentication mechanism 🌸. Its PDU format is in Section 4.1, and the procedures for using that format come later in this document 📖.

ISAAC is used to generate an infinite stream of pseudorandom numbers, which this doc calls "Auth Keys" 🎲. With Meticulous Keyed ISAAC Authentication, these Auth Keys work as a signal that the sending party is legit 🪪. Only the sending party can generate the correct Auth Keys. So if the receiving party sees a correct Auth Key in a BFD Control Packet while the session is Up, only the sending party could have generated it 🙌.

Heads up though: BFD Control Packets using the lighter ISAAC Authentication Format type are not signed or authenticated 🙈. So this format MUST NOT be used to signal BFD state changes ⚠️.

Part 1 of 7 is done, bestie! More parts are coming, so keep your eyes peeled 🧚💖

3.1. Rationale for ISAAC and Operational Overview ✨

Okay so let's talk about why ISAAC got picked 🎀 There are a ton of cryptographically secure pseudorandom number generators (CSPRNGs) out there, and this section explains why ISAAC won 👑

The goal for this less computationally intensive authentication was to give a signal that the session is in the Up state, using a 32-bit number that's hard for an attacker to guess 🦋 That number should come from a CSPRNG that produces its results from a Seed made of both public and private data. And since BFD can have packet loss, the generator should also be "seekable", which means the BFD state machine should be able to ask the generator (within a small window) for new numbers 💅

This last property rules out most CSPRNGs, because they aren't seekable by design 🙈 Most CSPRNGs keep minimal state and are built to crank out a long sequence of pseudorandom numbers from a few simple calculations. Basically, every call to the CSPRNG function changes the internal state in an irreversible way, and then spits out a new random number as the result.

You could use a generator like that and manually save a bunch of results in a buffer. That buffer would then let you "seek" within a short window. ISAAC, on the other hand, produces large sets of numbers by design, so it's an integrated solution 🧚

Also, most CSPRNGs are designed with small seeds 🥺 That means any secret key an administrator defines can't be used directly as a Seed for the generator. Instead, any secret key (including any per-session data) would have to be hashed before being used to seed the generator. For these reasons, ISAAC was chosen. It accepts keys up to 8192 octets in length, which is more than enough for BFD 💖

ISAAC has been through cryptanalysis, most notably ISAAC+ [ISAAC-Plus]. There are no known vulnerabilities 🌈

Two instances of ISAAC are created: one for transmission and one for reception. An instance is required for each direction, since the inputs for seeding ISAAC need the locally, randomly generated Seed value and the current BFD Your Discriminator value for an Up session. These values are distinct on each side of the BFD session 🍓

Here's how the process for using ISAAC with BFD works in each direction:

  • The administrator provides a secret key that is used to authenticate each party in the BFD sessions.
  • When the session transitions into the Up state, the secret key is combined with per-session data to seed ISAAC.
  • The ISAAC process produces a "page" of 256 32-bit random numbers.
  • The BFD state machine also records a sequence number that is associated with the first entry of that page. The combination of 256 entries and the sequence number lets the BFD state machine "seek" within a 256-packet window with zero cost, through simple addition or subtraction of sequence numbers 🔥
  • If there is a lost packet, the BFD state machine simply seeks to the entry associated with the received packet, and checks whether the received packet contains the expected number.
  • BFD supports packet rates of hundreds of packets per second. Even at those rates, 256 entries per ISAAC page gives you about a second of BFD operation before the next page has to be calculated ⭐
  • As the next page calculation is complex, and there's a long period of time available before the next page is needed, this calculation can be done in the background 🫶
  • If the next page calculation is started immediately after the current page is fully used, there should be sufficient time to calculate the next page as a background task, no matter what the packet rate.

So, in summary: the ISAAC Seed depends on both a secret key and per-session data, which makes it difficult for an attacker to guess or attack via an offline dictionary attack 🔒 The generated numbers are saved in an array, where the BFD fast path can consume them at essentially zero cost. Main character efficiency 👑

The only downside is that this method doesn't provide per-packet integrity checks 🥲 That limitation is addressed by mandating that Meticulous Keyed ISAAC Authentication is only used to signal that the session remains in the Up state. The ISAAC numbers then signal that the originator of the packet is authentic, and the BFD state machine verifies that the rest of the packet is well formed and matches the expected state.

The result is an authentication method that meets the needs of the BFD state machine and is secure 💅✨

4. Meticulous Keyed ISAAC Authentication Types 🎀

4.1. Meticulous Keyed ISAAC Authentication, ISAAC Format 🦋

If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains either Optimized MD5 Meticulous Keyed ISAAC Authentication (7) or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8), and the Optimized Authentication Mode field contains 2 (Section 7 of [RFC9985]), the Authentication Section has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Auth Type   |   Auth Len    |  Auth Key ID  |   Opt. Mode   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Seed                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Auth Key                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 1: Meticulous Keyed ISAAC Authentication Format
  • Auth Type: The current Auth Type. It MUST provide for meticulous keying. That is, an authentication type where each packet is authenticated and where the Sequence Number field is incremented by one (1) for every packet that is sent.
  • Auth Len: The length of the Authentication Section in bytes. For Meticulous Keyed ISAAC Authentication Format, the length is 16 bytes.
  • Auth Key ID: The authentication key ID in use for this packet. This allows multiple secret keys to be active simultaneously.
  • Opt Mode: The Optimized Authentication Mode is defined in Section 7 of [RFC9985]. When the Auth Type is either Optimized MD5 Meticulous Keyed ISAAC Authentication (7) or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8), and the format is Meticulous Keyed ISAAC Authentication Format, the Optimized Authentication Mode field will be set to 2.
  • Sequence Number: The sequence number for this packet. For Meticulous Keyed ISAAC Authentication, this value is incremented once for each successive packet transmitted for a session. This provides protection against replay attacks.
  • Seed: A 32-bit (4 octet) Seed that is used in conjunction with the shared key in order to configure and initialize the ISAAC Pseudorandom Number Generator (PRNG). It is used to identify and secure different "streams" of random numbers that are generated by ISAAC.
  • Auth Key: This field carries the 32-bit (4 octet) ISAAC output that is associated with the sequence number. The ISAAC PRNG MUST be configured and initialized as given in Section 10.

Note that the Auth Key here does not include any summary or hash of the BFD Control Packet. The packet itself is completely unauthenticated.

When the receiving party gets a BFD packet with an expected sequence number and the correct corresponding ISAAC output in the Auth Key field, it knows that only the authentic sending party could have sent that message. The sending party is therefore Up, since it's the only one who could have sent the message 🌸

4.2. Meticulous Keyed ISAAC Authentication, MD5 Format 💜

If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains Optimized MD5 Meticulous Keyed ISAAC Authentication (7), and the Optimized Authentication Mode field contains 1 (Section 7 of [RFC9985]), the Authentication Section has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Auth Type   |   Auth Len    |  Auth Key ID  |   Opt. Mode   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Auth Key/Digest...                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2: Meticulous Keyed ISAAC Authentication, MD5 Format
  • Auth Type: The current Auth Type. It MUST provide for meticulous keying. That is, an authentication type where each packet is authenticated and where the Sequence Number field is incremented by one (1) for every packet that is sent.
  • Auth Len: The length of the Authentication Section in bytes. For Meticulous Keyed ISAAC Authentication, MD5 Format, the length is 24 bytes.
  • Auth Key ID: The authentication key ID in use for this packet. This allows multiple secret keys to be active simultaneously.
  • Opt Mode: The Optimized Authentication Mode is defined in Section 7 of [RFC9985]. When the Auth Type is Optimized MD5 Meticulous Keyed ISAAC Authentication (7), and the format is MD5 Authentication Format, the Optimized Authentication Mode field will be set to 1.
  • Sequence Number: The sequence number for this packet. For Meticulous Keyed ISAAC Authentication, this value is incremented once for each successive packet transmitted for a session. This provides protection against replay attacks.
  • Auth Key/Digest: This field carries the 16-byte MD5 digest for the packet. The procedure for calculating this field is documented in Section 6.7.3 of [RFC5880] 🧮

4.3. Meticulous Keyed ISAAC Authentication, SHA-1 Format ✨

okay so this is the SHA-1 flavor of the same ISAAC vibe 🧚 If the Authentication Present (A) bit is set in the header, the Authentication Type field says Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8), and the Optimized Authentication Mode field has 1 (Section 7 of [RFC9985]), then the Authentication Section looks like this:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Auth Type   |   Auth Len    |  Auth Key ID  |   Opt. Mode   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Sequence Number                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Auth Key/Hash...                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                              ...                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 3: Meticulous Keyed ISAAC Authentication, SHA-1 Format

Auth Type: The current Auth Type. It MUST provide for meticulous keying. That means an authentication type where each packet is authenticated and where the Sequence Number field goes up by one (1) for every packet that is sent. 🔥

Auth Len: The length of the Authentication Section in bytes. For Meticulous Keyed ISAAC Authentication, SHA-1 Format, the length is 28 bytes. 💅

Auth Key ID: The authentication key ID in use for this packet. This lets multiple secret keys be active at the same time, which is so iconic 👑

Opt Mode: The Optimized Authentication Mode is defined in Section 7 of [RFC9985]. When the Auth Type is Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8) and the format is SHA-1 Authentication Format, the Optimized Authentication Mode field will be set to 1. 🌸

Sequence Number: The sequence number for this packet. For Meticulous Keyed ISAAC Authentication, this value goes up once for each packet sent in a session. This gives protection against replay attacks, so nobody gets to sneak in old packets and pretend to be the main character 🙈

Auth Key/Digest: This field carries the 16-byte SHA-1 hash for the packet. The procedure for calculating this field is documented in Section 6.7.4 of [RFC5880]. 🦋

5. New State Variables for Meticulous Keyed ISAAC Authentications ✨

okay this section is where the document introduces its brand new state variables for Meticulous Keyed ISAAC Authentication 💖 Think of them as the notes each system keeps about what's going on in the conversation.

  • bfd.MetKeyIsaacRcvKeyKnown: A boolean value that says whether or not the system knows the receive key for the Meticulous Keyed ISAAC Authentication. It starts out false. It flips to "true" when a party checks that the other party has started using the Meticulous Keyed ISAAC Authentication with an authenticated Auth Key. 🔑
  • bfd.MetKeyIsaacRcvAuthBase: A 32-bit unsigned integer holding a copy of the bfd.RcvAuthSeq number that goes with the current ISAAC "page" used for authenticating received packets. 📖
  • bfd.MetKeyIsaacRcvAuthIndex: An 8-bit number used to index within a particular "page" of pseudorandom numbers. 🧮
  • bfd.MetKeyIsaacRcvAuthSeed: A 32-bit unsigned integer holding a copy of the Seed associated with received packets. 🌱
  • bfd.MetKeyIsaacRcvAuthData: A data structure with the ISAAC data for the received Auth Type method. The format and contents of this structure are implementation specific and hold the internal state of the ISAAC CSPRNG. It's giving "private diary" energy 🤫
  • bfd.MetKeyIsaacXmitKeyKnown: A boolean value that says whether or not the system knows the xmit key for Meticulous Keyed ISAAC Authentication. It starts out false. It flips to "true" when a party starts transmitting using Meticulous Keyed ISAAC Authentication. 📤
  • bfd.MetKeyIsaacXmitAuthBase: A 32-bit unsigned integer holding a copy of the bfd.XmitAuthSeq number that goes with the current ISAAC "page" used for authenticating sent packets. 📚
  • bfd.MetKeyIsaacXmitAuthIndex: An 8-bit number used to index within a particular "page" of pseudorandom numbers. 🔢
  • bfd.MetKeyIsaacXmitAuthSeed: A 32-bit unsigned integer holding a copy of the Seed associated with sent packets. 🌷
  • bfd.MetKeyIsaacXmitAuthData: A data structure with the ISAAC data for the sending Auth Type method. The format and contents of this structure are implementation specific and hold the internal state of the ISAAC CSPRNG. 🪄

6. Procedures for BFD Authentication Using Meticulous Keyed ISAAC, MD5, or SHA-1 Formats 🎀

the transmit and receive procedures use the extra procedures in Section 7.1 of [RFC9985]. Okay, that's the whole group chat plan 🫶

The authentication procedure for Meticulous Keyed ISAAC, MD5 Format is described in Section 6.7.3 of [RFC5880] for the Meticulous Keyed MD5 Authentication Mode.

The authentication procedure for Meticulous Keyed ISAAC, SHA-1 Format is described in Section 6.7.4 of [RFC5880] for the Meticulous Keyed SHA-1 Authentication Mode.

7. Procedures for BFD Authentication Using Meticulous Keyed ISAAC, ISAAC Format 🧚

this is the optimized authentication mode, and it's honestly so clever 😭 One or more secret keys, each with its own key ID, get configured in each system. One of those keys seeds the ISAAC PRNG. The ISAAC output is what proves the sender is legit. To help block replay attacks, every packet also carries a sequence number. For Meticulous Keyed ISAAC Authentication, the sequence number MUST go up by one on every packet.

The receiving system accepts the packet if the key ID matches one of the configured Keys, AND the Auth Key derived from the selected Key, Seed, and sequence number matches the Auth Key in the packet, AND the sequence number is strictly greater than the last sequence number received (modulo wrap at 2^32). If any of these checks fail, the packet fails validation and gets discarded. Bye bye 💀

7.1. Transmission using Meticulous Keyed ISAAC Authentication, ISAAC Format 💖

The Auth Type field MUST be set to one of two values: Optimized MD5 Meticulous Keyed ISAAC Authentication (7) or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8).

The Auth Len field MUST be set to 16.

The Auth Key ID field MUST be set to the ID of the current authentication key. The Sequence Number field MUST be set to bfd.XmitAuthSeq.

The Seed field MUST be set to the value of the current Seed used for this session.

The Auth Key field MUST be set to the output of ISAAC, which depends on the secret Key, the current Seed, and the sequence number.

The Optimized Authentication Mode field MUST be 2, the "less computationally intensive authentication type". See Section 7 of [RFC9985]. 🌈

For Meticulous Keyed ISAAC Authentication, bfd.XmitAuthSeq MUST be incremented by one on each packet in a circular fashion (when treated as an unsigned 32-bit value). The bfd.XmitAuthSeq MUST NOT be incremented by more than one per packet. No skipping ahead, bestie 🙅‍♀️

7.2. Receipt using Meticulous Keyed ISAAC Authentication, ISAAC Format 🔍

If the received BFD Control Packet does not contain an Authentication Section, or the Auth Type is not correct (either Optimized MD5 Meticulous Keyed ISAAC Authentication (7) or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (8)), then the received packet MUST be discarded.

If the Auth Key ID field does not match the ID of a configured authentication key, the received packet MUST be discarded.

The Optimized Authentication Mode field MUST be 2, the "less computationally intensive authentication type". See Section 7 of [RFC9985]. ✨

If the Auth Len field is not equal to 16, the packet MUST be discarded.

If bfd.AuthSeqKnown is 1, check the Sequence Number field. For Meticulous Keyed ISAAC, if the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space), the received packet MUST be discarded. 🚫

If bfd.MetKeyIsaacRcvKeyKnown is "true" and the Seed field does not match the current Seed value, bfd.MetKeyIsaacRcvAuthSeed, the packet MUST be discarded.

Calculate the current expected output of ISAAC, which depends on the secret Key, the current Seed, and the sequence number. If the value does not match the Auth Key field, then the packet MUST be discarded.

If bfd.MetKeyIsaacRcvKeyKnown is false, the ISAAC related variables are initialized as per Section 10.2 using the contents of the packet. 🌟

Note that in some cases, calculating the expected output of ISAAC will create a new "page" of 256 numbers. This process is irreversible and destroys the current "page". So if making the new output will create a new "page", the receiving party MUST save a copy of the entire ISAAC state before going any further with this calculation. If the outputs match, the saved copy can be thrown out and the new ISAAC state is used. If the outputs do not match, the saved copy MUST be restored, and the modified copy gets discarded or cached for later use. Be careful with that backup, it's giving "do not delete the save file" energy 😭⚠️

8. Secret Key 🔐

the security of the Meticulous Keyed ISAAC Auth Type depends on the secret key. The secret key gets mixed with a per-session Seed, as discussed below. The result is used to initialize a stream of pseudorandom numbers using the ISAAC random number generator. Keep that key secret, babe 🤫

Using the same or distinct secret keys for each Optimized Authentication Mode has security and operational impacts. See Section 15.1.2 for discussion on these points.

It is RECOMMENDED that implementations permit distinct secret keys to be provisioned for a given Auth Key ID for each Optimized Authentication Mode. The operator's choice to use such distinct secret keys instead of a single secret key is out of scope for this document. 🗝️

A particular secret key set is identified via the Auth Key ID field. This Auth Key ID is either placed in the packet by the sender or verified by the receiver. Meticulous Keyed ISAAC Authentication lets systems have multiple Secret Keys configured, but this document doesn't talk about how those keys are managed or used. A session MUST NOT, however, change the Auth Key ID for Meticulous Keyed ISAAC Authentication during a session. There is no defined way to resync or reinitialize an ongoing session with a different Auth Key ID and correspondingly different secret key. So once the session starts, the key ID is locked in 🔒

For interoperability, the management interface used to configure the key MUST accept ASCII strings and SHOULD also allow for the configuration of any arbitrary binary string in hexadecimal form. Other configuration methods MAY be supported. 🎀

The secret key MUST be at least eight (8) octets in length and SHOULD NOT be more than 128 octets in length. Main character energy, but make it a proper length 💅

9. Transition to Using ISAAC ✨

Okay bestie, this is the glow-up moment 💖. A BFD session that uses Optimized MD5 Meticulous Keyed ISAAC Authentication or Optimized SHA-1 Meticulous Keyed ISAAC Authentication MUST begin with Auth Type set to the relevant authentication type and the Optimized Authentication Mode field set to 1.

When a BFD session using more computationally intensive authentication transitions to the Up state, the first Up packet MUST contain an Optimized Authentication Mode field with value 1. State transitions need full packet integrity checks, so an Optimized Authentication Mode field with value 2 is not permitted for state changes 🙅‍♀️. Each party MUST keep using the more computationally intensive authentication mode until the other side has confirmed the switch to the Up state with a packet that also uses more computationally intensive authentication. No skipping the line, periodt 💅.

Once the session is Up, the sender MAY send the subsequent packets for the Up state with the Optimized Authentication Mode field containing value 2 using the ISAAC Format ✨.

When a system first receives a packet with the Optimized Authentication Mode field set to 2, it initializes the ISAAC PRNG state using the Seed from that packet 🌸. A system that originates a packet using Meticulous Keyed ISAAC Authentication generates a Seed and puts it into the packet, and then the packet gets sent. We'll get into more initialization details in Sections 10.1 and 10.2.

The first packet after the transition to Up is the only time the ISAAC random number generator for transmission gets initialized. A temporary switch away from Meticulous Keyed ISAAC Authentication, ISAAC Format (Section 12) and back again does not rekey ISAAC, which is very chill of it 🦋.

There's no negotiation about when authentication switches over to Meticulous Keyed ISAAC Authentication using the ISAAC Format. The sender just starts sending packets with a relevant Auth-Type and the Optimized Authentication Mode field set to 1. When the sender actually switches to Meticulous Keyed ISAAC Authentication, ISAAC Format, it sets the Optimized Authentication Mode field to 2 and starts doing the ISAAC calculations described here 🧚.

The receiving side switches over too, and it does so once it sees a packet with the Optimized Authentication Mode field set to 2 while bfd.MetKeyIsaacRcvKeyKnown is false 👀. Then it initializes its variables and authenticates the received packet by comparing the Auth Key in the packet with the key it generated itself.

The state variables MUST now follow the rules of the new Optimized Authentication Mode. In other words, when a session changes Optimized Authentication Mode, the current values of bfd.RcvAuthSeq and bfd.XmitAuthSeq are used as the starting value(s) for the new mode 💜.

10. Seeding ISAAC 🌸

The Seed field is what identifies and secures the different "streams" of random numbers that ISAAC generates 🎀. Every session gets its own Seed, and it's used together with the Your Discriminator field (Section 4.1 of [RFC5880]) and the secret key to initialize ISAAC. Iconic teamwork.

The value of the Seed field MUST be derived from a CSPRNG source. How exactly you do that is outside the scope of this document, so you're on your own there, bestie 🙈.

A brand-new Seed value MUST be created every time a BFD session transitions into the Up state. To prevent continuous rekeying, once the session is Up, the Seed for that session MUST NOT be changed until another state transition happens 🔒.

The ISAAC PRNG starts out by setting all of its internal variables and data structures to zero (0). Then it gets seeded using the following structure:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Seed                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Your Discriminator                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Secret Key ...            |  Counter |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: ISAAC Initialization Structure

Here the Your Discriminator field comes from the BFD packet defined in [RFC5880], Section 4.1 📦. Sending systems use their own respective values for this field, and receiving systems take it from the received packet.

The buffer used for seeding has a limited size, so the length of the secret key MUST be no more than 1015 octets 📏. The Counter field makes sure the initial seeding of ISAAC avoids the seeding issues discussed in ISAAC+ [ISAAC-Plus]. Smart, right? 🧠

No matter what API or other interface is used to input the Secret Key, any implementation-specific internal representation of the secret key MUST NOT be used when encoding it into the data structure above. There's no length field saying how long the key is, and there's no trailing zero or NUL byte marking where it ends. Implementors, this is your reminder that internal representations of data shouldn't affect protocol operation 💅.

The buffer gets filled with repeated copies of the structure above. For each complete copy, the Counter field goes up, starting from zero (0) 🔢. The last part of the initialization buffer holds a partial copy of the structure, as much of it as fits in whatever room is left.

Once the ISAAC "page" is set up, the data gets run through the "randinit()" function of ISAAC [ISAAC]. After that, pseudo-random numbers come out 32 bits at a time by calling the "isaac()" function ✨.

For the sender, this calculation can be done outside of the BFD "fast path" as soon as the Your Discriminator value is known 🏃‍♀️. For the receiver, the calculation can only happen once the Seed arrives from the sender, so the initial seeding has to happen inside the BFD "fast path" instead.

The table below gives the Seed and Your Discriminator as 32-bit hexadecimal values, and the secret key as an eleven-character string. The table after it shows the first eight sequence numbers and the matching Auth Key values that come out of those initial values 🍓.

                       +============+=============+
                       | Field      | Value(s)    |
                       +============+=============+
                       | Seed       | 0x0bfd5eed  |
                       +------------+-------------+
                       | Y-Disc     | 0x4002d15c  |
                       +------------+-------------+
                       | Secret Key | RFC5880June |
                       +------------+-------------+
                       | Counter    | 0...50      |
                       +------------+-------------+

                         Table 1: Test Inputs for
                              Seeding ISAAC

                          +==========+==========+
                          | Sequence | Auth Key |
                          +==========+==========+
                          | 0        | 9af65d83 |
                          +----------+----------+
                          | 1        | 44355d56 |
                          +----------+----------+
                          | 2        | 9334074e |
                          +----------+----------+
                          | 3        | b643ef59 |
                          +----------+----------+
                          | 4        | 74d659f1 |
                          +----------+----------+
                          | 5        | 8966dc56 |
                          +----------+----------+
                          | 6        | a1f6f9bc |
                          +----------+----------+
                          | 7        | 21895a46 |
                          +----------+----------+

                         Table 2: Expected Outputs

This construct gives you 64 bits of entropy, and each party in the BFD session controls 32 of them 🌈. For security, each implementation SHOULD randomize its discriminator fields at the start of a session, as discussed in [RFC5880], Section 9 🔐.

Heads up: this construct only uses the Your Discriminator field once, to seed ISAAC. That means the My Discriminator field is allowed to change, as BFD [RFC5880] (Section 6.3) permits 🦋.

The Your Discriminator field can change, but there's no way to signal or negotiate changes to the Seed. The Seed is set once by each party after the session transitions into the Up state, and then it stays the same for the whole session. The receiving party MUST remember the current Seed value 🧠. The Seed value MUST NOT change unless the sending party has signaled a BFD state change with a packet that's authenticated using a more computationally intensive authentication method. And when a system gets a BFD packet containing Meticulous Keyed ISAAC Authentication, it MUST check that the received Seed has the expected value. If it doesn't, it MUST discard the packet as inauthentic 🚫.

10.1. Sender Variable Initialization 💅

A system that sends packets initializes ISAAC the way we described above. Here's how the ISAAC-related variables get set up, bestie 💖.

bfd.MetKeyIsaacXmitKeyKnown: This variable flips from false to true when the sender decides to start using ISAAC. The sender also initializes the other variables at that same moment ✨.

bfd.MetKeyIsaacXmitAuthBase: The sender copies the bfd.XmitAuthSeq number from the current packet about to be sent into this variable 📤.

bfd.MetKeyIsaacXmitAuthIndex: The sender sets this variable to zero (0) 🎯.

bfd.MetKeyIsaacXmitAuthSeed: The sender copies the current Seed value into this variable. This variable then gets copied into the "Seed" field of each Auth Type packet 🌱.

bfd.MetKeyIsaacXmitAuthData: The ISAAC state for sending is encapsulated in this variable 🫶.

10.2. Receiver Variable Initialization ✨

Okay bestie, now it's the receiver's turn 🦋 When a system gets packets with Meticulous Keyed ISAAC Authentication and can authenticate one for the first time, it sets up its ISAAC variables like this:

  • bfd.MetKeyIsaacRcvKeyKnown: this one flips from false to true when the receiver notices the sender has started using Meticulous Keyed ISAAC Authentication. The receiver sets up the other variables at that same moment 💖
  • bfd.MetKeyIsaacRcvAuthBase: the bfd.RcvAuthSeq number from the current packet gets copied in here.
  • bfd.MetKeyIsaacRcvAuthIndex: the receiver sets this to zero.
  • bfd.MetKeyIsaacRcvAuthSeed: the receiver copies the Seed value from the received packet into this. Lowkey important: this copy only happens when bfd.MetKeyIsaacXmitKeyKnown goes from false to true.
  • bfd.MetKeyIsaacRcvAuthData: the ISAAC state for receiving lives in this variable 🧚

Now the tricky part 😭 Packets can get lost, so the receiver has to be extra careful when it sets bfd.MetKeyIsaacRcvAuthBase. If nothing got lost, bfd.MetKeyIsaacRcvAuthBase is taken straight from bfd.RcvAuthSeq, and bfd.MetKeyIsaacRcvAuthIndex is set to zero. Easy peasy 🌸

But if the packet's sequence number is different from what was expected, the difference "N" tells you how many packets went missing. The receiver can use that difference to index into the ISAAC page and find the matching Auth Key. If the key in the ISAAC page doesn't match the Auth Key in the packet, the packet fails validation and gets discarded. No mercy 💅

If a key found by indexing into this ISAAC page does match the Auth Key in the packet, then bfd.MetKeyIsaacRcvAuthIndex gets set to that value. Then bfd.MetKeyIsaacRcvAuthBase is set to bfd.RcvAuthSeq minus bfd.MetKeyIsaacRcvAuthIndex. This is what lets the pseudorandom stream resync after lost packets, and it's honestly iconic 🔥

So the value of bfd.MetKeyIsaacRcvAuthBase is the sequence number of the first Auth Key used in this session. That value might come from a lost packet, but the receiver can still work it out from a later packet. The math is doing the most 🧮✨

11. Operation 🌈

Once the variables are initialized, ISAAC can produce 256 random numbers to use as Auth Keys at near-zero cost. The AuthIndex field goes up by one for every new Auth Key generated. Each new value of the Sequence Number field (sent or received) is then calculated by adding the relevant AuthBase and AuthIndex fields. Bestie, this is so clean 🫶

When all 256 numbers are used up, AuthIndex wraps back to zero. The ISAAC mixing function then runs, which gives you another set of 256 random numbers. AuthBase goes up by 256 to show that 256 Auth Keys have been used. This keeps going until there's a BFD state change 🦋

Think of ISAAC as an infinite stream of numbers based on a secret key, where the numbers come out in "pages" of 256 32-bit values. This is the property that makes "seeking" within a page basically free 💜 The expensive mixing only happens once per 256 packets, so most BFD packet exchanges stay fast and efficient. Main character energy for sure ⭐

The receiving party looks at the sequence number to figure out which particular PRNG value is being used in the packet. By subtracting bfd.MetKeyIsaacAuthBase from the sequence number (with possible wrapping), it can work out the expected Index and find the matching Auth Key. This is how the two parties stay in sync when packets get lost 🤝

Incrementing the sequence number for every packet also stops any single pseudorandom number derived from ISAAC from being reused 🔒

The sequence number can keep going without bounds, though it can wrap once it hits the limit of the 32-bit counter field. ISAAC has a cycle length of 2^8287, so using more than 2^32 values from it is totally fine 🌈

The end result is an infinite series of numbers that can't be guessed and can be used to authenticate the sending party. Literally unguessable 💀

Each system sending BFD packets picks its own seed, generates its own sequence of pseudorandom numbers with ISAAC, and puts those values into the Auth Key field. Each system receiving BFD packets runs its own separate pseudorandom number generator and checks that the received packets contain the expected Auth Key 👑

11.1. Page Flipping 🎀

Once all 256 Auth Keys on the current page have been used, the next page gets calculated by calling the isaac() function. This function changes the current page to make the next one, so it's destructive by design. To avoid problems, you have to do this part carefully 🙈

It is RECOMMENDED that implementations keep both a current page and a next page associated with the ISAAC state. The next page can be calculated by making a copy of the current page and then calling the isaac() function. Copy first, then isaac, no cap 🍓

The system has to keep the current page at all times when Meticulous Keyed ISAAC Authentication is in use. The next page doesn't need to be kept around all the time and can be calculated on demand. However, to avoid slowing down the fast path, the next page should be calculated in the background, asynchronously 🧚

This approach has a few perks. First, at 60 packets per second, the system has roughly four (4) seconds to calculate the next page. If the calculation is quick, the next page is ready for the fast path before it's needed 🏃‍♀️💨

Second, having the next page ready early means an attacker can't spoof BFD packets and force the receiver to burn lots of resources calculating a next page on the BFD fast path. Instead, the receiver can just check the contents of the next page at near-zero cost and toss out the spoofed packet. Not today, hacker 😤

When the receiver decides it needs to move to the next page, it can swap the current and next pages (updating the BFD variables as needed) and then start calculating a new next page asynchronously. Async calculations are way better than doing it on the BFD fast path 💅

This document does not cover the case of losing more than 512 packets. Implementors MUST limit the value of Detect Multi to a small enough number to keep the number of lost packets within an acceptable limit. Bestie, please don't skip this one 🚨

11.2. Multiple Keys 🔑

In a keyed algorithm, the key is shared between the two systems. Getting that key to all the systems at the same time can be a super cumbersome job 😩 BFD sessions running at a fast rate may need their keys refreshed often, which is an extra challenge.

The Auth Key ID field lets you provision multiple keys at once, but BFD has no way for each party to say which set of Key IDs it supports. Any signaling or negotiation has to happen "out of band" for BFD, usually through manual administrator configuration 🛠️

The seeding mechanism for ISAAC, covered in Section 10, only runs once for a BFD session. To rotate keys, it is REQUIRED to administratively disable the BFD session as part of changing the keys. Bringing the session back up then lets the new session get seeded fresh 🌱

12. Transition Away from Using ISAAC 🦋

There are two ways to move away from using ISAAC 💫 The first is through state changes: either the link goes down because of a fault, or one party signals a state change in a packet signed with a more computationally intensive authentication. The second is when one party wants to temporarily signal, using the more computationally intensive method, that it's still Up. It does this by changing the Optimized Authentication Mode field from value 2 to value 1.

The more computationally intensive authentication type gives you full packet integrity checks, so it's a stronger sign that the session is Up and both parties are fully synchronized 🔐 This switch can happen at any point during a session.

It is RECOMMENDED that implementations periodically switch to the more computationally intensive authentication type for packets that keep the session in the Up state. The gaps between these switches SHOULD be long enough that the system still gets a real benefit from using Meticulous Keyed ISAAC Authentication. See [RFC9985] for the right procedure for switching Optimized Authentication Mode ✨

When switching to the more computationally intensive authentication mode after ISAAC has been seeded, the Authentication Section's Sequence Number field keeps increasing meticulously. To be able to switch back to ISAAC as the less computationally intensive mechanism, ISAAC has to keep generating pages that are appropriate for validating the received sequence number 🧚‍♀️

[RFC9985] describes the procedures that require switching to the more computationally intensive authentication mode, particularly BFD Poll Sequences 🌸

13. The YANG Module ✨

okay so this section is where the YANG model shows up 💅 It adds two identities to the YANG key chain model from [RFC8177]. The first one pairs Meticulous Keyed MD5 as the more computationally intensive authentication with Meticulous Keyed ISAAC, ISAAC Format as the less computationally intensive one. The second one pairs Meticulous Keyed SHA-1 as the more computationally intensive authentication with that same Meticulous Keyed ISAAC, ISAAC Format option 🦋

<CODE BEGINS> file "ietf-bfd-met-keyed-isaac@2026-06-19.yang"
module ietf-bfd-met-keyed-isaac {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac";
  prefix bfd-mki;

  import ietf-key-chain {
    prefix key-chain;
    reference
      "RFC 8177: YANG Data Model for Key Chains.";
  }

  organization
    "IETF Bidirectional Forwarding Detection (BFD) Working Group";

  contact
    "WG Web:   <https://datatracker.ietf.org/wg/bfd>
     WG List:  <rtg-bfd@ietf.org>

     Authors: Mahesh Jethanandani (mjethanandani@gmail.com)
              Ashesh Mishra (ashesh@aalyria.com)
              Jeffrey Haas (jhaas@juniper.net)
              Alan Dekok (alan.dekok@inkbridge.io)
              Sonal Agarwal (sonal@arrcus.com).";

  description
    "This YANG module provides identities derived from the
     ietf-key-chain model for the experimental BFD Meticulous Keyed
     ISAAC Authentication Mechanism.

     Copyright (c) 2026 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC 9986
     (https://www.rfc-editor.org/info/rfc9986); see the RFC itself
     for full legal notices.";

  revision 2026-06-19 {
    description
      "Initial Version.";
    reference
      "RFC 9986: Meticulous Keyed ISAAC for Bidirectional
       Forwarding Detection (BFD) Optimized Authentication.";
  }

  identity optimized-md5-meticulous-keyed-isaac {
    base key-chain:crypto-algorithm;
    description
      "BFD Optimized Authentication using Meticulous Keyed MD5 as the
       strong authentication and Meticulous Keyed ISAAC, ISAAC Format
       as the less computationally intensive authentication.";
    reference
      "RFC 9986: Meticulous Keyed ISAAC for Bidirectional
       Forwarding Detection (BFD) Optimized Authentication.";
  }

  identity optimized-sha1-meticulous-keyed-isaac {
    base key-chain:crypto-algorithm;
    description
      "BFD Optimized Authentication using Meticulous Keyed SHA-1 as
       the strong authentication and Meticulous Keyed ISAAC, ISAAC
       Format as the less computationally intensive authentication.";
    reference
      "RFC 9986: Meticulous Keyed ISAAC for Bidirectional
       Forwarding Detection (BFD) Optimized Authentication.";
  }
}
<CODE ENDS>

14. IANA Considerations 🎀

okay IANA gets its own little moment here. This section says IANA has assigned two BFD Auth Types, one URI, and one YANG module 🌸

14.1. BFD Auth Types

IANA has added the following two Auth Types to the "BFD Authentication Types" registry and to the accompanying YANG and MIB modules:

  • 7: Optimized MD5 Meticulous Keyed ISAAC Authentication
  • 8: Optimized SHA-1 Meticulous Keyed ISAAC Authentication

14.2. IETF XML Registry

IANA has registered the following URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]:

URI:  urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac
Registrant Contact:  The IESG
XML:  N/A; the requested URI is an XML namespace.

14.3. The YANG Module Names Registry

IANA has registered the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group:

Name:  ietf-bfd-met-keyed-isaac
Maintained by IANA?  N
Namespace:  urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac
Prefix:  bfd-mki
Reference:  RFC 9986

15. Security Considerations 💀

this part is serious, bestie, so pay attention 🫶 Everything here matters for keeping sessions safe, and it's all about how the keys and the ISAAC algorithm hold up.

15.1. Protocol Security Considerations

all security considerations of [RFC5880] and [RFC9985] apply to this document, so go read those too 🔒

distributing secret keys is typically done through provisioning. Secure distribution of these keys for any particular provisioning mechanism is out of scope for this document.

Keys that are generated and distributed out of band for the purposes of this specification are generally limited in the security they can provide. It is essential that these keys are selected well and protected when stored.

the security of this proposal depends on the security of the ISAAC algorithm, which has had minimal analysis. It is believed that the algorithm is secure enough for this use case, but no proof is offered. ISAAC was chosen for the reasons discussed in Section 3.1, because no other option was found to be suitable.

the choice of ISAAC was driven partly by the limited functionality of systems that implement this specification. Many of these systems do not have hardware assistance for cryptographic operations, which means any CSPRNG based on a block cipher would be unsuitably slow. Where hardware assistance for block ciphers is available, ISAAC offers no advantages over those methods.

as CPUs get faster and hardware acceleration becomes more common, more secure methods become better options. Alternative solutions could be AES with hardware acceleration in Output Feedback Mode (OFB) (see FIPS 197 and SP 800-38A), Chacha in software [RFC8439], or other well-understood techniques.

for all of these reasons and many others, the ISAAC CSPRNG is, at best, tolerable for use in this specification and is completely unsuitable for use in any other IETF protocol 😭

the security of this proposal depends strongly on the length of the secret key and on its entropy. It is RECOMMENDED that the key be 16 octets in length or more.

the dependency on the secret key for security is eased by using two 32-bit numbers: the Your Discriminator field from the BFD protocol and the ISAAC Seed. Both numbers are procedurally required to be random. These numbers act as a nonce that keeps attackers from performing an offline brute-force dictionary attack to discover the key 🧚

15.1.1. Spoofing

Meticulous Keyed ISAAC Authentication protects the session against the spoofing of BFD Up packets and keeps the BFD session Up when it would otherwise be reset.

if Meticulously Keyed ISAAC, which is operating as the less computationally intensive authentication mechanism for Optimized BFD, ever gets subverted, the periodic more computationally intensive reauthentication mechanism limits how long the session can be kept inappropriately in the Up state (Section 5 of [RFC9985]) ⏳

the Meticulous Keyed ISAAC Authentication method lets the BFD endpoints detect a malicious packet in a number of different ways. Packets that are malformed are discarded. Packets that do not pass the BFD state machine [RFC5880] (Section 6.2) checks are discarded. Packets that do not have the correct sequence number, Seed, and Auth Key are discarded. These discarded packets have no effect on the BFD state machine 🛡️

the correlation between the sequence number and the Auth Key makes sure that each sequence number has a corresponding Auth Key associated with it. The structure and design of the ISAAC CSPRNG make sure that each Auth Key is unique and is unguessable ✨

performing an attack on this authentication method would require all of the following to be true:

  • The attacker is on-path and can perform an active attack.
  • The attacker has the contents of one or more packets.
  • The attacker has deduced the secret key used for ISAAC and is able to correlate the sequence number to the current ISAAC state.

these conditions are unlikely to all be true at once 🙈 If the secret key is long and complex, the search space to guess it is too large to discover via brute-force. The use of the Seed and Your Discriminator fields when seeding ISAAC adds 64 bits of entropy to each session, which makes offline dictionary attacks even more impractical.

15.1.2. Reuse of Keys

the cryptographic strength of the Optimized Authentication Mode methods is significantly different between SHA-1 and ISAAC. ISAAC has had cryptanalysis and has not been shown to be broken, but that analysis is limited. So the question is whether it is safe to use the same key for both mechanisms (SHA-1 and ISAAC), or whether we should require different keys for each mechanism 🤔

ISAAC is seeded not only with the secret key, but also with 32 bits of random data along with 32 bits of a sequence number. This added randomness increases the difficulty of breaking the secret key.

if we recommended different keys, the two keys could be configured differently on each side of a BFD link. For example, a correctly configured key could let the BFD state machine advance to Up. Then, when the session switches to the less computationally intensive Optimized Authentication Mode with a different key, that key may not match and the session would immediately drop. Suggesting that the keys be identical instead means that no such misconfiguration is possible 💅

if it becomes possible to recover the secret key for the Meticulous Keyed ISAAC Auth Type, and the same key is used for more computationally intensive authentication types such as the MD5 and SHA-1 types defined in this document, then authentication for those mechanisms would be compromised 💀

Implementations are therefore free to use the same key or different keys for the Optimized Authentication Modes. The choice between a single secret key or a distinct secret key per Optimized Authentication Mode must be evaluated by the operator, who is balancing their security and operational requirements.

15.1.3. Random Number Considerations ✨

okay bestie, let's talk randomness 🎲💖 BFD [RFC5880] and its Authentication stuff, including Meticulous Keyed ISAAC Authentication from this doc, totally rely on random numbers. They show up in:

  • Per BFD session Local Discriminators (bfd.LocalDiscr - Section 6.8.1 of [RFC5880])
  • Initial Authentication sequence number (bfd.XmitAuthSeq - Section 6.8.1 of [RFC5880])
  • Meticulous Keyed ISAAC Authentication, ISAAC Format Seed (Section 4.1)

The mechanism in this document makes an ISAAC instance for each BFD session 🧚, seeded by that session's secret key(s) plus two locally generated random numbers: the session's Local Discriminator, which gets echoed back in the protocol as Your Discriminator, and a locally generated Seed. These numbers are generated way less often than the stuff ISAAC is built for in BFD Optimized Authentication, so you can use beefier random number generators with stronger entropy guarantees. It's giving reliability 🔥.

highkey RECOMMENDED: these locally generated random numbers, both the ones for the BFD protocol and the ones for initializing ISAAC, should use a non-ISAAC CSPRNG 💅. It is RECOMMENDED that these locally generated random numbers used for the BFD protocol and for initializing ISAAC utilize a non-ISAAC CSPRNG.

ngl this next part is strict 🙈: random numbers in BFD MUST come from a different source than the ISAAC generator used to create per-BFD session Auth Keys. A different ISAAC instance MAY be used to make random numbers for use elsewhere in BFD 🌸. So nobody accidentally leaks the local random number generator state 😭, that instance MUST be distinct from the generator used for per-session Auth Keys, and it MUST NOT be keyed from any BFD session's secret key. Iconic boundary energy 👑.

15.2. YANG Security Considerations 🔐

This section is modeled after the template described in Section 3.7.1 of [RFC9907].

The "ietf-bfd-met-keyed-isaac" YANG module is a data model meant to be accessed through YANG-based management protocols, like the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. These management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication 🫶.

The Network Configuration Access Control Model (NACM) [RFC8341] is the tool that lets you restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content 💅.

There are no particularly sensitive writable data nodes. 🌈

There are no particularly sensitive readable data nodes. 🦋

There are no particularly sensitive RPC or action operations. ✨

The YANG module defines a set of identities, and those identities are meant to be reused by other YANG modules. The module by itself doesn't expose any writable data nodes, any data nodes that contain read-only state, or any RPCs. So there are no additional security issues related to the YANG module that need to be considered 😭💜.

16. References 📚

16.1. Normative References

16.2. Informative References

Acknowledgments 🫶

The authors want to thank Ketan Talaulikar for his reviews and suggestions, which made this document so much better 💖.

Contributors 💜

The authors of this document want to acknowledge Ankur Saxena and Reshad Rahman as contributors to this document 🌷.

Authors' Addresses 📮

Alan DeKok
InkBridge Networks
100 Centrepointe Drive #200
Ottawa ON K2G 6B1
Canada
Email: alan.dekok@inkbridge.io


Mahesh Jethanandani
Arrcus
Email: mjethanandani@gmail.com


Sonal Agarwal
Arrcus, Inc.
170 W. Tasman Drive
San Jose, CA 95070
United States of America
Email: sagarwal12@gmail.com


Ashesh Mishra
Aalyria Technologies
Email: ashesh@aalyria.com


Jeffrey Haas
HPE
Email: jeffrey.haas@hpe.com
📦 where this page comes from