SNMP version 1 (SNMPv1)

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. SNMPv1 is a
simple request/response protocol. In the SNMPv1 framework, the network-management system
installed a request, and managed devices return responses.
(A) SNMP Basic Components
An SNMP-managed network consists of three key components: managed devices, agents, and network
management systems (NMSs).
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. Figure 1.1 illustrates the relationships of these three components.

Figure 1.1 An SNMP-Managed Network Consists of Managed Devices, Agents, and NMSs
(B)SNMP Basic Commands
:

Managed devices are monitored and controlled using four basic SNMP commands: read, write, trap,
and 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.
(C)SNMP Architecture
The SNMP architecture is illustrated in the figure 1.2 below. The figure identifies two major roles
(Manager and Agent) and two communication channels (UDP port 161 and UDP port 162).

Figure 1.2 Simplified SNMP architecture

SNMP managers can be anything from monolithic GUI based management frameworks to
individual console applications that communicate over network using SNMPv1 protocol. There
are also specific trap listeners for logging and dispatching incoming trap event messages.
SNMP agents can either work alone or with sub-agents. When sub-agents are present, the agent
that listens for SNMPv1 requests from managers is called a master agent. The master agent
forwards a received request to corresponding sub-agents. This communication may be done
using a special sub-agent protocol. If the sub-agent does not respond directly to the requester,
then the master agent may be involved in converting the response into SNMPv1 and delivering
it to the manager. The master agent may be completely transparent to the manager.

"A master agent provides access to SNMP variables that may be provided by one or more
subagents. The master agent usually uses a subagent protocol (AgentX, DPI, SMUX,
EMANATE, ...) to interact with the subagents. One of the key features of such an extensible
agent is that it is complete transparent to the manager."
A SNMP proxy agent is an element capable of acting as gateway to the other management
agents. Proxies could be used to map different management protocols and to pass through an
application level firewall.
"The current definition of a proxy SNMP agent is an agent which acts like a gateway to other
SNMP agents. This can be useful in order to pass firewalls or to map SNMP protocol versions.
Such a proxy is however not transparent to the manager since the manager usually has to
select special parameters to address the target agent through the proxy."

(D)The Information Model

The Information Model deals with Structure of Management Information(SMI) and Management
Information Base (MIB).
Structure of Management Information
The Structure of Management Information (SMI) defines the rules for describing management
information, using Abstract Syntax Notation One (ASN.1). A managed object can be considered to be
composed of an object type and not object instance, as shown in Figure 1.3. SMI is concerned only
with the object type and not object instance. That is, the object instance is not defined by SMI. Figure
1.4 shows the situation where there are multiple instances of an object type. 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.

Figure1.3 Managed Object:Type and Instances

Figure 1.4 Managed Object:Type with MUltiple Instances

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.
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, opaques, integers, and unsigned integers.
Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32bit 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 retains 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.

Management Information Base (MIB)

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 and 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. Figure1.5 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 nameiso.identifiedorganization.dod.internet.private.enterprise.cisco.temporary variables. AppleTalk.atInputor by the
equivalent object descriptor, 1.3.6.1.4.1.9.3.3.1.

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

(E)SNMPv1 Message Formats

SNMPv1 messages contain two parts: a message header and a protocol data unit (PDU). Figure 1.5
illustrates the basic format of an SNMPv1 message.

Figure 1.6 An SNVPv1 Message Consists of a Header and a PDU

SNMPv1 Message Header
SNMPv1 message headers contain two fields: Version Number and Community Name.
Version numberSpecifies the version of SNMP used.
Community nameDefines 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.
SNMPv1 Protocol Data Unit
SNMPv1 PDUs contain a specific command (Get, Set, and so on) and operands that indicate the object
instances involved in the transaction. SNMPv1 PDU fields are variable in length, as prescribed by
ASN.1. Figure 1.6 illustrates the fields of the SNMPv1 Get, GetNext, Response, and Set PDUs
transactions.

Figure 1.6 SNMPv1 Get, GetNext, Response, and Set PDUs Contain the Same Fields
PDU typeSpecifies the type of PDU transmitted.
Request IDAssociates SNMP requests with responses.
Error statusIndicates one of a number of errors and error types. Only the response operation sets
this field. Other operations set this field to zero.
Error indexAssociates an error with a particular object instance. Only the response operation sets
this field. Other operations set this field to zero.
Variable bindingsServes 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).
Trap PDU Format
Figure 1.7 illustrates the fields of the SNMPv1 Trap PDU.

Figure 1.7 The SNMPv1 Trap PDU Consists of Eight Fields

