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

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.

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

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

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

Thanks,
---George Jones

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