Skip to main content

1.5. Protection against Message Replay, Delay and Redirection

1.5. Protection against Message Replay, Delay and Redirection​

The User-based Security Model provides protection against several types of message-based attacks.

Message Replay​

Threat: An attacker captures a valid authenticated SNMP message and retransmits it at a later time to achieve an unauthorized effect.

Protection Mechanism: USM uses a time-based mechanism to detect and reject replayed messages. Each SNMP engine maintains:

  1. snmpEngineBoots: A counter that increments each time the SNMP engine reinitializes
  2. snmpEngineTime: A counter of seconds since the last engine reboot

These values are included in the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields of authenticated messages. The receiving engine verifies that these values fall within an acceptable time window.

Time Window: Messages are considered authentic if:

|msgAuthoritativeEngineTime - snmpEngineTime| ≤ 150 seconds

And:

msgAuthoritativeEngineBoots = snmpEngineBoots

Messages outside this window are rejected as potential replays.

Message Delay​

Threat: An attacker delays delivery of a valid message to cause it to be processed at an inappropriate time.

Protection Mechanism: The same time window mechanism that protects against replay also protects against significant message delay. Messages delayed by more than 150 seconds will be rejected.

Limitations:

  • Delays within the 150-second window cannot be detected
  • This is considered acceptable for most network management applications
  • Applications requiring stricter timing must implement additional mechanisms

Message Redirection​

Threat: An attacker intercepts a message intended for one SNMP engine and redirects it to a different SNMP engine.

Protection Mechanism: USM includes the msgAuthoritativeEngineID in the authenticated portion of the message. This value identifies the intended recipient engine. A receiving engine will reject messages where:

msgAuthoritativeEngineID ≠ snmpEngineID (of receiving engine)

Additional Protection: The combination of engineID, engineBoots, and engineTime provides strong protection because:

  1. Each engine has a unique snmpEngineID
  2. Keys are localized to specific engines (see Section 2.6)
  3. The authentication digest covers the engineID, making it impossible to modify without detection

Interaction of Protection Mechanisms​

The three values (msgAuthoritativeEngineID, msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime) work together to provide comprehensive protection:

  1. engineID prevents redirection to different engines
  2. engineBoots prevents replay of messages from before the last engine restart
  3. engineTime prevents replay of recent messages and detects significant delays

Limitations and Considerations​

Clock Synchronization​

The time window mechanism requires that:

  • SNMP engines have reasonably accurate clocks
  • Clocks do not drift significantly over time
  • Time synchronization is maintained between communicating engines

Impact of Clock Issues:

  • Fast clock: May cause valid messages to be rejected
  • Slow clock: May allow replayed messages to be accepted
  • Clock reset backwards: Requires incrementing snmpEngineBoots

Time Window Size​

The 150-second window represents a balance between:

  • Security: Smaller window = less opportunity for replay
  • Operational flexibility: Larger window = more tolerance for clock drift and network delays

Rationale for 150 seconds:

  • Accommodates typical network latencies
  • Tolerates moderate clock drift
  • Provides reasonable replay protection for management traffic

Notification Messages​

For notification messages (traps and informs):

  • The authoritative engine is the notification originator
  • The notification receiver must synchronize with the originator's time
  • This is opposite to the command responder model

Discovery and Time Synchronization​

Before secure communication can occur:

  1. The non-authoritative engine must discover the authoritative engine's snmpEngineID
  2. The non-authoritative engine must synchronize its cached time values with the authoritative engine

These processes are described in detail in Section 4 (Discovery) and Section 2.3 (Time Synchronization).

Security Analysis​

The USM time-based replay protection provides:

Strong Protection Against:

  • Exact replay of old messages
  • Redirection to different engines
  • Long-term storage and replay attacks

Limited Protection Against:

  • Replay within the 150-second window
  • Attackers with the ability to manipulate both endpoints' clocks

Not Protected:

  • Real-time message duplication (same message sent twice within the window)
  • Application-layer replay (attacker initiates a legitimate new request with the same content)

These limitations are acceptable for SNMP's intended use cases, where management operations are generally idempotent or where application-layer mechanisms can detect duplicates.

Last updated on