1. SNMP V2 & V3 W.lilakiatsakun

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

3. SNMP V2 Message Structure

4. SNMPV2 PDU Formats

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

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

7. SNMP V2 Operations

8. Comparison of SNMPv1 and SNMPv2 PDUs

9. Error Status Codes in response-PDU

10. Values in Variable Bindings

11. 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 2 Otherwise, but not accessible for operation – value is set to noSuchInstance 3 Otherwise, value is set to the value of variable

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

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

14. GetBulkRequest PDU (2)

15. SetRequest PDU The structure is same as SNMPv1 SetRequest PDU for SNMPv1 and SNMPv2 is both atomic operation

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

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

18. SNMPv2 MIB (1) System Group : include MIB for Object Resources – sysORlast change – sysORTable

19. SNMPv2 MIB (2) System Group of SNMPv2

20. SNMPv2 MIB (3)

21. Revised SNMP Group

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

23. 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 2 31 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

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

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

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

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

29. SNMP V3 W.lilakiatsakun

30. Related RFC RFC 3411 — An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks RFC 3411 RFC 3412 — Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) RFC 3412 RFC 3413 — Simple Network Management Protocol (SNMP) Applications RFC 3413 RFC 3414 — User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) RFC 3414 RFC 3415 — View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) RFC 3415

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

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

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

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

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

36. SNMP Entity

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

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

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

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

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

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

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

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

45. SNMP Traditional Manager

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

47. SNMP Traditional Agent

48. SNMP Process

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

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

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

52. VBAC (View-Based Access Control)