Middlebox Communications (midcom) T. Taylor Internet Draft Nortel Networks Document: draft-taylor-midcom-semgen-00.txt Expires: March 2003 September 2002 General Considerations For MIDCOM Semantics Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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 document was derived from draft-taylor-midcom-semantics-00.txt. The present version incorporates tentative conclusions reached in discussion at the IETF 54 meeting of the MIDCOM WG. It removes the concrete expression of the MIDCOM requests, responses, and notifications in favour of those presented in draft-stiemerling- midcom-semantics-xx.txt. Taylor Expires - March 2003 [Page 1]
General Considerations For MIDCOM Semantics Sep 2002 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 [ii]. The notation [X:y] (example [3:2.14]) denotes section y of reference X. 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 Changes From The Predecessor Documents......................3 1.3 New Issues..................................................4 2. Semantic Implications Of The MIDCOM Framework..................4 2.1 Agent Identity..............................................4 2.2 MIDCOM Session..............................................4 2.3 Filters, Policy Actions, Policy Rules.......................5 2.4 MIDCOM Scenarios............................................7 2.5 MIDCOM Timers..............................................11 3. Semantic Implications Of The MIDCOM Requirements..............11 4. Security Considerations.......................................16 5. References....................................................16 6. Acknowledgments...............................................16 7. Author's Addresses............................................17 Taylor Expires - March 2003 [Page 2]
General Considerations For MIDCOM Semantics Sep 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 [iii]. The detailed requirements which the protocol must satisfy are described in [iv]. 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. It demonstrates that these proposed information flows do indeed meet the requirements. Finally it specifies the semantics formally using ABNF. 1.1 Terminology "MIDCOM agent" (or simply "agent") and "middlebox" have the meanings given in [3]. "Agent" in this document always denotes a MIDCOM agent. 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]. The term "rule" is often used to denote "policy rule". 1.2 Changes From The Predecessor Documents The previous list of issues has been cleared on the basis of discussion at the MIDCOM meeting at IETF 54. As a result of that discussion, the following changes have been made in this document: i) Policy rule takeover is now on an individual policy rule rather than session basis. To facilitate this, policy rule identifiers are now specified to be globally unique rather than unique per session. ii) Policy rule life has no relationship to the life of the session in which the rule was created. If the session terminates, the policy rules created in that session remain until they expire. iii) A policy rule is assigned to a group (given a group identifier) when it is created. Group identifiers are also specified to be globally unique. iv) Only the "allow" action is supported. The "deny" action is no longer seen as a requirement. (It is viewed as an administrative rather than MIDCOM function.) Taylor Expires - March 2003 [Page 3]
General Considerations For MIDCOM Semantics Sep 2002 v) A policy rule contains only one filter. vi) Address ranges are supported in filter expressions. In addition to these changes: vii) The filter expression has been extended to handle twice-NAT configurations. viii) The "Policy Rule Request" operation in the previous version of this document has been replaced with "Enable Request", to make clear the restricted scope of the operation. This is a follow- on from (iv) above. 1.3 New Issues 1.3.1 Purpose Of Groups There seemed to be some debate over the role of groups. This document currently assumes that a group is a shortcut reference to the individual policy rules assigned to it. 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. However, the present document assumes that the Agent (or Middlebox) identifier and accompanying credentials provide an adequate representation of the session in messages between the two entities. Taylor Expires - March 2003 [Page 4]
General Considerations For MIDCOM Semantics Sep 2002 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. The canonical form of the filter in [3] is the 5-tuple: {source address, source port, destination address, destination port, protocol} The MIDCOM meeting at IETF 54 decided that "deny" actions are currently out of scope. This decision is obviously subject to further testing on the Working Group list, but assuming that it stands, the actions we must define are those that allow flows through NATs and firewalls. The 5-tuple shown above is sufficient to identify the packet flows to be enabled if and only if the internal and external address spaces are non-overlapping. In the general case there may be such overlap. To cover this general case, the filter must include a direction, "IN" or "OUT". For a pure firewall operation, the filter itself provides enough information to enable the flow. When the Middlebox performs a NAT or NAPT operation, however, additional information is needed. The discussion which follows uses the term "address-port" for brevity, but address and port should be considered as separate components to be specified in any concrete policy rule. In particular, in some situations one of these components may be specified while the other is left wildcarded. The possibilities are illustrated in Figure 1. ------------- | Middlebox | S | | D Flow A +--------------------->-------------------+ | | S D'| | D Flow B +---------------+----->-------------------+ | | S | |S' D Flow C +--------------------->-----+-------------+ | | S D'| |S' D Flow D +---------------+----->-----+-------------+ | | ------------- Taylor Expires - March 2003 [Page 5]
General Considerations For MIDCOM Semantics Sep 2002 Figure 1: Possible Flow Arrangements Through The Middlebox In Figure 1, Flow A represents a pure firewall operation. The source and destination for the incoming packets will be passed on without change in the packets as forwarded. Flow B represents a typical public-to-private flow through a NAT. The source is S in both the arriving and forwarded packets, but the destination is changed from public address-port D' to private address-port D. Flow C represents a typical private-to-public flow through a NAT. The destination is D for the arriving and forwarded packets, but the source is changed from the private address-port S to the public address-port S'. Finally, Flow D represents a twice-NAT situation. Arriving packets have source address-port S, destination address-port D'. Forwarded packets have source address-port S', destination address-port D. To cover all these cases, it is clear that the policy rule has to be augmented by two more components: the source address-port and the destination address-port for the forwarded packet. In some cases it is necessary to enable flows before (typically) the external address-port is known. Thus the policy rule semantics should allow the use of an "ANY" wildcard for either S or D in the notation of Figure 1. In other cases it is necessary to reserve the address-port binding without enabling the flow, since it is contrary to local policy to open a pinhole before the external address is known. The flow is enabled subsequently when the missing information becomes available. Thus the semantics of the MIDCOM protocol must allow for two separate operations: an address-bind request and an enable request, where the latter may update the policy rule by specifying an S or D address- port which was wildcarded in the address-bind request. To tie the two requests together, it is necessary to have a policy rule identifier which the Middlebox can use to correlate them. Further requirements on the policy rule identifier are noted below. Finally, it is sometimes necessary to reserve bindings for a sequence of destination ports, beginning with a port of specified parity (e.g. particularly in the case of RTP/RTCP). Summing up, the complete policy rule consists of a filter part and a mapping part. The filter part consists of the classical 5-tuple describing the arriving packet plus the flow direction. The mapping Taylor Expires - March 2003 [Page 6]
General Considerations For MIDCOM Semantics Sep 2002 part consists of the address and port for the source and destination of the packet as forwarded, and the port count where a sequence of ports must be enabled. In addition, the address-bind request may indicate that the first port of a sequence must have a specified parity. 2.4 MIDCOM Scenarios [3:7] presents three scenarios for the operation of the MIDCOM protocol in mid-session. 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 address binding and flow enabling where the source and destination address-ports in the mapping part of the rule are identical to the source and destination address-ports in the filter part. The protocol is UDP, the direction is OUT in the case of a) and IN in the case of b), and no wildcarding is necessary because all of the addresses are known at the time of rule instantiation. Each rule specifies a sequence of two ports. (Specification of parity is unnecessary because the forwarded destination port value is specified explicitly in the mapping part.) Operation c) uninstalls the two rules installed by a) and b). Scenario [3:7.2], NAPT control The messaging sequence includes the following MIDCOM operations: a) A->M: Query Port-BIND for port 5060 incoming to the Middlebox public address. M->A: returns Port-BIND. b) A->M: Query NAT session descriptor for SIP flow from external to private endpoint (where address of latter came from the first query). Taylor Expires - March 2003 [Page 7]
General Considerations For MIDCOM Semantics Sep 2002 M->A: returns session descriptor. c) A->M: Create NAT sessions for outgoing flows of RTP and RTCP (adjacent ports). 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 above, these operations are equivalent to a single query requesting the return of any active Policy Rules for which the filter includes the following in its scope: { source address = Ea (the external endpoint address), source port = ANY, destination address = Ma (the external address at the Middlebox), destination port = 5060, protocol = ANY, direction = IN } 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. Operation c) is similar to operation a) in the previous case, except that the address-port values in the mapping part of the policy rule are no longer identical to the corresponding values in the filter part. The address-binding request has a filter part with the content: { source address = Pa (the internal endpoint address), source port = ANY, destination address = CHOOSE, destination port = CHOOSE, protocol = UDP, direction = OUT Taylor Expires - March 2003 [Page 8]
General Considerations For MIDCOM Semantics Sep 2002 } The mapping part of the address-binding request is as follows: { source address = CHOOSE, source port = CHOOSE, destination address = Ea (the external endpoint address), destination port = <the external endpoint RTP port>, port count = 2 } It is unnecessary to specify parity of the first port in the request because the destination port is specified explicitly. The Middlebox is expected to supply values for the CHOOSE components in its reply. In a twice-NAT configuration it will assign a private address and port to the destination in the filter part; otherwise it will copy the destination address and port from the mapping part. In any event it assigns values to the source address and port in the mapping part. It maintains all of these values as part of the its record of the policy rule, and applies them when the rule is activated (flow enabled). The above expressions for the address-binding filter and mapping parts in fact provide all the information the Middlebox needs even in a pure firewall operation. This makes it clear that it is unnecessary to specify either the filter part destination address- port or the mapping part source address-port in an address-binding request. These can be implicitly assumed to be CHOOSE in all cases. The Middlebox takes appropriate action based on its own configuration, without the Agent needing to be aware of that configuration. Operations d) and e) are semantically equivalent to operation c), except that they apply in the inbound direction with the appropriate filter part source address and mapping part destination address-port. Operations c), d), and e) also require the assignment of the new rules to the same session bundle as the previously installed SIP control Policy Rules. This introduces the concept of a session bundle identifier, which must be supplied at the address-bind stage in case the session is aborted before the flow is ever activated. Since it is the Agent that is aware of the scope of a session, the session bundle identifier is provided in the address-bind request. Operation f) requires an information exchange where the Agent supplies the session bundle identifier and requests deactivation of all rules in the session bundle. Taylor Expires - March 2003 [Page 9]
General Considerations For MIDCOM Semantics Sep 2002 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. c) is equivalent to the address-bind phase of operation c) in the previous case, while d) corresponds to the flow enabling phase of that operation. Similarly, e) and f) correspond to the address-bind phase of operations d) and e) in the previous case, and g) corresponds to the flow enabling phase of those operations. Finally, h) and i) are semantically equivalent to deactivation of the bundle of rules created in the previous steps. Taylor Expires - March 2003 [Page 10]
General Considerations For MIDCOM Semantics Sep 2002 Summary Of Observations In summary, the three scenarios have demonstrated the need for information exchanges supporting querying of instantiated policy 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. 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. [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: Taylor Expires - March 2003 [Page 11]
General Considerations For MIDCOM Semantics Sep 2002 . 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. [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 Taylor Expires - March 2003 [Page 12]
General Considerations For MIDCOM Semantics Sep 2002 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. Based on discussion at IETF 54, the end of a session does not affect the life of policy rules created 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. 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; Taylor Expires - March 2003 [Page 13]
General Considerations For MIDCOM Semantics Sep 2002 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. [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 Taylor Expires - March 2003 [Page 14]
General Considerations For MIDCOM Semantics Sep 2002 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 that Policy Rule identifiers are unique within the Middlebox, hence should be assigned by the Middlebox in the reply to the address-bind request. Of course, this masks a set of requirements on operations outside of the MIDCOM protocol: sharing of Policy Rule and possibly session bundle identifiers between Agents, and authorization of one Agent to operate on policy rules 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 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.3. [4:2.2.10]: ranges of ports Also covered in section 2.3. 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. Taylor Expires - March 2003 [Page 15]
General Considerations For MIDCOM Semantics Sep 2002 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. 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]. 5. 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, RFC 3303, August 2002. [4] R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox Communications (midcom) Protocol Requirements", draft-ietf- midcom-requirements-05.txt, RFC 3304, August 2002. [5] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. 6. 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. Taylor Expires - March 2003 [Page 16]
MIDCOM Semantics September 2002 7. Authors Address Tom Taylor Nortel Networks Ottawa, Canada Phone: +1 613 736 0961 Email: taylor@nortelnetworks.com Taylor Expires - March 2003 [Page 17]