Java SNMP Agent Builder FAQ

Agent Builder is a tool for developing SNMP agents. SNMP API is for developing SNMP manager applications.

Some of its advantages include:

• High-performance agents.
• The first Java SNMP product to support both DES and strong 128-bit AES encryption.
• Conformance to SNMP RFCs; many competing implementations do not fully conform.
• Significantly reduced development complexity because base classes implement most complex agent functionality.
• A master/subagent architecture based on the standard AgentX protocol.
• A small footprint compared with other Java-based SNMP agents.

• The first Java SNMP product to support both DES and strong 128-bit AES encryption.
• Complete SNMPv1, SNMPv2c, and SNMPv3 support, including USM and VACM.
• Complete SNMPv3 USM support, including HMAC-MD5, HMAC-SHA, CBC-DES, CFB128-AES-128, CFB128-AES-192, and CFB128-AES-256.
• A master/subagent architecture based on standard AgentX technology.
• Support for building Windows Extension Agents.
• An intuitive GUI that automatically generates Java source code from MIBs.
• Reusable base classes that hide many complex SNMP implementation details.
• Optimization techniques for high-performance agents.
• Conformance to SNMP RFCs.
• Dynamic row creation and deletion.
• Small-footprint agents.
• IPv6 support.
• An easy-to-understand configuration-file format.
• Runtime reconfiguration.
• Support for multihomed interfaces.

The relevant reports are summarized in the CERT SNMP vulnerabilities advisory.

• VU#107186 — Multiple vulnerabilities in SNMPv1 trap handling.

  SNMP agents send trap messages to managers. A trap may report a warning or error condition or otherwise notify the manager about the agent's state. SNMP managers must correctly decode trap messages and process the resulting data. OUSPG testing found multiple vulnerabilities in the way many SNMP managers decoded and processed SNMP trap messages.

  iReasoning SNMP Agent Builder successfully passed all 24,100 tests in the OUSPG test suite. We therefore concluded that this advisory did not affect Agent Builder.

• VU#854306 — Multiple vulnerabilities in SNMPv1 request handling.

  Managers send SNMP requests to agents to obtain information or configure the host device. SNMP agents must correctly decode and process these requests. OUSPG testing found multiple vulnerabilities in the way many SNMP agents handled request messages.

  Agents developed with Agent Builder successfully passed the complete OUSPG test suite. We therefore concluded that this advisory did not affect agents built with iReasoning SNMP Agent Builder.

• VU#878044 — Improper SNMPv3 HMAC validation allows authentication bypass.

  This vulnerability allowed specially crafted packets to bypass authentication in affected SNMPv3 implementations. Agents developed with all versions of iReasoning SNMP Agent Builder were not affected.

iReasoning SNMP Agent Builder supports SNMPv1, SNMPv2c, and SNMPv3, including USM and VACM.

iReasoning SNMP Agent Builder fully supports SNMPv3, including the complete USM security model with HMAC-MD5, HMAC-SHA, CBC-DES, CFB128-AES-128, CFB128-AES-192, and CFB128-AES-256, as well as VACM. It has passed interoperability tests with several other vendors' SNMPv3 implementations and is used as a de facto reference implementation by other implementers.

The agent is compatible with the JMX 1.0, 1.1, and 1.2 specifications.

Yes. Agent Builder currently uses the MX4J JMX implementation, but it also works with other implementations, such as the Sun JMX reference implementation. To switch implementations, place the other implementation's JAR file before snmpagent.jar in the classpath.

Yes. The iReasoning agent architecture is based on JMX technology. An agent can run as a standalone application, as an SNMP agent service within an application, or as a JMX adaptor.

See examples/agent/mib2/AgentMX4J.java for details. You can connect a web browser to port 8000 to view the registered MBeans. For example, if AgentMX4J runs on localhost, open http://localhost:8000.

Yes. First, start a server that makes the MBeans remotely accessible. One approach is to start an HTTP adaptor, such as HttpAdaptor from MX4J or HtmlAdaptor from Sun's JMX reference implementation, and then use a web browser to manage the agent.

See AgentMX4J.java and JMXAdaptor.java. Another approach is to start MX4J's JRMP adaptor using the startJRMPAdaptor method in AgentMX4J.java, then use a client such as MC4J to monitor and control the agent through RMI.

iReasoning SNMP Agent Builder is written in Java, so it can run on any operating system with compatible JVM support.

Agent eXtensibility, or AgentX, is a standard protocol designed to dynamically extend the managed objects available on a node. It allows one SNMP master agent and several subagents to connect and register managed objects without interrupting the management service.

AgentX was the first IETF standards-track specification for extensible SNMP agents and was designed to replace earlier open and proprietary extensibility solutions, such as SMUX and DPI. See RFC 2741 for details.

No. Our master agents and subagents use AgentX, which is newer technology and is not interoperable with SMUX.

