The Simple Network Management Protocol (SNMP)

The Simple Network Management Protocol (SNMP), issued in 1988, was designed to provide an easily implemented, low-overhead foundation for multivendor network management of routers, servers, workstations, and other network resources. The SNMP specification:

· Defines a protocol for exchanging information between one or more management systems and a number of agents

· Provides a framework for formatting and storing management information

· Defines a number of general-purpose management information variables, or objects

The original version of SNMP (now known as SNMPv1) rapidly became the most widely used vendor-independent network management scheme. However, as the protocol gained widespread use, its deficiencies became apparent. These include a lack of manager-to-manager communication, the inability to do bulk data transfer, and a lack of security. All of these deficiencies were addressed in SNMPv2, issued as a set of proposed Internet standards in 1993.

SNMPv2 has not received the acceptance its designers anticipated. While the functional enhancements have been welcome, developers found the security facility for SNMPv2

too complex. Accordingly, the SNMPv2 working group was reactivated to provide a “tune-up” of the SNMPv2 documents. The result of this effort has been one minor success and one major failure. The minor success is the tune-up of the functional

aspects of SNMPv2. The major failure is in the area of security. The working group was unable to resolve the issue, and two competing approaches emerged. With this tune-up,

The functional portion of SNMPv2 progressed from proposed to draft Internet standard status as of 1996. Then, in 1997, work began on SNMPv3, which makes additional minor functional changes and incorporates a new security approach.

This article will provide a survey of SNMPv1 and SNMPv2, and a brief overview of SNMPv3. The article begins with a discussion of basic concepts common to all versions; these concepts define the network management framework that SNMP is designed to support. Then, the operation of SNMPv1 is described. Next, the functional enhancements found in SNMPv2 are discussed. A final section introduces SNMPv3.

NETWORK MANAGEMENT

Nowadays fast developing information technologies make networks more and more complex. We inevitably face a different challenge that how to contend with an ever broadening array of network resources. Network management is a critical solution to enhance the administrative productivity. It evolves making all the components in a consistent manner, monitoring network activity with an outdated protocol analyzer, coping with a distributed database, auto-polling of network devices, and generating real-time graphical views of network topology changes and traffic. In all network management is a service with very broad range that employs a variety of tools, applications and devices to assist network managers in monitoring and maintaining networks.

MAIN FUNCTION OF THE NETWORK MANAGEMENT

According to the definition of Open Systems Interconnect (OSI), the main functions of the network management is FCAPS which is an acronym explained as below:

· Fault management

· Configuration management

· Accounting management

· Performance management

· Security management

The goal of fault management is to detect, log, notify users of, and (to the extent possible) automatically fix network problems to keep the network running effectively. Because faults can cause downtime or unacceptable network degradation, fault management is perhaps the most widely implemented of the ISO network management elements. Fault management deals with the events and traps as they occur on the network, according the related information saved in the Management Information Base to find the wrong point and solve the problems automatically.

Configuration management is perhaps the most important part of the network management because without the ability to manage the configuration of the network we can not realize the real network management. The goal of configuration management is to monitor network and system configuration information so that the effects on network operation of various versions of hardware and software elements can be tracked and managed. All network software and hardware configuration information should be store in a database which allow the dynamic updating and ease access.

Accounting management help we to measure network-utilization parameters so that individual or group uses on the network can be regulated appropriately.
Performance management is to measure and make available various aspects of network performance to maintain the performance of network at an acceptable level. In the field of network management, there are no functional addresses of systems or applications performance management.
The main field of Security management is to monitor and control the access to network resources according to local guidelines so that sensitive network resources can only be accessed by right users. Most network management application only addresses security applicable to network hardware but not really deal with system security.

REQUIREMENT OF NETWORK MANAGEMENT

Network management requires IT professionals to keep network available, run at peak performance, utilize network bandwidth efficiently and all while keep the total cost of network operations under control.

First network management should have the most efficient utilization of the bandwidth of the network. The purpose of using network management system is to protect the most availability of the network and we can not suffer much band utilization of the management system which has bad influence to the application systems on the computer network. Second, network management would have to be extensible. The network architecture was being designed to allow the use of multiple modules that would provide the same or similar services at each layer and to simultaneously support multiple-layer protocols in a network. Therefore, the management architecture transparently assimilates new devices and technologies. The network management architecture had to become as extensible as the network architecture. Finally, since network layer was designed to be an open architecture, management of network layer components would have to be effective in a multivendor network. Our design had to ensure that the ability to provide effective management of network components was independent of the vendors supplying them.