EnterpriseIdentifies the type of managed object generating the trap.
Agent addressProvides the address of the managed object generating the trap.
Generic trap typeIndicates one of a number of generic trap types.
Specific trap codeIndicates one of a number of specific trap codes.
Time stampProvides the amount of time that has elapsed between the last network reinitialization
and generation of the trap.
Variable bindingsThe data field of the SNMPv1 Trap PDU. Each variable binding associates a
particular object instance with its current value.
(F)SNMP Communication Model
The Communication Model defines the specifications of four aspects of SNMP communication:
The architecture, the administrative model, SNMP protocol and the SNMP MIB.
The SNMP architecture
The SNMP architecture consists of communication between network management stations and
managed network elements, or objects. Network elements have built-in management agents if they are
managed elements. The SNMP communications protocol is used to communicate information between
the network management stations and the management agents in the elements.
There are three goals of the architecture in the original specifications of SNMP [RFC 1157]. First, I it
should minimize the number and complexity of the management functions realized by the management
agent. Second, it should be flexible enough to allow expansion. Last the SNMP architecture should be
independent of the architecture and mechanisms of particular hosts and gateways. Only nonaggregate
objects are communicated using SNMP. Consistent with the rest of the SNMP standards, ASN.1 and
BER are used for data transfer in SNMP.
The SNMP manages the network with the five messages. They comprise three basic messages: set, get,
and trap. The information about the network is obtained primarily by the management stations polling
the agents. The get-request and get-next-request messages are generated by the manager to retrieve
data from network elements using the associated management agents. The set-request is used to
initialize and edit the parameters of the network element. The get-response-request is the response
from the agent to get (get-request and get-next-request) and set (set-request) messages from the
manager. The number of unsolicited messages, in the form of traps, is limited to make the architecture
simple and to minimize the traffic. There are three types of traps: generic-trap, specific-trap, and timestamp. The traps are application specific. The generic-trap type consists of coldStart, warmStart,
linkDown, linkUp, authenticationFailure, egpNeighborLoss, and enterpriseSpecifi,c.The specific-trap
is a specific code and is generated even when an enterprise Specific trap is not present. The time-stamp
trap is the time elapsed between the last initialization or reinitialization of the element and the
generation of the trap.
The SNMP messages are exchanged using the connectionless UDP transport protocol in order to be
consistent with simplicity of the model, as well as to reduce the traffic. However, the mechanisms of
the SNMP are suitable for a variety of protocols.
The Administrative Model
In RFC 1157 the entities that reside in the management stations and network elements are called
SNMP application entities. We'll refer to the application entity residing in the management station as
the SNMP manager, and the application entity in the element as the SNMP agent. The pairing of the
two entities is called an SNMP community. The SNMP community name, called the community, is
specified by a string of octets. Multiple pairs can belong to the same community. Figure 1.8 shows
multiple SNMP managers communicating with a single SNMP agent. With the one-to-many, many-to:

one, and many-to-many communication links between managers and agents, the basic authentication
scheme and the access policy have been specified in SNMP. Figure 1.8 shows the authentication
scheme, which is a filter module in the manager and in the agent.

Figure 1.8 An SNMP Community

A network element comprises many managed objects, both standard 2nd private. However, a
management agent may be permitted to view only a subset of the network element's managed objects.
This is called the community MIB view. In Figure 1.9, the SNMP agent has a MIB view of objects 1,
2, and 3, although there may be other objects associated with a network element. In addition to the
MIB view, each community name is also assigned an SNMP access mode, either READ-ONLY or
READ-WRITE, as shown in Figure 1.9. A pairing of the SNMP MIB view with the SNMP access
mode is called the community profile.

Figure 1.9 An SNMP Community Profile

The SNMP access can be extended to managing a nonSNMP community that uses the SNMP proxy
access policy. The SNMP agent associated with the proxy policy is called a proxy agent, or
commercially a proxy server. The proxy agent monitors a non-SNMP community with non-SNMP
agents and then converts the objects and data to SNMP-compatible objects and data to feed to an
SNMP manager. Figure 1.10 shows an illustration of SNMP and non-SNMP communities being managed by an SNMP manager. A practical example of this would be a network of a LAN and a WAN. The
LAN could be a TCP/IP network with SNMP agents. The WAN could be an X.I5 network, which is not
:

an Internet model, but can be managed by a proxy agent and integrated into the overall management
system.

Figure 1.10 An SNMP Proxy Access Policy

(F)SNMP protocol
The message format for all versions of SNMP is similar except PDU. The PDU (Protocol Data Unit)
for SNMPv1 have five different PDU types: GetRequest, GetNextRequest, GetResponse, SetRequest,
and Trap. The format for GetRequest, GetNext Request, GetResponse and SetRequest PDUs is shown:
PDU type Request ID Error status Error index
Object 1, value 1
Object 2, value 2 ...
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).

The format of the Trap PDU is shown below:

PDU type Enterp Agent Addr Gen Trap Spec Trap Time Stamp Obj 1, Val 1 Obj 1, Val 1 ...
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. The following seven values are
defined:

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.

(G)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.

SNMP version 2 (SNMPv2)

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.
(A) 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.
Proxy Agents
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.
(B) SNMPv2 System Architecture
SNMPv1 evolved at a time when a single network manager was responsible for maintaining a set of
network elements connected to it. However, as networks have become more sophisticated, the concept
:

of multiple network managers working together has appeared. SNMPv1 did not have provisions for
two network managers to exchange messages specifically between managers (instead, it provided
manager/agent messages). Figure 2.1 illustrates the new capability provided by SNMPv2, with two
managers sharing responsibility for managing the SNMP agent. Just as a manger can exchange
information with the agent (who is under the control of the manager), so also can a manager exchange
information with a partner manager to coordinate management of the agent. A new SNMP message
informrequest provides the means for one manager to request information from another manager, just
as the get-request provides the means for a manager to request information from an agent.

Figure 2.1 SNMPv2 Architecture