Master agents and subagents built with Agent Builder should interoperate with other AgentX-based agents regardless of their implementation language. Net-SNMP snmpd version 5 and later has been reported to interoperate successfully with our master agents and subagents. Net-SNMP snmpd is an SNMP daemon written in C and is available on Windows and Unix platforms.

Yes. Interoperability is independent of programming language and platform. The agent can communicate with SNMP managers that conform to the SNMP protocol and with master agents or subagents that conform to AgentX.

Yes. Create a separate SubAgentSession for each master agent.

Yes.

AgentX support is one of the major features introduced in version 3.x. If you do not need AgentX, no code changes are required. To add master-agent or subagent support, make the Agent class extend SnmpAgentX instead of SnmpBaseAgent, then add a few lines to the main method. See the master-agent and subagent sample code for details.

The SnmpConfig.xml file also has minor changes. If your application updates the configuration dynamically, replace trapd with trapSink and snmpV3Trapd with snmpV3TrapSink.

Agent Builder 4.0 is compatible with version 3.x, so no existing code changes are required.

An SNMP master agent can route parts of one SNMP request to multiple subagents. The subagents are completely hidden from the SNMP manager, which sees only a single SNMP entity: the master agent.

With a proxy forwarder, the manager must know about the proxied agents. It builds a request for one specific proxied agent and includes the information the proxy forwarder needs to identify that target.

Yes. Add the following line of code:

Logger.setLevel(Logger.NONE);

Yes. For example, to place the configuration files in d:\config, set the following Java system property:

java -Dcom.ireasoning.configDir=d:\config ...

Yes. You can add entries to the properties, trapSink, and snmpV3TrapSink sections. New entries are loaded and saved automatically. Use the SnmpAgentConfig.getProperty and TrapSink.getProperty methods to retrieve them.

The default agent port is 161. On Unix, binding to that port requires root privileges. Alternatively, change the port number in the agent configuration file.

Yes. See the log4j documentation and the Logger JavaDoc for details and an example.

See the Java source and JBoss configuration file, jboss-service.xml, in jboss.zip. The example creates and registers an MBean during JBoss startup, then starts the SNMP agent from that MBean's start method.

Include snmpagent.jar in the JBoss classpath; for example, place it in .../server/default/lib. Pass the MBeanServer object, server, to the Agent constructor. Otherwise, agent startup creates a new MBeanServer and may cause JBoss to behave differently.

Yes. Set encryptPasswordAndCommunity to yes in the configuration file, then enter the desired plaintext passwords and community names. When the agent starts, it encrypts those values and saves the encrypted forms back to the configuration file.

Yes, when used with J2SDK/JRE 1.4. See the Networking IPv6 User Guide for J2SDK/JRE 1.4 for more information. As of JVM 1.4.2, the supported operating systems were Solaris 8 and later and Linux kernel 2.1.2 and later.

The following excerpt is from the National Institute of Standards and Technology:

“The Advanced Encryption Standard (AES) is a new Federal Information Processing Standard (FIPS) Publication that will specify a cryptographic algorithm for use by U.S. Government organizations to protect sensitive (unclassified) information. NIST also anticipates that the AES will be widely used on a voluntary basis by organizations, institutions, and individuals outside of the U.S. Government—and outside of the United States—in some cases.

The AES is being developed to replace DES, but NIST anticipates that Triple DES will remain an approved algorithm (for U.S. Government use) for the foreseeable future. Single DES is being phased out of use and is currently permitted only in legacy systems.

Assuming that one could build a machine that could recover a DES key in a second (that is, try 2⁵⁵ keys per second), it would take that machine approximately 149 trillion years to crack a 128-bit AES key. For perspective, the universe is believed to be less than 20 billion years old.”

See The AES Cipher Algorithm in the SNMP User-based Security Model for more information about AES in SNMP.

Configuration settings can be stored in an XML file, a database, or another data source. Create a subclass of DefaultAgentConfig and implement its abstract methods.

The DbConfig.java reference implementation stores configuration in eight tables: properties, trapsink, snmpv3trapsink, proxy, trapproxy, user, v3group, and view. Column names match the XML configuration names, and all columns use the varchar type for simplicity.

Storing every row of a very large table in memory can consume too much memory. Call setProcessSnmpRequestDirectly(true) so the table handles SNMP requests directly. The table must then implement getOID and getNextOID to describe the OID tree to the base class.

This approach does not create a corresponding table-entry object for every row. Instead, each getter method in the table class retrieves data from another source and returns the appropriate result. See examples/agent/mib2/AtTable.java.

No. You only need to write Java code to implement the Java SNMP agent. The subagent.dll module delegates SNMP requests from the Windows SNMP service to your Java agent.

The JAR files are obfuscated, so conflicts can occur when all of them are present in the same classpath. If you need both SNMP API and Agent Builder, we can provide a special edition that contains all required classes.