RE: strict and loose uRPF. Sanity check please.

["Smith, Donald" <Donald.Smith@qwest.com>]

George and fellow opsec teammates. I have received a large set of
comments from a fellow qwest engineer.
Since he is not on the opsec list I am forwarding these on.

From the fingers of Steve Lennon:::::
Topics to consider including:
	1) There should be a requirement that the device under
management does not volunteer any useful information before
authentication occurs.  There are some network devices which,  for
example, that TELNETing to the management interface will  display device
type, firmware version, alarm status, local time,  and users currently
logged-in.  This type of information must  not be displayed without
authentication.
	2) There should not be a command, or capability, in the
 device under management which allows any user to view another  user's
local password in clear text.  There should only be a  method to change
a password, with sufficient privileges, but not.
	3) Devices under management should have the ability to
 include a configurable warning banner on both in and out of  band
management interfaces.  The length of these warning banners  should be
of sufficient length (eg. more then one line).

Section 2.3.5 Requirement:  Should the requirement first be that  the
Console supports authentication first, then it can later be  required to
support a backup method?
	The mention of "failing open" should have stronger warnings
against this.  If this is put forward in a Best Practices document  like
this one, it may be used as a excuse by equipment vendors.

Section 2.3.6 This section seems to start a new type of section  based
on OOR IP interfaces while 2.3.1-2.3.5 are concerned about  the serial
console ports.  IP management interfaces have much  different types of
requirements then serial ports so it might be  advantageous to create a
new sub-category.

Section 2.4  FYI, there are already DSL modems which use XML for  their
configuration.  The future is here.  :)

Section 2.4.5  Warnings:  Do you want to include a warning against
using a protocol like BOOTP?

Section 2.5.1  You could include a mention of section 3's  documentation
requirements here.

Section 2.5.7:  The counters are good, but do you want to include  any
references on how these counters can be viewed (eg. via the  console
CLI, by SNMP, etc.)?

Section 2.6.1 Warnings:  Might want to include a caveat about taking
care not to DOS your own network by rate limiting "legitimate"
traffic., or worse yet your own management interface traffic.

Section 2.6.3 Requirements:  Extra "on" in first line.

Section 2.7:  Since there are requirements in the CLI section for
simplicity in the implementation of the interface, it would be nice  to
include the same type of requirement for the implementation of  filters.
Some of them are rather inelegant.

Section 2.9.1 Examples 3rd sentence:  "IPS's Acceptable Use Policy"
  should be "ISP's Acceptable Use Policy".

Section 2.9.3:  Again having filter counters are good, but do you  want
to include any references on how these counters can be viewed  (eg. via
the console CLI, by SNMP, etc.)?

Section 2.11.4 - 2.11.6:  These are functional time related
requirements of the devices itself and while extremely important  to
logging, it is really a separate set of requirements that might  be
better in its own section.

Section 2.10.1 Justification 2nd sentence:  "wold be logged" should  be
"would be logged"

Section 2.10:  Like the configuration section it might be useful to
include the following requirements:
	1) Logs should be in textual format, not proprietary (though
this might be implied in 2.11.1).
	2) Logging should not cause performance issues
	3) Logging locally must no preclude the use of the device
 (eg.  turning Cisco's console logging on)

Section 2.12.4:  This requirement seems to preclude 2.3.5.

Section 2.12.6 Warnings:   Don't forget this implies the AAA method
 of transporting these authentication credentials across the network  is
secure.

Section 2.12.8  Isn't this implied in 2.1.1?

Section 2.12.17 Example:  Mention should be made of the logging
requirement 2.11.7 (timestamps) here.

Section 2.15:  Does this section make 2.7.4 redundant?

Appendix A, 2nd sentence:  "A profile is a list of list of" should  be
"A profile is a list of"


-- 
	steve lennon, CISSP, proto-CISA		slennon@qwest.com
	Staff Internet Security Engineer

	Qwest Communications, IP Security Enforcement