Network Working Group R. Atarashi Internet-Draft Internet Initiative Japan Inc. Intended status: Standards Track H. Okita Expires: August 29, 2007 Central Research Laboratory, Hitachi, Ltd. Y. Atarashi Alaxala Networks Co. Feb. 25, 2007 Consideration of NETCONF Architecture draft-atarashi-ngo-consider-architecture-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Atarashi, et al. Expires August 29, 2007 [Page 1] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Abstract The NETwork CONFiguration (NETCONF) protocol has been designed to configure routers, switches, firewalls and other network devices. This document describes a high level description of the Netconf architecture and how the Netconf framework relates to other network management protocols and architectures. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. NETCONF Protocol . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 2. NETCONF Reference Model . . . . . . . . . . . . . . . . . . . 5 3. NETCONF System Architecture . . . . . . . . . . . . . . . . . 7 3.1. NETCONF Manager . . . . . . . . . . . . . . . . . . . . . 7 3.2. NETCONF Device . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. SOAP/HTTP(S) Transport Mapping . . . . . . . . . . . . 9 3.2.2. SSH Transport Mapping . . . . . . . . . . . . . . . . 10 3.2.3. BEEP Transport Mapping . . . . . . . . . . . . . . . . 11 3.3. NETCONF System Functions . . . . . . . . . . . . . . . . . 12 4. Relation to other Protocols . . . . . . . . . . . . . . . . . 14 4.1. NETCONF Role in Network Management System . . . . . . . . 14 4.2. Network Management System Reference Model using NETCONF protocol . . . . . . . . . . . . . . . . . . . . . 14 5. NETCONF Applicability . . . . . . . . . . . . . . . . . . . . 17 5.1. Target Networks . . . . . . . . . . . . . . . . . . . . . 17 5.2. Network Operation Scenario . . . . . . . . . . . . . . . . 17 6. Event Notification . . . . . . . . . . . . . . . . . . . . . . 22 6.1. Comparison of Event Notification Protocols . . . . . . . . 22 6.2. Event Handling Architecture . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7.1. Configuration Sniffing . . . . . . . . . . . . . . . . . . 26 7.2. Spoofing of the NETOCNF Manager . . . . . . . . . . . . . 26 7.3. Spoofing of the NETCONF Device . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 32 Atarashi, et al. Expires August 29, 2007 [Page 2] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 1. Introduction 1.1. NETCONF Protocol NETCONF Protocol is specified as standardized protocol for network devices configuration by network management system. NETCONF Protocol is used to configure routers, switches, firewall appliance and other network devices. With NETCONF Protocol, the network management system can configure the network devices in unified procedure. NETCONF Protocol is a client-sever type protocol based on RPC model communication, which provides a response for each configuration request. NETCONF uses Extensible Markup Language (XML) [12] to describe its protocol messages and its configuration data. Applications can access the structure and contents of the messages and data with XML parsers. These features enable network management systems to automate its network management process. For example, with XML Stylesheet Language Transformation (XSLT), the management system can transform responses from network devices into a human- readable form to indicate the response for operators. NETCONF Protocol is divided into four layers shown in the following figure (Figure 1). NETCONF Protocol operations are classified into configuration and notification. NETCONF configuration operations are unified by NETCONF RPC. The NETCONF RPCs are mapped into transport protocols, SSH, SOAP/HTTP(S) and BEEP. NETCONF notification [5] operations are mapped directly into the transport protocols. Layer Example +-------------+ +-------------------------------------------+ | Content | | Configuration data | +-------------+ +-------------------------------------------+ | | +-------------+ +-------------------------------------------+ | Operations | | , | +-------------+ +-------------------------------------------+ | | | +-------------+ +-----------------------------+ | | RPC | | , | | +-------------+ +-----------------------------+ | | | | +-------------+ +-------------------------------------------+ | Application | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-------------------------------------------+ Figure 1: NETCONF Protocol Layers Atarashi, et al. Expires August 29, 2007 [Page 3] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 1.2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [8]. 1.3. Motivation NETCONF protocol defines function set of configurations for routers, switches, and other network devices. When network devices are configured, network behavior are changed, it impacts the performance of applications and services running on the network. It means applications and services may be able to change the network behavior using NETCONF protocol. NETCONF can be used not only for the operation management, but also for the collaboration between application and network. NETCONF Notification is reliable functions for getting configurations of network devices. It can be applied for feedback system using with NETCONF. NETCONF and NETCONF Notification are designed based on the XML technologies. XML-based protocols make collaboration with other operation systems and applications easy. XML can also deal with data model, it have a much broader range of applications. The purpose of this draft is consideration of NETCONF architecture for research application possibilities by expanding the scope to application layer. Atarashi, et al. Expires August 29, 2007 [Page 4] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 2. NETCONF Reference Model Figure 2 presents a proposed reference model for network configuration system. Network configuration system consists of two parts. One is Data model and Description part that manage abstract configuration information. The other is network monitoring and management based on SNMP. Atarashi, et al. Expires August 29, 2007 [Page 5] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 +----------------------------------------------------------------+ | Network +------+ +--------+ Data | | Configuration |Visual|<----------------->|XML | Model | | System |Design| +------------+ |Database| and | | |Tool | |netconf | |(Policy,| Description| | +--+---+ |datamodel(1)| | rules, | | | | +------------+ | Device,| | | | | etc. | | | | +---+----+ | | | | | | | +----------+ | | | +---->|XML Config|<---------+ | | |Controller| | | +-+---+--+-+ | +-------------------------/-----\--\-----------------------------+ / \ \ netconf protocol / \ \ +-----+ ISP Service +----V--+ \ +--------->/ \ Area |Router/| +V------+ / \ |Switch | |Router/| +---------+ +-------+ |Switch | |Home/SOHO| ^ +----+--+ | -PDA | | | | -Video | | +-------+ | | -Devices| | |Router/| | +---------+ | >Switch | | | /+---+---+ | | / | | | / | | +----------------------/-------------------------------------+ | | / | | | | Current +------+++ | +---+----+ | | Management |BB/ | | |SNMP/MIB| | | System |PolicyDB| | +---+----+ | | +--------+ | | | | | | | | | +---V----+ | | +--->| NMS | Monitoring/ | | +--------+ Observation | | | | +---------------------------------------|--------------------+ V netconf datamodel (2) Figure 2: NETCONF reference model Atarashi, et al. Expires August 29, 2007 [Page 6] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 3. NETCONF System Architecture In this section, we describe the architectural components of the NETCONF manager and the NETCONF device. 3.1. NETCONF Manager Figure 3 shows the components on the NETCONF manager. With these components, it automates network management operation. NETCONF Manager +--------------------------------------------------------+ |+------------------------------------------------------+| +----------+ || +-----------+ +---------+ +---------+ +------------+|| |Other | || |NETCONF | |Visualize| |User | |Configs, ||| |Network |<-++->|Automation | |Tool | |Interface| |Status, ||| |Management| || |Application| | | | | |Policies ||| |System | || | | | | | | | (XML DB) ||| |System | || +-----------+ +---------+ +---------+ +------------+|| +----------+ |+------------------------------------------------------+| | ^ ^ | | | | | | | +----------+---------------------------+ | | | | | | | | | | v +-------------+| | | | | +-------------------+ | Config || | | | | | Network Level API | | Datamodel || | | | | +-------------------+ | (XML Schema)|| | | | | ^ +-------------+| | | | | | | | | | +----------+---------------------------+ | | | | | | +------+-----------------+---------------------------+ | | | | | | | | | v v +--------------+| | | | +--------------------------+ | Config || | | | | NETCONF API | | Datamodel || | | | +--------------------------+ | (XML Schema) || | | | +--------------+| | | +----------------------------------------------------+ | +--------------------------------------------------------+ Figure 3: NETCONF Manager Components Atarashi, et al. Expires August 29, 2007 [Page 7] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Visual Design Tool: The visual Design Tool visualizes network topology and type of each device on display. It follows network topology change and update the links and nodes on the display. It is also used to validate the network topology before the actual change is carried out. User Interface: The user interface is the interface for the operators to instruct the NETCONF manager to transfer the configuration data which they create to NETCONF device via NETCONF protocol. This interface receives designation of the target device in the form of IP address or host name. This interface indicates the operator about the configuration data applied to the devices. NETCONF Application: The NETCONF application is the main component of the NETCONF manager to automate the network operation. It implements configuration operation logic. According to this logic, Network level API and NETCONF API are called from a NETCONF application. Further, the application interacts with other network management systems like SNMP server, and receives the information about events which occurred in the network from the systems. Configs, Status, Policies: An XML database on the NETCONF manager contains the configuration set, the abstract network model and the network policies, which are described in XML. XML technologies can also describe semantics including relation. We can generate device dependent configration from device independent configration using XML technology. NETCONF Configuration Datamodel: A configuration datamodel defines element type and data type in the NETCONF protocol message and configuration data. This datamodel is composed of XML schema. Components in the NETCONF manager share this datamodel. NETCONF API: NETCONF API is the API to operate the objects defined in a network device. This API , being called from upper layer application, creates NETCONF RPC message to operate the designated object(s) and transport this RPC message to corresponding NETCONF device. Network Level API: Network level API is the API to operate the objects extended over the network. This API is called from upper layer application and internally calls NETCONF API. Atarashi, et al. Expires August 29, 2007 [Page 8] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 3.2. NETCONF Device A NETCONF device receives NETCONF messages from the NETCONF manager and analyzes the messages, then it applies the result of the analysis to itself. A NETCONF device has two kinds of functional blocks, NETCONF message analysis block and device internal configuration interface. The NETCONF message analysis block receives NETCONF protocol message from the NETCONF manager. It parses the NETCONF protocol message and extracts the operation command for the network device. Components of this block vary according to the selected transport protocol. A proprietary module may use XML API like Document Object Model (DOM) [14] or Simple API for XML (SAX) [15] to parse XML documents. By these API, the module extracts NETCONF operation block from the RPC message, and starts the processes corresponding to the operation block. Throughout the parsing, configuration datamodel described in XML schema is used to validate the XML data. The processes call internal lower configuration interface of the network devices. 3.2.1. SOAP/HTTP(S) Transport Mapping In the NETCONF device with SOAP/HTTP transport mapping (Figure 4), the NETCONF message analysis block executes SSL decryption followed by HTTP session termination. It extracts SOAP data from the HTTP request and removes SOAP envelope and extracts the NETCONF RPC message including NETCONF operation message. The XSLT module or a proprietary module receives the operation message including the transported configuration data. The NETCONF device implementors can use the optional module of the Web server implementation to implement SSL, SOAP, XSLT function block. On Java 2 Enterprise Environment (J2EE), they can integrate even proprietary module(s) as Enterprise Java Bean (EJB) on EJB container. Each EJB is bound to the NETCONF operation extracted from NETCONF RPC message. Atarashi, et al. Expires August 29, 2007 [Page 9] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Configuration Data | +-------------+---------------------------+ | | | | v | | +-----------------------------------+ | | | +------------------+ +----------+ | | | | | SSL Module | | Config | | | | | +------------------+ | Model | | | | | | HTTP Engine | | (XML | | | | | +------------------+ | Schema | | | | | | SOAP Module | | | | | | | +------+-----------+ +----------+ | | | | |XSLT |Proprietary| | | | | |Module|Modules(s) | | | | | +------+-----------+ | | | +-----------------------------------+ | | | | | v | | +-----------------------------------+ | | | Network Device | | | | Internal Configuration Interface | | | +-----------------------------------+ | +-----------------------------------------+ Figure 4: NETCONF Device Architecture (SOAP/HTTP(S) Mapping) 3.2.2. SSH Transport Mapping In the NETCONF device with SSH transport mapping (Figure 5), the NETCONF message analysis block has SSH stack and XML parse/RPC stack. The SSH stack manages secure channels to the NETCONF manager, and passes the transported NETCONF protocol message and configuration data to the XML parse/RPC stack. The RPC stack specifies the requested operation and, according to the operation type, calls the corresponding internal configuration interface of the network device. Atarashi, et al. Expires August 29, 2007 [Page 10] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Configuration Data | +-------------+---------------------------+ | | | | v | | +-----------------------------------+ | | | +------------------+ +----------+ | | | | | SSH Stack | | | | | | | +------------------+ | Config | | | | | +------------------+ | Model | | | | | | XML Parse | | (XML | | | | | | /RPC Stack | | Schema) | | | | | +------------------+ +----------+ | | | | +-----++-----------+ | | | | |XSLT ||Proprietary| | | | | |Stack||Stack | | | | | +-----++-----------+ | | | +-----------------------------------+ | | | | | v | | +-----------------------------------+ | | | Network Device | | | | Internal Configuration Interface | | | +-----------------------------------+ | +-----------------------------------------+ Figure 5: NETCONF Device Architecture (SSH Mapping) 3.2.3. BEEP Transport Mapping In the NETCONF device with BEEP transport mapping (Figure 6), the NETCONF message analysis block has TLS and optionally SASL stack and BEEP stack. The TLS stack manages the secure channels to the NETCONF manager, and passes the transported NETCONF protocol message and configuration data to the BEEP stack. According to the operation type, the BEEP stack calls the corresponding internal configuration interface of a network device. Atarashi, et al. Expires August 29, 2007 [Page 11] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Configuration Data | +-------------+---------------------------+ | | | | v | | +-----------------------------------+ | | | +------------------+ +----------+ | | | | | TLS/SASL Stack | | Config | | | | | +------------------+ | Model | | | | | +------------------+ | (XML | | | | | | BEEP Stack | | Schema) | | | | | +------------------+ +----------+ | | | | +-----++-----------+ | | | | |XSLT ||Proprietary| | | | | |Stack||Modules(s) | | | | | +-----++-----------+ | | | +-----------------------------------+ | | | | | v | | +-----------------------------------+ | | | Network Device | | | | Internal Configuration Interface | | | +-----------------------------------+ | +-----------------------------------------+ Figure 6: NETCONF Device Architecture (BEEP Mapping) 3.3. NETCONF System Functions The NETCONF manager transports, via the NETCONF protocol, the configuration data customized for each NETCONF device in the network. The configuration operations are classified into merge, replace, create and delete of the configuration on the NETCONF devices. The NETCONF manager should confirm the acceptance or failure of the configuration data on the NETCONF devices by NETCONF RPC reply from the devices. In addition to the configuration function, the NETCONF protocol has a notification function[5], which allows asynchronous message transmission between the NETCONF manager and the NETCONF devices. The NETCONF devices notify errors, warnings and information about configuration changes occurred on the devices to the NETCONF manager. The NETCONF manager creates event notification subscription specifying the events of interest. In the configuration and notification operation, the NETCONF manager and the NETCONF devices share the same data model to parse the Atarashi, et al. Expires August 29, 2007 [Page 12] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 protocol message and configuration data described in XML. This datamodel is described by XML schema and its contents are mapped into objects on the NETCONF devices. From the application point of view, application on the NETCONF manager accesses these mapped objects to configure the NETCONF devices. NETCONF protocol intermediates this object operation between the NETCONF manager and the NETCONF devices. Atarashi, et al. Expires August 29, 2007 [Page 13] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 4. Relation to other Protocols 4.1. NETCONF Role in Network Management System Traditional networks require human intervention to numerous events happening in the network. Network operators should deal promptly with network events, for example, topology change due to additional router or switch they installed, and network trouble from device failure. When these events occur, the operators create substitute configuration optimized for each device and apply these configuration to each device via proprietary configuration interface of each device. The role of the NETCONF protocol is transmission of the configuration data from the NETCONF manager to the NETCONF devices, and notification of the event information about configuration data on the NETCONF devices. The objective of the NETCONF protocol adoption is the reduction of network operation cost by automating network operator's configuration task. A network management system with NETCONF system configures the network devices automatically based on the network event. Using the NETCONF protocol, the NETCONF system distributes the configurations of the devices generated by the network management system according to the pre-defined algorithm or rule. To automate network operation, network management system should detect events and gather event information in the network. The network management system combine NETCONF configuration/notification function with other event management function, for example, Simple Network Management Protocol (SNMP), IP Flow Information Export (IPFIX) protocol, SYSLOG protocol. We should consider how we combine these protocols with NETCONF protocol function. The interaction between Netconf and those protocols should be addressed. 4.2. Network Management System Reference Model using NETCONF protocol Figure 7 shows reference model of entire network management system. It includes NETCONF manager, NETCONF devices and other network management servers like SNMP server, Syslog server and Flow Collector. Atarashi, et al. Expires August 29, 2007 [Page 14] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 +-----------+ | NETCONF | Interaction | Manager |<- -----------------+--------+---------+ | | | | | +-----------+ | | | ^ | | | NETCONF | | | | Notification | +------+--------+---------+------+ | | | | | | | | v v v | | | +-------+ +------+ +---------+ | NETCONF | | |SNMP | |Syslog| |flow | | Configuration | | |Manager| |Server| |Collector| | (RPC reply) | | +-------+ +------+ +---------+ | | | ^ ^ ^ | | | | | | | | +------+--------+---------+------+ | | | | NETCONF | | | | Configuration | |SNMP |SYSLOG | IPFIX (RPC request) | | | | | | | | +--------------+----------------------+ | | | | | | | | | | v | | | | |+---------+ +---------+ +---------+ | | | | || Network | | Network | | Network |<-+--+ | | || Device | | Device | | Device |--+-----------+ | || | | | | |--+---------------------+ |+---------+ +---------+ +---------+ | | | +-------------------------------------+ Figure 7: Network Management System Reference Model using NETCONF protocol Following events can be a trigger of the NETCONF configuration in the system. Network operator's operation NETCONF notification Other event gathering At first, network operators configure network device via NETCONF protocol to define VLAN, assign IP address, initiate routing Atarashi, et al. Expires August 29, 2007 [Page 15] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 protocol, activate filtering function, and management functions. NETCONF manager applies configuration data to network devices by NETCONF RPC. Network devices start to forward frames/packets and to interact with management servers via SNMP, SYSLOG protocol, IPFIX protocol, and some other management protocols. In the configuration data, NETCONF manager tells addresses of management servers and exported information. Network devices send NETCONF notification message to the NETCONF manager when configuration status or device construction changed. These events come from direct configuration without the NETCONF protocol or parts replacement of the devices by the operators, or some failure of the devices. Configured network devices notify asynchronously the corresponding management servers of threshold exceeding of traffic counter, protocol status change, flow statistics, and so on. In these management servers, the SNMP server may access periodically network devices and read synchronously the MIB-defined management information from the devices. The NETCONF manager and the management servers interact, and the NETCONF manager receives the event notifications from the servers. Receiving these event notifications, the NETCONF manager creates substitute configuration data of the network devices to deal with the events. For example, it activates the secondary device in slave state to save user traffic when the primary device fails, and enables bandwidth restriction to shape the traffic when traffic exceeds the threshold. Atarashi, et al. Expires August 29, 2007 [Page 16] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 5. NETCONF Applicability 5.1. Target Networks NETCONF protocol has applicability for carrier network and home or Small Office Home Office (SOHO) network. Carrier network has numerous network devices widely deployed in its service area. The devices contain normally multiple vendor's products and have proprietary configuration method. By unifying configuration procedure of the numerous devices with NETCONF protocol, carrier operators can reduce their operation load. Carrier or Internet Service Provider (ISP) can use NETCONF protocol as a method for configuration of subscriber's Home/SOHO network devices as one of their service. The concept of the Home/SOHO network device configuration by the central management system, named as CallHome, is discussed in netconf WG about its required protocol procedures and its specification. 5.2. Network Operation Scenario Figure 8shows a NETCONF system usage example. In this example, when network topology changes occur, the NETCONF manager dynamically configures the routing protocol of the routers deployed in a carrier network. Atarashi, et al. Expires August 29, 2007 [Page 17] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 +-----------------------+ | NETCONF Manager | +-----------------------+ | | ^ NETCONF | | | | | | SNMP Trap +-------------+ | | | | | Career Network +-------+---------------------+-----------------------------+ | | | | | | +-------------+ | | | | Core Router | | | | +-------------+ | | | / | \ | | | /- | \- | | | / | \ | | | / | \ | | | /- OSPF | OSPF \- OSPF | | | / | \ | | | / | \ | | | /- | \- | | v / | \ | | +-------------+ +-------------+ +-------------+ | | | Edge Router | | Edge Router | | Edge Router | | | +-------------+ +-------------+ +-------------+ | +-----------------------------------------------------------+ Figure 8: NETCONF system usage example The example system has a network manager, a core router and three edge routers. The manager and the routers have NETCONF protocol stack. The NETCONF manager is connected to the core router, and the core router accommodates the edge routers to form tree topologies. The core router and the edge routers exchange route information in the network by OSPF routing protocol. We assume that operator would add additional subnet by configuring the network interface of the left side edge router. The routing information of the additional route is distributed into the other routers via OSPF routing protocol. The core router receives the additional route information via OSPF and send it to the NETCONF manager via SNMP trap. In addition to the SNMP trap, the routers can notify the configuration change via the NETCONF notification. The NETCONF manager extracts, from the SNMP trap, the route information and ID of the origin edge router. The NETCONF manager configures the router according to the new route. For example, the Atarashi, et al. Expires August 29, 2007 [Page 18] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 NETCONF manager configures filter of the router to restrict clients in newly added subnet to access a service. Receiving the SNMP trap, the NETCONF manager creates automatically the configuration data describing filter settings in XML and sends a RPC message including the configuration data in an element to the router. The router parses this RPC message and updates its filter settings. Figure 9 shows the message sequence between the NETCONF manager, the core router and the edge router when the new route is added to the edge router. Atarashi, et al. Expires August 29, 2007 [Page 19] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 NETCONF Manger Core Router Edge Router | | | | Transport Initiation | | |<------------------------------------------------------------->| | | NECONF | | | | |-------------------------------------------------------------->| | NETCONF | | | | | |<--------------------------------------------------------------| | | | | | NETCONF | | | | |-------------------------------------------------------------->| | NETCONF | | | | | |<--------------------------------------------------------------| | | | | | +-------------+ | | | Route added | | | +-------------+ | SNMP Trap | OSPF | |<------------------------------|<------------------------------| | | | +-------------+ | | | RPC Message | | | | Generation | | | +---+---------+ | NETCONF | | | | |-------------------------------------------------------------->| | | | | | +-------------------+ | | | NETCONF Operation | | | | Deployment | | NETCONF | +-------------------+ | | | |<--------------------------------------------------------------| | | | | NETCONF | | | | | |<--------------------------------------------------------------| | | | v v v Figure 9: NETCONF Sequence The NETCONF manager initiates NETCONF transport session with the edge Atarashi, et al. Expires August 29, 2007 [Page 20] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 router. When the transport is opened, they exchange message including element. If the edge router has a capability of the NETCONF notification, the NETCONF manager creates subscription of the notification about configuration change. When an operator defines an additional network on the edge router, which creates new route, the core router and the edge router exchange the additional route information via OSPF. The core router sends an SNMP trap to the NETCONF manager about the route information update. Receiving the notification about the additional route via SNMP trap, the NETCONF manager generates an RPC message to configure filtering rules on the edge router. The NETCONF manager sends the message including element inside to the edge router via NETCONF protocol. The edge router analyzes the requested RPC from the NETCONF manager, and creates additional filtering rules on its configuration store according to the transported configuration data. If the edge router succeed to create the filtering rules, it sends message to the NETCONF manager including element in the message. In addition to this message, the edge router sends asynchronously a message to the NETCONF manager to notify the configuration change. By these interaction between the NETCONF manager and the network devices, integrated with the existing management means, we can automate network operation and reduce the administrative cost. Moreover, we can tighten security by the prompt configuration against the network incidents. Atarashi, et al. Expires August 29, 2007 [Page 21] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 6. Event Notification Network management system may contain multiple network management protocols. Various event management protocols, SNMP, Syslog, IPFIX, RADIUS / DIAMETER, and etc., are specified according to the management information which operators want to obtain. Each protocol has optimized sequence, datamodel and message encoding format. When we construct a network management system, we do not need to choose NETCONF notification as the unified event notification protocol. Network management system is an organism composed of multiple management means. Important point is to integrate the multiple means to the management system and to choose appropriate management protocol for each event notification. 6.1. Comparison of Event Notification Protocols NETCONF Notification Addition, change, removal of configuration Addition, removal of a device component SNMP MIB-defined event Syslog Application independent event IPFIX Flow statistics information Sampled packets information Routing Protocol Link state information Route information RADIUS, DIAMETER Authentication, Authorization and Accounting (AAA) information Atarashi, et al. Expires August 29, 2007 [Page 22] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Proprietary Device independent management information As a general event notification means, SNMP and Syslog are widely deployed. These management protocols are widely applied to, not only a small network of a laboratory, but also enterprise's intra-network or carrier's service network. These protocols are designed as general-purpose protocol to transport various management information. SNMP trap transports almost all kinds of management information. The management information has hierarchical structure, and each information node is specified by Object Identifier. Syslog transports the notification mainly about status changes of the control processes and device components. It has no hierarchical datamodel. Its messages are described in human-readable format as the main use-case of the Syslog is message logging for operators. Unlike the general purpose protocols, IPFIX protocol, RADIUS / DIAMETER protocol and routing protocol are designed to transport flow statistics, AAA information and link state/route information, respectively. It is respective decision whether it adopt hierarchical structure for its datamodel and message format or not. In the NETCONF notification, as the NETCONF configuration, protocol messages and notification data are hierarchically described by XML so that the NETCONF manager can analyze easily the data and react automatically. The NETCONF notification conveys the event information about configurations, hardware and software on the NETCONF devices. When these components are added, removed or replaced, the NETCONF devices send the NETCONF notification message. The NETCONF notification, unlike IPFIX protocol, does not require large capacity for its transported message size and frequency. Change of configuration, hardware or software on the network device seldom occurs since it affects network service directly. A huge, or frequent notification message including many events means that the network or its device fell into terrible and unrecoverable condition. 6.2. Event Handling Architecture Figure 10 shows an example of the NETCONF manager handling the NETCONF configuration, NETCONF notification and other notification. The NETCONF notification and configuration use the same NETCONF transport including SSH, SOAP/HTTP or BEEP. Atarashi, et al. Expires August 29, 2007 [Page 23] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 NETCONF Manager +-------------------------------------------------------+ | +-------------------------------------------------+ | | | | | | | NETCONF Application | | | | | | | +-------------------------------------------------+ | | +---------------+ +--------------+ +--------------+ | | | NETCONF | | NETCONF | | Other | | | | Configuration | | Notification | | Notification | | | |+-------------+| | | | | | | || Operation || | | | | | | |+-------------+| | | | | | | |+-------------+| | | | | | | || RPC || | | | | | | |+-------------+| | | | | | | +---------------+ +--------------+ | | | | +--------------------------------+ | | | | | NETCONF Transport | | | | | | +-----+ +------+ +------+ | | | | | | | SSH | | SOAP | | BEEP | | | | | | | +-----+ +------+ +------+ | | | | | +--------------------------------+ +--------------+ | | | ^ ^ ^ ^ | | | | | | | | +-------+--+----------+---------------------+-----+-----+ | | | | | | | | | |Event | | | | |Notification NETCONF| | NETCONF |NETCONF | +----+ RPC | | RPC |Event | | |Other NMS request| | reply |Notification | | | | | | | +----+ | | | | ^ v | | | | +------------------------------------------------+ | NETCONF Device | +------------------------------------------------+ Figure 10: Notification Handling on the Network Manager This NETCONF manager handles, in addition to the NETCONF notification, other event notifications on each transport protocol. The other notifications comes directly from the NETCONF devices or indirectly from other management server. Operators should select the notification method to suit the event. Atarashi, et al. Expires August 29, 2007 [Page 24] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 The NETCONF application integrates the network events received by these multiple methods. According to the notification content, for example, router added, device status changed, or flow threshold exceeded, the NETCONF application selects the countermeasure and apply it to the corresponding devices via the NETCONF configuration. Atarashi, et al. Expires August 29, 2007 [Page 25] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 7. Security Considerations The NETCONF system treats configurations of the network devices. The configuration data is important and critical by nature. It can reveal the network topology, address assignment, administrator's password, flow filtering policy, user authentication policy, and so on. So, it requires us to consider the security model for the NETCONF system. To consider the security model of the NETCONF system, we need to clarify the possible threats in the system. We can assume following threats on the NETCONF system. 7.1. Configuration Sniffing Threat: The configuration data can be sniffed on the route between a NETCONF manager and a network device. Solution: The NETCONF system can use data encryption for the transported message. We can use SSH/SSL/TSL for encryption in the transport layer. Also, we can use XML encryption [XML-ENC] in the content layer. 7.2. Spoofing of the NETOCNF Manager Threat: The network devices receive their configuration data from the NETCONF manager. If a spoofing NETCONF manager sends the untruth configuration data, the network device falls into inappropriate behaviour and the network are confused. Solution: The NETCONF system can use authentication of the NETCONF manager. At the session initiation stage, The NETCONF device can justify the manager by authentication method of the SSH/SSH/TLS transport protocols. Also, the NETCONF device can justify the RPC message generated by the NETCONF manager by XML signature [11]. 7.3. Spoofing of the NETCONF Device Threat: If the NETCONF system is configured to automatically start NETCONF session with the newly added NETCONF device, the malicious user can obtain the configuration data by introducing his computer pretending to be NETCONF device. Not only the malicious user, proper users are possible to connect their network devices to the network. Atarashi, et al. Expires August 29, 2007 [Page 26] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Solution: Same as the authentication of the NETCONF manager, the NETCONF system can use authentication of the NETCONF device. The NETCONF manager prepares the database of the proper devices and justifies the newly added devices in the initiation session, for example, in the SSH/SSL/TLS transport initiation stage, or in the message exchange stage. When the NETCONF system uses the SOAP/HTTP as the transport method, the system can adopt HTTP over TLS [9] concept to improve its security. The HTTP over TLS mechanism is widely deployed to existing implementation of HTTP server and application server. NETCONF system implementors can reduce implementation cost by these existing resource. Atarashi, et al. Expires August 29, 2007 [Page 27] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 8. IANA Considerations This document has no actions for IANA. Atarashi, et al. Expires August 29, 2007 [Page 28] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 9. References [1] Enns, R. , "NETCONF Configuration Protocol" , draft-ietf-netconf-prot-12 (work in progress) , March 2006 . [2] Lear, E. and K. Crozier , "Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)" , draft-ietf-netconf-beep-10 (work in progress) , March 2006 . [3] Goddard, T. , "Using the Network Configuration Protocol (NETCONF) Over the Simple Object Access Protocol (SOAP)" , draft-ietf-netconf-soap-08 (work in progress) , March 2006 . [4] Wasserman, M. and T. Goddard , "Using the NETCONF Configuration Protocol over Secure Shell (SSH)" , draft-ietf-netconf-ssh-06 (work in progress) , March 2006 . [5] Trevino, H. and S. Chisholm , "NETCONF Event Notifications" , draft-ietf-netconf-notification-06 (work in progress) , February 2007 . [6] Admankar, S. and S. Chisholm , "Using XML Schema to define Netconf Content" , draft-chisholm-netconf-model-06 (work in progress) , February 2007 . [7] Harrington, D. and J. Schoenwaelder , "Transport Subsystem for the Simple Network Management Protocol (SNMP)" , draft-ietf-isms-tmsm-06 (work in progress) , February 2007 . [8] Bradner, S. , "Key words for use in RFCs to Indicate Requirement Levels" , BCP 14 , RFC 2119 , March 1997 . [9] Rescorla, E. , "HTTP Over TLS" , RFC 2818 , May 2000 . [10] Harrington, D. , Presuhn, R. , and B. Wijnen , "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" , STD 62 , RFC 3411 , December 2002 . [11] Eastlake, D. , Reagle, J. , and D. Solo , "XML-Signature Syntax and Processing" , RFC 3075 , March 2001 . [12] Bray, T. , Paoli, J. , and C. Sperberg-McQueen , "XML 1.0 Recommendation" , World Wide Web Consortium FirstEdition REC- xml-19980210 , February 1998 , . [13] Eastlake, D. and J. Reagle , "XML Encryption Syntax and Atarashi, et al. Expires August 29, 2007 [Page 29] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Processing" , World Wide Web Consortium Recommendation REC- xmlenc-core-20021210 , December 2002 , . [14] Robie, J. , Hegaret, P. , Nicol, G. , Byrne, S. , Hors, A. , Wood, L. , and M. Champion , "Document Object Model (DOM) Level 3 Core Specification" , World Wide Web Consortium Recommendation REC-DOM-Level-3-Core-20040407 , April 2004 , . [15] "Simple API for XML (SAX)" . Atarashi, et al. Expires August 29, 2007 [Page 30] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Authors' Addresses Ray S. Atarashi Internet Initiative Japan Inc. Jinbocho Mitsui Bldg. 1-105 Kanda Jinbo-cho Chiyoda-ku, Tokyo 101-0051 Japan Phone: +81-3-5205-6464 Fax: +81-3-5205-6466 Email: ray@iijlab.net Hideki Okita Central Research Laboratory, Hitachi, Ltd. 1-280 Higashi-Koigakubo Kokubunji, Tokyo 185-8601 Japan Phone: +81-42-323-1111 Fax: +81-42-327-7868 Email: hideki.okita.pf@hitachi.com Yoshifumi Atarashi Alaxala Networks Co. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1200 Fax: +81-44-549-1272 Email: atarashi@alaxala.net Atarashi, et al. Expires August 29, 2007 [Page 31] Internet-Draft Consideration of NETCONF Architecture Feb. 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Atarashi, et al. Expires August 29, 2007 [Page 32]