[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-jones-opsec-04 comments



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):

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

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

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

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

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

(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).

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------