Bluetooth Mesh IV Update: Preserve Replay Protection Across Long Offline Periods

A returning Mesh node must recover an authenticated network epoch without reusing unsafe sequence state or treating previously accepted traffic as new. Do not repair a long-offline failure by zeroing counters, clearing replay records or copying an IV Index from an unauthenticated advertisement.

Applicability: the historical Bluetooth Mesh Protocol 1.1 document, especially sections 3.9.8, 3.11.5 and 3.11.6, plus Zephyr 4.2.0 implementation evidence. Numerical cases below are hypothetical state fixtures. No network recovery, persistent-store fault injection or interoperability test was executed.

1. Capture the complete local security state

Record the stored IV Index, IV Update state, sequence allocation state, known subnet membership and whether state/time information survived reboot. Record software and settings-backend versions without exporting NetKeys, AppKeys or device keys.

The IV Index is only one part of the decision. A node in IV Update in Progress transmits with the preceding IV Index while accepting the current and preceding values. In Normal Operation it transmits with the current value and still accepts the preceding value under the protocol rules.

For example, stored index 101 with update in progress means transmit index 100. Stored index 101 in Normal Operation means transmit index 101. Logging only “IV=101” hides a material difference.

Section 3.9.8 orders replay protection by source address and IVISeq, which combines the IV Index with the sequence number. Authentication alone cannot distinguish a valid old packet from a new one. Resource exhaustion must not silently disable replay checks.

2. Require authenticated, eligible recovery evidence

Let the stack process Secure Network beacons or Mesh Private beacons through the specified authentication and subnet rules. A member of the primary subnet uses a beacon authenticated with the primary NetKey for recovery; a node that is not a primary-subnet member can use the specified secondary-subnet case.

Do not let a management UI replace this decision with the largest visible integer. A nearby unprovisioned beacon, failed authentication or a beacon from an ineligible subnet does not authorize epoch adoption.

Section 3.11.6 bounds accepted forward recovery to at most current IV Index plus 42. Lower values and larger jumps are not an invitation to overwrite local state manually. A legitimate node beyond the supported recovery boundary needs an authorized provisioning/recovery workflow.

The often-associated long-offline duration is conditional on network evolution. State the actual index gap and key compatibility; do not promise that any device left in a cupboard for a particular number of months will automatically rejoin.

3. Apply the state-specific transition table

After authentication, subnet eligibility and recovery-observation guards, use the table in section 3.11.6. The following examples assume local current index 100 and otherwise eligible evidence.

The reset belongs to the accepted protocol transition, not an application shortcut. A blanket “reset sequence whenever a beacon arrives” violates the first row and destroys the distinction between old and new transmit contexts.

The procedure also restricts repeated recovery, including a 192-hour guard and explicit handling when elapsed time cannot be determined. Preserve that uncertainty and use the selected stack’s procedure; do not manufacture elapsed time to force a transition.

4. Keep ordinary IV Update distinct from recovery

Ordinary IV Update has Normal and In-Progress timing rules. The historical specification requires a minimum 96-hour phase interval in the described normal transitions and limits how frequently an update starts. Transitioning back to Normal changes which index is used for transmission and resets sequence numbers.

Outstanding segmented transfers can defer the change back to Normal until acknowledgment or delivery timeout. A UI should therefore expose pending transition state rather than repeatedly forcing the update because the flag has not changed immediately.

Zephyr 4.2.0 bt_mesh_net_iv_update rejects out-of-bound indices, handles recovery separately, enforces its recovery guard and defers the Normal transition while a transfer is active. Recovery clears the replay list through the stack and resets sequence state; ordinary update entry uses a different replay-list reset path.

These are coordinated internal transitions. They do not justify independently calling a replay-list clear operation to make a blocked application message pass. The tagged replay implementation tracks source, sequence and old/current IV context and schedules persistence according to configuration.

5. Audit persistence before testing long absence

In the tagged network source, IV settings include index, update flag and duration. Sequence restoration uses CONFIG_BT_MESH_SEQ_STORE_RATE to advance the restored allocation boundary when configured. Copying a saved integer back into live state would bypass that implementation logic.

Qualify the actual settings backend, save scheduling and reset behavior. A power cut between accepted traffic and a deferred settings write is a separate failure from missing months of beacons. Record both local outbound nonce safety and inbound replay protection outcomes.

Do not restore an old device backup into a live network as a casual test. Use isolated lab identities and an approved restoration procedure so duplicated addresses and rolled-back security state cannot affect production nodes.

6. Build a long-offline interoperability matrix

• Normal 100 receives authenticated 101/1: verify state and transmit-index behavior without an inappropriate sequence reset.
• Normal 100 receives 101/0: verify the recovery path and sequence transition.
• Exercise gaps of 42 and 43: verify the boundary, not a calendar-age guess.
• Supply failed-authentication and ineligible-subnet evidence: verify no adoption.
• Attempt repeated recovery inside the known guard interval, then test reboot with uncertain elapsed time under the documented rules.
• Interrupt persistence and repeat an already accepted lab message: verify the declared replay-protection behavior.
• Keep a segmented transaction pending across a Normal transition request: verify deferral and eventual resolution.

Use a supported local test mode only in controlled qualification. The specification’s IV Update test mode removes the 96-hour limit, not every protocol guard. Acceptance requires an explainable state transition, safe sequence ownership and continued replay rejection after the node returns.