SNMP Update

1
SNMP Update

• Jeff Case
• Founder and CTO
• SNMP Research, Inc.
• 1 865 573 1434 case_at_snmp.com

Please see www.snmp.com/jdctutorial.ppt for slides
2
Topics

• Introduction
• Differences between SNMPv1, SNMPv2c, and SNMPv3
• Advantages of SNMPv3 over SNMPv1 and SNMPv2c
• Disadvantages of SNMPv3

3
Topics (Continued)

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

4
Topics (Continued)

• A brief look at SNMP/MIB vis-à-vis
• DMI/MIFs
• CIM/MOFs
• COPS/PIBs
• Conclusions

5
The SNMP-basedInternet Standard Management
Frameworkhas EvolvedSNMPv1, SNMPv2c, and
SNMPv3
6
SNMP The Right Architecture, in part, for the
Wrong Reason

• Multiple competing efforts circa 1987 - early
  1988 with duplication of effort slowing progress
  and discouraging product development and
  deployment
• The time of GOSIP
• Blue-ribbon panel develops direction statement
• SNMP was to be the short-term interim standard
• Protocol independent SMI-based MIB
• MIB independent SMI-based protocol
• SMI glue

7
Protocol VersionsSummary Picture
Simple-Based Management
SNMPv3
Party-based SNMPv2
SNMPv2
Common
SNMPv2
SNMPv2c
SNMPv2u
8
SNMP The Right Architecture, in part, for the
Wrong Reason

• 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
• People have been predicting the demise of SNMP
  for a decade and it just keeps going and growing
  while replacements appear and then disappear

9
The SNMP-based Internet-Standard Management
Framework

• 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
• The Internet-standard Structure of Management
  Information (SMI)
• 2. Definitions of management information
• Instrumentation described in the
  Internet-standard Management Information
  Base (MIB)
• 3. Protocol definition
• The Simple Network Management Protocol

10
Structure of Management Information (SMI)
Evolution

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

11
Advantages of SMIv2 over SMIv1

• After about 1995, all information modules (MIB
  definitions) should be written in SMIv2 format
• Benefits
• New Data Types
• Counter64
• BITS
• Table indexing more clear and concise
• Improved set operations for row create/delete
  (important for configuration/control)

12
Advantages of SMIv2 over SMIv1

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

13
MIB Grammar Versions and Protocol Versions --
Decoupled

• In general, there is no need for the version of
  the protocol to match the version number of the
  format of a MIB document
• 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
• The only noteworthy exception is MIB documents
  containing MIB objects with a datatype of
  Counter64 (this datatype is not supported by
  version 1 of the protocol)

14
Protocol VersionsSummary Picture
Simple-Based Management
SNMPv3
Party-based SNMPv2
SNMPv2
Common
SNMPv2
SNMPv2c
SNMPv2u
15
Management Information Base (MIB) Evolution

• Modular (3 part) specification architecture
• 2. Definitions of management information
• 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

16
Management Information Base(MIB) Evolution

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

17
Management Information Base(MIB) Evolution
(Continued)

• Many of MIB documents are on the standards track
  at various levels of standardization maturity and
  market acceptance/demand
• Most are adequate for monitoring
• Many must be supplemented for configuration and
  control
• More standardization work needed
• Enterprise-specific extensions in the absence of
  standards

18
Management Information Base(MIB) Evolution
(Continued)

• Expanded scope of MIB reflective of expanded
  application of the Internet-Standard Management
  Framework, the basis for seamless Internet
  management
• traditional network management
• system management
• application management
• service management
• proxy management of legacy devices

19
MIB DocumentsNetwork Management

• ADSL RFC 2662
• ATM Multiple
• AppleTalk RFC 1742
• BGPv4 RFC 1657
• Bridge RFC 1493
• Character Stream RFC 1658
• CLNS RFC 1238
• DECnet Phase IV RFC 1559
• DOCSIS Cable Modem Multiple

20
MIB DocumentsNetwork Management (Continued)

