SNMP V2 & V3

W.lilakiatsakun

SNMP V2 Protocol

• RFC 3416• 3 types of access to management information– Manager–agent request-response– Manager-Manager request-response : different

from SNMPV1– Agent-manager unconfirmed

SNMP V2 Message Structure

SNMPV2 PDU Formats

PDU Details (1)

• request-id :unique number to each outstanding request to the same agent

• error-status: a non-zero value indicates that an exception occurred

• error-index: When the error-status field is nonzero, the error-index value identifies the object that caused the error

PDU Details (2)

• variable-bindings: this field enables a single operation to be applied to a group of object instances – First element is an OID (Object Identifier)– Second element can be

• Value – Value associated with each object instances• unSpecified – a NULL values is used in retrieval requests• NoSuchObject – indicates agent does not implement the object refered

this OID • noSuchInstance – indicates that this object instance does not exist for

this operation• endOfMibView – indicates an attempt to reference an OID that is

beyond the end of the MIB at the agent

SNMP V2 Operations

Comparison of SNMPv1 and SNMPv2 PDUs

Error Status Codes in response-PDU

Values in Variable Bindings

GetRequest PDU

• Same as SNMPv1, it is different only the way that responses are handled

• SNMP v1 operation is atomic• SNMP v2 operation prepares variable binding

according to following rules1 OID not match – value is set to noSuchObject2 Otherwise, but not accessible for operation – value

is set to noSuchInstance3 Otherwise, value is set to the value of variable

GetNextRequestPDU

• Same as SNMPv1, it is different only the way that responses are handled

• SNMP v1 operation is atomic• SNMP v2 processes as many as possible by the

following rule1 the next instance can be retrieved, set the name and value

in variable-bindings2 if no lexicographic successor exists, set the value field to

endOfMibView

GetBulkRequest PDU (1)• Its purpose is to minimize the number of protocol

exchanges required to retrieve a large amount of management information

• It uses the same selection principle as the GetNextRequest but multiple lexicographic successor can be selected

• 2 additional fields – Non-repeaters – the number of variables that single

successor value to be returned– Max-repetitions – the number of successor value to be

returned

GetBulkRequest PDU (2)

SetRequest PDU

• The structure is same as SNMPv1• SetRequest PDU for SNMPv1 and SNMPv2 is

both atomic operation

SNMPv2-Trap PDU

• The format is different from SNMPv1• It uses the same format as GetRequestPDU • Using variable bindings field to contain– sysUpTime.0– snmpTrapOID.0- If the OBJECT clause is present in the macro

NOTIFICATION-TYPE, each variable and its value are copied to the variable-binding

InformRequest PDU

• New PDU type for SNMP• Manager to Manager operation• It uses the same format as GetRequestPDU • Using variable bindings field to contain– sysUpTime.0– snmpTrapOID.0- If the OBJECT clause is present in the macro

NOTIFICATION-TYPE, each variable and its value are copied to the variable-binding

• Response by using Response PDU

SNMPv2 MIB (1)

• System Group : include MIB for Object Resources– sysORlast change– sysORTable

SNMPv2 MIB (2)

System Group of SNMPv2

SNMPv2 MIB (3)

Revised SNMP Group

SNMPv2 MIB (4)

• MIB Objects Group– snmpTrap• snmpTrapOID : OID of trap or notification currently

being sent• snmpTrapEnterprise :OID of enterprise associated with

the trap currently being sent

SNMPv2 MIB (5)

– snmpSet• snmpSerialNo : TestAndIncr (INTEGER 0..2147483647)• If the agent receive a set operation for this object with

value K then the value is incremented to K+1 mod 231

• If the agent receive a set operation for this object with value not equal to K then the operation fails with an error of inconsistentValue• To solve multiple managers using an agent

SNMPv2 MIB (6)

• Interfaces Group in RFC1573 : extension of interface Group in MIB-II– ifXTable (Extension Table)– ifStackTable (Stack Table)– ifTestTable (Test Table)– IfRcvAddressTable (Receive Address Table)

SNMPv2 MIB (7)

• ifXTable – This table contains objects that have been added t

o the Interface MIB as a result of the Interface Evolution effort, or replacements for objects of the original, MIB-II, ifTable that were deprecated because the semantics of said objects have significantly changed.

SNMPv2 MIB (8)

• ifStackTable – This table contains objects that define the relationships a

mong the sub-layers of an interface.

• ifTestTable – This table contains objects that are used to perform tests o

n interfaces. – This table is a generic table. – The designers of media-specific MIBs must define exactly h

ow this table applies to their specific MIB.

SNMPv2 MIB (9)

• ifRcvAddressTable – This table contains objects that are used to define

the media-level addresses which this interface will receive.

– This table is a generic table. – The designers of media- specific MIBs must define

exactly how this table applies to their specific MIB.

SNMP V3

W.lilakiatsakun

Related RFC

• RFC 3411 — An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks

• RFC 3412 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)

• RFC 3413 — Simple Network Management Protocol (SNMP) Applications

• RFC 3414 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)

• RFC 3415 — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)

SNMP v3 Goals (1)

• Use existing materials as much as possible. – It is heavily based on previous work, informally known as

SNMPv2u and SNMPv2*, based in turn on SNMPv2p. • Address the need for secure SET support, which is

considered the most important deficiency in SNMPv1 and SNMPv2c.

• Make it possible to move portions of the architecture forward in the standards track, even if consensus has not been reached on all pieces.

• Define an architecture that allows for longevity of the SNMP Frameworks that have been and will be defined.

SNMP v3 Goals (2)

• Keep SNMP as simple as possible. • Make it relatively inexpensive to deploy a minimal

conforming implementation. • Make it possible to upgrade portions of SNMP as new

approaches become available, without disrupting an entire SNMP framework.

• Make it possible to support features required in large networks, but make the expense of supporting a feature directly related to the support of the feature.

Security Requirement (1)

• Modification of Information – Some unauthorized entity may alter in-transit SNMP

messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object.

• Masquerade – Management operations not authorized for some pri

ncipal may be attempted by assuming the identity of another principal that has the appropriate authorizations.

Security Requirement (2)

• Message Stream Modification – Messages may be maliciously re-ordered, delayed or replay

ed to an extent which is greater than can occur through the natural operation of a subnetwork service, in order to effect unauthorized management operations.

• Disclosure – Eavesdropping on the exchanges between SNMP engines. – Protecting against this threat may be required as a matter o

f local policy.

Not in Security requirement

• Denial of Service – Indeed, such denial-of-service attacks are in many cases ind

istinguishable from the type of network failures with which any viable management protocol must cope as a matter of course.

• Traffic Analysis– Many traffic patterns are predictable - entities may be man

aged on a regular basis by a relatively small number of management stations - and therefore there is no significant advantage afforded by protecting against traffic analysis.

SNMP Entity

SNMP engine

• An SNMP engine provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects.– a Dispatcher– a Message Processing Subsystem– a Security Subsystem– an Access Control Subsystem.

Dispatcher

• It allows for concurrent support of multiple versions of SNMP messages in the SNMP engine.

• It does so by: – sending and receiving SNMP messages to/from the network, – determining the version of an SNMP message and interactin

g with the corresponding Message Processing Model– providing an abstract interface to SNMP applications for deli

very of a PDU to an application. – providing an abstract interface for SNMP applications that al

lows them to send a PDU to a remote SNMP entity.

Message Processing Subsystem

• The Message Processing Subsystem is responsible for preparing messages for sending, and extracting data from received messages.

Security Subsytem

• The Security Subsystem provides security services such as the authentication and privacy of messages and potentially contains multiple Security Models

* User-Based Security (RFC 3414)

Security Model

• A Security Model specifies the threats against which it protects, the goals of its services, and the security protocols used to provide security services such as authentication and privacy.

• A Security Protocol specifies the mechanisms, procedures, and MIB objects used to provide a security service such as authentication or privacy.

Access Control Subsytem

• The Access Control Subsystem provides authorization services by means of one or more (*) Access Control Models.

* View-Based Access Control (RFC 3415)

Application

• There are several types of applications, including:– Command generators, which monitor and manipulate man

agement data – Command responders, which provide access to manageme

nt data– Notification originators, which initiate asynchronous messa

ges– Notification receivers, which process asynchronous messag

es, and – Proxy forwarders, which forward messages between entiti

es.

SNMP Manager

• An SNMP entity containing one or more command generator and/or notification receiver applications (along with their associated SNMP engine) has traditionally been called an SNMP manager

SNMP Traditional Manager

SNMP Agent

• An SNMP entity containing one or more command responder and/or notification originator applications (along with their associated SNMP engine) has traditionally been called an SNMP agent

SNMP Traditional Agent

SNMP Process

SNMP Security Function (1)

• User-based security (RFC3414)– Encryption : DES (Data Encryption Standard) in

CBC (Cipher Block Chaining) mode– Authentication :Combine the use of a hash

function with a secret key to provide both authentication and protection against tampering :HMAC (Hashed Message Authentication Codes) [RFC2104]• the HMAC-MD5-96 authentication protocol.• the HMAC-SHA-96 authentication protocol.

SNMP Security Function (2)

• Protection against playback– The receiver requires that the sender include a value in each

message that is based on a counter in the receiver.– This counter which functions as a nonce– RFC3414 for details

• Access Control : VBAC (View-Based Access Control) [RFC3415] – It Controls which network management information can be

queried and/or set by which users.– An SNMP entity retains information about access rights and

policies in a Local Configuration Datastore (LCD)

VBAC (View-Based Access Control)

• Access ‘s right will be given by– The read-view represents the set of object

instances authorized for the group when reading objects.

– The write-view represents the set of object instances authorized for the group when writing objects.

– The notify-view represents the set of object instances authorized for the group when sending objects in a notification, such as when sending a notification

VBAC (View-Based Access Control)