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

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 4 Apr 2002 17:04:43 -0600

Inline.

-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH] 
Sent: Thursday, April 04, 2002 12:57 PM
To: 'Martin Stiemerling'
Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH]
Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

That's two people so far who have said requests should be satisfied
completely or not at all.  Shall we take this as the working assumption?

First-come-first-serve vs. policy hides another issue: how to allow multiple
authorized agents to work on the same ruleset (requirement 2.2.7).  Our
proposals so far assumed this was handled through a policy mechanism.  There
is a distinction, of course, between two agents operating on the same Policy
Rule Identifier (which is perhaps what 2.2.7 permits) and two agents
defining identical rulesets with different Policy Rule Identifiers.  So I
have a couple of questions for the WG:

 1) Does the protocol address the possibility of two agents defining
overlapping rulesets and if so, are conflicts handled on a
first-come-first-served basis? 

[SS] The protocol has to allow overlapping rulesets because multiple agents
are installing rulesets independently and there're bound to be overlaps in,
say, the filter spec.  Question is, what happens when there is a
contradiction. Requirement 2.2.11 seems to suggest that we need to allow the
later agent to win, at least, under special circumstances. For example, a
Midcom agent installs a ruleset allowing packets from the address range
100.10.*.* to pass through, but at a later time, the firewall administrator
wants to create a ruleset disallowing packets from 100.10.50.10. I would
like to think that the firewall administrator would have the last say. An
administrator Agent has the highest priority. 

IMO, an Agent priority list makes sense, with an agent higher up in the
priority list can modify/revoke rulesets created by lower priority agents.
For agents of same priority, a first-come-first-serve approach may be more
suitable.

 2) Does the protocol need a formal delegation capability, so that Agent A
can tell the Middlebox that Agent B can make requests affecting Policy Rule
Identifier x?  Here we would distinguish between sharing of authority (both
Agent A and Agent B can manipulate the Policy Rule) vs. handoff (Agent A
gives up its authority to Agent B).  Which one might we want, if we want
either?  I visualize a message exchange of the form: 

[SS] Since we're requiring the Middlebox to report unsolicitated messages to
the Agent, we can do this in another way. When there is an attempt by Agent
B to install a ruleset which overlaps with and has contradictory action(s)
to one that has been installed by Agent A, then the Middlebox can send a
notification message reporting this event to A with Agent B's id. Agent A
may or may not allow this. If disallowed, the Middlebox may either reject
B's request to install or suggests an alternative/modified ruleset by
sending B an error message. 

    Agent A                     Middlebox                  Agent B 

    Grant(Policy Rule Id x, Agent B) 
    -------------------------------> 
                                        Notify (Grant, Policy Rule Id x) 
    Grant Acknowledge               ---------------------------> 
    <------------------------------- 
                                        Notify Acknowledge 
                                    <--------------------------- 

Sorry about the really theoretical stuff -- it was something I had to think
through clearly for myself, but I can see it wouldn't be generally helpful,
so we can omit it or put it into an appendix.

-----Original Message----- 
From: Martin Stiemerling [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, April 04, 2002 8:58 AM 
To: Taylor, Tom-PT [CAR:B800:EXCH] 
Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH] 
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content 

Hi, 

please find my comments embedded in the text. 

Regards 
Martin 

Tom-PT Taylor wrote: 

> This is the theoretical section of the I-D Cedric and I are working on.
We 
> 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. 

> 4     Structure And Comparison Of Policy Rules 
> 
> In this note, a Policy Rule is defined to be a set of terms of the form 

[...] 

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

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. 