• DS0, DS1/E1, DS3/E3 Interfaces Multiple
• Entity RFC 2737
• FDDI Multiple
• Frame Relay Multiple
• IEEE 802.3 Multiple
• IEEE 802.5 Multiple
• IEEE 802.12 Multiple
• Integrated Services Multiple
• ISDN Multiple

21
MIB DocumentsNetwork Management (Continued)

• MIB-2 RFC 1213
• Modem RFC 1696
• PPP Multiple
• RMON Multiple
• Routing Multiple
• RS-232-Like RFC 1659
• SNA technology Multiple
• Sonet/SDH RFC 1595
• X.25 technology Multiple

22
MIB DocumentsService Management

• Frame Relay Service RFC 1604
• Meter RFC 2720
• SMDS SIP RFC 1694

23
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

24
MIB Documents System and Applications Management
(Cont.)

• Parallel Printer RFC 1660
• Printer RFC 1759
• Radius Multiple
• Relational Database Server RFC 1697
• System Application RFC 2287
• TN3270 Multiple
• UPS RFC 1628
• WWW Server RFC 2594
• X.500 Directory Services Monitoring RFC 2605

25
The SNMP-based Management Framework Is Not Just
For Networks

• The only
• relatively complete
• open
• multi-vendor
• multi-platform
• interoperable
• standards-based management framework
• for seamless integrated management of networks,
  systems, applications, and services

26
Importance of Seamlessness

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

27
Importance of Seamlessness

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

28
Protocol VersionsSummary Picture
Simple-Based Management
SNMPv3
Party-based SNMPv2
SNMPv2
Common
SNMPv2
SNMPv2c
SNMPv2u
29
Evolution of the SNMP Protocol Portion of
Internet-Standard Management Framework

• Modular (3 part) specification architecture
• 3. Protocol definition
• MIB independent
• The Simple Network Management Protocol
• Protocol operations
• Transport mappings
• Security and administration
• First defined in RFC 1157 (SNMPv1)
• Separate documents beginning in SNMPv2
• Security and administration completed in SNMPv3

30
Protocol Evolution
31
New Features of SNMPv2c

• 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, Appletalk, IPX, ...
• Etc.

32
New Features of SNMPv3

• New features inherited from SNMPv2c, plus
• Security and Administration

33
New Features of SNMPv3 Inherited from SNMPv2c

• The 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, AppleTalk, IPX, ...
• Etc.
• Plus ...

34
Features of SNMPv3 Security and Administrative
Framework

• Security
• authentication
• privacy
• Administration
• 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

35
Security Threats and Mechanisms

• Threats protected against by SNMPv3
• 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.

36
Security Mechanisms

• SNMPv3 uses MD5 and DES as symmetric, i.e.,
  private key mechanisms(MD5 Message Digest
  Algorithm 5, RFC 1321)(DES Data Encryption
  Standard)

37
SNMPv3 User-based Authentication Mechanism

• Based on
• MD5 message digest algorithm in HMAC
• indirectly provides data origin authentication
• directly defends against data modification
  attacks
• uses private key known by both sender and
  receiver
• 16 byte key
• 128 bit digest (truncated to 96 bits)
• SHA an optional alternative algorithm
• Loosely synchronized monotonically increasing
  time indicator values
• defends against certain message stream
  modification attacks

38
SNMPv3 User-based Privacy Mechanism

• Based on
• Symmetric encryption used
• Data Encryption Standard (DES) Cipher Block
  Chaining (CBC) mode
• provides privacy / protection against disclosure
• uses encryption
• subject to export and use restrictions in many
  jurisdictions
• 16 byte key (8 bytes DES key, 8 byte DES
  initialization vector)
• Multiple levels of compliance with respect to DES
  due to problems associated with international use

39
Secret Rules

• Note that both of these mechanisms depend on
  private keys
• Secrets must be kept secret
• No postem notes, no world readable files
• Initial keys must be loaded out-of-band
• 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

40
Remote Configuration MIB Modules

• Each document in the set of SNMPv3 specifications
  has appropriate Information Modules which define
  appropriate MIB instrumentation
