however, the necessary changes require more than an extension
and/or are inconsistent with the design intent of the
protocol.
F = Failed Compliance. Does not meet the requirement.
2.1. Protocol Machinery
This section describes the compliancy of the proposed protocols
against the protocol machinery requirements from section 2.1 of the
requirements document [1]. A short description of each of the
protocols is provided to substantiate the evaluation.
2.1.1. Ability to Establish Association Between Agent and Middlebox.
SNMP: T, RSIP: P+, Megaco: P, Diameter: T, COPS: P
SNMP: SNMPv3 provides mutual authentication at the user level
(where the user can be an application or a host if desired) via
shared secrets. Each authenticated principal is associated with a
group that has access rights that control the principals ability
to perform operations on specific subsets of data. Failure to
authenticate can generate a SNMP notification (administrator
configurable choice).
RSIP: RSIP allows sessions to be established between middleboxes
and applications and MIDCOM agents. Authorization credentials
would have to be added to the session establishment request to
allow the middlebox to authorize the session requestor.
Megaco: There is a directionality component implicit in this
requirement in that the MA initiates the establishment of the
authorized session. Megaco defines this association to be
established in the opposite direction, i.e., the Middlebox(MG)
initiates the establishment. If this restriction is not
considered, then Megaco makes the syntax and semantics available
for the endpoint to initiate the connection.
Diameter: Although this is out of scope, the Diameter specification
describes several ways to discover a peer. Having done so, a
Diameter node establishes a transport connection (TCP, TLS, or
SCTP) to the peer. The two peers then exchange Capability
Exchange Request/Answer messages to identify each other and
determine the Diameter applications each supports.
If the connection between two peers is lost, Diameter prescribes
procedures whereby it may be re-established. To ensure that loss
of connectivity is detected quickly, Diameter provides the
Device-Watchdog Request/Answer messages, to be used when traffic
between the two peers is low.
Diameter provides an extensive state machine to govern the
relationship between two peers.
COPS: COPS does not meet the directionality part of the
requirement. The definition of COPS allows a PEP (Middlebox) to
establish communication with a PDP (MIDCOM Agent). However,
nothing explicitly prohibits a PDP from establishing communication
with a PEP. The PEP could have local policies dictating what
action to take when it is contacted by an unknown PDP. These
actions, defined in the local policies, would ensure the proper
establishment of an authorized association.
2.1.2. Agent Can Relate to Multiple Middleboxes
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: An SNMP manager can communicate simultaneously with several
Middleboxes.
RSIP: RSIP sessions are identified by their IP source and
destination addresses and their TCP / UDP port numbers. Thus each
RSIP client can communicate with multiple servers, and each server
can communicate with multiple clients. However, RSIP did not
explicitly include agents in its design. The architecture and
semantics of RSIP messages do not preclude agents, thus the RSIP
architecture could certainly be extended to explicitly include
agents; therefore RSIP is deemed partially compliant to this
requirement.
Megaco: Megaco allows an MA to control several Middleboxes. Each
message carries an identifier of the endpoint that transmitted the
message allowing the recipient to determine the source.
Diameter: Diameter allows connection to more than one peer (and
encourages this for improved reliability). Whether the Diameter
connection state machine is too heavy to support the number of
connections needed is a matter for discussion.
COPS: COPS PDPs are designed to communicate with several PEPs.
2.1.3. Middlebox Can Relate to Multiple Agents
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: An SNMP agent can communicate with several SNMP managers
Simultaneously.
RSIP: Refer to 2.1.2.
Megaco: Megaco has the concept of Virtual Media Gateways (VMG),
allowing multiple MGCs to communicate simultaneously with the same
MG. Applying this model to MIDCOM would allow the same middlebox
(MG) to have associations with multiple MIDCOM Agents (MGCs).
Diameter: Diameter allows connection to more than one peer and
encourages this for improved reliability. Whether the Diameter
connection state machine is too heavy to support the number of
connections needed is a matter for discussion. The Middlebox and
Agent play symmetric roles as far as Diameter peering is
concerned.
COPS: The COPS-PR framework specifies that a PEP should have a
unique PDP in order to achieve effective policy control. The
COPS-PR protocol would allow the scenario whereby a PEP
establishes communication with multiple PDPs by creating a COPS
client instance per PDP.
2.1.4. Deterministic Outcome When Multiple Requests are Presented to
the Middlebox Simultaneously
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: While the architectural design of SNMP can permit race
conditions to occur, there are mechanisms defined as part of the
SNMPv3 standard, such as view-based access control and advisory
locking that can be used to prevent the conditions, and MIB
modules may also contain special functionality, such as RMONs
OwnerString, to prevent conflicts. Deterministic behavior of SNMP
agents when being accessed by multiple managers is important for
several management applications and supported by SNMP.
RSIP: All RSIP requests are defined to be atomic. Near simultaneous
requests are executed as is they were sequential.
Megaco: Megaco supports the concept of VMGs to make these
interactions deterministic and to 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 to whom to
send the response or asynchronously report certain events.
Diameter: Diameter depends partly upon the transport protocol to
provide flow control when the server becomes heavily loaded. It
also has application-layer messaging to indicate that it is too
busy or out of space (Diameter_TOO_BUSY and Diameter_OUT_OF_SPACE
result codes).
COPS: COPS has built-in support for clear state and policy
instances. This would allow the creation of well-behaved MIDCOM
state machines.
2.1.5. Known and Stable State
SNMP: T, RSIP: T, Megaco: T, Diameter: P, COPS: T
SNMP: Requests are atomic in SNMP. MIB modules can define which
data is persistent across reboots, so a known startup state can be
established. The manager can poll the agent to determine the
current state.
RSIP: RSIP assumes that on middlebox start-up no sessions are
defined, and thus no allocations have been made. In effect, all
resources are released upon restart after failure.
Megaco: Megaco has extensive audit capabilities to synchronize
states between the MG and the MGC. Megaco also provides the MGC
with the ability to do mass resets, as well as individual resets.
The MGC can always release resources in the MG. The MG can also
initiate the release of resources by the MGC.
Diameter: Diameter documentation does not discuss the degree of
atomicity of message processing, so this would have to be
specified in the MIDCOM extension.
COPS: The COPS protocol maintains synchronized states between
Middleboxes and MA hence all the states are known on both sides.
2.1.6. Middlebox Status Report
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: The status of a middlebox can be reported using asynchronous
communications, or via polling.
RSIP: All RSIP client requests have explicit server responses.
Additionally, a client may explicitly request server status using
a QUERY request.
Megaco: 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.
Diameter: Diameter provides a number of response codes by means of
which a server can indicate error conditions reflecting status of
the server as a whole. The Disconnect-Peer-Request provides a
means in the extreme case to terminate a connection with a peer
gracefully, informing the other end about the reason for the
disconnection.
COPS: The COPS Report message is designed to indicate any
asynchronous conditions/events.
2.1.7. Middlebox Can Generate Unsolicited Messages
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 supports both confirmed and unconfirmed asynchronous
notifications.
RSIP: An RSIP server will send an unsolicited DE_REGISTER_RESPONSE
to force an RSIP host to relinquish all of its bindings and
terminate its relationship with the RSIP gateway. An RSIP server
can send an asynchronous ERROR_RESPONSE to indicate less severe
conditions.
Megaco: Megaco supports the asynchronous notification of events
using the Notify command.
Diameter: The Diameter protocol permits either peer in a connection
to originate transactions. Thus the protocol supports Middlebox-
originated messages.
COPS: The COPS Report message is designed to indicate any
asynchronous conditions/events.
2.1.8. Mutual Authentication
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 meets this requirement. SNMPv3 supports user
authentication and explicitly supports symmetric secret key
encryption between MIDCOM agent (SNMP manager) and Middlebox (SNMP
agent), thus supporting mutual authentication. The default
authentication and encryption methods are specified in RFC 3414
[11] (MD5, SHA-1, and DES). Different users at the same
management application (MIDCOM agent) can authenticate themselves
with different authentication and encryption methods, and
additional methods can be added to SNMPv3 entities as needed.
RSIP: This requirement can be met by operating RSIP over IPSec as
described in RFC 3104 [19]. The RSIP framework recommends all
communication between an RSIP host and gateway be authenticated.
Authentication, in the form of a message hash appended to the end
of each RSIP protocol packet, can serve to authenticate the RSIP
host and gateway to one another, provide message integrity, and
avoid replay attacks with an anti-replay counter. However, the
message hash and replay counter parameters would need to be
defined for the RSIP protocol.
Megaco: Megaco provides for the use of IPSec [22] 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.
Diameter: The Diameter base protocol assumes that messages are
secured by using either IPSec or TLS [21]. Diameter requires that
when using the latter, peers must mutually authenticate
themselves.
COPS: COPS has built-in message level security for authentication,
replay protection, and message integrity. COPS can also use TLS
or IPSec.
2.1.9. Termination of session by either party
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: Each SNMPv3 message is authenticated and authorized, so each
message could be considered to have its own session, which
automatically terminates after processing. Processing may be
stopped for a number of reasons, such as security, and a response
is sent.
Either peer may stop operating, and be unavailable for further
operations. The authentication and/or authorization parameters of
a principal may be changed between operations if desired, to
prevent further authentication or authorization for security
reasons.
Additionally, managed objects can be defined for realizing
sessions that persist beyond processing of a single message. The
MIB module would need to specify the responsibility for cleanup of
the objects following normal/abnormal termination.
RSIP: An RSIP client may terminate a session with a
DE_REGISTER_REQUEST. An RSIP server may terminate a session with
an unsolicited DE_REGISTER_RESPONSE, and then respond to
subsequent requests on the session with a REGISTER_FIRST error.
Megaco: The Megaco protocol allows both peers to terminate the
association with proper reason code.
Diameter: Either peer in a connection may issue a Disconnect-Peer-
Request to end the connection gracefully.
COPS: COPS allows both the PEP and PDP to terminate a session.
2.1.10. Indication of Success or Failure
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: Each operation request has a corresponding response message
that contains an error status to indicate success or failure. For
complex requests that the middlebox cannot complete immediately,
the corresponding MIB module may be designed to also provide
asynchronous notifications of the success or failure of the
complete transaction, and/or may provide pollable objects that
indicate the success or failure of the complete transaction. For
example, see ifAdminStatus and ifOperStatus in RFC 2863 [28].
RSIP: All RSIP requests result in a paired RSIP response if the
request was successful or an ERROR_RESPONSE if the request was not
successful.
Megaco: Megaco defines a special descriptor called an Error
descriptor that contains the error code and an optional
explanatory string.
Diameter: Every Diameter request is matched by a response, and this
response contains a result code as well as other information.
COPS: The COPS Report message directly fulfills this requirement.
2.1.11. Version Interworking
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMP has a separation of the protocol to carry data, and the
data that defines additional management functionality. Additional
functionality can be added easily through MIBs. Capability
exchange in SNMP is usually uni-directional. Managers can query
the middlebox (SNMP agent) to determine which MIBs are supported.
In addition, multiple message versions can be supported
simultaneously, and are identified by a version number in the
message header.
RSIP: Each RSIP message contains a version parameter.
Megaco: Version interworking and negotiation are supported both for
the protocol and any extension Packages.
Diameter: The Capabilities Exchange Request/Answer allows two peers
to determine information about what each supports, including
protocol version and specific applications.
COPS: The COPS protocol can carry a MIDCOM version number and
capability negotiation between the COPS client and the COPS
server. This capability negotiation mechanism allows the COPS
client and server to communicate the supported
features/capabilities. This would allow seamless version
interworking.
2.1.12. Deterministic Behaviour in the Presence of Overlapping
Rules
SNMP: T, RSIP: T, Megaco: P, Diameter: T, COPS: T
SNMP: Rulesets would be defined in MIBs. The priority of rulesets,
and the resolution of conflict, can be defined in the MIB module
definition. The SNMPConf policy MIB defines mechanisms to achieve
deterministic behavior in the presence of overlapping rule sets.
RSIP: All requests for allocation of IP addresses, or ports or both
resulting in rule overlap are rejected by an RSIP server with a
LOCAL_ADDR_INUSE error.
Megaco: This is met with the help of a model that separates Megaco
protocol elements from the overlapping Policy rules (see Appendix
C). However, new behavior for the Megaco protocol elements needs
to be specified as part of a new MIDCOM specific Package.
Diameter: The IPFilterRule type specification, which would probably
be used as the type of a Policy Rule AVP, comes with an extensive
semantic description providing a deterministic outcome, which the
individual Agent cannot know unless it knows all of the Policy
Rules installed on the Middlebox. Rules for the appropriate
direction are evaluated in order, with the first matched rule
terminating the evaluation. Each packet is evaluated once. If no
rule matches, the packet is dropped if the last rule evaluated was
a permit, and passed if the last rule was a deny. The
IPFilterRule format and further details on its applicability to
this requirement are provided in Appendix D.
COPS: The COPS protocol provides transactional-based communication
between the PEP and PDP, hence the behavior is totally
deterministic provided the middlebox state machine is designed
correctly. The COPS protocol features encourage and support good
state machine design.
2.2. Protocol Semantics
This section contains the individual protocols as evaluated against
the protocol semantic requirements from section 2.2 of the
requirements document [1]. A short description of each of the
protocols is provided to substantiate the evaluation.
2.2.1. Extensibility
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: Extensibility is a basic feature of the SNMP management
Framework.
RSIP: All RSIP messages consist of three mandatory fields (protocol
version, message type, and message length) and a sequence of
parameterType / length / value 3-tuples. New messages may be
defined by defining new values for the message type field. New
parameter types may be defined, and existing messages may be
extended, by defining new parameterType values. If new messages,
parameters, or both are added in a non-backward compatible way, a
new value of the protocol version field may be defined. This may
be desirable even of the additions are backward compatible.
Megaco: Megaco is easily extensible through new Packages, which
allow definition of new attributes and behavior of a Termination.
Diameter: Diameter provides a great deal of flexibility for
extensions, including allowance for vendor-defined commands and
AVPs and the ability to flag each AVP as must-understand or
ignorable if not understood.
COPS: The COPS protocol is extensible, since it was designed to
separate the Protocol from the Policy Control Information.
2.2.2. Support of Multiple Middlebox Types
SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T
SNMP: SNMP explicitly supports managing different device types with
different capabilities. First the managed object called
sysObjectID from basic MIB-II [3] identifies the type of box. For
boxes with variable capabilities, SNMP can check the availability
of corresponding MIBs.
RSIP: All types of middleboxes are supported so long as the ruleset
action is permit. Other actions would require the definition of a
new RSIP message parameter with values for permit and the other
desired actions.
Megaco: Megaco can support multiple Middlebox types on the same
interface either by designing the properties representing the
Policy Rules to provide this support, or by using multiple
terminations in the same session, each representing one type of
action. In the latter case, the Megaco Context can be used as a
convenient means of managing the related terminations as a group.
However, the inherent idea of flow between terminations of a
context is irrelevant and would have to be discarded.
Diameter: Any necessary additional AVPs or values must be specified
as part of the MIDCOM application extension (see <2.2.8> below).
COPS: COPS allows a PDP to provide filters and actions to multiple
PEP functions through a single COPS session.
2.2.3. Ruleset Groups
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: This requirement can be realized via the SNMP management
framework by an appropriate definition of a MIB module. The
SNMPConf WG has already defined an SNMP Policy MIB that permits
the definitions of policy rulesets and grouping of rulesets.
RSIP: RSIP currently only allows one IP address, or address and
port range, to be assigned to a bind-ID. RSIP could implement
rulesets as required by adding an optional bind-ID parameter to
the ASSIGN_REQUESTs to extend an existing ruleset rather than
creating a new one. Similarly, the FREE_REQUESTs would have to be
extended by adding optional, local and remote, address and port
parameters.
Megaco: The Megaco context can be used to group terminations to be
managed together. For example, all of the terminations, each
representing an instantiation of a Policy Rule, can be deleted in
one command by doing a wildcarded Subtract from the context.
However, the inherent idea of media flows between terminations of
a context would be irrelevant in this application of the protocol.
Diameter: Diameter allows message syntax definitions where multiple
instances of the same AVP (for example, a Policy Rule AVP whose
syntax and low-level semantics are defined by the IPFilterRule
type definition) may be present. If a tighter grouping is
required, the set of Diameter base types includes the Grouped
type. MIDCOM can choose how to make use of these capabilities to
meet the ruleset group requirement when defining its application
extension to the Diameter protocol.
COPS: The COPS-PR Handle State may be used to associate the set of
closely related policy objects. As the Middlebox learns
additional requirements, the Middlebox adds these resource
requirements under the same handle ID, which constitutes the
required aggregation.
2.2.4. Lifetime Extension
SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+
SNMP: This requirement can be realized via the SNMP management
framework by an appropriate definition of a MIB module. The
SNMPConf WG has developed a Policy MIB module that includes a
pmPolicySchedule object with a modifiable lifetime.
RSIP: A client may request an explicit lease time when a request is
made to assign one or more IP addresses, ports or both. The
server may grant the requested lease time, or assign one if none
was requested. Subsequently, the lease time may be extended if a
client’s EXTEND_REQUEST is granted by the server.
Megaco: The MG can report the imminent expiry of a policy rule to
the MGC, which can then extend or delete the corresponding