[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf pm issue #23 - policy termination
Right. Generally speaking I don't expect policy evaluation to be extremely
computationally expensive such that it is infeasible to force a premature
evaluation of a policy. I also don't expect policies to be toggling in and
out of effect at a high frequency, at least not policies that are in any
The security argument is a good one, but I think a more general argument is
that policy should put our network into a known state. By leaving a gap
between taking a policy out of service and putting the lower priority
policy in service, we have a time period where the network policy is
undefined. I don't think providers, especially telecom providers, will be
very happy with that arrangement.
--On Wednesday, June 06, 2001 8:34 PM -0700 Steve Waldbusser
> I totally agree with you guys that this is necessary. You can already
> see this behavior described somewhat, it's just not complete yet.
> The following text is in the defer() function:
> "When a policy defers it exits and the filter-matching policy with the
> next-highest precedence is immediately run."
> Similar text needs to be added to the policy table logic as well.
> This isn't expensive either. We're just changing the timing a bit. We're
> just re-evaluating the "previously trumped" policy filters immediately
> rather than waiting till the next policyFilterMaxLatency time.
> Wes Hardaker wrote:
>> >>>>> On Tue, 05 Jun 2001 11:40:26 -0400, David Harrington
>> >>>>> <email@example.com> said:
>> David> I am concerned that for policies which may affect the security
>> David> of the network, it may not be acceptable to wait until the next
>> David> regularly-scheduled policy evaluation; a more immediate
>> David> determination of the policy to apply may be necessary to ensure
>> David> the viability of the security environment.
>> David, thanks for writing up the exact point that I would have made.
>> It is a grave flaw to simply "wait" for the next update.
>> David> OTOH, I also recognize that forcing a complete evaluation cycle
>> David> to occur every time a policy becomes inactive may be
>> David> problematic. Is there any way with the existing language and
>> David> primitives to cause the evaluation to be done immediately when
>> David> selected policies become inactive?
>> Really you want to evaluate just the current element, which is what I
>> think you're applying. Or, if a policy is deleted/made-in-active you
>> should evaluate any elements that it may have covered. Unfortunately,
>> the point that this gets either ugly or expensive is a good point.
>> However, I think an immediate evaluation must be done regardless of
>> the costs (to do otherwise would prevent security policies from making
>> use of this work).
>> Wes Hardaker
>> NAI Labs
>> Network Associates