Subject: Re: Question Inform Request

From: Randy Presuhn <[email-masked]>
Date: Mon, 29 Nov 1999 16:44:18 -0800 (PST)

Hi -

> To: Randy Presuhn <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: Question Inform Request
> References: <[email-masked]>
> From: Wes Hardaker <[email-masked]>
> Date: 29 Nov 1999 16:15:23 -0800
...
> Randy> I think nlmConfigLogFilterName from
> Randy> <draft-ietf-disman-notif-log-mib-12.txt> takes care of this
> Randy> scenario by permitting the creation of appropriately selective
> Randy> logs.
> 
> Yes, but you can't configure it to say "only log authenticated
> requests for this log" which means I can flood a CR with messages to
> over-write the history limit or over-run the processes memory...
> 
> Randy> The decision by the logging application to omit information
> Randy> delivered to that application is NOT an access control
> Randy> function.  Rather, it's part of the normal operation of such a
> Randy> logging application.
> 
> Ok, I understand you're view point.  I still disagree simply because I 
> think it would benefit from standardization, but I won't argue for it
> any longer (unless other people agree start to agree with me).
...

And I think I understand yours, and actually agree with (some of)
what you're advocating.  I think the difference is whether the
ability to limit what gets logged based on the sender's credentials
should be part of the SNMP application infrastructure or the logging
application itself.

I think the current documents tacitly assume that such a decision
would be application specific, and, if we wanted to be able to
protect the notification log from such an attack, we'd need to modify
<draft-ietf-disman-notif-log-mib-12.txt> to include the ability to
limit what gets logged based on senders' credentials.  The other way
of looking at the problem, the perspective I think you're taking, is
to approach this problem as being generic to all notification receiver
applications, and thus something to be handled in conjunction with the
other MIBs from RFC 2573.

The more standardized notification receiver applications we have, the
stronger the argument for using common infrastructure for this. However,
we also need to consider whether the policy (which (authenticated)
notification sources should actually be logged) belongs to the security
administrator or to the log applications' respective users.

 -------------------------N-E-W---A-D-D-R-E-S-S--------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

---

From: David Harrington <[email-masked]>
Date: Tue, 30 Nov 1999 08:56:43 -0500

I suggest the opportunity for another mib module that provides a place
to record filter conditions for notify-log. Maybe DISMAN WG will choose
to merge the two into one document, but it could also remain as two.

I suggest that such a filtering mib might constrain according to
credentials, or might explicitly list authorized notify senders. It also
maight take advantage of the expression mib for forming conditions.

dbh

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Tue, 30 Nov 1999 09:26:36 -0800

>to merge the two into one document, but it could also remain as two.

That's Yet-Another-Filtering-MIB :-(
I'd argue for a common infrastructure for filtering, instead of having applications each with their own filtering mechanisms.

Talking about filtering, someone implementing the Notification-Logmib rasied
the following issues to me:

User Foo has a named notification log called "Foolog", which contains
instances of notifications "A" and "B". After several notifications are logged,
Foo's notify view changes - now, notif "A" is still included, but notif "B"
is excluded. What should the log do? Should it:
1. leave the existing log entries as is, but log only notif A going forward?
2. remove old notification entries which were i the log but are now excluded
by the view?
3. leave the notif entries in the log, but filter each get PDU according to the
notify-view of the user/comm string used in the get query for the log?
4. set a discontinuity object (which is not in the notif-log MIB today), 
clear out the existing log, and log new entries?
5. In a discontinuityTable, set a discontinuity object, and the log entry from which the new view or filter entry took effect.

I'm not sure what the preferred/desired behaviour should be...
My preference is in the following order (best to worst):
5, 1, 4
However, I'm not sure if this issue came up in the past, or if
there are better ways to solve it.

Ram