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

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.

The IETF-Standard Management Framework The Established Concepts

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

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

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)

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)

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

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

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

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

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)

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)

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

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

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

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.

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

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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

Questions? Thank you