[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Definitions of "Console" and "CLI" expanded
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.
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.