[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   Middlebox Communications (midcom)
   Internet Draft                                            Tom Taylor
   Document: draft-taylor-midcom-semantics-00.txt       Nortel Networks
   Expires: December 2002                                     June 2002


             Semantics Which The MIDCOM Protocol Must Support


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.


Abstract

   This document is written to aid the process of selecting and
   completing the definition of the MIDCOM protocol, which will operate
   between MIDCOM Agents and Middleboxes such as firewalls and NATs.  It
   describes the semantics which the protocol must support.  These
   semantics are derived from the MIDCOM requirements and the MIDCOM
   usage scenarios which helped to inspire the requirements.

   This is intended to be a working document of the IETF Middlebox
   Communications (MIDCOM) Working Group.


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].

   The notation [X:y] (example [3:2.14]) denotes section y of reference
   X.

Taylor                 Expires - December 2002               [Page 1]

                           MIDCOM Semantics                  June 2002



   In message flows, A->M indicates information passed from the MIDCOM
   Agent to the Middlebox.  M->A indicates information passed from the
   Middlebox to the MIDCOM Agent.


Table of Contents

   1. Introduction...................................................3
      1.1 Terminology................................................3
      1.2 Open Issues................................................3
   2. Semantic Implications Of The MIDCOM Framework..................5
      2.1 Agent Identity.............................................5
      2.2 MIDCOM Session.............................................5
      2.3 Filters, Policy Actions, Policy Rules......................5
      2.4 MIDCOM Scenarios...........................................6
      2.5 MIDCOM Timers.............................................10
   3. Semantic Implications Of The MIDCOM Requirements..............10
   4. MIDCOM Semantics: Pulling It All Together.....................15
      4.1 MIDCOM Session Initiation.................................15
      4.2 Policy Rule Installation..................................16
      4.3 Rule Delete...............................................17
      4.4 Rule Reset................................................17
      4.5 Rule Query................................................18
      4.6 Policy Rule Bundling......................................19
      4.7 Bundle Delete.............................................20
      4.8 Autonomous Rule Deactivation..............................20
      4.9 Middlebox Status..........................................21
      4.10 Session Audit............................................21
      4.11 Session Termination......................................22
   5. Formal Syntax.................................................23
   Security Considerations..........................................24
   References.......................................................24
   Acknowledgments..................................................24
   Author's Addresses...............................................24
















Taylor                 Expires - December 2002               [Page 2]

                           MIDCOM Semantics                  June 2002


1. Introduction

   This document presents the semantics which must be supported by the
   MIDCOM protocol.  The purpose and framework within which this
   protocol will operate are described in [3].  The detailed
   requirements which the protocol must satisfy are described in [4].

   This document first reviews the framework and requirements and draws
   out their implications for the semantics of the protocol.  It then
   summarizes the results as a series of possible information flows
   between the MIDCOM Agent and Middlebox and associated behaviour.
   Finally it specifies the semantics formally using ABNF.

1.1 Terminology

   "MIDCOM Agent" and "Middlebox" have the meanings given in [3].

   Terminology is inconsistent between the framework and the
   requirements documents.  This document assumes that the term "Policy
   Rule" defined in [3] is the same concept as "ruleset" in [4].

1.2 Open Issues

   The ideas in this initial version of this document were originally
   presented to the MIDCOM E-mail list for discussion.  A number of
   issues were raised during that discussion, and others have been
   identified during the writing of this document.

1.2.1 Support for failover between Agents

   The requirements [4:2.2.7] include the ability for more than one
   Agent to work on the same ruleset.  This requirement was inserted at
   least in part to support failover between Agents.  The open question
   is whether failover must be supported on a per-session basis or on a
   per-ruleset basis.  It is still necessary to share rulesets because
   of the possibility of load sharing between Agents, as one example.

1.2.2 Meaning Of multiple filter tuples in the same Policy Rule

   [3] allows for multiple filter tuples in the same Policy Rule, but
   does not say what this means.  It is proposed that the intent be that
   the tuples are combined by a Boolean AND.

1.2.3 Need To Support Address Ranges Within Filters

   Is there such a need, and how should ranges be expressed if they are
   required?




Taylor                 Expires - December 2002               [Page 3]

                           MIDCOM Semantics                  June 2002


1.2.4 Meaning of "deterministic result"

   List discussion did not conclude on what a deterministic result
   [4:2.1.12] would mean in the case of conflicting rules.  The basic
   problem is this: current NAT and firewall behaviour is based on
   queuing a set of rules and evaluating successive members of the queue
   for applicability on a per-packet basis.  As a result, the Middlebox
   is unaware if conflict amongst its rules exists: the first applicable
   rule prevails.

   From the point of view of the Middlebox, its behaviour is indeed
   deterministic in the presence of conflict.  However, an individual
   MIDCOM Agent can never know in advance whether a rule it is adding
   will have the effect it desires.

   There are three possible resolutions to this dilemma.  The first is
   to say that it is sufficient for outcomes to be deterministic from
   the point of view of the Middlebox.  The second is to require the
   Middlebox to perform an analysis of its installed rules whenever a
   rule is added, changed, or deleted, and characterize the packets for
   which each Agent's rules will fail to apply.  The final possibility
   is for the Agent to be able to learn the complete set of active rules
   so it can apply its own analysis.

   Requiring additional analytical capability on the Middlebox may not
   be practical, on grounds of device cost.  Giving each Agent access to
   the full set of active rules will raise privacy concerns.  Hence the
   only viable alternative may be to say that requirement [4:2.1.12] is
   satisfied if a particular sequence of rules always has the same
   result at the Middlebox, even if that result is not predictable by an
   Agent.  This conclusion needs to be confirmed by the MIDCOM Working
   Group.

