This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth.
In typical SNMP use, one or more administrative computers called managers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system executes, at all times, a software component called an agent which reports information via SNMP to the manager.
Essentially, SNMP agents expose management data on the managed systems as variables. The protocol also permits active management tasks, such as modifying and applying a new configuration through remote modification of these variables. The variables accessible via SNMP are organized in hierarchies. These hierarchies, and other metadata (such as type and description of the variable), are described by Management Information Bases (MIBs).
Three versions of SNMP exist: SNMP version 1 (SNMPv1) , SNMP version 2 (SNMPv2) and SNMP Version 3 (SNMPv3). Both version1 and 2 have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. SNMPv3 primarily added security and remote configuration enhancements to SNMP.
A managed device is a network node that contains an SNMP agent and that resides on a managed network. Managed devices collect and store management information and make this information available to NMSs using SNMP. Managed devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, computer hosts, or printers.
An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP.
An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network. NMS is usually a software program running on a workstation or larger computer that communicates with agent processes that run on each device being monitored. An NMS is responsible for polling and receiving traps from agents in network. In network management context, a poll is the act of querying an agent (router, switch etc.) for some information. On the other hand, a trap is a way for agent to tell NMS that something has happened.Traps being sent asynchronously, not in response to queries from NMS. NMS then is further responsible to perform an action based on information received from agent. One or more NMSs must exist on any managed network. Other functionalities of the NMS include reporting features, network topology mapping and documenting, tools to allow user to monitor the traffic on your network, and so on. Some management consoles can also produce trend analysis reports. These types of reports can help in capacity planning and set long-range goals. Illustration of the relationships of these three components will be shown in Figure 2. Meanwhile, Figure 2 will show the SNMP operation.
Figure 2 A SNMP-Managed Networks Consists of Managed Devices, Agents, and NMSs
As mentioned above, manager is generally the 'main' station while agents can be found on switches, firewalls, servers, wireless access points, routers, hubs, and even users' workstations. As seen in the illustration, the manager polls the agents making requests for information, and the agents respond when asked with the information requested.
According to (3), SNMP has seven types of packets. The six messages are from an initiator whereby the seventh message is response message.
Requests the value of one or more variable
Sent by an NMS to an agent to collect a management parameters
Requests the variable following this one
Requests the variable following parameter in a list or table of parameters
Fetches a large table
Sent by an NMS to retrieve large blocks of data, such as multiple rows in a table
Updates one or more variables.
Sent by an NMS to an agent to configure a parameter on a managed device
Manager-to-manager message describing local MIB
Sent by an NMS to notify another NMS of information in a MIB view that is remote to the receiving application
Agent-to-manager trap report
Sent autonomously (not in response to a request) by an agent to an NMS to notify the NMS of an event
Sent by an agent to an NMS in response to a request
1.2. SNMP Basic Commands
Managed devices are monitored and controlled using four basic SNMP commands:
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.
1.3 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:
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 at Input, 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 at Input can be uniquely identified either by the object name-iso.identified-organization.dod.internet.private.enterprise.cisco.temporary variables. Apple Talk. At Input-or by the equivalent object descriptor, 220.127.116.11.18.104.22.168.3.1.
Figure 4 The MIB Tree Illustrates the Various Hierarchies Assigned by Different Organizations
1.4. Before and after SNMP:
Consider the environment of the network with 100 machines running with various operating systems. Several machines are application and databases servers and the rest are PC. On top of that, various switches and routers keep the network going. Suddenly, the database server crashes and it happens over the weekend and everyone including the administrator definitely not in the office. How about the data need to be restoring to keep the system running smoothly before the weekday started? This is where SNMP comes in. Instead of waiting for an angel to notice something is going wrong behind the scene and the need to locate the responsible person to fix the problem just in time, SNMP allows for monitoring network constantly even when nobody is around. For example, SNMP will notice if number of bad packets coming through one of the router's interface is increasing as indicator for the router to fail. Therefore, arrangement can be made to fix the router before it actually turns down. Notification also can be arrange before some application get hang and the administrator will be able to fix it from home. SNMP definitely will help much in fixing the problems before it occurs because it enables users to keep logs that prove the network is running reliably and show the action taken to avert an impending crisis.
1.5. 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.
2.0 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.
2.1. 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.
2.1.1. 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.
2.1.2 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: network addresses, counters, gauges, time ticks, opaque, integers, and 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.
2.1.3 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.
2.2. SNMP V1 message format:
The SNMP general message format first used to define the format of messages in the original SNMP Protocol, SNMP version 1 (SNMP v1). This first version of SNMP is probably best known for its relative simplicity, compared to the versions that followed it. This is reflected in its message format, which is quite straight-forward.
The general message format in SNMPv1 is a "wrapper" consisting of a small header and an encapsulated PDU. Not very many header fields were needed in SNMPv1 because the community-based security method in SNMPv1 is very rudimentary.
A SNVPv1 Message Consists of a Header and a PDU
2.2.1 SNMPv1 Message Header
SNMPv1 message headers contain two fields: Version Number and Community Name.
The following descriptions summarize these fields:
â€¢Version number-specifies the version of SNMP used.
â€¢Community name-defines an access environment for a group of NMSs. NMSs within the community are said to exist within the same administrative domain. Community names serve as a weak form of authentication because devices that do not know the proper community name are precluded from SNMP operations.
The format and figure of the SNMP V1 message
Figure5: General Message Format
2.3. SNMP v1 PDU Format:
The message format for all versions of SNMP is similar except PDU. And all of the PDUs in SNMPv1 have the same format, with one exception: Trap-PDU.
The PDU (Protocol Data Unit) for SNMPv1 have five different PDU types:
Retrieve the value of a variable or list of variables. Desired variables are specified in variable bindings (values are not used). Retrieval of the specified variable values is to be done as an atomic operation
by the agent. A Response with current values is returned.
Change the value of a variable or list of variables. Variable bindings are specified in the body of the request. Changes to all specified variables are to be made as an atomic operation by the agent. A Response with (current) new values for the variables is returned.
Returns a Response with variable binding for the lexicographically next variable in the MIB .The entire MIB of an agent can be walked by iterative application of GetNextRequest starting at OID 0. Rows of a table can be read by specifying column OIDs in the variable bindings of the request.
Returns variable bindings and acknowledgement for GetRequest, SetRequest, GetNextRequest, GetBulkRequest and InformRequest. Error reporting is provided by error-status and error-index fields. Although it was used as a response to both gets and sets, this PDU was called GetResponse in SNMPv1.
Asynchronous notification from agent to manager.Includes current sysUpTime value,an OID identifying the type of trap and optional variable bindings. Destination addressing for traps is determined in an application specific manner typically through trap configuration variables in the MIB. The format of the trap message was changed in SNMPv2 and the PDU was renamed SNMPv2-Trap.
The common format for GetRequest, GetNextRequest, GetResponse and SetRequest PDUs
PDU type- Specifies the type of PDU transmitted: 0 GetRequest, 1 GetNextRequest, 2 GetResponse and 3 SetRequest.
Request ID- Associates SNMP requests with responses.
Error status- Indicates one of a number of errors and error types. Only the response operation sets this field. Other operations set this field to zero.
Error index- Associates an error with a particular object instance. Only the response operation sets this field. Other operations set this field to zero.
Variable bindings- Serves as the data field of the SNMPv1 PDU. Each variable binding associates a particular object instance with its current value (with the exception of Get and GetNext requests, for which the value is ignored).
Figure 6: SNMPv1 Common PDU Format
2.4. SNMP v1 Trap-PDU Format:
The format of the Trap-PDU is shown in table and figure below.
PDU type --Specifies the type of PDU (4=Trap).
Enterprise -- Identifies the management enterprise under whose registration authority the trap was defined.
Agent address- - IP address of the agent, used for further identification.
Generic trap type -- Field describing the event being reported.
Specific trap type -- Used to identify a non-generic trap when the Generic Trap Type is enterprise specific.
Timestamp -- Value of the sysUpTime object, representing the amount of time elapsed between the last (re-)initialization and the generation of that Trap.
Figure 7 SNMPv1 Trap-PDU Format
3.0. SNMP Version 2
SNMP version 2 (SNMPv2) is an evolution of the initial version, SNMPv1. Originally, SNMPv2 was published as a set of proposed Internet standards in 1993; currently, it is a draft standard. As with SNMPv1, SNMPv2 functions within the specifications of the Structure of Management Information (SMI). In theory, SNMPv2 offers a number of improvements to SNMPv1, including additional protocol operations.
The main problem of the version 1 is the authentication of the messages source, protecting these messages from disclosure and placing access controls on MIB database. Those problems are solved in SNMPv2. They required significant changes to the format of SNMP PDUs. Two new protocol operations have been added. In version 1, traps had a different format than all of other PDUs.
3.1. SNMPv2 and Structure of Management Information
The Structure of Management Information (SMI) defines the rules for describing management information, using ASN.1.
The SNMPv2 SMI is described in RFC 1902. It makes certain additions and enhancements to the SNMPv1 SMI-specific data types, such as including bit strings, network addresses, and counters. Bit strings are defined only in SNMPv2 and comprise zero or more named bits that specify a value. Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32-bit IP addresses, but SNMPv2 can support other types of addresses as well. 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. In SNMPv2, 32-bit and 64-bit counters are defined.
3.2. SMI Information Modules
The SNMPv2 SMI also specifies information modules, which specify a group of related definitions. Three types of SMI information modules exist:
MIB modules contain definitions of interrelated managed objects. Compliance statements provide a systematic way to describe a group of managed objects that must be implemented for conformance to a standard. Capability statements are used to indicate the precise level of support that an agent claims with respect to a MIB group. An NMS can adjust its behaviour toward agents according to the capabilities statements associated with each agent.
3.3. SNMPv2 Protocol Operations
The Get, GetNext, and Set operations used in SNMPv1 are exactly the same as those used in SNMPv2. However, SNMPv2 adds and enhances some protocol operations. The SNMPv2 Trap operation, for example, serves the same function as that used in SNMPv1, but it uses a different message format and is designed to replace the SNMPv1 Trap.
SNMPv2 also defines two new protocol operations: GetBulk and Inform. The GetBulk operation is used by the NMS to efficiently retrieve large blocks of data, such as multiple rows in a table. GetBulk fills a response message with as much of the requested data as will fit. The Inform operation allows one NMS to send trap information to another NMS and to then receive a response. In SNMPv2, if the agent responding to GetBulk operations cannot provide values for all the variables in a list, it provides partial results.
3.4 SNMP Management
SNMP is a distributed-management protocol. A system can operate exclusively as either an NMS or an agent, or it can perform the functions of both. When a system operates as both an NMS and an agent, another NMS might require that the system query manage devices and provide a summary of the information learned, or that it report locally stored management information.
3.5 SNMP Security
SNMP lacks any authentication capabilities, which results in vulnerability to a variety of security threats. These include masquerading occurrences, modification of information, message sequence and timing modifications, and disclosure. Masquerading consists of an unauthorized entity attempting to perform management operations by assuming the identity of an authorized management entity. Modification of information involves an unauthorized entity attempting to alter a message generated by an authorized entity so that the message results in unauthorized accounting management or configuration management operations. Message sequence and timing modifications occur when an unauthorized entity reorders, delays, or copies and later replays a message generated by an authorized entity. Disclosure results when an unauthorized entity extracts values stored in managed objects, or learns of notifiable events by monitoring exchanges between managers and agents. Because SNMP does not implement authentication, many vendors do not implement Set operations, thereby reducing SNMP to a monitoring facility.
3.6 SNMP Interoperability
As presently specified, SNMPv2 is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2 messages use different header and protocol data unit (PDU) formats than SNMPv1 messages. SNMPv2 also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 1908 defines two possible SNMPv1/v2 coexistence strategies: proxy agents and bilingual network-management systems.
An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as follows:
â€¢An SNMPv2 NMS issues a command intended for an SNMPv1 agent.
â€¢The NMS sends the SNMP message to the SNMPv2 proxy agent.
â€¢The proxy agent forwards Get, GetNext, and Set messages to the SNMPv1 agent unchanged.
â€¢GetBulk messages are converted by the proxy agent to GetNext messages and then are forwarded to the SNMPv1 agent.
The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS.
Bilingual Network-Management System
Bilingual SNMPv2 network-management systems support both SNMPv1 and SNMPv2. To support this dual-management environment, a management application in the bilingual NMS must contact an agent. The NMS then examines information stored in a local database to determine whether the agent supports SNMPv1 or SNMPv2. Based on the information in the database, the NMS communicates with the agent using the appropriate version of SNMP.
3.7. SNMPv2 Message Format
SNMPv2 messages consist of a header and a PDU. Figure 6 illustrates the basic format of an SNMPv2 message.
SNMPv2 Messages Also Consist of a Header and a PDU
SNMPv2 Message Header
SNMPv2 message headers contain two fields: Version Number and Community Name.
The following descriptions summarize these fields:
â€¢Version number-specifies the version of SNMP that is being used.
â€¢Community name-defines an access environment for a group of NMSs. NMSs within the community are said to exist within the same administrative domain. Community names serve as a weak form of authentication because devices that do not know the proper community name are precluded from SNMP operations.
For SNMPv2, Get, GetNext, Inform, Response, Set and Trap PDU have the following format:
PDU type: Identifies the type of PDU transmitted (Get, GetNext, Inform, Response, Set or Trap
Request ID: Associates SNMP requests with responses.
Error status: Indicates one of the numbers of error and error types. Only the response operation sets this field. Other operations set this field zero.
Error Index: Associates an error with a particular object instance. Only the response operation sets this field. Other operations set this field to zero.
Variable binding: Serves as the data field (value 1, value 2â€¦) of the SNMPv2 PDU. Each variable binding associates a particular object instance with its current value.
3. 8. SNMPv2 GetBulk PDU Format:
PDU types: Identifies the PDU as a GetBulk operations
Request ID: Associates SNMP requests with responses.
Non repeaters: Specifies the number of object instance in the variable binding's field that should be retrieved no more than once from the beginning of request.
Max repetitions: Defines the maximum number of times that other variables beyond those specified by the Non repeaters should be retrieved.
Variable binding: Serves as the data field (Obj 1, Obj 2â€¦) of the SNMPv2 PDU. Each variable binding associates a particular object instance with its current value.
3.9. SNMP v2 Operations:
- NOTIFICATION (SNMP v2 & v3)
- INFORM (V2 & V3)
- REPORT (V2 & V3)
Get operation: The get request is initiated by the NMS, which sends the request to the agent. The agent receives the request and processes. Some devices that are under heavy load, such as routers, may not be able to respond to the request and will have to drop it. If the agent is successful in gathering the requested information, it sends a get-response back to the NMS, where it is processed.
Get - next operation: The get-next operation allows sequence of commands to retrieve a group of values from MIB. The get-next command traverses a subtree in lexicographic order. Since an OID is a sequence of integers, it's easy for an agent to start at the root of its SMI object tree and work its way down until it finds the OID it is looking for. When the NMS receives a response from the agent for the next-get command it just issued, it issued another get-next command. It keeps doing this until the agent returns an error, signifying that the end of the MIB has been reached and there are no more objects left to get.
Get- bulk operation: Get-bulk operation allows a management application to retrieve a large section of a table at once. The standard get operation can attempt to retrieve more than one MIB object at once, but messages sizes are limited by the agent's capabilities. If the agent can't return all the requested responses, it returns an error messages with no data. The get-bulk operation also tells the agents to send as much of the response back as it can.
Set operation: The set command is used to change the value of a managed object or to create a new row in a table. Objects that are defined in the MIB as read-write or write-only can be created using this command. It is possible for an NMS to set more than one object at a time.
SNMP trap: A trap is a way for an agent to tell the NMS that something bad has happened. The trap originates from the agent itself. The trap destination is typically the IP address of the NMS. No acknowledgement is sent from the NMS to the agent, so the agent has no way of knowing if the trap makes it to the NMS. Here are a few situations that a trap might report:
A network interface on the device (where the agent is running) has gone down.
A network interface on the device (where the agent is running) has come back up.
An incoming call to a modem rack was unable to establish a connection to a modem.
The fan on a switch or router has failed.
In an effort to standardize the PDU format of SNMP traps, SNMPv2 defines a NOTIFICATION-TYPE. The PDU format for NOTIFICATION-TYPE is identical to that for get and set.
SNMPv2 provides an inform mechanism, which allows for manager-to-manager communication. This operation can be useful when the need arises for more than one NMS in the network. When an inform is sent from one NMS to another, the receiver sends a response to the sender acknowledging receipt of the event.
The report operation was defined in the draft version SNMPv2 but never implemented. It is now part of the SNMPv3 specification and is intended to allow NMP engines to communicate with each other.
4.0. SNMP Version 3
Previous SNMPv1 or SNMPv2 didn't offer security features. Specifically, SNMP v1 or v2 can neither authenticate the source of a management message nor provide encryption. Without authentication, it is possible for nonauthorized users to exercise SNMP network management functions. It is also possible for nonauthorized users to eavesdrop on management information as it passes from managed systems to the management system. Because of this lack of security, many SNMPv1 or v2 implementations are limited to simply a read-only capability, reducing their utility to that of a network monitor; no network control applications can be supported. SNMPv3 primarily added security and remote configuration enhancements to SNMP.
SNMPv3 provides important security features:
Confidentiality - Encryption of packets to prevent snooping by an unauthorized source.
Integrity - Message integrity to ensure that a packet has not been tampered with in transit.
Authentication - to verify that the message is from a valid source.
SNMP V3 is also including three important services:
SNMPv3 introduces the concept of a principal, which is the entity on whose behalf services are provided or processing takes place. A principal can be an individual acting in a particular role or a set of individuals, where each acting in a particular role and also an application or set of applications or combinations thereof. In essence, a principal operates from a management station and issues SNMP commands to agent systems. The identity of the principal and the target agent together determine the security features that will be invoked, including authentication, privacy, and access control. The use of principals allows security policies to be tailored to the specific principal, agent, and information exchange, and gives human security managers considerable flexibility in assigning network authorization to users.
Figure 8 SNMPv3 Security Features
SNMPv3 is defined in a modular architecture, as shown in above Figure. Each SNMP entity includes a single SNMP engine. An SNMP engine implements functions for sending and receiving messages, authenticating and encrypting/decrypting messages, and controlling access to managed objects. These functions are provided as services to one or more applications that are configured with the SNMP engine to form an SNMP entity. This modular architecture provides several advantages. First, the role of an SNMP entity is determined by the modules that are implemented in that entity. For example, a certain set of modules is required for an SNMP agent, whereas a different (though overlapping) set of modules is required for an SNMP manager. Second, the modular structure of the specification lends itself to defining different versions of each module. This, in turn, makes it possible to define alternative or enhanced capabilities for certain aspects of SNMP without needing to go to a new version of the entire standard (for example, SNMPv4), and clearly specify coexistence and transition strategies.
4.1. SNMP v3 Message Processing:
SNMPv3 relies on the User Datagram Protocol (UDP) or some other transport-layer protocol to convey SNMP information. SNMP functionality is organized into two application-level layers:
PDU processing layer.
Message processing layer.
At the PDU processing layer, management commands (such as Get, Set, Trap, Inform) are realized in a PDU that includes an indication of the command type and a list of variables (management objects) to which the command refers. This PDU is then passed down to the message processing layer, which adds a message header. The message header contains security-related information that may be used for authentication and privacy operations.
Next figure shows the message structure. The first five fields are generated by the message processing model on outgoing messages and processed by the message processing model on incoming messages. The next six fields show security parameters used by the security model, which is invoked by the message processing model to provide security services. Finally, the PDU, together with the context Engine ID and context Name, constitute a scoped PDU, used for PDU processing.
Figure 9 SNMPv3 Message Format with User-Based Security Model
4.2. User Based Security Model
The User-Based Security Model (USM) uses the concept of an authoritative engine. In any message transmission, one of the two entities, transmitter or receiver, is designated as the authoritative SNMP engine, according to the following rules:
When an SNMP message contains a payload that expects a response (for example, a Get, Get Next, Get Bulk, Set, or Inform 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.
Thus, for messages sent on behalf of a Command Generator and for Inform messages from a Notification Originator, the receiver is authoritative. For messages sent on behalf of a Command Responder or for Trap messages from a Notification Originator, the sender is authoritative. This designation serves two purposes:
The timeliness of a message is determined with respect to a clock maintained by the authoritative engine. When an authoritative engine sends a message (Trap, Response, Report), it contains the current value of its clock, so that the nonauthoritative recipient can synchronize on that clock. When a nonauthoritative engine sends a message (Get, GetNext, GetBulk, Set, Inform), it includes its current estimate of the time value at the destination, allowing the destination to assess the timeliness of the message.
A key localization process, described later, enables a single principal to own keys stored in multiple engines; these keys are localized to the authoritative engine in such a way that the principal is responsible for a single key but avoids the security risk of storing multiple copies of the same key in a distributed network. When an outgoing message is passed to the USM by the Message Processor, the USM fills in the security-related parameters in the message header. When an incoming message is passed to the USM by the Message Processor, the USM processes the values contained in those fields.
4.3. Secret-Key Authentication
The authentication mechanism in SNMPv3 assures that a received message which is transmitted by the principal whose identifier appears as the source in the message header. In addition, this mechanism assures that the message was not altered in transit and that it was not delayed or replayed.
In authentication process, each pair of principal and remote SNMP engines that wishes to communicate must share a secret authentication key. The sending entity provides authentication by including a message authentication code with the SNMPv3 message it is sending. This code is a function of the contents of the message, the identity of the principal and engine, the time of transmission, and a secret key that should be known only to the sender and the receiver. The secret key must initially be set up outside of SNMPv3 as a configuration function. That is, the configuration manager or network manager is responsible for distributing initial secret keys to be loaded into the databases of the various SNMP managers and agents.
This can be done by using some form of secure data transfer outside of SNMPv3. When the receiving entity gets the message, it uses the same secret key to calculate the message authentication code again. If the receiver's version of the code matches the value appended to the incoming message, then the receiver knows that the message can only have originated from the authorized manager, and that the message was not altered in transit. The shared secret key between sending and receiving parties must be preconfigured. USM is responsible for assuring that messages arrive within a reasonable time window to protect against message delay and replay attacks. Two functions support this service are synchronization and time-window checking.
Each authoritative engine maintains two values, SNMP Engine Boots and SNMP Engine Time, which keep track of the number of boots since initialization and the number of seconds since the last boot. These values are placed in outgoing messages in the field msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime. A nonauthoritative engine maintains synchronization with an authoritative engine by maintaining local copies of snmpEngineBoots and snmpEngineTime for each remote authoritative engine with which it communicates. These values are updated on receipt of an authentic message from the remote authoritative engine. Between these message updates, the non-authoritative engine increments the value of snmpEngineTime for the remote authoritative engine to maintain loose synchronization. These values are inserted in outgoing messages intended for that authoritative engine.
When an authoritative engine receives a message, it compares the incoming boot and time values with its own boot and time values. If the boot values match and if the incoming time value is within 150 seconds of the actual time value, then the message is declared to be within the time window and, therefore, to be a timely message.
4.4. SNMP v3 Privacy:
The SNMPv3 USM privacy facility enables managers and agents to encrypt messages to prevent eavesdropping by third parties. Again, manager entity and agent entity must share a secret key. When privacy is invoked between a principal and a remote engine, all traffic between them is encrypted using the Data Encryption Standard (DES). The sending entity encrypts the entire message using the DES algorithm and its secret key, and sends the message to the receiving entity, which decrypts it using the DES algorithm and the same secret key. Again, the two parties must be configured with the shared key.
The cipher-block-chaining (CBC) mode of DES is used by USM. This mode requires that an initial value (IV) be used to start the encryption process. The msgPrivacyParameters field in the message header contains a value from which the IV can be derived by both sender and receiver.
4.5. View-Based Access Control Model (VACM):
The access control facility allows us to configure agents to provide different levels of access to the agent's MIB to different managers. An agent entity can restrict access to its MIB for a particular manager entity in two ways. First, it can restrict access to a certain portion of its MIB. For example, an agent may restrict most manager principals to viewing performance-related statistics and allow only a single designated manager principal to view and update configuration parameters. Second, the agent can limit the operations that a principal can use on that portion of the MIB. For example, a particular manager principal could be limited to read-only access to a portion of an agent's MIB. The access control policy to be used by an agent for each manager must be preconfigured. It essentially consists of a table that details the access privileges of the various authorized managers. Access control is done by group, not by a single user.
The above flowchart illustrates the overall VACM logic, which proceeds in the following steps:
The context name refers to a named subset of the MIB objects at an agent. VACM checks to see if there is an entry in vacmContextTable for the requested contextName. If so, then this context is known to this SNMP engine. If not, then an errorIndication of noSuchContext is returned.
Each principal operating under a given security model is assigned to at most one group, and access privileges are configured on a group basis. VACM checks vacmSecurityToGroupTable to determine if there is a group assigned to the requested <securityModel, securityName> pair. If so, then this principal, operating under this securityModel, is a member of a group configured at this SNMP engine. If not, then an errorIndication of noGroupName is returned.
VACM next consults the vacmAccessTable with groupName, contextName, securityModel, and securityLevel (indicates authentication, authentication plus privacy, or neither) as indices. If an entry is found, then an access control policy has been defined for this groupName, operating under this securityModel, at this securityLevel, for access to this contextName. If not, then an errorIndication of noAccessEntry is returned.
A MIB view is a structure subset of a context; it is essentially a set of managed object instances viewed as a set for access control purposes. VACM determines whether the selected vacmAccessTable entry includes reference to a MIB view of viewType (read, write, notify). If so, then this entry contains a viewName for this combination of groupName, contextName, securityModel, securityLevel, and viewType. If not, then an errorIndication of noSuchView is returned.
The viewName from Step 4 is used as an index into vacm ViewTreeFamilyTable. If a MIB view is found, then a MIB view has been configured for this viewName. If not, then an errorIndication of noSuchView is returned.
VACM checks the variableName against the selected MIB view. If this variable is included in the view, then a statusInformation of accessAllowed is returned. If not, then an errorIndication of notIn-View is returned.
5.0. Case Study
5.1. DMH Software:
DMH Software is a recognized global leader in SNMP Agent solutions. It provides field proven portable, real-time and extensible C and Java implementations of SNMP Agents (SNMPv1, SNMPv2c, SNMPv3). DMH Software's SDK includes a SMIv2 MIB-Compiler for rapid MIB development. The agent can be used in a wide range of platforms - from very small embedded systems such as 8bit 8051, and up to 64bit systems. In addition, the agent can fit proprietary Real Time Operating Systems (RTOS), Standard RTOS or no RTOS. Since DMH's portable software is highly portable, it offers a free platform integration if required.
5.2. DMH Technology
DMH portable software is platform, compiler and RTOS independent which was proven by porting to numerous platforms and CPU architectures from the smallest 8 bit configuration to 64 bit large system. Listed below are the platforms that have been proven complied with the DMH software:
5.3. DMH Products
DMH Software licenses highly portable software components designed for embedded real-time systems and other systems. All the components are implemented in 100% ANSI-C. Some components were modified to meet specific compiler and system requirements but without compromising ANSI-C conformance. Below is the list of available products:
5.4. DMH SNMP Agent Architecture:
DMH SNMP portable Agent consists of the software components implementing the SNMP protocol and MIB II. This is the Agent kernel. The kernel is relatively small, simple, and highly portable. Its overall design is optimized for fast integration and ease of use.
The SDK includes the DMH MIB-Compiler for rapid development of additional MIBs. The MIB compiler accepts an ASN.1 MIB definition as input, and produces a set of 'C' and 'H' files as output. The generated 'C" files include the code implementing the given MIB. Figure 11 illustrates the DMH SNMP internal architecture:
Figure10 DMH SNMP Architecture
5.5. DMH SNMP Main Components
DMH SNMP kernel
IP stack MIB-II
Adding support for MIB-II
Basic hosting -system services