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

[George Jones <gmj@pobox.com>]

On Thu, 26 Feb 2004, Pekka Savola wrote:

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

OK. Added to req for storing remote configs.

This whole req has been rewoked a bit (Don, see if you like
this better).

04> 2.4.8 Support Text Configuration Files
04>
04>    Requirement. The device MUST support display, backup and restore of
04>       system configuration in a simple well defined textual
04>       format. The configuration MUST also be viewable as text on the
04>       device itself.  It MUST NOT be necessary to use a proprietary
04>       program to view the configuration.
04>
04>    Justification. Simple,  well-defined textual configurations
04>       facilitate human understanding of the operational state of the
04>       device, enable off-line audits, and facilitate automation.
04>       Requiring the use of a proprietary program to access the
04>       configuration inhibits these goals.
04>
04>    Examples. A 7-bit ASCII configuration file that shows the current
04>       settings of the various configuration options wold satisfy the
04>       requirement, as would a Unicode configuration or any other
04>       "textual" representation. A structured binary format intended
04>       only
04>       for consumption by programs would not be acceptable.
04>
04>    Warnings.
04>
04>       Offline copies of configurations should be well protected as
04>       they often contain sensitive information such as SNMP community
04>       strings, passwords, network blocks, customer information, etc.
04>
04>       "Well defined" and "textual" are open to interpretation. Clearly
04>       an ASCII configuration file with a regular, documented command
04>       oriented-syntax would meet the definition.  These are currently
04>       in wide use.  Future options, such as XML based configuration
04>       may meet the requirement.  Determining this will require
04>       evaluation against the justifications listed above.

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

I thought that IOS's "ip [logging|tacacs|telnet...] source-interface ..."
provided this granularity of control, at least for some services.

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

Added the following to "examples".

04>      Similar effects may be achieved with the use of global filters,
04>      sometimes called "receive" or "loopback" ACLs, that filter
04>      traffic destined for the device itself on all interfaces.

>
> > ps> 2.7.5 Support Route Filtering

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

The current working is:

04> 2.7.5 Support Route Filtering
04>
04>    Requirement. The device MUST provide a means to filter routing
04>       updates for all protocols to be used to exchange external
04>       routing information.
04>
04>    Justification. See [RFC3013] and section 3.2 of [RFC2196].
04>
04>    Examples. Operators may wish to ignore advertisements for routes to
04>       addresses allocated for private internets. See eBGP.
04>
04>    Warnings. None.

Let me know if you think some language about interior/external gateway
protocols would help (& possible refs).

Thanks,
----George