
One Brick at a Time Although the original SNMP is the foundation of today's enterprise network management systems, it has some shortcomings. First and foremost, SNMP lacks an effective security model--an essential component in any critical network service. Second, SNMP agents suffer from an ironic paradox: Although SNMP allows managers to Get and Set MIB variables from afar, there is no standardized way to manage SNMP agents themselves via SNMP. Other flaws have come to light only after nearly a decade's use: SNMP cannot accurately describe relationships among managed objects, nor can it address an object within an object, perform more efficient Get operations, issue clarified Set operations or handle larger counters to accommodate gigabit technologies.
SNMP also suffers from a different problem. While it effectively provides the plumbing for network management and offers an extremely flexible and extensible MIB language, MIB support has proven to be its greatest weakness. Network management platforms must manage MIB extensions from literally hundreds of vendors--many variables of which are either redundant or at least similar. A handful of MIB standards, including MIB, MIB2, RMON and RMON2, have attempted to standardize common data types, but network management platforms face the Herculean task of correctly interpreting and associating large volumes of device-specific information. SNMPv3 addresses protocol-level improvements over previous SNMP implementations, but the operation of the MIB has changed little.
However, SNMP implementers should not despair. A separate initiative by the DMTF (Desktop Management Task Force) is attempting to standardize and associate these various data types into more useful information through CIM (Common Information Model) as well as DEN (Directory-Enabled Networking) initiatives (see "Hyping the Common Information Model," www.network computing.com/912/912ws1.html).
When the revolutionary SNMP first emerged, it faced a dilemma: how to create an effective network management system using the fewest hardware resources possible. At the time, CPUs and memory were at a premium, especially in the firmware of infrastructure devices. Community strings--passwords encoded in plain text in each packet--granted a modicum of security, but more important, they provided a protocol that was inexpensive to implement in silicon.
Today, plain-text community strings are under an even greater threat. Since packet sniffers and protocol analyzers are inexpensive and readily available to users at large, traffic traveling across the enterprise network must assume it's crossing a potentially hostile environment. Unfortunately, SNMP, which still relies on community strings, can perhaps better be defined as "Security's Not My Problem."
Efforts during the past five years to improve SNMP's security model arrived at an impasse, with competing versions of SNMPv2 (v2* and v2u) vying for approval while a compromise version called v2c omitted security enhancements, defaulting back to community strings. None had a clear advantage. In contrast, the recently proposed SNMPv3 standard promises finally to deliver a vastly overhauled security model and other protocol enhancements. Last winter, SNMPv3 moved from the inner workings of an IETF working group to the level of proposed standard. Unlike the stalemated SNMPv2 effort, SNMPv3 already has drawn a high level of commitment from the network management community, as well as from infrastructure vendors.
|