0
16kviews
What is SNMP v3 MIB, message format, architecture, engine ID, security services?

Subject: Telecom Network Management

Topic: Internet Management(SNMP)

Difficulty: Medium

2 Answers
0
282views

SNMP v3 MIB:

i) Figure1 shows the MIB of the new object groups. They are nodes under snmpModules.

ii) There are seven new MIB groups. The snmpFrameworkMlB, node 10 under snmpModules, describes the SNMP Management architecture. The MIB group snmpMPDMIB (node 11) identifies objects in message processing and dispatching subsystems.

SNMPv3 MIB

iii) There are three groups defined under snmpModules for applications. They are snmpTargetMIB (node 12), snmpNotificationMIB (node 13), and snmpProxyMIB (node 14).

iv) The first two are used for notification generator. The snmpTargetMIB defines MIB objects, which are used to remotely configure the parameters used by a remote SNMP entity. There are two tables in that MIB, which are of specific interest for us. They are shown in Figure2.

Target Address and Target Parameter Table

The snmpTargetAddrTable, which is in snmpTargetObjects group, contains the addresses to be used in the generation of SNMP messages. There are nine columnar objects in the table, which are listed in Table1.

SNMP Target Address Table

Message Format:

The SNMPv3 message format is shown in Figure3.

SNMPv3 General Message Format

Msg Version: Syntex – Integer, Size (bytes) – 4 Message Version Number: Describes the SNMP version number of this message; used for ensuring compatibility between versions. For SNMPv3, this value is 3.

MsgID :Syntax-Integer, Size (bytes) – 4 Message Identifier: A number used to identify an SNMPv3 message and to match response messages to request messages.

Msg Max Size: Syntax -Integer,Size (bytes) – 4 Maximum Message Size: The maximum size of message that the sender of this message can receive. Minimum value of this field is 484.

Msg Flags: Syntax - Octet String, Size (bytes) – 1

Msg Security Model: Syntax -Integer, Size (bytes) – 4 An integer value indicating which security model was used for this message. For the user-based security model this value is 3.

Msg Security Parameters: Size (bytes) –Variable Message Security Parameters: A set of fields that contain parameters required to implement the particular security model used for this message.

Scoped PDU: - Size (bytes) – Variable

Architecture:

The architecture of an SNMP entity is defined as the elements of an entity and the names associated with them. There are three kinds of naming: naming of entities, naming of identities, and naming of management information.

Elements of an Entity:

The elements of the architecture associated with an SNMP entity, shown in Figure4, comprise an SNMP engine and a set of applications. The SNMP engine, named snmpEnginelD, comprises a dispatcher, message processing subsystem, security subsystem, and an access control subsystem.

SNMP Engine: i) As shown in Figure4, an SNMP entity has one SNMP engine, which is uniquely identified by ansnmpEnginelD. The SNMP engine ID is made up of octet strings. The length of the ID is 12 octets for SNMPvI and SNMPv2, and is variable for SNMPv3.

ii) 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.

iii) The fifth octets for SNMPv l and SNMPv2 indicate the method that the enterprise used for deriving the SNMP engine ID and 6-12 octets function of the method.

iv) For a simple entity, it could be just the IP address of the entity. The fifth octet of the SNMPv3 engine ID indicates the format used in the rest of the variable number of octets.

SNMPv3 Architecture

Engine ID: SNMPv3 engine ID indicates the format used in the rest of the variable number of octets.

Engine ID

security services :

The security subsystem provides security services at the message level in terms of authentication and privacy protection. The access control subsystem provides access authorization service.

0
120views
  1. SNMP v3 MIB:

• SNMP agents expose management data on the managed systems as variables.

• The protocol also permits active management tasks, such as configuration changes, through remote modification of these variables.

• The variables accessible via SNMP are organized in hierarchies.

• SNMP itself does not define which variables a managed system should offer. Rather, SNMP uses an extensible design which allows applications to define their own hierarchies. These hierarchies, are described as a management information base (MIB).

• MIBs describe the structure of the management data of a device subsystem; they use a hierarchical namespace containing object identifiers (OID). Each OID identifies a variable that can be read or set via SNMP.

• MIBs use the notation defined by Structure of Management Information Version 2.0 (SMIv2, RFC 2578), a subset of ASN.1.

• Figure shows the MIB of the new object groups. They are nodes under snmpModules.

• There are seven new MIB groups. The snmpFrameworkMlB, node 10 under snmpModules, describes the SNMP Management architecture. The MIB group snmpMPDMIB (node 11) identifies objects in message processing and dispatching subsystems.

• There are three groups defined under snmpModules for applications. They are snmpTargetMIB (node 12), snmpNotificationMIB (node 13), and snmpProxyMIB (node 14).

• The first two are used for notification generator. The snmpTargetMIB defines MIB objects, which are used to remotely configure the parameters used by a remote SNMP entity..

  1. Message Format:

• The SNMPv3 message format is shown in Figure

• Version – It is an Integer that identifies the version of SNMP. For SNMPv3, it is 3.

• ID – This field contains the SNMP message identifier which is a unique ID associated with the message. The msgID field is different from the reqID field available in the PDU.

• Max Size – This field represents the maximum size of message which the requesting SNMP entity can accept.

• Flags – This field contains the message security level. 0 – message is authenticated, 1 – message uses privacy, 2 – a report PDU is expected for the message

• Security Model – This field indicates the security model used to generate the message. When USM is used, it has a value of 3

• Engine ID – This field has the SNMPEngineID of the authoritative SNMP entity involved in the transaction. When a request PDU is generated from an SNMP engine, the remote peer (agent for Get request and manager for Trap request) is the authoritative SNMP entity.

• Engine Boots – This field has the snmpEngineBoots value of the authoritative SNMP entity involved in the transaction

• Engine Time – This field has the snmpEngineTime value of the authoritative SNMP entity involved in the transaction

• User Name – This field contains the principal who originated the request.

• Security Parameters – This field contains the security parameters that are security model dependent. It contains the authentication parameters and the privacy parameters for USM.

• Context Engine ID – Within an administrative domain, the contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName.

• Context Name – A contextName is used to name a context. Each contextName must be unique within an SNMP entity.

• PDU – The SNMP PDU (Protocol Data Unit) is used for communication between the SNMP entities.

  1. Architecture:

• An SNMP entity is a node with an SNMP management element – either an agent or manager or both.

• The architecture of an SNMP entity consists of the elements of the entity and the names associated with it.

• There are three names associated with an entity – 1.Entities: e.g. SNMP engine (snmpEngineID) . 2. Identities: e.g. Principal and security name 3. Management Information: Used when multiple objects are managed. E.g. Context engine SNMP Engine:

• The engine is composed of four pieces: the Dispatcher, the Message Processing Subsystem, the Security Subsystem, and the Access Control Subsystem.

• The Dispatcher's job is to send and receive messages. It tries to determine the version of each received message (i.e., v1, v2, or v3) and, if the version is supported, hands the message off to the Message Processing Subsystem. The Dispatcher also sends SNMP messages to other entities.

• The Message Processing Subsystem prepares messages to be sent and extracts data from received messages. A message processing system can contain multiple message processing modules. For example, a subsystem can have modules for processing SNMPv1, SNMPv2, and SNMPv3 requests. It may also contain a module for other processing models that are yet to be defined.

• The Security Subsystem provides authentication and privacy services. Authentication uses either community strings (SNMP Versions 1 and 2) or SNMPv3 user-based authentication. User-based authentication uses the MD5 or SHA algorithms to authenticate users without sending a password in the clear. The privacy service uses the DES algorithm to encrypt and decrypt SNMP messages. Currently, DES is the only algorithm used, though others may be added in the future.

• The Access Control Subsystem is responsible for controlling access to MIB objects. You can control what objects a user can access as well what operations she is allowed to perform on those objects. For example, you might want to limit a user's read-write access to certain parts of the mib-2 tree, while allowing read-only access to the entire tree.

SNMP Applications:

• Version 3 divides SNMP into a number of applications:

  1. Command generator:

• Generates get, get-next, get-bulk, and set requests and processes the responses. This application is implemented by a Network Management Station (NMS), so it can issue queries and set requests against entities on routers, switches, Unix hosts, etc.

  1. Command responder:

• Responds to get, get-next, get-bulk, and set requests. This application is implemented by an entity on a Cisco router or Unix host. (For Versions 1 and 2, the command responder is implemented by the SNMP agent.)

  1. Notification originator:

• Generates SNMP traps and notifications. This application is implemented by an entity on a router or Unix host. (For Versions 1 and 2, the notification originator is part of an SNMP agent. Freestanding utilities for generating traps are also available.)

  1. Notification receiver:

• Receives traps and inform messages. This application is implemented by an NMS.

  1. Proxy forwarder:

• Facilitates message-passing between entities.

  1. Engine ID:

• SNMPv3 engine ID indicates the format used in the rest of the variable number of octets.

• As shown in Figure, an SNMP entity has one SNMP engine, which is uniquely identified by ansnmpEnginelD. The SNMP engine ID is made up of octet strings. The length of the ID is 12 octets for SNMPvI and SNMPv2, and is variable for SNMPv3.

• 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.

• The fifth octets for SNMPv l and SNMPv2 indicate the method that the enterprise used for deriving the SNMP engine ID and 6-12 octets function of the method.

• For a simple entity, it could be just the IP address of the entity. The fifth octet of the SNMPv3 engine ID indicates the format used in the rest of the variable number of octets.

  1. Security services :

• SNMP entities contain a security subsystem (and possibly an access control subsystem) to prevent unauthorized users from accessing a MIB or parts of a MIB.

• SNMP entities also possess these subsystems to ensure that authorized users retrieve and update information from only the parts of the MIB that they are allowed to view.

• Only a user who has the necessary access privileges will be able to obtain the desired level of service from a properly configured SNMP entity.

• A Security Administration Framework defines the mechanisms, which control the level of service provided by an SNMP entity.

• The mechanisms discriminate each message based on who is sending the message, what operation is requested, where the operation takes place within the MIB, and how the request is being sent (security protocol in use).

  1. Who? -- Authentication discriminates a request based on the sender of the message. An authentication identifier includes some type of shared secret, which is used to verify the identity of the sender.

  2. What? -- Authorization discriminates a request based on the operation being requested. An authorization identifier defines a set of operations that are permitted (e.g., Get, Set, Trap, etc.).

  3. Where? -- Access Control discriminates a request based on the MIB objects where a requested operation would be performed. An access control identifier, or MIB View, defines a set of objects in the MIB where operations may be performed.

  4. How? -- Security Level discriminates a request based on the security protocols used for a request. Security level options include privacy protocols and alternative authentication algorithms.

    SNMP Provides some security services such as:

• Authentication – Data integrity:

  1. HMAC-MD5-96

  2. HMAC-SHA-96

• Data origin authentication

Append to the message a unique Identifier associated with the authoritative SNMP engine

• Privacy – Encryption is used

Cipher Block Chaining mode of the Data Encryption Standard (DES) is suggested.

• Timeliness – Used to prevent message redirection, delay, and replay. – Authoritative Engine ID, No. of engine boots and time in seconds (recommended window time of 150 s).

Please log in to add an answer.