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

From: "Casey Carr" <[email-masked]>
Date: Thu, 10 May 2001 10:14:27 -0400

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

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

Casey

---

From: Wes Hardaker <[email-masked]>
Date: 11 May 2001 07:40:23 -0700

>>>>> On Thu, 10 May 2001 10:14:27 -0400, "Casey Carr" <[email-masked]> said:

Casey> I was confused between the MIB contents pertaining to
Casey> filter/condition processing and the contents of the Policy
Casey> Model draft.

The filter table is probably going to be rewritten.

One thing you should note is that the MIB was written from the -01
version of the data-model, and both the -02 version of the data-model
and the MIB were published at the same time so that the MIB is
functionally behind the data model and needs to catch up again.

I'll try to a new draft out by the end of this month, but I doubt I'll
make that deadline.  June should be possible, however.
-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Wes Hardaker <[email-masked]>
Date: 31 May 2001 15:27:26 -0700

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

  conditionFilterListType OBJECT-TYPE
      SYNTAX	IpsecBooleanOperator
      MAX-ACCESS  read-create
      STATUS	current
      DESCRIPTION
  	"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
model.

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