The messages get-request, get-next request, and set-request are the same as in version 1 and are
generated by the manager application. The message response is also the same as get-response in
version 1, and is now generated by both the agent and the manager applications. It is generated by the
agent application in response to a get or set message from the manager application. It is also generated
by the manager application in response to an inform-request message from another manager
application.
An inform-request message is generated by a manager application and transmitted to another manager
application. The receiving manager application responds with a response message. This set of
communication messages is a powerful enhancement in SNMPv2, because It makes two network
management systems interoperable.
The message get-bulk-request is generated by a manager application. It is used to transfer large
amounts of data from the agent to the manager, especially if it includes retrieval of table data. The
retrieval is fast and efficient. The receiving entity generates and fills data for each entry in the request
and transmits all the data as a response message the originator of the request.

AnSNMPv2-trap event, known as trap in version 1, is generated and transmitted by agent process
when an exceptional situation occurs. The destination to which it is sent implementation-dependent.
The PDU structure has been modified to be consistent with other PDUs.
(C) SNMPv2 Structure of Management Information
There several changes to SMI in version 2, as well as enhancements to SMlv2 over of SMlvl. As stated
earlier, the SMIv2 [RFC 1902], is divided into three parts: module definitions, object definitions, and
notification definitions. The module definitions describe the semantics of an information module and
are formally defined by an ASN.1 macro, MODULE-ENTITY. Object definitions are used to describe
managed objects. The OBJECT-TYPE macro is used to define managed objects. Notification is
specified by an ASN.1 macro, NOTIFICATION-TYPE, and conveys both its syntax and semantics.
Basic Augmentation of Table
Figure 1a shows a table in SNMPv2. Column C1 contains the index specifying the row of the table. If
you want to read the information in the second row (say with index-1 = 127.128.129.130), you would
use the value of this index 127.128.129.130 rather than the numerical number of the row. Next, assume
(e.g., as manufacturer of the network element or as the manager of the system) that you want to add
additional information to (i.e., you want to augment) each of the rows in Figure 1a to have the 7
column table in Figure 1b. To make such changes, you would need to rewrite the definitions of this
table (respecifying the columns of the table entry) - and you do not want to do this. SNMPv2 provides
a means of augmenting the table with the "AUGMENT" construct. Figure 1c shows conceptually one
way to do this - illustrated visually with the new "Augment" column containing an arrow pointing to a
new column to add. We would call the new column Table 2. Conceptually, Figure 1d shows the
augmenting as an addition of a row with multiple elements within the rightmost column of Figure 1d.
This is intended to illustrate that the index for the first row remains index-1 for the new row of
instances extending Table 1 in Figure 1a. This would be done by defining a new table (Table 2) and,
when defining the row entries, adding a statement "AUGMENTS {Table 1}." Figure 1e shows the final
result, namely two tables sharing a common index to define the rows of each. Here, the work
"Augments" has been removed from the individual rows and shown only for the column labels,
reflecting the fact that the "AUGMENT" statement is associated with the general row definition, not
any specific row.

Extension of Only Some Rows of a Table

Perhaps you want to only extend some of the rows in the table. Since the row entries have been defined
for each row (and each row is identified by the index in column C1), some consistency must be
maintained. Figure 2 shows conceptually how the third row is not extended (its entries are blank). This
is calls "Addition of a Sparse Table to a Base Table".
:

Extended TFigure 2: Adding Sparse Table

Extending a Row by Adding a Table Element
In Figure 1d, I illustrated the progression to Figure 1e as addition of a row of columns for Table 2 in a
single additional row. This was, for row extension, an intermediate step leading to the final result in
Figure 1e. Suppose however, that you want to extend the row in Table 1 by addition of a table as an
augmented element of that row. Figure 3 shows conceptually the steps of Figure 1d and Figure 1e, but
in this case for addition of a table to a row. In Table 2, the smaller table added to the rows of Table 1
are shown with row indices (index-1A, index-1B, etc.). To specify an element of this smaller table
within a given row of Table 1, it is necessary to specify the index for a row in Table 1 and then to
specify the index for a row in the embedded table in Table 2. The row highlighted in red in Figure 4b
illustrates the need for two indices, index-1 and index-1B.

Figure 3: Augmenting Row Elements with Added Tables.

(D) SNMPv2 Message Format
SNMPv2 messages consist of a header and a PDU. Figure 2.2 illustrates the basic format of an
SNMPv2 message.

Figure 2.2 SNMPv2 Messages Also Consist of a Header and a PDU

SNMPv2 Message Header
:

SNMPv2 message headers contain two fields: Version Number and Community Name.
Version numberspecifies the version of SNMP that is being used.
Community namedefines 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.
SNMPv2 Protocol Data Unit
SNMPv2 specifies two PDU formats, depending on the SNMP protocol operation. SNMPv2 PDU
fields are variable in length, as prescribed by Abstract Syntax Notation One (ASN.1).
Figure 2.3 illustrates the fields of the SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs.
The following descriptions summarize the fields illustrated in Figure 2.3:
PDU typeIdentifies the type of PDU transmitted (Get, GetNext, Inform, Response, Set, or Trap).
Request IDAssociates 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 indexAssociates an error with a particular object instance. Only the response operation sets
this field. Other operations set this field to zero.
Variable bindingsServes as the data field of the SNMPv2 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 2.3 SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs Contain the Same
Fields
Figure 2.4 illustrates the fields of the SNMPv2 GetBulk PDU.

Figure 2.4 The SNMPv2 GetBulk PDU Consists of Seven Fields

