SNMP Update Jeff Case Founder and CTO SNMP

SNMP Update Jeff Case Founder and CTO SNMP Research, Inc. +1 865 573 1434 case@snmp. com

Topics: u Introduction u Differences between SNMPv 1, SNMPv 2 c, and SNMPv 3 Advantages of SNMPv 3 over SNMPv 1 and SNMPv 2 c l Disadvantages of SNMPv 3 l 2

Topics (Continued): u Recent l and Ongoing IETF Work Items SNMP-based Configuration Management n Policy MIB Module EOS Working Group: Evolution of SNMP l SMIng Working Group: Evolution of the Structure of Management Information l Distributed Management Working Group (DISMAN) l MIB Definitions l 3

Topics (Continued): u. A brief look at SNMP/MIB vis-à-vis DMI/MIFs l CIM/MOFs l COPS/PIBs l u Conclusions 4

The SNMP-based Internet Standard Management Framework has Evolved: SNMPv 1, SNMPv 2 c, and SNMPv 3

SNMP: The Right Architecture, in part, for the Wrong Reason u Multiple competing efforts circa 1987 - early 1988 with duplication of effort slowing progress and discouraging product development and deployment u The time of GOSIP u Blue-ribbon panel develops direction statement u SNMP was to be the “short-term interim” standard u Protocol independent SMI-based MIB u MIB independent SMI-based protocol u SMI “glue” 6

Protocol Versions: Summary Picture Simple-Based Management SNMPv 1 Party-based SNMPv 2* SNMPv 3 Common SNMPv 2 c SNMPv 2 u Management Information Definitions (MIB Documents) RFC 1155 Format RFC 1212/1215 Format RFC 1442 -4 Format 7 RFC 1902 -4 Format RFC 2578 -80 Format

SNMP: The Right Architecture, in part, for the Wrong Reason u This architecture which was designed to ease the shortening of the life of SNMP has actually allowed it to age gracefully and to evolve, thereby extending its useful life u People have been predicting the demise of SNMP for a decade and it just keeps going and growing while “replacements” appear and then disappear 8

The SNMP-based Internet-Standard Management Framework u Based on the Simple Network Management Protocol, but more than merely a protocol for data movement, but a complete framework: 1. A data definition language n The Internet-standard Structure of Management Information (SMI) 2. Definitions of management information n Instrumentation described in the [Internet-standard] Management Information Base (MIB) 3. Protocol definition n The Simple Network Management Protocol 9

Structure of Management Information (SMI) Evolution Modular (3 part) specification architecture: 1. A data definition language l The Internet-standard Structure of Management Information (SMI) 1 st Generation (1988 -1991): RFC 1155 n 2 nd Generation (1991 -1993): RFC 1212 and 1215 n 3 rd Generation (1993 -present): SMIv 2 RFCs 2578 -2580 n 4 th Generation: SMIng: a new work in progress n 10

Advantages of SMIv 2 over SMIv 1 u After about 1995, all information modules (MIB definitions) should be written in SMIv 2 format u Benefits: l New Data Types Counter 64 n BITS n Table indexing more clear and concise l Improved set operations for row create/delete (important for configuration/control) l 11

Advantages of SMIv 2 over SMIv 1 u Pragmatic Reality Most management stations and applications will load SMIv 2 format whereas a few still require SMIv 1 format so you need both l Information in SMIv 2 formatted documents is a superset of the information in an SMIv 1 formatted document l If you have SMIv 2 format, SMIv 1 format can be generated automatically by throwing away information and reformatting via an automatic tool l If you have SMIv 1 format, the tool is vi, emacs, etc plus human input l 12

MIB Grammar Versions and Protocol Versions -- Decoupled u In general, there is no need for the version of the protocol to match the version number of the format of a MIB document u With few exceptions, can use any MIB object, regardless of the version of the grammar of the MIB document, with any version of the protocol u The only noteworthy exception is MIB documents containing MIB objects with a datatype of Counter 64 (this datatype is not supported by version 1 of the protocol) 13

