The Simple Times (tm) is an openly-available publication devoted to the promotion of the Simple Network Management Protocol. In each issue, The Simple Times presents technical articles and featured columns, along with a standards summary and a list of Internet resources. In addition, some issues contain summaries of recent publications and upcoming events.
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 as an online journal in HTML and PostScript. New issues are announced via an electronic mailing list. For information on subscriptions, see the end of this issue.
Before giving more details on how we reached this point and where I see us going from here, I want to express my special thanks to the following individuals that made up the specification editor teams. Their commitment and actually doing the hard work of writing down the Working Group consensus made our core set of specifications possible.
This seems like a reasonable time to give my views about where we are. A few words on the Internet Standards Process seem in order since the SNMPv3 core specifications are about to be published as Proposed Standards.
The Internet Standards Process is described in RFC 2026. I encourage everyone to read this RFC to get a broader understanding of the various types and maturity designations for RFCs. Additional information on the Process as well as information on the current status of RFCs is contained in the Internet Official Protocol Standards (STD 1) currently published as RFC 2200.
The designation of the core specifications from the Working Group as Proposed Standards indicates that they have entered on to the ``Internet Standards Track''. The objective of specifications on this ``Track'' is to become full Internet Standards but there are several steps along the way. As described in RFC 2026, the subsequent maturity levels on the ``Internet Standards Track'' are Draft Standard and Internet Standard. The Proposed Standard status of the specifications indicates a number of things, for instance:
Where do I see the Working Group going from here? Identifying SNMPv3 implementations and promoting interoperability tests must be done before the specifications can be advanced to Draft Standard. An important part of this activity will be determining more specifically what is meant by SNMPv3 interoperability. This will likely involve developing Applicability Statement(s) for the specifications. Additionally, the Working Group has indicated support for providing a simple, understandable overview of SNMPv3 and more documentation for the transition from and the coexistance with the earlier versions of SNMP. It is also likely that some changes will be required to RFCs 1902-1908 though these are expected to be fairly small.
The Working Group met at the 40th IETF in Washington, D.C. in December '97. Besides celebrating the advancement of the core specifications to Proposed Standard, the Working Group heard implementation reports, discussed interoperability testing in the early summer, and gathered suggestions for future work and an update of the charter.
The article will quickly review the efforts from which the concepts derive, the constraints and technical goals for SNMPv3, and then discuss the major architectural concepts and how they evolved into their current form.
It is expected that the reader will be acquainted with SNMPv1 concepts, and have read the document ``An Architecture for Describing SNMP Management Frameworks''. A knowledge of the SNMPv2 effort, while not required, will aid understanding.
In December 1995, the SNMPv2 Working Group was deactivated, and independent coalitions were formed to study and experiment with alternative security and administrative framework designs. The two most prominent approaches, SNMPv2u and SNMPv2*, both employed a user-based security model as a simpler alternative to the party-based model. They had many points in common in the design of the administrative framework, but the two approaches had philosophical differences.
SNMPv2u supported early standardization of the security features and a minimal specification, and deferred standardization of features for managing large networks to encourage rapid deployment of simple agents.
SNMPv2* supported concurrent standardization of security and scalability features to ensure that the security design adequately addressed issues of proxy, trap destinations, discovery, and remote configuration of security, to enable effective management of medium and large networks.
In August 1996, the Security and Administrative Framework Evolution Advisory Team was formed to recommend a single approach that would resolve the differences between SNMPv2u and SNMPv2*. At the San Jose IETF meeting (December 1996), the team published its recommendation.
In March 1997, the SNMPv3 Working group was chartered to continue the work of the SNMPv2 Working Group to define a standard for SNMP security and administration.
In this article, an unqualified reference to ``the Working Group'' refers to the SNMPv3 Working Group.
The Working Group must have realistic expectations; the documents and the design do not need to be perfect. The documents must be done quickly, and the standard must be useful, functional and deployable, without constraining implementation decisions. It should be reasonably possible to move portions of the architecture forward in the standards track, even if consensus has not been reached on all pieces, and to correct problems later without destabilizing the whole proposal.
The focus must be on specifying a single standard approach in a timely manner. The work will start with the recommendation of the advisory team. The recommendation is based on reusing concepts, technical elements and documentation from SNMPv2u and SNMPv2*. The focus must be on completing the existing proposals, not on developing new proposals. RFCs 1902-1908, the SNMPv2 Draft Standard, should not be changed if that can be avoided. An initial set of documents should be ready for Working Group ``Last Call'' by Munich (August 1997). Work on additional output should be deferred until after that date.
SNMP must be secure in a way that is useful for the people operating networks, especially support for secure SETs, which is the most important deficiency in SNMPv1.
The wide range of operational environments with differing management demands that comprise the Internet community must be accommodated. It must be relatively inexpensive to deploy a minimal conforming implementation, but also possible to support additional features useful for managing large networks.
SNMP should be able to be extended as new mechanisms or protocols become available or unanticipated aspects of network operation and management arise.
The documents should be clear and unambiguous.
It should be easy to setup and maintain the security and administrative configuration.
SNMP should be kept as simple as reasonably possible.
The Working Group should use as much as practical of the concepts, technical elements and documentation from the SNMPv2u and SNMPv2* activities, since implementation experience has already been gained for features of these designs.
It is highly desirable that the architecture be able to ease the transition to SNMPv3 from earlier versions, including SNMPv1, SNMPv2p, SNMPv2c, SNMPv2u, and SNMPv2*. It should also be flexible enough to support a wide range of possibilities for future frameworks.
Since new technologies may emerge, or existing technologies may prove inadequate, the architecture should make it possible to incrementally upgrade portions of SNMP, without disrupting an entire SNMP framework. To facilitate the development, testing, and deployment of alternative solutions to supplement the industry standards, the architecture should permit the integration of enterprise-specific modules.
Since there are many more agents than managers in a typical network environment, any complexity should be incurred in the manager rather than the agent. Where the overhead to support features needed for large networks must be present in all entities, even those that do not support the feature, the overhead should be minimized as much as feasible.
A standard MIB for specifying trap destinations should be part of the output of the Working Group, since this is needed by a number of SNMP-related Working Groups.
One of the major problems noted in the discussions regarding converging the SNMPv2u approach and the SNMPv2* was side-effects. There were many instances of an item important to one ``camp'', on which the second camp was willing to compromise, until it was studied further, and it was found that the compromise caused unwanted side-effects to something important to the second camp. This happened frequently, and made it difficult to find reasonable compromise solutions.
It also became obvious that the proposals could not simply be merged by taking pieces of text from A, adding them to pieces of text from B, and publishing a set of merged documents. Even when the advisory team attempted to resolve conflicts by selecting one approach over the other, the side-effects that occurred caused those simple decisions to be revisited again and again.
Software engineering techniques, namely modularity, encapsulation, tight cohesion, and loose coupling, can be used to help resolve the side-effect problem. Starting with those elements that were common to SNMPv2u and SNMPv2*, such as authentication, encryption, timeliness checking, and view-based access control, the team identified those parts of the designs which were not generally contentious. Then the team defined interfaces to hide the internal processing and data of those modules, to protect them from side-effects of changes external to the module.
This was not a very difficult task for the areas that were not highly contentious, since SNMPv2u and SNMPv2* separated user-based security from the administrative model to a large degree, replaceable components of user-based security were already modular, some implementors had added view-based access control to SNMPv1, and the use of existing components made SNMPv2c relatively simple to implement.
The greatest problem was the MIB, where objects that were related to separate areas of processing were combined into one large MIB module, and objects were sometimes used in different ways by different elements of procedure, rather than reflecting the separate nature of the various processing modules that operated on the objects. By defining separate MIB modules for different processing areas, managed objects could be limited to one processing module, and resolution of issues regarding those objects could be deferred until discussion of that module was on the table. When managed objects were used by multiple processing areas, duplicate objects could be defined, and the variations in semantics caused by different usage of the objects could be identified. It was always possible that the duplicated objects could be merged later.
More importantly, the debate over proxy led to agreements that if an adequate interface could be identified and defined, then proxy could be developed later as a separate module.
Based on the precedent of RFCs 1902-1908 and the proposed deferral of proxy, the advisory team recommended a modular SNMP architecture, with fixed interfaces, and documents that could be advanced individually. This approach would use modularity, encapsulation, tight cohesion, and loose coupling to minimize the side-effects, and make independent advancement of SNMP modules possible.
All very pretty, but the devil is in the details. The SNMPv3 Working Group was chartered and the real work began.
It is unacceptable to dictate to enterprises how they should implement their code. Using application programming interfaces was rejected, but they could be defined as application service interfaces, so they only describe the nature of the data that crosses boundaries between modules. Enterprises merely need to understand the concepts of the data that must be passed from module to module.
However, that still had the effect of dictating how an enterprise should build their implementation in specific modules - still unacceptable. ``The Architecture for SNMP Management Frameworks'' was changed to ``An Architecture for SNMP Management Frameworks'', to show that enterprises could use a different architecture if they chose.
But that still implied constraints for those who were willing to follow this architectural model. The architecture was useful for describing the concepts, but the constraint for a modular implementation, even if only implied, was unacceptable.
An architecture could only be used to describe the concepts and the conceptual interfaces contained in the conceptual architecture - thus, ``An Architecture for Describing SNMP Management Frameworks''.
The SNMPv3 architecture keeps the competing requirements of these environments in balance and allows the more complex environments to logically extend the simple environment. Whenever possible, the costs associated with allowing support for extended functionality is borne only by those who extend the functionality.
The subsystem and modular approach aids in this goal by permitting modules to define a minimal implementation approach for those environments with severe resource constraints, more complete implementation approaches for those environments where resources are less constrained, and by permitting support for multiple approaches within a given node.
+-------------------------------------------------------------------+ | SNMP entity | | | | +-------------------------------------------------------------+ | | | SNMP engine (identified by snmpEngineID) | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | | | | | | | | | | | Dispatcher | | Message | | Security | | Access | | | | | | | | Processing | | Subsystem | | Control | | | | | | | | Subsystem | | | | Subsystem | | | | | | | | | | | | | | | | | +------------+ +------------+ +-----------+ +-----------+ | | | | | | | +-------------------------------------------------------------+ | | | | +-------------------------------------------------------------+ | | | Application(s) | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Proxy | | | | | | Generator | | Receiver | | Forwarder | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | Command | | Notification | | Other | | | | | | Responder | | Originator | | | | | | | +-------------+ +--------------+ +--------------+ | | | | | | | +-------------------------------------------------------------+ | | | +-------------------------------------------------------------------+
By defining message processing in modules that can be replaced or supplemented, the burden of perfection is eliminated. The Working Group can accept the current proposal to allow the standard to advance, but the message processing, and its defined format, can be replaced or supplemented if necessary.
One concern regarding the SNMPv2 message format was its sheer size. The size of the proposed SNMPv3 message format is also large. If somebody can design a message format that is smaller and more efficient than the current design, the existing format can be superseded without necessarily changing the other conceptual modules of the architecture.
That said, changing the message format could have a very negative effect on interoperability, so the designer of a new message format is likely to face a steep uphill battle to convince the community to use the new format. The architecture allows for new message formats, but the marketplace is expected to discourage the development of new formats.
Multiple message format modules can exist simultaneously, to permit support for new, and especially for old, message formats. Message Processing Modules can be developed for SNMPv1 and various flavors of SNMPv2.
Support for previous security formats, such as SNMPv1 communities, can be added fairly easily. For example, implementors may choose to support communities by mapping them to user-based security identifiers, or by defining a separate module for community-based security.
There have been a number of security models discussed during the evolution of SNMPv2/SNMPv3. Some models, such as the party model, require parameters that do not fit well with the requirements of the User-based model. Security processing is defined in modules, and the message processing module can call the appropriate module for a particular message. This permits support for security models with different parameter requirements, and to support co-existent security models.
The starting design defined an engine which contained modules for message processing, message security, and local processing of PDUs. It also identified applications that used the engine. In keeping with traditional SNMP concepts, the applications executed only on managers.
Proxy was included in the design as a management application. Proxy has historically been viewed as an agent functionality, even though proxy agents generate requests and receive notifications and responses, which are manager functions.
The design showed Inform PDUs being issued by management applications, while trap PDUs were issued by the local processing module in the engine. To send traps, the local processing module needed a trap table, but then so did informs. The Working Group debated combining informs and traps into one module, but would this be a module in the engine (i.e. in an agent) or an application external to the engine (i.e. in a manager)?
The concept developed that applications were not limited to execution on a manager; an agent could be described as executing specific applications, such that all local processing is just a special case of an application. All traditional processing can be broken down to five types of applications - request generation, response processing, notification sending, notification receiving, and proxy processing.
A combination of these application modules would exist in a traditional agent; a different combination would exist in a traditional manager. Other existing implementations contain non-traditional combinations of applications, such as an implementation that emits traps, but does not accept requests.
This line of thinking resolves some of the SNMPv2 issues such as whether informs were generated by agents or only by managers, and whether only agents should have agentIDs/snmpIDs. The concepts of agent and manager become only specific subsets of the possible configurations of SNMP entities.
Additional applications can be defined that allow extensions to address new aspects of network operation and control, such as applications for distributed management.
Since SNMPv1 is defined in terms of traditional agent and manager functionality, and traditional agents and managers can be described as a combination of applications, then applications can be used to describe SNMPv1 functionality. Therefore, the architecture can be used to describe not only an SNMPv3 framework, but also the SNMPv1 framework, and possibly the various SNMPv2 proposed frameworks.
While access control is commonly considered part of security, analysis of the usages showed that there was a distinct difference between the security processes applied to messages and the security processes applied for access control. Application modules need to use access control services while processing objects, but authentication and encryption are used while processing messages. A message header is used while processing message security, but the PDU is used while applying access control.
There are certainly common factors, such as identification of the principal and the level of security processing requested. These can be provided through the service interface. The distinction was sufficient to get consensus among the active participants that the MIB objects could be described in independent MIB modules, and the elements of procedure for access control could be described in a module separate from the message security procedures.
If access control is a separate module called only by applications, it can be used by non-SNMP applications running on the same system. Consistent access control is possible without the onerous operational task of maintaining parallel configurations of access control policy databases for SNMP and non-SNMP applications.
Hopefully, this architecture will encourage the deployment of SNMPv3 and allow continued advances in SNMP as the needs of network operation and control change over time.
To deal with the ``who'' question, it is necessary to define that ``who.'' Thus, the SNMP architecture introduces the term ``principal.'' A principal is the ``who'' on whose behalf services are provided, or processing takes place. A principal can be, among other things, an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or a set of applications; and any combination thereof.
Since a principal may have to be identified both inside and outside a given security model, there is a need to have two identities: one specific for that security model that may take any shape convenient for that security model (for example, an ASN.1 OID to identify a Party, or an octet string to identify a User), and the other one, security-model-independent, that can be used outside a particular security model. This last one, called securityName, is a human-readable string.
Therefore, the proposed SNMP architecture supports multiple security models. Moreover, it allows several different security models to be used simultaneously by an SNMP entity. SNMPv3 messages carry a field in the header that identifies by which security model the message must be processed.
To guarantee interoperability, one security model must be defined and implemented by every compliant SNMPv3 entity. It is called User-based Security Model (USM) and its model number is 3.
The USM identifies SNMPv3 entities by their snmpEngineID. SNMPv3 entities can be traditional agents running on managed devices, traditional network management stations, mid-level managers, etc. The userName is needed for auditing and authorization purposes while the snmpEngineID is needed to identify the target of an SNMP operation.
When two SNMP engines communicate, one is designated to be the authoritative SNMP engine. When an SNMP message contains a payload that expects a response (for example a get-request, get-next-request, get-bulk-request, set-request or inform-request PDU), then the receiver of such messages is authoritative. When an SNMP message contains a payload that does not expect a response (for example, an snmpV2-trap, response or report PDU), then the sender of such a message is authoritative. It is important because (a) the keys that are owned by the principal but stored in SNMP engines are localized to the authoritative engine (see below), and (b) the timeliness indicators of the authoritative engine are, well, authoritative. (The non-authoritative SNMP engine maintains its notion of the timeliness values from the authoritative engine and updates its notion as appropriate to keep them in sync with the authoritative one).
UsmUserEntry ::= SEQUENCE
{
usmUserEngineID SnmpEngineID,
usmUserName SnmpAdminString,
usmUserSecurityName SnmpAdminString,
usmUserCloneFrom RowPointer,
usmUserAuthProtocol AutonomousType,
usmUserAuthKeyChange KeyChange,
usmUserOwnAuthKeyChange KeyChange,
usmUserPrivProtocol AutonomousType,
usmUserPrivKeyChange KeyChange,
usmUserOwnPrivKeyChange KeyChange,
usmUserPublic OCTET STRING,
usmUserStorageType StorageType,
usmUserStatus RowStatus
}
As you see, the table entry holds: a principal identifier (usmUserName
and usmUserSecurityName); a reference to another entry in this table
from which this entry was cloned; authentication and privacy protocol discriminants
(which tell us what protocol to use); the typical SNMP table row maintenance
objects (usmUserStorageType, usmUserStatus); and several
objects related to remote key update (usmUserAuthKeyChange, usmUserOwnAuthKeyChange,
usmUserPrivKeyChange, usmUserOwnPrivKeyChange), that we will
discuss later on.
Since all the keys are localized (see below) to a particular SNMP engine, it is necessary to store the identifier of the SNMP engine (usmUserEngineID), for which the given keys for the user usmUserName are prepared (since they will not work with any other user, or with any other engine).
If you take a human-readable ASCII string (what a typical user would choose as his password) and run a cryptographically strong hash function over it, you will get a pseudorandom sequence of bytes (usually of a fixed-length), just what a computer would love to use as a key. The USM password to key algorithm concatenates the password with itself many times until it forms a 1 Megabyte string before the hash function is computed. This slows down a possible dictionary attack, when an adversary puts a whole dictionary in his computer and runs the hash-function over each word from it in turn, to see whether the resulting key will match the cryptographic lock he's trying to pick.
As a result, if an SNMP engine is compromised, only communications between this one engine and the users whose localized keys were stored in that engine, are compromised. All the communications between those users and other engines are still secure.
Key update uses a cryptographically strong one-way function to: (a) put an impenetrable barrier between the old and the new keys, preventing backwards movement; and (b) make the relations between the bits of the old and the new key intractable both ways (forward and backward), forcing the cryptanalyst to use only the traffic protected by a given key in the attempts to determine that key.
There is, however, a danger if a key for an engine ever falls into the hands of an adversary. From that point on, it is possible for the adversary to ``drill forward.'' The adversary will know the current communication key for as long as the adversary monitors all the traffic to that engine and picks all the key update requests. In order to make ``drilling forward'' more difficult, it is strongly recommended that key update requests always be protected by encryption, if at all possible.
The Textual Convention KeyChange defines the behavior of the objects responsible for key updates.
It is assumed, that there are secrets already available on the SNMP engine whose keys we are updating. Normally, there would be a ``user template'' - an entry in the user table that is used for only one thing - providing cryptographic material (initial keys) and information (initial cryptographic algorithms) for creating new users. Since it was chosen not to employ Diffie-Hellman key negotiation, and encryption is optional, it is not feasible to securely deliver a secret remotely, unless the remote end already shares some secrets with us. Thus, whether the secrets were distributed off-line, or were taken from the preconfigured entries in the user table, by the time we do a key update there is always an ``old'' secret that we replace (modify).
Once you have your old secret and know what you want to replace it with, the steps in the TC KeyChange key update algorithm are:
Thus, there are two key update objects per each key in the user entry. One, usmUserAuthKeyChange, is for authentication key updates by the network administrator, and would not be within the accessible part of the MIB tree of anybody else.
The other one, usmUserOwnAuthKeyChange, differs from the previous object in one important detail: in addition to implementing the algorithm defined by KeyChange TC, before permitting the operation it checks whether the requester of the operation has the same userName as the ``owner'' of the row in which this object resides. This means, that even though a user may be granted write access to this object, he will be able to modify only his own key. Precisely as designed, and without increasing the complexity of access control.
Thus, the network administrator can configure the initial keys for a user, while the user can do subsequent key changes by himself. Of course, coordination between the users and the network administrator is required - it is easy to see that if the administrator starts changing people's keys without letting them know, nothing good would come of it.
In SNMPv3 USM, both data integrity and authenticity are ensured by using a cryptographically strong hash-function in HMAC mode (RFC 2104). HMAC is the ``top of the line'' method of applying keyed hash functions for authentication purposes. In brief, the steps for the HMAC mode are:
In general, synchronized clocks are used. Every message carries a timestamp, which can be examined upon receipt, and if the difference between the timestamp and the clock value of the receiving engine is too large, the message is rejected as old.
However, synchronizing the clocks can be a problem. In addition to that, some SNMP entities may have no battery-powered clocks (i.e. after reboot or power failure their clocks start from zero). But if it is difficult for one engine to keep track of another engine's clock, having each of them keeping track of the other is simply intolerable.
The authoritative engine maintains two timeliness values: engineBoots (how many times this SNMP engine was rebooted) and engineTime (how many seconds passed since the last reboot). These are not the same as ``real'' clock, but the similarities are obvious.
Both timeliness values are present in the USM message header and play an important role in replay detection.
The non-authoritative SNMP engine must figure out the current timeliness values of the authoritative engine it communicates with (possibly by sending an insecure GET, and verifying the obtained values with an authenticated request), and keep track of them. By providing automatic clock synchronization (see below), SNMPv3 USM reduces the overhead of explicit clock retrievals to a minimum.
Initially, the non-authoritative engine has to explicitly retrieve the time value from the authoritative engine. From that point on, clock synchronization is automatic, as long as the authoritative engine's clock does not fall behind the non-authoritative engine's clock for more than 150 seconds since the last secure communication.
Each secure message carries a time value (when it was encoded to be sent). Upon arrival, this time value is compared with the clock. If the difference is within 150 seconds, the message is timely.
If a secure message is within the time window and comes from the engine with the authoritative clock, and the clock value is greater than the latestReceivedEngineTime for that engine, then the notion of the time (engineTime) for that engine is updated. If the received engineBoots value from the authoritative engine is greater than the saved value, then the value is updated for all three objects: engineBoots, engineTime, latestReceivedEngineTime.
Every message has a message identifier - an integer field msgID. This field should be different for every request, and it is expected that at least for a 150 second interval this will hold true for any implementation. A request originator must match the responses it receives with its outstanding requests using msgID, and it is clear that there cannot be two responses with the same msgID within a 150 second period. This is how the originator detects the replays.
A receiver, on the other hand, cannot utilize msgID for this purpose. The only downside of receiving reasonably ``fresh'' but duplicated (replayed) retrieval requests is time spent on processing them - they can cause no other harm. Requests to modify the information are more dangerous. They are dealt with adequately by the sender including a TestAndIncr object in a SET request. Thus, in a replayed message the object's value will not match the expected one and the operation will fail. This is described in the Message Processing Model.
If privacy is supported by a given engine, it must support the DES [3,4] encryption algorithm. The Encryption algorithm is determined by the usmUserPrivProtocol object in the user table entry.
Previous versions of SNMP had a problem because the DES initialization vector (IV) was not changed from message to message. This has been fixed in the USM. The IV now differs for each encrypted message.
The encryption keys are obtained, localized, kept and updated exactly the same way as those for authentication. The objects usmUserPrivKeyChange and usmUserOwnPrivKeyChange are responsible for that. Note that if SHA-1 is used to obtain a DES encryption key, the first 128 bits of the SHA-1 output are used and the rest is discarded.
There is no complete mechanical conversion from definitions of managed objects in the SMIv1 format to the SMIv2 format, since the SMIv2 format contains fields for additional information that must be provided by the designer of the definitions. Also, the ACCESS clause was changed to MAX-ACCESS and its meaning changed, and, thus, the values need to be reviewed when converting from SMIv1 to SMIv2. (You cannot simply use the same values in all cases when you translate object definitions.) Finally, the SMIv2 format contains constructs to define requirement specifications and implementation specifications not found in the SMIv1 format.
By design, the format for the definition of managed objects is independent of the protocol to access them, except for objects with data type of Counter64. That data type does not exist in the SNMPv1 and SNMPsec protocols. A conforming SNMPv1 or SNMPsec entity will generate an ASN.1 parse error when parsing a message containing a Counter64 data type. RFC 2089 defines the behavior of a conforming bilingual (and multilingual) agent that has access to objects with the Counter64 data type.
At this time, there is widespread use and support of both versions of the SMI. This is due in part to the policy in the IETF that new versions of RFCs must specify MIB modules in the SMIv2 format. Many commercial products that process MIB modules support both formats.
The Simple Times started back in spring 1992. The various issues of The Simple Times not only presented interesting articles, but also mixtures of thoughtful summaries, answers to frequently asked questions, excellent inside information and sometimes thought-provoking discussions about future directions. Since its appearance, The Simple Times has been very popular within the SNMP community and old issues are still being downloaded from the SimpleTimes Web server by people who want to better understand why things are the way they are. Nowadays, The Simple Times has nearly 5000 registered readers.
Marshall Rose left the network management area about a year ago and his farewell seemed to ring the death-knell of the The Simple Times. However, given the immense amount of SNMP related work still going on within the IETF, there was a need to re-active The Simple Times in order to document some of the evolution and to have a place where people can publish their thoughts on the future of Internet network management.
After some talks with Marshall and other people who had previously contributed to The Simple Times, it was decided to move the newsletter and the associated Web server to a new home. The Web server is now maintained by the University of Twente by the same people who maintain the SimpleWeb server, and the editing work is done as a joint project between the Technical University of Braunschweig (Germany) and the University of Twente (the Netherlands). We would like to take this opportunity to thank Marshall for all his help and the time he has spend to make the previous 16 issues of The Simple Times a reality.
The issue you are reading right now is the result of this transition and we plan to continue The Simple Times as the same newsletter it has been in the past. This means that we continue to rely on help and contributions from the SNMP community. As Marshall wrote in the first issue:
Our job is simply to make the trains run on time. When you like the contents, thank the other volunteers. If an issue comes out late, you know who to blame.
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 electronic 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.