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

Outline  Introduction  SNMPv2 Architecture  SNMPv2 SMI  SNMPv2 MIB  SNMPv2 Protocol  Conclusion 2

Outline  Introduction  SNMPv2 Architecture  SNMPv2 SMI  SNMPv2 MIB  SNMPv2 Protocol  Conclusion 3

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!!! 4

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 5

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 6

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 7

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) 8

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 9

Outline  Introduction  SNMPv2 Architecture  SNMPv2 SMI  SNMPv2 MIB  SNMPv2 Protocol  Conclusion 10

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 11

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 12

SNMPv2 Architecture 13

Outline  Introduction  SNMPv2 Architecture  SNMPv2 SMI  SNMPv2 MIB  SNMPv2 Protocol  Conclusion 14

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 15

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 16

Textual Convention Example 17

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 18

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 19

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 20

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 21

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

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

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 24

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 25 State / Command Enume ration Description active1 Row exists and is operational notInService2 Operation on the row is suspended notReady3 Row does not have all the columnar objects needed createAndGo4 This is a one-step process of creation of a row; immediately goes into active state createAndWait5 Row is under creation and should not be commissioned into service destroy6 Same as Invalid in EntryStatus. Row should be deleted

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

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 27

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

Row Deletion 29

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 30

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 31

SMIv2: Conformance Information  SNMPv2 has the ability to address conformance to the specs built in  E.g., A product is compliant when it meets the specifications set in RFC1904  The requirements for SNMPv2 compliance are called module compliance and are defined by the MODULE-COMPLIANCE macro  Specifies the minimum MIB modules or subsets that should be implemented to be compliant 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

snmpMIBConformance  The standard conformance requirements 41

Outline  Introduction  SNMPv2 Architecture  SNMPv2 SMI  SNMPv2 MIB  SNMPv2 Protocol  Conclusion 42

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 43 variable-bindings00 request id PDU type (a) GetRequest, GetNextRequest, SetRequest, SNMPv2-Trap, InformRequest variable-bindings error index error status request id PDU type (b) Response-PDU variable-bindings max- repetitions non- repeaters request id PDU type (c) GetBulkRequest-PDU PDUcommunityversion

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

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) 45

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 46

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 47

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 48

Get-Bulk-Request Example 49

Get-Next-Request Operation 50

51 Get-Bulk-Request Operation

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 52

SNMPv2 PDU Sequences 53

SNMPv2 Proxy Server 54

SNMPv2 Summary  Key enhancements in SNMPv2  New messages  Manager-to-Manager communication  Bulk information transfer  TRAPS have same format as other PDUs  Better error handling including exceptions  Table modification, Textual conventions & Conformance  MIB improvements  More powerful but more complex than SNMPv1  SNMPv2 failed to improve on security 55

References  Reading Assignment: Chapter 6 of “Mani Subramanian, ‘Network Management: Principles and Practice’, Pearson Education, 2012”  R. Dssouli, “Advanced Network Management,” Concordia Institute for Information Systems Engineering, html html  Nhut Nguyen, “Telecommunications Network Management,” University of Texas at Dallas,  J. Won-Ki Hong, “Network Management System,” PosTech University, dpnm.postech.ac.kr/cs607/dpnm.postech.ac.kr/cs607/ 56