SNMPv2

1. SNMPv2 Network Management Spring 2014 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology This presentation is based on the slides listed in references.

2. Outline • Introduction • SNMPv2 Architecture • SNMPv2 SMI • SNMPv2 MIB • SNMPv2 Protocol • Conclusion

3. Outline • Introduction • SNMPv2 Architecture • SNMPv2 SMI • SNMPv2 MIB • SNMPv2 Protocol • Conclusion

4. SNMPv1 Summary • Organizational model • Manager – agent hierarchy • Information model • MIB, SMI and basic encoding rules (BER) • SMI uses a subset of ASN.1 • Communication model • Five message types • Request-and-response • TRAP based notification – no confirmation • UDP based – no acknowledgement • Security model • Very limited community based • Works well only if there is not any attacker!!!

5. Why SNMPv2? • Limitations of SNMPv1  SNMPv2 • Why so many limitations in SNMPv1? • SNMPv1 was intended as an interim network management protocol while waiting for OSI network management protocols to mature • CMOT which is CMIP over TCP/IP was created but did not do well • When the industry realized that CMOT would not overtake SNMP focus was on enhancing SNMPv1

6. Limitations of SNMPv1 • Limited error codes & error handling • genErr is a catch-all • Simple data types • Only scalar types • Table manipulation is tedious • New data types can not be defined • Limited notification • Unacknowledged • Agent does not know if critical notifications (traps) have reached the manager

7. Limitations of SNMPv1 (cont’d) • Limited performance • GET only get one scalar at a time • Not suitable for large network • Transport dependency • UPD not reliable • Lack of hierarchies • Only Manager-Agent, no Manager-Manager • Lack of security • Minimum authentication & authorization

8. SNMPv2 Birth • Performance & Security problems of SNMPv1 • Secure SNMP was proposed (July 1992) to solve this problem in SNMP • Simple Management Protocol (SMP) was also proposed (July 1992) to extend the SNMP functionality • secure SNMP + SMP = SNMPv2 (March 1993) • A major security flaw was detected in this proposal and the security aspects were dropped and the result is community-based SNMPv2c (Jan. 1996)

9. Key Changes in SNMPv2 • Bulk data transfer & Better error handling • To improve performance • Manager-to-manager message • For hierarchal network management • Textual conventions • To define new data types • Conformance & Capability statements • To formally specify agent capabilities • Row creation and deletion in table • More complex information modeling • MIB enhancements • New MIBs and drop unused complex MIBs • Transport mappings • Transport protocols other than UDP

10. Outline • Introduction • SNMPv2 Architecture • SNMPv2 SMI • SNMPv2 MIB • SNMPv2 Protocol • Conclusion

11. SNMPv2 Architecture • Two key enhancements on SNMPv1 architecture • 1) Eight messages instead of five, new msg.: • Get-bulk-request • Inform-request • Report • 2) Two manager applications communication • Hierarchal and distributed network management

12. SNMPv2 Messages • inform-request (new) • manager-to-manager with acknowledgement • get-bulk-request (new) • Transfer of large data (e.g., multiple rows of a table) • report (new) • Not used currently • response is the get-response • SNMPv2-Trap is the trap with modified PDU • get-request, get-next-request, and set-request are the same as SNMPv1

13. SNMPv2 Architecture

14. Outline • Introduction • SNMPv2 Architecture • SNMPv2 SMI • SNMPv2 MIB • SNMPv2 Protocol • Conclusion

15. SNMPv2 SMI (SMIv2) • Major changes in SMIv2 are • 1) New object definition macros • New macros replaced SNMPv1 macros • We have discussed in SNMPv1 • 2) Textual convention • 3) Table modification • 4) Conformance and Agent capabilities

16. SMIv2: Textual Convention • Enables defining new data types • Creates new data types using existing ones and applies restrictions to them • Makes semantics of data types consistent and human readable • Using the TEXTUAL-CONVENTION macro • Some textual conventions in SNMPv2 • MacAddress, TimeStamp, DateandTime, and RowStatus

17. Textual Convention Example

