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

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 12 Apr 2002 15:08:06 -0400

Then perhaps we do have to debate decision rules, and can't just live with
first-come, first-served.  However, let me make one last try: could the
broader rule be provisioned, and the narrower one installed by the Midcom
protocol?

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Friday, April 12, 2002 3:01 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]; Sen, Sanjoy [NGC:B692:EXCH]; Jiri
Kuthan; Martin Stiemerling
Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

Not necessarily. From an operational point of view, it is important to not
tie a rule to an agent -- we debated that at length last year. 

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 11:51 AM
To: Christian Huitema; Sanjoy Sen; Jiri Kuthan; Martin Stiemerling
Cc: [email-masked]; Cedric Aoun
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

Would the same Agent install both rules? 
-----Original Message----- 
From: Christian Huitema [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 2:24 PM 
To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]; Jiri 
Kuthan; Martin Stiemerling 
Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH] 
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content 

I am sorry, but the requirement was there for a very strong operational
reason. For example, it should be possible to say something like:
1) disallow UDP on port 3456 in general 
2) allow UDP on port 3456 if the source is X and the destination Y. 
-- Christian Huitema 
-----Original Message----- 
From: Sanjoy Sen [mailto:[email-masked]] 
Sent: Friday, April 12, 2002 10:21 AM 
To: Tom-PT Taylor; 'Jiri Kuthan'; 'Martin Stiemerling' 
Cc: [email-masked]'; Cedric Aoun 
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content 
I support this as a good compromise. We should disallow contradictions in
overlapping rulesets (and resolve on a FCFS basis). But, we should allow
overlapping rulesets if there's no contradiction.  
> -----Original Message----- 
> From: Taylor, Tom-PT [CAR:B800:EXCH] 
> Sent: Friday, April 12, 2002 7:52 AM 
> To: 'Jiri Kuthan'; 'Martin Stiemerling'; Sen, Sanjoy [NGC:B692:EXCH] 
> Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH] 
> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content 
> 
> 
> I agree with your distinction between the issues of rule 
> overlapping and access control.  I do wonder if you are being 
> too dogmatic on the matter of rule overlapping, and would beg 
> for exceptions in two cases: 
> 
>   -- the rules do not involve contradictory actions (e.g. 
> both rules allow flows) 
> 
>   -- the rules both come from the same Agent. 
> 
> Here is an example scenario in which I could see the 
> possibility of rule overlapping: a rule is set up allowing 
> any node inside to connect to a specific address outside.  
> Then an Agent sets up a rule allowing connection from a 
> specific inside address to that outside address.  In the 
> process, the Agent receives an address binding to the mapped 
> address at the Middlebox.  Using the notation I have proposed 
> earlier, the first rule is: 
> 
> Filter= { Source address:      ANY, 
>           Source port:         ANY, 
>           Source realm:        <the internal realm>, 
>           Map address:         ANY, 
>           Map port:            ANY, 
>           Map realm:           <the external realm>, 
>           Destination address: <specific external address>, 
>           Destination port:    <specific external port>, 
>           Destination realm:   <the external realm>, 
>           Protocol             <a specific protocol> }, 
> 
> Action = Allow 
> 
> The second, more specific rule is: 
> 
> Filter= { Source address:      <specific internal address>, 
>           Source port:         <specific internal port>, 
>           Source realm:        <the internal realm>, 
>           Map address:         CHOOSE, 
>           Map port:            CHOOSE, 
>           Map realm:           <the external realm>, 
>           Destination address: <specific external address>, 
>           Destination port:    <specific external port>, 
>           Destination realm:   <the external realm> }, 
> 
> Action = Allow 
> 
> In response to this second rule the Middlebox reports the 
> bindings it has assigned for the CHOOSE entries. 
> 
> I can think of one or two arguments you may have against this 
> sort of situation, but I don't know which particular 
> arguments you would choose.  So I'll see what you have to say. 
> 
> As for allowing an Agent to amend or contradict itself, I see 
> this as a matter of convenience.  It makes it easier to 
> associate specific Policy Rules with specific application 
> sessions, regardless of how they interact.  If you disallow 
> it, the workaround is for the agent to combine everything 
> into a single Policy Rule.  This is OK provided that the 
> Agent knows that it itself is the source of the overlap. 
> 
> 
> -----Original Message----- 
> From: Jiri Kuthan [mailto:[email-masked]] 
> Sent: Friday, April 12, 2002 5:30 AM 
> To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Martin Stiemerling'; Sen, Sanjoy 
> [NGC:B692:EXCH] 
> Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH] 
> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content 
> 
> 
> I think people mix up two issues: rule overlapping and access control. 
> 
> I argumented against rule overlapping -- I want to disallow rules 
> with different packet matching expressions with packets matching 
> both of them. Doing anything else is a ticket for unneeded complexity 
> and I see reluctance to enter such business on mailing list. 
> 
> The other, security-policy issue is how access to rules 
> with identical packet matching expressions is governed. Which is 
> a different discussion. 
> 
> -Jiri 
> 
> At 06:43 PM 4/5/2002, Tom-PT Taylor wrote: 
> 
> >Assuming that contradictions are possible (see my previous message), 
> 
> Please NO. 
> 
> > we should distinguish two cases: 
> > - a specific Agent contradicts a Policy Rule installed 
> previously by that same Agent 
> > - a specific Agent contradicts a Policy Rule installed by 
> another Agent. 
> > 
> >An underlying premise of our proposed semantics is that each 
> Policy Rule (defined as a set of {Filter, Action} pairs with 
> a specific Policy Rule Identifier) has one or more owners.  
> That is, the Middlebox remembers the Agent(s) who installed 
> those rules. 
> > 
> >Whether more than one Agent should be able to work with the 
> same Policy Rule is a matter for discussion, though I sense 
> an inclination not to allow this.  (But it seems to me that 
> an Administrator should be able to audit all installed Policy 
> Rules and deactivate any of them if need be.)  On the other 
> hand, I think it is accepted that different Policy Rules 
> could overlap in their scope.  So I'll concentrate my 
> discussion on the case where a new Policy Rule is in conflict 
> with a previously installed Policy Rule. 
> > 
> >I would suggest a general approach to conflicts of this form: 
> > 
> > - If an Agent contradicts itself, the Middlebox denies the 
> new Policy Rule Request.  It returns an appropriate reason 
> code and the Policy Rule Identifier of the rule which is in 
> conflict.  The Agent then has the information it needs to 
> choose between modifying the already-existing rule to 
> accommodate the new conditions or giving up on the new Policy Rule. 
> > 
> > - If an Agent contradicts another Agent, Agent priorities 
> come into play.  I'm happy enough to allow only two 
> priorities: Administrator and others, but I'm not sure we 
> need to specify this, only that there exists a hierarchy of 
> Agent priorities.  The general rule is then that the Policy 
> Rule installed by the higher priority agent prevails and the 
> other one is rejected or deactivated as the case may be.  
> Between equal-priority Agents, existing Policy Rules take 
> priority over new ones. 
> > 
> >One open question is what diagnostic information should be 
> supplied when a Policy Rule is rejected or deactivated.  I 
> see the following possibilities: 
> > 
> >(1) The Middlebox computes and returns a modified Policy 
> Rule that would be consistent with the over-riding Policy Rule. 
> > 
> >(2) The Middlebox returns the complete contents of the 
> over-riding Policy Rule. 
> >(3) The Middlebox returns the (sub)set of {Filter, Action} 
> pairs within the over-riding Policy Rule which are in 
> conflict with the disallowed Policy Rule. 
> > 
> >(4) The Middlebox returns a set of filters which describe 
> the precise area of conflict with the over-riding Policy Rule. 
> > 
> >I have a bit of a concern with privacy which inclines me to 
> alternative (4). 
> > 
> >-----Original Message----- 
> >From: Martin Stiemerling 
> [<mailto:[email-masked]>mailto:Martin.Stiemer 
[email-masked]] 
>Sent: Friday, April 05, 2002 9:57 AM 
>To: Sen, Sanjoy [NGC:B692:EXCH] 
>Cc: 'Jiri Kuthan'; Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]; 
>Aoun, Cedric [QPD:MA01:EXCH] 
>Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content 
> 
>Sanjoy Sen wrote: 
> 
>> 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. 
> 
>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>http://www.ccrle.nec.de  IPv6:
<http://www.ipv6.ccrle.nec.de>http://www.ipv6.ccrle.nec.de 

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

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 12 Apr 2002 14:23:06 -0500 (CDT)

This discussion, while fascinating, appears to be operating
in a vacuum. Please name ONE existing middlebox device that
disallows -- or can even detect -- conflicting rules. While
a few probably exist, most will use a stacking model of some
sort. Logic of the form:

	the most recently applied rule relevant to the packet applies
or
	all relevant rules are applied in the order they were
	created until either a rule discards the packet or
	all are done.

or whatever. There are numerous ways to resolve this. Disallowing
conflicting rules simply isn't one of the good ways.

It is NORMAL to build policy by layering rules according to
whatever the conflictin-rule logic of your box is. It is NORMAL
to define general policy, and overlay/underlay/whatever special
cases.

		Andrew