The Simple Times is an openly-available publication devoted to the promotion of the Simple Network Management Protocol. In each issue, The Simple Times presents: a refereed technical article, an industry comment, and several featured columns. In addition, some issues include brief announcements, summaries of recent publications, and an activities calendar. For information on submissions, see the end of this issue.
The Simple Times is openly-available. You are free to copy, distribute, or cite its contents; however, any use must credit both the contributor and The Simple Times. (Note that any trademarks appearing herein are the property of their respective owners.) Further, this publication is distributed on an "as is" basis, without warranty. Neither the publisher nor any contributor shall have any liability to any person or entity with respect to any liability, loss, or damage caused or alleged to be caused, directly or indirectly, by the information contained in The Simple Times.
The Simple Times is available via both electronic mail and hard copy. For information on subscriptions, see the end of this issue.
In this issue: An Implementation of SNMP Security
In his Security and Protocols column in The Simple Times, Keith McCloghrie discusses SNMP Security. In his first two columns, he briefly explained the new security mechanisms, outlined the protection that these extensions provide, and showed how the mechanisms are integrated into SNMP. In this issue, I report on my implementation of SNMP Security, demonstrating that the process is certainly feasible, and hopefully encouraging further fielding of SNMP Security software.
In keeping with the SNMP tradition of ensuring implementation experience prior to standardization, several implementations of SNMP Security were written while the proposals were Internet-Drafts. Implementation experience is essential to verify the soundness of the technology and to highlight those areas in the specifications which are unclear or perhaps not reasonably implementable. So, I wrote an implementation as a part of my Master's work under Dr. Jeffrey D. Case at the University of Tennessee at Knoxville. The implementation is based on the 4BSD/ISODE SNMP package.
In this article, I briefly discuss modifications made to an SNMP implementation to incorporate the SNMP Security features. Further, we'll examine the cost of realizing these changes, along with improvements made to the specifications during the implementation period. In this way I hope to provide future implementors with modest guidance for implementing SNMP Security in a performant and correct fashion.
The implementation as a whole progressed quickly and without serious difficulty. The largest portion of the time was spent in understanding the software platform and not in the actual coding. The methodology I chose was straightforward: I first altered the wrappers in the SNMP message and then implemented the party concept from the SNMP administrative model. These two changes essentially implemented noAuth/noPriv. I then added the Digest Authentication Protocol, the next logical step, followed finally by the Symmetric Privacy Protocol.
Message::=
SEQUENCE {
version
INTEGER { version-1(0) },
community
OCTET STRING,
data
PDUs
}
This is the sole
wrapper.
SNMP Security's innermost wrapper,
the SnmpMgmtCom
(SNMP management communication)
includes the PDU along with the identities of the source and destination
parties,
but neither a community string nor a version:
SnmpMgmtCom ::=
[1] IMPLICIT SEQUENCE {
dstParty
OBJECT IDENTIFIER,
srcParty
OBJECT IDENTIFIER,
pdu
PDUs
}
The SnmpMgmtCom is in turn wrapped in a
SnmpAuthMsg (SNMP authenticated message),
which contains the authentication information
(AuthInformation,
which is used in an authentication protocol-specific manner),
and the SnmpMgmtCom:
SnmpAuthMsg ::=
[1] IMPLICIT SEQUENCE {
authInfo
AuthInformation,
authData
SnmpMgmtCom
}
Finally,
the SnmpPrivMsg (SNMP private message) contains the identity of
the destination party and a possibly encrypted serialization of the
SnmpAuthMsg:
SnmpPrivMsg ::=
[1] IMPLICIT SEQUENCE {
privDst
OBJECT IDENTIFIER,
privData[1]
IMPLICIT OCTET STRING
}
Thus,
the first major step is to change from one SNMP wrapper to a wrapper inside a
wrapper inside a wrapper.
The additional change to SNMP for noAuth/noPriv is the implementation of the party database. Recall that SNMP Security's administrative model is based upon the notion of an SNMP party, which can be thought of as the identity of a particular protocol entity running at a particular network location and in a particular security context. Of course, a particular protocol entity may operate as any of several parties (for example, one which uses no authentication and no privacy, and one which uses both), but each party uniquely identifies that protocol entity. This specificity contrasts with the community-based model used in the original SNMP, and is necessary in order to uniquely identify the source and destination of a message. An implementation of SNMP Security must of course implement a party database with all the relevant information for that party. There are many possible strategies for implementing the party database, but care should be taken to provide a stable database which is recoverable, i.e., after crashes.
The cost of implementing only noAuth/noPriv in comparison to the original SNMP is apparent. Three wrappers cost more in processing speed, agent complexity, and protocol complexity than a single wrapper. While this is true, each wrapper serves an essential role in SNMP Security. The destination party from the SnmpPrivMsg determines which privacy protocol to use, as this is based upon the destination. The source party in the SnmpMgmtCom determines the authentication protocol. Thus, each of the wrappers is necessary, despite the additional cost. Further, the cost of the party database, which could become quite large, cannot be avoided if SNMP Security is to be used at all.
In order to perform the MD5 message digest procedures, I extracted the appropriate code from the reference C Programming Language implementation in the MD5 specification (RFC 1321). The code integration required little effort. Naturally, optimization of the MD5 code for a particular hardware platform is desirable, if at all possible.
Implementation of the authentication steps required that I first manage loosely synchronized party clocks. Each SNMP party has its own party clock, and any outside parties which communicate with that party must keep their view of that party's clock loosely synchronized with its true value. This is done to protect against message reordering and replay attacks. I chose to maintain the party clock as an offset from the system clock where the agent was running, which eliminated the burden of having to maintain the clock manually.
The initial specification for the granularity of this clock was 100 ticks per second. Additionally, the nonce, essentially a sequence counter within one clock tick, permits (2**32) uniquely identified messages to be sent per clock tick. Since it is unlikely that a party would exchange (2**39) messages per second, the clock granularity was later changed to one tick per second. This still allows for (2**32) messages to be sent per second while avoiding clock roll-over for over 100 years for those basing their clocks on a 32-bit system clock.
Since the correct operation of the MD5 message digest generation depends upon the private authentication key, implementors must take precautions to ensure that the keys with which they are dealing are in fact the required 16 octets. The initial MIB specification did not include this requirement (although it was stated elsewhere and is now in the MIB), and it is wise to take great care in ensuring correctness of the keys, just as with any value which must be of a specified length. This is also true with respect to the length of the private key used for the Symmetric Privacy Protocol.
The cost incurred by the Digest Authentication Protocol lies primarily in the cost of the digest generation code. A message digest over the serialized SnmpAuthMsg must be performed for both incoming and outgoing messages. Each implementor would be well advised to optimize this code as much as possible for the deployment platform.
A possible additional cost is incurred if one chooses to serialize the SnmpAuthMsg twice on outgoing messages. The SnmpAuthMsg is serialized once before the digest is generated with the private authentication key in the authDigest field. The authDigest field is then replaced with the computed digest. If the implementor does not wish to alter the serialized BER stream in place, the SnmpAuthMsg must then be serialized again. (In the initial implementation, I chose the twice-serialized approach. In the current implementation, serialization occurs exactly once.)
One question, which did not arise when working on my implementation, dealt with which portion of the serialized SnmpAuthMsg is to be used for authentication and encryption. Simply put, the entire BER tag/length/value stream should be used.
protocol vars/sec %-of 1157 %-of prev ======== ======== ========= ========= 1157 (SNMP) 60.97 n/a n/a noAuth/noPriv 37.97 62% 62% md5/noPriv 32.13 53% 85% md5/des 15.06 25% 47%Based upon these results, it is apparent that there is a significant loss of speed with even noAuth/noPriv. I attribute this to the additional wrapper processing and the added complexity prior to processing the PDU.
Furthermore, in a given time period, the manager will be able to retrieve approximately 85% as many variables with md5/noPriv as when using noAuth/noPriv. This result confirms earlier estimates and appears to be a reasonable price to pay for authentication.
Finally, as would be expected, the use of the Symmetric Privacy Protocol greatly reduces the speed of variable retrieval. According to these tests, only 47% as many variables can be retrieved in a given time period when using privacy as with md5/noPriv. This drops to 40% when compared to noAuth/noPriv. There can be little doubt that hardware implementations of DES or highly optimized software would speed processing, but the degree of speedup is unknown.
The MD5 implementation I used is taken from RFC 1321, and is hereby identified as ``derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm''.
Welcome to the third issue of The Simple Times.
In this issue, the Industry Comment presents a perspective on SNMP evolution. But first, some subscription information: in his Interoperability column in the June 8th issue of Communications Week, Carl Malamud discussed The Simple Times. In the following two weeks, about 200 more people subscribed for electronic distribution. The interesting part is that by the morning of June 10th, nearly sixty had subscribed -- yes, there are clearly a lot of people who read Communications Week as soon as it hits their mailbox! Thanks to Carl and the usual trickle of subscription requests, there are now over 1000 electronic subscribers (including several re-distribution lists), with nearly 11% receiving the MIME edition.
In March of this year, the Internet Engineering Steering Group (IESG) issued a call for proposals to evolve the Internet-standard Network Management Framework. A fundamental observation made in this call is the understanding that the existing framework provides the foundation for stable and effective network management of the Internet. Further, these management capabilities are used pervasively and continuously. In other words, SNMP is an integral part of the Internet community's installed base.
At present, the Internet-standard Network Management Framework consists of three core technologies: a notation for describing management information (termed the ``Structure of Management Information'' or SMI), a collection of modules which define management information (each termed a ``Management Information Base'' or MIB), and, the management protocol, SNMP. Historically, the balance between stability and extensibility has been achieved by allowing only one kind of change: new MIB modules may be defined and existing ones may be revised.
In one response to the IESG's call, four people developed the Simple Management Protocol (SMP) Framework. The SMP specification and four independent, interoperable implementations are scheduled for release at the beginning of July. (Perhaps before you read this issue of The Simple Times.) When the deadline nears for the IESG's call for proposals, the SMP authors will submit the current revision of the SMP specification for consideration.
Because other proposals may be forthcoming, rather than examining the SMP Framework, the Industry Comment looks at the issues associated with evolving the Internet-standard Network Management Framework.
Historically, it is clear that the SNMP philosophy of shifting the burden of management away from the managed nodes and towards the management stations, has allowed us to tend toward the first two goals. Further, the minimal communications infrastructure required by the SNMP (i.e., a connectionless-mode transport service), has allowed us to achieve the third goal.
A second part of building on the success of the current framework is for an evolutionary scheme to maximize backward-compatibility. That is, for each change under consideration, a careful cost/benefit analysis must be undertaken. Whilst the advantages of a feature are often evident, the impact on the installed base is often hidden. This means that for each change, the following questions must receive intense scrutiny:
Obviously, to be consistent with the philosophy of the current framework, the ideal change is one which has a minimal (or preferably no) impact on agents, and in which the modifications are well-localized.
In brief, when evaluating any evolutionary scheme, independent of its technical details, great attention must be given to the meta-issues of consistency and compatibility with the current framework.
As a part of evaluating RFC 1303, a compiler with an ``agent evaluator'' back-end was built. The algorithm used by the evaluator looks at the RFC 1303 definition of the agent's capabilities, assigns a rating from zero to one-hundred which represents the ``goodness'' of the agent implementation. The algorithm is limited in that it can evaluate the agent implementation only in a generic sense. In the prototype, when the rating is determined, it is displayed to the user and a different audio file is rendered. If the rating is zero, the message might result in:
``You have an excellent agent -- not!''Similarly, a rating of twenty might be several people laughing, whilst a rating of forty might result in:
``Bogus!''and a rating of eighty might result in:
``We can name that tune!''(Of course, this example of the use of RFC 1303 is purposefully humorous.)
However, RFC 1303 is not without its drawbacks: in addition to requiring that implementors and users understand this new notation, management station implementors must build a compiler for the RFC 1303 notation and then instrument their software accordingly. Further, vendors of agent products might resist publication of descriptions of their agent implementations as this might provide marketing-fodder information to their competitors. Another drawback is that RFC 1303 limits its scope to agent implementations and doesn't consider user requirements. That is, the RFC1303 notation describes the capabilities of an agent, but doesn't have a way to describe the capabilities expected of an agent if it is going to operate in a particular user-environment. So, it would seem that we need both a way of specifying compliance issues in addition to agent capabilities. If we had notations for describing both kinds of information, then one could imagine that, in the future, one could write a program which could automatically compare both kinds of specifications in order to give a rough feeling for how well an agent implementation would work in the user's environment.
As Keith McCloghrie has pointed out in his Security and Protocols column (and as David Partain confirmed in his technical article on An Implementation of SNMP Security) security has both benefits and costs. The challenge for implementors is to provide turn-key solutions which hide the details and allow users to get on with the business of managing their networks.
However, one should keep in mind that even though the long-awaited SNMP Security work is largely consistent with the SNMP philosophy, it still needs a small bit of work. For example, SNMP Security, as presently specified, mandates ordered delivery for intra-party traffic. As Keith McCloghrie points out in his column in this issue: ordered delivery is largely unnecessary, and perhaps harmful, for retrieval operations; further, ordered delivery for intra-party traffic is inadequate for coordinating multiple managers performing modification operations. So, one might expect some additional work in this area.
First, SNMP's set-request hasn't seen a great deal of operational use. There are probably two reasons: one is that some vendors have used the lack of SNMP Security as an excuse to avoid implementing the set-request. (This is, of course, specious as most vendors use a TELNET-based mechanism to modify a managed node. In addition to being no more secure than the original SNMP, because TELNET uses TCP, during times of network stress it is less likely to be able to control a device in comparison to using SNMP's set-request.) In addition to the ``security'' issue, when an SNMP set-request fails, very limited diagnostic information is returned. In brief, the management station asks the agent to do something, and the agent says:
``No!''What we really need is a richer collection of diagnostics, so the management station can determine if the failure is permanent or transient in nature, in addition to receiving a coarse indication of the cause. In other words, under any evolutionary scheme, it would be a good idea for the agent to be able to say:
``No, because...''Hopefully, introduction of SNMP Security and a somewhat richer diagnostic set will greatly increase the use of SNMP for modifying the behavior of managed nodes.
A second protocol issue that must be dealt with is the question of bulk retrieval. Historically, this has been one of the areas of greatest mis-understanding. The plain fact is that it is impractical to require an agent to provide an arbitrarily large amount of management information in a single transaction. Hence, a solution must be based on the notion of incremental retrieval. Today, there are several strategies, all of which make use of SNMP's get-next operator. Because of this, each strategy, regardless of how cleverly it makes use of parallelism and pipelining, is limited to retrieving a fixed amount of information in each transaction. This would seem to indicate that we need a new SNMP operator for bulk retrieval, one in which the agent helps to decide how much information is returned in a given transaction. However, great care must go into the design of such a facility, as it must not unduly burden the managed node.
Although there may be many causes for this, the one thing which seems clear is that management information is currently defined strictly on a micro-level. That is, we produce a lot of MIB modules containing a lot of managed objects; but nowhere do we produce documents describing how those objects can be used to provide for effective management. The result is that the majority of management applications are browsers. These browsers, regardless of the GUI, have little management smarts. (Steve Waldbusser discussed this situation in his Applications and Directions column in the previous issue.)
Achieving this task may be nigh impossible: first, the actual details are very often specific to individual environments; and, second, the actual details are also highly technical and (at present) not very amenable to machine-processing. However, figuring out a way of doing this may very well be the most helpful thing of all. The amusing part is that activity is probably outside the scope of any evolutionary scheme!
In this issue: The Truth About SNMP Performance
One of the most frequently repeated concerns about SNMP is that it won't perform well or won't scale up to the large networks of the future. This is often vocalized as ``You shouldn't use SNMP because it isn't efficient enough and will clog the network.'' Unfortunately, such statements have not been supported by technical rationale or by direct user experience, and this has left consumers very confused. There are many large sites using SNMP today to manage networks. These sites have direct experience that should ease the uncertainty in this area.
There are two areas to be addressed separately:
In addition, there are some up and coming advances that will make the situation even better.
Carnegie Mellon University also has a large network, on which SNMP has proven to scale very well. An SNMP monitoring tool monitors more than 200 devices on the Carnegie Mellon network, polling each one once every 15 seconds for status information. This also uses much less than one percent of an ethernet's bandwidth -- so little in fact, that a second computer performs the identical task as a backup. Both computers spend less than 5% of their processing on these SNMP tasks, which shows that high-powered management station hardware is not required.
A barrier to the fast download of data is the discovery of previously unknown instances of data. Before asking for the value of a variable, a management station must know its name. The SNMP get-next operator allows the discovery of the names of such variables, but unless a sophisticated algorithm is used, only one instance may be discovered per packet (such a sophisticated algorithm is described in RFC 1187, Bulk Table Retrieval with the SNMP). The RMON MIB was specifically designed to allow another method of discovering instances of data quickly. However, many other MIBs exist that weren't designed with this in mind. It would be desirable to provide a fast and easy mechanism to download data from any MIB. The newly defined Simple Management Protocol (SMP) provides such a mechanism, called the get-bulk operator. This operator allows the discovery of many variables per packet, speeding the transfer of data and making it more efficient by packing more in every PDU. Initial testing shows that this operator will improve on the blazing speeds cited above, and will also make normal operations more efficient, requiring less network load than the tests mentioned previously.
Dear Dr. SNMP,
I recently read that the new Simple Management Protocol (SMP) will have a mechanism for the efficient retrieval of large amounts of data. Will this new mechanism be the one described in RFC 1187, Bulk Table Retrieval with the SNMP, or will it be the one described in the premiere issue of The Simple Times? Will it be fast and efficient?
P.S. Will Dr. SNMP soon become Dr. SMP?
-- Impatient in Indianapolis
Dear Impatient in Indianapolis,
Back on the farm, we have a saying:
``That thing's faster than a scalded dog.''The answer is yes, it will be fast and efficient. The new bulk retrieval mechanism uses neither of the mechanisms you ask about. Instead, it uses a new operator, called get-bulk, which has been optimized to communicate requests for the transfer of large quantities of data. Responses are communicated via the usual SNMP response mechanism.
Regarding your postscript, SMP really is SNMP. But, the SMP authors couldn't just call it that, because the name ``SNMP'' belongs to the Internet community. The SMP authors tried to be careful to avoid offense by using a different name. (They were perhaps too sensitive.) It is anticipated that, over time, it will be acceptable to call SMP what it really is, SNMP version 2.
Dear Dr. SNMP,
Recently I've been hearing about this new management protocol, X.700, which is supposed to be well-suited for wide-area network (WAN) management. The same people who told me about X.700 also tell me that since SNMP is a protocol for managing local-area networks (LANs), that I need both protocols for network management.
-- Vacillating in Virginia
Dear Vacillating in Virginia,
Back on the farm, we have a saying:
``You can give a doggie bone to a pig but it still won't hunt.''(Dr. SNMP thinks this is right up there with ``A leopard can't change its spots'' and ``A zebra can't change its stripes.'')
What this means is that calling something by a different name won't yield fundamental changes in its characteristics and behavior. Your question brings four important ideas to mind.
First, there are those who are attempting to avoid the excess baggage associated with the name of the OSI management framework, anchored by CMIP. Consequently, they are attempting to use a fresh, new name (X.700), in order to avoid many of the negative connotations and emotions associated with the ``CMIP'' label. Dr. SNMP is somewhat sympathetic toward the notion of using new names for existing protocols. However, the rationale for using ``SMP'' instead of ``SNMP version 2'' is entirely different than the motives used in renaming CMIP to X.700: SMP really is SNMP, with a few problems corrected and a few important enhancements. SMP uses the same basic well-engineered framework enjoyed by SNMP but these minimal changes lead to dramatic results. In contrast, the X.700 framework really is the CMIP framework, albeit without any problems corrected and without any important enhancements. The motivations for the name changes are quite different.
Second, Dr. SNMP is less charitable toward the dis-information campaign that seems to be underway. This dis-information campaign attempts to position SNMP as a LAN management technology. The truth is that while SNMP has become popular as a LAN management technology, the original impetus for the design was the monitoring and control of wide area network components, especially IP routers. SNMP can, has, and will continue to perform this function in many production networks.
Third, the dis-information campaign attempts to position X.700 as a superior WAN management technology. The truth is that the requirements of WAN management are incompatible with the characteristics and performance of connection-oriented transports in the lossy environments frequently encountered in wide area networks. In other words, CMIP is actually better suited for use in LANs than it is for use in WANs.
Finally, the dis-information campaign appears to be too well organized and orchestrated to be an accident. Perhaps the next dis-information you hear will be that you need a different protocol for manager-to-manager communications than is used for manager-to-agent communications.
It is difficult for Dr. SNMP to see how dissimilar communications technologies and techniques will be helpful. Building translators between these frameworks (SNMP and CMIP) is a difficult problem that many have underestimated. The entity models are different. The information models are different. The naming mechanisms are different. The SMIs are different. The protocol operations are different. The transport assumptions are different. Other than that, they both have managers and agents!
In conclusion, you do not need two different protocols for managing LANs and WANs.
In previous issues, we have looked at the protections provided by SNMP Security and discussed how introducing the concept of a SNMP party allows the three primary mechanisms: the MD5 message digest algorithm, the DES encryption algorithm, and loosely synchronized clocks to be integrated into the protocol. In this issue, we'll discuss some issues involved in implementation and deployment.
However, to simplify matters, a set of six initial OIDs have been assigned for use with each IP address, three for local execution at an agent, and three for the agent to communicate with (i.e., at a manager). The three have different settings of authentication and privacy algorithms, with an appropriate MIB view and access control parameters defined for each. The extension of these six to the number actually required in an agent can, of course, be done through the use of SNMP requests acting on appropriate MIB objects.
The definitions of new encapsulation schemes for SNMP, e.g., over OSI, are also defining their own conventions for initial Party OIDs using their own addressing schemes. Note, however, that the use of an address as part of an OID is purely administrative, as one means of providing uniqueness; there is no requirement to have a relationship between protocol stack addresses and party identifiers.
Indeed, for agents which need more than six parties, the party OIDs for the additional parties would typically not be allocated from the initialPartyId branch, but from some other branch (e.g., from a OID subtree within the vendor's tree of the management station which is being used to create them). The only requirement to be met when assigning OIDs is to make them unique across the network.
These initial parties need six secrets. As it turns out, all six are the same length. Thus, at initial distribution, all six secrets can have the same value. This does not impair security because all six values should be immediately changed by the management station as soon as secure communication begins. Changing the secrets thereafter is desirable on a relatively frequent basis. When changed, there is no need for humans to be informed of the new values. In fact, it is better security if humans are not informed. Humans are typically lazy, and thus are unlikely to change secrets at the desired frequency. Thus, it is a good practice to have the secrets which are in frequent use changed automatically.
Some parties may be set-up for special use, for example: for use in emergencies by network fire-fighters who may wish to access an agent from wherever they may happen to be at the time. The secrets for these parties do not need to be changed periodically, but can be left unaltered ready for use at a moment's notice.
As was discussed in a previous article, the use of clocks ensures message timeliness within the limit specified by the lifetime. The specifications also include another clock-based mechanism, called ordered delivery. This mechanism specifies that messages delivered out-of-order be discarded as unauthentic. While this has some benefit for set-requests, there is potential for this to be harmful when applied to retrieval requests. As such the inclusion of ordered delivery has been questioned, but no one wants to further delay the specifications, so these arguments are moot at this time. Due to the inclusion of ordered delivery, another variable (called the nonce) is introduced to distinguish multiple requests generated within one tick of the clock (i.e., within one second).
The inclusion of DES may be problematic for some implementors because of export regulations. While products incorporating DES can be exported from most countries, the inclusion of DES may incur additional complications. As such, it is to be expected that some implementors may choose not to include DES in their implementations, especially since conformance to the specification only requires DES for access to party secrets and, as mentioned above, the requirement to use DES for such access is most significant when establishing new parties, as opposed to changing the secrets of existing parties.
In May and June, there were no new SNMP-related standards that were approved. In the pipeline are the IP Forwarding Table MIB and the three documents defining SNMP Security. Only after these documents are published as RFCs with proposed standard status will they be included in this column.
In the previous issue, the process which is used in the IETF to develop standards was described. In this issue, the heritage of the SNMP standards is discussed, and in the next issue, we'll look at the standards process for IEEE committee 802.
The documents produced by IEEE committee 802 has had significant influence on several media-specific MIBs:
Finally, from ANSI committee X3T9, revision 6.2 of the FDDI Station Management (SMT) document was used as the input to the working group that produced RFC 1285, FDDI Interface Type MIB.
From this, it can be seen that IEEE 802 has been a major influence on SNMP standards. The IEEE is currently in the process of developing a management protocol, named LAN/MAN Management Protocol (LMMP). LMMP, sometimes termed CMIP over LLC (CMOL), is based on CMIP running on top of the IEEE 802 connectionless logical link control (LLC type 1). At present, it appears that the LMMP work in IEEE 802 will not be used in the Internet standardization process, but the management information documented in IEEE 802 will continue to be used as input to IETF standards development process.
This issue has listed the SNMP standards that have been significantly influenced by documents from other organizations. The next issue will present the process that develops the IEEE network management standards.
Draft Standards:
Proposed Standards:
Experimental:
Informational:
Historical:
Once again the working groups supplied plenty of discussion, with the prize going to the SNMP mailing list, which doesn't even have a working group. Be aware that the following synopses present my condensation of many statements by many people. Although I try to present the flavor and summary of the discussion as it occurred, I do not include either direct quotes or attribute, nor do I edit for correctness. If you want to know who really said what, subscribe to the mailing lists. There's no substitute for being there.
Someone asked about good objects to monitor to detect network congestion. One opinion held that monitoring icmpInSrcQuenchs and icmpOutSrcQuenchs was a good idea. Another respondent noted that SNMP is not well suited to congestion control which requires intelligence in hosts, routers, and bridges. The response that SNMP can monitor congestion got agreement, if using ifOutDiscards or ifOutOctets, with the caveat that source quench itself is optional and defaults to being disabled. A different respondent said they use the ICMP objects because agents running on UNIX often cannot supply ifOutOctets.
Someone asked for a UNIX library for MIB-I, MIB-II and private MIBs, and wondered if the API could be standardized. Someone else suggested built-in SNMP for UNIX, e.g., an extensible agent, and SNMP and ASN.1 libraries, all of which could be produced by an IETF working group. A respondent noted that implementation specifications are not consistent with the IETF mission.
Some asked if, in promiscuous mode, should all packets be counted in the MIB-II interfaces table, or just those packets addressed locally? The Interface Extensions MIB says that its receive address table holds only the addresses used in non-promiscuous mode. So, the behavior depends on whether the interface being modeled is a MIB-II interface. In the case of repeater ports, which are not MIB-II interfaces, counting is not done; but, if both a bridge and router are using the same interface, and it is thus promiscuous, all packets are counted.
Someone asked how does an NMS determine the maximum message size that an agent can accept, and on error, should the NMS retry progressively smaller sizes or simply drop to the minimum size? The recommended procedure is to guess initially, and then start decreasing until the complaints stop. Unfortunately, a long, string-valued, variable may make the problem insoluble. A followup asked that since the request is usually smaller than response, how does an agent know the maximum response size? The answer was that the SNMP Security Party MIB includes a maximum message size.
Someone asked if enumerated INTEGERs could be negative, even though they may not be zero-valued. The answer was that use of negative values appears to be within the letter, but not the spirit, of the SMI. So, negative-valued enumerations should not be used.
There was a fairly long discussion on the parallel processing of incoming SNMP requests which produced many warnings for agent implementors.
Someone asked if order of processing of the variable bindings in a set-request was important. In particular, can a manager make any assumption about the order in which processing will occur. A respondent indicated that the processing must occur ``as if simultaneously''. Another respondent observed that there should be no external way to detect the order of processing.
Someone offered to the public domain a utility to monitor a logfile and send SNMP traps under conditions from a regular expression. The host is wuarchive.wustl.edu and the file is /pub/log2sd.tar.Z
There were some questions about EMANATE, a technology for multiplexing agents on a single host, which was announced in the trade press. These questions were referred for off-line discussion as EMANATE is a commercial product used as a local-mechanism and is out of customary IETF concerns.
Someone asked for real data on SNMP overhead. A respondent indicated that a test using a home-grown tool based on the CMU package showed that polling for key objects at reasonable periods of 5 and 10 minutes generated negligible Ethernet overhead and very useful information. The experimenter concluded that monitoring up to 200 systems this way was not intrusive. (See this issue's Applications and Directions column for further discussion.) Another respondent suggested traps backed by polling for a ``last changed'' time-stamp, carefully designed to avoid fast-changing objects such as normal message counters.
A message concerning the Communications Week story on SMP, a proposed new version of SNMP, indicated that the SMP specification and four implementations will be available before a planned Birds-of-a-Feather (BOF) at the Boston IETF. The message then went on to plead for no follow-up questions to the four SMP authors as they have a lot of work to do by then. The Communications Week reporter asked for community reactions. Although there was some concern over previous contributions of the proposers giving their work too much weight, the general consensus was that having relatively complete work by competent people was a good starting place for the open process.
Someone asked how an agent should respond if it does not implement an object in a MIB group which is mandatory for the agent's managed node. The immediate, first reply was that the agent should return noSuchName. Then began an interminable, thundering flame war, replete with denigration of individuals and companies over a topic that has been discussed much the same way several times over the past four years. The ``dogmatic architectural purists'' maintained the strict position, with justification based on the intention to have a stable, predictable base for advanced network management applications. The ``heretical pragmatic iconoclasts'' held that returning a static value promoted easy compliance and was necessary due to many existing implementations that lacked real information and had to interoperate with NMSs that treated noSuchName as a serious failure. Those of the ``Inquisition'' called such responses lies and declared such NMSs broken, and the ``heretics'' retreated behind interoperability and marketing pressure. This discussion will no doubt replay itself in the future, perhaps at the Boston IETF.
Someone noted that statistics in the Internet Monthly Report showed an error rate on one network that was 2000 times better than a second network, and then asked if this was possible. One respondent indicated that the information was probably true but could be misleading; for example, 9870 errors on a DS1 could indicate a single burst. Another respondent said the numbers were for a single interface, not a network, and that the ``good'' interface was an Ethernet, while the other interfaces were DS1 circuits. A followup asked if a new MIB object was needed to indicate what is expected as ``normal''. The responses which followed indicated that the concept of ``normal'' was murky.
Finally, there was a very long discussion about the effect of export restrictions on SNMP's new security mechanisms. The discussion started with several questions: are there any changes in U.S. export regulations, is authentication useful without privacy, will public domain implementations have privacy, can an implementation be compliant without privacy, how will the market react if privacy is omitted, why hasn't the press caught on to this situation, and can the IAB or IETF help. The ensuing discussion was rife with fear, uncertainty, and doubt.
In response to several questions he had received, the editor said there is no counter for multicast bytes sent because it was not in Phase IV DECnet; however, such an object will be added to the list for the next edit. The editor also solicited responses from those interested in interoperability testing in the Fall.
Finally, although the working group has concluded its charter, the mailing list will remain for implementation discussion.
The mailing list has moved to enet_mib@ftp.com
The working group was officially formed, chartered to define ``SNMP MIB objects that instrument characteristics common to all internet hosts''.
Request Address: hostmib-request@andrew.cmu.edu
Someone seeking information on an ISDN MIB got two responses: first, a masters student is writing such a MIB as a part of thesis work, with the final form due May 14 prior to submission to the IETF; and, second, a company is working on IP over ISDN experiments, with results one or two months out.
The Boston meeting agenda includes the Frame Relay MIB and the X.25 MIB.
For the meeting at the Boston IETF, the only agenda item is MAU MIB.
Someone wanted to know if on-line detection of health or failure could be done reliably and with common meaning. A respondent indicated that such information is very implementation-specific. Further discussion brought a proposed wording change, pending editor approval.
A new Internet-Draft is available with all changes.
Someone asked that since the counter pppLinkPacketTooLongs counts DISCARDED packets longer than MRU, should it count packets that are too long but not discarded? In response, the MIB was changed to include ``too long for any reason which results in a loss of information or lack of communication''. If such frames are discarded, then their count is also included in ifInErrors.
There was a long and detailed discussion of reusing ifIndex for internal PPP layers which included analysis of code and data size. Someone argued against filling the MIB-II interfaces table with internal PPP details, and also noted that counting everything was, in general, a bad policy. There were also objections to optional objects or objects relating to unfinished PPP features being required in all MIB implementations.
Distribution of a new MIB draft elicited comments on various specific objects and a general objection to the MIB's technique for presenting optional or negotiated features. The conclusion was to word the MIB so that it doesn't imply a particular implementation strategy.
The editor announced separate documents available as Internet-Drafts for: LCP, Security, IP, and Bridging, and solicited comments at the Boston IETF.
Someone asked for a way to stop data collection but leave results in place. A respondent suggested a ``freeze'' EntryStatus but noted that this is inconsistent with concurrent use by multiple managers and prefers a way to snapshot.
Someone asked how possible inconsistencies among interdependent objects should be dealt with, and went on to suggest various ways to interpret the NMS intent, such as order sensitivity. This drew the response that agents can't do the NMS job and should ignore inconsistencies not prohibited by the MIB specification. (It was further noted that SNMP prohibits order sensitivity.)
A question about RMON extensions for higher level protocols received the reply that such work is scheduled after the Token Ring RMON work completes.
A long discussion of sensing stations in a token ring reached no clear conclusion.
Someone asked if historyControlDataSource, (an OID for an interface) and channelIfIndex (an INTEGER for an interface) should be the same. A respondent said the two objects are different because the former will someday point to other things but the latter may not.
Someone asked about a working group meeting at the Boston IETF. After some discussion, it was decided to have an implementor's BOF instead.
Someone asked when a MIB view should be evaluated. A respondent noted that is an implementation decision, but that it is sensible to evaluate VarBinds as they are processed, keeping in mind that evaluation for get-next occurs after the processing, not before.
A late-breaking message said the final Internet-Drafts have been approved for standardization by the IAB.
All three documents were reissued with various changes, mostly suggested by editor, and with little group discussion.
July 13-17, Boston, MA
For information: +1 703-620-8990
Wednesday, June 15, 7:00-10:00pm
For information: +1 703-620-8990
November 16-20, Washington, DC
For information: +1 703-620-8990
The Simple Times also solicits terse announcements of products and services, publications, and events. These contributions are reviewed only to the extent required to ensure commonly-accepted publication norms.
Submissions are accepted only via e-mail, and must be formatted in HTML version 1.0. Each submission must include the author's full name, title, affiliation, postal and electronic mail addresses, telephone, and fax numbers. Note that by initiating this process, the submitting party agrees to place the contribution into the public domain.
In addition, The Simple Times has numerous hard copy distribution outlets. Contact your favorite SNMP vendor and see if they carry it. If not, contact the publisher and ask for a list.