Subject: [midcom] MIDCOM Semantics

From: "Tom-PT Taylor"<[email-masked]>
Date: Mon, 25 Mar 2002 14:24:49 -0500

Cedric Aoun and I are working on an I-D describing MIDCOM semantics.  What
follows is the part that deals with message contents.  The remainder of the
draft deals with the detailed structure of Policy Rules and shows
application of the messages and detailed structure to the scenarios
documented in draft-ietf-midcom-scenarios-02.txt.

3	Message semantics 

3.1	General assumptions

1. The exchanges are all structured as request/response, to accord with
requirement 2.1.5 (known and stable state).  There are other ways to meet
this requirement, if someone wants to document them.

2. No explicit association startup sequence.  Instead, each party supplies
its credentials in every message it sends.  The Agent's authority is based
on those credentials and the policy available to the Middlebox.

3. There is an ambiguity in the requirements regarding the ability to group
"rulesets", as well as inconsistency in terminologies where rulesets are
used instead of policy rule.  It is assumed that a Policy Rule provides all
of the grouping required.

4. It is assumed in this note that the protocol supports both "all or
nothing" and partial intallation of Policy Rules (see discussion in the next
section), where the choice is made by the Agent.  The partial installation
option may be considered too complex to support, in which case the semantics
will simplify accordingly.

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.

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

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

2) Middlebox Action Notification/Acknowledgement

Asynchronous notification from the Middlebox, indicating what Policy Rule
was affected, if any, what action or event has occurred, and a reason for
the action or event.  Acknowledgement has no additional content.

3) Deactivation Request/Acknowledgement

Request from either peer to deactivate all Policy Rules associated with the
given Agent.  Acknowledgement indicates compliance and has no additional
content.

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
   
Request from the Agent to audit the content of a given Policy Rule or all
rules associated with that Agent, as viewed by the Middlebox.  The response
provides the desired information, possibly in multiple messages.

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?

5) Capability Request/Response

Assuming the possibility that the Middlebox may support differing options,
the request is made by the Agent and the response indicates the supported
Middlebox options.

Open issue: besides the Policy Rule audit, there is also the possibility of
a flow audit, asking about the specifications for active flows which have
been bound to Policy Rules.

3.3	Detailed Message Description

General parameters
------------------

Every message carries the following parameters:

 - Version: the version of the MIDCOM protocol used to encode the message.
 - Source Identifier: the Agent or Middlebox identifier associated with the
accompanying credentials.
 - Credentials: authenticating content.
 - Transaction Identifier: used to correlate requests with their responses.

These are omitted from the following message descriptions for brevity.

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.  

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.

Lifetime:
The desired lifetime of the rule, e.g. in number of seconds from the time of
installation.  The Middlebox deactivates the rule and notifies the Agent if
the lifetime expires.  The Middlebox may autonomously extend the lifetime
when it detects packet activity coming within the scope of the Policy Rule.
Note that such autonomous extension could be undesirable under certain
failure conditions.  If the Policy Rule is empty, Lifetime is set to 0.

Integrity:
This has two values:
(a) The Policy Rule must apply completely or not at all.
(b) Partial installation of the Policy rule is allowed.
Integrity has effect throughout the lifetime of the rule:

·	at the time of processing of the Policy Rule request, it affects the
outcome if conflicting Policy Rules are found

·	subsequently, if any Agent issues a Policy Rule request with a
different Policy Rule Identifier which is found to conflict with this one
and policy finds that this one is of lower priority, Integrity determines
whether it is deactivated or modified.

If a Policy Rule Request causes another Policy Rule to be modified or
deactivated, the Middlebox sends a Middlebox Action Notification message to
the Agent which requested the installation of that rule, as well as sending
a Policy Rule Response to the source of the Policy Rule Request.

1(b) Policy Rule Response (Middlebox to Agent)
-------------------------

Specific parameters: Policy Rule Identifier, Policy Rule, Lifetime, Reason

Policy Rule Identifier:
Policy Rule Identifier as it appeared in the Policy Rule Request.

Policy Rule:
The Policy Rule actually installed.  If partial installation is allowed this
may differ from the Policy Rule in the original request.  If the request was
denied completely this must be empty.

Lifetime:
The rule lifetime actually assigned by the Middlebox.  This may differ from
the lifetime requested, regardless of the value of Integrity in the request.
Changes in lifetime are not reflected in Reason (e.g. a request could be
"accepted", yet lifetime has been modified).  If the Policy Rule is empty,
Lifetime is set to 0.

Reason:
Indicates the reason for the outcome.  Possible values are:
 - accepted
 - Policy Rule modified due to conflict
 - denied due to conflict (returned Policy Rule must be empty)
 - Policy Rule modified due to lack of resources
 - denied due to lack of resources (returned Policy Rule must be empty)
 - denied due to lack of authority (returned Policy Rule must be empty)

2(a) Middlebox Action Notification (Middlebox to Agent)
----------------------------------

Specific parameters: Reason, Policy Rule Identifier (optional), Policy Rule
(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)
 - ???

Policy Rule Identifier:
If present, identifies the Policy Rule affected by the event.

Policy Rule:
If present, indicates the present content of the given Policy Rule.

2(b) Middlebox Action Acknowledgement (Agent to Middlebox)
-------------------------------------

No specific parameters.

3(a) Deactivation Request (either Agent or Middlebox to peer)
-------------------------

No specific parameters.

3(b) Deactivation Acknowledgement (responding peer to requesting Agent or
Middlebox)
---------------------------------

No specific parameters.

4(a) Policy Rule Audit Request (Agent to Middlebox)
------------------------------

Specific parameter: Policy Rule Identifier

Policy Rule Identifier:
The identifier of the specific policy to be audited, or else the special
identifier ALL.  If ALL is specified the request is for an audit of all
Policy Rules installed by the requesting Agent.

4(b) Policy Rule Audit Response (Middlebox to Agent)
-------------------------------

Specific parameters: Sequence Number, Total Count, Policy Rule Identifier,
Policy Rule, Lifetime, Integrity

Each Policy Rule Audit Response message reports the content of one Policy
Rule associated with the Agent.

Sequence Number:
The order of the message in the set of responses, beginning with 1 and
incrementing by 1 for each additional message.

Total Count:
The total number of Policy Rules associated with the Agent.  This may be 0
if no Policy Rules are currently associated with the Agent.

Policy Rule Identifier (optional):
Present unless no Policy Rules are currently associated with the Agent.
Identifies the Policy Rule specified in this message.

Policy Rule (optional):
Present unless no Policy Rules are currently associated with the Agent.
Specifies the Policy Rule as it is known to the Middlebox.

Lifetime (optional):
Present unless no Policy Rules are currently associated with the Agent.
Indicates the remaining lifetime of the Policy Rule at the time of the
response.

Integrity (optional):
Present unless no Policy Rules are currently associated with the Agent.
Indicates whether  the Middlebox deactivate or modify the Policy Rule if a
conflicting rule takes precedence.

5(a) Capability Request (Agent to Middlebox)
-----------------------

Specific parameters: Option List

Option List (optional):
if present, indicates options the Agent proposes to use.  Possible options
are for further study.

5(b) Capability Response (Middlebox to Agent)
-----------------------

Specific parameters: Option List

Option List):
indicates options supported by the Middlebox.  Possible options are for
further study.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)