ietf-openproxy
[Top] [All Lists]

Re: [midcom] policy & duration

2001-08-08 00:13:24

Do you think that alignment between OPES policy and MidCom policy
concepts should be applied where appropriate?  If so, should the document
not reflect this?
At 08:42 AM 8/7/2001, Eliot Lear wrote:

In our bar-fob we had a number of issues with policy.  i have promised to
provide some words to help improve the situation.  I hope this does.
Please note that there is a trivial case hidden in these requirements,
obviating the need for a policy server in many instances.  Thus the
wording allows for a fairly flexible architecture.  Don't understand the
policy conditions?  Go ask the policy server.

This information supersedes section 4.3 of the requirements document and
augments (and will need to be reconciled with) sections 2.9 and 6 of the
framework document.  The wording here will need to be further reconciled
with the policy documents.

Please note that I have not addressed what information is returned to the
midcom agent.  That is an important topic and it needs to be better
understood.

I've also taken a stab at rewriting the duration discussion.  There may be
lots of text we can borrow from the policy people on this subject.

--

4.3  Policy

Each middlebox decision is made based on either configured policy or by
querying a policy server.  While it is not within the midcom rubric to
specify policy configuration methods, the actual policy configuration
itself is important to discuss.

A policy statement consists of one or more policy conditions and a policy
action.[policy]

4.3.1 Policy conditions

Some policy decisions, such as those based on 5-tuple simple access lists
are likely to be made by a middle box.  Other decisions, however, are
likely to be more complex.  Hence we propose a nuanced approach that
allows the policy function to be split.

The midcom agent MUST be able to satisfy informational requirements of the
policy conditions in a policy statement in order for the policy server to
make a decision.  Therefore, a structured exchange that contains those
components MUST occur between the midcom agent and the middlebox, both
query and response.  In as much as a policy server is required to resolve
the policy conditions, a structured exchange MUST also occur between the
middle box and the policy server.

If a middle box acts as its own policy server, it MUST understand any
policy information needed to execute a policy statement.  Put another way,
it MAY discard any policy information that it doesn't understand so long
as that information is not required to make a policy decision.

If the middle box does not understand all of the policy conditions, it
MUST refer the request to a policy server.  It is a configuration error to
have a policy condition that neither the middle box nor the policy agent
can evaluate.

A middle box SHOULD understand, at a minimum, policy conditions that
contain the interfaces involved, protocol, source address and port,
destination address and port, all of which with the exception of protocol
and interfaces MUST be capable of being expressed as a range of values.
This is the trivial case, necessary to deploy a middlebox without the
assistance of a policy server.

One should expect a middle box that understands a given policy condition
to police it.  However, we do not require it.

4.3.2 Policy actions

Policy actions are those actions associated with a set of policy
conditions in a policy statement.  Examples might be "open a pinhole" or
"return NAT bindings for a given system".

The middle box MUST understand the policy action it is to take.  The
semantics and syntax of each of those policy actions MUST be documented in
a standard.

Hence, policy information SHOULD be encoded in a standard form that is
possible for a middle box to decode, even if it cannot evaluate each
policy condition.

Examples of policy statements can be found in [POLICY].

X Duration

Decisions made by middle boxes MUST have a specific duration.  That
duration MUST include a time interval or a set of actual dates and times,
and MAY include additional termination conditions.  Examples of
termination conditions include an exchange of TCP FINs, the excessive use
of bandwidth, or the exchange of unauthorized content.  A midcom agent MAY
request a change in duration, but the decision of the middle box, like
every other decision will be bound by policy.
--
Eliot Lear
lear(_at_)cisco(_dot_)com

_______________________________________________
midcom mailing list
midcom(_at_)ietf(_dot_)org
http://www1.ietf.org/mailman/listinfo/midcom

Michael W. Condry
Director,  Network Edge Technology




<Prev in Thread] Current Thread [Next in Thread>