Protocol Versions: Summary Picture Simple-Based Management SNMPv 1 Party-based SNMPv 2* SNMPv 3 Common SNMPv 2 c SNMPv 2 u Management Information Definitions (MIB Documents) RFC 1155 Format RFC 1212/1215 Format RFC 1442 -4 Format 14 RFC 1902 -4 Format RFC 2578 -80 Format

Management Information Base (MIB) Evolution Modular (3 part) specification architecture: 2. Definitions of management information l l l Standard or non-standard Protocol independent Instrumentation described in the [Internet-standard] Management Information Base (MIB) Has undergone constant revision (mostly expansion) since first defined in 1988 A wide variety of technologies covered by standard MIB definitions and others through vendor-specific extensions 15

Management Information Base (MIB) Evolution u In the beginning (1988), there was MIB-I: basic to all managed systems u Next (early ‘ 90 s) came MIB-2: a superset of MIB-I u When MIB-2 reached Full Standard status (Mar ‘ 91), MIB-I became historic u Change in strategy: a distributed approach of multiple committees with differentiated staffing producing many mini-MIB documents u Lost benefit of input from almost all current operators and administrators 16

Management Information Base (MIB) Evolution (Continued) u Many of MIB documents are on the standards track at various levels of standardization maturity and market acceptance/demand Most are adequate for monitoring l Many must be supplemented for configuration and control l More standardization work needed n Enterprise-specific extensions in the absence of standards n 17

Management Information Base (MIB) Evolution (Continued) u Expanded scope of MIB reflective of expanded application of the Internet-Standard Management Framework, the basis for seamless Internet management: l l l traditional network management system management application management service management proxy management of legacy devices 18

MIB Documents: Network Management ADSL ATM Apple. Talk BGPv 4 Bridge Character Stream CLNS DECnet Phase IV DOCSIS Cable Modem RFC 2662 Multiple RFC 1742 RFC 1657 RFC 1493 RFC 1658 RFC 1238 RFC 1559 Multiple 19

MIB Documents: Network Management (Continued) DS 0, DS 1/E 1, DS 3/E 3 Interfaces Entity FDDI Frame Relay IEEE 802. 3 IEEE 802. 5 IEEE 802. 12 Integrated Services ISDN 20 Multiple RFC 2737 Multiple Multiple

MIB Documents: Network Management (Continued) MIB-2 Modem PPP RMON Routing RS-232 -Like SNA technology Sonet/SDH X. 25 technology RFC 1213 RFC 1696 Multiple RFC 1659 Multiple RFC 1595 Multiple 21

MIB Documents: Service Management u Frame Relay Service RFC 1604 RFC 2720 RFC 1694 u Meter u SMDS SIP 22

MIB Documents: System and Applications Management Application RFC 2564 Diffie-Helman USM Key Management RFC 2786 DISMAN Scheduling RFC 2591 DISMAN Scripting RFC 2592 Domain Name System Multiple Host Resources RFC 2790 Identification RFC 1414 Mail Monitoring RFC 2249 Network Services Monitoring RFC 2788 23

MIB Documents: System and Applications Management (Cont. ) Parallel Printer Radius Relational Database Server System Application TN 3270 UPS WWW Server X. 500 Directory Services Monitoring 24 RFC 1660 RFC 1759 Multiple RFC 1697 RFC 2287 Multiple RFC 1628 RFC 2594 RFC 2605

The SNMP-based Management Framework Is Not Just For Networks u The l l l l only relatively complete open multi-vendor multi-platform interoperable standards-based management framework for seamless integrated management of networks, systems, applications, and services 25

Importance of Seamlessness u Sharing: Among cooperating management applications u Showing: User interfaces and reports u Crunching: Converting data to information and information to data u Telling: SNMP-based movement of management data u Knowing: SMI-based instrumentation 26

Importance of Seamlessness u No single application or set of applications can meet all requirements u Sharing is essential Single naming scheme l Consistent data definitions l Standard information semantics l u Mapping l functions do not work well Every time you convert you lose u Example: event correlation for network, system, and application management with point solutions and proprietary database formats 27