NETWORK MANAGEMENT ARCHITECTURE

The model of network management that is used for SNMP includes the following key elements:

· Management station

· Management agent

· Management information base

· Network management protocol

A Management station is typically a standalone device, but may be a capability implemented on a shared system. In either case, the management station serves as the interface for the human network manager into the network management system.

The management station will have, at minimum:

· A set of management applications for data analysis, fault recovery, and so on.

· An interface by which the network manager may monitor and control the network. That is, the interface between the user and the network management applications enables the user to request actions (monitoring and control) which are

carried out by the management station by communicating with the managed elements of the network.

· A protocol by which the management station and managed entities exchange control and management information.

· A database of information extracted from the management databases of all the managed entities in the network.

That is, the management station maintains at least a summary of the management information maintained at each of the managed elements in the network.

Only the last two elements are the subject of SNMP standardization. The other active element in the network management system is the management agent. Key platforms, such as hosts, bridges, routers, and hubs, may be equipped with SNMP agent software so that they may be managed from a management station. The management agent responds to requests for information from a management station, responds to requests for actions from the management station, and may asynchronously provide the management station with important but unsolicited information. In order to manage the resources in a network, these resources are represented as objects. Each object is, essentially,

A data variable that represents one aspect of the managed system. The collection of objects is referred to as a management information base (MIB). The MIB functions as a collection of access points at the agent for the management station; the agent software maintains the MIB. These objects are standardized across systems of a particular class (e.g., bridges all support the same management objects). In addition, proprietary

extensions can be made. A management station performs the monitoring function by retrieving the value of MIB objects. A management station can cause an action to take

place at an agent or can change the configuration settings of an agent by modifying the value of specific variables.

The management station and agents are linked by a network management protocol, which includes the following key capabilities:

· Get: enables the management station to retrieve the values of objects at the agent

· Set: enables the management station to set the values of objects at the agent

· Trap: enables an agent to notify the management station of significant events

There are no specific guidelines in the standards as to the number of management stations or the ratio of management stations to agents. In general, it is prudent to have at least

two systems capable of performing the management station function, to provide redundancy in case of failure. The other issue is the practical one of how many agents a single management station can handle. As long as SNMP remains relatively “simple,” that number can be quite high, certainly in the hundreds.

SIMPLE NETWORK MANAGEMENT PROTOCOL ARCHITECTURE

SNMP was designed to be an application-level protocol that is part of the TCP/IP protocol suite. As Fig. 1 illustrates, SNMP typically operates over the user datagram protocol (UDP), although it may also operate over TCP. For a standalone management station, a manager process controls access to the central MIB at the management station and provides an interface to the network manager. The manager process achieves

network management by using SNMP, which is implemented on top of UDP, IP, and the relevant network-dependent protocols (e.g., Ethernet, FDDI, X.25). Each agent must also implement SNMP, UDP, and IP. In addition, there is an agent process that interprets the SNMP messages and controls remote access to the agent’s MIB. For an agent device that supports other applications, such as FTP, TCP as well as UDP is required. From a management station, three types of SNMP messages are issued on behalf of a management application: GetRequest, GetNextRequest, and SetRequest. The first two are variations of the get function. All three messages are acknowledged by the agent in the form of a GetResponse message, which is passed up to the management application. In addition, an agent may issue a trap message in response to an event that affects the MIB and the underlying managed resources. SNMP relies on UDP, which is a connectionless protocol, and SNMP is itself connectionless. No ongoing connections are maintained between a management station and its agents. Instead, each exchange is a separate transaction between a management station and an agent.

The above concepts are illustrated in the following diagram:

TRAP-DIRECTED POLLING

If a management station is responsible for a large number of agents, and if each agent maintains a large number of objects, it becomes impractical for the management station to regularly poll all agents for all of their readable object data. Instead, SNMP and the associated MIB are designed to encourage the manager to use a technique referred to as

Trap-directed polling.

The recommended strategy is this. At initialization time, and perhaps at infrequent intervals, such as once a day, a management station can poll all the agents it knows of for

some key information, such as interface characteristics, and perhaps some baseline performance statistics, such as average number of packets sent and received over each interface over a given period of time. Once this baseline is established, the management station refrains from polling. Instead, each agent is responsible for notifying the management station of any unusual event. Examples are if the agent crashes and is

