Midcom Working Group Sanjoy Sen Internet Draft Cedric Aoun Tom Taylor Category: Informational Nortel Networks Expires on Nov 2002 May 2002 Applicability of MEGACO to Middlebox Control Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 draft discusses the applicability of the Megaco/H.248 device control protocol [1] as the Middlebox communication protocol. It discusses the architectural similarities between Megaco and Midcom and how Megaco meets most of the key requirements for the Midcom protocol. Modeling the underlying Middlebox resources (such as, filters, policy rules etc) as separate elements from the Megaco entities allows the usage of the protocol as-is, satisfying some of the resource access control requirements. Minimal extensions in the form of new Termination/Package definition (without impacting the base protocol) are sought for Midcom. The Midcom protocol profile and other extensions/packages will be specified in a separate internet draft. Sen/Aoun/Taylor [Page 1] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Introduction...................................................2 2 Conventions used in this document..............................3 3 Midcom Terminologies and Concepts..............................3 4 Megaco Architectural Model.....................................3 5 SIMILARITIES and DISSIMILARITIES between the Megaco and Midcom Architectural Frameworks...........................................4 5.1 Midcom Requirements MET by Megaco..............................4 5.2 Midcom requirements partially met by Megaco....................9 5.3 Midcom Requirements NOT met by Megaco.........................11 6 APPENDIX: Modeling Approach.....................................11 7 References......................................................13 8 Acknowledgments...............................................13 9 Author's Address..............................................13 10 Intellectual Property Statement...............................14 11 Full Copyright Statement......................................14 1 Introduction This draft discusses the applicability of the Megaco/H.248 device control protocol [1] as the Middlebox communication protocol. It discusses the architectural similarities between Megaco and Midcom and how Megaco meets most of the key requirements for the Midcom protocol. Modeling the underlying Middlebox resources (e.g., filters, policy rules) as separate elements from the Megaco entities allows the usage of the protocol as-is, satisfying some of the resource access control requirements. Minimal extensions in the form of new Termination / Package definition (without impacting the base protocol) are sought for Midcom. Section 3 introduces some of the key Midcom terminologies and concepts. Section 4 provides an overview of the Megaco architectural model. Section 5 depicts the similarities between Megaco and Midcom frameworks and discusses how Megaco meets most of the key Midcom protocol requirements. This section also points out the requirements that are either partially met or are not met. In Section 6, we discuss an approach to model Middlebox resources that are shared and would need access control, as separate elements from Megaco entities, and provide directions towards minimal protocol extensions in the form of new Midcom-oriented Packages. Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 2] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 2 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. 3 Midcom Terminologies and Concepts All terminologies used in this document are consistent with the terminology defined in [2]. 4 Megaco Architectural Model Megaco [1] is a master-slave, transaction-oriented protocol in which Media Gateway Controllers (MGC) control the operation of Media Gateways (MG). Originally designed to control IP Telephony gateways, it is used between an application-unaware device (the Media Gateway) and an intelligent entity (the Media Gateway Controller) having application awareness. The Megaco model includes the following key concepts: 1. Terminations: Logical entities on the MG that act as sources or sink of packet streams. Can be physical or ephemeral. A Termination is associated with a single MGC. 2. Context: An association between Terminations for sharing media between the Terminations. Terminations can be added, subtracted from a Context and can be moved from one Context to another. A Context and all of the Terminations it contains are associated with a single MGC. 3. Virtual Media Gateways: A physical MG can be partitioned into multiple virtual MG's allowing multiple Controllers to interact with disjoint sets of Contexts/Terminations within a single physical device. 4. Transactions/Messages: Each Megaco command applies to one Termination within a Context and generates a unique response. (Commands may be replicated implicitly so that they act on all Terminations of a given Context through wildcarding of Termination identifiers.) Multiple commands addressed to different Contexts can be grouped in a Transaction structure. Similarly, multiple Transactions can be concatenated into a Message. 5. Descriptors/Properties: A Termination is described by a number of characterizing parameters or Properties, which are grouped in a set of Descriptors that are included in commands and responses. Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 3] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 6. Events and signals: A Termination can be programmed to detect certain events and notify the Agent or perform certain actions. 7. Packages: Packages are groups of properties, events etc. associated with a Termination. Packages are simple means of extending the protocol to serve various types of devices or Middleboxes. 5 SIMILARITIES and DISSIMILARITIES between the Megaco and Midcom Architectural Frameworks In the Midcom architecture, the Middlebox plays the role of an application-unaware device being controlled by the application-aware Agent. The Midcom Agent (MA) and the Middlebox (MB) perform similar roles to those of the Media Gateway Controller and the Media Gateway, respectively, in the Megaco architecture. The following Sections present an analysis of the capabilities of the protocol to meet the Midcom requirements defined in [4] by the Midcom Working Group. Owing to the architectural similarities between the two protocols, the following terms will be used interchangeably in rest of the draft û 1) Midcom Agent and Media Gateway Controller 2) Middlebox and Media Gateway 5.1 Midcom Requirements MET by Megaco ö2.1.2. The Midcom protocol must allow a Midcom agent to communicate with more than one Middlebox simultaneously. In any but the most simple network, an agent is likely to want to influence the behavior of more than one middlebox. The protocol design must not preclude the ability to do this.ö MEGACO allows an MA to control several Middle Boxes. Each message carries an identifier of the endpoint that transmitted the message allowing the recipient to determine the source. ô2.1.3. The Midcom protocol must allow a middlebox to communicate with more than one Midcom agent simultaneously. There may be multiple instances of a single application or multiple applications desiring service from a single middlebox, and differ- ent agents may represent them. The protocol design must not pre- clude the ability to do so.ö Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 4] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 Megaco has the concept of Virtual Media Gateways (VMG) within a single physical MG that allows multiple MGCs communicate simultaneously with the same MG, sharing resources in a conflict- free manner. ô2.1.4. Where a multiplicity of Midcom Agents are interacting with a given middlebox, the Midcom protocol must provide mechanisms ensuring that the overall behavior is deterministic. This states that the protocol must include mechanisms for avoiding race conditions or other situations in which the requests of one agent may influence the results of the requests of other agents in an unpredictable manner.ö As discussed under 2.1.3, Megaco supports the concept of VMGÆs to make these interactions deterministic and avoid resource access conflicts. Each VMG has a single owner (in a MGC) and there can be no overlap between the sets of Terminations belonging to multiple VMGs. The Megaco protocol messages also include the identifier of the sending entity, so that the MG can easily determine whom to send the response back or whom to asynchronously report certain events that have taken place. ô2.1.5. The Midcom protocol must enable the Middlebox and any associated Midcom agent to establish known and stable states. This must include the case of power failure, or other failure, where the protocol must ensure that any resources used by a failed element can be released.ö Megaco has extensive Audit capabilities to keep states synchronized between the MG and the MGC. Megaco also provides the MGC with the ability to do mass resets as well as individual resets. MGC can always release resources in MG. The MG can also initiate the release of resources by the MGC. ô2.1.6. The middlebox must be able to report its status to a Midcom agent with which it is associated.ö Megaco has extensive Audit capabilities for the MG to report status information to the MGC. It can also report some status updates using the ServiceChange command. ô2.1.7. Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 5] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 The protocol must support unsolicited messages from middlebox to agent, for reporting conditions detected asynchronously at the middlebox. It may be the case that exceptional conditions or other events at the middlebox (resource shortages, intrusion mitigation) will cause the middlebox to close pinholes or release resources without consulting the associated Midcom agent. In that event the protocol must allow the middlebox to notify the agent.ö MEGACO supports asynchronous events notification using the Notify command. ô2.1.8. The Midcom protocol must provide for the mutual authentication of Midcom agent and middlebox to one another. In addition for the more obvious need for the Midcom agent to authenticate itself to the middlebox, there are some attacks against the protocol which can be mitigated by having the middlebox authenticate to the agent.ö MEGACO provides that IPSec be used for all security mechanisms including mutual authentication, integrity check and encryption. Use of IKE is recommended with support of RSA signatures and public key encryption. ô2.1.9. The Midcom protocol must allow either the Midcom agent or the middlebox to terminate the Midcom session between a Midcom Agent and a middlebox. This allows either entity to close the session for maintenance, security or other reasons.ö The MEGACO protocol allows both peers to terminate the association with proper reason code. ô2.1.10. A Midcom agent must be able to determine whether or not a request was successful. This states that a middlebox must return a success or failure indication to a request made by an agent.ö Megaco defines a special descriptor called an Error descriptor that contains error code and an optional explanatory string. ô2.1.11. Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 6] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 The Midcom protocol must contain version interworking capabilities to enable subsequent extensions to support different types of middlebox and future requirements of applications not considered at this stage. We assume that there will be later revisions of this protocol. The initial version will focus on communication with firewalls and NATs, and it is possible that the protocol will need to be modified as support for other middlebox types is added. These version interworking capabilities may include (but not be limited to) a protocol version number.ö Version interworking and negotiation are supported both for the protocol and any extension Packages. ô2.2.1. The syntax and semantics of the Midcom protocol must be extensible to allow the requirements of future applications to be adopted. This is related to, but different from, the requirement for versioning support. As support for additional middlebox types is added there may be a need to add new message types.ö Megaco is easily extensible through new Packages that allow definition of new attributes and behavior of a Termination. ô2.2.2. The Midcom protocol must support the ability of an agent to install a policy rule that governs multiple types of middlebox actions (e.g. Firewall and NAT). This states that the protocol must support policy rules and actions for various types of middleboxes. A Midcom agent ought to be able to have a single Midcom session with a middlebox and use the Midcom interface on the middlebox to interface with different middlebox functions on the same middlebox interface.ö Megaco supports the aggregation of commands for various Terminations (or Middlebox functions) within a single message transaction. ô2.2.3. The protocol must support the concept of a policy rule comprising a multiple of individual {filter, action} pairs to be treated as an aggregate. Applications using more than one data stream may find it more convenient and more efficient to be able to use single messages to Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 7] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 tear down, extend, and manipulate all middlebox rulesets being used by one instance of the application.ö In Megaco, a Termination can be modeled as a Policy rule comprising of multiple filter and action pairs (see Appendix). A Termination can be created, modified and deleted as a whole. Megaco also supports the ability to aggregate multiple commands into a single transaction and multiple transactions into a single message. ô2.2.4. The protocol must allow the midcom agent to extend the lifetime of an existing policy rule that otherwise would be deleted by the middle box.ö The MG can report the imminent expiry of a policy rule to the MGC that can then extend or delete the corresponding Termination. ô2.2.6. To enable management systems to interact with the Midcom environment, the protocol must include failure reasons that allow the Midcom Agent behavior to be modified as a result of the information contained in the reason. Failure reasons need to be chosen such that they do not make an attack on security easier.ö The MG can provide Error codes in response messages allowing the MGC to modify its behavior. Megaco uses transaction identifiers for correlation between a response and a command; in case the same transaction id is received more than once, the receiving entity silently discards the message. This provides some protection against replay attacks. ô2.2.8. The Midcom protocol must be able to carry filtering rules, including but not limited to the 5-tuple, from the midcom agent to the middlebox. By "5-tuple" we refer to the standard tuple. Other filtering elements may be carried, as well.ö Megaco protocol can carry descriptors and properties defining all types of filters and associated actions. ô2.2.11. It should be possible to define policy rules that contain a more Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 8] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 specific filter spec than an overlapping policy rule. This should allow agents to request actions for the subset that contradict those of the overlapping set. This should allow the Midcom agent to request to a Midcom server controlling a firewall function that a subset of the traffic that would be allowed by the overlapping policy rule be specifically disallowed.ö This requirement would be met if the policy in the Middlebox allows contradictory, overlapping policy rules to be installed. ô2.3.1. The Midcom protocol must provide for message authentication, confidentiality, and integrity.ö Megaco provides for these functions with the combined usage of IPSEC or TLS. ô2.3.2. The Midcom protocol must allow for optional confidentiality protection of control messages. If provided the mechanism should allow a choice in the algorithm to be used.ö Megaco provides for these functions with the combined usage of IPSEC or TLS. ô2.3.4. The Midcom protocol must define mechanisms to mitigate replay attacks on the control messages.ö Megaco commands and responses include matching transaction identifiers. The recipient receiving the same transaction id more than once would discard the message, thus providing some protection against replay attacks. If even stronger protection against replay attack is needed, Megaco provides for the use of IPSec or TLS. 5.2 Midcom requirements partially met by Megaco ô2.1.12. It must be possible to deterministically predict the behavior of the middlebox in the presence of overlapping rules. The protocol must preclude nondeterministic behavior in the case of overlapping rulesets, e.g. by ensuring that some known Precedence is imposed.ö Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 9] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 This is met with the help of a model that separates Megaco protocol elements from the overlapping Policy rules (see Appendix). However, new behavior for the Megaco protocol elements needs to be specified as part of a new MIDCOM specific Package. ô2.2.5. If a peer does not understand an option it must be clear whether the action required is to proceed without the unknown attribute being taken into account or the request is to be rejected. Where attributes may be ignored if not understood, a means may be provided to inform the client about what has been ignored. This states that failure modes must be robust, providing sufficient information for the agent or middlebox to be able to accommodate the failure or to retry with a new option that is more likely to succeed.ö Megaco entities provide Error codes in response messages. If a command marked "Optional" in a transaction fails, the remaining commands will continue. However, the above requirement deals with rules of processing properties that need definition in new Package. ô2.2.7. The Midcom protocol must not preclude multiple authorized agents from working on the same policy rule.ö In case the Megaco state machine on the Middle Box is decoupled from the Middle Box policy rule management, this requirement is met with local policies on the Middle Box. However, this is in violation of the spirit of the Megaco protocol, hence this is presented under partial compliancy. ô2.2.9. When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that the external port number have the same oddity as the internal port. This requirement is to support RTP and RTCP [RFC1889] "oddity" requirements.ö Megaco can be easily extended using a MIDCOM specific Package to support this feature. ô2.2.10. When the middlebox performs a port mapping function, the protocol should allow the Midcom agent to request that a consecutive range of external port numbers be mapped to consecutive internal ports. Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 10] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 This requirement is to support RTP and RTCP "sequence" requirements.ö Megaco can be easily extended using a MIDCOM specific Package to support this feature. 5.3 Midcom Requirements NOT met by Megaco ô2.1.1. The Midcom protocol must enable a Midcom agent requiring the services of a middlebox to establish an authorized association between itself and the middlebox. This states that the protocol must allow the middlebox to identify an agent requesting services and make a determination as to whether or not the agent will be permitted to do so.ö There is a directionality component implicit in this requirement, i.e., the MA should initiate the establishment of the authorized session. Megaco allows this association to be established in the opposite direction, i.e., the Middlebox (MG) initiates the establishment. But, if one ignores this restriction, then Megaco makes the syntax and semantics available for the endpoint to initiate the connection. 6 APPENDIX: Modeling Approach To model the Middlebox functions such as firewall, NAT etc., a new Middlebox Termination type needs to be defined within Megaco. If policy-rule overlap or modification by multiple Agents is NOT required, then a policy rule is equivalent to a Termination (see Figure 1). The various components of a Policy rule such as filter, action, life-time, creator etc. are described as various properties of a Termination. Use of the Virtual Media Gateway (VMG) concept allows for conflict-free interaction of multiple MAÆs with the same MB. +-------+ +-------+ | MA-1 | | MA-2 | | | | | +-------+ |IF2 +-------+ | | | +-------------|---------|----------|-----------+ Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 11] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 | +---------+ | +-------------+ | IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3 ----------| |Tx|-------+ +---|Ty|--|Tz|---------------- | | +--+ | | | +--+ +--+ | | | ....| | | +-------------+ | | +---------+ | | | +--------------------------------- | Middlebox | IF4 +----------------------------------------------+ Tx: Termination x = Policy rule x Ty: Termination y = Policy rule y Tz: Termination z = Policy rule z MA: Midcom Agent IF: Interface Figure 1. If it is required to allow multiple agents manipulate the same Middlebox resource (e.g., a Policy rule or a filter), the latter needs to be kept separate from the Termination (the Policy rule is manipulated by the MA by manipulating the properties of the associated Termination). For example, if overlapping policy rule manipulation is required, then a Termination shall be associated with a single policy rule, but a policy rule may be associated with more than one Termination. Thus, a Termination can share a policy rule with another Termination, or have a policy rule partially overlapping with that of another Termination. This model allows two MAÆs, controlling two distinct Terminations (see Figure 2), manipulate the same or overlapping policy rules. In Figure 2, policy rules 1 and 2 are overlapping and they are shared by MA-1 and MA-2. +-------+ +-------+ | MA-1 | | MA-2 | | | | | +-------+ |IF2 +-------+ | | | MB +-------------|---------|----------|-----------+ | +-----------+ | +-------------+ | IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3 ------------------|Ty|----+ +---|Tx|--|Tz|---------------- | | +--+ | | | +--+ +--+ | | | .... | | | | +--/------\---+ | | +-------|---+ | / \ | Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 12] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 | | +----/----------\------------------ | +------+----+------+ +------+ |IF4 | |Policy1 Policy2 | |Policy| | | | | | | | 3 | | | +----+------+------+ +------+ | +----------------------------------------------+ Tx: Termination x Ty: Termination y Tz: Termination z MA: Midcom Agent IF: Interface MB: Middlebox Figure 2. This requires that the Agent and the Middlebox adhere to the following principles: (1) Only one Termination has read/write access to a filter at any time. (2) When the policy rule is being modified by a new agent (i.e. not the one that created the policy) the Middlebox makes a policy decision and decides whether to accept the requested modification or not. In the case the modification is accepted the intial Midcom agent may be notified. 7 References [1] "MEGACO Protocol Version 1.0", RFC 3015 [2] "Midcom Architecture & Framework", Internet draft, draft-ietf- midcom-framework-03.txt (work in progress) [3] Sen, Aoun, Taylor, "Megaco Middlebox Packages", draft-sct- midcom-package-00.txt, work in progress [4] " Middlebox Communications (midcom) Protocol Requirements", draft-ietf-midcom-requirements-05.txt (work in progress) [5] "IP Authentication Header", RFC 2402 [6] "IP Encapsulating Security Payload", RFC 2406 8 Acknowledgments The authors would like to thank Mary Barnes and Penno Reinaldo for their useful comments and suggestions related to this draft. 9 Author's Address Sanjoy Sen Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 13] Internet Draft Applicability of Megaco to Middlebox Control Apr 2002 Nortel Networks sanjoy@nortelnetworks.com Cedric Aoun Nortel Networks cedric.aoun@nortelnetworks.com Tom Taylor Nortel Networks taylor@nortelnetworks.com 10 Intellectual Property Statement Nortel Networks may be pursuing Intellectual Property Rights for concepts described in this draft. The IPR statement http://www.ietf.org/ietf/IPR/NORTEL-GENERAL is applicable to this draft. 11 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Sen/Aoun/Taylor Informational - Expires Oct 2002 [Page 14]