Subject: [midcom] MIDCOM SEmantics: Policy Rule Content

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 2 Apr 2002 10:25:24 -0500

This is the theoretical section of the I-D Cedric and I are working on.  We
are still validating it against the various scenarios.

4	Structure And Comparison Of Policy Rules

In this note, a Policy Rule is defined to be a set of terms of the form
{Filter, Action}, the union of which defines the desired policy.  Any such
set can be refined into a canonical form in which the Filter part of each
{Filter,Action} term represents a rectangular prism (i.e. a box) in N-space,
where N is the number of components of the filter.  If two such filters are
compared for overlap, the zone of overlap, if any, will be another box.  See
the diagram below, where the area of overlap is marked with X's.

                  +-------------------------+
                  |     Filter 1            |
                  |                         |
                  |                         |
                  |            +-------------------------+
                  |            |XXXXXXXXXXXX  Filter 2   |
                  |            |XXXXXXXXXXXX             |
                  |            |XXXXXXXXXXXX             |
                  |            +-------------------------+
                  |                         |
                  +-------------------------+

Suppose now that these two filters are associated with actions which
contradict each other.  Then the decision rules used by the Middlebox will
decide which action will apply in the region of overlap.  By assumption,
these decision rules will be based on the combination of order of
specification and policy at the Middlebox.

There are two possible cases:

(1) The Policy Rule associated with each of the two {Filter, Action} pairs
must be installed completely or not at all.  In this case, if there is a
conflict between the two rules in the zone of overlap, the lower-priority
Policy Rule will be disallowed (if it was the later arrival) or deactivated
(if it was already installed).

(2) The Policy Rule which has lower priority in the zone of conflict allows
for partial implementation.  Thus the desired {Filter, Action} pair is
modified to exclude the zone of overlap.  There are two sub-cases:

(a) In the simpler case, the exclusion of the zone of overlap still leaves a
box in N-space.  This is true of Filter 2 in the diagram.  In this case, the
original {Filter, Action} pair is replaced by another {Filter', Action} pair
where Filter' defines the region outside the zone of overlap.

(b) In the more complex case, the exclusion of the zone of overlap leaves a
complex region rather than a simple box.  This is true of Filter 1 in the
above diagram.  In this case, the region can be partitioned into a set of up
to 2N simple boxes in N-space.  Thus the canonical outcome of the conflict
with respect to the original {Filter, Action} pair is a set of {Filter,
Action} pairs where Action is the same as in the original pair.

Policy rules are evaluated for conflict through a pairwise comparison of
their individual {Filter, Action} components.

Let us turn now to the detailed semantic content of the {Filter, Action}
pairs.  As the examples of section 4 illustrate, it is possible to represent
NAT and firewall policies using sets of uni-directional filters of the form
 
{<Source Address-Port>, <Map Address-Port>, <Destination Address-Port>,
Protocol} 

with suitable wildcarding.  Each Address-Port term has the detailed form
{Address, Port, Realm}.  Two wildcards are needed:

 - ANY is a placeholder for a value to be bound when a flow instance is
matched against the Policy Rule.

 - CHOOSE is a value to be assigned by the Middlebox at Policy Rule
installation time.  That is, each CHOOSE in a Policy Rule Request must be
replaced by a specific value in a Policy Rule Response.  CHOOSE must only be
used for components of <Map Address-Port>.

Our requirements indicate the need for two additional items.  It must be
possible on occasion for the filter to specify a range of ports rather than
a single port.  Moreover, it must be possible to constrain the parity of the
Map port assignment(s).  These requirements are satisfied by adding three
modifiers to the port components of the filter:

 - the Count modifier is an integer from 1 upwards.  If it is included in a
port component, it indicates that a range of ports is requested.  If the
filter provides a specific value rather than a wildcard for the port in
question, the port assignments begin with that value.  If Count is absent,
only one port is indicated.

 - the Step modifier must not be present unless the Count modifier is also
present.  It is an integer from 1 upwards indicating the increment to be
applied in determining port numbers for a port number range.  One example of
when Step would be needed is when allocating RTP or RTCP ports for layered
encoding.  In this example, Step would have value 2.  The default if Step is
absent is an increment of 1. 

 - the Parity modifier has values Odd or Even.  If it is included in a port
component, it indicates that the port (or the first port of a range) must
have the given parity.  If Parity is not specified, port assignment is
unconstrained.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 04 Apr 2002 15:57:51 +0200

Hi,

please find my comments embedded in the text.

Regards
Martin

> are still validating it against the various scenarios.

Yes, it is very theoretical. We should aviod such text for internet 
drafts, because a lot of people won't even continue reading the entire 
document.

> In this note, a Policy Rule is defined to be a set of terms of the form

[...]

> (if it was already installed).

This sounds very complicated and with a lot of administrative overhead. 
I prefer Jiri's idea of disallowing overlapping rules at all and using a 
first come, first served scheme, instead of priorities. Should there be 
any conflict, reject the latest policy rule request.

> modified to exclude the zone of overlap.  There are two sub-cases:

Hmm, how to tell the agent, that his rule request has been fulfilled 
only partial? My opinion is, that the agent wants exactly this policy 
rule and if he can't get this, tell him!

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 12 Apr 2002 10:11:53 -0400

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>
<snip>
> {<Source Address-Port>, <Map Address-Port>, <Destination Address-Port>,

I would think that the filter would contain only the data used to match
packets. The Map Address-Port would part of the action. Also, I don't think
a single Map Address-Port is sufficient.

I see the parameters in the Filter as follows:

    Source Address-Port
    Destination Address-Port
    Transport Protocol (UDP, TCP, etc)

The actions would include:

    New Source Address-Port
    New Destination Address-Port
    Allow/Disallow