by William Stallings

Data networks typically include bridges, routers, links into WANs, and end-user equipment from multiple vendors. Users need automated tools to help manage such configurations that are easy to install, easy to use, and don't place a great burden on the network.

This accounts for the popularity of the Simple Network Management Protocol (SNMP). Introduced in 1988 to provide management capability for TCP/IP-based networks, SNMP rapidly became the most widely used standardized network management tool. Virtually all vendors of network-based equipment provide SNMP.

The appeal of SNMP has indeed been its simplicity because SNMP provides a bare-bones set of functions, and it is indeed easy to implement, install, and use. And, used sensibly, it will not place undue burden on the network. Moreover, because of its simplicity, achievement of interoperability is a relatively straightforward task: SNMP modules from different vendors can be made to work together with minimal effort.

SNMP—Strengths and Weaknesses
SNMP is based on three concepts: managers, agents, and the Management Information Base (MIB). In any configuration, at least one manager node runs SNMP management software. Network devices to be managed, such as bridges, routers, servers, and workstations, are equipped with an agent software module. The agent is responsible for providing access to a local MIB of objects that reflects the resources and activity at its node. The agent also responds to manager commands to retrieve values from the MIB and to set values in the MIB. An example of an object that can be retrieved is a counter that keeps track of the number of packets sent and received over a link into the node; the manager can track this value to monitor the load at that point in the network. An example of an object that can be set is one that represents the state of a link; the manager could disable the link by setting the value of the corresponding object to the disabled state.

Such capabilities are fine for implementing a basic network-management system. To enhance this basic functionality, a new version of SNMP was introduced in 1993 and revised in 1996. SNMPv2 added bulk transfer capability and other functional extensions. However, neither SNMPv1 nor SNMPv2 offers security features. Specifically, SNMPv1/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 these deficiencies, many SNMPv1/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.

Enter SNMPv3
To correct the security deficiencies of SNMPv1/v2, SNMPv3 was issued as a set of Proposed Standards in January 1998 (Table 1). This set of documents does not provide a complete SNMP capability but rather defines an overall SNMP architecture and a set of security capabilities. These are intended to be used with the existing SNMPv2. As one of the SNMPv3 working documents puts it, "SNMPv3 is SNMPv2 plus administration and security."

Table 1: SNMPv3 RFCs

RFC Number	Title
2271	An Architecture for Describing SNMP Management Frameworks
2272	Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
2273	SNMPv3 Applications
2274	User-Based Security Model for SNMPv3
2275	View-Based Access Control Model (VACM) for SNMP

SNMPv3 includes three important services: authentication, privacy, and access control (Figure 1). To deliver these services in a flexible and efficient manner, 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; a set of individuals, with each acting in a particular role; 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.


SNMPv3 is defined in a modular fashion, as shown in Figure 2. 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 (1) 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 (2) clearly specify coexistence and transition strategies.


Table 2 provides a brief definition of each module.

Table 2: Components of an SNMP Entity (RFC 2271 and 2273)

Dispatcher	Allows for concurrent support of multiple versions of SNMP messages in the SNMP engine. It is responsible for (1) accepting protocol data units (PDUs) from applications for transmission over the network and delivering incoming PDUs to applications; (2) passing outgoing PDUs to the Message Processing Subsystem to prepare as messages, and passing incoming messages to the Message Processing Subsystem to extract the incoming PDUs; and (3) sending and receiving SNMP messages over the network.
Message Processing Subsystem	Responsible for preparing messages for sending and for extracting data from received messages.
Security Subsystem	Provides security services such as the authentication and privacy of messages.This subsystem potentially contains multiple Security Models.
Access Control Subsystem	Provides a set of authorization services that an application can use for checking access rights. Access control can be invoked for retrieval or modification request operations and for notification generation operations.
Command Generator	Initiates SNMP Get, GetNext, GetBulk, or Set request PDUs and processes the response to a request that it has generated.
Command Responder	Receives SNMP Get, GetNext, GetBulk, or Set request PDUs destined for the local system as indicated by the fact that the contextEngineID in the received request is equal to that of the local engine through which the request was received.The command responder application performs the appropriate protocol operation, using access control, and generates a response message to be sent to the originator of the request.
Notification Originator	Monitors a system for particular events or conditions, and generatesTrap or Inform messages based on these events or conditions. A notification originator must have a mechanism for determining where to send messages, and which SNMP version and security parameters to use when sending messages.
Notification Receiver	Listens for notification messages, and generates response messages when a message containing an Inform PDU is received.
Proxy Forwarder	Forwards SNMP messages. Implementation of a proxy forwarder application is optional.

SNMPv3 Message Processing
SNMPv3 relies on the User Datagram Protocol (UDP) or some other transport-layer protocol to convey SNMP information. Above the UDP layer, SNMP functionality is organized into two application-level layers: a PDU processing layer and a message processing layer.

The topmost layer is the PDU processing layer. At this layer, management commands (such as Get, Set, Trap, Inform) are realized in a PDU Scope of 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.

Figure 3 illustrates 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 contextEngineID and contextName, constitute a scoped PDU, used for PDU processing.


The first five fields follow:

	msgVersion: Set to snmpv3(3).
	msgID: A unique identifier used between two SNMP entities to coordinate request and response messages, and by the message processor to coordinate the processing of the message by different subsystem models within the architecture. The range of this ID is 0 through 231 —1.
	msgMaxSize: Conveys the maximum size of a message in octets supported by the sender of the message, with a range of 484 through 2 31 —1. This is the maximum segment size that the sender can accept from another SNMP engine (whether a response or some other message type).
	msgFlags: An octet string containing three flags in the least significant three bits: reportableFlag, privFlag, authFlag. If reportableFlag = 1, then a Report PDU must be returned to the sender under those conditions that can cause the generation of a Report PDU; when the flag is zero, a Report PDU may not be sent. The reportableFlag is set to 1 by the sender in all messages containing a request (Get, Set) or an Inform, and set to 0 for messages containing a Response, a Trap, or a Report PDU. The reportableFlag is a secondary aid in determining when to send a Report. It is used only in cases in which the PDU portion of the message cannot be decoded (for example, when decryption fails because of incorrect key). The privFlag and authFlag are set by the sender to indicate the security level that was applied to the message. For privFlag = 1, encryption was applied and for privFlag = 0, authentication was applied. All combinations are allowed except (privFlag = 1 AND authFlag = 0); that is, encryption without authentication is not allowed.
	msgSecurityModel: An identifier in the range of 0 through 2 31 —1 that indicates which security model was used by the sender to prepare this message and, therefore, which security model must be used by the receiver to process this message. Reserved values include 1 for SNMPv1, 2 for SNMPv2c, and 3 for SNMPv3.

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, GetNext, GetBulk, 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. The security-related parameters include the following: msgAuthoritativeEngineID: 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. msgAuthoritativeEngineBoots: The snmpEngineBoots value of the authoritative SNMP engine involved in the exchange of this message. The object snmpEngineBoots is an integer in the range 0 through 2 31 —1 that represents the number of times that this SNMP engine has initialized or reinitialized itself since its initial configuration. msgAuthoritativeEngineTime: The snmpEngineTime value of the authoritative SNMP engine involved in the exchange of this message. The object snmpEngineTime is an integer in the 0 through 2 31 —1 range that represents the number of seconds since this authoritative SNMP engine last incremented the snmpEngineBoots object. Each authoritative SNMP engine is responsible for incrementing its own snmpEngineTime value once per second. A non-authoritative engine is responsible for incrementing its notion of snmpEngineTime for each remote authoritative engine with which it communicates. msgUserName: The user (principal) on whose behalf the message is being exchanged. msgAuthenticationParameters: Null if authentication is not being used for this exchange; otherwise, this is a privacy parameter. For the current definition of USM, the privacy parameter is a parameter used in the encryption algorithm DES.

Secret-Key Authentication
The authentication mechanism in SNMPv3 assures that a received message was, in fact, 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 artificially delayed or replayed.

To achieve authentication, 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 manually or 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.

Another aspect of USM authentication is timeliness verification. 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: synchronization and time-window checking. Each authoritative engine maintains two values, snmpEngineBoots and snmpEngineTime, that 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 fields 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 nonauthoritative 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.

Privacy Using Conventional Encryption
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.

View-Based Access Control Model (VACM)
The access control facility makes it possible 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. Unlike authentication, which is done by user, access control is done by group, where a group may be a set of multiple users.


Figure 4 illustrates the overall VACM logic, which proceeds in the following steps:

1.	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.
2.	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 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.
3.	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.
4.	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.
5.	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.
6.	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.

References
[0] The SNMPv3 RFCs, see Table 1 above.

[1] J. D. Case, M. Fedor, M. L. Schoffstall, and C. Davin, "Simple Network Management Protocol," RFC 1157, May 1990.

[2] Rose, M. T., The Simple Book: An Introduction to Networking Management, Revised Second Edition, Prentice-Hall, ISBN 0-13-451659-1, 1996.

[3] Waters, G., Editor, "User-based Security Model for SNMPv2," RFC 1910, February 1996.

[4] ConneXions—The Interoperability Report, Volume 10, No. 5, May 1996—Special Issue: "Network Management Today."

WILLIAM STALLINGS is a consultant, lecturer, and author of over a dozen books on data communications and computer networking. He has a PhD in computer science from M.I.T. This article is based on material in the author's latest book: SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, Second Edition (Addison Wesley, 1998). His home in cyberspace and he can be reached at ws@shore.net