Protocol Versions: Summary Picture Simple-Based Management SNMPv 1 Party-based SNMPv 2* SNMPv 3 Common SNMPv 2 c SNMPv 2 u Management Information Definitions (MIB Documents) RFC 1155 Format RFC 1212/1215 Format RFC 1442 -4 Format 28 RFC 1902 -4 Format RFC 2578 -80 Format

Evolution of the SNMP Protocol Portion of Internet-Standard Management Framework Modular (3 part) specification architecture: 3. Protocol definition MIB independent l The Simple Network Management Protocol l Protocol operations n Transport mappings n Security and administration n First defined in RFC 1157 (SNMPv 1) l Separate documents beginning in SNMPv 2 l Security and administration completed in SNMPv 3 l 29

Protocol Evolution 30

New Features of SNMPv 2 c u Expanded data types: 64 -bit counters u Improved efficiency and performance: get-bulk operator u Confirmed event notifications: inform operator u Richer error handling: errors and exceptions u Improved sets: especially row creation/deletion u Transport independence: IP, Appletalk, IPX, . . . u Etc. 31

New Features of SNMPv 3 u New features inherited from SNMPv 2 c, plus u Security and Administration 32

New Features of SNMPv 3 Inherited from SNMPv 2 c u The l l l list we just saw … Expanded data types: 64 -bit counters Improved efficiency and performance: get-bulk operator Confirmed event notifications: inform operator Richer error handling: errors and exceptions Improved sets: especially row creation/deletion Transport independence: IP, Apple. Talk, IPX, . . . Etc. u Plus . . . 33

Features of SNMPv 3: Security and Administrative Framework u Security authentication l privacy l u Administration l l l l Authorization and view-based access control Logical contexts Naming of entities, identities, and information People and policies Usernames and key management Notification destinations and proxy relationships Remotely configurable via SNMP operations 34

Security Threats and Mechanisms u Threats protected against by SNMPv 3: 1. Masquerade/data origin authentication: interloper assumes the identity of a sender to gain its privileges. 2. Modification of information/data integrity: alteration of in -transit messages. 3. Message stream modification: messages are re-ordered, delayed, or replayed 4. Disclosure/data confidentiality: privileged information is obtained via eavesdropping on messages. 35

Security Mechanisms u SNMPv 3 uses MD 5 and DES as “symmetric, ” i. e. , private key mechanisms (MD 5 = Message Digest Algorithm 5, RFC 1321) (DES = Data Encryption Standard) 36

SNMPv 3 User-based Authentication Mechanism u Based l on: MD 5 message digest algorithm in HMAC indirectly provides data origin authentication n directly defends against data modification attacks n uses private key known by both sender and receiver n 16 byte key n 128 bit digest (truncated to 96 bits) n SHA an optional alternative algorithm l Loosely synchronized monotonically increasing time indicator values l n defends against certain message stream modification attacks 37

SNMPv 3 User-based Privacy Mechanism u Based on: Symmetric encryption used l Data Encryption Standard (DES) Cipher Block Chaining (CBC) mode l provides privacy / protection against disclosure n uses encryption n subject to export and use restrictions in many jurisdictions n 16 byte key (8 bytes DES key, 8 byte DES initialization vector) l Multiple levels of compliance with respect to DES due to problems associated with international use l 38

Secret Rules u Note that both of these mechanisms depend on private keys Secrets must be kept secret l No postem notes, no world readable files l Initial keys must be loaded out-of-band l Note that key management is a requirement for a secure infrastructure because without a standardized key distribution mechanism, proper key hygiene will not be practiced l 39

Remote Configuration MIB Modules u Each document in the set of SNMPv 3 specifications has appropriate Information Modules which define appropriate MIB instrumentation u Includes key management for proper key hygiene u User-friendly string-based naming u UTF 8 for international use 40

