test

Java Dynamic Management Kit 5.1 Getting Started Guide

2.7 The SNMP Toolkit

The Java Dynamic Management Kit provides a toolkit for integrating SNMP management into a JMX architecture. SNMP management includes:

For more information regarding the SNMP toolkit, refer to the Java Dynamic Management Kit 5.1 Tools Reference Guide and the Java Dynamic Management Kit 5.1 Tutorial.

2.7.1 SNMP Packaging in Java DMK 5.1

The Java packaging of the SNMP classes for Java DMK 5.1 has changed. In Java DMK 5.0, the SNMP classes were included in the SUNWjsnmp package, and they required a separate Java archive (JAR) file, jsnmpapi.jar. In Java DMK 5.1, the SNMP classes are packaged in the SUNWjdmk-runtime package, and require the same jdmkrt.jar JAR file as the rest of the current Java DMK classes. This new arrangement avoids the issue of potentially conflicting versions of the SUNWjsnmp package encountered under Java DMK 5.0.

In addition, the SNMP API delivered with Java DMK 5.0 is now deprecated. The SNMP API in Java DMK 5.1 is effectively a completely new SNMP API, that introduces a more orthodox system of Java class naming.

To use existing SNMP implementations that you created using Java DMK 5.0 alongside SNMP implementations created using Java DMK 5.1, you must translate the class names of the 5.0 implementations into the new format. How to perform this translation is explained in the Release Notes.

To continue to use SNMP implementations you created using version 5.0 of Java DMK under version 5.1, a new JAR file called legacysnmp.jar is provided. You must add this new JAR to your classpath when running your Java DMK 5.0 SNMP implementations under Java DMK 5.1.

All the examples of SNMP code given in the /examples/current/Snmp directory have already been translated to implement the new class naming system. However, should you require them, a full set of SNMP examples that follow the package naming from Java DMK 5.0 have been retained in the /examples/legacy/Snmp directory.

2.7.2 Developing an SNMP Agent

An SNMP agent is an application that responds to SNMP requests formulated as get, set, getnext, and getbulk operations on variables defined in a MIB. This behavior can be fully mapped onto the MBean server and MBean resources of a Java dynamic management agent, provided that those MBeans specifically implement the MIB. An SNMP agent can be issued either with or independently from an MBean server.

There are two SNMP protocol adaptors: one that supports SNMPv1 and v2, and another introduced in the Java DMK 5.0 that supports SNMPv3 as well as the two previous versions. All features added in the Java DMK 5.0 therefore support SNMPv3 USM MIBs, providing user-based security, and scoped MIBs, that can be registered in the adaptor using a context name. The addition of multithread support in SNMP adaptors and timers in Java DMK 5.0 has also improved the performance of SNMP.

The SNMP protocol adaptors respond to requests in SNMP and translate the requests into management operations on the specific MIB MBeans. The SNMP adaptors also send traps, the equivalent of a JMX agent notification, in response to SNMP events or errors.

The SNMP protocol adaptors can manage an unlimited number of different MIBs. These MIBs can be loaded or unloaded dynamically, by registering and unregistering the corresponding MBeans. The adaptors attempt to respond to an SNMP request by accessing all loaded MIBs. However, MIBs are dynamic only through the agent application, and the SNMP protocol does not support requests for loading or unloading MIBs.

One advantage of the dual JMX–SNMP agent is that MIBs can be loaded dynamically in response to network conditions, or even in response to SNMP requests. Other Java dynamic management applications can also access the MIB through its MBean interface. For example, the value of a MIB variable might be computed in another application and written by a call to the MBean setter.

The SNMP protocol adaptors also send inform requests from an SNMP agent to an SNMP manager. The SNMP manager sends an inform response back to the SNMP agent.

2.7.3 SNMP MIB Compiler – mibgen

The mibgen tool takes as input a set of SNMP MIBs and generates standard MBeans that you can customize. MIBs can be expressed using either structure of management information (SMI) v1 or SMI v2 syntax.

