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
<draft-sct-midcom-megaco-02.txt>
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 <source address, source port,
destination address, destination port, transport protocol> 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]