skip to content

How do SNMPv3's snmpEngineBoots, snmpEngineTime and 150-second time window reject replayed messages, and which replays do they still let through?

level: seniorimportance: should knowfreq 15%

answer

  1. the authoritative engine owns the clock
  2. boots survive a power cycle
  3. two Reports during discovery
  4. plus or minus 150 seconds
  5. a window, not a nonce

basics

~20 s

Each authenticated SNMPv3 message carries the authoritative engine's snmpEngineBoots and snmpEngineTime under the HMAC. A message with stale boots, or time more than 150 seconds off, is rejected - but a copy replayed inside that window is still accepted.

solid answer

~40 s

One engine in each exchange is **authoritative** - the agent for Get and Set, the sender for a Trap, the manager for an Inform - and it keeps `snmpEngineBoots` (reboots, held in non-volatile storage) and `snmpEngineTime` (seconds since). Every authenticated message carries both, protected by the HMAC. The authoritative receiver rejects a message whose boots differ from its own or whose time is more than 150 seconds off, counts it in `usmStatsNotInTimeWindows`, and answers with an authenticated Report carrying its current values so a legitimate manager can resynchronise. Managers learn these values by discovery, not from a wall clock. The limits are explicit in RFC 3414: a message stays valid for about 150 seconds and can be replayed during that time, reordering and deletion are not detected, and `snmpSetSerialNo` exists to guard repeated Sets.

go deeper

for a junior

Recall that SNMPv3 rejects authenticated messages that are too old, using a reboot counter, a seconds counter and a 150-second window.

for a middle

Explain who is authoritative for each message type, the two-step discovery, and why the check runs only after the HMAC verifies.

for a senior

Show the production view: the one failed poll after a reboot, a latched boots counter, and the replays the window still allows and what guards Sets against them.

for a principal

Judge whether a 150-second replay exposure is acceptable for write access in your estate, or whether Set operations need extra controls such as snmpSetSerialNo or a different transport.

## The clock USM uses USM (RFC 3414) does not use wall-clock time. Each SNMP engine keeps three values: - **`snmpEngineID`** - unique within the administrative domain; - **`snmpEngineBoots`** - how many times the engine has rebooted since its engine ID was configured, kept in **non-volatile storage**; - **`snmpEngineTime`** - seconds since `snmpEngineBoots` last incremented. At every reboot the engine reads, increments and stores the boots counter, and resets the time to zero. For a given engine ID the pair (boots, time) therefore only ever moves forward, even on a device with no battery-backed clock. No NTP is involved. ## Who is authoritative RFC 3414 section 1.5.1 makes one engine per exchange the owner of the clock: | Exchange | Authoritative engine | |---|---| | Get, GetNext, GetBulk, Set and their Response | the agent | | Trap | the sending agent | | Inform and its Response | the receiving manager | The rule is: the receiver of a message that expects a response is authoritative; the sender of one that does not is authoritative. Every authenticated message carries `msgAuthoritativeEngineID`, `msgAuthoritativeEngineBoots` and `msgAuthoritativeEngineTime`, all inside the HMAC. ## The check, in order RFC 3414 section 3.2 processes an authenticated message as follows: 1. **Verify the HMAC** with the user's localized key. Only after this are the time values trusted. 2. **Check timeliness.** At the authoritative engine the message is outside the window if its boots field differs from the local `snmpEngineBoots`, if its time field differs from the local `snmpEngineTime` by more than **plus or minus 150 seconds**, or if the local boots value has latched at 2147483647. 3. **Decrypt** the scoped PDU if privacy was applied. A failure at step 2 increments `usmStatsNotInTimeWindows`, and the error is reported with security level `authNoPriv` - so the Report is itself authenticated and the manager can trust the fresh values it carries. A non-authoritative receiver - a manager receiving a Trap - is more lenient in one direction: it accepts a boots value *higher* than it remembers, because the agent may simply have rebooted, and updates its stored notion. It rejects lower boots, or the same boots with a time more than 150 seconds behind. ## How a manager learns the clock RFC 3414 section 4 defines discovery: 1. The manager sends a `noAuthNoPriv` request with an empty user name, an empty engine ID and no variable bindings. 2. The agent replies with a Report carrying `usmStatsUnknownEngineIDs`; its security parameters reveal the agent's `snmpEngineID`. 3. The manager sends an authenticated request with that engine ID, a valid user name, and boots and time set to zero. 4. The agent replies with a Report carrying `usmStatsNotInTimeWindows` and its current boots and time; the manager stores them and keeps its local copy advancing with its own elapsed seconds. The same Report mechanism rescues the manager after an agent reboot: its next request carries the old boots value, is rejected, and the Report carries the new one. ## What the window does not stop RFC 3414 is candid about the limits: - **Replay inside the window.** An authenticated message "will be valid for a period of time of approximately 150 seconds under normal circumstances, and is subject to replay during this period". - **Reordering.** Messages sent within one window can arrive in any order without detection. - **Deletion or suppression.** Timeliness says nothing about messages that never arrive. What does stop the other replays: - **Replay after a reboot** fails because the boots value no longer matches. - **Replay to another engine** fails because `msgAuthoritativeEngineID` names the intended engine, and that engine's localized key differs anyway. - **A duplicated Response** cannot answer a new request: RFC 3414 requires a sender to use different `msgID` and request-id values for every request it sends within a 150-second window, and an engine MUST drop Responses that match no outstanding request. - **Repeated Sets** can be guarded with `snmpSetSerialNo` (RFC 3418), an advisory lock whose value changes after each successful use. ## Operating it - **Persist boots properly.** If an engine cannot determine its last boots value it must set it to 2147483647, which latches: every authenticated message then fails until the device is reconfigured with a new engine ID or new user secrets. Even at one reboot per second, honest counting takes about 68 years to get there. - **Expect one failed request after an agent reboot**, then recovery once the Report resynchronises the manager; a steady rise in `usmStatsNotInTimeWindows` points at a manager that is not resynchronising. - **The 150 seconds is not a tunable.** RFC 3414 section 2.2.3 fixes the same window for all users.

  • Why does a manager's first authenticated poll fail right after an SNMPv3 agent reboots, and the next one succeed?
    The reboot incremented the agent's `snmpEngineBoots` and reset `snmpEngineTime`, but the manager still sends the old boots value. The agent rejects the request as not in the time window, increments `usmStatsNotInTimeWindows`, and returns an authenticated Report carrying its new boots and time; the manager stores them and its retry passes.
  • Why does SNMPv3's time window work without NTP between manager and agent?
    The clock being checked is the authoritative engine's own boots-and-seconds counter, not wall-clock time. The manager learns it from authenticated messages, advances its copy with its own elapsed time, and only needs to stay within 150 seconds; any drift beyond that is corrected by the next Report.
  • What happens when an SNMPv3 engine's snmpEngineBoots reaches 2147483647?
    It latches there, and every authenticated message to or from that engine fails the timeliness check. RFC 3414 requires manual intervention: reconfigure the engine with a new `snmpEngineID` or new secrets for all its users. An engine that cannot read its stored boots value must set this maximum, which is why the counter belongs in non-volatile storage.

saying these in an interview costs you the question

  • The 150-second window makes every replayed SNMPv3 message fail.
  • The agent and manager must run NTP for SNMPv3 to work.
  • The time window also applies to noAuthNoPriv requests.
  • The manager is always the authoritative engine.
  • Each agent can set its own time window length.
  • A reboot resets snmpEngineBoots to zero.