Internet Draft Suzanne Woolf draft-ops-operator-req-mgmt-00.txt Metromedia Fiber Networks Expires: August 11, 2001 Bill Woodcock Packet Clearing House July 1, 2001 Operator Requirements of Infrastructure Management Methods Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 1. Abstract This document describes the network operator community's requirements of the configuration, management, and debugging interfaces of the devices of which the Internet is built, and establishes a baseline of minimum functionality against which proposed device-management interfaces can be evaluated. This document is in the process of being developed through discussion on the ops-nm@ops.ietf.org mailing list, which was created for this purpose. In this -00 incarnation, this is a very rough work-in-progress, and is intended to stimulate discussion within the _operator_ community. 2. Conventions used in this document 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 [RFC-2119]. The word "device" is used herein to describe any piece of managed network equipment, such as an IP router, an Ethernet switch, or a fiber DACS. The words "operator" and "operators" are used herein to describe representative members of the community of engineers who design, configure, test, maintain, and debug the networks of which the Internet is built. The words "developer" and "developers" are used herein to decribe representative members of the community of programmers who design and implement the configuration and management portions of devices' operating systems. The phrase "snippet" is used herein to describe a set of device configuration commands which are valid and sufficient to produce a desired change in the configuration of a device, yet do not constitute the whole configuration of the device. For example, the set of commands which configure a single interface are a snippet. Woolf & Woodcock draft-ops-operator-req-mgmt-00.txt [Page 1] Internet Draft Operator Requirements June 2001 of Infrastructure Management Methods Table of Content 1. Introduction 2. Interactive Communications Methods 2.1. Mandatory 2.2. Optional 2.3. Counterindicated 3. File Transfer Methods 3.1. Mandatory 3.2. Optional 3.3. Counterindicated 4. Syntax 4.1. Universality & Exceptions 4.2. Verbosity & Completeness 4.3. Templates, Lists, and Tokenization 5. Authentication & Permissions 6. Security 7. Traps and Logging ... n. Open Issues n+1. Security Considerations n+2. References n+3. Authors' Addresses 1. Introduction Over the past decade, operators' configuration practices and the tools and interfaces which developers have been creating have diverged. This has led to great inefficiency in the practices of operators who have had to write tools to meet their own needs or do without, and great waste on the part of developers who bring tools to market which do not meet operators' needs. This document is a work item from interim meetings of the Operations and Management Area, hosted by the Area Directors at the Minneapolis IETF and subsequently in conjunction with the North American Network Operators' Group meeting on May 23-24, 2001 in Scottsdale, Arizona. At those meetings, operators and developers discussed this divergence and its possible remedies, formed a mailing list (ops-nm@ops.ietf.org) for further discussion, and resolved to produce this document, an informational RFC clearly specifying the needs of the operator community and establishing a baseline of functionality for developers to implement in devices. All of the requirements rest upon these basic principles: - All interaction with devices look the same at the ASCII level. Devices should not require different protocol, syntax, or encoding depending upon who manufactured the device, who is communicating with it, or upon the medium by which communication is acheived. - Devices should behave safely and securely. That is, the default mode of operation of any device or portion of a device should be as inert, static, and secure as possible, and the default mode or configuration should be apparent. Deviations from this state must be explicitly performed by the operator. - Interfaces should be optimized for worst-case operation, not best-case operation. Best-case is a group of programmers working alone in a fully-stocked lab environment with a testbed network of known and contained parameters and no time pressure. Worst case is a junior operator in the field, crouched in front of a rack of unidentified and undocumented equipment in a hot, dark, noisy machine room, with senior management yelling in both ears about thousands of customers out of service, and only a VT100 serial terminal at hand. Worst-case is far more common than best-case. 2. Interactive Communications Methods The primary means by which device configuration, maintenance, and debugging is performed is through command-line interaction with an individual operator. This is thus the most critical means of communication between operator and device, and the one to which developers need to be most attentive. 2.1. Mandatory Interactive Communications Methods Serial, specifically RJ45 (pinout to be specified later) Telnet ssh 2.2. Optional Interactive Communications Methods kerberized rlogin 2.3. Counterindicated Interactive Communications Methods Curses-based interface or menuing system http/html We're currently debating whether front-panel LCD displays with button navigation should be included in this section. On the one hand, they provide almost no value most of the time, since they're limited to physical in-person interaction. On the other hand, when no other tools are available, they do provide some minimum communications capability. The down-side to this is that their development must perforce come at some opportunity-cost. The current position of this document is that we do not object to the inclusion of a front-panel display if it does not detract in any way from implementation of the mandatory and optional communications methods. 3. File Transfer Methods Most devices contain primarily just file transfer _clients_ rather than operating as file transfer _servers_. This addresses many of the security concerns surrounding authenticated and unencrypted file service. It is occasionally useful for devices to also act as servers in order to assist in the bootstrapping of neighbor devices. When this is the case, it is strongly recommended that developers restrict file _service_ to files which contain no sensitive information, like operating system images, and that access be read-only. 3.1. Mandatory File Transfer Methods scp tftp xmodem 3.2. Optional File Transfer Methods ftp (strongly recommended) bootp zmodem 3.3. Counterindicated File Transfer Methods http 4. Syntax 4.1. Syntax: Universality & Exceptions A common configuration language needs to exist between platforms. For example, an interface should be named by its position within its host chassis and by any logical subdivision of the physical interface, and the syntax by which it's named should be exactly the same regardless of the vendor of the equipment. Reads and writes should, wherever possible, share the same name-space. For example, while SNMP OIDs can be used in either SNMP read or write mode, they're not the same descriptors that are currently used in either device configuration or command-line device output; they're also not human-readable, and don't map statically to the human-readable names. Thus in the long term, they're not useful to the operator community. The syntax of any management language must be portable to different transport methods, and not be coupled explicitly to a single protocol like SNMP. That is, one must be able to dictate commands over the telephone, or type them in on a serial port, or via SSH, all in the same syntax. The syntax of data collected from reads should be, wherever possible, the same as the sytax which would be used to perform any corresponding write. An example of this is the command "show configuration" in IOS, which produces a file which can be re-entered into another router of similar hardware configuration to produce an identical configuration. Note that this process could work better in IOS, but the intent is correct. A counter-example is the IOS command "show access-list" which produces text which appears to be configuration, but cannot be re-entered into a router. The syntax of the response to a query about device state should, to the extent possible, be congruent with the syntax of related configuration. For example, one form of a query to show matches against an access-list should express matches in the same parameter order and other notation used by the access-list, showing consistency in regular expression matching rules and netmask notation conventions. 4.2. Syntax: Verbosity & Completeness Developers should consider including a "smart diff" utility in devices, which could take as input two configurations or snippets, and produce a snippet which, when applied to the first configuration, will result in the second configuration. SMTP should be taken as a model of a good on-the-wire protocol for operational use. It's easily implemented, whether in code or in scripts. It's also easily typed manually, for debugging purposes. It contains machine-readable numeric error codes, as well as verbose text descriptions of the errors which can be either observed by an operator performing interactive debugging, or communicated by an automated system to someone capable of interpreting them. It requires no special tools of the person attempting the debugging, as they can do so simply by telnetting to a well-known port. The commands are simple enough and memorable enough that a person of average intelligence can use them from memory, in the middle of the night, without enough coffee, and it contains a rudimentary interactive help system which allows an interactive user to determine what commands are available. If a device-management protocol were to be implemented in a manner similar to SMTP, a "no verbose" command should be included so that automated console implementations could minimize the volume of return traffic from the device. 4.3. Syntax: Templates, Lists, and Tokenization Operators need to be able to define templates, and apply those templates to lists or ranges of interfaces, or peers, or users, or whatever. Operators need to be able to define default configurations for new resources before they become available or before they're created. That is, an operator needs to be able to define the default settings (DNS servers, for instance) for any DHCP pool, and have those defaults applied to any new pool which is created on a managed device, or to any new pool which is created within a specific address range on a managed device, or to any new pool which is created by a specific user of a managed device. Similarly, an operator needs to be able to define default settings (ESF, B8ZS, frame relay encapsulation, for instance) for new serial interfaces which may be subsequently inserted into the chassis, or subsequently defined within a channelized resource. When making automatically-applied templates, one needs to be able to create pools of resources to be drawn from by the template. For example, just as DHCP users are temporarily assigned IP addresses from a pool, numbered interfaces need to be able to semi-permanently draw IP addresses from a pool and configure themselves according to rules within the template. 5. Authentication & Permissions Any management system which results from this work needs to include provision for multiple permissions-levels of authenticated access, each with read and write access to different resources within the managed device or system. For instance, some users should have only read access, and only to specific portions of a device. Other users would have the authority to create new instances by applying a predefined template (turning up new BGP peers using a peer-group). More advanced users would have permission to apply a template but also make specific individual-line overrides to the predefined configuration of the template. Superusers would have the ability to define new templates and destroy old ones. It must be possible to limit interaction with these features to a safe minimum. Operators must not be required to spend more time configuring authentication and permissions than building operational configuration on a device replacement in the field. 6. Security New management interfaces or services should not introduce "convenience" at the expense of either reduced security or dramatically higher overhead for interaction with the device. Changes to interface capabilities should always be carefully examined for their security implications and should not be assumed benign unless otherwise proven; internet infrastructure operates in at best a suspect and at worst a relentlessly hostile environment. We note the recent instructive example of a security compromise for unauthorized configuration changes to devices with "convenient" web interfaces. 7. Traps and Logging n. Open Issues n+1. Security Considerations Device configurations are attractive targets to anyone who wishes to deny or subvert Internet services. This document recognizes this threat, and attempts to both document the limitations of both current management techniques and those which will be required in the future, as well as attempt to set a higher standard for support of secure management techniques in future devices. Of principle concern are the observation by third parties of unencrypted configuration or authentication data as it is being transferred in-band across the network; the strength of encryption employed when storing or transmitting passwords; restricting access to device resources on a per-user and per-command basis; and the security of "password recovery" or factory-default-restoration procedures. All of these are preexisting problem areas which this document attempts to either make explicit or solve. n+2. References (Pointers to minutes from previous two meetings to be inserted here.) n+3. Authors' Addresses Suzanne Woolf Metromedia Fiber Network 50 West San Fernando Street, Suite 1010 San Jose, California 95113-2414 USA Phone: +1 EMail: woolf@mfnx.net Bill Woodcock Packet Clearing House 2355 Virginia Street Berkeley, California 94709-1315 USA Phone: +1 415 831 3100 Email: woody@pch.net