Summary

  • RFC 9986 produces authentication values in ISAAC pages of 256. Generating the next page is irreversible and destroys the current one.
  • A receiver that must cross that boundary while checking a packet is required to save its complete ISAAC state first. A match commits the new state; a mismatch restores the checkpoint.
  • The mechanism authenticates an already-Up sender's continuity signal, not the full packet contents or an end-to-end service. A useful operating receipt proves both the successful commit path and the failed-check restoration path without exposing secrets.

The packet that could move the verifier before passing

A BFD receiver sees a packet with a plausible sequence number ahead of the last one it accepted. The gap may be ordinary loss: control packets are frequent, and the network is allowed to drop some. To decide, the receiver has to derive the authentication value that belongs to that future position.

Most of the time, the lookup is cheap. RFC 9986 uses ISAAC to make pseudorandom outputs available in pages of 256 values. Within the current page, the receiver can seek by index. Once the requested sequence lies beyond it, however, ISAAC runs its mixing operation to produce another page. That operation is one-way. The current page is destroyed.

This creates a rare but fundamental hazard. The packet has not yet proved itself. If the receiver advances its only generator state merely to test the candidate and the authentication value then fails, the verifier may have consumed its own legitimate past on behalf of a hostile or damaged input. It cannot simply say no and continue from where it stood.

RFC 9986's answer is precise: before a calculation that would create a new page, the receiver must save a copy of the entire ISAAC state. It derives the candidate output against the copyable boundary. If the value matches, the saved state can be discarded and the new page becomes current. If the value does not match, the saved state is restored; the modified candidate is discarded or retained separately for possible later use.

The check is reversible until trust has been earned.

Loss tolerance is a bounded permission to look ahead

The receiver needs this design because the next packet received need not be the next packet sent. RFC 9986 couples every packet to a meticulously increasing 32-bit sequence number. When packets go missing, the difference between the received number and the expected number tells the receiver which ISAAC entry to test.

That permission has a fence. Once a receive sequence is known, an incoming number must lie between the last accepted value plus one and that value plus three times Detect Mult, in circular 32-bit arithmetic. Outside the range, the packet is discarded. Inside it, the receiver may seek to the corresponding pseudorandom value and, on a match, resynchronise after loss.

The window matters twice. It limits replay or speculative jumps, and it determines when an otherwise permitted look-ahead may cross a page boundary. A production trace that records only “authentication failed” loses both facts. It should retain the previous accepted sequence, received sequence, Detect Mult, derived window, page base and index, and whether the calculation required a mix.

It should not retain the secret key or raw generator state. The safe receipt uses a non-reconstructable checkpoint identifier or digest, timing and outcome. For a successful cross-page packet, the record should show checkpoint-before-mix, matching output and commit to the new base. For a failed packet, it should show checkpoint-before-mix, mismatch and restoration to exactly the prior state identifier.

Authentic sender, unauthenticated contents

The distinction around the packet is just as narrow. Meticulous Keyed ISAAC uses a shared secret, a per-session Seed and BFD discriminator material to produce the stream. A packet carries a key ID, sequence number, Seed and 32-bit ISAAC output. A receiver rejects the wrong authentication type, mode, length, key ID, sequence range, Seed or output.

But the ISAAC output does not contain a hash or summary of the BFD Control packet. RFC 9986 states plainly that the packet itself is completely unauthenticated. A correct value establishes that only the authentic sending party could have produced this continuity signal. It does not establish integrity for every field.

That is why the inexpensive format can be used only after a session is already Up, and cannot signal a state change. Moving into Up, changing state and periodic stronger reassurance use the more computationally intensive mode with a full-packet integrity check. Existing production coverage already examines that cheap-continuity-versus-change-authority boundary in RFC 9985. The separate fact here is what happens inside the RFC 9986 verifier when even a permitted continuity check would mutate one-way state.

BFD also has a limited observation surface. An authenticated Up continuity signal does not prove that an application works, a route is correct, a customer can reach a service or a particular payload traverses an end-to-end path. It answers a defined adjacency/session question. Treating it as a universal health receipt would turn a fast local mechanism into a false global promise.

An experimental compromise that names its limits

Ashesh Mishra is one of five RFC 9986 authors, alongside Alan DeKok, Mahesh Jethanandani, Sonal Agarwal and Jeffrey Haas. Mishra also appears on the 2017 predecessor draft, RFC 9985 and an earlier BFD integrity-check patent. That record connects him to the engineering problem; it does not make the mechanism a solitary invention.

The document is an Experimental IETF RFC, not an Internet Standard. Its security section is unusually direct about the bargain. ISAAC was selected for systems without useful cryptographic hardware acceleration. Its cryptanalysis is limited; where suitable acceleration exists it offers no advantage, and the RFC calls it unsuitable for use in other IETF protocols.

Operations inherit the same boundedness. Secret distribution is outside the specification. The session cannot switch the Meticulous Keyed ISAAC Auth Key ID in place because there is no defined resynchronisation path. Key rotation requires disabling and reseeding the session. Using distinct keys for strong and inexpensive modes reduces one exposure while creating another: a mismatch can let strong authentication bring the session up and then make it fail as soon as the cheaper mode begins.

These are not footnotes to be averaged away. They identify the decisions that remain with implementers and operators after the common wire mechanism ends.

A receipt for a check that leaves no secret behind

The most revealing conformance test is not a normal in-page success. It is an invalid packet aimed just across a page boundary. Before the test, fingerprint the receiver's non-public state inside the harness. Inject a sequence that lies within the permitted loss window but carries a wrong Auth Key. Verify that a checkpoint exists before mixing begins, the candidate fails, and the old fingerprint returns unchanged. Then send the legitimate packet and prove it is still accepted.

Repeat with invalid Seed, key ID, mode and length; with gaps inside and outside the sequence window; and at wraparound. Measure checkpoint allocation, mixing, restoration and steady-state lookup time. A burst of invalid future packets should not create unbounded memory, CPU work or retained candidate states. Periodically exercise the stronger full-packet mode and rehearse the session restart required for key rotation.

The public operational record contains build identity, session and ticket identifiers, non-secret key ID, sequence window, page base/index, opaque checkpoint fingerprint, timing, result and commit-or-restore disposition. Raw ISAAC state and keys stay out. An evidence system that publishes the material needed to forge its next answer would defeat its own purpose.

The smallest authority belongs to the check

Heng Lu's agency test maps cleanly onto this mechanism. The authors specify an interoperable invariant. The implementer chooses how a complete state copy is represented and protected. The operator chooses keys, stronger-authentication cadence and restart timing. The peer's running code decides whether one candidate matches. None of those actors can honestly promise the outcome controlled by another.

The RFC is also a minimum specification in the useful sense. It mandates save-before-destroy and restore-on-failure without pretending to standardise every memory layout, cache policy or operating procedure. Local decisions remain local, but they are bounded by an invariant that another implementation can test.

Running code closes the final gap. A requirement written as MUST does not prove that one vendor's rare page-crossing error path really restores state. Fault injection, before-and-after fingerprints and acceptance of the next legitimate packet do. The standard describes the branch; the execution supplies the receipt.

The lesson is narrower than a slogan about transactions. A verifier should not gain irreversible control over legitimate state merely because an untrusted input asked a question about the future. Preserve the past, test the candidate, and advance only after the answer earns it.

Sources