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]