| Internet-Draft | ISAAC Authentication | October 2025 |
| Dekok, et al. | Expires 11 April 2026 | [Page] |
This document describes a BFD Optimized Authentication Mode, Meticulous Keyed ISAAC Authentication. This mode can be used to authenticate some BFD packets with less CPU time cost than using MD5 or SHA1, with the tradeoff of decreased security. This mechanism cannot be used to signal state changes, but it can be used to maintain a session in the Up state.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
BFD [RFC5880] (Section 6.7) defines a number of authentication mechanisms, including Simple Password, and various other methods based on MD5 and SHA1 hashes. The benefit of using cryptographic hashes is that they are secure. The downside to cryptographic hashes is that they are expensive and time consuming on resource-constrained hardware.¶
When BFD packets are unauthenticated, it is possible for an attacker to forge, modify, and/or replay packets on a link. These attacks have a number of side effects. They can cause parties to believe that a link is down, or they can cause parties to believe that the link is up when it is, in fact, down.¶
[I-D.ietf-bfd-optimizing-authentication] defines procedures that enable better scaling of authentication for BFD by splitting BFD authentication work between more computationally intensive authentication used for significant changes, and less computationally intensive authentication for packets validating that the session is in the Up state. See that document for general performance and security considerations.¶
This document provides the definition of BFD optimized authentication modes using the existing MD5 (Section 6.7.3 of [RFC5880]) and SHA1 (Section 6.7.4 of [RFC5880]) authentication mechanisms for the more computationally intensive work. It also defines methods for using a mechanism, ISAAC [ISAAC], for the less computationally intensive mechanism.¶
ISAAC requires only a few CPU operations per generated 32-bit number, can take a large secret key as a seed, and it has an extremely long cycle length. These properties make it ideal for use in BFD.¶
ISAAC+ [ISAAC_] documents some cryptanalysis of the ISAAC mechanism. This analysis addressed an issue with initial seeding, and the method proposed here incorporates recomendations to address that attack.¶
RFC5880 [RFC5880] uses the term "meticulous keyed" and "meticulous keying" without defining those terms. That meaning of that term is found by examining the definition of the Sequence Number from BFD [RFC5880] (Section 4.2):¶
In this context, the term "meticulous" means that the Sequence number is incremented on every new packet which is sent. The term "keyed" means that the packets are authenticated via the use of a secret key or keys which are known to both sender and receiver. The term "meticulous keyed" therefore refers to BFD authentication type where each subsequently transmitted packet has a sequence number one greater than the immediately prior one, and can be authenticated.¶
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.¶
This document uses several placeholder values throughout the document. Please replace them as follows and remove this note before publication.¶
RFC XXXX, where XXXX is the number assigned to this document at the time of publication.¶
2025-10-08 with the actual date of the publication of this document.¶
This document describes an experimental update to BFD [RFC5880]. This experiment is intended to provide additional insights into what happens when the authentication method defined in this document is used.¶
This document is classified as Experimental and is not part of the IETF Standards Track. Implementations based on this document should not be considered as compliant with BFD [RFC5880] and should not assume interoperability with other implementations that conform to this document.¶
Some of the state variables in BFD [RFC5880] (Section 6.8.1), are related to the authentication type being used for a particular session. However, the definitions given in BFD [RFC5880] are specific to Keyed MD5 or SHA1 Authentication, which limit their utility for new authentication types. For the purpose of the experiment, this specification updates the definition of some of the state variables as given below.¶
These updated definitions are entirely compatible with the definitions given in BFD [RFC5880] (Section 6.8.1), and require no changes to existing configurations or implementations. Instead, the updated definitions clarify that the state variables apply to the current authentication type, no matter what it is.¶
The text first updates the [RFC5880] definitions, and then defines a new authentication type which uses these updated definitions.¶
These updated definitions also mean that Authentication Sections SHOULD include a Sequence Number field. Where a Sequence Number is not used (as with Simple Password) the variables bfd.RcvAuthSeq and bfd.XmitAuthSeq MUST be set to zero. Where an Authentication Section uses a meticulous keyed authentication type, it MUST include a Sequence Number field.¶
The current authentication type in use for this session, as defined in BFD [RFC5880] (Section 4.1), or zero if no authentication is in use.¶
When using an authentication method implementing optimized authentication ([I-D.ietf-bfd-optimizing-authentication]), packets which indicate a BFD significant change MUST use an authentication method which provides for full packet integrity checks with the more computationally intensive authentication method. When the bfd.SessionState value is Up, packets MAY use a less computationally intensive authentication method such as Meticulous Keyed ISAAC.¶
Set to 1 if the next expected Authentication Section has a sequence number which is known, or 0 if it is not known. This variable MUST be initialized to zero.¶
This variable MUST be set to zero after no packets have been received on this session for at least twice the Detection Time. This ensures that the sequence number can be resynchronized if the remote system restarts.¶
This document specifies two Optimized BFD [I-D.ietf-bfd-optimizing-authentication] authentication modes:¶
ISAAC is used as a way to generate an infinite stream of pseudo-random numbers, referred to here as "Auth Keys". With Meticulous Keyed ISAAC Authentication, these Auth Keys are used as a signal that the sending party is authentic. That is, only the sending party can generate the correct Auth Keys. Therefore if the receiving party sees a correct Auth Key in a BFD Control Packet in the Up state, then only the sending party could have generated it.¶
Note that BFD Control Packets with the less computationally intensive ISAAC authentication format type are NOT signed or authenticated. Therefore, this format MUST NOT be used to signal BFD state changes.¶
There are many CSPRNGs available. This section explains why ISAAC was chosen.¶
The goal for this less computationally intensive authentication was to provide a signal that the session was in the Up state, in the form of a 32-bit number which is difficult for an attacker to guess. The number should be generated from a CSPRNG which produces results based on a seed composed of both public and private data. Since BFD can have packet loss, the generator should also be "seekable", in that the BFD state machine should be able to query the generator (within a small window) for new numbers.¶
This last property rules out most CSPRNGs, as they are not seekable by design. That is, most CSRNGs maintain minimal state, and are designed to produce a long sequence of pseudo-random numbers from a few simple calculations. In general, every call to the CSPRNG function modifies the internal state in an irreversible fashion, and then produces a new random number as the result.¶
It could be possible to use such a generator, and then to manually save many results in a buffer. This buffer could then enable "seeking" within a short window. In contrast, ISAAC produces large sets of numbers by design, making it an integrated solution.¶
Further, most CSPRNGs are designed to have small seeds. This limitation means that any secret key defined by an administrator is not directly usable as a seed for the generator. Instead, any secret key (including any per-session data) would have to be hashed before being used to see the generator. For these reasons, ISAAC was chosen. It can accept keys up to 8192 octets in length, which is more than sufficient for BFD.¶
ISAAC has been subject to cryptanalysis, most notably ISAAC+ [ISAAC_]. There are no known vulnerabilities.¶
An instance of ISAAC is created for transmission and one for reception. An instance is required for each direction since the inputs for seeding ISAAC require the locally randomly generated Seed value, and the current BFD Your Discriminator value for an Up session, and these values are distinct on each side of the BFD session.¶
The process for using ISAAC with BFD for each direction is then as follows:¶
In summary, the ISAAC seed depends on both a secret key and per-session data, so it is difficult for an attacker to guess or attack via an off-line dictionary attack. The generated numbers are saved in an array, where the BFD fast path can consume them at essentially zero cost.¶
The only downside to this method is that it does not provide for per-packet integrity checks. This 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 which satisfies both the needs of the BFD state machine, and is secure.¶
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains either Optimized MD5 Meticulous Keyed ISAAC Authentication (TBD1), or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (TBD2), and the Optimized Authentication Mode field contains 2 (Section 7 of [I-D.ietf-bfd-optimizing-authentication]) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This field carries the 32-bit (4 octet) ISAAC output which is associated with the Sequence Number. The ISAAC PRNG MUST be configured and initialized as given in Section 10, below.¶
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 receives 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, as it is the only one who could have sent the message.¶
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains Optimized MD5 Meticulous Keyed ISAAC Authentication (TBD1), and the Optimized Authentication Mode field contains 1 (Section 7 of [I-D.ietf-bfd-optimizing-authentication]) 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the Authentication Present (A) bit is set in the header, and the Authentication Type field contains Optimized SHA1 Meticulous Keyed ISAAC Authentication (TBD2), and the Optimized Authentication Mode field contains 1 (Section 7 of [I-D.ietf-bfd-optimizing-authentication]) 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/Hash... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document defines new state variables for use with Meticulous Keyed ISAAC Authentication.¶
The transmit and receive procedures utilize the additional procedures documented in Section 7.1 of [I-D.ietf-bfd-optimizing-authentication].¶
The authentication procedure for Meticulous Keyed ISAAC, MD5 Format is covered by Section 6.7.3 of [RFC5880] for the Meticulous Keyed MD5 Authentication mode.¶
The authentication procedure for Meticulous Keyed ISAAC, SHA1 Format is covered by Section 6.7.4 of [RFC5880] for the Meticulous Keyed SHA1 Authentication mode.¶
In this mode of optimized authentication, one or more secret keys (with corresponding key IDs) are configured in each system. One of the keys is used to seed the ISAAC PRNG. The output of ISAAC is used to signal that the sender is authentic. To help avoid replay attacks, a sequence number is also carried in each packet. For Meticulous Keyed ISAAC Authentication, the sequence number MUST be incremented 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 carried 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 criteria do not match, the packet fails validation, and is discarded.¶
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 (TBD1); or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (TBD2).¶
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 [I-D.ietf-bfd-optimizing-authentication].¶
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.¶
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 (TBD1) or Optimized SHA-1 Meticulous Keyed ISAAC Authentication (TBD2)), 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 [I-D.ietf-bfd-optimizing-authentication].¶
If the Auth Len field is not equal to 16, the packet MUST be discarded.¶
If bfd.AuthSeqKnown is 1, examine 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 result in the creation of a new "page" of 256 numbers. This process will be irreversible, and will destroy the current "page". As a result, if the generation of a new output will create a new "page", the receiving party MUST save a copy of the entire ISAAC state before proceeding with this calculation. If the outputs match, then the saved copy can be discarded, and the new ISAAC state is used. If the outputs do not match, then the saved copy MUST be restored, and the modified copy discarded, or cached for later use.¶
The security of the Meticulous Keyed ISAAC Auth Type depends on the Secret Key. The Secret Key is mixed with a per-session Seed as discussed below. The result is used to initialize a stream of pseudo-random numbers using the ISAAC random number generator.¶
A particular Secret Key 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 permits systems to have multiple Secret Keys configured, but we do not discuss 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 re-sync or re-initialize an ongoing session with a different Auth Key ID and correspondingly different Secret Key.¶
For interoperability, the management interface by which the key is configured 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.¶
There are no known issues with using the same secret Key for multiple Auth Type methods. However, it is RECOMMENDED that administrators use different Secret Keys for each Auth Type.¶
A BFD session which uses Optimized MD5 Meticulous Keyed ISAAC Authenticationo or Optimized SHA-1 Meticulous Keyed ISAAC Authentication MUST begin a session 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. Since state transitions require full packet integrity checks, an Optimized Authentication Mode field with value 2 is not permitted for state changes. Each party MUST continue to use 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.¶
Once the BFD session has transitioned to the Up state, the sender MAY send the subsequent packets for the Up state with the Optimized Authentication Mode field containing value 2 using ISAAC format.¶
When a system first receives a packet containing Optimized Authentication Mode field with value 2, it initializes the ISAAC PRNG state using the Seed from that packet. A system originating a packet using Meticulous Keyed ISAAC Authentication will generate a Seed, and place it into the packet which is then sent. Further discussion of initialization is below in Section 10.1 and Section 10.2.¶
The first packet after the transition to the Up state is the only time when the ISAAC random number generator for transmission is initialized. In contrast, a temporary transition away from using Meticulous Keyed ISAAC Authentication, ISAAC format (Section 12) and back, does not cause ISAAC to be re-keyed.¶
There is no negotiation as to when authentication switches from the original type, to using Meticulous Keyed ISAAC Authentication using the ISAAC format. The sender simply begins sending packets with a relevant Auth-Type, and with the Optimized Authentication Mode field set to 1. When the sender switches to using using Meticulous Keyed ISAAC Authentication, ISAAC format, it sets the Optimized Authentication Mode field to 2, and starts performing the ISAAC calculations as described here.¶
Similarly, a receiving system switches to using this method when it sees that it has received a packet contains Optimized Authentication Mode field set to 2 when bfd.MetKeyIsaacRcvKeyKnown variable is false. The receiving system then initializes its variables, and authenticates the received packet, by comparing the Auth Key in the packet with the key it generated itself.¶
The operation of those state variables MUST now satisfy the requirements of the new Optimized Authentication Mode. That is, when changing Optimized Authentication mode in a session, the current value of the bfd.RcvAuthSeq and bfd.XmitAuthSeq variables is used as the initial value(s) for the new mode.¶
The Seed field is used to identify and secure different "streams" of random numbers which are generated by ISAAC. Each session uses a different Seed, which is used along with the Your Discriminator field (Section 4.1 of [RFC5880]), and the Secret Key, to initialize ISAAC.¶
The value of the Seed field MUST be derived from a CSPRNG source. Exactly how this can be done is outside of the scope of this document.¶
A new Seed value MUST be created every time a BFD session transitions into the Up state. In order to prevent continuous rekeying, once the session is in the Up state, the Seed for a session MUST NOT be changed until another state transition occurs.¶
The ISAAC PRNG is initialized by setting all internal variables and data structures to zero (0). The PRNG is then seeded by using the 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the Your Discriminator field is taken from the BFD packet defined in RFC5880 Section 4.1 [RFC5880]. This field is taken from the respective values used by a sending system. For receiving systems, the field are taken from the received packet. As the size of the buffer used to seed is limited, the length of the Secret Key MUST be no more than 1015 octets. The Counter field is used to ensure the the initial seeding of ISAAC avoids the seeding issues discussed in ISAAC+ [ISAAC_].¶
Whatever the API or other interface used to input the Secret Key, any implementation-specific internal representations of the Secret Key MUST NOT be used when encoding the Secret Key into the above data structure. That is, there is no "length field which indicates how long the Secret Key is, and there is no trailing zero or NUL byte which indicates the end of the Secret Key. Implementers are reminded that internal representations of data should not affect protocol operation.¶
The buffer used to initialize ISAAC filled it with repeated copies of the above structure. For each complete copy of the structure, the Counter field is incremented, starting from zero (0). The final portion of the initialization buffer holds a partial copy of the structure, which is however much can be accommodated in the remaining portion of the buffer.¶
Once the ISAAC "page" is initialized, the data is processed through the "randinit()" function of ISAAC [ISAAC]. Pseudo-random numbers are then produced 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, this calculation can only be done when the Seed is received from the sender, and therefore the initial seeding needs to be done in the BFD "fast path".¶
The following table gives Seed and Your Discriminator as 32-bit hexadecimal values, and the Secret Key as an eleven-character string. The subsequent table shows the first eight Sequence numbers and corresponding Auth Key values which were generated using the above initial values.¶
Field Value(s)
---------- ------------
Seed 0x0bfd5eed
Y-Disc 0x4002d15c
Secret Key RFC5880June
Counter 0...50
Sequence Auth Key
-------- --------
0 9af65d83
1 44355d56
2 9334074e
3 b643ef59
4 74d659f1
5 8966dc56
6 a1f6f9bc
7 21895a46
This construct provides for 64 bits of entropy, of which 32 bits is controlled by each party in a BFD session. For security, each implemention SHOULD randomize their discrimator fields at the start of a session, as discussed in Section 10 [RFC5880].¶
Note that this construct only uses the Your Discriminator field once, to seed ISAAC. It therefore allows the My Discriminator field to change as permitted by BFD [RFC5880] (Section 6.3).¶
While the Your Discriminator field may change, there is no way to signal or negotiate Seed changes. The Seed is set once by each party after the session transitions into the Up state, and then remains unchanged for the duration of the session. The receiving party MUST remember the current Seed value. The Seed value MUST NOT change unless sending party has signalled a BFD state change with a packet that is authenticated using a more computationally intensive authentication method. When a system receives a BFD packet containing Meticulous Keyed ISAAC Authentication, it MUST check that the received Seed contains the expected value, and if not, it MUST discard the packet as inauthentic.¶
A system which sends packets initializes ISAAC as described above. The ISAAC related variables are initialized as follows:¶
When a system receives packets with Meticulous Keyed ISAAC Authentication and is able to authenticate such a packet the first time, the ISAAC related variables are initialized as follows:¶
As there may be packet loss, the receiver has to take special care to initialize the bfd.MetKeyIsaacRcvAuthBase variable. If there has been no packet loss, the bfd.MetKeyIsaacRcvAuthBase is taken directly from the bfd.RcvAuthSeq variable, and the bfd.MetKeyIsaacRcvAuthIndex is set to zero.¶
If, however, the packet's Sequence Number differs from the expected value, then the difference "N" indicates how many packets were lost. The receiver then can use this difference to index into the ISAAC page to find the corresponding Auth Key. If the key in the ISAAC page does not match the corresponding Auth Key in the packets, the packet fails validation, and is discarded.¶
If a key found by indexing into this ISAAC page does match the Auth Key in the packet, then the bfd.MetKeyIsaacRcvAuthIndex field is initialized to this value. The bfd.MetKeyIsaacRcvAuthBase field is then initialized to contain the value of bfd.RcvAuthSeq, minus the value of bfd.MetKeyIsaacRcvAuthIndex. This process allows the pseudo-random stream to be re-synchronized in the event of lost packets.¶
That is, the value for bfd.MetKeyIsaacRcvAuthBase is the Sequence Number for first Auth Key used in this session. This value may be from a lost packet, but can never the less be calculated by the receiver from a later packet.¶
Once the variables have been initialized, ISAAC will be able to produce 256 random numbers to use as Auth Keys, at near-zero cost. The AuthIndex field is incremented 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.¶
When all 256 numbers are consumed the AuthIndex field will wrap to zero. The ISAAC mixing function is then run, which then results in another set of 256 random numbers. The AuthBase variable is then incremented by 256, to indicate that 256 Auth Keys have been consumed. This process then continues until a BFD state change.¶
ISAAC can be thought of here as producing an infinite stream of numbers, based on a secret key, where the numbers are produced in "pages" of 256 32-bit values. This property of ISAAC allows for essentially zero-cost "seeking" within a page. The expensive operation of mixing is performed only once per 256 packets, which means that most BFD packet exchanges can be fast and efficient.¶
The receiving party can then look at the Sequence Number to determine which particular PRNG value is being used in the packet. By subtracting the bfd.MetKeyIsaacAuthBase from the Sequence Number (with possible wrapping), an expected Index can be derived, and a corresponding Auth Key found. This process thus permits the two parties to synchronize if/when a packet or packets are lost.¶
Incrementing the Sequence Number for every packet also prevents the re-use of any individual pseudo-random number which was derived from ISAAC.¶
The Sequence Number can increment without bounds, though it can wrap once it reaches the limit of the 32-bit counter field. ISAAC has a cycle length of 2^8287, so there is no issue with using more than 2^32 values from it.¶
The result of the above operation is an infinite series of numbers which are unguessable, and which can be used to authenticate the sending party.¶
Each system sending BFD packets chooses its own seed, and generates its own sequence of pseudo-random numbers using ISAAC, and place those values into the Auth Key field. Each system receiving BFD packets runs a separate pseudo-random number generator, and verifies that the received packets contain the expected Auth Key.¶
Once all 256 Auth Keys from the current page have been used, the next page is calculated by calling the isaac() function. This function modifies the current page to create the next page, and is inherently destructive. In order to prevent issues, care should be taken to perform this process correctly.¶
It is RECOMMENDED that implementations keep both a current page, and a next page associated with the ISAAC state. The next can be calculated by making a copy of the current page, and then calling the isaac() function.¶
The system needs to maintain the current page at all times when Meticulous Keyed ISAAC Authentication is used. The next page does not need to be maintained at all times, and can be calculated on demand. However, in order to avoid impacting the fast path, the next page should be calculated in the background in an asynchronous manner.¶
This process has a number of benefits. First, At 60 packets per second, the system has approximately four (4) seconds of time to calculate the next page. If the calculation is done quickly, the next page is available to the fast path before it is needed.¶
Second, having the next page available early means that an attacker cannot spoof BFD packets, and force the received to spend significant resources calculating a next page on the BFD fast path. Instead, the receiver can simply check the contents of the next page at near-zero cost, and discard the spoofed packet.¶
When the receiver determines that it needs to move to the next page, it can simply swap the current and next pages (updating the BFD variables as appropriate), and then begin an asynchronous calculation of the next page. Such asynchronous calculations are preferable to calculating the next page in the BFD fast path.¶
This document does not make provisions for dealing with the case of losing more than 512 packets. Implementors MUST limit the value of Detect Multi to a small enough number in order to keep the number of lost packets within an acceptable limit.¶
In a keyed algorithm, the key is shared between the two systems. Distribution of this key to all the systems at the same time can be quite a cumbersome task. BFD sessions running a fast rate may require these keys to be refreshed often, which poses a further challenge.¶
While the Auth Key ID field provides for the provisioning of multiple keys simultaneously, there is no way within the BFD protocol for each party to signal which set of Key IDs are supported. Any such signalling or negotiation needs to be done "out of band" for BFD, and usually via manual administrator configuration.¶
The seeding mechanism for ISAAC, covered in Section 10, is carried out only once for a BFD session. In order to rotate keys, it is REQUIRED to administratively disable the BFD session as part of changing the keys. This permits the new session to be seeded as part of bringing up the new session.¶
There are two ways to transition away from using ISAAC. One way is via state changes: the link either goes down due to an fault, or one party signals a state change via a packet signed with a more computationally instensive authentication. The second situation is where one party wishes to temporarily signal via a more computationally intensive method that it is still Up, by setting the Optimized Authentication Mode field away from value 2 to value 1.¶
The more computationally intensive authentication type provides for full packet integrity checks, which serves as a stronger indication that the session is Up, and that both parties are fully synchronized. This switch can be done at any time during a session.¶
It is RECOMMENDED that implementations periodically switch to the more computationally intensive authentication type for packets which maintain the session in an Up state. The interval between these switches SHOULD be long enough that the system still gains significant benefit from using Meticulous Keyed ISAAC Authentication. See [I-D.ietf-bfd-optimizing-authentication] for appropriate procedure on 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 will continue meticulously increasing. In order to permit transition back to ISAAC as the less computationally intensive authentication mechanism, it is necessary for ISAAC to continue to generate pages appropriate for validating the received sequence number.¶
[I-D.ietf-bfd-optimizing-authentication] describes the procedures that require the switch to the more computationally intensive authentication mode - particularly BFD Poll Sequences.¶
This YANG module adds two identities defined in this document to the IETF Keychain Model [RFC8177]. One of them uses the Meticulous Keyed MD5 as the more computationally intensive authentication and Meticulous Keyed ISAAC Keyed as the less computationally intensive authentication. The other uses the Meticulous Keyed SHA-1 as the more computationally intensive authentication and Meticulous Keyed ISAAC Keyed as the less computationally intensive authentication.¶
<CODE BEGINS> file "ietf-bfd-met-keyed-isaac@2025-10-08.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 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) 2025 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 XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.";
revision "2025-10-08" {
description
"Initial Version.";
reference
"RFC XXXX: Meticulous Keyed ISAAC for 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 Keyed as the
less computationally intensive authentication.";
reference
"RFC XXXX: Meticulous Keyed ISAAC for 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 Keyed as
the less computationally intensive authentication.";
reference
"RFC XXXX: Meticulous Keyed ISAAC for BFD Optimized
Authentication.";
}
}
<CODE ENDS>¶
This documents requests the assignment of two BFD Auth Types, one URI and one YANG model.¶
This document requests an update to the registry titled "BFD Authentication Types". IANA is requested to assign two new BFD AuthType:¶
This document registers one URIs in the "ns" subregistry of the "IETF XML" registry [RFC3688]. Following the format in [RFC3688], the following registration is requested:¶
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.¶
This document registers one YANG modules in the "YANG Module Names" registry [RFC6020]. Following the format in [RFC6020], the following registrations are requested:¶
name: ietf-bfd-met-keyed-isaac namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac prefix: bfd-mki reference: RFC XXXX¶
All security considerations of [RFC5880] and [I-D.ietf-bfd-optimizing-authentication] apply to this document.¶
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 mitigated through the use of 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 serve as a nonce that inhibits attackers from performing an off-line brute-force dictionary attack to discover the key.¶
The security of this proposal depends strongly on ISAAC. Research shows that there are few other CSRNGs which are as simple and as fast as ISAAC. For example, many other generators are based on AES, which may perform worse than ISAAC on resource constrained systems without hardware acceleration.¶
Meticulously Keyed ISAAC authentication protects vs. the spoofing of BFD Up packets and keeping the BFD session Up when it would otherwise be reset.¶
In the event that Meticulously Keyed ISAAC, which is operating as the less computationally intensive authentication mechanism for Optimized BFD, is subverted, the periodic more computationally reauthentication mechanism will limit the time that the session is kept inappropriately in the Up state. (Section 5 of [I-D.ietf-bfd-optimizing-authentication])¶
The Meticulous Keyed ISAAC Authentication method allows the BFD end-points to detect a malicious packet via a number of different methods. Packets which are malformed are discarded. Packets which do not pass the BFD state machine [RFC5880] (Section 6.2) checks are discarded. Packets which 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 ensures that each Sequence Number has a corresponding Auth Key associated with it. The structure and design of the ISAAC CSPRNG ensures 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. If the Secret Key is long and complex, the search space to guess the Secret Key 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 further makes off-line dictionary attacks impractical.¶
The cryptographic strength of the Auth-Type methods is significantly different between SHA-1 and ISAAC. While ISAAC has had cryptanalysis, and has not been shown to be broken, that analysis is limited. The question then is whether or not it is safe to use the same key for both Auth Type methods (SHA1 and ISAAC), or should we require different keys for each method?¶
If we recommend different keys, then it is possible for the two keys to be configured differently on each side of a BFD link. For example, a correctly configured key could allow to the BFD state machine to advance to Up. Then when the session switches to using to weaker Auth Type with a different key, that key may not match, and the session would immediately drop. Suggesting instead that the keys be identical means that no such misconfiguration is possible.¶
Implementations are therefore free to use the same key, or different keys. The use of the same key for for both more and less computationally intensive authentication is acceptable, as ISAAC is keyed not only with the authentication key, but also depends on 32 bits of random data, along with 32 bits of a Sequence Number. The use of this added randomness increases the difficulty of breaking the key.¶
This section is modeled after the template described in Section 3.7 of [I-D.ietf-netmod-rfc8407bis].¶
The "ietf-bfd-met-keyed-isaac" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH [RFC4252] TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication.¶
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
The YANG module defines a set of identities. These identities are intended to be reused by other YANG modules. The module by itself does not expose any data nodes that are writable, data nodes that contain read-only state, or RPCs. As such, there are no additional security issues related to the YANG module that need to be considered.¶
The authors of this document want to acknowledge Ankur Saxena and Reshad Rahman as contributors to this document.¶
The authors want to thank Ketan Talaulikar for his reviews and suggestions that have improved the document.¶