Re: draft-jones-opsec-04 comments

[George Jones <gmj@pobox.com>]

On Fri, 19 Mar 2004 Black_David@emc.com wrote:

> George,
>
> At the request of one of the Transport ADs (Allison Mankin),
> I've taken a look at the latest draft version:
>
> http://www.port111.com/opsec/draft-jones-opsec-04.txt
>
> I've looked at earlier versions of this draft, and I like it,
> I think it's important and I think that it's "digging in the
> right place".  I have a few specific comments (please cc: me
> explicitly on responses, as I'm not on the opsec@ops.ietf.org
> list):

Will do.   Please CC the list so everyone can see...I'll approve the
bounces.

> (1) General concern about RS-232.  An unfortunately common
> practice is to connect RS-232 ports to terminal servers that
> permit networked access for convenience.  This increases the
> potential security exposure of mechanisms available only via
> RS-232 ports.  A specific example can be found in my comment
> on Section 2.12.15 below, but it would be a good idea to check
> all mentions of RS-232 for implicit "port is not connected to
> the network" assumptions and make them explicit.

This is true and is a risk, but is for the most part beyond the
scope.  This doc focuses on the capabilities needed in individual
network elements.  Operational practices, physical security
and the security of management networks is assumed.

See if this, added to

  04> 2.3.1 Support a 'Console' Interface

helps:

04>   Warnings.
04>
04>      It is common practice is to connect RS-232 ports to terminal
04>      servers that permit networked access for convenience.  This
04>      increases the potential security exposure of mechanisms
04>      available only via RS232 ports.  For example, a password
04>      recovery mechanism that is available only via RS232 might give a
04>      remote hacker to completely reconfigure a router.  While
04>      operational procedures are beyond the scope of this document, it
04>      is important to note here that strong attention should be give
04>      to policies, procedures, access mechanisms and physical security
04>      governing access to console ports.

>
> (2) In Section 2.5.1 (Ability to Identify All Listening Services),
> the Requirement should include the ability to display the ports
> that the services are listening at in addition to the addresses
> to cover the case of a service listening at a port other than
> the obvious well-known default for that service.

Wow.  How did that slip through ?   Added:

04> Display any and all port(s) on which the service is listing.

Thanks.

>
> (3) The Requirement in Section 2.5.4 (Ability to Control Service
> Source Address) says "to specify the source address used for all
> outbound connections".  Please allow for the plural (e.g., "source
> address or addresses") to cover protocols such as SCTP that can use
> more than one IP address as the endpoint of a single connection.
> Similarly the section title should probably say "Address(es)"
> rather than "Address".  This is a nit, but an important one.

Better ?

04> 2.5.4 Ability to Control Service Source Addresses
04>
04>    Requirement.
04>
04>       The device MUST provide a means that allows the user to specify
04>       the source addresses used for all outbound connections or
04>       transmissions originating from the device.  It SHOULD be
04>       possible to specify source addresseses independently for each
04>       type of outbound connection or transmission.  Source addresseses
04>       MUST be limited to addresses that are assigned to interfaces
04>       (including loopbacks) local to the device.
04>
...
04>    Warnings.
04>
04>       Note that some protocols, such as SCTP [20], can use more than
04>       one IP address as the endpoint of a single connection.


>
> (4) In Section 2.8.1 (Ability to Filter on Protocols), please clarify
> the Requirement to make it clear that this is about the value of the
> protocol field in the IP header and not some higher level notion
> of protocol.

04> The device MUST provide a means to filter traffic based on the value
04> of the protocol field in the IP header.

>
> (5) The following Example in Section 2.12.15 (Support Recovery Of
> Privileged Access) is slippery:
>
>       *  The user sends a special sequence to the RS232 console port
>          during the initial boot sequence.
>
> If the RS232 port is connected to a networked terminal server and
> the device supports a remote boot mechanism of some form (e.g.,
> remote interruption of power on the protected side of the UPS), this
> need not require physical access to the device.  The example should
> be restricted so that physical access to the device is required.

Cited previous warning:

04> 2.12.15 Support Recovery Of Privileged Access
04>
04> Warnings
04>
04>       Also see the warnings in Section 2.3.1 (Support a 'Console'
04>       Interface).


> (6) Section 3.1 (Identify Services That May Be Listening) discusses
> default ports for services.  The language should be tweaked to include
> services that are configured listen at ports other than the well-known-
> default port for that service (e.g., web server is listening at 8080
> instead of 80 or possibly in addition to some other web server that
> is listening at 80).

How's this:

04>      Web servers "usually" listen on port 80. In the default
04>      configuration of the device, it may have a web server listening
04>      on port 8080. In the context of this requirement "identify ...
04>      default port" would mean "port 8080".


Thanks,
----George Jones