Subject: [midcom] resource/ruleset ownership (R3b, R59 & R79)

From: "Bob Penfield" <[email-masked]>
Date: Wed, 26 Sep 2001 11:09:37 -0400

I have some questions/comments on these items relative to ownership.

R3b: The Midcom protocol MUST support multiple agents manipulating
     the same middlebox resource.

R59: The MIDCOM Protocol must allow the ownership of a requested flow
     to be transferred from one MIDCOM Agent to another.

R79: The midcom protocol must not preclude multiple authorized agents
     from working on the same ruleset.

First, R3b and R79 seem to be talking about the same thing. My question is:
based on our current definition of ruleset, what other resources would a
midcom agent manipulate? If rulesets (and their component parts) are the
only thing that an agent is allowed to manipulate, then we should pick
either R3b (s/resource/ruleset/) or R79.

Given that we want to allow (or at least not preclude) multiple agents
manipulating the same ruleset (e.g. one agent creates it and another deletes
it), the issue is how does the middlebox decide that a given agent is
authorized to manipulate a given ruleset?

I do not like R59 because it requires that the application (via the midcom
agent) explicitly handoff the "ownership" to another. This is particularly
problematic when you have redundancy in the application. If a given instance
of the application (and its midcom agent that created the ruleset) dies, the
midcom agent associated with a redundant instance of the application needs
to be able to delete the ruleset when the application determines that the
ruleset is no longer required (e.g. when a SIP session ends, the ruleset
allowing the RTP flows needs to be removed).

So, do we have a notion of multiple ownership which is expressed in the
protocol? Or does the middlebox have policy (locally or acquired from a
policy server) that somehow defines the flavors of rulesets that each agent
is allowed to manipulate? Or is there another approach?

What I mean by "flavors" is that the policy might express the ranges of
addresses and ports that a given set of agents were allowed to define
firewall pin-holes for. Or in the case of NAT, it would be the pool of
addresses and ports that could be given out for NAT bindings.

I think I prefer the policy approach because it removes the issue of midcom
agents knowing about each other from the midcom protocol. In that case, do
we need to address this as part of the policy server component of the
framework?

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 26 Sep 2001 12:04:14 -0400

At 11:09 AM 9/26/01 -0400, Bob Penfield wrote:
>manipulating the same ruleset 

That decision hasn't been made by the group yet.  There
was substantial disagreement in London.

Melinda

---

From: Scott Brim <[email-masked]>
Date: Wed, 26 Sep 2001 12:15:54 -0400

> either R3b (s/resource/ruleset/) or R79.

OK.  "Resource" means more than rulesets, but I believe you're right
that the only thing an agent gets to influence *directly* is rulesets.

> authorized to manipulate a given ruleset?

First, it's not given (yet -- that's the point of your mail, yes?).
Second, part of initial handshaking is authentication/authorization for
the middlebox/agent functions as wholes, and then there may be further
authorization checking for each transaction (with or without involvement
of a policy server).

> allowing the RTP flows needs to be removed).

I thought we already tossed out ownership in discussions in and around
the last IETF.

> is allowed to manipulate? Or is there another approach?

Those are separate questions, not mutually-exclusive alternatives.

Personally I think (1) no, (2) yes, (3) yes but not a desirable one.

> addresses and ports that could be given out for NAT bindings.

Yes.

> we need to address this as part of the policy server component of the

Yes.

..Scott

---

From: Melinda Shore <[email-masked]>
Date: Wed, 26 Sep 2001 12:40:25 -0400

At 12:28 PM 9/26/01 -0400, Bob Penfield wrote:
>    This was accepted at the London meeting, except that we need
>    to decide on the very last word.
>
>There was substantial disagreement on the "ownership" issue, however I think
>there is a widespread belief that midcom will need to work in an environment
>where there is redundancy in the application that would lead to the need for
>multiple midcom agents to access the same ruleset/resource.

You'll note that R79 doesn't discuss ownership as such.  I think
that it's sufficient to deal with this as an authorization question.

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 26 Sep 2001 12:28:36 -0400

> was substantial disagreement in London.

Please excuse me, s/Given that/If/

However, according to the 9/24/01 bullet list:

(-:bob

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 26 Sep 2001 13:05:48 -0400

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "midcom mail-list"
<[email-masked]>
Sent: Wednesday, September 26, 2001 12:40 PM
Subject: Re: [midcom] resource/ruleset ownership (R3b, R59 & R79)

> that it's sufficient to deal with this as an authorization question.
Absolutely. I'm in favor of rejecting R59 and "ownership" and using the
policy approach to control which midcom agents can access which rulesets.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 27 Sep 2001 12:58:49 -0400

The proposal before us is to delete R3b and R59 in favor of
retaining R79.  There doesn't seem to be any objection so far,
although this was a hotly contested topic in London.  If
there are objections to this proposal, please speak up.

Melinda