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

Re: snmpconf-pm-04 notes

Wes Hardaker wrote:
> Following up on the discussion related issues:
> >  "Policies always express a notion of:
> >     if (an object has certain characteristics) then (apply an operation(s) to
> >     an object)"                                            ^^
> >     ^^
> Steve> What if it said: "Policies are intended to express a notion
> Steve> of:" and then we could use the original pseudo-code, which is
> Steve> designed to show the intent of the policy-based management
> Steve> model rather than the limits of what a *could* be done.
> What I didn't like about the original statement is that it implied to
> me that operations always applied to the objects that triggered them,
> which is hardly the case (if anything, its probably counter to how
> they'd typically be used.  The operation is more likely to apply to a
> near by object to the one that triggered the action).  Anyway, you can
> do what you want of course.  The notion of applying multiple actions
> is less important (IMHO) than the notion of applying the action to a
> possibly different object.

Your statement surprises me but I'm wondering if it's because I've
created another terminology problem. I happen to not mean object in the
SNMP sense (i.e. a variable, sort of) but in an object-oriented sense.
What I should really say is element (I wrote this text before I siezed
on element as the term - "thingie" was in the running for a while too

This should really be re-written to:
    "Policies are intended to express a notion of:
        if (an element has certain characteristics) then (apply an
operation to that element)"

After fixing my notational blunder, would you agree that an operation is
more likely to apply to the same element? Second most likely to a
related element? And unrelated elements are also possible but don't
really draw as many strengths from the architecture.

> >> 5) section 4:
> >> There are security issues with not uploading policies to a managed
> >> object until they are discovered.  This issue comes up repeatedly in
> >> the document.  During the time that the policy is not in place it
> >> obviously can't be enforced (which could be serious if financial or
> >> highly secure information was transmitted (EG) during that time
> >> window).  In theory, you'd think, that this shouldn't happen that
> >> often and the window would be small.  But what if the
> >> pmNewRoleNotification isn't received by the management station?
> Steve> I agree. I'll make some mention of this as appropriate (at least in the
> Steve> security section). How's this text?:
> Steve> -- Note that using this algorithm to avoid installing "unnecessary"
> Steve> -- policies may result in delays in having the policy available when
> Steve> -- the policy becomes necessary. This delay could become extensive if
> Steve> -- an interruption of communications prevents the notification from
> Steve> -- being delivered and/or the policy from being downloaded, causing
> Steve> -- the sytem to not be in compliance with policy for a period of
> Steve> -- time. In particular, if the policy is enforcing security rules,
> Steve> -- this could open up security vulnerabilities during this period of
> Steve> -- time.
> That looks good.  2 comments:
> 1) please don't put it in the MIB as a comment (see issues discussed
>    in my second mail message with respect to putting functionality
>    related discussions in MIB comments)
> 2) download -> installed    ;-)

Sigh. It seems it will take some time to purge that from my vocabulary.

> > ***
> > 9) 5.3 and others
> >    If syntax or processing errors occur, the action will terminate
> >    immediately for this element.  I think failures need to be dealt
> >    with in a better way.  The document repeatedly references failing
> >    actions and that processing stops.
> >
> >    First and most importantly, I think a failure notification needs to
> >    be sent out (if configured to do so), as there are security
> >    implications with policies that fail to run properly.
> Steve> For each policy, there's a rollup of the total number of
> Steve> instances of the policy that are failing now (a gauge,
> Steve> pmPolicyAbnormalTerminations).  Also, when I send an updated
> Steve> draft next week, check out pmTrackingPolicyToElementInfo which
> Steve> contains info about errors and exceptions on a
> Steve> per-execution-context basis (i.e. per policy/element pair). Of
> Steve> course, there's also the debugging table.
> Steve> So we've made it easy to poll but haven't achieved sub-second
> Steve> notification (only possible with a notification). And it's here
> Steve> that I'm a bit reluctant to say that a notification is a
> Steve> requirement. To be honest, I really don't have a sense of this
> Steve> yet. One more notification isn't that big a deal but I'm most
> Steve> worried about getting into ratholes about how we can make sure
> Steve> that floods of notifications don't occur.
> Steve> All we would absolutely need would be to have a notification
> Steve> that is sent whenever the abnormalTerminations gauge goes from
> Steve> zero to non-zero and no more than 1 notification per 60 seconds
> Steve> (or some similar non-configurable constant). If we could keep
> Steve> it simple like this it might be worth it.
> IMHO, it is a serious security issue not to enable a way for failed
> actions to be run incorrectly and not have a way to inform an
> administrator of this immediately.  You're right that the counter
> objects exist, but (IMHO) thats not enough.  I don't want to have to
> rely on a management station monitoring 50,000 boxes to determine
> which ones are failing.  The chances of monitoring it frequently
> enough to ensure that my policies are being implemented properly
> everywhere is slim.  HP-OV, the last time I ran it, defaulted to
> polling objects only every 30 or 60 minutes (and I couldn't decrease
> it from that because the polling was taking 20 minutes in the first
> place (granted it was a slow box)).  I'd much rather have a trap sent
> warning me of such a serious problem.
> The other possibility is to configure backup actions to be used when a
> primary action fails.  This is what many other policy related
> architectures are trying to do (specifically, the one I'm most
> familiar with is the ipsec-policy WG and they're providing a list of
> backup actions to take).  In theory, then, you could implement a
> backup action that sent a trap.  Though I think making a specific
> notification to handle failures is a better way to go.

Understood. Still thinking. And eager to hear others viewpoints.