HTTP and IPSEC are not alternatives because they do only part of the job u They provide authentication and privacy, but do not help with the other parts of the problem: authorization and view-based access control l multiple logical contexts and information naming l MIB module for standards-based remote configuration of l security parameters including key management n notification destinations, etc n u HTTP over SSL has the additional problem of connection-orientation which rules it out for use in fault management 41

Mechanisms: Configurability u Can have: no authentication / no privacy l authentication / privacy l u Configured at choice of network administrator with the user deciding how much to “spend” on security, l selecting the correct level of protection, l potentially on a transaction-by-transaction basis l 42

Mechanisms: Configurability (Continued) u Most administrators are expected to use three security. Level choices as follows: Monitoring: no authentication / no privacy l Control: authentication / no privacy l Downloading secrets: authentication / privacy l u Privacy l use may possibly be limited by: Vendor reluctance to ship cryptographic technology Multiple versions, extra paperwork, etc n FUD n DOTFWHAS: We should not confuse excuses for reasons n l Usage restrictions in some jurisdictions 43

Multi-Lingual Implementations for Coexistence and Transition u Cannot upgrade all systems at once u Some systems will never be upgraded u Virtually all products expected to be multi-lingual with simultaneous support for SNMPv 1 and SNMPv 3, perhaps including SNMPv 2 c, maybe including Web-based management u Old agent, old packet, old rules, old response; New agent, new packet, new rules, new response u Modular SNMPv 3 architecture allows view-based access control to be applied to any/all of these paths 44

Advantages of SNMPv 3 So What? Who Cares?

Good Things Operators and Administrators will like in SNMPv 3 u Able to practice safe sets Configuration / Control / Provisioning l No longer mere monitoring l Able to augment or replace proprietary CLI over Telnet l Via standards-based solutions providing l Commercial-grade industrial strength security n Authentication and Privacy n 46

Good Things Operators and Administrators will like in SNMPv 3 (Cont’d) u Now able to distribute management out to intelligent agents and mid-level managers Important for scalability l Keep local management traffic local l Shorter feedback loops with lower latency l 47

Good Things Operators and Administrators will like in SNMPv 3 u View-based l Access Control Various groups can have differentiated: levels of access, e. g. staff versus customers n access to different information, e. g. , customer 1 versus 2 n l Example: n Some groups of users might be allowed: ¡ Read-write access to ¡ Read-only access to n all subsets All others get no access 48 of the MIB data

Good Things Operators and Administrators will like in SNMPv 3 (Cont’d) u Better l Notifications: Traps Spray and pray n The only option in SNMPv 1 n l Informs Send, wait for acknowledgement n Retry count and retry interval n Added in SNMPv 2 c but with problems n Problems fixed in SNMPv 3 n Standard MIB objects to configure l Source-side notification suppression l 49

Good Things Operators and Administrators will like in SNMPv 3 (Cont’d) u Source l Side Notification Suppression Too many resources spent on uninteresting notification messages, e. g. , unwanted traps and informs Notification generation n Notification transmission and delivery n Notification logging n Notification filtering n SNMPv 3 allows you to use a standard MIB and standardsbased tools to turn unwanted notifications off at the source l You will really like this l 50

Good Things Operators and Administrators will like in SNMPv 3 (Cont’d) u Standards-based applications enabled through standard MIB definitions for ease of administration User names and keys l Authorization and access control rights l Notification destinations (traps and informs) l Also management of SNMPv 1 and SNMPv 2 c parameters such as community strings l 51

Good Things Operators and Administrators will like in SNMPv 3 (Cont’d) u Better l performance The Awesome get. Bulk operator works better with SNMPv 3 Less latency and lower overhead through a smaller number of larger packets n One to three orders of magnitude faster than SNMPv 1 get. Next operator (typically two) n Negotiates maximum message size correctly n l Counter 64 n u New l No need to poll as often features eliminate need for “gross hacks” e. g. , logical contexts 52

Good Things Operators and Administrators will like in SNMPv 3 (Cont’d) u Better l error handling: In a Get Request with 10 items requested and one is unavailable: In SNMPv 1, returns in an error with no partial results n In SNMPv 2/3, results in 9/10 good values and one exception n l In a Set Request, if something fails: In SNMPv 1, results in a “No” n In SNMPv 2/3, results in a “No-because” n 53