PDU type Identifies the PDU as a GetBulk operation.
Request IDAssociates SNMP requests with responses.
Non repeatersSpecifies the number of object instances in the variable bindings field that should be
retrieved no more than once from the beginning of the request. This field is used when some of the
instances are scalar objects with only one variable.
Max repetitionsDefines the maximum number of times that other variables beyond those specified
by the Non repeaters field should be retrieved.

 Variable bindingsServes as the data field of the SNMPv2 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).
(E) SNMPv2 Protocol
The general formats for all SNMP versions are similar except the format of PDU (Protocol Data Unit).
The format of the PDU for SNMPv2 is displayed as follows:
For SNMPv2, Get, GetNext, Inform, Response, Set, and Trap PDUs have the following format:
PDU type Request ID Error status Error index Object 1, value 1
Object 2, value 2
...
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 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 (value 1, value 2) of the SNMPv2 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).

SNMPv2 GetBulk PDU Format:

PDU type
Request ID
Non repeaters
Max repetitions
PDU type- Identifies the PDU as a GetBulk operation.
Request ID- Associates SNMP requests with responses.

Obj 1, Val 1

...

Non repeaters- Specifies the number of object instances in the variable bindings field that
should be retrieved no more than once from the beginning of the request. This field is used
when some of the instances are scalar objects with only one variable.

Max repetitions- Defines the maximum number of times that other variables beyond those
specified by the Non repeaters field should be retrieved.

Variable bindings- 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 (with the
exception of Get and GetNext requests, for which the value is ignored).

(F) SNMPv2 PROTOCOL OPERATIONS

Obj 1,Val 1

It is similar to snmpv1, except for "exceptions. Possible exceptions are:

noSuchObject
noSuchInstance
Exceptions are coded within the varbinds. Exceptions do not raise error status and index.
GET EXAMPLES
get(7)
response(error-status => noError, 7 => noSuchObject)
get(7.1)
response(error-status => noError, 7.1 => noSuchInstance)
get(7.1.9)
response(error-status => noError, 7.1.9 => noSuchInstance)
get(7.2)
response(error-status => noError, 7.2 => noSuchObject)
get(7.4.0)
response(error-status => noError, 7.4.0 => noSuchObject)
get(7.1.0, 7.4.0)
response(error-status => noError, 7.1.0 => 192.168.101.102, 7.4.0 => noSuchObject)

It is similar to snmpv1, except for "exceptions". Possible exceptions:

endofmibview
EXAMPLE
getnext(7.4.0)
response(error-status => noerror, 7.4.0 => endofmibview)

It is new in snmpv2 to retrieve a large number of varbinds. It improves performance.

getbulk request has two additional parameters:
non-repeators
max-repetitions
The first n elements (non-repeators) of the varbind list are treated as if the operation was a normal
getnext operation. The next elements of the varbind list are treated as if the operation consisted of a
number (max-repetitions) of repeated getnext operations.
GET-BULK EXAMPLE
getBulk(max-repetitions = 4; 7.1)
response(
7.1.0 => 192.168.101.102
7.2.1.0 => printer-1
7.2.2.0 => 123456
7.3.1.1.2.1 => 2 )
getBulk(max-repetitions = 3; 7.3.1.1; 7.3.1.2; 7.3.1.3)
response( 7.3.1.1.2.1 => 2; 7.3.1.2.2.1 => 1; 7.3.1.3.2.1 => 2
7.3.1.1.3.1 => 3; 7.3.1.2.3.1 => 1; 7.3.1.3.3.1 => 3
7.3.1.1.5.1 => 5; 7.3.1.2.5.1 => 1; 7.3.1.3.5.1 => 2)

It is similar to snmpv1. It has conceptual two phase commit:

phase 1: perform various checks
phase 2: perform the actual set
There are many new error codes defined.

NEW ERROR CODES FOR SETS

SNMPv1:
cold start
warm start
link down
link up
authetication failure
egp neighbor loss
SNMPv2:
MIBs may now include notification type macros
First two varbinds: sysuptime and snmptrapoid
Uses same format as other PDUs
EXAMPLE OF NOTIFICATION TYPE MACRO
:

linkUp NOTIFICATION-TYPE
OBJECTS {ifIndex}
STATUS current
DESCRIPTION "A linkUp trap signifies that the entity has detected that the ifOperStatus object has
changed to Up"
::= {snmpTraps 4}

It is confirmed trap. It is originally to inform a higher level manager It has same format as trap
PDU.Possible error: toobig

It required new PDU to signal protocol. There is no semantics defined in snmpv2.

SNMP version 3 (SNMPv3)

SNMPv3 is an interoperable standards-based protocol for network management. SNMP Version 3
(SNMPv3) adds security and remote configuration capabilities to the previous versions. The SNMPv3
architecture introduces the User-based Security Model (USM) for message security and the Viewbased Access Control Model (VACM) for access control. SNMPv3 provides secure access to devices
by a combination of authenticating and encrypting packets over the network. The security features
provided in SNMPv3 are:
Message integrityEnsuring that a packet has not been tampered with in-transit.
AuthenticationDetermining the message is from a valid source.
EncryptionScrambling the contents of a packet prevent it from being seen by an unauthorized
source.
SNMPv3 provides for both security models and security levels. A security model is an authentication
strategy that is set up for a user and the group in which the user resides. A security level is the
permitted level of security within a security model. A combination of a security model and a security
level will determine which security mechanism is employed when handling an SNMP packet.
:

