In retrospect, the OSI nitwits, preaching their mad CMIP sermons, were more comic relief than clear and present danger. Indeed, SNMP's own success was to be its greatest challenge: the multi-year SNMPv2 effort did considerable harm to networking management. The SNMPv2 effort was more damaging than an infinite number of monkeys writing International Standards during a four-year study period.
Before explaining why the SNMPv2 effort was a bad thing, one must acknowledge that it did provide some advancements:
From a design perspective, the faithful SNMP technologist always:The impact of adding network management to managed nodes must be minimal, reflecting a lowest common denominator.
If networking management is viewed as an essential aspect, then it must be universally deployed on the largest possible collection of devices in the network.
When all else fails, network management must continue to function, if at all possible.
The core problem dealt with SNMPv2's notion of a party, which refers to a virtual entity executing within an agent or manager. A party contains information about an entity's:
The first problem is that they were tightly integrated with virtually every aspect of an SNMP entity. This meant that implementation of SNMPv2 required an all-or-nothing approach. One had to implement the whole party infrastructure to get even the simplest functionality. The second problem, which ultimately proved fatal to SNMPv2, was that configuration in the field became problematic: a network configuration tool would have a quadratic number of relationships to configure, which doesn't scale in the field. And, once again, a management application and agent had to be pre-configured before the simplest management task could be attempted.
In early 1995, the SNMPv2 working group ultimately rejected this scheme because it required that different entities share the same parties in an uncoordinated fashion, which could lead to unacceptable side-effects. Instead, the working group introduced the notion of Configuration Models which integrated with, rather than layering on top of, parties. For example, the Simplified Configuration Model introduced a user concept very similar to the one rejected earlier by the working group, but its mapping mechanism was dynamic, so that parties were created and destroyed as needed, thereby eliminating party sharing.
Unfortunately, the resulting specification was simply too complicated. Although it provided a user-based model, it retained all of the party-based baggage, and introduced still more so that things would work right. However, the working group was winding down, and it looked like the new specification would follow in the footsteps of the original SNMPv2, a paper success and a market failure. And then, something rather extraordinary happened.
Waters' approach, the User-based Security Model (USEC), achieved this by making:
First, it must be acknowledged that McCloghrie and Rose, by virtue of their long and heavy involvement in developing SNMP specifications and technology, had tremendous professional investment in the status quo SNMPv2, and yet, they placed the community's interest well ahead of their own by acting as they did.
Second, when these two SNMP authors expressed their public support for USEC, the working group's drafts, all but published as standards for the Internet community, were discredited. Perhaps this indicates the working group's latent displeasure with its work, as no one was particularly happy with the burden imposed by configuration models.
Perhaps it really was no surprise that when USEC was introduced that the previous work on SNMP security was doomed.
Believe it or not, part of the community still wants to follow the insane path of complexity, and suggest that a ``complete and correct'' solution is desirable. That's right, they want to develop an all-inclusive administrative framework to simultaneously support multiple security models, both standardized and privately-defined. Of course, in order to do this one needs a lot more packet formats, dozens of MIB objects, and still more implementation options.
The current attempt at being all things to all people isn't quite as bad as the earlier notion of configuration models, but it's still considerably more complex than the original SNMPv2 party concept. Further, while the approach currently adopts some of the protocol mechanisms of USEC, it does so by integrating it within a considerably larger infrastructure, an infrastructure which simultaneously supports multiple models for a given user, and hence inherits all of the burdens of generalized extensibility for future, unspecified models.
All of the pain and none of the gain, it's OSI all over again. Perhaps this is inevitable, as in the words of Phil Karn: ``One doesn't stay young and agile and un-OSIified forever.'' I hope for the community's sake that this doesn't apply to SNMP!
Bert Wijnen and Shawn Routhier were the first to join the design team. Although they held the motives of the group advocating the complex solution in high regard, Wijnen, Routhier, and the cast of thousands which followed felt that the interests of the community were best served by the minimalist appoach.
Over the course of the next three months, the small group revised the specification, implemented the revisions, tested for interoperability, and then began another set of revisions. Each iteration resulted in clarification, correction, and, often further simplification.
Finally, in January of 1996, the group decided that USEC was consistent with the basic tenets of SNMP's design philosophy: it was simple, yet powerful, providing core competence in strong security for an extremely small cost!
And this brings us to the present.