The following articles were updated on Friday 6 March 2009 to the current snapshot of activities:
“Work-in-Progress: Current IETF activity related to SNMP”
“Work-in-Progress: Current IETF activity related to MIBs”
These updates are provided in anticipation of the 74th IETF meeting to be held in San Francisco, CA, USA, 22-27 March 2009.
In a world of commercial and open source software toolkits, how can we best identify and select the option lowering the cost of developing SNMP Agent and SNMP Manager applications?
The goal in selecting an SNMP developers’ toolkit is to find the most cost effective means to accelerate development and realize successful project completion.
During the process of SNMP toolkit evaluation, we need to consider factors from both the technical perspective and business perspective.
Some examples of business factors:
Some examples of technical factors:
Based upon the relative significance of each factor we can identify and select the SNMP developers’ toolkit offering the best value and most cost effective means to accelerate development and realize successful project completion. The right SNMP developers’ toolkit is not necessarily the least expensive. Rather, the right SNMP developers’ toolkit is the one that is capable of providing substantial engineering efficiencies during development and facilitates the delivery of a less encumbered, more profitable product.
Open-source SNMP software was initially created as a reference implementation for interoperability testing with proprietary implementations of the SNMP protocol. Over time, the quality of open-source SNMP developers’ toolkits has improved to a point where there is a suitable match for a variety of OEM development efforts.
Commercial SNMP software often provide a much richer feature set than open-source developers’ toolkits. Also, commercial SNMP software offerings have adjusted to low-end market realities of quality open-source software to a point where there is a low cost or no cost binary commercial version that is often competitive with open-source alternatives.
In either case, open-source or commercial, it is important to have sufficient development expertise with SNMP and MIB technologies to make effective use of the selected SNMP developers’ toolkit. This is the core value provided to your project by the right choice of SNMP consultant.
The next step to gaining a better understanding of the alternatives and trade-offs when identifying and selecting the best choice of commercial or open-source SNMP developers’ toolkit is to contact me with your project requirements and questions.
Updated on Tuesday 10 March 2009
The Structure of Management Information version 2 (SMIv2) provides the standard for the definition of managed objects within Management Information Base (MIB) modules. The current specifications for SMIv2 as published in April of 1999 by the Internet Engineering Task Force (IETF) are freely available as IETF Standard 58, a set of three RFCs (2578-2580).
I am often asked what MIB modules are IETF working groups developing. MIB modules are defined within the relevant working group and reviewed by a small cadre of IETF MIB doctors prior to publication as an RFC. The following provides a brief outline of and links to the current work-in-progress.
Note that Internet-Drafts are works-in-progress and expire when a subsequent revision is available, or six months after initial publication, whichever occurs first.
I am happy to discuss the usefulness and applicability of the below works-in-progress to your project. Just contact me with your project parameters and ideas.
Operations and Management Area:
Internet Area:
Security Area:
Routing Area:
Transport Area:
Individual Submissions:
Updated on Tuesday 10 March 2009
The Simple Network Management Protocol version 3 (SNMPv3) is the Internet-Standard Management Framework. The current specifications for SNMPv3 as published in December of 2002 by the Internet Engineering Task Force (IETF) are freely available as IETF Standard 62, a set of eight RFCs (3411-3418).
I am often asked what IETF working groups have work-in-progress on improving upon the current SNMPv3 standard. The following provides a brief outline of and links to the current work-in-progress.
Within the Security Area:
Within the Operations and Management Area:
Current RFCs include:
Current RFCs include:
Individual Submissions:
Management Information Base (MIB) modules are designed within the applicable protocol working group and is the topic of another article.
I am happy to discuss the usefulness and applicability of the above works-in-progress to your project. Just contact me with your project parameters and ideas.
Versions of the SNMP prior to third version (SNMPv3) did not include adequate security. Any sufficiently motivated individual with physical access to a shared network link and a protocol sniffer had the ability to capture clear text messages exchanged between a manager application and its agents. Once captured, it was simply a matter of extracting community strings and agent addresses of interest in order to usurp the role of the manager application, possibly hijacking and re-configuring network devices along the way.
The design of SNMPv3 included authentication and privacy (encryption) mechanisms for the protocol. By incorporating these mechanisms, SNMPv3 became self sufficient with no need of any other network services for the secure transmission of SNMP messages. After all, network operators need their network management protocol to be functional even when major portions of the network and its services are impaired.
Three security levels are defined for SNMPv3, in increasing degree of security as follow:
For manager applications that only require their agents to verify the authenticity of SNMP message exchanges, the authNoPriv security level is sufficient. This security level offers adequate protection for SNMP message exchanges that do not include sensitive data.
For manager applications that require their agents to both verify the authenticity of SNMP message exchanges and to provide privacy (encryption) of sensitive data contained within the scoped PDU portion of the SNMP message, the authPriv security level must be used. Since the DES encryption cipher is considered cracked, an AES encryption cipher of sufficient length should be used.
However, it is important to avoid using weak authentication or privacy pass phrases. Even when an SNMP manager application uses the authPriv security level with the AES cipher, you can jeopardize secure SNMPv3 message transmissions. In better deployments, the SNMP configuration and applications work together with the proper ciphers and strong pass phrases to ensure secure SNMPv3 message transmission and I am happy to show you just how easy it is to get this right.
In highly secure environments snmpEngineID values should also be protected by using a discovery mechanism together with a security model that avoids exchanging cleartext SNMP messages on network links.
The next step towards using SNMPv3 for secure transmission of SNMP messages is to contact me with your project requirements and questions.
In our current business economy development schedules are short and project budgets constrained.
When a software project involves the design of Enterprise MIB modules, there is a tried and true approach to reducing associated cost and risk factors. This valuable design approach leverages the practical wisdom and lessons-learned from the development of more than 250 IETF standards-track MIB modules.
The IETF Operations And Management (OAM) Area directorate collected and posted helpful information related to MIB design on the following topics:
These topics and others are published as a “Best Current Practice” in RFC 4181, “Guidelines for MIB Documents”. RFC 4181 describe a better approach towards the design of MIB modules, but does not address the single largest cause of rework and redesign. This critical step, is the creation of an Information Model, as cited by the Network Management Research Group (NMRG).
Within each IETF standards-track MIB module there exists a tacit, de-facto Information Model. This NMRG view describes how Information Models can represent different abstraction levels and provides a set of reverse-engineered Information models for IETF published MIB modules. This NMRG point of view is described in RFC 3444, “On the Difference between Information Models and Data Models”. Since publication of RFC 3444, IETF working groups now define an Information Model before designing their MIB modules.
My consulting clients who choose to first define an Information Model regard this initial step as a great value for reasons that include the following:
And the best value yielded by the small amount of time and effort spent on first defining an Information Model is the significant reduction in latter development stage risk involving re-design of portions of their Enterprise MIB modules.
It is simply easier to identify and correct logic on a single page or screen image than it is to modify definitions and descriptive text across the hundreds of pages comprising a set of enterprise MIB modules. The simple fact that the need for re-design is often first detected during the latter phases of implementing MIB modules in an SNMP Agent or SNMP Manager application serves to compound the value provided by the initial definition of an Information Model.
Certainly the design approach of information modeling before Enterprise MIB design reduces cost and reduces risk that can adversely impact project budget and schedule.
The next step in taking advantage of this valuable design approach is to contact me with your project requirements and questions.
Using standards based technology we provide software design and development services for the remote monitoring, control and configuration of internet-enabled devices and services.
Our clients are original equipment manufacturers of communications equipment, computational and storage systems, web and internet based software applications.
An overview of our company and principal consultant are provided for your review.
Contact us for additional information about our consulting services and to review your project requirements.