rebooted, the failure of a link, or an overload condition as defined by the packet load crossing some threshold. These events are communicated in SNMP messages known as traps.

Once a management station is alerted to an exception condition, it may choose to take some action. At this point, the management station may direct polls to the agent reporting the event and perhaps to some nearby agents in order to diagnose any problem and to gain more specific information about the exception condition. However, because traps are communicated via UDP and are therefore delivered unreliably, a management station may wish to infrequently poll agents. Trap-directed polling can result in substantial savings of network capacity and agent processing time. In essence, the network is not made to carry management information that the management station does not need, and agents are not made to respond to frequent requests for uninteresting information.

PROXIES

The use of SNMP requires that all agents, as well as management stations, must support UDP and IP. This limits direct management to such devices and excludes other devices, such as some bridges and modems that do not support any part of the TCP/IP protocol suite. Furthermore, there may be numerous small systems (personal computers, workstations, programmable controllers), that do implement TCP/IP to support their applications, but for which it is not desirable to add the additional burden of SNMP, agent logic, and MIB maintenance.

To accommodate devices that do not implement SNMP, the concept of proxy was developed. In this scheme an SNMP agent acts as a proxy for one or more other devices; that is, the SNMP agent acts on behalf of the proxied devices. Figure 2 indicates the type of protocol architecture that is often involved. The management station sends queries concerning a device to its proxy agent. The proxy agent converts each query into the management protocol that is used by the device. When a reply to a query is received by the agent, it passes that reply back to the management station. Similarly, if an event notification of some sort from the device is transmitted to the proxy, the proxy sends that on to the management station in the form of a trap message.

OVERVIEW OF SNMPV1

SNMP BASIC COMMANDS

Managed devices are monitored and controlled using four basic SNMP commands

1. Read

2. Write

3. Trap

4. Traversal operations.

The read command is used by an NMS to monitor managed devices. The NMS examines different variables that are maintained by managed devices.

The write command is used by an NMS to control managed devices. The NMS changes the values of variables stored within managed devices.

The trap command is used by managed devices to asynchronously report events to the NMS. When certain types of events occur, a managed device sends a trap to the NMS.

Traversal operations are used by the NMS to determine which variables a managed device supports and to sequentially gather information in variable tables, such as a routing table.

SNMP MANAGEMENT INFORMATION BASE

A Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network-management protocol such as SNMP. They are comprised of managed objects and are identified by object identifiers.

A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of specific characteristics of a managed device. Managed objects are comprised of one or more object instances, which are essentially variables.

Two types of managed objects exist:

1. scalar

2. tabular.

Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped in MIB tables.

An example of a managed object is atInput, which is a scalar object that contains a single object instance, the integer value that indicates the total number of input AppleTalk packets on a router interface.

