Do We Need a New Network Management Framework?

1. Do We Need a New Network Management Framework? David Harrington IETF66 OPS Area Meeting Montreal, Quebec, Canada

2. Purpose of the Presentation • There has been increasing discussion about whether the existing IETF-Standard Management Framework needs to be modified to better meet the emerging needs of the Internet. • This presentation is designed to expand the discussion to a larger audience and focus the discussion so solutions can be researched and engineered.

3. The IETF-Standard Management Framework The Established Concepts

4. An Overview • Identify the concepts that underlie the existing IETF-Standard Management Framework • Establish a common terminology for discussing the evolution of the existing IETF-Standard Management Framework

5. Concepts Four Components of a System • several managed nodes • each with entity to provide remote access to management instrumentation • Management applications • Possibly multiple applications • A protocol over standard transport • Management information

6. Concepts The Modular Architecture of the IETF Management Framework • a data definition language (SMI) • definitions of management information (The MIB) • a protocol definition (SNMP) • security and administration (SNMPv3)

7. Concepts Data Definition Language - SMI • Mechanism to address data instances • Tree-shaped space with tag assigned to each object instance • Standard external representation of the value (BER) • definition of the meaning, or semantics of a value (MIB Module document)

8. Concepts Definitions of Management Information • The MIB contains MIB modules • MIB module defines content specific to managed functionality • Experience has shown that MIB modules are preferred over one monolithic MIB definition (e.g. MIB-I and MIB-II) to enable easier updates to a system and standards

9. Concepts A Protocol Definition • Currently SNMP is the recommended protocol for use in the IETF standard management framework • SNMPv1 protocol defined transport mapping, message format, operations, naming scope, weak authentication, weak authorization • SNMPv1/v2c aspects not very modular

10. Concepts Security and Administration • RFC3411 added stronger authentication, message security, and authorization. • Added remote administration of SNMP • Modularized the internal structure of an SNMP entity by identifying data flows and using different MIB modules for different aspects

11. Concepts • Modularity: Subsystems and Models • Subsystems have “service interfaces” to identify data flows between subsystems • A Model instantiates a subsystem • Multiple models can co-exist within a subsystem

12. Concepts • Multiple models can co-exist within a subsystem • transports (UDP/IPv4, UDP/IPv6, TCP, SSH) • message formats (v1, v2c, v3) • security models (Community, USM, SSH) • Internal applications (command generator, command responder, notification originator, notification receiver, proxy) • access control models (VACM, others)

13. Concepts • Some mandatory-to-implement models per subsystem for interoperability • transports (UDP/IPv4, TCP, SSH) • message formats (v1, v2c, v3) • security models (Community, USM, SSH) • Internal applications (command generator, command responder, notification originator, notification receiver, proxy) • access control models (VACM, others)

14. Concepts • Subsystems • Transport Mapping • Message Format • Message Security • Applications • Authorization • Major bindings between subsystems • Security Principal, Model, Level • Classes of Operations (read/write/notify)

15. Convergence of IETF Network Management Protocols Work Being Done, and Done, and Done

16. Purpose of the Presentation • Describe some efforts under way so contributors are aware of how their work fits into the IETF-Standard Management Framework • Make contributors aware of options being considered in similar problem spaces. • Make contributors aware of duplication of effort

17. Purpose of the Presentation • At IETF64, I did a full presentation about the Convergence of NM efforts in the IETF and recommended improved integration and reuse of related work • Here is a brief recap of that presentation. • For the complete presentation, consult the proceedings and streaming audio archive.

18. Message Security + Transport Protocol SNMP/ISMS Netconf Syslog Content MIBs TBD Not Standard Modeling Language SMIv2 XML Schema Structured ASCII Authorization VACM/RADIUS TBD Operations Get-*/SET GET/EDIT none Message Security USM->SSH SSH SSH or TLS? Transport UDP->TCP TCP UDP->TCP?

19. Operations Protocol ISMS Netconf Syslog Content MIBs TBD Not Standard Modeling Language SMIv2 XML Schema Structured ASCII Authorization VACM/RADIUS TBD Operations GET*/Set/Notify GET/EDIT/Notify Log/Notify Message Security USM->SSH SSH SSH or TLS Transport UDP->TCP TCP UDP->TCP

20. Operation Authorization Protocol ISMS Netconf Syslog Content MIBs TBD Not Standard Modeling Language SMIv2 XML Schema Structured ASCII Authorization RADIUS/VACM All-or-nothing All-or-nothing Operations GET-*/SET GET/EDIT none Message Security SSH SSH SSH or TLS? Transport UDP->TCP TCP UDP->TCP

21. Data Modeling Language Protocol ISMS Netconf Syslog Content MIBs TBD Not Standard Modeling Language SMIv2 XML Schema Structured ASCII Authorization RADIUS TBD Operations GET-*/SET GET/EDIT Message Security SSH SSH SSH or TLS Transport UDP->TCP TCP UDP->TCP