> 
> (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: 

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: Juergen Quittek <[email-masked]>
Date: Fri, 05 Apr 2002 13:16:56 +0200

Sanjoy,

--On 04 April 2002 17:04 -0600 Sanjoy Sen wrote:
> That's two people so far who have said requests should be satisfied completely
> or not at all.  Shall we take this as the working assumption?
>
> authorized agents to work on the same ruleset (requirement 2.2.7).
> Our proposals so far assumed this was handled through a policy mechanism.
> There is a distinction, of course, between two agents operating on the same
> Policy Rule Identifier (which is perhaps what 2.2.7 permits) and two agents
> defining identical rulesets with different Policy Rule Identifiers.
> So I have a couple of questions for the WG:
>
> say, the filter spec.  Question is, what happens when there is a contradiction.
> Requirement 2.2.11 seems to suggest that we need to allow the later agent to win,
> at least, under special circumstances. For example, a Midcom agent installs a
> ruleset allowing packets from the address range 100.10.*.* to pass through,
> but at a later time, the firewall administrator wants to create a ruleset
> disallowing packets from 100.10.50.10. I would like to think that the firewall
> administrator would have the last say. An administrator Agent has the highest
> priority.

I did not yet consider the midcom protocol as the interface for a system
administrator to consider the firewall. I think this taks includes restricting
the the midcom interface's access to firewall control. So if the administrator
wants to disallow packets from 100.10.50.10, he should do it by configuring
the access rights of the midcom server running at the firewall, for example by
modifying the midcom serve configuration files.

But maybe I'm wrong here. I considered midcom to be used for temporary
configurations by users or applications but not as a mean for permanent
configuration of the firewall as it is done by the administrator.

So, I clearly vote for not having priorities in order to KISS. However, if
the WG decides to support also administrator configuration running over
a midcom protocol, then it should be enough to have exactly two priorities:
administrator and user (and first-come-first-serve per priority).

> Identifier x?

I think we do not need this at all. First, the scenario would be rather
a rare one to happen. Second this increases complexity significantly on
server side and on client side. More state need to be kept an more message
types are required. We should not overdesign the protocol and avoid all
complexity that is not required by a strong usage scenario.

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

> Here we would distinguish between sharing of authority (both Agent A and
> Agent B can manipulate the Policy Rule) vs. handoff (Agent A gives up its
> authority to Agent B).  Which one might we want, if we want either?
> I visualize a message exchange of the form:
>
> [SS] Since we're requiring the Middlebox to report unsolicitated messages
> to the Agent, we can do this in another way. When there is an attempt by
> Agent B to install a ruleset which overlaps with and has contradictory
> action(s) to one that has been installed by Agent A, then the Middlebox can
> send a notification message reporting this event to A with Agent B's id.
> Agent A may or may not allow this. If disallowed, the Middlebox may either
> reject B's request to install or suggests an alternative/modified ruleset
> by sending B an error message.
>
> From: Martin Stiemerling [mailto:[email-masked]]
>> This is the theoretical section of the I-D Cedric and I are working on.  We
>> Policy Rule will be disallowed (if it was the later arrival) or deactivated
>> (2) The Policy Rule which has lower priority in the zone of conflict allows

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 05 Apr 2002 09:34:27 -0500

I believe that the problem turns on how large a range of "rules" we want to 
allow.
My understanding of the goal is to allow a controlling entity to:
1) create some holes that will allow traffic to pass through the middle box
2) find out certain things about these holes (for NAT)
3) provide auxiliary processing for some packets.

Note that for cases 1 and 2, there is not much trouble.  Overlapping holes 
merely means that that hole remains open as long as either requestor needs it.

As far as I can tell, it is only the "auxilliary processing" case that 
makes life complicated.  It would seem that we could again say "both" for that.

We are not providing arbitrary policy management.
At the same time, declaring that two servers can not open overlapping holes 
in the same firewall / NAT would seem counter-factual.

Yours,
Joel M. Halpern

At 01:16 PM 4/5/2002 +0200, Juergen Quittek wrote:
>>completely
>>contradiction.

---

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

>     -----Original Message-----

[... ]

>     [SS] The protocol has to allow overlapping rulesets because multiple
>     agents are installing rulesets independently and there're bound to
>     be overlaps in, say, the filter spec.  Question is, what happens
>     when there is a contradiction. Requirement 2.2.11 seems to suggest
>     that we need to allow the later agent to win, at least, under
>     special circumstances. For example, a Midcom agent installs a
>     ruleset allowing packets from the address range 100.10.*.* to pass
>     through, but at a later time, the firewall administrator wants to
>     create a ruleset disallowing packets from 100.10.50.10. I would like
>     to think that the firewall administrator would have the last say. An
>     IMO, an Agent priority list makes sense, with an agent higher up in
>     the priority list can modify/revoke rulesets created by lower
>     priority agents. For agents of same priority, a
>     first-come-first-serve approach may be more suitable.

Midcom is not intended to be a complete firewall management tool,  but 
rather a tool for configuring pin-holes for applications. And by the 
way, the best way to disallow packets permanently, you better use the 
command line interface.

> 
>      2) Does the protocol need a formal delegation capability, so that
>     Agent A can tell the Middlebox that Agent B can make requests
>     affecting Policy Rule Identifier x?  Here we would distinguish
>     between sharing of authority (both Agent A and Agent B can
>     manipulate the Policy Rule) vs. handoff (Agent A gives up its
>     [SS] Since we're requiring the Middlebox to report unsolicitated
>     messages to the Agent, we can do this in another way. When there is
>     an attempt by Agent B to install a ruleset which overlaps with and
>     has contradictory action(s) to one that has been installed by Agent
>     A, then the Middlebox can send a notification message reporting this
>     event to A with Agent B's id. Agent A may or may not allow this. If
>     disallowed, the Middlebox may either reject B's request to install
>     or suggests an alternative/modified ruleset by sending B an error
>     message.

Delegating rules to other agents blows the whole protocol up and it is 
from my view questionable, if this function is ever needed. We can put a 
lot of functions into this protocl, but we should consider that somebody 
has to implement this stuff sometimes.

Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 05 Apr 2002 17:10:45 +0200

Joel M. Halpern wrote:

> I believe that the problem turns on how large a range of "rules" we want 
> to allow.

What is your definition of "auxiliary processing"?

> 
> Note that for cases 1 and 2, there is not much trouble.  Overlapping

> holes merely means that that hole remains open as long as either 
> requestor needs it.

You assume that the holes are already configured, but the problem 
appears earlier: How to configure the rules at all?

Martin

> At the same time, declaring that two servers can not open overlapping 
> holes in the same firewall / NAT would seem counter-factual.
> 
> Yours,
> Joel M. Halpern
> 

-- 
Martin Stiemerling

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