snmp v2 and v3

42
SNMP V2 & V3 SNMP V2 & V3

Upload: bharathkumar363

Post on 18-Sep-2015

252 views

Category:

Documents


9 download

DESCRIPTION

SNMP V2 AND V3 DIFFERENCES

TRANSCRIPT

  • SNMP V2 & V3

  • SNMP V2 ProtocolRFC 34163 types of access to management informationManageragent request-responseManager-Manager request-response : different from SNMPV1Agent-manager unconfirmed

  • SNMP V2 Message Structure

  • SNMPV2 PDU Formats

  • PDU Details (1)request-id :unique number to each outstanding request to the same agenterror-status: a non-zero value indicates that an exception occurrederror-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 beValue Value associated with each object instancesunSpecified a NULL values is used in retrieval requestsNoSuchObject indicates agent does not implement the object refered this OID noSuchInstance indicates that this object instance does not exist for this operationendOfMibView 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 PDUSame as SNMPv1, it is different only the way that responses are handledSNMP v1 operation is atomicSNMP 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

  • GetNextRequestPDUSame as SNMPv1, it is different only the way that responses are handledSNMP v1 operation is atomicSNMP 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 informationIt uses the same selection principle as the GetNextRequest but multiple lexicographic successor can be selected2 additional fields Non-repeaters the number of variables that single successor value to be returnedMax-repetitions the number of successor value to be returned

  • GetBulkRequest PDU (2)

  • SetRequest PDUThe structure is same as SNMPv1SetRequest PDU for SNMPv1 and SNMPv2 is both atomic operation

  • SNMPv2-Trap PDUThe format is different from SNMPv1It uses the same format as GetRequestPDU Using variable bindings field to containsysUpTime.0snmpTrapOID.0- If the OBJECT clause is present in the macro NOTIFICATION-TYPE, each variable and its value are copied to the variable-binding

  • InformRequest PDUNew PDU type for SNMPManager to Manager operationResponse by using Response PDU

  • SNMPv2 MIB (1)System Group : include MIB for Object ResourcessysORlast changesysORTable

  • SNMPv2 MIB (2)System Group of SNMPv2

  • SNMPv2 MIB (3)

  • Revised SNMP Group

  • SNMPv2 MIB (4)MIB Objects GroupsnmpTrapsnmpTrapOID : OID of trap or notification currently being sentsnmpTrapEnterprise :OID of enterprise associated with the trap currently being sent

  • SNMPv2 MIB (5)snmpSetsnmpSerialNo : 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 231If the agent receive a set operation for this object with value not equal to K then the operation fails with an error of inconsistentValueTo solve multiple managers using an agent

  • SNMPv2 MIB (6)Interfaces Group in RFC1573 : extension of interface Group in MIB-IIifXTable (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

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

  • SNMP engineAn SNMP engine provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects.a Dispatchera Message Processing Subsystema Security Subsysteman Access Control Subsystem.

  • SNMP ManagerAn 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 AgentAn 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

  • SNMPv3 Message FormatSNMPv3 message format is very different from the above two because of lot of security parameters introduced in this version. Below is how it looks like:

  • 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 3Engine Time This field has the snmpEngineTime value of the authoritative SNMP entity involved in the transaction

  • 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