RE: Reply to reveiw comments from Pekka Savola (2 of ?)

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

djs> marks my short comments:-)

-----Original Message-----
From: owner-opsec@psg.com
To: opsec@ops.ietf.org
Sent: 2/25/2004 6:43 PM
Subject: Reply to reveiw comments from Pekka Savola (2 of ?)

...continued

ps> 2.3.1 Support a 'Console' interface
ps>
ps>   Requirement. The device MUST support complete configuration and
ps>       management via a 'console' interface that functions
ps>       independently
ps>       from the forwarding and control planes.
ps>
ps> ==> "independently from control planes".  You must probably clarify
to
ps> make it clearer what you mean by "control plane".  I guess "IP
control
ps> plane" or whatever?

Yes.  Changed.

ps> I mean, if the CPU of the system is hosed or at
ps> 100%, or all the memory has been exhausted due to a memory leak,
ps> even console interface doesn't help.

True.  This was in intended to go with 2.3.8.

ps>
ps>
ps> 2.3.2 'Console' Has A Simple Default Communication Profile
ps>
ps>   Requirement. The device MUST support a simple default profile of
ps>       communications parameters on the 'console'.
ps> [...]
ps>   Examples.
ps>
ps>         The following is a profile widely used for RS232 console
ps>         connections:
ps>
ps> ==> At front you say "MUST ... default profile".  What do you mean?
ps> That the consoles of the same type must have the same parameters
ps> (physical or otherwise)?  I don't think the language about RS232 in
ps> the examples is strict enough to create good
ps> interoperability/standard.
ps>
ps> FWIW, we have 3 kinds of 9 pin (not to mention 25 or RJ11 or RJ45..)
ps> console cables in our machine room, so choosing one is pretty
ps> important.  Not sure, however, whether coming to a consensus might
ps> be more difficult.

OK.  You're right.  "simple" is to subjective and mandating the bygone
dependability or 25pin RS232, 2+3 live, 9600,8,n,1 is beyond the
scope.   This one will go.  3.5, requiring console settings to be
documented will stay.

ps>   Requirement. If it is possible to change the default console
ps>       communication profile, then there MUST be a method defined and
ps>       published for returning to the default configuration.
ps> ==> this seems like too obvious to be true.  If you can change the
ps> profile, you obviously can change it back :-).  I assume you mean
ps> something like, "must be able to reset the console configuration
ps> without console access" or something -- if so, say it!

Better ?

djs> this is intended to be as simple as push in this button
djs> and power cycle. If it requires sending out a tech it 
djs> could take longer to recover. Should (must?) it require physical djs> access to change the console setting? I am thinking about changing
djs> the baud rate via a key sequence.


04>   Requirement. There MUST be a method defined and published for
04>      returning the console communication parameters to their default
04>      settings.   This method must not require the current settings
to
04>      be known.
04>
04>   Justification. Having to guess at communications settings can
waste
04>      time. In a crisis situation, the operator may need to get on
the
04>      console of a device quickly.
04>
04>   Examples.
04>
04>      One method might be to send a break or a predefined character
04>      sequence on a serial line.

ps> ==> unless this mechanism is standardized (different key sequences
for
ps> 10 different vendors) I don't think this really helps that much
:-).

Having to remember, or have a cheat sheet 10 different sequences is a
far better problem to have than not having any way at all to reset
forgotten parameters.


djs> George maybe I am stating the odvious but although
djs> many systems implement break as a key sequence it 
djs> is an electronic singnal. 


ps>
ps> 2.3.5 'Console' Supports Fall-back Authentication
ps>
ps>   Requirement. The 'console' SHOULD support an authentication
ps>   mechanism
ps>       which does not require functional IP or depend on external
ps>       services.  This authentication mechanism MAY be disabled until
a
ps>       failure of other preferred mechanisms is detected.  In the
event
ps>       of fall-back AUTHENTICATION, the interface SHOULD either im
ps>   a locally defined AUTHORIZATION profile or consider all commands
ps>       to be AUTHORIZED. This mechanism SHOULD be implemented as a
ps>       fall-back if the preferred authentication method is not
"LOCAL".
ps>
ps> ==> there seem to be multiple requirements here?  Does it make sense
ps> to include these in one requirement?

Right again.  The basic thing this is trying to say is "support
fallback authenticadtion when IP dosn't work".  This was just to busy.
I've shortened the req to its core:

04> 2.3.4 'Console' Supports Fall-back Authentication
04>
04>    Requirement. The 'console' SHOULD support an authentication
04>    mechanism which does not require functional IP or depend on
04>    external services.  This authentication mechanism MAY be disabled
04>    until a failure of other preferred mechanisms is detected.

ps> 2.3.8 Provide Separate Resources For The Management Plane
ps>
ps>   Requirement. If the device implements separate network
interface(s)
ps>
ps>       for the management plane per Section 2.3.6 then the device
ps>       SHOULD
ps>       provide separate resources and use separate software for
ps>       different
ps>       classes of interface.
ps>
ps> ==> I don't think anybody implements something like this and this
ps> should be
ps> removed.  I can't say this is B_C_P.

This one survived (until now) from the earliest, non-BCP incarnations
of the document.   Gone.

ps>
ps> 2.4.8 Support Text Configuration Files
ps>
ps>   Requirement. The device MUST provide a means to remotely save a
copy
ps>       of the system configuration file(s) in a textual format.  It
ps>       MUST
ps>       NOT be necessary to use a proprietary program to view the
ps>       configuration. The configuration MUST also be viewable as text
ps>       on
ps>       the device itself. Sensitive information such as passwords
that
ps>       could be used to compromise the security of the device MAY be
ps>       excluded from the saved configuration.
ps>
ps> ==> is text compression using e.g. gzip or bzip2 allowed, though?

Hmm.  Remotely savable.  No propritary format.   I'd say yes, but I
can't think of a good way to reword this.  Thoughts ?

djs>  Requirement. The device MUST provide a means to 
djs> remotely save a copy of the system configuration 
djs> file(s) in a "well defined" format.  
djs> It MUST NOT be necessary to use a proprietary program 
djs> to view the configuration. 

UNCHANGED
djs>The configuration MUST also be viewable as text
djs>on the device itself. Sensitive information such 
djs> as passwords that could be used to compromise the 
djs>security of the device MAY be excluded from the saved configuration.







ps> 2.5.4 Ability to Control Service Bindings for Listening Services
ps>
ps>   Requirement. The device MUST provide a means for the user to
specify
ps>       the bindings used for all listening services.  It MUST support
ps>       binding to a list of addresses and netblocks.  It MUST also
ps>       support configuration of binding services to any interface
local
ps>       to the device, physical or non-physical (e.g. "loopbacks").
ps>
ps> ==> it should be clearer what's in scope for this.  Is e.g. the his
ps> like:
ps>
ps>   Examples. Another way of stating the requirement is that filter
ps>       performance should not be the limiting factor in device
ps>       throughput.  If a device is capable of forwarding 1000Mb/sec
of
ps>       packets of any size without filtering, then it should be able
ps>       to forward the same amount with filtering in place.
ps>       This requirement, especially on higher throughput rates, most
ps>       likely implies a hardware-based solution (ASIC).

It thought this was pretty specific.

03>   Examples. If the device listens for inbound SSH connections, this
03>      requirement means that it should be possible to specify that
the
03>      device will only listen to connections destined to specific
03>      addresses (e.g. the address of the loopback interface) or
03>      received
03>      on certain interfaces (e.g. an ethernet interface designated as
03>      the "management" interface). It should be possible in this
03>      example
03>      to configure the device such that the SSH is NOT listening on
03>      every interface or to every address configured on the device.

no ?  Perhaps the longish justifcaiotn (result of discussinon on the
opsec list IIRC) before that confused the issue ?

ps> 2.7.5 Support Route Filtering
ps>
ps>   Requirement. The device MUST provide a means to filter routing
ps>       updates for all supported dynamic routing protocols.
ps>
ps>   Justification. See [RFC3013] and section 3.2 of [RFC2196].
ps>
ps>   Examples. Operators may wish to ignore advertisements for routes
to
ps>       addresses allocated for private Internets.
ps>
ps> ==> well, this just isn't done for many vendors and many protocols
ps> at the moment.  For example, inbound OSPF and IS-IS filtering is
ps> often not implemented.  Is this intentional?

I could be convinced do something like s/all...protocols/BGP/
or (better) s/protocols/protocols used to recieve routes from
external sources/ (wording ?)....but being able to filter
routes is pretty fundemntal for networks that are in scope.


djs> EBGP external border gateway protocol.

continued again...

George M. Jones    |  Most important ideas are uninteresting. Most
interesting
                   |  ideas are unimportant. Not every problem has a
good
                   |  solutions. Every solution have side effects.
                   |      Quoted from Dan Geer
gmj@pobox.com