1 / 94

SNMP Update

SNMP Update. Jeff Case Founder and CTO SNMP Research, Inc. +1 865 573 1434 case@snmp.com. Please see www.snmp.com/jdctutorial.ppt for slides. Topics:. Introduction Differences between SNMPv1, SNMPv2c, and SNMPv3 Advantages of SNMPv3 over SNMPv1 and SNMPv2c

gali
Download Presentation

SNMP Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SNMP Update Jeff Case Founder and CTO SNMP Research, Inc. +1 865 573 1434 case@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 Evolved:SNMPv1, 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. SNMPv1 Management Information Definitions (MIB Documents) RFC 2578-80 Format RFC 1155 Format RFC 1212/1215 Format RFC 1442-4 Format RFC 1902-4 Format Protocol Versions:Summary 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. SNMPv1 Management Information Definitions (MIB Documents) RFC 2578-80 Format RFC 1155 Format RFC 1212/1215 Format RFC 1442-4 Format RFC 1902-4 Format Protocol Versions:Summary 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 Documents:Network 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 Documents:Network 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 Documents:Network 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 Documents:Service 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. SNMPv1 Management Information Definitions (MIB Documents) RFC 2578-80 Format RFC 1155 Format RFC 1212/1215 Format RFC 1442-4 Format RFC 1902-4 Format Protocol Versions:Summary 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 response;New 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 (Cont’d) • 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 (Cont’d) • 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 (Cont’d) • 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

More Related