(A) SNMPv3 System Architecture

There are four main parts to the SNMPv3 architecture. The interaction between these systems to
provide the necessary data requested is depicted in the following figure 3.1:

Figure 3.1 The primary parts of the SNMPv3 architecture

The DPI2 subagent, smux peer, SNMP manager, and SNMP agent are shown. In addition, how they
communicate with each other is shown.
SNMP agent
The SNMP agent receives requests from, and makes responses to, the SNMP manager.
In addition, the SNMP agent communicates with all DPI2 subagents and SMUX peers on the
system. The SNMP agent manages some MIB variables, and all DPI2 subagents and SMUX
peers register their MIB variables with the SNMP agent.
When clsnmp (the SNMP manager) issues a request, it is sent to UDP 161 on the SNMP agent.
If the request is an SNMPv1 or SNMPv2c request, the SNMP agent will verify the community
name and process the request. If the request is an SNMPv3 request, the SNMP agent will
attempt to authenticate the user requesting the data and ensure that the user has the access
permissions required to fulfill the request by using the authentication keys, and, if the encrypted
version is running, privacy keys. If the SNMP agent cannot authenticate the user, or if the user
does not have the correct access permissions to fulfill the request, the SNMP agent will not
honor the request. For information on creating users in SNMPv3.
If the user is authenticated and has the correct access permissions, the SNMP agent will fulfill
the request. The SNMP agent will locate the MIB variables being requested. If the SNMP
agent itself is managing the requested MIB variables, it will process the request and send a
response back to the SNMP manager. If a DPI2 subagent or SMUX peer is managing the
requested MIB variables, the SNMP agent will forward the request to the DPI2 subagent or
SMUX peer on which the MIB variables are managed, allow it to process the request, and will
then respond to the SNMP manager.
DPI2subagents
A DPI2 subagent, such as hostmibd, communicates with the DPI2 agent, which, in SNMPv3, is part of
the SNMP agent. A DPI2 subagent, such as hostmibd, communicates with the DPI2 agent, which, in
SNMPv3, is part of the SNMP agent. The DPI2 subagent sends responses and traps to the DPI2 agent
through dpiPortForTCP.0. Because this is not a well-known port, the DPI2 subagent must first issue a
:

request for the port number for dpiPortForTCP.0. This request is issued to UDP 161 on the SNMP
agent, after which the SNMP agent responds to the DPI2 subagent with the port number for
dpiPortForTCP.0. After the port number is received, the DPI2 subagent establishes a connection with
the DPI2 agent using the port number given. The DPI2 subagent then registers its MIB subtrees with
the DPI2 agent.
SMUXpeers
A SNMP Multiplexing (SMUX) peer, such as gated, when started, will establish the connection to TCP
199 and will initialize the SMUX association.
A SNMP Multiplexing (SMUX) peer, such as gated, when started, will establish the connection
to TCP 199 and will initialize the SMUX association.
Following the initialization, the SMUX peer will register the MIB subtrees it is going to
manage.
After the registration, the SMUX peer is ready to accept any incoming request from the SMUX
server and send responses back. When the SMUX peer receives a request, it will process the
request and send a response back the SMUX server.
The SMUX peer can also send a trap to the SMUX server. If a trap is sent, the SNMP agent
will check the /etc/snmpdv3.conf file to determine the IP address or addresses to which the trap
must be forwarded, and it will send the trap to those addresses.
SNMP manager
The SNMP manager runs clsnmp, which is compatible with SNMPv1, SNMPv2c, and SNMPv3. The
SNMP manager runs clsnmp, which is compatible with SNMPv1, SNMPv2c, and SNMPv3. Use the
clsnmp command to issue a request, such as a get, get-next, get-bulk, or set request. The request is sent
to UDP 161 on the SNMP agent, after which it waits for the response from the SNMP agent.
MIB variables
Information on MIB variables can be found in the following locations:
Information on MIB variables can be found in the following locations.
For information on MIB variables.
If you want to configure your own DPI2 subagent or smux peer.
(B) SNMPv3 Applications
It is the purpose of RFC 3413, "SNMPv3 Applications" to describe the five types of applications that
can be associated with an SNMP engine. The applications are: Command Generators, Command
Responders, Notification Originators, Notification Receivers, and Proxy Forwarders. The document
also defines MIB modules for specifying targets of management operations (including notifications),
for notification filtering, and for proxy forwarding.
(C) SNMPv2 Management Information Base
MIB modules usually contain object definitions, may contain definitions of notifications, and
sometimes include compliance statements specified in terms of appropriate object groups. As such,
MIB modules define the management information 1) maintained by the instrumentation in managed
nodes, 2) made remotely accessible by management agents, 3) conveyed by the management protocol,
and 4) manipulated by management applications.
MIB modules are defined according to the rules defined in the documents that specify the data
definition language, principally the SMI as supplemented by the related specifications. There is a large
and growing number of standards-based MIB modules as defined in the periodically updated list of
standard protocols (RFC 2400). As of this writing, there are about 100 standards-based MIB modules
with a total number of defined objects of approximately 10,000. In addition, there is an even larger and
:

growing number of enterprise-specific MIB modules defined unilaterally by various vendors, research
groups, consortia, and the like resulting in an unknown and virtually uncountable number of defined
objects.
In general, management information defined in any MIB module, regardless of the version of the data
definition language used, can be used with any version of the protocol. For example, MIB modules
defined in terms of the SNMPv1 SMI are compatible with the SNMPv3 Management Framework and
can be conveyed by the protocols specified therein. Conversely, with one notable exception, MIB
modules defined using the SNMPv2 SMI are compatible with the SNMPv1 protocol operations. The
exception is the new Counter64 data type introduced in the SNMPv2 SMI: an SNMPv1 protocol
engine is unable to convey data of this type.
(D) SNMPv2 Message Format

msgVersion: Identifies the message as an SNMPv3 message when msgVersion = 3.

msgID: Used to coordinate request and response messages between the manager and the agent. The
msgID in a response must be the same as the msgID in a request.
msgMaxSize: conveys the maximum message size that the sender can accept.
msgFlags: bit fields which control processing of the message:
Field
Meaning
.... ...1
authFlag
.... ..1.
privFlag
.... .1..
reportableFlag
.... ..00
is OK, means noAuthNoPriv
.... ..01
is OK, means authNoPriv
.... ..10
reserved, must NOT be used
.... ..11
is OK, means authPriv
msgSecurity Model: identifies the Security Model used for the message generation and reception.
msgSecurityParameters: used for communication between the Security Model modules.
scopedPduData: either a plaintext scoped PDU, or a cyphertext encrypted PDU.
scopedPDU: identifies an administratively-unique context and PDU.
contextEnginelD: determines the context to process this PDU, such as the correct application.
contextName: identifies the context associated with the management information in the PDU.
:

data: contains the SNMPv3 PDU, which must be one of the PDUs specified in RFC 1905:
GetRequest, GetNextRequest, Response, SetRequest, GetBulkRequest, InformRequest, SNMPv2-Trap
or Report.
(E) SNMPv3 Protocol

Version --For SNMPv3 it is 3.

ID --A unique identifier used between two SNMP entities to coordinate request and response
messages

Msg Size -- Maximum size of a message in octets supported by the sender of the message

Msg Flags --An octet string containing three flags in the least significant three bits:
reportableFlag, privFlag, authFlag.

Security Model --An identifier to indicate which security model was used by the sender and
therefore which security model must be used by the receiver to process this message.

AuthoritativeEngineID -- The snmpEngineID of the authoritative SNMP engine involved in

the exchange of this message. Thus, this value refers to the source for a Trap, Response, or
Report, and to the destination for a Get, GetNext, GetBulk, Set, or Inform.

AuthoritativeEngineBoots --The snmpEngineBoots value of the authoritative SNMP engine

involved in the exchange of this message.

AuthoritativeEngineTime -- The snmpEngineTime value of the authoritative SNMP engine

involved in the exchange of this message.

User Name --The user (principal) on whose behalf the message is being exchanged.

AuthenticationParameters -- Null if authentication is not being used for this exchange.

Otherwise, this is an authentication parameter.

PrivacyParameters -- Null if privacy is not being used for this exchange. Otherwise, this is a
privacy parameter.

PDU (Protocol Data Unit)-- The PDU types for SNMPv3 are the same as the SNMPv2.

(F) User Security Model

Two core modules within the framework are the User-based Security Model (USM) and the Viewbased Access Control Model (VACM). The USM is in charge of authenticating/ encrypting/ decrypting
SNMP packets and the VACM is in charge of administering access to MIB data. The USM is specified
in RFC 2574. A weak point of all the previous well known SNMP versions has been the lack of a solid,
agreed upon, security scheme. In designing the USM, these classic security threats had to be addressed:
Modification of Information (Data Integrity)
Ensure that the data is not maliciously altered during transit by an unauthorized entity.
Masquerading (Data Origin Authentication)
Ensure that it is known exactly who and where the data came from to prevent an unauthorized
entity from assuming the identity of an authorized user.
Disclosure (Data Confidentiality)
Ensure that an unauthorized entity cannot eavesdrop on the data exchanges.
Message Stream Modification (Message Timeliness)
Ensure that the data was received in a timely manner to prevent malicious re-ordering of data
by an unauthorized entity.
The USM is able to protect SNMPv3 packets from the above threats by utilizing a concept of multiple
users where each user provides secret keys for authentication and privacy. The authentication protocols
specified for use are HMAC-MD5 and HMAC-SHA. The privacy protocol specified is CBC-DES. The
RFC states that the security protocols used for the USM are considered acceptably secure at the time of
its writing. However, the model allows for new authentication and privacy protocols to be specified at
a future time if the need arises.
Concepts
The SNMPv3 framework introduces many new concepts. Most of these concepts are used by multiple
modules within the framework. Here are a few that are used by the USM:
snmpEngineID
A unique identifier for an SNMP engine within an administrative domain. The value of this
octet string cannot be zero length, all '0x00'H, or all '0xFF'H. The snmpEngineID is usually
computed using a combination of the enterprise number, IP or MAC address, and an
administratively assigned string.
snmpEngineBoots
A count of the number of times an SNMP engine has re-booted or re-initialized since the
snmpEngineID was last set. This counter is initially set to zero.
snmpEngineTime
The number of seconds since the snmpEngineBoots counter was last incremented. This counter
is initially set to zero. If the snmpEngineTime reaches its maximum (2147483647), then the
snmpEngineBoots is incremented by one and the snmpEngineTime starts counting again from
zero.
snmpSecurityLevel
There are three possible security levels: noAuthNoPriv, authNoPriv, and authPriv. The
noAuthNoPriv level specifies no authentication or privacy is performed. The authNoPriv level
specifies that authentication is performed but not privacy. And the authPriv level specifies that
both authentication and privacy are being performed. One reason why a noAuthPriv security
level does not exist is because a message authentication digest is needed to ensure the integrity
of the security parameters, namely the privacy parameters (i.e. DES salt).
Authoritative SNMP Engine
In order to protect against message replay, delay, and redirection, one of the communicating
SNMP engines is designated as the Authoritative SNMP Engine. The Authoritative SNMP
:

