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

From: "Tom-PT Taylor"<[email-masked]>
Date: Thu, 4 Apr 2002 13:56:30 -0500

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?

 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:

    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]]
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: Adina Simu <[email-masked]>
Date: Thu, 04 Apr 2002 11:18:38 -0800

Tom,

> completely or not at all.  Shall we take this as the working

I vote "yes". If an agent receives a negative answer to its request, it
can try again, this time requesting a narrower ruleset. 

One idea would be to include some error codes in the response, to let
the agent know if a narrower ruleset might be accepted.

-Adina

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

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

---

From: Scott Brim <[email-masked]>
Date: Thu, 4 Apr 2002 17:18:35 -0500

> completely or not at all.  Shall we take this as the working assumption?

I think so too.  You could have a flag saying partial fulfillment is
allowed.  However, it would be very good to keep the midcom protocol
lean and mean.  If a request is not atomic and can be partially
fulfilled, then it can be broken up into independent requests as well.

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 5 Apr 2002 15:03:48 -0500

There have been a lot of comments on this thread, but I want to go back to
the original questions and make a few points which may also apply to later
comments.

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>

> completely or not at all.  Shall we take this as the working assumption?

First, I think that each request from the agent should be atomic. Partial
rule installation just makes everything too complex.

> First-come-first-serve vs. policy hides another issue: how to allow
multiple
> Rule Identifier (which is perhaps what 2.2.7 permits)

That is exactly what 2.2.7 is talking about. The motivation for allowing
multiple agents to work on the same rule came from the need for redundancy
and reliability in the application layer (i.e. the agents). I don't think
the case would be that both agents would create/install the rule, but rather
one would create it and the other might modify or remove if the second agent
became responsible for the rule because the first agent died.

> and two agents

I think first-come-first-served is the right approach. However, I would see
a conflict only when the filter was identical. We had talked about having
overlapping rules, but one would have a "more specific" filter. For example,
a rule might allow a whole range of addresses and ports thru, but there
might be rules to deny more specific or narrower ranges of addresses and
ports. The more specific filter would take precedence when deciding what to
do with a specific packet which matched multiple rules (i.e. their filters).

> Identifier x?

I don't think this is what we want. For the case of a failure of one agent
in a redundant pair, the crashed agent would not be able to "delegate" the
rule to the other agent. This relationship has to be established either by
policy in the middlebox, or in rule creation/modification with the semantics
of "BTW, allow agent X to also mess with this rule, and send it
notifications about this rule too".

cheers,
(-:bob