• Includes key management for proper key hygiene
• User-friendly string-based naming
• UTF8 for international use

41
HTTP and IPSEC are not alternatives because they
do only part of the job

• They provide authentication and privacy, but do
  not help with the other parts of the problem
• authorization and view-based access control
• multiple logical contexts and information naming
• MIB module for standards-based remote
  configuration of
• security parameters including key management
• notification destinations, etc
• HTTP over SSL has the additional problem of
  connection-orientation which rules it out for use
  in fault management

42
Mechanisms Configurability

• Can have
• no authentication / no privacy
• authentication / no privacy
• authentication / privacy
• Configured at choice of network administrator
• with the user deciding how much to spend on
  security,
• selecting the correct level of protection,
• potentially on a transaction-by-transaction basis

43
Mechanisms Configurability(Continued)

• Most administrators are expected to use the three
  securityLevel choices as follows
• Monitoring no authentication / no privacy
• Control authentication / no privacy
• Downloading secrets authentication / privacy
• Privacy use may possibly be limited by
• Vendor reluctance to ship cryptographic
  technology
• Multiple versions, extra paperwork, etc
• FUD
• DOTFWHAS We should not confuse excuses for
  reasons
• Usage restrictions in some jurisdictions

44
Multi-Lingual Implementations forCoexistence and
Transition

• Cannot upgrade all systems at once
• Some systems will never be upgraded
• Virtually all products expected to be
  multi-lingual with simultaneous support for
  SNMPv1 and SNMPv3, perhaps including SNMPv2c,
  maybe including Web-based management
• Old agent, old packet, old rules, old
  responseNew agent, new packet, new rules, new
  response
• Modular SNMPv3 architecture allows view-based
  access control to be applied to any/all of these
  paths

45
Advantages of SNMPv3

• So What?
• Who Cares?

46
Good Things Operators and Administrators will
like in SNMPv3

• Able to practice safe sets
• Configuration / Control / Provisioning
• No longer mere monitoring
• Able to augment or replace proprietary CLI over
  Telnet
• Via standards-based solutions providing
• Commercial-grade industrial strength security
• Authentication and Privacy

47
Good Things Operators and Administrators will
like in SNMPv3 (Contd)

• Now able to distribute management out to
  intelligent agents and mid-level managers
• Important for scalability
• Keep local management traffic local
• Shorter feedback loops with lower latency

48
Good Things Operators and Administrators will
like in SNMPv3

• View-based Access Control
• Various groups can have differentiated
• levels of access, e.g. staff versus customers
• access to different information, e.g., customer 1
  versus 2
• Example
• Some groups of users might be allowed
• Read-write access to all of the MIB data
• Read-write access to subsets of the MIB data
• Read-only access to all of the MIB data
• Read-only access to subsets of the MIB data
• All others get no access

49
Good Things Operators and Administrators will
like in SNMPv3 (Contd)

• Better Notifications
• Traps
• Spray and pray
• The only option in SNMPv1
• Informs
• Send, wait for acknowledgement
• Retry count and retry interval
• Added in SNMPv2c but with problems
• Problems fixed in SNMPv3
• Standard MIB objects to configure
• Source-side notification suppression

50
Good Things Operators and Administrators will
like in SNMPv3 (Contd)

• Source Side Notification Suppression
• Too many resources spent on uninteresting
  notification messages, e.g., unwanted traps and
  informs
• Notification generation
• Notification transmission and delivery
• Notification logging
• Notification filtering
• SNMPv3 allows you to use a standard MIB and
  standards-based tools to turn unwanted
  notifications off at the source
• You will really like this

51
Good Things Operators and Administrators will
like in SNMPv3 (Contd)

• Standards-based applications enabled through
  standard MIB definitions for ease of
  administration
• User names and keys
• Authorization and access control rights
• Notification destinations (traps and informs)
• Also management of SNMPv1 and SNMPv2c parameters
  such as community strings

52
Good Things Operators and Administrators will
like in SNMPv3 (Contd)