Engine is an engine which receives SNMP messages which need a response. This is always the
agent that a manager communicates with.
USM Security Parameters
The USM uses the msgSecurityParameters to hold five values. These values are used by the
authentication module to ensure data integrity and origin authentication, by the timeliness module to
protect against message delay or replay, and by the privacy module to protect against message payload
disclosure.
msgAuthoritativeEngineID
The snmpEngineID of the authoritative engine is always put in this field no matter which side
the packet originates from.
msgAuthoritativeEngineBoots
The snmpEngineBoots of the authoritative engine.
msgAuthoritativeEngineTime
The snmpEngineTime of the authoritative engine.
msgUserName
The name of the user whose secret keys were used to possibly authenticate and encrypt the
packet.
msgAuthenticationParameters
If the packet has been authenticated, then this field contains the computed HMAC-MD5 or
HMAC-SHA message digest for the packet.
msgPrivacyParameters
If the scopedPDU of the packet has been encrypted, then this field contains the salt (i.e. random
variant) that was used as input to the DES algorithm.
Authentication
The USM specifies the use of the Message Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA-1)
algorithms for authenticating SNMPv3 packets. These algorithms are used to create unique fixed sized
message digests, also called digital signatures or fingerprints, of a variable length message. MD5
creates a digest of 128 bits (16 bytes) and SHA-1 creates a digest of 160 bits (20 bytes). Both MD5 and
SHA-1 cannot be used directly as a message authentication code because they do not use secret keys as
input to derivate the computed message digest. This is why the Keyed Hashing for Message
Authentication (HMAC) algorithm in combination with MD5 and SHA-1 is used for computing
message digests. The HMAC algorithm defines a procedure for appending a secret key to the data and
then computing the MD5 or SHA-1 message digest. This guarantees that parties who wish to compute
identical message digests for the same block of data must share a common secret key. Here are the
steps that are taken for sending and receiving an authenticated SNMPv3 packet:
Sending an authenticated SNMPv3 packet:
1. The entire packet is created. The authentication flag is turned on in the msgFlags, and the
msgAuthenticationParameters is zeroed out.
2. A message digest is computed of the packet using the secret authentication key for the user
specified in msgUserName. The algorithm used (i.e. HMAC-MD5 or HMAC-SHA) is
determined by the authentication protocol specified for the user in the User Table.
3. The computed message digest is inserted in the msgAuthenticationParameters.
4. The packet is sent.
Receiving an authenticated SNMPv3 packet:
1. The packet is received.
2. If the authentication flag is turned on in the msgFlags, then continue with the authentication
process at step 3. If the packet was not authenticated by the sender, authentication is skipped.
:

3. The msgAuthenticationParameters is saved.

4. The msgAuthenticationParameters is zeroed out.
5. A message digest is computed of the packet using the secret authentication key for the user
specified in msgUserName. The algorithm used (i.e. HMAC-MD5 or HMAC-SHA) is
determined by the authentication protocol specified for the user in the User Table. If the user
does not exist in the User Table then the packet cannot be authenticated and it is dropped.
6. The
computed
message
digest
is
compared
to
the
previously
saved
msgAuthenticationParameters. If they are different then the packet is not authentic and it is
dropped. If they are the same, then the packet is authentic and processing may continue.
Privacy
The USM specifies the use of the Cipher Block Chaining mode to the Data Encryption Standard (CBCDES) algorithm for encrypting and decrypting SNMPv3 packets. The scope of the encryption only
covers the scopedPDU which contains the PDU and context data used by the VACM. The DES
algorithm takes three inputs. These inputs are the data to be encrypted, a 56 bit secret key, and a 56 bit
randomly generated salt which is used to ensure that two different initialization vectors are used for
two different data inputs encrypted with the same secret key. For two parties to use encryption during
communication, each must share a secret privacy key as well as the salt used to derivate the
initialization vector. The secret privacy keys are stored in the User Table, and the salt is transmitted
with the packet in the msgPrivacyParameters. Here are the steps that are taken for sending and
receiving an encrypted packet.
Sending an encrypted SNMPv3 packet:
1. The entire packet is created, and the authentication and privacy flags are turned on in the
msgFlags.
2. A random salt value is computed.
3. The scopedPDU is encrypted using the salt and the secret privacy key for the user specified in
msgUserName.
4. The salt is inserted into the msgPrivacyParameters.
5. Authenticate the packet as previously described.
6. The packet is sent.
Receiving an encrypted SNMPv3 packet:
1. The packet is received.
2. If the authentication flag is turned on in the msgFlags, then the packet must be authenticated as
previously described and continue to step 3. If the authentication flag is turned off in the
msgFlags then decryption is skipped.
3. If the privacy flag is turned on in the msgFlags, then continue with the decryption process at
step 4. If the packet was not encrypted by the sender, the decryption is skipped.
4. Decrypt the scopedPDU using the salt specified in the msgSecurityParameters and the secret
privacy key for the user specified in msgUserName.
5. Continue processing the packet.
User Table
Every agent maintains a User Table which is used to store all the users that have access to the system
via SNMP. Each user entry in the table contains the following information, all of which can be
modified via SNMP operations on the USM MIB:
User Name
A human readable string representing the name of the user.
Authentication Protocol
An indication of whether or not messages sent or received on behalf of this user can be
:

authenticated and if so, which authentication protocol to use. The current values for this field
are: usmNoAuthProtocol, usmHMACMD5AuthProtocol, and usmHMACSHAAuthProtocol.
Authentication Key
The localized secret key used by the authentication protocol for authenticating messages.
Privacy Protocol
An indication of whether or not messages sent or received on behalf of this user can be
encrypted and if so, which privacy protocol to use. The current values for this field are:
usmNoPrivProtocol and usmDESPrivProtocol.
Privacy Key
The localized secret key used by the privacy protocol for encrypting and decrypting messages.

The User Table has a spin lock associated with it named usmUserSpinLock. A spin lock is an advisory
lock which is used to allow several SNMP managers to coordinate their attempts in modifying a MIB
table. The concept is simple. Whenever a change is going to be made to the User Table on an agent, the
value of the usmUserSpinLock must be retrieved via a GET command by the manager. Then the
manager sends a SET command to the agent which contains a PDU to set the usmUserSpinLock and
whatever variables in the User Table that need to be modified. The value of the usmUserSpinLock in
the SET command must be the value that was retrieved in the previous GET command. Once the agent
receives the message containing the SET command, the usmUserSpinLock is immediately processed.
If the current value of the usmUserSpinLock is not the same as the value specified in the SET
command, the SET operation has failed and an error is returned. If the two values are the same, then
the User Table variables specified in the PDU of the SET command are set. When the agent has
finished processing the entire PDU, the usmUserSpinLock value is incremented by one. As you can
see, if the value of the usmUserSpinLock is different when it is being set, then the User Table has been
modified since the initial retrieval of the usmUserSpinLock value.
Localized Keys
A localized key is a concept that allows the use of the same password for a user on many different
agents. It would be very cumbersome to be forced to remember a different password for each agent the
user exists. The localized key is computed using a one way hash function (e.g. MD5 or SHA-1) against
a secret password and the snmpEngineID of the agent where the user exists. This results in secret keys
that, although use the same password, are completely different for each agent.
Changing Keys
The USM introduces the KeyChange type which describes a convention for using secret keys. The
KeyChange definition provides a secure means of sending localized keys across networks which
allows users to change their keys. The following steps will occur when a user changes their key:
Manager:
1. The user enters in a new password.
2. The localized key is computed using the new password and the snmpEngineID of the agent
where the key is going to be changed.
3. A one-way function is used to produce a value from the old key.
4. This value is exclusively or'ed (XOR) with the new key.
5. The final KeyChange value is sent to the agent in a SET operation.
Agent: (after receiving the KeyChange SET operation)
1. The same one-way function that the manager used to produce a value from the old key is
performed.
2. This value is exclusively or'ed (XOR) with the received KeyChange to produce the new key.
3. The new key for the user is set in the User Table.
:

(G) View-based Access Control VACM

In general, there exist various ways to manage the access control, that is, determing the access rights of
a remote user to alter or view the local MIB. This means that the access control is a security function
that is performed at the PDU level. The access control mechanism intended to be used with SNMPv3 is
called View-Based Access Control (VACM), specified in RFC-2575.
The VACM is specified to determine the access rights per group basis. It defines the Elements of
Procedure for controlling access to management information. This document also includes a MIB for
remotely managing the configuration parameters for the View-based Access Control Model. The
VACM can simultaneously be associated in a single engine implementation with multiple Message
Processing Models and multiple Security Models. It is architecturally possible to have multiple,
different, Access Control Models active and present simultaneously in a single engine, but this is
expected to be very rare in practice and far less common than simultaneous support for multiple
Message Processing Models and/or multiple Security Models. This is different from the USM which
specifies the authentication of users individually. In VACM each user has to be included in some group
and the different groups can then be granted different security levels. This means that there might be,
for example, a group of root managers, which have the ultimate control to alter all the parameters in all
the managed nodes.
Additionally, there could be a group of minor, observing managers who would be granted only read
permissions to certain parts of each local MIB. The access rights are stored in different tables at the
node and each of the tables is consulted to determine the access rights of the requesting manager. The
procedure is based on the following concepts:
"Who" is the subject of the operation and is defined by securityModel and
securityName. This subject then belongs to one group at this SNMPv3 node.
The contextName specifies "where" the desired management object can be found.
"How" is the combination of securityModel and securityLevel and it defines how the incoming
request was protected.
The viewType specifies the type of access request ("why"). The options are read, write, or notify
access request.
The object of the SNMP operation ("what") is defined by the variableName. The final access
decision is made by comparing the variableName to the retrieved MIB view. If the variableName is
found in the MIB view the access is granted.