An object identifier (or object ID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. Figure 56-3 illustrates the MIB tree.

The top-level MIB object IDs belong to different standards organizations, while lower-level object IDs are allocated by associated organizations.

Vendors can define private branches that include managed objects for their own products. MIBs that have not been standardized typically are positioned in the experimental branch.

The managed object atInput can be uniquely identified either by the object name?iso.identified- organization.dod.internet.private.enterprise.cisco.temporary variables.AppleTalk.atInput? or by the equivalent object descriptor, 1.3.6.1.4.1.9.3.3.1.

Figure: The MIB Tree Illustrates the Various Hierarchies Assigned by Different Organizations

SNMP AND DATA REPRESENTATION

SNMP must account for and adjust to incompatibilities between managed devices. Different computers use different data representation techniques, which can compromise the capability of SNMP to exchange information between managed devices. SNMP uses a subset of Abstract Syntax Notation One (ASN.1) to accommodate communication between diverse systems.

SNMP VERSION 1

SNMP version 1 (SNMPv1) is the initial implementation of the SNMP protocol. It is described in Request For Comments (RFC) 1157 and functions within the specifications of the Structure of Management Information (SMI). SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk Datagram- Delivery Protocol (DDP), and Novell Internet Packet Exchange (IPX). SNMPv1 is widely used and is the de facto network-management protocol in the Internet community.

SNMPv1 and Structure of Management Information

The Structure of Management Information (SMI) defines the rules for describing management information, using Abstract Syntax Notation One (ASN.1). The SNMPv1 SMI is defined in RFC 1155. The SMI makes three key specifications: ASN.1 data types, SMI-specific data types, and SNMP MIB tables.

SNMPv1 and ASN.1 Data Types

The SNMPv1 SMI specifies that all managed objects have a certain subset of Abstract Syntax Notation One (ASN.1) data types associated with them. Three ASN.1 data types are required: name, syntax, and encoding. The name serves as the object identifier (object ID). The syntax defines the data type of the object (for example, integer or string). The SMI uses a subset of the ASN.1 syntax definitions. The encoding data describes how information associated with a managed object is formatted as a series of data items for transmission over the network.

SNMPv1 and SMI-Specific Data Types

The SNMPv1 SMI specifies the use of a number of SMI-specific data types, which are divided into two categories: simple data types and application-wide data types.

Three simple data types are defined in the SNMPv1 SMI, all of which are unique values: integers, octet strings, and object IDs. The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647. Octet strings are ordered sequences of 0 to 65,535 octets. Object IDs come from the set of all object identifiers allocated according to the rules specified in ASN.1.

Seven application-wide data types exist in the SNMPv1 SMI:

1. network addresses

2. counters

3. gauges

4. time ticks

5. opaques,

6. integers

7. unsigned integers.

Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32-bit IP addresses. Counters are non-negative integers that increase until they reach a maximum value and then return to zero. In SNMPv1, a 32-bit counter size is specified. Gauges are non-negative integers that can increase or decrease but that retain the maximum value reached. A time tick represents a hundredth of a second since some event. An opaque represents an arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the SMI. An integer represents signed integer-valued information. This data type redefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI. An unsigned integer represents unsigned integer-valued information and is useful when values are always non-negative. This data type redefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI.

SNMP MIB Tables

The SNMPv1 SMI defines highly structured tables that are used to group the instances of a tabular object (that is, an object that contains multiple variables). Tables are composed of zero or more rows, which are indexed in a way that allows SNMP to retrieve or alter an entire row with a single Get, GetNext, or Set command.

SNMPv1 Protocol Operations

SNMP is a simple request/response protocol. The network-management system issues a request, and managed devices return responses. This behavior is implemented by using one of four protocol operations: Get, GetNext, Set, and Trap. The Get operation is used by the NMS to retrieve the value of one or more object instances from an agent. If the agent responding to the Get operation cannot provide values for all the object instances in a list, it does not provide any values. The GetNext operation is used by the NMS to retrieve the value of the next object instance in a table or a list within an agent. The Set operation is used by the NMS to set the values of object instances within an agent. The Trap operation is used by agents to asynchronously inform the NMS of a significant event.

LIMITATIONS OF SNMPV1

This chapter summarizes the deficiencies perceived in the SNMPv1 framework in the past years.

The deficiencies that will be dealt with in this chapter are:

_ the severe security limitations,
_ the waste of bandwidth when retrieving large amounts of data,
_ there is no communication defined between managers,
_ the standards make minimal use of formal structures,
_ there are only very limited protocol operations available,
_ there is no uniform table accessing mechanism,
_ there are only a limited number of error codes defined

Security Limitations

The information added in the message consists of a version number and a group-identification key (called a community). The security mechanism that uses these communities is known as the trivial authentication mechanism. This means that the community name is placed, in the clear, in the message. This community name is used in the authentication mechanism to identify different parties. A community is defined to be a relationship between an agent and one or more managers. The agent uses the community name to grant the sending party certain privileges. Once a message is authorized, i.e. the sending party of a message uses a valid community name, the agent creates an access environment in which the request will be processed. Note that an agent does not validate whether the sending manager should be using this community. In fact, the identity of the manager is not checked at all!

This implies that knowing a valid community name is a potential dangerous situation. Since the community name is not encrypted, a straight forward eavesdropping tool could be used to discover this secret. Devin, Galvin & McCloghrie (1991) identify the following threats:

_ Masquerade. The SNMP administrative model includes a model of access control. Access

control necessarily depends on knowledge of the origin of the message. The masquerade

Threat is the danger that management operations which are not authorized for some party,

may be attempted by that party by assuming the identity of an administratively distinct

party that is authorized for the management operation.

_ Modification of information. The SNMP protocol provides the means for management

stations to interrogate and to manipulate the value of objects in a managed agent. The

modification threat is the danger that some party may alter in-transit messages generated by an authorized party in such a way as to affect unauthorized management operations,

including falsifying the value of an object.

_ Disclosure of information. The disclosure threat is the danger of eavesdropping on the

exchanges between managed agents and a management station. Protecting against this

Threat is mandatory when the SNMP is used to administer private parameters on which its

security is based. (Protecting against this disclosure threat may also be required as a matter of local policy.)

_ Message sequencing. The SNMP protocol is based upon connection-less transport services. The message sequencing threat is the danger that messages may be arbitrarily re-ordered, delayed or replayed to effect unauthorized management operations. This threat may arise either by the work of a malicious attacker or by the natural operation of a sub network service.

_ Denial of service. The denial of service threat is the danger that an active eavesdropper will prevent exchanges between managed agents and a management station.

_ Traffic analysis. The traffic analysis threat is the danger that a passive eavesdropper will

infer information from the exchanges between managed agents and a management station, which may be protected from disclosure, to which the eavesdropper is not authorized.

From these definitions, it is clear that the trivial authentication mechanism used in SNMPv1does not provide any real protection against any of these threats.

Waste of Bandwidth

The SNMPv1 protocol consists of two retrieval operators, i.e. the get-request and the get-nextrequest. The get-request attempts to retrieve for every object identifier in the variable bindings list its value. If the agent does not support the variable (in that community view) or the object identifier does not identify a leaf object, the request will fail. The get-next-request on the other hand attempts to retrieve for every object identifier in the variable bindings list the name and value of the lexicographical successor. This request will only fail if there is no lexicographical successor (this is the case when the request addresses an object that exceeds the end of the MIB in that community view). Although the get-next-request is considered to be much more powerful than the get-request, both operators work sequentially on the variables identified in the variable bindings list. So if a manager wishes to retrieve an entire table from an agent it is faced with the problem that it

has to name every row instance it wants to retrieve. However, in most cases the manager does not know the name of every row instance. The only available solution is to successively use the get-next operator to retrieve the next row entry in the table.

No Communication Between Managers

Depending on the size of a network, one could want to divide the manager’s tasks over several management stations. Ideally one would want one high-level manager to which the other lower-level managers report only extra-ordinary events and status reports, thereby hiding unnecessary information from the high-level manager. This is extremely useful in a geographically diverse network, in order to minimize unnecessary network traffic. In the current framework however, this is not possible since communication between managers is not defined. It is only possible for a manager to communicate with several agents, and one agent can be managed by several managers. So the only means of structuring with the current framework is to have several managers each manage different aspects in several agents, which has no positive effect on network traffic. Moreover, there is no suitable mechanism defined that provides for multiple managers (nor agents as a matter of fact) to reside on the same platform. An additional problem is the excessive use of polling within the current framework, since the managers have to query their agents regularly in order to stay up to date. The use of traps by

agents to inform a manager of some situation is strongly discouraged and should only be used for exceptions, moreover its possibilities are rudimentary.

The Standards Use Few Structuring Techniques

Since one of the main goals of the SMNP standards is that they should be expandable in the future, the management framework has to provide the means to do this. This means that the management framework has to describe how additional information modules (MIBs) have to be structured. The contents, capabilities, compliance, etc. should be uniformly defined.

Communication Between Managers

We already discussed the need for communication between managers. However no attention was paid on the kind of information that would be transmitted, nor on the

mechanism needed for the transmission of said information. The manager that has the task of monitoring a set of agents will inform another manager if the information is of interest to said manager (e.g. because certain conditions have occurred). This way of providing information to a manager is slightly comparable to the trap, only now generated by another manager. However, traps were originally designed to indicate extra-ordinary events, and are therefore not suitable for use between managers. Besides, traps are always unconfirmed, whereas all other operations initiated by a manager are always confirmed. This suggests an additional protocol operation.

No Uniform Table Accessing Mechanism

In general, accessing a table entry is no different from accessing an object identifier. The same set-request, get-request, and get-next-request operators have to be used to access the entry. It was already mentioned that although the get-request and get-next-request operator do not have any bugs, they are not efficient when retrieving large amounts of data. Problems do arise when creating, updating or deleting table entries, especially when multiple managers are involved. There was no mechanism defined to regulate multiple managers accessing the same entry.

Limited Number of Error Codes

The original protocol defined only a few error codes (i.e. noError, tooBig, noSuchName,

badValue, readOnly1, and genErr). The return of one of these values was often ambiguous, thereby leaving the manager in the dark as to the cause of the error. In many cases the manager had to successively request parts of the original request, in order to discover the problem. It is clear that adding new error codes makes it much easier for a manager to understand what went wrong. In most cases the additional overhead in the agent is small, the state in the agent where the error occurred often contained all the information needed to result in a descriptive error code if it had been available.

Engineering Seminar Topics :: Seminar Paper