Simplifying SNMPv3

Version 3's shortcomings haven't stopped some key vendors from supporting the protocol in their products. All the major router and switch vendors have supported it for several years. Cisco, for instance, has had full SNMPv3 support since IOS 12.0. On the management platform side, Aprisma's Spectrum, BMC Software's Patrol, Computer Associates' Unicenter, Hewlett-Packard's OpenView, IBM's Tivoli and Smarts' InCharge all support v3. Even Castle Rock Computing's SNMPc and MG-Soft's MIB Browser include SNMPv3 support. These management packages store a user ID and password in their database so they can securely communicate with, and manage, an SNMPv3-capable device. SNMPv3 is slowly catching on with cable broadband providers, too; Cox Cable and Time Warner, for instance, use SNMPv3 for securely managing their cable modem networks, and they've expanded on the spec with stronger encryption.

Entities and Engines

SNMPv3 has incorporated and extended earlier versions of the protocol so you can add new functions as modules without having to rewrite the protocol altogether. So if a new access model were developed for v3, for example, it would replace the existing one without affecting the rest of the protocol.

That's good news for network managers, because it means your existing SNMP software won't require a complete rewrite, and your new v3 software will work with previous versions. Although SNMPv1 and v2 rely on plain-text community strings and can't use v3 authentication and encryption, for example, you can still manage your v1 and v2 devices with v3. And vendors will be able to reuse code and upgrade functionality without overhauling their management software.

SNMPv3 doesn't use the traditional SNMP terms agent and manager. Devices and management components are entities in SNMPv3 parlance. One entity (formerly known as the agent) sits on a router, and the other entity (formerly known as the manager) handles application polling. The names may have changed, but the functions have not. Each entity has an SNMP engine and application (see "Start Your Engine,"). The SNMP engine has four functions--access control, security, message processor and dispatcher. Both the message processor and dispatcher modules come with SNMPv1 and v2 functions, such as processing sets and gets and formatting the SNMP data units, or PDUs (protocol data units).

Here's how the SNMPv3 engine works: The dispatcher is the gatekeeper for SNMPv3, and all message I/O goes through it. When an SNMP message is processed, the dispatcher determines the SNMP version of the message and sends it on to the message-processor module for parsing. If the dispatcher can't determine the version due to a malformed or illegal packet, for instance, it logs an error.

The message processor passes the message to the security subsystem or to the access-control subsystem, and then back to the dispatcher, which hands the message off to the SNMP applications. These applications are not conventional transaction-processing or database-query applications, for instance, but merely functions for initiating or responding to SNMP requests. Network-management applications issue command-generator applications to get information from routers, switches and hosts.

The command-responder application is the reverse side of the generator: It resides on routers, switches and host and responds to a get command, for instance. The notification originator and receiver applications send and receive traps and the proxy forwarder moves SNMP messages between management and managed entities when direct SNMP support isn't available.

SNMPv3's security features are its main attraction. Version 3 follows the User-Based Security Model (USM) RFC3414, for authentication and privacy. But any future authentication and privacy modules that emerge could be added to the specification without changing the basic SNMPv3 framework.

SNMPv3 wasn't meant to plug every security hole in a network: Stopping denial-of-service attacks, for example, is not part of the v3 specification. And SNMPv3 was designed to be self-contained so it doesn't rely on other network services, like NTP or key management. It's all about securing the management protocol rather than the management environment or network.

USM consists of authentication, timeliness and privacy modules. Authentication and privacy provide data integrity, authenticity and confidentiality. The timeliness module synchronizes clock values between SNMP entities to thwart replay attacks--it blocks packets with old clocks.

With USM's key management, a user password is converted into a key that is unique to each SNMP entity, so if a key is exposed or captured, only the single device matched to that key is at risk. USM uses the MD5 algorithm, but SHA or other hashing algorithms also work with SNMPv3. As a precaution, the password is not sent over the wire. Rather, the PDU is hashed twice using two keys derived from the secret key, and then the first 12 octets are used as the Message Authentication Code (MAC), which is added to the message. This same process occurs in reverse on the other end. This cumbersome key management may soon be replaced with the more straightforward Diffie-Hillman key-exchange method.

SNMPv3 specifies three levels of authentication and privacy: The first level is simply no privacy, or "noAuthnoPriv." This is similar to SNMPv1 and v2 clear-text community strings, and makes the most sense when you are debugging or the SNMP network entities are in a trusted environment. The second level is authentication without privacy, or "authNoPriv." Many management vendors say their customers opt for this simpler level of security when they first implement SNMPv3. The third level, "authPriv," not only authenticates but also encrypts the SNMP data, but many vendors and enterprises consider that too much overhead for network devices.

Meanwhile, the popular DES encryption algorithm used in v3 actually does not provide acceptable privacy protection. Other algorithms with stronger privacy are in the works, including CBC-AES-128.

SNMPv3 also comes with a view-based access-control model (VACM), which lets you limit access to MIB variables. VACM defines which portion of the MIB is accessible and links users to that view. VACM mechanisms require that a view and group are created on each network device, where the view defines which portion of the MIB is accessible and the group links users to that view.

Early adopters of SNMPv3, such as broadband cable providers, are working around SNMPv3's shortcomings. The cable industry developed the Data Over Cable Service Interface Specification, for example, and providers use Diffie-Hillman or Kerberos to manage their key exchange rather than the bulky USM. They are also using a stronger method of encryption, AES-128, rather than DES.

Bruce Boardman is executive editor of Network Computing, testing and writing about network management and systems. Write to him at [email protected]. Post a comment or question on this story at www.nwc.com/go/ask.html. You can't set up SNMPv3 security using SNMP, so how do you get started? We ran through basic version 3 configuration on some devices in Network Computing's Real-World Labs®at Syracuse University, and found that configuring more than two devices for SNMPv3 was way too much work and prone to errors. Although devices like routers and switches have the SNMP hooks to support USM authentication and encryption and VACM access control, the management applications still have to be configured manually.

First you create a "view" of the network, which is defined in SNMPv3 VACM. The specification can generally be the ASN.1 notation (1.3.6.2.4) or the name of the SNMP MIB branch, like system or Internet. Then you need to define a group, where the users are matched to their approved security level, noAuthnoPriv, authNoPriv or authPriv.

On a single switch, we created a view named "ALLMIB" with a scope of the Internet or OID 1.3.6.1, which is at the root of MIB II and all private MIBs. Next we created a group named "READALL." This group used MD5 authentication and DES encryption for authPriv security. We linked the ALLMIB to the READALL group's view.

We then created a view named "SYSTEM," and another group called "WRITE" (and gave it write access). We linked WRITE to the SYSTEM view, with authPriv as its security level. Members of this group could access only the system or OID 1.3.6.1.2.1.1 section of the MIB, but could read and write values.

Then we created two users, placing each into one of the two groups created on the switch--USERREAD went to READALL and USERWRITE to WRITE. We repeated the same process creating views, groups and users on a different switch. (We copied the configuration to the switch because they were both Cisco Catalyst 2900s, but that won't work with different brands of switches).

At that point, just the two network devices were configured with SNMPv3 security. Next, we needed to configure the management application to use the same security parameters. So for the two switches configured above, we created two users with the same security levels and same user IDs and passwords. We only needed two user IDs and passwords on our SNMPv3 management station.

Now we were able to access both switches with SNMPv3 security. When we attempted to change the system contact, which resides within the system portion of the MIB as USERREAD, we could not. And when we attempted to read interface counters as USERWRITE, we could not do that either. So version 3 security worked.

But even with just the two switches we manually configured in the lab, it was obvious that implementing SNMPv3 across an entire network would be too labor-intensive.