1.2.5 Support For Symmetric Mapping

   Is there a requirement to force a mapping for bidirectional flows
   such that the mapped address and port are identical for the outgoimg
   and the incoming flow?

1.2.6 Meaning Of End Of Session

   Does the ending of a MIDCOM session uninstall all of the Policy Rules
   installed during that session?

1.2.7 Indefinite Policy Rule Life

   Related to the previous question: should the protocol allow
   installation of rules which never expire?  This would be especially
   useful to open a permanent pinhole for incoming calls.


Taylor                 Expires - December 2002               [Page 4]

                           MIDCOM Semantics                  June 2002


1.2.8 Scope Of Queries

   As the scenarios illustrate, it is necessary that the Agent be
   allowed to query installed rules, to determine existing address
   mappings.  The question is whether the Agent is allowed to learn of
   rules which were not installed within its MIDCOM session.  The answer
   is propobably that the scope of a query is determined by local
   policy.


2. Semantic Implications Of The MIDCOM Framework

2.1 Agent Identity

   The framework speaks of the ability for a MIDCOM Policy Decision
   Point to revoke authorization for a MIDCOM Agent [3:2.9], and of
   MIDCOM Agent profiles [3:2.11].  For these concepts to be
   enforceable, the MIDCOM Agent must be associated with an identifier
   which must be presented at least at the start of a MIDCOM session and
   which must be associated with its profile.

2.2 MIDCOM Session

   [3:2.12] speaks of the MIDCOM session.  [3:4] provides a requirement
   for a formal information exchange to start up or to terminate a
   MIDCOM session.  Start-up is initiated by the MIDCOM Agent, while
   either the Agent or Middlebox may terminate the session.  This
   requirement raises the possibility of using a session identifier in
   subsequent messages to indicate the session to which each is related.
   This is not a hard requirement: the Agent identifier could be used
   instead to represent the association between the Agent and the
   Middlebox.  The advantages of separately identifying the session are
   that:

     .  more than one session could be supported between the same Agent-
        Middlebox pair;

     .  it may be easier to hand off a session than an Agent identity in
        the case of failover between Agents.

2.3 Filters, Policy Actions, Policy Rules

   [3:2.15] defines a Policy Rule as a combination of one or more
   filters and an action.  The basic idea is that packets matching the
   filter have the action applied to them.

   By redistributing the semantic content of the Policy Rule between the
   filter and action portions, it is possible to come up with a unified
   semantic representation which has the same form for all the


Taylor                 Expires - December 2002               [Page 5]

                           MIDCOM Semantics                  June 2002


   applications intended for the MIDCOM protocol.  The filter becomes
   more complex, but the actions reduce to "permit" and "deny" only.
   (Secondary action qualifiers such as "log", "alarm", and "ignore" may
   also be needed.)

   The proposed representation of the filter part has the form:

     {source address, mapped address, destination address, protocol}

   Each of the three addresses has the same sub-structure, except that
   the mapped address has additional components (see section 2.4 second
   scenario).  The semantic components of an address are:

         .  address type (IPv4, IPv6, tunnel ID, ...)

         .  address space identifier.  The initial address space
            identifiers "public" and "private" are defined to support
            the MIDCOM applicability statement [3:9].

         .  address value.  For IP addresses, this includes a port
            component.  It is an open issue, whether the MIDCOM
            protocol should be able to express address ranges.

   The address value in any address may be the wildcard "ANY".  This
   allows rule setup in circumstances where an endpoint is not yet known
   or mapping is inapplicable or irrelevant.  In Policy Rules sent from
   the Agent to the Middlebox, the mapped address value may also be the
   wildcard "CHOOSE", indicating that a mapping is desired.

   Note that this definition of a filter is unidirectional.  Where the
   MIDCOM protocol needs to express requests applying to both directions
   of a bidirectional flow, additional semantic elements will have to be
   added.

   The possibility of multiple filter tuples in one Policy Rule is
   problematic: the semantics need definition.  The Boolean OR is not
   needed, since it can be achieved by having multiple rules, each with
   one filter tuple and all with the same action.  It is therefore
   proposed that if multiple filter tuples are present within the same
   Policy Rule they are to be ANDed.  Where the mapped address value is
   "CHOOSE", an additional semantic is proposed: that the requested
   mapping shall be the same in each filter term, so that the overall
   meaning is that the mapping applies to an ANDed filter condition on
   the flow endpoints.

2.4 MIDCOM Scenarios

   [3:7] presents three scenarios for the operation of the MIDCOM
   protocol in mid-session.


Taylor                 Expires - December 2002               [Page 6]

                           MIDCOM Semantics                  June 2002



