Subject: RE: [midcom] Precedence of wildcards

From: John LaCour <[email-masked]>
Date: Thu, 13 Sep 2001 16:04:00 -0700

I'd like to ask the group if the requirement to ensure
that the precedence of rulesets is determinate can be
defined as it must be possible to determine if a MIDCOM
ruleset takes precedence over existing rulesets or
is evaluated after other rules?

I'd like to reduce the complexity of this requirement
if at all possible.

In many middleboxes today, there are a variety of 
'things' which define policies.  These include, 
administratively defined policies, ALGs, interaction with
IDS (external or internal to the midbox), and others.
I'm concerned about going down the path where MIDCOM
has to learn about all of these things, when their
rulesets change, etc. in order to specify an
explicit precedence of its rules relative to everything
else.

If we limit precedence to "before everythings else" or
"after everythings else" I think we're ok.  

I personally don't even think this is a real requirement.
In all cases a MIDCOM rule's precedence should be 
before all currently existing rules, but after future
rules.

-John

> -----Original Message-----
> From: Mark Duffy [mailto:[email-masked]]
> Sent: Thursday, September 13, 2001 3:17 PM
> To: Christian Huitema; [email-masked]
> Subject: [midcom] Precedence of wildcards
> 
> 
> (subject line changed -- this is really a resumption of a 
> thread from last
> week)
> 
> At 02:34 PM 9/13/01 -0700, Christian Huitema wrote:
> >OK, there is a confusion in my initial phrasing. Try this:
> >
> >R86: It should possible to define rulesets that contain a 
> more specific
> >filter than an overlapping ruleset, and a different set of 
> attributes.
> >This should allow Midcom agent to request that a subset of 
> the traffic
> >that would be allowed by the overlapping ruleset be specifically
> >disallowed. 
> >
> >Reasoning: this is required for rapid response to intrusion 
> detection.
> 
> Christian, thanks.  That sounds better.  I agree with the requirement.
> 
> 
> >To answer Mark question, yes I expect that "when the filters of two
> >rulesets overlap, the middlebox only executes the actions 
> specified by
> >the most specific ruleset."
> 
> This is where we get back to the earlier thread about precedence of
> wildcards and  a fixed canonical ordering scheme as you have proposed.
> 
> Consider a firewall which usually has the following rule to 
> permit access
> from the Internet to a web server:
>    Rule1: SA=*, DA=1.2.3.4, prot=tcp, SP=*, DP=80: permit all incoming
> 
> Now there is some kind of attack from 5.6.7.8.  If I understand the
> motivation here, one might want to add a "rapid response" 
> rule to block any
> acces from that host, i.e.:
>    Rule2: SA=5.6.7.8, DA=*, prot=*, SP=*, DP=*: deny all
> 
> Clearly we want Rule2 to be applied in preference to Rule1 
> when both may
> match.  Now if I understand the canonical ordering idea, we 
> pick some fixed
> significance order for the 5-tuple fields, such as
>   MSB-->   SA|DA|prot|SP|DP   <--LSB
> so we have:
>             SA      DA prot SP  DP
>   Rule1: *.*.*.*.1.2.3.4.6.*.*.0.80
>   Rule2: 5.6.7.8.*.*.*.*.*.*.*.*.*
> 
> Now I gather we order the rules according to:
>    '1' bit > '0' bit > 'dont care' bit
> which means Rule2 > Rule1 and any traffic from 5.6.7.8 is 
> therefore denied.
>  In this case that is exactly what we want.  But how can we 
> be confident
> that this algorithm will give the desired result in all 
> cases?  Suppose the
> "usual" rule only allowed server access from subnet 
> 8.9.10/24.  Now we have
>    Rule1a: SA=8.9.10.*, DA=1.2.3.4, prot=tcp, SP=*, DP=80: 
> permit all incoming
> Now Rule1a > Rule2 and the rapid response ruledoesn't get the desired
> preference!
> 
> Perhaps I am misunderstanding how the canonical ordering 
> would be imposed?
> 
> I know you advocate Interior/Exterior address and port view 
> rather than
> Source/Dest but I do not believe that alters the basic 
> question in this case.
> 
> --Mark
> 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
> 

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 13 Sep 2001 18:36:17 -0700 (PDT)

I agree with John. I like the simple requirement, as stated below.
Let us not make the requirements so hard that it becomes impossible
to design a MIDCOM protocol/language that can meets the requirements. 

The requirements at some point of time should be categorized as
MUST/SHOULD/MAY. 

cheers,
suresh

> > Source/Dest but I do not believe that alters the basic 

__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

---

From: Scott Brim <[email-masked]>
Date: Fri, 14 Sep 2001 09:06:53 -0400

> I'd like to reduce the complexity of this requirement

   R85: It must be possible to deterministically predict the behavior of
        the middlebox in the presence of overlapping rules.

I think that does what you want.  Christian introduced that one, right?

We're spending a lot of time on the next working group's business.  I
guess we're impatient to get on with it.  So let's finish the
requirements.