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