18. SMIv2: Tables • Static Tables • Table structure is defined in MIB development time • Access is read-only and read-write • Useful when the number of rows corresponds to a fixed attribute (e.g., # physical interfaces) or a quantity controlled only by agent • Vendors can add new columns to existence columns (new) • Dynamic Table • Allows row creation/deletion by a manager • At run/operation time • Access includes read, write and create/delete privileges

19. Why Table Modification? • Application 1 • Standard MIBs define a set of parameters for NIC (e.g., type, MTU, MAC) • Vendor needs additional parameters (e.g., Serial #, Power Consumption) • In SNMPv1, the vendors should define a separated new table for the parameters • Two tables (different set of OIDs) to manage NICs • In SNMPv2, these new parameters can be added to the existence table • Single table for NIC parameters (much easier) • Table Augmentation

20. Why Table Modification? • Application 2 • Firewall rules (typically) are specified as a table (src IP, dst IP, src port, dst port, proto, action) • Rules are not fixed; are changed over the time • Manager want to manage the firewall using SNMP • SNMPv1 cannot be used • It is not possible to create or delete rows • SNMPv2 dynamic tables is the solution • Rules can be added/deleted • Existing rules can be modified

21. Changing Columns: Table Augmentation • Adding new columnar objects (augmented table) to an existing table (base table) • Old base table is compiled & running in agent • The MIB of the new table is defined • The MIB is compiled & added to the agent • The agent treats both tables as a single table • Using the following assumptions • One to one correspondence between rows of tables • Number of rows is not affected • INDEX of the second table is the same as the first table

22. Table Augmentation (cont’d) Table 2 Table 1 Base table Dependent table table1 table 2 (T1) (T2) table1Entry table2Entry (E1) (E2) T1.E1.C1.1 T1.E1.C2.1 T1.E1.C3.1 T2.E2.C4.1 T2.E2.C5.1 T1.E1.C1.2 T1.E1.C2.2 T1.E1.C3.2 T2.E2.C4.2 T2.E2.C5.2 T1.E1.C1.3 T1.E1.C2.3 T1.E1.C3.3 T2.E2.C4.3 T2.E2.C5.3 T1.E1.C1.4 T1.E1.C2.4 T.E1.C3.4 T2.E2.C4.4 T2.E2.C5.4 Index: First columnar object in Table 1

23. A clause used to increase the number of columns in a table w/out rewriting the table definition Table Augmentation (cont’d) The resulting table is therefore treated the same way as if it was defined in a single table definition

24. Table Augmentation (cont’d) • What happen if • 1) New table row # > Base table row # • Dense dependent table is added to base table • 2) New table row # < Base table row # • Sparse dependent table • More details in the text book

25. Dynamic Tables • Table rows can be modified at the run-time using set-requests to create or delete rows • No new MIB is defined & compiled & installed

26. Row Creation and Deletion Example Column Object for row modification, Syntax is RowStatus

27. Create-and-Go Row Creation • Manager initiates a SetRequest-PDU to create a new row • status = 4, i.e., create and go • Agent interacts with the management entity and successfully create an instance; subsequently a response is transmitted to the manager • status = 1, indicates that the row is active

28. SetRequest ( status.3 = 5, Create and wait, no default data specified index.3 = 3 ) Response ( Agent responds with “notReady” (no default value) status.3 = 3, index.3 = 3) Get the data for the row GetRequest ( data.3 ) Response ( Data value is missing data.3 = noSuchInstance) SetRequest ( Value of data is sent data.3 = DefData) Response ( status.3 = 2 Agent responds with notInServcie data.3 = DefData) SetRequest ( Manager requests to activate the row status.3 = 1) Response ( Row activated status.3 = 1) Create-and-Wait Row Creation Manager Agent Process Process

29. Row Deletion

30. SMIv2: Conformance & Capability • Recent NM protocols provide mechanisms • To specify what agent implements • To allow manager to know what agent can do • SNMP provide two mechanisms: • Similar to each other • Use similar facilities • 1) Module compliance • MIB developer specifies what should be implemented • 2) Agent capabilities • Agent developer specifies what it implements

31. Object Groups • OBJECT-GROUP macro • Specifies objects in a MIB that are part of the conformance group compliance • NOTIFICATION-GROUP macro • Identifies a group of notifications required for conformance purposes • MANDATORY-GROUPS • The required object and notification groups that must be implemented by agent to comply the standard • GROUP • Optional object and notification groups that my be implemented by agent