• Better performance
• The Awesome getBulk operator works better with
  SNMPv3
• Less latency and lower overhead through a smaller
  number of larger packets
• One to three orders of magnitude faster than
  SNMPv1 getNext operator (typically two)
• Negotiates maximum message size correctly
• Counter64
• No need to poll as often
• New features eliminate need for gross hacks
• e.g., logical contexts

53
Good Things Operators and Administrators will
like in SNMPv3 (Contd)

• Better error handling
• In a Get Request with 10 items requested and one
  is unavailable
• In SNMPv1, returns in an error with no partial
  results
• In SNMPv2/3, results in 9/10 good values and one
  exception
• In a Set Request, if something fails
• In SNMPv1, results in a No
• In SNMPv2/3, results in a No-because

54
Disadvantages of SNMPv3

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

55
Disadvantages of SNMPv3 (Contd)

• Export and international usage considerations
• Incomplete product support
• Some vendors claim customers (i.e., you) dont
  care about security
• Agents better than manager stations and
  applications
• SNMPv3 code often less mature and shaken out

56
ConclusionWhat is SNMPv3?

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

57
Conclusions about SNMPv3

• There is a lot to like
• But we are not done yet -- there is more to be
  done

58
The SNMP-basedInternet Standard Management
Frameworkis Still EvolvingRecent and Ongoing
IETF Work Items
59
The SNMP-based Management Framework is Evolved
and Evolving

• Not the same old SNMP your mother used in 1988
• Many positive advancements already standardized,
  implemented, and deployed
• Some more are nearly done and ready for
  implementation and deployment
• SNMP-based configuration
• Policy-based Management MIB
• Provisioning MIB for DiffServ
• Some standardization work is just getting
  started
• SMIng
• Evolution of SNMP SNMP EOS

60
Recent and Ongoing IETF Work ItemsTopics

• SNMP-based Configuration Management
• Policy MIB Module
• EOS Working Group Evolution of SNMP
• SMIng Working Group Evolution of the Structure
  of Management Information
• Distributed Management Working Group (DISMAN)
• MIB Definitions

61
Significant Market Drivers

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

62
Multiple Meanings of Policy

• Policy-based distribution of configurations
  (targets selected according to a policy, e.g.,
  every system which run Solaris and an Apache Web
  server)
• 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
  andconfiguration B on all other interfaces
• Configuration of policy, e.g., QoS policy or
  Security policy

63
SNMP-based Configuration Management

• IETF SNMPCONF Working Group
• Goals
• Show best practices regarding how to do it
• Deliverable BCP document
• Make it easier to do it
• Deliverable Policy MIB Module
• Provide a worked out example while addressing
  pressing immediate needs
• DOTFWHAS One example is worth two books
• Provisioning of DiffServ QoS Policy

64
SNMP-based Configuration ManagementPolicy MIB
Module

• Challenges
• Configure multiple parameters with many instances
  while, to the extent possible, being
• Vendor independent (unlike CLI)
• Technology independent (ATM versus DiffServ)
• Instance independent (at a higher level of
  abstraction)
• Integration of configuration management with
  fault management, performance monitoring, etc

65
SNMP-based Configuration ManagementPolicy MIB
Module

• The PM MIB uses structured scripts to do
  policy-based configuration of standard and
  vendor-specific MIB objects
• A policy in the PM MIB is a pairing of a filter
  rule and an action (simple or complex)
• The filter rule selects the applicable elements,
  i.e.,
• if (an element has certain characteristics) then
  (apply operation to that
  element)
• Alternately if (policyFilter) then (policyAction)

66
PolicyScript Language

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

67
The Policy-Based Management MIB

• PM MIB Policies can be applied to any type of
  manageable element
• Interfaces
• Circuits
• Queues
• Processes
• Software
• others...

68
A Conceptual Policy
69
A Conceptual Policy
70
PM MIB Goals

• Leverage existing infrastructure, tools, and MIBs
• Resulting simplicity will accelerate time to
  market