Scenario [3:7.1], firewall control

   The messaging sequence includes three MIDCOM operations:

     a) A->M: Open up the firewall to outgoing flows of RTP and RTCP.
        M->A: OK.

     b) A->M: Open up the firewall to incoming flows of RTP and RTCP.
        M->A: OK.

     c) A->M: Close firewall to the previously enabled incoming and
        outgoing flows.
        M->A: OK.

   Operations a) and b) have the semantics of Policy Rule Activation.
   One Policy Rule is set for RTP, a second for RTCP, in each case.
   Operation c) uninstalls the four rules installed by a) and b).
   Middlebox return codes are discussed in section 3 below.

Scenario [3:7.2], NAPT control

   The messaging sequence includes the following MIDCOM operations:

      a) A->M: Query Port-BIND for mapped address (assumed known), port
         5060.
         M->A: returns Port-BIND.

      b) A->M: Query NAT session descriptor for SIP flow from external
         to private endpoint.
         M->A: returns session descriptor.

      c) A->M: Create NAT sessions for outgoing flows of RTP and RTCP.
         Link sessions to SIP control session.
         M->A: returns session descriptor.

      d) A->M: Create Port-BINDs for incoming RTP, RTCP flows (adjacent
         ports).
         M->A: returns Port-BINDs.

      e) A->M: Create NAT session for incoming flows of RTP and RTCP
         (adjacent ports).  Link session to SIP control session.
         M->A: returns session descriptor.

      f) A->M: end session bundle.
         M->A: OK.

   Operations a) and b) allow the Agent to determine the private address
   of the internal endpoint.  In terms of the filter semantics defined


Taylor                 Expires - December 2002               [Page 7]

                           MIDCOM Semantics                  June 2002


   above, these operations are equivalent to a single query requesting
   the return of any active Policy Rules matching a filter of the form:

     {external address, mapped address + port 5060, ANY, ANY}

   Note the wildcarded protocol in this expression.  Presumably the
   Middlebox will consult with the MIDCOM PDP to determine the permitted
   scope of the query.  The returned Policy Rule (probably only one in
   this example) should be associated with an identifier so that it can
   be referred to in later operations.  Issue: should queries return
   rules set by administration?  In general, what is the relationship of
   query scope to the MIDCOM session within which the query is made?  Is
   this a local policy issue?

   Operation c) is similar to operation a) in the previous case, except
   that operation c) requires a further transaction to create a session
   bundle.  The Agent provides the identifier of the rule returned in
   the query (operations a) and b)) and the identifiers of the new rules
   just installed, and asks that they be grouped.  The Middlebox returns
   a group identifier.

   Operations d) and e) are semantically equivalent to activating a
   single Policy Rule, provided that additional semantics are present to
   indicate that adjacent ports are required.  Accordingly, the semantic
   description of the <mapped address> part of the filter as presented
   in section 2.3 is augmented as follows.  If the address type is IPv4
   or IPv6 and the address value is "CHOOSE", then the following
   additional components may be present:

         .  port count.  Requests mappings for this number of
            consecutive ports.  If port count is absent, 1 port is
            requested.

         .  parity.  Requests that the first port of the series has the
            given parity.  If parity is absent the first port may be of
            either parity.

   With these additions, operations d) and e) are equivalent to a
   request to install a rule of the form:

     filter={external endpoint address,
      {type=IPv4, space="public", value="CHOOSE", count=2, parity=even},
      internal endpoint address + port, UDP},
     action="permit"

   The port part of the external endpoint address has content 'ANY',
   since in general the source port for RTP/RTCP transmission will be
   unknown.  The internal endpoint address contains a port value for the



Taylor                 Expires - December 2002               [Page 8]

                           MIDCOM Semantics                  June 2002


   receiving RTP port.  The Middlebox MUST assume that the internal
   endpoint receives RTCP at the next higher port.

   The Middlebox returns the same rule with the mapped address value
   assigned.  An additional information exchange groups the with the
   others in the same session bundle.

   Operation f) requires an information exchange where the Agent
   supplies the session bundle identifier and requests deactivation of
   all rules in the session bundle.

Scenario [3:7.3]: Middlebox implementing NAPT and firewall

   The messaging sequence includes the following MIDCOM operations:

     a) A->M: Query Port-BIND for mapped address (assumed known), port
        5060.
        M->A: returns Port-BIND.

     b) A->M: Query NAT session descriptor for SIP flow from external to
        private endpoint.
        M->A: returns session descriptor.

     c) A->M: Create NAT sessions for outgoing flows of RTP and RTCP.
        Link sessions to SIP control session.
        M->A: returns session descriptor.

     d) A->M: Open up the firewall to outgoing flows of RTP and RTCP.
        M->A: OK.

     e) A->M: Create Port-BINDs for incoming RTP, RTCP flows (adjacent
        ports).
        M->A: returns Port-BINDs.

     f) A->M: Create NAT session for incoming flows of RTP and RTCP.
        Link session to SIP control session.
        M->A: returns session descriptor.

     g) A->M: Open up the firewall to incoming flows of RTP and RTCP.
        M->A: OK.

     h) A->M: end NAPT session bundle.
        M->A: OK.

     i) A->M: Close firewall to the previously enabled incoming and
        outgoing flows.
        M->A: OK.

   a) and b) are the same as in the previous case.