A MIB is like a management interface. It defines what is exposed, but it does not define how to compute the exposed value. Therefore, MBeans generated by mibgen need to be customized to provide the definitive implementation. The MIB is implemented through Java objects, meaning that it has access to all Java runtime libraries and all features of the dynamic agent where it will be instantiated.

The mibgen compiler parses an SNMP MIB and generates the following:

The resulting classes should be made accessible in the agent application. When the single MBean representing the whole MIB is registered in the MBean server, all the associated groups are automatically instantiated and registered as well.

The mibgen compiler supports all data structure of SMI v1 and v2 protocols, including:

The Java DMK also provides an example program, showing how an agent can act as an SNMP master agent to access MIBs implemented remotely in subagents. This allows SNMP managers to access hierarchies of agents through a single master agent. In this way, some MIBs can be implemented by native devices and others can be implemented in JMX agents, yet this heterogeneous architecture is completely transparent to the manager issuing a request.

2.7.4 SNMP Manager API

The SNMP manager API simplifies the development of Java applications for managing SNMP agents. Its classes represent SNMP manager concepts such as sessions, parameters, and peers through Java objects. Using this API, you can develop an application that can issue requests to SNMP agents.

For example, you could create an SNMP resource using the SNMP manager API. You would define a management interface that corresponds to your resource's MIB, in which variables are easily mapped as MBean attributes. In response to calls on the attribute getters and setters, your MBean would construct and issue an SNMP request to the SNMP agent that represents the resource.

The SNMP manager API supports requests in the SNMP v1, v2 or v3 protocol, including inform requests for communicating between SNMP managers. The manager API is used to access any compliant SNMP agent, including those developed with the use of the Java DMK.

2.7.5 SNMPv1 and SNMPv2 Security

Because of backward compatibility, Java DMK 5.1 implements the security aspects of the SNMP protocol v1 and v2. However, you should implement the superior security mechanisms of SNMPv3, which are added in the Java DMK 5.1.

2.7.5.1 SNMPv1 and SNMPv2 Access Control

SNMPv1 and v2 define an access control mechanism similar to password authentication. Lists of authorized manager host names are defined in an access control list (ACL) stored in a file on the agent side, called the IP ACL file. There are no passwords, but logical community names (IP addresses) can be associated with authorized managers to define sets of allowed operations.

The SNMP adaptor performs access control if an ACL file is defined. Because SNMP is a connection—free protocol, the manager host and community are verified with every incoming request. By default, the file is not loaded and any SNMP manager can send requests.

The ACL file is the default access control mechanism in the SNMP protocol adaptor. However, you can replace this default implementation with your own mechanism. For example, if your agent runs on a device with no file system, you could implement access control lists through a simple Java class.

2.7.5.2 SNMPv1 and SNMPv2 Encoding

SNMP requests follow the standardized Basic Encoding Rules (BER) for translating management operations into data packets. At the communication level, an SNMP request is represented by an array of bytes in a UDP protocol packet. The SNMP components in the Java DMK provide access to the byte encoding of these packets.

Your applications can customize the encoding and decoding of SNMP requests, as follows:

2.7.6 SNMPv3 Security

The main addition to Java DMK 5.1 provided by SNMPv3 is the possibility of secure SNMP operation. The SNMPv3 security in Java Dynamic Management Kit 5.1 implements the following SNMP RFCs:

RFC 2571

Architecture

RFC 2572

Message Processing and Dispatching

RFC 2574

USM

The SNMPv3 protocol implementation provides:

Despite the differences between the previous versions of SNMP and SNMPv3, agents in Java DMK 5.1 can respond to requests from any version if the SNMPv3 protocol adaptor is used. SNMP v1 and v2 requests have greater security constraints than v3 requests in an agent compatible with SNMPv3.

The USM MIB is accessible remotely and is not registered to the SNMPv3 adaptor by default.

