Request for Comments: 4097 Nortel Networks
Category: Informational June 2005
Middlebox Communications (MIDCOM) Protocol Evaluation
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document provides an evaluation of the applicability of SNMP
(Simple Network Management Protocol), RSIP (Realm Specific Internet
Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as
the MIDCOM (Middlebox Communications) protocol. A summary of each of
the proposed protocols against the MIDCOM requirements and the MIDCOM
framework is provided. Compliancy of each of the protocols against
each requirement is detailed. A conclusion summarizes how each of
the protocols fares in the evaluation.
Table of Contents
Overview.......................................................... 2
Conventions Used in This Document................................. 3
1. Protocol Proposals............................................ 3
1.1. SNMP.................................................... 3
1.2. RSIP.................................................... 5
1.3. Megaco.................................................. 7
1.4. Diameter................................................ 8
1.5. COPS.................................................... 10
2. Item Level Compliance Evaluation.............................. 11
2.1. Protocol Machinery...................................... 11
2.2. Protocol Semantics...................................... 20
2.3. General Security Requirements........................... 27
3. Conclusions................................................... 29
4. Security Considerations....................................... 30
5. References.................................................... 31
5.1. Normative References.................................... 31
5.2. Informative References.................................. 33
6. Acknowledgements.............................................. 33
Appendix A - SNMP Overview........................................ 34
Appendix B - RSIP with Tunneling.................................. 35
Appendix C - Megaco Modeling Approach............................. 37
Appendix D - Diameter IPFilter Rule............................... 39
Contributors ..................................................... 42
Overview
This document provides an evaluation of the applicability of SNMP
(Simple Network Management Protocol), RSIP (Realm Specific Internet
Protocol), Megaco, Diameter and COPS (Common Open Policy Service) as
the MIDCOM (Middlebox Communications) protocol. This evaluation
provides overviews of the protocols and general statements of
applicability based upon the MIDCOM framework [2] and requirements
[1] documents.
The process for the protocol evaluation was fairly straightforward as
individuals volunteered to provide an individual document evaluating
a specific protocol. Thus, some protocols that might be considered
as reasonably applicable as the MIDCOM protocol are not evaluated in
this document since there were no volunteers to champion the work.
The individual protocol documents for which there were volunteers
were submitted for discussion on the list with feedback being
incorporated into an updated document. The updated versions of these
documents formed the basis for the content of this WG document.
Section 1 contains a list of the proposed protocols submitted for the
purposes of the protocol evaluation with some background information
on the protocols and similarities and differences with regards to the
applicability to the framework [2] provided.
Section 2 provides the item level evaluation of the proposed
protocols against the Requirements [1].
Section 3 provides a summary of the evaluation. A table containing a
numerical breakdown for each of the protocols, with regards to its
applicability to the requirements, for the following categories is
provided: Fully met, Partially met through the use of extensions,
Partially met through other changes to the protocol, or Failing to be
met. This summary is not meant to provide a conclusive statement of
the suitability of the protocols, but rather to provide information
to be considered as input into the overall protocol decision process.
In order for this document to serve as a complete evaluation of the
protocols, some of the background information and more detailed
aspects of the proposals documenting enhancements and applications of
the protocols to comply with the MIDCOM framework and requirements
are included in Appendices.
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 BCP 14, RFC 2119 [4].
1. Protocol Proposals
The following protocols were submitted to the MIDCOM WG for
consideration:
o SNMP
o RSIP
o Megaco
o Diameter
o COPS
The following provides an overview of each of the protocols and the
applicability of each protocol to the MIDCOM framework.
1.1. SNMP
This section provides a general statement with regards to the
applicability of SNMP as the MIDCOM protocol. A general overview and
some specific details of SNMP are provided in Appendix A. This
evaluation of SNMP is specific to SNMPv3, which provides the security
required for MIDCOM usage. SNMPv1 and SNMPv2c would be inappropriate
for MIDCOM since they have been declared Historic, and because their
messages have only trivial security. Some specifics with regards to
existing support for NAT and Firewall Control are provided in section
1.1.2. The differences between the SNMP framework and the MIDCOM
framework are addressed in section 1.1.3.
1.1.1. SNMP General Applicability
The primary advantages of SNMPv3 are that it is a mature, well
understood protocol, currently deployed in various scenarios, with
mature toolsets available for SNMP managers and agents.
Application intelligence is captured in MIB modules, rather than in
the messaging protocol. MIB modules define a data model of the
information that can be collected and configured for a managed
functionality. The SNMP messaging protocol transports the data in a
standardized format without needing to understand the semantics of
the data being transferred. The endpoints of the communication
understand the semantics of the data.
Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly
due to variations in configuration requirements across vendors, few
MIB modules have been developed that enable standardized
configuration of managed devices across vendors. Since monitoring
can be done using only a least-common-denominator subset of
information across vendors, many MIB modules have been developed to
provide standardized monitoring of managed devices. As a result,
SNMP has been used primarily for monitoring rather than for
configuring network nodes.
SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c
versions. Specifically, SNMPv3 shares the separation of data
modeling (MIBs) from the protocol to transfer data, so all existing
MIBs can be used with SNMPv3. SNMPv3 also uses the SMIv2 standard,
and it shares operations and transport with SNMPv2c. The major
difference between SNMPv3 and earlier versions is the addition of
strong message security and controlled access to data.
SNMPv3 uses the architecture detailed in RFC 3411 [5], where all SNMP
entities are capable of performing certain functions, such as the
generation of requests, response to requests, the generation of
asynchronous notifications, the receipt of notifications, and the
proxy-forwarding of SNMP messages. SNMP is used to read and
manipulate virtual databases of managed-application-specific
operational parameters and statistics, which are defined in MIB
modules.
1.1.2. SNMP Existing Support for NAT and Firewall Control
For configuring NATs, a NAT MIB module [16] has been developed. The
NAT MIB module meets all of the MIDCOM requirements concerning NAT
control with the exception of grouping of policy rules (requirement
2.2.3.). In order to support this, an additional grouping table in
the NAT MIB module is required.
Existing work for firewall control with SNMP only considered the
monitoring of firewalls and not the configuration. Further work is
required towards the development of MIBs for configuring firewalls.
1.1.3. Architectural Differences between SNMP and MIDCOM
The SNMP management framework provides functions equivalent to those
defined by the MIDCOM framework, although there are a few
architectural differences.
Traditionally, SNMP entities have been called Manager and Agent.
Manager and agent are now recognized as entities designed to support
particular configurations of SNMPv3 functions. A traditional manager
is an entity capable of generating requests and receiving
notifications, and a traditional agent is an entity capable of
responding to requests and generating notifications. The SNMP use of
the term agent is different from its use in the MIDCOM framework: The
SNMP Manager corresponds to the MIDCOM agent and the SNMP Agent
corresponds to the MIDCOM PDP. The SNMP evaluation assumes that the
MIDCOM PDP (SNMP Agent) is physically part of the middlebox, which is
allowed by the MIDCOM framework as described in section 6.0 of [2].
Thus, for the purpose of this evaluation, the SNMP agent corresponds
to the Middlebox.
While this evaluation is based on the assumption that the SNMP agent
corresponds to the middlebox, SNMP does not force such a restriction.
Proxy means many things to many people. SNMP can be deployed using
intermediate entities to forward messages, or to help distribute
policies to the middlebox, similar to the proxy capabilities of the
other candidate protocols. Since proxy adds configuration and
deployment complexity and is not necessary to meet the specified
MIDCOM requirements, the use of a proxy agent or mid-level manager is
not considered in this evaluation. Further details on SNMP proxy
capabilities are provided in Appendix A.
Although the SNMP management framework does not have the concept of a
session, session-like associations can be established through the use
of managed objects. In order to implement the MIDCOM protocol based
on SNMP, a MIDCOM MIB module is required. All requests from the
MIDCOM agent to the Middlebox would be performed using write access
to managed objects defined in the MIDCOM MIB module. Replies to
requests are signaled by the Middlebox (SNMP agent), by modifying the
managed objects. The MIDCOM agent (SNMP manager) can receive this
information by reading or polling, if required, the corresponding
managed object.
1.2. RSIP
The RSIP framework and detailed protocol are defined in RFC 3102 [17]
and RFC 3103 [18] respectively.
1.2.1. Framework Elements in Common to MIDCOM and RSIP
The following framework elements are common to MIDCOM and RSIP listed
by their MIDCOM names, with the RSIP name indicated in parenthesis:
o Hosts
o Applications
o Middleboxes (RSIP gateways)
o Private domain (private realm)
o External domain (public realm)
o Middlebox communication protocol (RSIP)
o MIDCOM agent registration (host registration)
o MIDCOM session (RSIP session)
o MIDCOM Filter (local / remote address and port number(s) pairs)
1.2.2. MIDCOM Framework Elements Not Supported by RSIP
The following MIDCOM framework elements are not supported by RSIP:
o Policy actions and rules. RSIP always implicitly assumes a permit
action. To support MIDCOM, a more general and explicit action
parameter would have to be defined. RSIP requests specifying
local / remote address and port number(s) pairs would have to be
extended to include an action parameter, in MIDCOM rules.
o MIDCOM agents. RSIP makes no distinction between applications and
agents; address assignment operations can be performed equally by
applications and agents.
o Policy Decision Points. RSIP assumes that middleboxes grant or
deny requests with reference to a policy known to them; the policy
could be determined jointly by the middlebox and a policy decision
point; such joint determination is not addressed by the RSIP
framework, nor is it specifically precluded.
1.2.3. RSIP Framework Elements Not Supported by MIDCOM
The following elements are unique to the RSIP framework. If RSIP
were adopted as the basis for the MIDCOM protocol, they could be
added to the MIDCOM framework:
o RSIP client: that portion of the application (or agent) that talks
to the RSIP gateway using RSIP.
o RSIP server: that portion of an RSIP gateway that talks to
applications using RSIP.
o Realm Specific Address IP (RSA-IP) and Realm Specific Address and
Port IP (RSAP-IP): RSIP distinguishes between filters that include
all ports on an IP address and those that do not.
o Demultiplexing Fields: Any set of packet header or payload fields
that an RSIP gateway uses to route an incoming packet to an RSIP
host. RSIP allows a gateway to perform, and an application to
control, packet routing to hosts in the private domain based on
more than IP header fields.
o Host-to-middlebox tunnels: RSIP assumes that data communicated
between a private realm host and a public realm host is
transferred through the private realm by a tunnel between the
inner host and the middle box, where it is converted to and from
native IP based communications to the public realm host.
1.2.4. Comparison of MIDCOM and RSIP Frameworks
RSIP with tunneling, has the advantage that the public realm IP
addresses and port numbers are known to the private realm host
application, thus no translation is needed for protocols such as SDP,
the FTP control protocol, RTSP, SMIL, etc. However, this does
require that an RSIP server and a tunneling protocol be implemented
in the middlebox and an RSIP client and the tunneling protocol be
implemented in the private realm host. The host modifications can
generally be made without modification to the host application or
requiring the implementation of a host application agent. This is
viewed as a significant advantage over NAT (Network Address
Translation).
Further details on the evaluation of RSIP with regards to tunneling
in the context of NAT support are available in Appendix B of this
document.
1.3. Megaco
1.3.1. Megaco Architectural Model
Megaco is a master-slave, transaction-oriented protocol defined in
RFC 3015 [20] 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. A termination can be physical or
ephemeral and 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 its Terminations are associated with a single
MGC.
3. Virtual Media Gateways: A physical MG can be partitioned into
multiple virtual MGs 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.
6. Events and signals: A Termination can be programmed to perform
certain actions or to detect certain events and notify the Agent.
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.
1.3.2. Comparison of 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. In the Megaco architecture, the Media Gateway controller
serves a role similar to the MIDCOM Agent (MA) and the Media Gateway
serves a role similar to the Middlebox (MB). One major difference
between the Megaco model and the MIDCOM protocol requirements is that
MIDCOM requires that the MIDCOM Agent establish the session.
Whereas, the Megaco definition is that a MG (Middlebox) establishes
communication with an MGC (MIDCOM Agent).
1.4. Diameter
1.4.1. Diameter Architecture
Diameter is designed to support AAA for network access. It is meant
to operate through networks of Diameter nodes, which both act upon
and route messages toward their final destinations. Endpoints are
characterized as either clients, which perform network access
control, or servers, which handle authentication, authorization and
accounting requests for a particular realm. Intermediate nodes
perform relay, proxy, redirect, and translation services. Design
requirements for the protocol include robustness in the face of
bursty message loads and server failures, resistance to specific DOS
attacks and protection of message contents, and extensibility
including support for vendor-specific attributes and message types.
The protocol is designed as a base protocol in RFC 3588 [24] to be
supported by all implementations, plus extensions devoted to specific
applications. Messages consist of a header and an aggregation of
"Attribute-Value Pairs (AVPs)", each of which is a tag-length-value
construct. The header includes a command code, which determines the
processing of the message and what other AVP types must or may be
present. AVPs are strongly typed. Some basic and compound types are
provided by the base protocol specification, while others may be
added by application extensions. One of the types provided in the
base is the IPFilterRule, which may be sufficient to express the
Policy Rules that MIDCOM deals with.
Messaging takes the form of request-answer exchanges. Some exchanges
may take multiple round-trips to complete. The protocol is
connection-oriented at both the transport and application levels. In
addition, the protocol is tied closely to the idea of sessions, which
relate sequences of message exchanges through use of a common session
identifier. Each application provides its own definition of the
semantics of a session. Multiple sessions may be open
simultaneously.
1.4.2. Comparison of Diameter With MIDCOM Architectural Requirements
The MIDCOM Agent does not perform the functions of a Diameter client,
nor does the Middlebox support the functions of a Diameter server.
Thus the MIDCOM application would introduce two new types of
endpoints into the Diameter architecture. Moreover, the MIDCOM
requirements do not at this time imply any type of intermediate node.
A general assessment might be that Diameter meets and exceeds MIDCOM
architectural requirements, however the connection orientation may be
too heavy for the number of relationships the Middlebox must support.
Certainly the focus on extensibility, request-response messaging
orientation, and treatment of the session, are all well-matched to
what MIDCOM needs. At this point, MIDCOM is focused on simple
point-to-point relationships, so the proxying and forwarding
capabilities provided by Diameter are not needed. Most of the
commands and AVPs defined in the base protocol are also surplus to
MIDCOM requirements.
1.5. COPS
Overall, COPS, defined in RFC 2748 [25], and COPS-PR, defined in RFC
3084 [26], have similar compliancy with regards to the MIDCOM
protocol requirements. In this document, references to COPS are
generally applicable to both COPS and COPS-PR. However, COPS-PR is
explicitly identified to meet two of the requirements. The only
other major difference between COPS-PR and COPS, as applied to the
MIDCOM protocol, would be the description of the MIDCOM policy rule
attributes with COPS-PR MIDCOM PIB attributes rather than COPS MIDCOM
client specific objects.
1.5.1. COPS Protocol Architecture
COPS is a simple query and response protocol that can be used to
exchange policy information between a policy server (Policy Decision
Point or PDP) and its clients (Policy Enforcement Points or PEPs).
COPS was defined to be a simple and extensible protocol. The main
characteristics of COPS include the following:
1. The protocol employs a client/server model. The PEP sends
requests, updates, and deletions to the remote PDP and the PDP
returns decisions back to the PEP.
2. The protocol uses TCP as its transport protocol for reliable
exchange of messages between policy clients and a server.
3. The protocol is extensible in that it is designed to leverage
self-identifying objects and can support diverse client specific
information without requiring modification of the COPS protocol.
4. The protocol was created for the general administration,
configuration, and enforcement of policies.
5. COPS provides message level security for authentication, replay
protection, and message integrity. COPS can make use of existing
protocols for security such as IPSEC [22] or TLS [21] to
authenticate and secure the channel between the PEP and the PDP.
6. The protocol is stateful in two main aspects:
(1) Request/Decision state is shared and kept synchronized in a
transactional manner between client and server. Requests from
the client PEP are installed or remembered by the remote PDP
until they are explicitly deleted by the PEP. At the same
time, Decisions from the remote PDP can be generated
asynchronously at any time for a currently installed request
state.
(2) State from various events (Request/Decision pairs) may be
inter-associated. The server may respond to new queries
differently because of previously installed, related
Request/Decision state(s).
7. The protocol is also stateful in that it allows the server to push
configuration information to the client, and then allows the
server to remove such state from the client when it is no longer
applicable.
1.5.2. Comparison of COPS and the MIDCOM Framework
In the MIDCOM framework, the Middlebox enforces the policy controlled
by an application-aware Agent. Thus, when compared to the COPS
architecture, the Middlebox serves as the PEP (COPS Client) and the
MIDCOM Agent serves as the PDP (COPS Policy Server). One major
difference between the COPS protocol model and the MIDCOM protocol
requirements is that MIDCOM requires that the MIDCOM Agent establish
the session. Whereas, the COPS definition is that a PEP (Middlebox)
establishes communication with a PDP (MIDCOM Agent).
2. Item Level Compliance Evaluation
This section contains a review of the protocol’s level of compliance
to each of the MIDCOM Requirements [1]. The following key will be
used to identify the level of compliancy of each of the individual
protocols:
T = Total Compliance. Meets the requirement fully.
P+ = Partial Compliance+. Fundamentally meets the requirement
through the use of extensions (e.g., packages, additional
parameters, etc).
P = Partial Compliance. Meets some aspect of the requirement,