Taylor                 Expires - December 2002               [Page 9]

                           MIDCOM Semantics                  June 2002



   Using the filter semantics described in section 2.3, the NAPT
   operations in c) and the firewall operations in d) are both implied
   by the same Policy Rules.  For example, the outgoing RTP flow is
   enabled by specifying a Policy Rule of the form:

     filter={ internal endpoint address (port = ANY),
       {type=IPv4, space="public", value="CHOOSE"},
       external endpoint address + port, UDP},
     action="permit"

   In a similar way, f) and g) are both accomplished by the same
   information exchange as for operations d) and e) in the previous
   case.

   Finally, h) and i) are semantically equivalent to deactivation of the
   bundle of rules created in the previous steps.

Summary Of Observations

   In summary, the three scenarios have demonstrated the need for
   information exchanges supporting querying of active rules against a
   pattern, activating Policy Rules (generally with wildcards), creating
   bundles of Policy rules, deactivating individual policy rules, and
   deactivating bundles of Policy Rules.  In addition, semantic content
   had to be added to the mapped address portion of the filter to
   express requirements for consecutive port numbers and their parity.

2.5 MIDCOM Timers

   [3:8.3] talks about the potential usefulness of timers in the MIDCOM
   protocol, to facilitate resource cleanup.  This raises the question
   of whether the timer values should be visible to the Agent.  Given
   that their intended use is to compensate for Agent outages, an
   information exchange prior to timer expiry seems indicated.


3. Semantic Implications Of The MIDCOM Requirements

   This section reviews the semantic implications of the requirements
   documented in [4].

[4:2.1.1]: authorization.

   This requirement implies the need for credentials in any request the
   Agent sends to the Middlebox, sufficient to allow the latter to
   determine the Agent's scope of authority.




Taylor                 Expires - December 2002              [Page 10]

                           MIDCOM Semantics                  June 2002


[4:2.1.2]: one MIDCOM Agent dealing with multiple Middleboxes

   This implies that a parameter must be present in each message coming
   from a Middlebox, identifying that Middlebox uniquely.  The session
   identifier discussed in section 2.2 might serve that purpose, beyond
   the initial setup of the session.

[4:2.1.3]: one Middlebox dealing with multiple MIDCOM Agents

   Similarly, this implies that a parameter must be present in each
   message coming from a MIDCOM Agent, identifying that MIDCOM Agent
   instance uniquely.  MIDCOM Agent identifiers were discussed in
   section 2.1.  Again, the session identifier may serve the purpose
   after initial session setup.

[4:2.1.4]: deterministic Middlebox behaviour when multiple MIDCOM
   Agents interact with it.

   This implies several points:

         .  well-defined Middlebox behaviour when it processes
            requests, particularly when conflicts are encountered;

         .  the behavioural equivalent of mutual exclusion, such that
            requests affecting the same resources (for example,
            involving overlapping filter specifications) are required
            to be processed serially;

         .  requests can be of sufficiently large extent that the Agent
            can accomplish what it needs in a single request, thus
            avoiding deadlock.

[4:2.1.5]: known and stable state

   The explanation of this requirement suggests that a request
   identifier parameter is needed for each request, that each request
   must have a reply, and that the reply must include the request
   identifier parameter as well as the result of the request.

   The requirement also appears to imply the need for a MIDCOM Agent to
   be able to audit the Middlebox state as it relates to requests made
   in the past by that Agent.  As an optimization, the audit request may
   include parameters limiting the scope of the audit.  The response
   includes a state parameter expressed as a sequence of Policy Rules.
   In view of the potential volume of information, provision should be
   made for segmentation of the response.

   Auditing can be seen as an additional use of the query exchange
   documented as part of the scenario analysis in section 2.4.


Taylor                 Expires - December 2002              [Page 11]

                           MIDCOM Semantics                  June 2002



[4:2.1.6]: Middlebox reporting status

   This implies a a need for a Middlebox to send autonomous
   notifications to a MIDCOM Agent.  It is assumed that [4:2.1.6]
   relates to the operational status of the Middlebox as a whole, and
   possibly also the state it retains on behalf of a given Agent.
   Accordingly, the status notification should be able to express the
   following situations:
         .  Middlebox going out of service
         .  Middlebox returned to service, having retained all state
            (i.e. sessions, Policy Rules and associated timers)
         .  Middlebox returned to service, state information lost or
            stale
         .  Middlebox congested.

[4:2.1.7]: autonomous reporting of conditions and autonomous actions

   The main thrust of the explanation of this requirement is that the
   Middlebox be able to report autonomously actions taken with regard to
   particular Policy Rules.  The information passed must therefore
   include the Policy Rule identifier(s), the action taken, and the
   reason for the action.

[4:2.1.8]: mutual authentication

   This requirement bears upon session startup in the first place, with
   proper follow-up to maintain the integrity of the session in
   subsequent messages.

[4:2.1.9]: either entity can terminate a session

   This implies a formal exchange to terminate a session.  Issue: does
   the end of a session uninstall all Policy Rules installed during that
   session?