32. Conformance Module • MODULE-COMPLIANCE macro • Defines compliance requirement for an agent in terms of MIB modules • AGENT-CAPABILITIES macro • Defines the capabilities of the agent

33. Outline • Introduction • SNMPv2 Architecture • SNMPv2 SMI • SNMPv2 MIB • SNMPv2 Protocol • Conclusion

34. SNMPv2 Internet Group • Additional SNMPv2 group added • Security group is a placeholder • Objects added to System group • Extensive modification of the SNMP group

35. SNMPv2 MIB

36. SNMPv2 MIB-2 • New protocols and technologies

37. SNMPv2 System Group • Table sysORTable • List of resources that the agent controls

38. SNMPv1 SNMP MIB • SNMP MIB was very complex in SNMPv1 • Some object are very rarely used

39. SNMPv2 SNMP MIB (cont’d) • SNMP MIB in SNMPv2 is simplified

40. Outline • Introduction • SNMPv2 Architecture • SNMPv2 SMI • SNMPv2 MIB • SNMPv2 Protocol • Conclusion

41. PDU type request id 0 0 variable-bindings SNMPv2 Protocol • Overall, 8 messages with almost common message format • To improve the efficiency and performance • Significant improvement is that trap message has the same format version community PDU (a) GetRequest, GetNextRequest, SetRequest, SNMPv2-Trap, InformRequest PDU type request id error status error index variable-bindings (b) Response-PDU PDU type request id non- repeaters max- repetitions variable-bindings (c) GetBulkRequest-PDU

42. Better Error Handling • SNMPv1 error codes (error-status) are very limited • More specific (informational) codes in SNMPv2 • SNMPv2 Error Status • noError • tooBig • noSuchName • badValue • readOnly • genErr • wrongType • wrongLength • wrongEncoding • wrongValue • noCreation • inconsistentValue • resourceUnavailable • commitFailed • undoFailed • authorizationError • notWritable • inconsistentName

43. Better Error Handling (cont’d) • SNMPv1 operations are atomic: • Either all values are returned or none! • error-status = 0  All are valid • error-status ≠ 0  None is valid • SNMPv2 can handle up to one error • If one variable is failed • Error-status and error-index are set, this index is ignored, others are valid • If multiple variables are failed • Only error-status is set (error-index is not set), all variables are ignored (we don’t know the failed one)

44. Better Error Handling: Exceptions • Besides errors, SNMPv2 defines three exceptions • noSuchObject OID is not found • noSuchInstance  OID is valid but is not accessible • endOfMibView No next OID exists • Used in GetNext & GetBulk • Exceptions do not raise error • They are encoded in variable binding • Better performance, for example • 10 OID is requested • 2 OID is wrong • SNMPv1  Whole operation fails with error-status = noSuchName • SNMPv2  8 valid values are returned, wrong OID’s value = noSuchObject

45. SNMPv2 GetBulkRequest PDU • Enables the retrieval of data in bulk, both • A variable binding list (similar to GetNextRequest) • Given # of successive objects of OIDs (another variable binding list) • Series of GetNexRequest (new) • Error status field replaced by Non-repeaters • The number of scalar field values requested • Error index field replaced by Max repetitions • The maximum number of table rows requested

46. GetBulkRequest • Selection principle is the same as GetNextRequest • the next object instance in lexicographic order • Includes a list of (N + R) variable names in the variable-bindings list • the first N variables for retrieving single values • the next R variables for retrieving multiple values • non-repeaters = N  Next objects of N given object are asked • max-repetition = M  At most M successive (next lexicographical) object instances of each R repetitive objects are asked

47. Get-Bulk-Request Example

48. Get-Next-Request Operation

49. Get-Bulk-Request Operation

50. SNMPv2-trap & Inform-request • Both use the same PDU • Positions 1 and 2 in VarBindList are sysUpTime and snmpTrapOID, respectively • Both packets are used to send unsolicited messages • Trap for agent-to-manage, but Inform for manager-to-manger messages • No acknowledge for trap, but response for inform