Subject: RE: [midcom] MIDCOM Semantics

From: "Tom-PT Taylor"<[email-masked]>
Date: Tue, 2 Apr 2002 10:04:06 -0500

My responses follow your comments, marked with [PTT].

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Tuesday, April 02, 2002 9:21 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]
Subject: Re: [midcom] MIDCOM Semantics

see embedded comments below

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>
<snip>
> 3.2 Summary of Exchanges:
>
> 1) Policy Rule Request/Response
>
> Request from the Agent to install a specific Policy Rule, associating it
> with a specific identifier and assigning it a specific lifetime.  The
> request also indicates whether partial installation is allowed.  This
> request has replacement semantics: if the identified rule was previously
> installed, it is replaced completely by the content of the request
assuming
> that the Agent has the authority to make this request.  This assumption is
> made to simplify the semantic presentation: the WG may wish as an
> optimization to define an additional message to incrementally modify a
rule
> already in place.

Providing for incremental modification of the rule (i.e. specifying only the
fields that have changed) would reduce the amount of bandwidth used by the
protocol.

[PTT]
Agreed.  My intent was to state the semantics at the most abstract level,
with the idea that a practical realization would break them up, but in
different ways for different protocols. 

>
> An empty Policy Rule implies that the rule has been deactivated and the
> associated identifier is available for reuse.

As an alternative, the semantics could be explict create, modify, and delete
commands within the request.

[PTT]
Agreed.

>
> The Policy Rule Response indicates the Policy Rule actually installed and
> the lifetime assigned to it by the Middlebox.

I assume this would have the full content of the rule.

[PTT]
Yes.

> 3) Deactivation Request/Acknowledgement
<snip>
> Open issue: does the Middlebox deactivate all Policy Rules the Agent has
> ever installed, or only those for which it is the most recent installer?
> 4) Policy Rule Audit Request/Response
<snip>
> Open issue: when "ALL" is requested, does the Middlebox return all Policy
> Rules the Agent has ever installed, or only those for which it is the most
> recent installer?

A sort of related issue: Does the middlebox remember all the agents that
have operated on this rule? Can one agent indicate that additional agents
are allowed to modify/audit the rule and/or receive notification?

[PTT]
I had assumed that communication of Policy Rule Identifiers between agents
was achieved by means out of scope of the Midcom protocol, and that the
authority to modify and audit rules was assigned by the policy mechanism
(based on the specific source and destination addresses involved) rather
than agent communication with the Middlebox.  If people are of the view that
the Midcom protocol should support delegation of authority, I'll add the
necessary exchanges.

>
> 1 (a): Policy Rule Request (Agent to Middlebox)
> --------------------------
>
> Specific Parameters: Policy Rule Identifier, Policy Rule, Lifetime,
> Integrity
>
> Policy Rule Identifier:
> An identifier which can be used to correlate further requests involving
this
> rule.  At a minimum, the tuple {Agent Identifier, Middlebox Identifier,
> Policy Rule Identifier) must be unique.  It is probably necessary that the
> Policy Rule Identifier be globally unique so that one Agent can (if given
> the authority) manipulate rules belonging to other Agents.

Alternatively, the Middlebox Identifier could be globally unique, and the
Policy Rule Identifier unique within a given middlebox.

[PTT]
I think you're right on the scope of the Policy Rule Identifier.

Question: Is the Policy Rule identifier determined by the agent or the
middlebox?

[PTT]
It is determined by the agent.  See the detailed parameter descriptions in
the latter part of my original note.

>
> Policy Rule:
> The specific Policy Rule which the Agent is asking to take effect,
specified
> as a set of {Filter, Action} pairs.  This replaces any Policy rule
> previously associated with the same Policy rule Identifier.  An empty
Policy
> Rule implies that the rule has been deactivated and the associated
> identifier is available for reuse.

Again, would explicit create, modify, and delete commands be better? If
creation is implicit, the agent has no way to tell that the rule previously
existed. However, if the policy rule identifier was assigned by the
middlebox, creation would be indicated by some sort of "pick one" wildcard.

[PTT]
I can see the potential problems introduced by inadvertent reuse of a Policy
Rule Identifier already activated by another agent.  Actual rule collision
is sorted out by policy, but reuse of an identifier for a totally unrelated
rule would be undesirable.  Your suggestion that the Middlebox assign the
identifier is probably the easier way to solve the problem.  The other way
is to require the Policy Rule Identifier to include the AgentId as one of
its components.  (I'm assuming an Agent can keep track of the Policy Rules
it has created.)

Based on the requirements, the filter may contain:
    source address
    source transport port
    destination address
    destination transport port
    transport protocol

For firewall pinholes, the action has at least "allow/deny"

For NAT, the action may have
    new source address
    new source transport port
    new destination address
    new destination transport port

[PTT]
I'm going to publish our proposed abstract representation of a Policy Rule
in another note.  Cedric and I are still working through the various
scenarios to validate it.

> 2(a) Middlebox Action Notification (Middlebox to Agent)
> ----------------------------------
>
> Specific parameters: Reason, Policy Rule Identifier (optional), Policy Rul
e
> (optional)
>
> Reason:
> Indicates why the notification was issued.  Possible values are:
>  - Policy Rule modified due to conflict (Policy Rule Identifier and Policy
> Rule must be present)
>  - Policy Rule deactivated due to conflict (Policy Rule Identifier must be
> present)
>  - Policy Rule deactivated due to lifetime expiry (Policy Rule Identifier
> must be present)
>  - ???

In cases where multiple agents are responsible for a rule, would we
need/want to notify the other agents when a rule is changed? If so, we
whould have a "Policy Rule modified by another agent" reason.

[PTT]
"Policy Rule modified by another agent" is implicit in the first two reasons
when generating a Middlebox Action Notification.  Guess I should have made
that clearer in the wording of the reasons.

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