[4:2.1.10]: MIDCOM Agent can determine success or failure of a
   request

   This implies that every request must have a reply, and the reply must
   indicate the outcome of the request.

[4:2.1.11]: version interworking

   There seems to be agreement to include protocol version in each
   message, governing the content of that message.  It is possible the
   initial message of a session should include an additional parameter
   listing the versions supported by the originator.



Taylor                 Expires - December 2002              [Page 12]

                           MIDCOM Semantics                  June 2002


   If the protocol has identifiable options the initial message of the
   session in each direction should include a parameter indicating what
   options the message sender supports.

[4:2.1.12]: deterministic behaviour for overlapping rulesets

   There is some dispute over what deterministic means in this case.
   The issue is described at length in section 1.2.4 above.  In keeping
   with existing implementation, we postulate an aggregate model of
   Middlebox operation as follows:

      a) rules are retained in their original form (including mappings)
         rather than aggregated;

      b) as each packet passes through the Middlebox, it is checked
         against the filter portion of each active rule in turn;

      c) if a match is found, the action associated with that rule is
         applied;

      d) if no match is found, the default action set by the Middlebox
         administrator is applied;

      e) rules are evaluated in the order in which they were installed
         (first-come, first-served).

   For a given sequence of rules this always gives the same per-packet
   outcomes.  In that sense it is deterministic, even if the Agent
   installing a given rule cannot know in advance what the effect of
   that rule will be unless it knows the complete sequence of rules
   installed at the Middlebox.

[4:2.2.1]: extensibility

   It would be possible to add content to the semantic description as a
   placeholder for new material, but there doesn't seem to be much point
   in doing so.

[4:2.2.2]: control of multiple functions

   The semantic content of firewall and NAT/NAPT control have been
   captured in the Policy Rule description in section 2.3.  This
   formulation may also be applicable to other Middlebox types.

[4:2.2.3]: ruleset groups

   The need for information exchanges to create such groups (referred to
   as session bundles) has been documented above in connection with the
   scenarios.


Taylor                 Expires - December 2002              [Page 13]

                           MIDCOM Semantics                  June 2002



[4:2.2.4]: ruleset lifetime extension

   This implies a possible need for several information exchanges:

         .  allowing the Agent to associate a lifetime (and perhaps a
            grace period) with a Policy rule at the time of
            installation

         .  allowing the Agent to audit the remaining lifetime for a
            Policy Rule (most reasonably as a parameter of a general
            Policy Rule audit capability)

         .  allowing the Middlebox to indicate when a Policy Rule is
            about to expire

         .  allowing the Agent to reset the remaining lifetime.

[4:2.2.5]: action on unknown attributes

   This requires a sub-field within certain attributes indicating
   whether the attribute can be ignored if not understood or stops the
   request from being processed.  It also implies that the
   responses to individual requests must identify components of the
   request which have caused failure or which have been ignored.

[4:2.2.6]: failure reasons

   A failure reason element must be a potential part of responses.
   Possible failure reasons are listed in the next section.

[4:2.2.7]: multiple authorised Agents working on the same ruleset

   This implies a requirement either that Policy Rule identifiers are
   unique across MIDCOM sessions or else that they are always associated
   with a specific session and the session identifier has to be provided
   in all messages dealing with Policy Rules.  The latter is probably
   the better approach, because it supports the idea that the
   termination of a MIDCOM session uninstalls all rules associated with
   that session.  Of course, all of this discussion masks a set of
   requirements on operations outside of the MIDCOM protocol: sharing of
   Policy Rule and MIDCOM session identifiers between Agents, and
   authorization of one Agent to intervene in a session set up by
   another one.

[4:2.2.8]: transport of filtering rules

   The filters of this semantic analysis are not, of course, the
   concrete expression of filters in the protocol itself.  This analysis


Taylor                 Expires - December 2002              [Page 14]

                           MIDCOM Semantics                  June 2002


   indicates within which information exchanges filters will have to be
   carried.

[4:2.2.9]: matching parity ("oddity")

   This requirement has already been recognized and incorporated in the
   semantic representation of a Policy Rule filter in section 2.4.  See
   the discussion of the [3:7.2] scenario.

[4:2.2.10]: ranges of ports

   Also covered in section 2.4.  The requirement extends beyond RTP/RTCP
   pairs to sequences of such pairs required for layered encoding.

[4:2.2.11]: contradictory actions for sub-filters

   Assuming that the contradictory actions are represented by separate
   Policy Rules, and assuming the model of Middlebox operation described
   in the discussion of requirement [4:2.1.12], this requirement is met
   provided that the rule with the sub-filter is installed before the
   main rule.  This is an operational requirement given semantics
   already defined.

Requirements For Security

   The security-related requirements postulated in [4:2.3] will have
   semantic consequences, but the details depend on the chosen
   mechanisms.


4. MIDCOM Semantics: Pulling It All Together

   This section describes the required MIDCOM information exchanges in
   detail.  The exchanges shown here will not necessarily map one-to-one
   into the messages of the MIDCOM protocol which realize them.