• Dont start from scratch in our data models
• Flexibility for real-world policy
• Simple or complex filters and simple or complex
  actions
• Do not underestimate the power of configuring by
  reference versus by value
• 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

71
policyFilter PseudoCode

• Pseudocode
• (is an ethernet
• AND is operational
• AND gets gold or silver service)
• Scripted As
• ((getvar(ifType.) ethernet-csmacd)
• (getvar(ifOperStatus.) up)
• (roleMatch("gold)roleMatch("silver")))

72
Execution Example

• Filter ((getvar(ifType.) ethernet-csmacd)
• (getvar(ifOperStatus.) up)
• (roleMatch("gold)roleMatch("silver")))
• Action
• setvar(ifAdminStatus., down(2),Integer)

73
Features of PM MIB

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

74
Features of PM MIB

• Conflict resolution
• Uses a precedence tree to find best policy in
  conflicts
• Error Recovery
• Helps meet service level goals by having backup
  policies on managed systems
• Policies have precedence - pmPolicyPrecedence
• Notifications if a policy encounters errors
• Operational aspects
• Ability to test a policy
• Ability to disable a policy on an element so
  operator can take back control (limp-home mode)
  until policy is fixed

75
SNMP-based Configuration ManagementBenefits of
the PM MIB Module

• Configuration tied to fault and performance
• Interface fails that has been configured with
  DiffServ or IPSec
• Statistics can be collected based on
  configuration - can selectively optimize data
  collection
• Built with existing infrastructure and tools
• Leverages existing MIBs
• A complete package, including operational aspects

76
SNMP-based Configuration Management Benefits of
the PM MIB Module

• You will like how the Policy MIB module works to
  configure DiffServ via the DiffServ MIB and
  DiffServ Provisioning MIB Modules
• The same approach can and will be used with other
  areas of configuration such as
• The secure policy-based configuration of security
  policy
• Routing
• etc.

77
Evolution of SNMPIETF EOS Working Group

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

78
Evolution of the Structure of Management
Information IETF SMIng Working Group

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

79
Evolution of the Structure of Management
Information IETF SMIng Working Group

• Best hits album of SMIv2 and SPPI, plus (still
  being decided)
• General cleanup / housekeeping
• Additional data types
• Signed and unsigned 64 bit integers
• Floating point Float32, Float64, and Float128
  ( of bits)
• Unions and discriminated unions
• Arrays
• Aggregate data types
• New C-like grammar / syntax
• Language extensibility

80
Evolution of the Structure of Management
Information IETF SMIng Working Group

• Object Oriented Design Features
• Classes
• Inheritance
• Containment
• Methods
• Procedures
• Constraints existence constraints, attribute
  transaction constraints, attribute value
  constraints, method constraints
• Associations and association cardinalities
• Not all of the proposals will make the cut

81
Distributed ManagementIETF DISMAN Working Group

• With security, it is possible to have intelligent
  agents or mid-level managers doing distributed
  management
• Intelligent requires configuration
• Configuration requires security
• or
• Security enables configuration
• Configuration enables intelligent
• Multiple proprietary MIB modules for years
• IETF DISMAN adding standardization

82
Distributed ManagementIETF DISMAN Working Group

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

83
Distributed ManagementIETF DISMAN Working Group

• Published 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)
• Works in progress
• Alarm MIB, ITU Alarm MIB, SNMP Alarms

84
MIB Definitions

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

85
MIB Definitions

• Use of a single paradigm allows integrated and
  correlated data and operations
• Addresses frustration of multiple, independent,
  incompatible databases

86
Conclusions
87
Conclusions The SNMP-based Management Framework
is Sturdy

• Originally the short-term interim standard
• According to the pundits, has been on its last
  legs since 1988
• To be eclipsed by a succession of replacements
• SNMP-based management is still
• growing
• expanding scope
• evolving
• While replacements come and go

88
What ever happened to?
89
What ever happened to?
90
What ever happened to?
91
Conclusions

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

92
Conclusions

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

93
Conclusions

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

94
Questions / Comments

• Thank you for your participation