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

Re: IPSEC-POLICY-MIB - Processing of filters and conditions

>>>>> On Thu, 10 May 2001 10:14:27 -0400, "Casey Carr" <caseycarr@xxxxxxx> said:

Casey> I was confused between the MIB contents pertaining to
Casey> filter/condition processing and the contents of the Policy
Casey> Model draft.  Jamie Jason was able to point me to the correct
Casey> location in RFC 3060 and the Policy Model draft to get
Casey> clarification.  After reviewing these documents it appears to
Casey> me that the MIB has changed the semantics for this processing.
Casey> The MIB draft seems to be a somewhat simpler implementation.
Casey> Was that the desire?

Casey> In particular the concept of a "condition group" has been
Casey> dropped in favor of a sequence of conditions.  Also, the
Casey> "sequence" attribute of filtersInCondition has been dropped.
Casey> This attribute was intended to allow either ANDing or ORing
Casey> filters.

You're right that doing DNF and CNF processing wasn't possible in the
MIB.  I've inserted the following object into the conditionTable which
should allow you to either AND or OR the filters.  Note that we have
separate objects that would functionally let you do things that the
policy model wouldn't let you do, like "AND and AND" and "OR and OR"
the conditions and filters respectively.  This is done for processing
simplicity and makes reuse of filter and condition definitions a bit

  conditionFilterListType OBJECT-TYPE
      SYNTAX	IpsecBooleanOperator
      MAX-ACCESS  read-create
      STATUS	current
  	"Indicates whether the filters contained within this filter
  	 are functionally ANDed or ORed together"
      DEFVAL { and }
        ::= { conditionEntry 3 }

Does this meet your requirements stated above?

You're right that the MIB draft attempted to simplify the model usage
a bit, as I found it somewhat complex and that you could accomplish
the same functionality without the higher overhead of the more OO like

The sequencing introduced into the model was intentional, primarily as
an methodology for introducing optimization.  If, for instance, you
put your more generic simpler filters higher in the sequence list you
could determine early on that the more complex filters/conditions
later in the sequence didn't need to be evaluated if the current
filter/condition indicated a stop condition.  Make sense?

So, condition grouping is functionally established in a different way:
the rule dictates the ANDing/ORing of the conditions within, and the
sequence number allows you to optimize which are evaluated first.

Do you find this a reasonable design, or do you still have problems
with it?  Note that I'm trying to support everything the data model
contains, but in a possibly more simple and flexible architecture.

Wes Hardaker
NAI Labs
Network Associates