Disadvantages of SNMPv 3 u Security l is expensive More to configure and administer Unlocked doors are more convenient to use n Community strings were relatively easy to administer n Off-the-shelf tools help n l More overhead Message headers longer and more complex n Cryptographic calculations can increase CPU load approximately 20 -ish percent n It will run slower, it will run much slower if software-based DES is used, especially if implemented in Java n l Some machines do not have the hardware assets, but almost all do: NO EXCUSES 54

Disadvantages of SNMPv 3 (Cont’d) u Export and international usage considerations u Incomplete product support l Some vendors claim customers (i. e. , you) don’t care about security n l Agents better than manager stations and applications SNMPv 3 code often less mature and shaken out 55

Conclusion: What is SNMPv 3? u Newest version of the Internet-standard Management Framework u What SNMPv 2 should have been - builds on the good u Compatible with the SMI and MIB you use now u Important enabling technology for configuration and control: adds security and administration for safe sets u Security: authentication and privacy u Administration: logical contexts, view-based access control, remote configuration u Available now 56

Conclusions about SNMPv 3 u There is a lot to like u But we are not done yet -- there is more to be done 57

The SNMP-based Internet Standard Management Framework is Still Evolving: Recent and Ongoing IETF Work Items

The SNMP-based Management Framework is Evolved and Evolving u Not the same old SNMP your mother used in 1988 u Many positive advancements already standardized, implemented, and deployed u Some more are nearly done and ready for implementation and deployment: l SNMP-based configuration Policy-based Management MIB n Provisioning MIB for Diff. Serv n u Some standardization work is just getting started: SMIng l Evolution of SNMP: SNMP EOS l 59

Recent and Ongoing IETF Work Items: Topics u SNMP-based l Configuration Management Policy MIB Module u EOS Working Group: Evolution of SNMP u SMIng Working Group: Evolution of the Structure of Management Information u Distributed Management Working Group (DISMAN) u MIB Definitions 60

Significant Market Drivers u Growth and scale u Dearth of expert personnel u The need for seamlessness u The need for security u Standards and enabling technology u Driver du jour: secure policy-based configuration of policy, e. g. , secure policy-based configuration of security policy l important to note multiple meanings of security and policy l 61

Multiple Meanings of Policy u Policy-based distribution of configurations (targets selected according to a policy, e. g. , every system which run Solaris and an Apache Web server) u Policy-based application of configuration rules within a system (targets selected according to roles), e. g. , for each interface on a switch, apply configuration A on every backbone interface and configuration B on all other interfaces u Configuration of policy, e. g. , Qo. S policy or Security policy 62

SNMP-based Configuration Management u IETF SNMPCONF Working Group u Goals l Show best practices regarding how to do it n l Make it easier to do it n l Deliverable: BCP document Deliverable: Policy MIB Module Provide a worked out example while addressing pressing immediate needs DOTFWHAS: One example is worth two books n Provisioning of Diff. Serv Qo. S Policy n 63

SNMP-based Configuration Management Policy MIB Module u Challenges l Configure multiple parameters with many instances while, to the extent possible, being Vendor independent (unlike CLI) n Technology independent (ATM versus Diff. Serv) n Instance independent (at a higher level of abstraction) n l Integration of configuration management with fault management, performance monitoring, etc 64

SNMP-based Configuration Management Policy MIB Module u The PM MIB uses structured scripts to do policybased configuration of standard and vendor-specific MIB objects u A policy in the PM MIB is a pairing of a filter rule and an action (simple or complex) u The filter rule selects the applicable elements, i. e. , l if (an element has certain characteristics) then (apply operation to that element) u Alternately: if (policy. Filter) then (policy. Action) 65

Policy. Script Language u The script language will look familiar to you if you use C, Perl, C++, Tcl, Python, or Javascript u A simple subset No pointers, structures, typed variables, objects, classes, etc. l Does contain expressions, variables, looping l 66

