RFC 6632
An Overview of the IETF Network Management Standards
Pages: 85
Informational
Informational
Part 1 of 5 – Pages 1 to 15
Internet Engineering Task Force (IETF) M. Ersue, Ed. Request for Comments: 6632 Nokia Siemens Networks Category: Informational B. Claise ISSN: 2070-1721 Cisco Systems, Inc. June 2012 An Overview of the IETF Network Management StandardsAbstract
This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6632.
Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................4 1.1. Scope and Target Audience ..................................4 1.2. Related Work ...............................................5 1.3. Terminology ................................................6 2. Core Network Management Protocols ...............................8 2.1. Simple Network Management Protocol (SNMP) ..................8 2.1.1. Architectural Principles of SNMP ....................8 2.1.2. SNMP and Its Versions ...............................9 2.1.3. Structure of Managed Information (SMI) .............11 2.1.4. SNMP Security and Access Control Models ............12 2.1.4.1. Security Requirements on the SNMP Management Framework ......................12 2.1.4.2. User-Based Security Model (USM) ...........12 2.1.4.3. View-Based Access Control Model (VACM) ....13 2.1.5. SNMP Transport Subsystem and Transport Models ......13 2.1.5.1. SNMP Transport Security Model .............14 2.2. Syslog Protocol ...........................................15 2.3. IP Flow Information eXport (IPFIX) and Packet SAMPling (PSAMP) Protocols ................................16 2.4. Network Configuration .....................................19 2.4.1. Network Configuration Protocol (NETCONF) ...........19 2.4.2. YANG - NETCONF Data Modeling Language ..............21 3. Network Management Protocols and Mechanisms with Specific Focus .................................................23 3.1. IP Address Management .....................................23 3.1.1. Dynamic Host Configuration Protocol (DHCP) .........23 3.1.2. Ad Hoc Network Autoconfiguration ...................24 3.2. IPv6 Network Operations ...................................25 3.3. Policy-Based Management ...................................26 3.3.1. IETF Policy Framework ..............................26
3.3.2. Use of Common Open Policy Service (COPS)
for Policy Provisioning (COPS-PR) ..................26
3.4. IP Performance Metrics (IPPM) .............................27
3.5. Remote Authentication Dial-In User Service (RADIUS) .......29
3.6. Diameter Base Protocol (Diameter) .........................31
3.7. Control and Provisioning of Wireless Access Points
(CAPWAP) ..................................................35
3.8. Access Node Control Protocol (ANCP) .......................36
3.9. Application Configuration Access Protocol (ACAP) ..........36
3.10. XML Configuration Access Protocol (XCAP) .................37
4. Network Management Data Models .................................38
4.1. IETF Network Management Data Models .......................39
4.1.1. Generic Infrastructure Data Models .................39
4.1.2. Link-Layer Data Models .............................40
4.1.3. Network-Layer Data Models ..........................40
4.1.4. Transport-Layer Data Models ........................40
4.1.5. Application-Layer Data Models ......................41
4.1.6. Network Management Infrastructure Data Models ......41
4.2. Network Management Data Models - FCAPS View ...............41
4.2.1. Fault Management ...................................42
4.2.2. Configuration Management ...........................44
4.2.3. Accounting Management ..............................45
4.2.4. Performance Management .............................46
4.2.5. Security Management ................................48
5. Security Considerations ........................................49
6. Contributors ...................................................51
7. Acknowledgements ...............................................52
8. Informative References .........................................52
Appendix A. High-Level Classification of Management Protocols
and Data Models .......................................77
A.1. Protocols Classified by Standards Maturity in the IETF .....77
A.2. Protocols Matched to Management Tasks ......................79
A.3. Push versus Pull Mechanism .................................80
A.4. Passive versus Active Monitoring ...........................80
A.5. Supported Data Model Types and Their Extensibility ........81
Appendix B. New Work Related to IETF Management Standards .........83
B.1. Energy Management (EMAN) ...................................83
1. Introduction
1.1. Scope and Target Audience
This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents where they exist and classifies the standards for easy orientation. The target audience of the document is, on the one hand, IETF working groups, which aim to select appropriate standard management protocols and data models to address their needs concerning network management. On the other hand, the document can be used as an overview and guideline by non-IETF Standards Development Organizations (SDOs) planning to use IETF management technologies and data models for the realization of management applications. The document can also be used to initiate a discussion between the bodies with the goal to gather new requirements and to detect possible gaps. Finally, this document is directed to all interested parties that seek to get an overview of the current set of the IETF network management protocols such as network administrators or newcomers to the IETF. Section 2 gives an overview of the IETF core network management standards with a special focus on Simple Network Management Protocol (SNMP), syslog, IP Flow Information eXport / Packet SAMPling (IPFIX/ PSAMP), and Network Configuration (NETCONF). Section 3 discusses IETF management protocols and mechanisms with a specific focus, e.g., IP address management or IP performance management. Section 4 discusses IETF data models, such as MIB modules, IPFIX Information Elements, Syslog Structured Data Elements, and YANG modules designed to address a specific set of management issues and provides two complementary overviews for the network management data models standardized within the IETF. Section 4.1 focuses on a broader view of models classified into categories such as generic and infrastructure data models as well as data models matched to different layers. Whereas Section 4.2 structures the data models following the management application view and maps them to the network management tasks fault, configuration, accounting, performance, and security management. Appendix A guides the reader for the high-level selection of management standards. For this, the section classifies the protocols according to high-level criteria, such as push versus pull mechanisms, passive versus active monitoring, as well as categorizes the protocols concerning the network management task they address and their data model extensibility. If the reader is interested only in a subset of the IETF network management protocols and data models
described in this document, Appendix A can be used as a dispatcher to the corresponding chapter. Appendix B gives an overview of the new work on Energy Management in the IETF. This document mainly refers to Proposed, Draft, or Internet Standard documents from the IETF (see [RFCSEARCH]). Whenever valuable, Best Current Practice (BCP) documents are referenced. In exceptional cases, and if the document provides substantial guideline for standard usage or fills an essential gap, Experimental and Informational RFCs are noticed and ongoing work is mentioned. Information on active and concluded IETF working groups (e.g., their charters, published or currently active documents, and mail archives) can be found at [IETF-WGS]). Note that this document does not cover OAM technologies on the data- path including MPLS forwarding plane and control plane protocols (e.g., OAM of tunnels, MPLS-TP OAM, and pseudowire) as well as the corresponding management models and MIB modules. For a list of related work, see Section 1.2.1.2. Related Work
"Internet Protocols for the Smart Grid" [RFC6272] gives an overview and guidance on the key protocols of the Internet Protocol Suite. In analogy to [RFC6272], this document gives an overview of the IETF network management standards and their usage scenarios. "Overview of the 2002 IAB Network Management Workshop" [RFC3535] documented strengths and weaknesses of some IETF management protocols. In choosing existing protocol solutions to meet the management requirements, it is recommended that these strengths and weaknesses be considered, even though some of the recommendations from the 2002 IAB workshop have become outdated, some have been standardized, and some are being worked on within the IETF. "Guidelines for Considering Operations and Management of New Protocols and Extensions" [RFC5706] recommends working groups consider operations and management needs and then select appropriate management protocols and data models. This document can be used to ease surveying the IETF Standards Track network management protocols and management data models. "Multiprotocol Label Switching (MPLS) Management Overview" [RFC4221] describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS
network management, where "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks" [RFC6371] describes the OAM Framework for MPLS-based Transport Networks. "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms" [OAM-OVERVIEW] gives an overview of the OAM toolset for detecting and reporting connection failures or measuring connection performance parameters. "An Overview of the OAM Tool Set for MPLS-based Transport Networks" [OAM-ANALYSIS] provides an overview of the OAM toolset for MPLS-based Transport Networks including a brief summary of MPLS-TP OAM requirements and functions and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each MPLS-TP OAM tool are listed in separate documents, which are referenced. "MPLS-TP MIB-based Management Overview" [MPLSTP-MIB] describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. Note that so far, the IETF has not developed specific technologies for the management of sensor networks. IP-based sensors or constrained devices in such an environment, i.e., with very limited memory and CPU resources, can use, e.g., application-layer protocols to do simple resource management and monitoring.1.3. Terminology
This document does not describe standard requirements. Therefore, key words from RFC 2119 [RFC2119] are not used in the document. o 3GPP: 3rd Generation Partnership Project, a collaboration between groups of telecommunications associations, to prepare the third- generation (3G) mobile phone system specification. o Agent: A software module that performs the network management functions requested by network management stations. An agent may be implemented in any network element that is to be managed, such as a host, bridge, or router. The 'management server' in NETCONF terminology. o BCP: An IETF Best Current Practice document. o CLI: Command Line Interface. A management interface that system administrators can use to interact with networking equipment.
o Data model: A mapping of the contents of an information model into
a form that is specific to a particular type of datastore or
repository (see [RFC3444]).
o Event: An occurrence of something in the "real world". Events can
be indicated to managers through an event message or notification.
o IAB: Internet Architecture Board
o IANA: Internet Assigned Numbers Authority, an organization that
oversees global IP address allocation, autonomous system number
allocation, media types, and other IP-related code point
allocations.
o Information model: An abstraction and representation of entities
in a managed environment, their properties, attributes,
operations, and the way they relate to each other, independent of
any specific repository, protocol, or platform (see [RFC3444]).
o ITU-T: International Telecommunication Union - Telecommunication
Standardization Sector
o Managed object: A management abstraction of a resource; a piece of
management information in a MIB module. In the context of SNMP, a
structured set of data variables that represent some resource to
be managed or other aspect of a managed device.
o Manager: An entity that acts in a manager role, either a user or
an application. The counterpart to an agent. A 'management
client' in NETCONF terminology.
o Management Information Base (MIB): An information repository with
a collection of related objects that represent the resources to be
managed.
o MIB module: MIB modules usually contain object definitions, may
contain definitions of event notifications, and sometimes include
compliance statements in terms of appropriate object and event
notification groups. A MIB that is provided by a management agent
is typically composed of multiple instantiated MIB modules.
o Modeling language: A modeling language is any artificial language
that can be used to express information or knowledge or systems in
a structure that is defined by a consistent set of rules.
Examples are Structure of Management Information Version 2 (SMIv2)
[STD58], XML Schema Definition (XSD) [XSD-1], and YANG [RFC6020].
o Notification: An unsolicited message sent by an agent to a
management station to notify it of an unusual event.
o OAM: Operations, Administration, and Maintenance
o PDU: Protocol Data Unit, a unit of data, which is specified in a
protocol of a given layer consisting protocol-control information
and possibly layer-specific data.
o Principal: An application, an individual, or a set of individuals
acting in a particular role, on whose behalf access to a service
or MIB is allowed.
o RELAX NG: REgular LAnguage for XML Next Generation, a schema
language for XML [RELAX-NG].
o SDO: Standards Development Organization
o SMI: Structure of Managed Information, the notation and grammar
for the managed information definition used to define MIB modules
[STD58].
o STDnn: An Internet Standard published at IETF, also referred as
Standard, e.g., [STD62].
o URI: Uniform Resource Identifier, a string of characters used to
identify a name or a resource on the Internet [STD66]. Can be
classified as locators (URLs), as names (URNs), or as both.
o XPATH: XML Path Language, a query language for selecting nodes
from an XML document [XPATH].
2. Core Network Management Protocols
2.1. Simple Network Management Protocol (SNMP)
2.1.1. Architectural Principles of SNMP
The SNMPv3 Framework [RFC3410], builds upon both the original SNMPv1
and SNMPv2 Frameworks. The basic structure and components for the
SNMP Framework did not change between its versions and comprises the
following components:
o managed nodes, each with an SNMP entity providing remote access to
management instrumentation (the agent),
o at least one SNMP entity with management applications (the
manager), and
o a management protocol used to convey management information
between the SNMP entities and management information.
During its evolution, the fundamental architecture of the SNMP
Management Framework remained consistent based on a modular
architecture, which consists of:
o a generic protocol definition independent of the data it is
carrying,
o a protocol-independent data definition language,
o an information repository containing a data set of management
information definitions (the Management Information Base, or MIB),
and
o security and administration.
As such, the following standards build up the basis of the current
SNMP Management Framework:
o the SNMPv3 protocol [STD62],
o the modeling language SMIv2 [STD58], and
o the MIB modules for different management issues.
The SNMPv3 Framework extends the architectural principles of SNMPv1
and SNMPv2 by:
o building on these three basic architectural components, in some
cases, incorporating them from the SNMPv2 Framework by reference,
and
o by using the same layering principles in the definition of new
capabilities in the security and administration portion of the
architecture.
2.1.2. SNMP and Its Versions
SNMP is based on three conceptual entities: Manager, Agent, and the
Management Information Base (MIB). In any configuration, at least
one manager node runs SNMP management software. Typically, network
devices, such as bridges, routers, and servers, are equipped with an
agent. The agent is responsible for providing access to a local MIB
of objects that reflects the resources and activity at its node.
Following the manager-agent paradigm, an agent can generate notifications and send them as unsolicited messages to the management application. SNMPv2 enhances this basic functionality with an Inform PDU, a bulk transfer capability and other functional extensions like an administrative model for access control, security extensions, and Manager-to-Manager communication. SNMPv2 entities can have a dual role as manager and agent. However, neither SNMPv1 nor SNMPv2 offers sufficient security features. To address the security deficiencies of SNMPv1/v2, SNMPv3 [STD62] has been issued. "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework" [BCP074] gives an overview of the relevant Standard documents on the three SNMP versions. The BCP document furthermore describes how to convert MIB modules from SMIv1 to SMIv2 format and how to translate notification parameters. It also describes the mapping between the message processing and security models. SNMP utilizes the MIB, a virtual information store of modules of managed objects. Generally, standard MIB modules support common functionality in a device. Operators often define additional MIB modules for their enterprise or use the Command Line Interface (CLI) to configure non-standard data in managed devices and their interfaces. SNMPv2 Trap and Inform PDUs can alert an operator or an application when some aspects of a protocol fail or encounter an error condition, and the contents of a notification can be used to guide subsequent SNMP polling to gather additional information about an event. SNMP is widely used for the monitoring of fault and performance data and with its stateless nature, SNMP also works well for status polling and determining the operational state of specific functionality. The widespread use of counters in standard MIB modules permits the interoperable comparison of statistics across devices from different vendors. Counters have been especially useful in monitoring bytes and packets going in and out over various protocol interfaces. SNMP is often used to poll a basic parameter of a device (e.g., sysUpTime, which reports the time since the last re- initialization of the network management portion of the device) to check for operational liveliness and to detect discontinuities in counters. Some operators also use SNMP for configuration management in their environment (e.g., for systems based on Data Over Cable Service Interface Specification (DOCSIS) such as cable modems).
SNMPv1 [RFC1157] has been declared Historic and its use is not recommended due to its lack of security features. "Introduction to Community-based SNMPv2" [RFC1901] is an Experimental RFC, which has been declared Historic, and its use is not recommended due to its lack of security features. Use of SNMPv3 [STD62] is recommended due to its security features, including support for authentication, encryption, message timeliness and integrity checking, and fine-grained data access controls. An overview of the SNMPv3 document set is in [RFC3410]. Standards exist to use SNMP over diverse transport and link-layer protocols, including Transmission Control Protocol (TCP) [STD07], User Datagram Protocol (UDP) [STD06], Ethernet [RFC4789], and others (see Section 2.1.5.1).2.1.3. Structure of Managed Information (SMI)
SNMP MIB modules are defined with the notation and grammar specified as the Structure of Managed Information (SMI). The SMI uses an adapted subset of Abstract Syntax Notation One (ASN.1) [ITU-X680]. The SMI is divided into three parts: module definitions, object definitions, and notification definitions. o Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module. o Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax and semantics of a managed object. o Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely convey the syntax and semantics of a notification. SMIv1 is specified in "Structure and Identification of Management Information for TCP/IP-based Internets" [RFC1155] and "Concise MIB Definitions" [RFC1212], both part of [STD16]. [RFC1215] specifies conventions for defining SNMP traps. Note that SMIv1 is outdated and its use is not recommended. SMIv2 is the new notation for managed information definitions and should be used to define MIB modules. SMIv2 is specified in the following RFCs. With the exception of BCP 74, they are all part of [STD58]:
o [RFC2578] defines Version 2 of the Structure of Management Information (SMIv2), o [RFC2579] defines the textual conventions macro for defining new types and it provides a core set of generally useful textual convention definitions, o [RFC2580] defines conformance statements and requirements for defining agent and manager capabilities, and o [BCP074] defines the mapping rules for and the conversion of MIB modules between SMIv1 and SMIv2 formats.2.1.4. SNMP Security and Access Control Models
2.1.4.1. Security Requirements on the SNMP Management Framework
Several of the classical threats to network protocols are applicable to management problem space and therefore are applicable to any security model used in an SNMP Management Framework. This section lists primary and secondary threats, and threats that are of lesser importance (see [RFC3411] for the detailed description of the security threats). The primary threats against which SNMP Security Models can provide protection are, "modification of information" by an unauthorized entity, and "masquerade", i.e., the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal. Secondary threats against which SNMP Security Models can provide protection are "message stream modification", e.g., reordering, delay, or replay of messages, and "disclosure", i.e., the danger of eavesdropping on the exchanges between SNMP engines. There are two threats against which the SNMP Security Model does not protect, since they are deemed to be of lesser importance in this context: Denial of Service and Traffic Analysis (see [RFC3411]).2.1.4.2. User-Based Security Model (USM)
SNMPv3 [STD62] introduced the User-based Security Model (USM). USM is specified in [RFC3414] and provides authentication and privacy services for SNMP. Specifically, USM is designed to secure against the primary and secondary threats discussed in Section 2.1.4.1. USM does not secure against Denial of Service and attacks based on Traffic Analysis.
The USM supports following security services:
o Data integrity is the provision of the property that data has not
been altered or destroyed in an unauthorized manner, nor have data
sequences been altered to an extent greater than can occur non-
maliciously.
o Data origin authentication is the provision of the property that
the claimed identity of the user on whose behalf received data was
originated is supported.
o Data confidentiality is the provision of the property that
information is not made available or disclosed to unauthorized
individuals, entities, or processes.
o Message timeliness and limited replay protection is the provision
of the property that a message whose generation time is outside of
a specified time window is not accepted.
See [RFC3414] for a detailed description of SNMPv3 USM.
2.1.4.3. View-Based Access Control Model (VACM)
SNMPv3 [STD62] introduced the View-based Access Control (VACM)
facility. The VACM is defined in [RFC3415] and enables the
configuration of agents to provide different levels of access to the
agent's MIB. An agent entity can restrict access to a certain
portion of its MIB, e.g., restrict some principals to view only
performance-related statistics or disallow other principals to read
those performance-related statistics. An agent entity can also
restrict the access to monitoring (read-only) as opposed to
monitoring and configuration (read-write) of a certain portion of its
MIB, e.g., allowing only a single designated principal to update
configuration parameters.
VACM defines five elements that make up the Access Control Model:
groups, security level, contexts, MIB views, and access policy.
Access to a MIB module is controlled by means of a MIB view.
See [RFC3415] for a detailed description of SNMPv3 VACM.
2.1.5. SNMP Transport Subsystem and Transport Models
The User-based Security Model (USM) was designed to be independent of
other existing security infrastructures to ensure it could function
when third-party authentication services were not available. As a
result, USM utilizes a separate user and key-management
infrastructure. Operators have reported that the deployment of a separate user and key-management infrastructure in order to use SNMPv3 is costly and hinders the deployment of SNMPv3. SNMP Transport Subsystem [RFC5590] extends the original SNMP architecture and Transport Model and enables the use of transport protocols to provide message security unifying the administrative security management for SNMP and other management interfaces. Transport Models are tied into the SNMP Framework through the Transport Subsystem. The Transport Security Model [RFC5591] has been designed to work on top of lower-layer, secure Transport Models. The SNMP Transport Model defines an alternative to existing standard transport mappings described in [RFC3417], e.g., for SNMP over UDP, in [RFC4789] for SNMP over IEEE 802 networks, and in the Experimental RFC [RFC3430] defining SNMP over TCP.2.1.5.1. SNMP Transport Security Model
The SNMP Transport Security Model [RFC5591] is an alternative to the existing SNMPv1 and SNMPv2 Community-based Security Models [BCP074], and the User-based Security Model [RFC3414], part of [STD62]. The Transport Security Model utilizes one or more lower-layer security mechanisms to provide message-oriented security services. These include authentication of the sender, encryption, timeliness checking, and data integrity checking. A secure Transport Model sets up an authenticated and possibly encrypted session between the Transport Models of two SNMP engines. After a transport-layer session is established, SNMP messages can be sent through this session from one SNMP engine to the other. The new Transport Model supports the sending of multiple SNMP messages through the same session to amortize the costs of establishing a security association. The Secure Shell (SSH) Transport Model [RFC5592] and the Transport Layer Security (TLS) Transport Model [RFC6353] are current examples of Transport Security Models. The SSH Transport Model makes use of the commonly deployed SSH security and key-management infrastructure. Furthermore, [RFC5592] defines MIB objects for monitoring and managing the SSH Transport Model for SNMP.
The Transport Layer Security (TLS) Transport Model [RFC6353] uses either the TLS protocol [RFC5246] or the Datagram Transport Layer Security (DTLS) protocol [RFC6347]. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. The TLS Transport Model supports the sending of SNMP messages over TLS and TCP and over DTLS and UDP. Furthermore, [RFC6353] defines MIB objects for managing the TLS Transport Model for SNMP. [RFC5608] describes the use of a Remote Authentication Dial-In User Service (RADIUS) service by SNMP secure Transport Models for authentication of users and authorization of services. Access control authorization, i.e., how RADIUS attributes and messages are applied to the specific application area of SNMP Access Control Models, and VACM in particular has been specified in [RFC6065].
(page 15 continued on part 2)