SNMP v2c and v3: what changes and why it matters

SNMP, the Simple Network Management Protocol, is how most network devices report on themselves. Routers, switches, firewalls, printers and power supplies have spoken it for decades, which is why nearly every network monitoring system still relies on it. Most of what changed between its versions is about security, and that is the part that matters when you choose how to run it.

How SNMP works

A device runs an SNMP agent. A monitoring system, the manager, asks the agent for values over UDP port 161. Each value has an object identifier (OID), a dotted path in a global tree, and MIB modules give the paths names and meanings. In IF-MIB, for example, ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6) counts the bytes an interface has received.

Managers read with GET and GETNEXT, and change settings with SET. Agents can also speak first: a notification, sent to UDP port 162, reports an event such as a link going down. A trap is sent once and never acknowledged; an inform is acknowledged by the receiver, and resent until it is.

What v2c added to v1

SNMPv1 (RFC 1157) dates from 1990. Community-based SNMPv2, v2c for short (RFC 1901), kept v1's security and improved the protocol (RFC 3416):

• GETBULK fetches many rows of a table in one request, instead of one GETNEXT round trip per value.
• Informs, so important notifications can be confirmed.
• 64-bit counters (RFC 2578). A 32-bit byte counter wraps after about 4.3 GB, which on a 10 Gbit/s link is under four seconds of full traffic. The ifHC… counters are 64-bit and don't have that problem.

What v2c didn't change is the security. A v2c message is authorized by its community string, which travels in clear text in every packet. Anyone who can see the traffic can read the community, and a read-write community lets them change the device.

What v3 changes

SNMPv3 (RFC 3411 to 3418) keeps the protocol operations and replaces the security model.

Users instead of communities. The User-based Security Model (RFC 3414) gives each message a user name and up to two keys:

• an authentication key, which proves the message came from that user and wasn't modified on the way. The original protocols are HMAC-MD5 and HMAC-SHA-1; RFC 7860 adds the SHA-2 family.
• a privacy key, which encrypts the message. RFC 3414 specifies DES; RFC 3826 adds AES-128, and many vendors support longer AES keys as extensions.

These combine into three security levels: noAuthNoPriv, authNoPriv and authPriv. Only authPriv both proves who sent a message and hides what it says.

Protection against replay. Every agent has an engine ID, and counts its restarts and the seconds since the last one. A receiver rejects a message whose timing falls outside a 150-second window, so a captured packet can't be replayed later. Keys are also localized: the same password produces a different key on each engine, so a key taken from one device doesn't open another.

Access by view. The View-based Access Control Model (RFC 3415) limits which parts of the OID tree each user may read or write.

Why it matters, and what it costs

With v2c, the community string is effectively a password sent in clear text, often to every device on the network, and often still set to public. With v3 at authPriv, monitoring traffic is authenticated and encrypted, and each user's access can be limited to the views it needs.

The cost is operational. Every device needs users and keys, which have to be rotated like any other credential. Informs need the receiver's engine ID configured on some devices. Encryption adds work on busy devices. And because some agents react badly to repeated authentication failures, a manager probing many addresses with v3 credentials should back off when a device refuses them.

If you have to keep v2c, keep its risk small:

• use a read-only community that isn't public or private, and no read-write community at all;
• restrict which addresses may query the agent, with an access list on the device;
• keep SNMP traffic on a management network rather than paths shared with users.

How Tracix handles it

Network device monitoring in Tracix polls devices through a collector on your network.

• Versions. Tracix polls with SNMP v2c or SNMPv3. A v3 user authenticates with SHA-256, SHA-512, SHA-1 or MD5 and encrypts with AES-256, AES-192, AES-128 or DES, and its security level follows the passwords you enter: both for authPriv, the auth password alone for authNoPriv, neither for noAuthNoPriv. The trap listener accepts v1 and v2c traps and v2c informs with a community the integration accepts, and v3 traps and informs from its v3 user, so you enter the credentials once.
• Device profiles. Tracix ships 174 device profiles, plus 21 building blocks they share, derived from Kentik's SNMP profiles under the Apache 2.0 license. A device is matched by its sysObjectID, then by its sysDescr; every device gets the base interface and system metrics, and Brain can propose a profile for a device nothing matches.
• OpenTelemetry names. Interface metrics use the OpenTelemetry semantic conventions where they exist, such as hw.network.io and hw.errors. Counters are stored raw, and rates are computed when you query them.
• Topology. LLDP neighbor tables, read over SNMP, draw the links on the topology map.
• Communities in configurations. If you use configuration management, the built-in No default SNMP community rule flags devices still configured with public or private.

SNMP polling and traps covers the setup, and From SNMP traps to problems follows a trap all the way to an incident.