The Policy-Based Management MIB u PM MIB Policies can be applied to any type of manageable element l l l Interfaces Circuits Queues Processes Software others. . . 67

A Conceptual Policy Trunk AND Ethernet AND 100 Mb: Trunk Ethernet Gold Autonegotiate 100 Mb Off Access Ethernet 10 Mb Access Frame Silver 512 Kb Trunk ATM Gold 45 Mb Trunk Ethernet Silver Autonegotiate 100 Mb Off Access Frame 128 Kb Trunk Ethernet Access Ethernet Gold 10 Mb Access Ethernet Silver 10 Mb Access Ethernet Gold 100 Mb Trunk Frame Access Frame Gold 512 Kb Access Ethernet Bronze 10 Mb Access Ethernet Gold 10 Mb Autonegotiate 100 Mb Off 68 45 Mb

A Conceptual Policy Ethernet AND Access AND Gold: Trunk Ethernet Gold 100 Mb Trunk ATM Gold 45 Mb Access Ethernet Trunk Ethernet Silver 100 Mb Access Ethernet Gold 100 Mb DSCP = 5 Access Frame Access Ethernet Bronze 10 Mb Access Frame Silver 512 Kb 128 Kb . Trunk Ethernet 100 Mb 69 Access Ethernet Gold 10 Mb= 5 DSCP Trunk Frame 45 Mb Access Ethernet Gold 10 Mb= 5 DSCP Access Ethernet Silver 10 Mb Access Frame Gold 512 Kb Access Ethernet Gold 10 Mb DSCP = 5

PM MIB Goals u Leverage existing infrastructure, tools, and MIBs Resulting simplicity will accelerate time to market l Don’t start from scratch in our data models l u Flexibility l for real-world policy Simple or complex filters and simple or complex actions u Do not underestimate the power of configuring by reference versus by value: l Consider 5 configuration parameters for 500 interfaces is 2, 500 operations. If these are common, then a single SET PDU could change them all simultaneously 70

