Chapter 7 SNMPv3 SNMPv3 was developed to meet the need for better security in SNMP management. Fortunately,SNMPv3 addressed more than just security:It now provides a framework for all three versions of SNMP and future development in SNMP management with minimum impact on existing operations. One of the key features of SNMPv3 is the modularization of documentation and architecture. Another key feature is improved security
Chapter 7 SNMPv3 SNMPv3 was developed to meet the need for better security in SNMP management. Fortunately, SNMPv3 addressed more than just security: It now provides a framework for all three versions of SNMP and future development in SNMP management with minimum impact on existing operations. One of the key features of SNMPv3 is the modularization of documentation and architecture. Another key feature is improved security
7.1 SNMPv3 Documentation published in January 1998 and listed in SNMPy3 RFCs: RFC 2271 An Architecture for Describing SNMP Management Frameworks RFC 2272 Message Processing and Dispatching for SNMP RFC 2273 SNMPv3 Applications RFC 2274 User-based Security Model (USM)for SNMPV3 RFC2275 View-based Access Control Model for SNMP
7.1 SNMPv3 Documentation published in January 1998 and listed in SNMPv3 RFCs: RFC 2271 An Architecture for Describing SNMP Management Frameworks RFC 2272 Message Processing and Dispatching for SNMP RFC 2273 SNMPv3 Applications RFC 2274 User-based Security Model (USM) for SNMPV3 RFC2275 View-based Access Control Model for SNMP
Chapter 7 SNMPy3 7.2 SNMPv3 Documentation Architecture The numerous SNMP documents have been organized into a document architecture.It addresses how existing documents and new documents can be designed to be autonomous and,at the same time, be integrated to provide documentation for the various SNMP frameworks.The representation shown in Figure 7.1 reflects the contents of the specifications,but is a different perspective than that given in [RFC 2271].It can be correlated with what we presented in Figure 4.4.Two sets of documents are general in nature.One is the set of documents covering the roadmap,the applicability statement, and coexistence and transition
Chapter 7 SNMPv3 7.2 SNMPv3 Documentation Architecture The numerous SNMP documents have been organized into a document architecture. It addresses how existing documents and new documents can be designed to be autonomous and, at the same time, be integrated to provide documentation for the various SNMP frameworks. The representation shown in Figure 7.1 reflects the contents of the specifications, but is a different perspective than that given in [RFC 2271]. It can be correlated with what we presented in Figure 4.4. Two sets of documents are general in nature. One is the set of documents covering the roadmap, the applicability statement, and coexistence and transition
7.3 Architecture An SNMP management network consists of several nodes,each with an SNMP entity.They interact with each other in monitoring and managing the network and its resources.The architecture of an SNMP entity is defined as the elements of that entity and the names associated with them.There are three kinds of naming: naming of entities,naming of identities,and naming of management information.Let us first look at the elements of an entity,including naming of the entity. 7.3.1 Elements of an Entity The elements of the architecture associated with an SNMP entity,shown in Figure 7.2,comprise an SNMP engine and a set of applications.The SNMP engine, named snmpEnginelD,consists of a dispatcher,a message processing subsystem,a security subsystem, and an access control subsystem
7.3 Architecture An SNMP management network consists of several nodes, each with an SNMP entity. They interact with each other in monitoring and managing the network and its resources. The architecture of an SNMP entity is defined as the elements of that entity and the names associated with them. There are three kinds of naming: naming of entities, naming of identities, and naming of management information. Let us first look at the elements of an entity, including naming of the entity. 7.3.1 Elements of an Entity The elements of the architecture associated with an SNMP entity, shown in Figure 7.2, comprise an SNMP engine and a set of applications. The SNMP engine, named snmpEngineID, consists of a dispatcher, a message processing subsystem, a security subsystem, and an access control subsystem
SNMP entity SNMP Engine(identified by snmpEnginelD) Message Access Dispatcher Processing Security Subsystem Control Subsystem Application(s) 兮9030月Q乡ga2v4形 Proxy Command Notification Forwarder Generator Receiver Subsystem Command Notification 后AN Other Responder Originator Figure 7.2 SNMPv3 Architecture
Chapter 7 SNMPv3 The SNMP Engine.As shown in Figure 7.2,an SNMP entity has one SNMP engine,which is identified by a unique snmpEngineID.The SNMP engine ID is made up of octet strings.The length of the ID is twelve octets for SNMPv1 and SNMPv2,and is variable for SNMPv3,as shown in Figure 7.3.The first four octets in both formats are set to the binary equivalent of the agent's SNMP management private enterprise number.The first bit of the four octets is set to 1 for SNMPv3 and 0 for earlier versions.For example,if Acme Networks has been assigned {enterprises 696}, the first four octets would read '800002b8'H in SNMPv3 and '000002b8'Hin SNMPy1 and SNMPv2. Hint 696=512+128+56+16+8=1010111000=2b8=000002b8
Chapter 7 SNMPv3 The SNMP Engine. As shown in Figure 7.2, an SNMP entity has one SNMP engine,which is identified by a unique snmpEngineID. The SNMP engine ID is made up of octet strings. The length of the ID is twelve octets for SNMPv1 and SNMPv2, and is variable for SNMPv3, as shown in Figure 7.3. The first four octets in both formats are set to the binary equivalent of the agent's SNMP management private enterprise number. The first bit of the four octets is set to 1 for SNMPv3 and 0 for earlier versions. For example, if Acme Networks has been assigned {enterprises 696}, the first four octets would read '800002b8'H in SNMPv3 and '000002b8'H in SNMPv1 and SNMPv2. Hint 696=512+128+56+16+8=1010111000=2b8=000002b8
Chapter 7 SNMPv3 7.3.2 Names Naming of entities,identities,and management information is part of SNMPv3 specifications.We have already mentioned the naming of an entity by its SNMP engine ID,snmpEnginelD.Two names are associated with identities,principal and securityName.The principal is the "who"requesting services.It could be a person or an application.The securityName is a human-readable string representing a principal.The principal could be a single user or a group of users.The principal is made nonaccessible;it is hidden and is protected by the security method being used. A management entity can be responsible for more than one managed object
Chapter 7 SNMPv3 7.3.2 Names Naming of entities, identities, and management information is part of SNMPv3 specifications. We have already mentioned the naming of an entity by its SNMP engine ID, snmpEngineID. Two names are associated with identities, principal and securityName. The principal is the "who" requesting services. It could be a person or an application. The securityName is a human-readable string representing a principal. The principal could be a single user or a group of users. The principal is made nonaccessible; it is hidden and is protected by the security method being used. A management entity can be responsible for more than one managed object
7.4 SNMPv3 Applications SNMPv3 formally defines five types of applications, but they are not the same as those of the functional model that the OSI model addresses.They may be considered as the application service elements used to build applications.They are the command generator,command responder,notification originator, notification receiver,and proxyi forwarder and are described in RFC 2273. 7.4.1 The Command Generator The command generator application is used to generate get-request,get-next-request,get-bulk,and set-request messages.It also processes the response to the command sent.Typically,the command generator application is associated with the network manager process
7.4 SNMPv3 Applications SNMPv3 formally defines five types of applications, but they are not the same as those of the functional model that the OSI model addresses. They may be considered as the application service elements used to build applications. They are the command generator,command responder, notification originator, notification receiver,and proxy forwarder and are described in RFC 2273. 7.4.1 The Command Generator The command generator application is used to generate get-request, get-next-request, get-bulk, and set-request messages. It also processes the response to the command sent. Typically, the command generator application is associated with the network manager process
Chapter 7 SNMPv3 7.4.2 The Command Responder The command responder processes the get and set requests destined for it from a legitimate remote entity.It performs the appropriate action of get or set on the network element,prepares a get- response message,and sends it to the remote entity that made the request,as shown in Figure 7.6.In contrast to Figure 7.5,which depicts two asynchronous processes,the processes shown in Figure 7.6 are run concurrently.Typically,the command responder is in the management agent associated with the managed object
Chapter 7 SNMPv3 7.4.2 The Command Responder The command responder processes the get and set requests destined for it from a legitimate remote entity. It performs the appropriate action of get or set on the network element, prepares a getresponse message, and sends it to the remote entity that made the request, as shown in Figure 7.6. In contrast to Figure 7.5, which depicts two asynchronous processes, the processes shown in Figure 7.6 are run concurrently. Typically, the command responder is in the management agent associated with the managed object
7.4.3 The Notification Originator The notification originator application generates either a trap or an inform message.Its function is somewhat similar to that of the command responder,except that it needs to find out where to send the message and what SNMP version and security parameters to use. Further,the notification generator must determine the contextEnginelD and the name of the context that has the information to be sent.It obtains these data using newly created MIBs for the notification and target groups,as well as using other modules in the system. 7.4.4 The Notification Receiver The notification receiver application receives SNMP notification messages.It registers with the SNMP engine to receive these messages,just as the command responder application does to receive get/set messages
7.4.3 The Notification Originator The notification originator application generates either a trap or an inform message. Its function is somewhat similar to that of the command responder, except that it needs to find out where to send the message and what SNMP version and security parameters to use. Further, the notification generator must determine the contextEngineID and the name of the context that has the information to be sent. It obtains these data using newly created MIBs for the notification and target groups, as well as using other modules in the system. 7.4.4 The Notification Receiver The notification receiver application receives SNMP notification messages. It registers with the SNMP engine to receive these messages, just as the command responder application does to receive get/set messages