4.1 MIDCOM Session Initiation

   A->M: Session Initiate Request
   M->A: Session Initiate Answer

   The Session Initiate Request initiates an association between a
   MIDCOM Agent and a Middlebox.  As required by [3:4], this is always
   sent by the Agent.  Required parameters include:
      .  the Agent identifier,
      .  authenticating information,
      .  MIDCOM protocol version information, and
      .  information on MIDCOM extensions supported by the Agent.



Taylor                 Expires - December 2002              [Page 15]

                           MIDCOM Semantics                  June 2002


   The Session Initiate Answer indicates the Middlebox acceptance or
   rejection of the proposed session.  It must contain the following
   information:

      .  the Middlebox identifier,
      .  authenticating information
      .  MIDCOM protocol version information, and
      .  result indicator.  Possible results are "successful", "not
         authorized", "too busy", "version not supported", and "request
         error".  The latter result covers syntax errors, protocol
         errors, and unrecognized elements.

   If the request was successful, the response must also contain:

      .  a MIDCOM session identifier unique at the Middlebox, and
      .  information on MIDCOM extensions supported by the Middlebox.

4.2 Policy Rule Installation

   A->M: Rule Install Request
   M->A: Rule Install Answer

   The Rule Install Request is a request to the Middlebox to add the
   rule presented in the request.  It is assumed that the Middlebox
   implements the aggregate model of rule application described in the
   discussion of requirement [4:2.1.12] in section 3.

   The Rule Install Request must contain the following information:

     .  Agent identifier
     .  authenticating information
     .  MIDCOM session identifier
     .  a Policy Rule identifier unique to the session
     .  the Policy Rule itself.  The content of the Policy Rule has been
        discussed in sections 2.3 and 2.4 above, and is summarized
        formally in section 5.
     .  requested rule lifetime.  Issue: should the range of possible
        values include a value for "forever", which means that the rule
        could outlast the session?

   Upon receiving a Rule Install Request, the Middlebox must first
   determine whether the requesting Agent has the authority to make this
   request, taking into account the filter(s) specified within the rule.
   If the mapped address component of the filter(s) contains CHOOSE
   elements, the Middlebox must if possible make concrete address and/or
   port assignments to these elements.  In any event it must return a
   Rule Install Answer.

   The Rule Install Answer must contain the following information:


Taylor                 Expires - December 2002              [Page 16]

                           MIDCOM Semantics                  June 2002



     .  Middlebox identifier
     .  authenticating information
     .  MIDCOM session identifier, copied from the request
     .  the Policy Rule identifier, copied from the request
     .  a result indicator.  Possible results are "successful", "not
        authorized", "too busy", "out of resources", or "request
        error".
     .  if successfully installed, the Policy Rule itself, with any
        CHOOSE components replaced by actual assignments.  If multiple
        ports were requested, the response provides the first (lowest-
        numbered) port of the assigned sequence and echoes back the
        number of requested (and assigned) ports.
     .  if the rule was successfully installed, the granted rule
        lifetime.

4.3 Rule Delete

   A->M: Rule Delete Request
   M->A: Rule Delete Answer

   The Rule Delete Request asks the Middlebox to uninstall the indicated
   Policy Rule.  The requesting Agent may ask for deletion of a rule
   created in a session different from its own.  It is a matter of local
   policy, whether such a request will be granted.  It is possible to
   delete rules individually even when they are contained in a bundle;
   deletion automatically removes the Policy Rule identifier from the
   bundle.  The Rule Delete Request must contain the following
   information:

     .  Agent identifier
     .  authenticating information
     .  session identifier of the MIDCOM session in which the Policy
        Rule was created
     .  Policy Rule identifier of the rule to be uninstalled.

   The Middlebox responds with a Rule Delete Answer.  This must contain
   the following information:

     .  Middlebox identifier
     .  authenticating information
     .  MIDCOM session identifier, copied from the request
     .  the Policy Rule identifier, copied from the request
     .  a result indicator.  Possible results are "successful", "not
        authorized", "too busy", or "request error".

4.4 Rule Reset

   A->M: Rule Reset Request


Taylor                 Expires - December 2002              [Page 17]

                           MIDCOM Semantics                  June 2002


   M->A: Rule Reset Answer

   The Rule Reset Request asks the Middlebox to rest the remaining
   lifetime of the indicated Policy Rule.  The requesting Agent may ask
   for reset of a rule created in a session different from its own.  It
   is a matter of local policy, whether such a request will be granted.
   The Rule Reset Request must contain the following information:

     .  Agent identifier
     .  authenticating information
     .  session identifier of the MIDCOM session in which the Policy
        Rule was created
     .  Policy Rule identifier of the rule to be reset
     .  Requested new lifetime

   The Middlebox responds with a Rule Reset Answer.  This must contain
   the following information:

     .  Middlebox identifier
     .  authenticating information
     .  MIDCOM session identifier, copied from the request
     .  the Policy Rule identifier, copied from the request
     .  a result indicator.  Possible results are "successful", "not
        authorized", "too busy", or "request error"
     .  if the request was successful, the new lifetime granted to the
        rule.

4.5 Rule Query

   A->M: Rule Query Request
   M->A: Rule Query Answer

   The Rule Query Request is used to determine installed rules matching
   a specific pattern.  The permitted scope of the query is assumed to
   be a matter of local policy, although an issue has been raised about
   this (issue 1.2.8).  The Rule Query Request must contain the
   following information:

     .  Agent identifier
     .  authenticating information
     .  MIDCOM session identifier
     .  a filter expression of the same form as that permitted in a
        Policy Rule, except that within the mapped address component
        CHOOSE wildcards are not permitted.

   The Middlebox must respond with a Rule Query Answer.  The Rule Query
   Answer must contain the following information:

     .  Middlebox identifier


Taylor                 Expires - December 2002              [Page 18]

                           MIDCOM Semantics                  June 2002


     .  authenticating information
     .  MIDCOM session identifier, copied from the request
     .  a result indicator.  Possible results are "successful", "not
        authorized", "too busy", or "request error".
     .  zero or more Policy Rules.  The reported Policy Rules are
        restricted to those which local policy permits the Agent to
        know about.  A Policy Rule is reported if its filter matches or
        overlaps the given filter.  "Overlap" is defined as a condition
        where for the filters being compared each of the source
        endpoint address, mapped address, destination endpoint address,
        and protocol have a non-empty intersection.

   For each reported Policy Rule, the Middlebox must also report

     .  remaining lifetime
     .  if allowed by local policy, the Policy Rule identifier and the
        session identifier for the MIDCOM session in which the Policy
        Rule was created.

4.6 Policy Rule Bundling

   A->M: Rule Bundle Request
   M->A: Rule Bundle Answer

   The Rule Bundle Request asks that a set of Policy Rules created
   within the same session be bundled together to share a common fate.
   The information required in the request is:

     .  Agent identifier
     .  authenticating information
     .  MIDCOM session identifier
     .  bundle identifier, unique within the MIDCOM session.  If the
        bundle identifier does not already exist, this request has the
        semantics of bundle creation; otherwise it implies addition of
        the listed Policy Rule(s) to the existing bundle.
     .  one or more Policy Rule identifiers, of Policy Rules which have
        been installed within this MIDCOM session.

   The Middlebox must respond with the Rule Bundle Answer.  This must
   contain the following information:

     .  Middlebox identifier
     .  authenticating information
     .  MIDCOM session identifier, copied from the request
     .  a result indicator.  Possible results are "successful", "not
        authorized", "too busy", or "request error".

   If the request is successful, the following additional information
   must be provided:


Taylor                 Expires - December 2002              [Page 19]

                           MIDCOM Semantics                  June 2002



     .  the bundle identifier
     .  the complete list of all Policy Rule identifiers in the bundle.

4.7 Bundle Delete

   A->M: Bundle Delete Request
   M->A: Bundle Delete Answer

   The Bundle Delete Request asks the Middlebox to uninstall the
   indicated bundle.  The requesting Agent may ask for deletion of a
   bundle created in a session different from its own.  It is a matter
   of local policy, whether such a request will be granted.  The Bundle
   Delete Request must contain the following information:

     .  Agent identifier
     .  authenticating information
     .  session identifier of the MIDCOM session in which the bundle was
        created
     .  bundle identifier of the bundle to be uninstalled.

   The Middlebox responds with a Bundle Delete Answer.  This must
   contain the following information:

     .  Middlebox identifier
     .  authenticating information
     .  MIDCOM session identifier, copied from the request
     .  the bundle identifier, copied from the request
     .  a result indicator.  Possible results are "successful", "not
        authorized", "too busy", or "request error".

4.8 Autonomous Rule Deactivation

   M->A: Rule Removal Notification
   A->M: Rule Removal Acknowledgement

   The Rule Removal Notification is issued by the Middlebox when a rule
   is removed for any reason other than a request from the Agent that
   created it.  The notification must contain the following information:

     .  Middlebox identifier
     .  authenticating information
     .  MIDCOM session identifier of the session in which the rule was
        created
     .  Policy Rule identifier of the uninstalled rule
     .  Reason information.  Possible reasons may include lifetime
        expiry, removal by other authorized entity, change in local
        policy, or Middlebox problem.



Taylor                 Expires - December 2002              [Page 20]

                           MIDCOM Semantics                  June 2002


   The Agent must respond with a Rule Removal Acknowledgement.  This
   must contain the following information:

     .  Agent identifier
     .  authenticating information
     .  MIDCOM session identifier copied from the notification
     .  Policy Rule identifier copied from the notification.

4.9 Middlebox Status

   M->A: Middlebox Status Notification
   A->M: Middlebox Status Acknowledgement

   The Middlebox Status Notification is sent to advise of a material
   change in Middlebox status.  The notification must contain the
   following information:

     .  Middlebox identifier
     .  authenticating information
     .  MIDCOM session identifier of the MIDCOM session the Middlebox
        believes is in progress with the target agent
     .  status change information.  Possible changes include pending
        shutdown, return to service with no loss of information, return
        to service with loss of Policy Rule state, congestion onset,
        end of congested condition.
     .  for pending shutdown, the time remaining until shutdown.

   A notification of congestion onset indicates that during the
   congested period the Middlebox may reject requests because it is
   overloaded.

   The Agent responds with a Middlebox Status Acknowledgement.  This
   must contain the following information:

     .  Agent identifier
     .  authenticating information
     .  MIDCOM session identifier copied from the notification.

