Subject: Re: [midcom] MIDCOM Semantics

From: Paul Sijben <[email-masked]>
Date: Tue, 02 Apr 2002 10:22:49 +0200

Tom,

sorry for not responding to this sooner but your mail must have gotten
lost in the noise. In fact this looks fairly good. I would consider this
to be a good start to the semantics work.

Paul

> Tom-PT Taylor wrote:
> 
> 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)
> 

-- 
Paul Sijben                         Tel:+31 356874774 
Bell Labs - Advanced Technologies   Fax:+31 356875954
Lucent Technologies     (internal) http://voip.nl.lucent.com/~sijben 
Huizen, The Netherlands

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

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 2 Apr 2002 09:20:52 -0500

see embedded comments below

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>
<snip>
> 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.

> associated identifier is available for reuse.

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

>
> 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.

> 3) Deactivation Request/Acknowledgement
<snip>
> 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?

> 1 (a): Policy Rule Request (Agent to Middlebox)
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.

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

> 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.

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

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

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 2 Apr 2002 08:39:30 -0600

see below
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bob Penfield
[snip]

> Question: Is the Policy Rule identifier determined by the agent or the

Hopefully by the agent. This would allow the agent to determine the
identifier through some repeatable algorithm, which would be very useful for
reducing agent state, allowing other agent to refer to the same rule without
sharing information, etc.

[snip]

> whould have a "Policy Rule modified by another agent" reason.

It depends on whether the additional agents know in advance that they are
responsible for the rule.