policy. Filter Pseudo. Code Pseudocode: (is an ethernet AND is operational AND gets gold or silver service) Scripted As: ((getvar(“if. Type. $*”)== ethernet-csmacd) && (getvar(“if. Oper. Status. $*”) == up) && (role. Match("gold”)||role. Match("silver"))) 71

Execution Example u Filter: ((getvar(“if. Type. $*”)== ethernet-csmacd) && (getvar(“if. Oper. Status. $*”) == up) && (role. Match("gold”)||role. Match("silver"))) u Action: setvar(“if. Admin. Status. $*”, down(2), Integer) 72

Features of PM MIB u Scripting Very flexible and understandable way to express policy l IT Personnel like the power of scripting l Much more flexible than string matching l u Policies based on operational status Capabilities, status of interface, utilization, etc. l Allows much more rich sets of policies than using humaninput strings l u Scheduling Business calendars: “M-F 9 -5” or “Last Friday of every month” l Videoconference from 12 PM to 1 PM l 73

Features of PM MIB u Conflict l Uses a precedence tree to find best policy in conflicts u Error l resolution Recovery Helps meet service level goals by having backup policies on managed systems ¡ Policies have precedence - pm. Policy. Precedence ¡ Notifications if a policy encounters errors u Operational aspects: Ability to test a policy l Ability to disable a policy on an element so operator can take back control (“limp-home mode”) until policy is fixed l 74

SNMP-based Configuration Management Benefits of the PM MIB Module u Configuration tied to fault and performance: Interface fails that has been configured with Diff. Serv or IPSec l Statistics can be collected based on configuration - can selectively optimize data collection l u Built with existing infrastructure and tools u Leverages existing MIBs u A complete package, including operational aspects 75

SNMP-based Configuration Management Benefits of the PM MIB Module u You will like how the Policy MIB module works to configure Diff. Serv via the Diff. Serv MIB and Diff. Serv Provisioning MIB Modules u The same approach can and will be used with other areas of configuration such as The secure policy-based configuration of security policy l Routing l etc. l 76

Evolution of SNMP IETF EOS Working Group u The SNMP Protocol portion of the Internet Standard Framework is in its 2 nd generation u The EOS Working Group is chartered to develop and propose a 3 rd generation u Performance enhancements under consideration / development Efficiency through OID suppression and compression l Enhanced table manipulation l Improved row operations l Support for new data types l 77

Evolution of the Structure of Management Information: IETF SMIng Working Group u The SMIng Working Group is developing a new proposal for a next generation data definition language u Currently compiling and winnowing requirements u Motivated to have a single protocol-independent data definition language to eliminate wasteful duplication between MIBs and PIBs u Realistic requirements that can be supported by the SNMP and COPS-PR protocols 78

Evolution of the Structure of Management Information: IETF SMIng Working Group u Best hits album of SMIv 2 and SPPI, plus (still being decided): General cleanup / housekeeping l Additional data types l Signed and unsigned 64 bit integers n Floating point: Float 32, Float 64, and Float 128 (# of bits) n Unions and discriminated unions n Arrays n Aggregate data types n l New C-like grammar / syntax n Language extensibility 79

Evolution of the Structure of Management Information: IETF SMIng Working Group u… l Object Oriented Design Features Classes n Inheritance n Containment n Methods n Procedures n Constraints: existence constraints, attribute transaction constraints, attribute value constraints, method constraints n Associations and association cardinalities n u Not all of the proposals will make the cut 80

Distributed Management: IETF DISMAN Working Group u With security, it is possible to have intelligent agents or mid-level managers doing distributed management l l l Intelligent requires configuration Configuration requires security or Security enables configuration Configuration enables intelligent u Multiple proprietary MIB modules for years u IETF DISMAN adding standardization 81

Distributed Management: IETF DISMAN Working Group u IETF DISMAN chartered to define MIB specs for distributed network management applications u Remotely configured as an SNMP agent, acts as a distributed SNMP manager application u Off-load polling, keeping local polling local u Proximity yielding lower latency and shorter feedback loops u Important for scalability 82

Distributed Management: IETF DISMAN Working Group u Published l l l Work Products Schedule MIB (RFC 2591): Time driven execution Script MIB: (RFC 2592): Movement of scripts, not standardizing language Remote Operations MIB: (RFC 2925): ping, traceroute, DNS lookup Event MIB (RFC 2981): actions based upon threshholds Notification Log MIB (RFC 3014) u Works in progress l Alarm MIB, ITU Alarm MIB, SNMP Alarms 83

MIB Definitions u Multiple l l l Standards-track Specifications WWW MIB Application MIB System Application MIB Network Services Monitoring MIB Host Resources MIB u You can use these to monitor your and your customers’ mission-critical servers and services running on open systems DNS l Web, e-commerce l etc l 84

MIB Definitions u Use of a single paradigm allows integrated and correlated data and operations u Addresses frustration of multiple, independent, incompatible databases 85

Conclusions

Conclusions: The SNMP-based Management Framework is Sturdy u Originally “the short-term interim standard” u According to the pundits, has been on its last legs since 1988 l To be eclipsed by a succession of replacements u SNMP-based management is still growing l expanding scope l evolving l u While “replacements” come and go 87

What ever happened to? 88

What ever happened to? 89

What ever happened to? 90

Conclusions: u The Internet-Standard Management Framework based on SNMP is Evolved l Not just for networks l Secure l Sturdy l u But there is much more work to be done Additional standards work l Better applications l Implementation l Deployment l 91

Conclusions: u SNMP-based management is far from perfect, but it continues to be the best game in town u The architecture and vision are fine u We need to execute to completion u You do not yet get to live that vision, in part because the vendors are not supplying complete and compliant products 92

Conclusions: u The vendors are not fully implementing and supplying products based on that vision, in part because you are not insisting that they do so l Some vendors claim they see little market demand for secure management u There is an alternative to scripts and proprietary CLI over Telnet: the Internet Standard Management Framework 93

Questions / Comments Thank you for your participation