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
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:
The HMAC is calculated by the following procedure:
Privacy Encryption
There are 5 different encryption methods used to encrypt an SNMP packet. These are:
The encryption is performed by the following procedure:
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:
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:
