500 likes | 870 Views
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).
E N D
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
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
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 rules 1 OID not match – value is set to noSuchObject 2Otherwise, but not accessible for operation – value is set to noSuchInstance 3Otherwise, 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 rule 1 the next instance can be retrieved, set the name and value in variable-bindings 2 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
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 • 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 (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 to 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 among the sub-layers of an interface. • ifTestTable • This table contains objects that are used to perform tests on interfaces. • This table is a generic table. • The designers of media-specific MIBs must define exactly how 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
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 principal 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 replayed 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 of local policy.
Not in Security requirement • Denial of Service • Indeed, such denial-of-service attacks are in many cases indistinguishable 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 managed 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 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 interacting with the corresponding Message Processing Model • providing an abstract interface to SNMP applications for delivery of a PDU to an application. • providing an abstract interface for SNMP applications that allows 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)
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 management data • Command responders, which provide access to management data • Notification originators, which initiate asynchronous messages • Notification receivers, which process asynchronous messages, and • Proxy forwarders, which forward messages between entities.
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 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 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]
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)