4.10 Session Audit

   A->M: Session Audit Request
   M->A: Session Audit Answer

   The Session Audit Request asks for information on all Policy Rules
   and bundles installed in the given session.  An Agent other than the
   Agent which created the session may issue this request (e.g. to take
   over from a failed Agent).  Local policy at the Middlebox governs the
   response.  The request must contain:



Taylor                 Expires - December 2002              [Page 21]

                           MIDCOM Semantics                  June 2002


     .  Agent identifier
     .  authenticating information
     .  session identifier of the MIDCOM session being audited.

   The Session Audit Answer contains the following information:

     .  Middlebox identifier
     .  authenticating information
     .  MIDCOM session identifier copied from the request
     .  the Policy Rule identifier, Policy Rule itself, and remaining
        lifetime of each Policy Rule installed within the session
     .  the bundle identifier and list of Policy Rule identifiers for
        each bundle created within the session.

   It is particularly likely that the actual implementation of the
   Session Audit Answer within the protocol uses multiple messages.

4.11 Session Termination

   A->M or M->A: Session Termination Request
   M->A or A->M: Session Termination Answer

   The Session Termination Request asks that the peer delete the MIDCOM
   session and consider all Policy Rules installed in the session to be
   deleted.  Issue, previously raised: can persistent rules be defined
   that will outlast a session?  This request can be issued by an Agent
   other than the Agent which created the session; local policy at the
   Middlebox determines whether it will be acted on in this case.  The
   request must contain the following information:

     .  Requestor identifier
     .  autheticating information
     .  session identifier of the session to be terminated.

   If a valid request is issued by the Agent which created the session,
   the Middlebox must honour and acknowledge it.  If the request is
   issued by the Middlebox, the Agent may either accept or refuse it.
   (The Middlebox has a definitive means of halting a session by issuing
   a notification of shutdown if it must do so.)  The  returned Session
   Termination Answer must contain the following information:

     .  Responder identifier
     .  authenticating information
     .  session identifier copied from the request
     .  result information.  Possible results include success, refused,
        not authorized (see below), too busy (Middlebox only), or
        request error.




Taylor                 Expires - December 2002              [Page 22]

                           MIDCOM Semantics                  June 2002


5. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [5].  In keeping with the fact
   that this is a semantic specification only, the specification
   contains no literals.

     request = sessionInitiateReq / ruleInstallReq / ruleDeleteReq /
               ruleResetReq /ruleQueryReq / ruleBundleReq /
               bundleDeleteReq / ruleRemovalNotif / mbStatusNotif /
               sessionAuditReq / sessionTerminationReq

     response = sessionInitiateAns / ruleInstallAns / ruleDeleteAns /
               ruleResetAns /ruleQueryAns / ruleBundleAns /
               bundleDeleteAns / ruleRemovalAck / mbStatusAck /
               sessionAuditAns / sessionTerminationAns

     [ ... to be completed after discussion ]

     policyRule = 1*filter action  ; filters are ANDed

     filter = source mapped destination protocol

     source = addressTuple

     mapped = (addressTuple / mapRequest) [portCount] [parity]
     ; mapRequest may only be present in Rule Install Request

     destination = addressTuple

     addressTuple = addrType addrSpace addrValue [portValue]
     ; portValue is required when addrType is an IP address type

     mapRequest = addrType addrSpace (addrValue / CHOOSE) CHOOSE

     addrType = IPv4 / IPv6

     addrSpace = PUBLIC / PRIVATE

     addrValue = address / ANY

     portValue = portNumber / ANY

     action = PERMIT / DENY







Taylor                 Expires - December 2002              [Page 23]

                           MIDCOM Semantics                  June 2002


Security Considerations

   This draft may receive its own discussion of security considerations,
   but for the moment these are well covered by the discussion in [3]
   and specific requirements in [4].


References


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   3  P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan,
      "Middlebox communication architecture and framework", draft-ietf-
      midcom-framework-07.txt, February 2002 (approved as RFC).

   4  R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox
      Communications (midcom) Protocol Requirements", draft-ietf-midcom-
      requirements-05.txt, November 2001 (approved as RFC).

   5  D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, November 1997.




Acknowledgments

   Cedric Aoun contributed to the initial version of this document,
   begun before list discussion of the topic of MIDCOM semantics.  The
   list discussion itself benefited from interventions by Ben Campbell,
   Bob Penfield, Paul Sijben, Martin Stiemerling, Christian Huitema,
   Scott Brim, Juergen Quittek, Ted Hardie, John LaCour, Andrew Molitor,
   Reinaldo Penno, Sanjoy Sen, Jiri Kuthan, James Renko, Joel Halprin,
   Cullen Jennings, and Adina Simu.


Author's Addresses

   Tom Taylor
   Nortel Networks
   Ottawa, Canada
   Phone: +1 613 736 0961
   Email: taylor@nortelnetworks.com



Taylor                 Expires - December 2002              [Page 24]

                           MIDCOM Semantics                  June 2002





















































Taylor                 Expires - December 2002              [Page 25]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/