Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 4 Apr 2002 16:27:47 -0600

How will then the following requirement from Midcom requirements draft be
satisfied?
*****
2.2.11.

     It should be possible to define rulesets that contain a more spe-
     cific filter spec than an overlapping ruleset.  This should allow
     agents to request actions for the subset that contradict those of
     the overlapping set.
*****

Whether you want it or not, there would be overlapping rulesets because the
filterspec may overlap for different rulesets installed by independent
agents. The question - who wins when there're contradictory actions is moot
because the requirement above seems to suggest that we need to allow
contradictory behavior.

Any comments?

Sanjoy

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 5:57 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]
> Cc: Aoun, Cedric [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content
> 
> 
> Tom-PT,
> 
> I'm glad midcom has gained momentum to focus on real things.
> 
> As for the overlapping rules: I'm very much in favor of the approach
> #1, i.e., disallowing overlapping rules. I think MidCom's primary
> purpose is to get apps over NATs/FWs for which this is good enough.
> It is not good enough for a FW/NAT mgmt protocol, but that is not
> what we are concerned with. Allowing overlapping rules would result 
> in unnecessarily higher complexity of midcom servers. Simple is good.
> 
> Rather then priorities, I would prefer to use first-come, 
> first-served 
> conflict resolution then. 
> 
> -Jiri
> 
> >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
> >
> >_______________________________________________
> >midcom mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/midcom 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
>

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 05 Apr 2002 16:56:33 +0200

Sanjoy Sen wrote:

> How will then the following requirement from Midcom requirements draft 
> be satisfied?
> *****
> 2.2.11.
> 

> Whether you want it or not, there would be overlapping rulesets because 
> the filterspec may overlap for different rulesets installed by 
> independent agents. The question - who wins when there're contradictory 

> actions is moot because the requirement above seems to suggest that we 
> need to allow contradictory behavior.

The questions is, who will decide how to behave in such a case? There 
are so many combinations of firewall/NAT configurations which will make 
it difficult to define a stable behaviour, i.e. how to react with this 
overlapping set. Furthermore, the requirement starts with "should"...

Martin
-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de