Yes, I know netconf/xmlconf is in the works. Yes, I know RS232 is passe. But *operators* at NANOG and RIPE/EOF have pointed out that TODAY, if you want to get on a box and fix it *NOW*, the best *current* practices is a CLI and RS232 (when all else fails). So....
It is my considered opinion that netconf/xmlconf will not change this. They will provide an additional tool, but, they do not provide a replacement which provides a guaranteed way to talk to the box regardless of it's configuration. (It's easier to search the RS-232 baud rate space than the IP Address space, for example).
x.y.2 Support Management and Configuration via RS232 (EIA232)
Requirement. The device SHOULD support configuration and management via an RS232 serial connection.
Justification. RS232 interfaces are ubiquitous. They are well understood. They do not depend on correct configuration or functioning of network interfaces, IP stacks or operating systems. They do not require high bandwidth.
Examples. One example would be a serial console interface that provides the capability to load new/initial versions of the operating system and perform configuration via a command line interface.
Warnings. None.
x.y.3 Support A Simple Default RS232 Profile
Requirement. The device SHOULD support a simple default RS232 profile. The only required signals SHOULD be Transmit Data (TD), Receive Data (RD) and Signal Ground (SG). Other signals, should not be required (e.g. DCD, RTS, CTS, DSR, etc.). The default settings SHOULD be 9600bps, 8 bit data, no parity, one stop-bit (9600 8n1).
Jones, Editor Expires April 21, 2004 [Page 11]
Internet-Draft Operational Security Requirements October 2003
Justification. A simple, standard profile minimizes confusion and maximizes the chances of successful and well understood recovery practices. This profile follows the principals of "least surprise" and "Be liberal in what you accept and conservative in what you send."
Examples. None.
Warnings. None.
x.z Configuration and Management Interface Requirements
This section lists requirements that document current best practice in device configuration and management methods. In most cases, this currently involves some sort of command line interface (CLI) and configuration files. It may be possible in the future to meet the individual requiremnts via other mechanisms, specifically via mechanisms currently (October 2003) being defined by the IETF netconf working group [netconf].
x.z.1 CLI Provides Access to All Configuration and Management Functions
Requirement. The Command Line Interface (CLI) or equivalent MUST allow complete access to all configuration and management functions.
Justification. Restricted or incomplete access to configuration or management functions may make it impossible to perform necessary tasks.
Examples. Examples of configuration include setting interface addresses, defining and applying filters, configuring logging and authentication, etc. Examples of management functions include displaying dynamic state information such as CPU load, memory utilization, packet processing statistics, etc.
Warnings. None.
x.z.2 CLI Uses Existing Authentication Mechanisms
Requirement. The CLI or equivalent MUST utilize existing authentication methods.
Justification. The use of existing authentication methods keeps the implemenation simple and avoids needless complexity.
Jones, Editor Expires April 21, 2004 [Page 12]
Internet-Draft Operational Security Requirements October 2003
Examples. If a CLI funciton requires authentication functions and a remote AAA (TACACS+, RADIUS, etc.) server is in use, then the CLI should be able to use that server of authenticaiton.
Warnings. None.
x.z.3 CLI Supports Scripting of Configuration
Requirement. The CLI or equivalent MUST support external scripting of configuration functions. The scripting capability MUST NOT require the use of a particular scripting language.
Justification. Scripting is necessary when the number of managed devices is large and/or when changes must be implemented quickly. The ability to script configuration functions provides operators with the ability to implement solutions to problems not foreseen or addressed by the vendor.
Examples. Example uses of scripting include: tracking an attack across a large network, updating authentication parameters, updating logging parameters, updating filters, configuration fetching/auditing etc. Some languages that are currently used for scripting include expect, Perl and TCL. Some properties of the command lanuage that inhance the ability to script are: simplicity, regularity and consistency.
Warnings. None.
x.z.4 CLI Supports Management Over 'Slow' Links
Requirement. The device MUST support a command line interface (CLI) or equivalent mechanism that works over low bandwidth connections
Justification. There are situations where high bandwidth for management is not available, for example when in-band connections are overloaded during an attack or when low-bandwidth, out-of-band connections such as modems must be used... and it is often under these conditions that it is most crucial to be able to perform management and configuration functions.
Examples. The network is down. The network engineer just disabled routing by mistake on the sole gateway router in a remote unmanned data center. The only access to the device is over a modem connected to a console port. The data center customers are starting to call the support line. The GUI management interface is redrawing the screen multiple times...slowly... at 9600 baud.
Jones, Editor Expires April 21, 2004 [Page 13]
Internet-Draft Operational Security Requirements October 2003
Warnings. None.
Attachment:
pgp00000.pgp
Description: PGP signature