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-gtSSH
SSH
SSH or TLS?
Transport
UDP-gtTCP
TCP
UDP-gtTCP?
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-gtSSH
SSH
SSH or TLS
Transport
UDP-gtTCP
TCP
UDP-gtTCP
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-gtTCP
TCP
UDP-gtTCP
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-gtTCP
TCP
UDP-gtTCP
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-gtTCP
TCP
UDP-gtTCP
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
lt--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-gtTCP
TCP
UDP-gtTCP?
44
Questions?

• Thank you
• dharrington_at_huawei.com