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

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



On Wed, 25 Feb 2004, George Jones wrote:
> 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 ?

Yep [snipped].
 
> 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.

Agreed, of course :)

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

OK, but be sure that the Warnings section then has a caveat about that 
MAY -- if the failure detection fails (murphy's law.. :), you wouldn't 
want to be stuck with no mechanism at all :)
 
> 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 ?

Hmm. "The configuration MAY be compressed using a compression 
algorithm which is openly available, as long as the fact is clearly 
identified, and the compression can be disabled." ?
 
> 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 ?

I'm trying to figure out what my point was.  Oh yes, I believe it was 
that currently, I'm not aware of implementations providing this kind 
of binding feature.  The fact is achieved using access lists, which 
are created by the user ("ip receive acl" in IOS or "loopback acl" in 
JunOS).  I think one should be clearer whether such user-created 
mechanisms are sufficient in this context, or do you require 
additional mechanisms?
 
> 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.

Ok.  For now, I guess this issue could be sneaked in by adding a
Warning, like, "Warnings.  Filtering Interior Gateway Protocols (e.g.,
OSPF or IS-IS) could be dangerous, and as these should only be used
inside a domain, this is less of a problem."

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings