SNMP - Anything But Simple - Page 2
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 rename 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 SNMPv2 of any variety never 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 in 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.