The USM MIB can be registered in an MBean server, thus making it accessible through the HTML adaptor. This is particularly useful when debugging, although it does create a security risk. Exposing the USM MIB through SNMP without the MBean server, however, is not insecure.

Users can also be configured into an agent by means of an ASCII text file that acts as an initial configuration template for all agents created.

2.7.6.1 SNMPv3 Authentication and Privacy

Inside SNMP domains, every SNMP entity is issued a unique identifier, the engine ID. Java DMK 5.1 provide a set of classes to allow you to generate engine IDs based on, amongst other identifiers, host names, internet protocol (IP) addresses, port numbers and Internet assigned numbers authority (IANA) numbers.

There are two types of SNMP entity:

Authoritative agent entities receive get, set, getnext, and getbulk requests and send traps. Nonauthoritative agents send informs.

Authoritative manager entities receive informs. Nonauthoritative managers send get, set, getnext and getbulk requests and informs, and receive traps. The engine ID and the number of times the engine has booted can be stored and persisted in the SNMPv3 security file, so that the timeliness of the incoming requests can be verified.

Under SNMPv3 there are three levels of security:

Managers and agents are both configured with a username, allowing the manager specific access to that agent. The username has an associated password. Both the agent and the manager sides must be configured according to the desired security policy. For requests to be authenticated, the manager and the agent must share knowledge of the authentication password associated with the username. For requests to be encrypted, the manager and the agent must additionally share knowledge of the privacy password associated with the username.

Unsecured SNMP Requests

When an agent receives a request from a manager, it checks its LCD. If the user is found in the LCD, the request is granted. No timeliness checking is performed, and the content of the request is not encrypted.

Authenticated Requests

The agent checks the identity of the originator of the request as previously described and then checks the timeliness of the request to ensure that it has not been delayed or intercepted for improper purposes. To monitor the timeliness of the arrival of requests, both manager and agent maintain synchronized clocks, and the manager's local notion of the authoritative engine's time of sending is included in the request. If the difference between the time of sending included in the request and the time of receipt recorded by the agent exceeds 150 seconds, then the request is not considered timely and is rejected.

Once the timeliness of the request has been confirmed, the request is authenticated using either of the HMAC-MD5 or HMAC-SHA protocols. These protocols check that the message digest included in the message matches the one computed locally in the receiving agent.

Authenticated and Encrypted Requests

If privacy has been activated, the content of the request is encrypted, using the DES encryption protocol provided by the Java cryptography extension (JCE) from JDK 1.4. The secure hash algorithm (SHA) and MD5 encryption protocols provided in JDK 1.2 are also used. The requests are decrypted and forwarded once the identity of the sender and the timeliness of the request have been established.

Error Messages

If any of the preceding checks fail, one of the following errors will be generated:

unknownUser

Unregistered user

unknownEngineID

Unregistered SNMP entity

encryptionFailed

Encryption error

unsupportedSecurityLevel

Unsupported security level

authentificationFailed

Password error

notInTimeWindow

Timeliness error

Note –

You can optionally implement alternative authentication and encryption algorithms. You cannot, however, plug in customized security or access control models in Java Dynamic Management Kit 5.1, although this will be possible in future versions.

2.7.6.2 SNMPv3 Access Control

SNMPv3 access control differs from the access control defined by versions 1 and 2, in that it is based on contexts and user names, rather than on IP addresses and community strings. The configuration for SNMPv3 access control is located in a text file, called the user ACL file. See the Java Dynamic Management Kit 5.1 Tutorial for information about the user ACL file and how to configure it.

When managers send a requests to an agent, the agent authenticates and, if necessary, decrypts the request, as explained earlier. It then passes the request through SNMP context-checking filters to determine whether it is authorized.

2.7.6.3 SNMPv3 Security Configuration

The configuration for SNMPv3 user-based security is located in a text file, called the security file. Each SNMP engine has its own security file. See the Java Dynamic Management Kit 5.1 Tutorial for information about the user security file and how to configure it.

You can view examples of security files at:

installDir/SUNWjdmk/5.1/examples/current/Snmp