RE: More BCP: revenge of RS232 and CLIs

[George Jones <gmj@pobox.com>]

On Sun, 26 Oct 2003, Owen DeLong wrote:

> I'd agree with that, although, I'm not sure how much of a mistake
> it was to list RS-232 specifically.  I agree the generalization is
> probably better, but, the example should still probably specify that
> this is the most prevalant and compatible mechanism available at the
> time of writing.

It's a mistake in the sense that it was the *only* requirement
in the whole document to list a speific requirement.

The requirement should basicly be "a console port that always works,
with well-understood default communications parameters and that
provides full access to all managment and configuration functions".

I've attempted to capture that in following (in the submitted -02):

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 Non-IP 'Console' interface

   Requirement. The device MUST support complete configuration and
      management via a non-IP interface.

   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, non-IP interfaces 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.

   Warnings. None.


2.3.2 Support A Simple Default Communication Profile On The 'Console'





Jones, Editor            Expires April 26, 2004                [Page 10]

Internet-Draft     Operational Security Requirements        October 2003


   Requirement. The device MUST support a simple default profile of
      communications parameters on the Non-IP management interface.
      These communications parameters MUST be published in the system
      documentation. There SHOULD 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. DCD, RTS, CTS, DSR, etc.).  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.

   Warnings. The default RS232 profile described above does not support
      hardware flow control.
.
.
.

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 in the future to meet the



Jones, Editor            Expires April 26, 2004                [Page 12]

Internet-Draft     Operational Security Requirements        October 2003


   individual requirements via other mechanisms, specifically via
   mechanisms currently (October 2003) being defined by the IETF netconf
   working group [netconf].

2.4.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.


2.4.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
      implementation simple and avoids needless complexity.

   Examples. If a CLI function 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 authentication.

   Warnings. None.


2.4.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



Jones, Editor            Expires April 26, 2004                [Page 13]

Internet-Draft     Operational Security Requirements        October 2003


      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 language that enhance the ability to script are:
      simplicity, regularity and consistency.

   Warnings. None.


2.4.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 9600bps.

   Warnings. One consequence of this requirement may be that requiring a
      GUI interface for management is unacceptable unless it can be show
      to work acceptably over slow links.