22. Data Modeling Protocol ISMS Netconf Syslog Content MIBs TBD Not Standard Modeling Language SMIv2 XML Schema Structured ASCII Authorization RADIUS TBD Operations GET-*/SET GET/EDIT Message Security SSH SSH SSH or TLS Transport UDP->TCP TCP UDP->TCP

23. Proposal to Develop a Modular Framework to Include IPFIX, Netconf, SNMP, and Syslog Focus on Bringing The Work Together

24. Proposal • Start with the RFC3411 subsystems • Other protocols do not have modular architectures • RFC3411 is a fuller architecture than others, and has been reviewed and approved by Security area. • Some aspects of RFC3411 are not needed by other protocols, but will be needed by some

25. Proposal • RFC3411 has known problems • A New architecture should be developed • Should probably use a layered architecture • Should show data flows pictorially • Should eliminate ASIs, which are frequently confused as being APIs • We should replace RFC3411 with a common architecture.

26. Start with these • Subsystems • Transport Mapping • Message Format • Message Security • Applications • Authorization • Other work is being broken into secure transport, protocol, data modeling, etc.

27. Start with these • Major bindings between subsystems • Security Principal, Model, Level • Classes of Operations (read/write/notify) • An instance addressing mechanism • These are used to provide model-independent handles between authenticated principal, operations, and data object instances or hierarchies

28. Retro-fit • Determine how portions of existing protocols fit into the modular architecture • Consider how difficult it would be to develop a modular “model” to separate the feature from the rest of the protocol design, similar to transport mappings

29. Retro-fit • Determine how portions of existing protocols do NOT fit into the modular architecture • Determine where the concepts conflict to the point they cannot fit in the modular architecture • Determine how the architecture should be changed to accommodate the conflict

30. Proposal to Collaborate on the Ongoing Work of Evolving the IETF Management Framework

31. Basic Premise • Network Management used to be an unusual problem because the database was remote from the processing application • This is no longer a unique type of application. • Therefore, Network Management should be considered just another application.

32. Basic Premise • Network Management Security used to be a low priority, and different NM protocols could use different security approaches. • This is no longer a low priority, and compatibility of solutions is critical. • Network Management should be considered just another application that needs to run over a secure transport, but with a few unique issues.

33. Convergence • NM solutions need to address • Secure NM Transport • Information Modeling Language • Data Modeling • Classes of Operations • Applications • Authorization

34. Secure NM Transport • WGs are striving to integrate Network Management protocols with existing security solutions • Having a “balanced” security approach between NM protocols would provide a more secure NM environment. • NM work has identified specific issues to address regarding using lower layer security.

35. Secure NM Transport • The Security Area is already working on defining how applications (generic) should utilize lower layer security. • OPS, Application, and Security Areas should standardize data flows between applications and secure transport • Then identify common threat models for NM and common solution models

36. Secure NM Transport • Recommend a Security WG effort to develop one (subsystem-style) strategy for NM solutions to use lower layer security • Different models for different needs • Bring contributors from syslog, netconf, ipfix, and snmpv3 together with contributors from TLS, SSH, BEEP, SASL, etc. to discuss NM requirements and design standard solution models.

37. Convergence • NM solutions need to address • Secure NM Transport • Information Modeling Language • Data Modeling • Classes of Operations • Applications • Authorization

38. Information Models • IETF has no standard language for information modeling, except ASCII. • It would be very helpful if WGs defined an information model about what can and should be managed, before committing the design to a data model, such as a MIB module.

39. NM Information Models • WGs should be required to develop an information model module to describe the management needs of their technology • In keeping with the lessons already learned, the information models should be developed from the bottom-up in modular fashion, by the technology creators, rather than as a monolithic information model by info-model designers.

40. NM Data Models • The IETF should develop a common ASCII-RFC-based data-modeling language with an eye toward sharing netconf, syslog, ipfix, and snmp information models • WGs should develop a data model (e.g., a MIB module) for their technology as proof of concept of their information model.

41. Data modeling languages • The collections of management data used by snmp, syslog, ipfix, and netconf are databases. • Information modeling and data modeling are simply aspects of database modeling • There should be collaboration between the Application Area and the OPS Area to develop information modeling language standards, suitable for use in NM.

42. Data modeling languages • Migrating from one data modeling language to another, or supplementing one form of data model with another will require tools. • The NMRG has done significant research on migrating from SMIv2 MIB modules to other data models from the same information model. • There should be collaboration between the NMRG and the OPS Area to develop tools, suitable for use in migrating between NM data models.

43. Possible Convergence Work Protocol SNMP/ISMS Netconf Syslog Content MIB models-- XML <--Standardize Modeling Language SMIv2 XML Schema Structured ASCII Authorization RADIUS/AAA AAA Operations Get-*/SET GET/EDIT Message Security SSH SSH SSH or TLS? Transport UDP->TCP TCP UDP->TCP?

44. Questions? • Thank you • dharrington@huawei.com