Deploying SNMPv3

Deploying SNMPv3 is not difficult, but that’s exactly what vendors want you to think.
SNMPv3 has been an official standard since 1998, so why has its deployment been so slow? Most network monitoring and management vendors rely on legacy SNMP software which has only partially implemented SNMPv3.

SNMPv3 Parameters

The following is a list of parameters you will see when dealing with SNMPv3:

  • Group and Username
  • Context
  • Engine ID
  • Boot Time
  • Boot Count
  • Authentication Type and Passphrase
  • Privacy Type and Passphrase

Group and Username

The group and username are used for access control on the client (e.g. router, switch). Access control allows you to limit the read/write capabilities and MIB views. In a SNMPv3 packet, the username is mandatory.

Context

The context is mostly used as a replacement for SNMPv2 community name addressing. The context is typically used to address individual bridge tables inside a switch. In SNMPv3 the context name is mandatory but is usually empty.

Engine ID

Each SNMP client (eg. router, switch, host, etc) contains a unique SNMP Engine Identifier. This engine ID is used during the authentication phase of SNMPv3. You will see below why it is absolutely imperative that the engine ID is unique. No two devices can have the same engine ID. The Engine ID is automatically generated by the device. Never manually configure the Engine ID.

Engine Boot Count

All SNMPv3 packets contain the engine boot count of the client. The client keeps a count of the number of times its SNMP engine is rebooted. This count is typically stored in non volatile RAM and is therefore not lost after power cycles. The boot count is used as part of the authentication process.

Engine Boot Time

All SNMPv3 packets contain the engine boot time of the client. The boot time is the number of seconds since the client's SNMP engine was started. The engine boot time is constantly increasing in value. This ensures that every SNMP packet is unique, which is important in countering "man in the middle" attacks.

HMAC Authentication

Note: You don't need to actually understand this ;-)

HMAC stands for Hash-based Message Authentication Code. There are two types of digest algorithms used in SNMPv3 to create the HMAC:

  • MD5 (deprecated)
  • SHA (recommended)
A digest reads a block of data and creates a unique fingerprint. MD5 digest is 16 bytes long and SHA is 20 bytes long. The SNMPv3 HMAC is truncated to 12 bytes.

The HMAC is calculated by the following procedure:

  1. The authentication passphrase is passed into the digest algorithm until it reaches a total of one megabyte.
  2. The digest is calculated and stored in a buffer.
  3. The client's engine ID is appended to the buffer.
  4. The buffer is passed into the digest and a new digest is calculated. This is called the Secret Authorisation Key.
  5. From the Secret Authorisation Key, two other keys (K1 and K2) are derived.
  6. The Secret Authorisation Key is extended to 64 octets by appending 48 zero octets and saving it as the Extended Authentication Key.
  7. Create IPAD by replicating the octet 0x36 64 times.
  8. Create K1 by XORing the Extended Authorisation Key with IPAD.
  9. Create OPAD by replicating the octet 0x5C 64 times.
  10. Create K2 by XORing the Extended Authorisation Key with OPAD.
  11. Prepend K1 to the SNMP packet and calculate the digest over it.
  12. Prepend K2 to the result of the step 11 and calculate the digest.
  13. Take the first 12 octets of the final digest and store it in the packet.

Privacy Encryption

There are 5 different encryption methods used to encrypt an SNMP packet. These are:

  1. DES (deprecated)
  2. 3DES (deprecated, extremely slow)
  3. AES-128 (deprecated)
  4. AES-192 (deprecated)
  5. AES-256 (recommended)

The encryption is performed by the following procedure:

  1. The privacy passphrase is passed into the digest algorithm until it reaches a total of one megabyte.
  2. The digest is calculated and stored in a buffer.
  3. The client's engine ID is appended to the buffer.
  4. The buffer is passed into the digest and a new digest is calculated. This is called the Secret Privacy Key.
  5. A salt is created by combining a random number with the client's engine boot count and boot time. The salt is included in the unencrypted portion of the SNMP packet allowing the other end to decrypt the packet.
  6. The packet is then encrypted using one of the above encryption methods.

Clear as mud? Sounds scary, but the code to implement all authentication and encryption combinations can be less than 300 lines.

Note that the username is not used at all during the authentication process. The username is only used for access control on the end device.

How SNMPv3 Authentication Works

When a management application needs to retrieve data from an SNMPv3 client there are two stages that occur:

  1. Engine ID, BootTime and BootCount discovery
  2. Authentication

Initially, the management application does not know what the client's Engine ID, BootTime or BootCount values are, therefore it must go through a discovery process. To do this, the management application sends a SNMP packet to the client with the Engine ID, BootTime, BootCount and HMAC fields set to zero. The intention of this packet is to force a authentication failure on the client, so the client will send back a error packet called a Report. This Report packet will contain the clients Engine ID, BootTime and BootCount.

From this point, the management application needs to keep a table of all discovered Engine IDs and their associated BootTime and BootCount values. Each time the management application sends a packet to a client, it needs to calculate the current BootTime of the client. If the client receives an unexpected BootTime, it will fail authentication and send an error Report response.

For most efficient deployment of SNMPv3, it is best to make sure all devices are configured to use NTP (Network Time Protocol) to keep their real time clocks in sync, otherwise clock drift will cause SNMPv3 BootTime values to drift, which will force unnecessary rediscovery packets.

Once the management application knows the Engine ID, BootCount and BootTime, it will construct a SNMP request packet (eg. Get, Set, GetNext,GetBulk).

Since the client BootTime and encryption salt is constantly changing, the calculated HMAC and encrypted packet are always guaranteed to be different for every SNMPv3 packet, making it more difficult for a man in the middle attack.

Since every device will have different engine BootTime and BootCount values, it is absolutely imperative that NO two devices use the same Engine ID, otherwise the management application will always incorrectly calculate the authentication HMAC or the client will fail authentication because the BootTime is not valid. This will cause every request to go through a rediscovery process.

SNMPv3 Performance

Most modern CPUs contain support for offloading the AES encryption workload to the CPU using builtin assembler instructions, therefore it is best to always configure SNMPv3 for SHA and AES256. Avoid MD5 and DES as much as possible. Triple DES is particularly evil as it significantly impacts the CPU load in the end devices.

From our benchmarking, an Intel Core i3/5/7 CPU can easily handle over 10,000 SHA authenticated and AES256 encrypted SNMPv3 requests/responses per second using a single CPU core and one process (ie. not threaded). In fact, we barely see any performance difference between SNMPv2 and SNMPv3.

Comments

As a rule of thumb, it is best to avoid vendors who:

  • Partially implemented SNMPv3, missing important functionality like SNMPv3 authenticated and encrypted traps.
  • Claim that SNMPv3 will have an impact on your routers and switches.
  • Claim that SNMPv3 requires significantly more CPU and memory.
  • Claim that SNMPv3 does not scale. It is not the fault of the protocol but their poor implementation.
  • Don't support all versions of AES.
  • Recommend the use of a single common engine ID on all devices.
  • Recommend manually configuring the engine ID.
  • Base their products on Net-SNMP, which is an extremely inefficient implementation.
  • Mix up username with the authentication mode and passphrase.
  • Think that the username is optional.