I'm finishing off loose ends/respond to outstanding comments
One is trying to reconcile the "RS232 is old as dirt and just works" style console with the reality that it's *starting* to go away, and a ethernet based interface, possibly supporting its own IP stack and HTTP/HTML interface could meet the console requirements.
I think the fact that certain manufacturers are starting to let this slip away is a *BAD* thing. Personally, I would rather NOT reconcile with this, as I don't believe it provides a reliable solution.
The total cost to putting a serial port in a box these days is usually under $20. Even ZyXEL in their "toaster" products has a serial port on most of them (all of the more recent models). If you have a CLI, there's really little or no additional software required for serial.
As to full-featured HTML as an option to replace CLI, it's not. The need for a full-featured CLI is not only to deal with Serial, but, also to make it possible to make global management of lots of devices scriptable without having to depend on the manufacturers central management system.
Frankly, of what is below, I'm not sure what 2.3.3 means, 2.3.4 seems on the surface to be a good thing, and I agree with 2.4.5. The rest, in my opinion, are a road paved with good intentions.
Attempted reconciliation below.
- Definition of "console" broadened. - 2.3.2 Support A Simple Default Communication Profile On The 'Console' broadened - 2.3.3 'Console' requires minimal functionality of attached devices. added - 2.3.4 'Console' Supports Fall-back Authentication added - 2.4 Configuration and Management Interface Requirements definition of "CLI" broadened to include full function HTML as long as it meets the other 2.4 reqs - 2.4.5 CLI Supports Idle Session Timeout (per Don Smith)
Feedback/synthesis sanity check requested.
---George Jones
------------------------------------------------------------------ 2.3 Out-of-Band (OoB) Management Requirements
See Section 2.2 for a discussion of the advantages and disadvantages of In-band vs. Out-of-Band management.
2.3.1 Support a 'Console' interface
Requirement. The device MUST support complete configuration and management via a 'console' interface that functions independently from the forwarding and control planes.
Justification. There are times when the device *must* be managed or configured, even when the network is unavailable, routing and network interfaces are incorrectly configured, the IP stack and/or operating system may not be working (or may be vulnerable to recently discovered exploits that make their use impossible/ inadvisable), or when high bandwidth paths to the device are unavailable. In such situations, a console interface can provide a way to manage and configure the device.
Examples.
* One example would be an RS232 (EIA232) interface that provides the capability to load new versions of the system software and to perform configuration via a command line interface. RS232 interfaces are ubiquitous and well understood.
* Another example might be a simple embedded device that provides HTTP+HTML management and configuration access via an Ethernet interface independent of functioning of the forwarding and
Jones, Editor Expires May 25, 2004 [Page 10]
Internet-Draft Operational Security Requirements November 2003
control planes.
Warnings. The console interface is valuable insofar as it is simple and available when other management mechanisms are not. The simplicity and availability can be reduced by dependencies on the functioning of other portions of the device (control+management plane), the need for complex/non-standard communication parameters, the need for complex/non-standard physical cabling, or the need for non-standard/proprietary clients.
2.3.2 Support A Simple Default Communication Profile On The 'Console'
Requirement. The device MUST support a simple default profile of communications parameters on the 'console'. These communications parameters MUST be published in the system documentation. While it MAY be possible to change the communication profile, if this is possible then there MUST be a method defined and published for returning to the default configuration.
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.
The following is a profile widely used for RS232 console connections: the only required signals SHOULD be Transmit Data (TD), Receive Data (RD) and Signal Ground (SG). Other signals, SHOULD NOT be required (e.g. RTS, CTS, DSR, etc.). Data Carrier Detect (DCD) SHOULD NOT be required to create a session, but existing sessions should terminate on HIGH to LOW or HIGH to FLOAT transitions to prevent unauthorized users from gaining access to existing sessions. The default settings SHOULD be 9600bps, 8 bit data, no parity, one stop-bit (9600 8n1). Sending a break would be one way to signal that the communications parameters should be reset.
In the case of a dedicated IP-based Ethernet 'console', the default IP address, netmask and broadcast addresses must be known as well as port numbers for HTTP servers, etc. Possible defaults might be 192.168.1.1/30, and port 443 for an HTTPS server. A physical toggle switch on the device might provide a way of resetting the default parameters.
Jones, Editor Expires May 25, 2004 [Page 11]
Internet-Draft Operational Security Requirements November 2003
Warnings. The default RS232 profile described above does not support hardware flow control.
2.3.3 'Console' requires minimal functionality of attached devices.
Requirement. The 'console' interface MUST place minimal requirements on attached devices. It MUST support attached devices that have minimal, standard functionality. The 'console' MUST NOT require proprietary devices, protocol extensions or specific client software.
Justification. The purpose of having the console interface is to have a management interface that 'just works' at all times. Requiring complex or nonstandard behavior on the part of attached devices reduces the likelihood that the console will 'just work'.
Examples.
* If the console is supplied via an RS232 interface, then it should function with an attached device that only implements a "dumb" terminal. Support of "advanced" terminal features/types should be optional.
* If the console is implemented via HTTP/HTML, then it should be possible to use browsers (or scripts) that implement a minimal subset of standard HTTP/HTML...in current terms this might mean supporting text-only browsers.
Warnings. None.
2.3.4 'Console' Supports Fall-back Authentication
Requirement. The 'console' SHOULD support an authentication mechanism which does not require functional IP or depend on external services. This authentication mechanism MAY be disabled until a failure of other preferred mechanisms is detected. In the event of fall-back AUTHENTICATION, the interface MUST either implement a locally defined AUTHORIZATION profile or consider all commands to be AUTHORIZED. This mechanism SHOULD be implemented as a fall-back if the preferred authentication method is not "LOCAL".
Justification. It does little good to have a console interface on a device if you cannot get into the device with it when the network is not working.
Jones, Editor Expires May 25, 2004 [Page 12]
Internet-Draft Operational Security Requirements November 2003
Examples. Some devices which use TACACS or RADIUS for authentication will fall back to a local account if the TACACS or RADIUS server does not reply to an authentication request.
Warnings. This requirement represents a trade-off between being able to manage the device (functionality) and security. There are many ways to implement this which would provide reduced security for the device, e.g. a back door for unauthorized access. Local policy should be consulted to determine if "fail open" or "fail closed" is the correct stance. The implications of "fail closed" (e.g. not being able to manage a device) should be fully considered.
. . . 2.4 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 to meet these requirements with other mechanisms, for instance a script-able HTML interface that provides full access to management and configuration functions. In the future, there may be others (e.g. XML based configuration).
2.4.1 CLI Provides Access to All Configuration and Management Functions 2.4.2 CLI Uses Existing Authentication Mechanisms 2.4.3 CLI Supports Scripting of Configuration 2.4.4 CLI Supports Management Over 'Slow' Links 2.4.5 CLI Supports Idle Session Timeout
Requirement. The command line interface (CLI) or equivalent mechanism MUST support a configurable idle timeout value.
Justification. Network administrators go to lunch. They leave themselves logged in with administrative privileges. They forget to use screen-savers with password protection. They do this while at conferences and in other public places. This behavior presents opportunity for unauthorized access. Idle timeouts reduce the window of exposure.
Examples. The CLI may provide a configuration command that allows an idle timeout to be set. If the operator does not enter commands for that amount of time, the login session will be automatically terminated.
Warnings. None.
-- If it wasn't crypto-signed, it probably didn't come from me.
Attachment:
pgp00003.pgp
Description: PGP signature