Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure

On Mon, Jan 26, 2004 at 06:49:45AM -0500, George M Jones wrote:
>> On Fri, 2004-01-23 at 12:43, David Meyer wrote:
>> 
>> > >> 
>> > >> An earlier draft had a requirement for saving complete configuration
>> > >> info,
>> > >> including "hidden" and default values (e.g. if finger is enabled in 
>> > >> one release, but disabled in subsequent releases, the config should show
>> > >> the settings even if they are set to the current default).   I was 
>> > >> told this was impractical so it was removed.
>> > 
>> > 	This turns out to be a major pain though, and it would be
>> > 	"nice" if it would be possible.
>> 
>> Seems like a reasonable candidate for reinstatement as a SHOULD.   If
>> there are business issues (support nightmare ?) or technical reasons it
>> can't be done, that will leave wiggle-room while.  It's on the to-do
>> list, pending IESG feedback/action.

	Fine.

>> > >> > 2.6.1 Support Rate Limiting
>> > >> > 
>> > >> > @@@ I would imagine one would want a mechanism along the lines 
>> > >> > @@@ of GTSM here, so that you could protect the limited resource
>> > >> > @@@ (whatever it may be) between the physical interface and the
>> > >> > @@@ processor performing the management function(s). i.e.,
>> > >> rate-limiting
>> > >> > @@@ may not be enough to stop an attacker who has deduced where
>> > >> > @@@ the resource limitation (potential DoS) exists.
>> > >> 
>> > >> The -00 draft included GTSM, but as it was not standardized, it was
>> > >> moved
>> > >> to the -info draft.  See
>> > 
>> > 	Will be RFC 3682 any day now.
>> 
>> 
>> Excellent.
>> 
>> I still think I'm not going to list it here.  Earlier drafts (dating
>> back to the pre-IETF versions) had a req that was essentialy RFC2644.
>> That was dropped after it became an IETF draft because other docs in
>> the same space covered it.   Same thing will go for GTSM.

	Ok.

>> > >> > 2.9.1 Ability to Accurately Count Filter Hits
>> > >> > 
>> > >> > @@@ s/Accurately// 
>> > >> > @@@ i.e., as opposed to inaccurately count, I suppose
>> > >> 
>> > >> Yes.  The adverb was placed there deliberately as a result of
>> > >> experience using filter counters that were not accurate.
>> > 
>> > 	But isn't this like saying: No bugs in clocks?
>> > 
>> > >> > 2.9.6 Filter Counters Must Be Accurate
>> > >> > 
>> > >> > @@@ Again, as opposed to "inaccurate" filter counts?
>> > >> 
>> > >> Yes.
>> > 
>> > 	Again, who purposely builds inaccurate clocks for this
>> > 	application (maybe someone does)? Wouldn't it (the
>> > 	inaccurate counter) be a bug? i.e., isn't the requirement
>> > 	just saying no bugs in the filter counters?
>> 
>> 
>> 1 + 1 = 2.  But there are major products out there that get it
>> wrong (in the case of accurate filter counts).   This needs to be said.

	Ok.

>> > >> > @@@ also, it should be possible to log to a local device (say
>> > >> > @@@ the console)
>> > >> 
>> > >> This req had that sort of logging in view, as well as the possibility
>> > >> of logging to local disk Let me know if there is wording that could
>> > >> make it more clear
>> > >> 
>> > >> > without hanging the box.
>> > >> 
>> > >> What ?  You want boxes to not crash ?  Picky, picky :-)
>> > 
>> > 	well, you know...
>> 
>> Again, let me know if there is wording that you think would make this 
>> (need to log to the console) more explcit.
>> 
>> 
>> 
>> > >> > 2.11.7 Logs Must Be Timestamped
>> > >> > 
>> > >> >    Requirement. The device MUST time-stamp all log messages.  The
>> > >> >       time-stamp MUST be accurate to within a second or less.  The
>> > >> >       time-stamp MUST include a timezone.
>> > >> > 
>> > >> > @@@ and maybe it should be possible to turn timestamping off?
>> > >> 
>> > >> Why ?
>> > 
>> > 	Because I'm an operator and I have some (arbitrary)
>> > 	reason want to, and a vendor wants to give it to me. That
>> > 	shouldn't violate the BCP. In any event, that was my
>> > 	thinking. 
>> 
>> Better ?
>> 
>>   By default, the device MUST time-stamp all log messages.  The
>>   time-stamp MUST be accurate to within a second or less.  The
>>   time-stamp MUST include a timezone.   There MAY be a mechanism
>>   to disable the generation of timestamps.

	Sure.

	Thanks,

	Dave

_______________________________________________
routing-discussion mailing list
routing-discussion@ietf.org
https://www1.ietf.org/mailman/listinfo/routing-discussion