General

SNMP Is Anything But Simple

For years, upgrading SNMP has been Simply Not My Priority, but with the vulnerabilities of version 1 making headlines, it's time to re-examine the proposals for SNMP versions 2 and 3.

by Drew Bird of CrossNodes, an EarthWeb site [March 11, 2002]

The recent vulnerabilities discovered in the Simple Network Management Protocol (SNMP) have had those involved in network management asking two questions:

1) Why was the problem not detected in the past 12 years?

2) Why are we using a product that is 12 years old?

The answer to both questions, if you'll excuse the pun, is anything but simple.

SNMPv1 was introduced in 1989 to provide a mechanism for devices on the network to communicate information about their state to a central system. The central system is referred to as an SNMP manager or more commonly as a Network Management System (NMS). The devices that can communicate with the manager are referred to as SNMP agents. It's a common misconception that SNMP is a network management system, which it is not. SNMP is a protocol, part of the TCP/IP protocol suite, that enables the communication of network management information between devices.

SNMP 101
SNMP operates on a fairly simple structure. A small number of commands can be issued by the manager to the agent, which responds with the information requested. In certain cases, the SNMP manager is able to reconfigure the device it is communicating with by issuing a special command, called a 'set'.

The information that can be retrieved from the agent or set by the manager is defined by a Management Information Base, or MIB. The MIB defines a set of values that can be read or changed by the SNMP manager. To make sure that SNMP remains protocol dependant rather than platform dependant, the International Standards Organization (ISO) controls the creation of MIBs. The ISO issues MIB identifiers (which look something like '1.3.6.1.4.1.311') to organizations that want to create their own MIBs. As long as they stay under the MIB ID they are assigned, they can do anything they like with it.

The devices themselves are also able to communicate with the manager through the use of 'trap' messages. Traps are generated when either a threshold is exceeded on the device, or when a certain condition is met.

Examples of events that might generate a trap message include an interface going down on a router or the the remaining amount of free disk space on a server falling below a specific number. It should be noted that SNMP agents are very simple pieces of software, which makes it possible to install SNMP agent functionality on just about anything from a server to a router to an air conditioning system to a vending machine. Now that's a practical application for technology if ever I have heard of one.

Version soup
As adept as SNMPv1 is at allowing the management of devices on the network, it does so at the expense of one major factor—security. Although there are additional mechanisms that can be used to increase the security of SNMP, the basic measures boil down to something called community strings. When configuring an SNMP agent, the community string (which is a name or combination of characters) is input as part of the configuration information. When a management system wants to communicate with the device, it authenticates using the community string.

There are typically two community strings accommodated by a device, one for reading values and one for writing (setting) values. It's a sound strategy, except for one fact. The community strings are transmitted between manager and agent in plain text, which means that anyone with a packet sniffer and the inclination to do so can discover the community strings. Amusingly, this facet of SNMP causes some in the industry to call it 'Security is Not My Problem.' Hey, who said this industry wasn't fun!

To move SNMP forward a version was needed that offered all of the good points of v1, but that took care of the bad—in other words, the security concerns. The next version of SNMP (called, not surprisingly, SNMPv2) set out to accomplish this goal in 1995. Although security was the major drive behind SNMPv2, it was not the only enhancement. New SNMP commands such as 'GetBulk', were added along with an enhanced MIB language which added a degree of flexibility missing from SNMPv1.

The only problem was that it quickly became apparent that opinions differed as to how to make SNMP more secure. As the wrangling continued, two separate versions, SNMPv2* and SNMPv2u emerged, each touting its advantages over the other. In attempt to move forward with SNMP as a whole, another version, SNMPv2c, was introduced that took the advantages of management over SNMPv1, but reverted back to the old community string authentication methods of the original version. The result of all these shenanigans is that no single variety of SNMPv2 ever managed to get a foothold.

Which brings us up to version 3, which is where we are today. SNMPv3 was introduced in 1999, and gets around the security concerns by making it possible to encrypt all SNMP related traffic. It also accommodates authentication via a digital signature for remote systems.

In other words, the router in Helsinki is able to verify, in a secure manner, that the request to reset Interface 0 originated from the SNMP management system in Orlando. It is also possible to operate SNMPv3 without the authentication or encryption if so desired, though the number of environments that would consciously disable security in this day and age is few.

It should be noted however, that SNMPv3 does not just offer security enhancements. Other features of the new version include auditing, an enhanced time synchronization protocol, and an increased set of management tools. It also incorporates the non-security related enhancements that were included in SNMPv2. To put it simply, SNMPv3 takes the best of version 2, perfects these features, adds a few of its own and then makes it secure. Another major plus for SNMPv3 is that it has been designed in a modular manner that, some say, will make it unnecessary for a new version (v4 per chance) to be introduced in the near future. When the need for new functionality is realized, it can be incorporated into SNMPv3 without the need for wholesale changes.

With all the advantages SNMPv3 offers you might think that everyone who's anyone would be using it, but that's not the case, and it's certainly not for lack of vendor support. All major network hardware vendors including Cisco, Nortel, and Intel provide SNMPv3 support. SNMPv3 support in network management software applications is also widespread and has been for some time.

To go back to the original question posed at the beginning of this article, you may now be asking yourself why everyone is not using SNMPv3. For many, it is a case of "If it's not broken don't fix it." The problem with this strategy is that now, with the security problems identified with SNMPv1, even if your SNMP structure is not broken, someone else is likely to try and break it for you.

—End