Termination.
Diameter: The Diameter concept of a session includes the session
lifetime, grace period, and lifetime extension. It may make sense
to associate the Diameter session with the lifetime of a MIDCOM
Policy Rule, in which case support for lifetime extension comes
ready-made.
COPS: COPS allows a PDP to send unsolicited decisions to the PEP.
However, the unsolicited events will be relevant to the COPS
MIDCOM specific client or the MIDCOM specific PIB which needs to
be defined. This would allow the PDP to extend the lifetime of an
existing ruleset.
2.2.5. Handling of Mandatory/Optional Nature of Unknown Attributes
SNMP: T, RSIP: T, Megaco: P+, Diameter: P+, COPS: T
SNMP: Unknown attributes in a read operation are flagged as
exceptions in the Response message, but the rest of the read
succeeds. In a write operation (a SET request), all attributes
are validated before the write is performed. If there are unknown
attributes, the request fails and no writes are done. Unknown
attributes are flagged as exceptions in the Response message, and
the error status is reported.
RSIP: All options of all requests are fully specified. Not
understood parameters must be reported by an ERROR_RESPONSE with
an EXTRA_PARM error value, with the entire request otherwise
ignored.
Megaco: Megaco entities provide Error codes in response messages.
If a command marked "Optional" in a transaction fails, the
remaining commands will continue. However, the specified
requirement deals with rules of processing properties that need
definition in new Package.
Diameter: Indication of the mandatory or optional status of AVPs is
fully supported, provided it is enabled in the AVP definition. No
guidance is imposed regarding the return of diagnostic information
for optional AVPs.
COPS: COPS provides for the exchange of capabilities and
limitations between the PEP and PDP to ensure well-known outcomes
are understood for scenarios with unknown attributes. There is
also clear error handling for situations when the request is
rejected.
2.2.6. Actionable Failure Reasons
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: The SNMPv3 protocol returns error codes and exception codes
in Response messages, to permit the requestor to modify their
request. Errors and exceptions indicate the attribute that caused
the error, and an error code identifies the nature of the error
encountered.
If desired, a MIB can be designed to provide additional data about
error conditions either via asynchronous notifications or polled
objects.
RSIP: RSIP defines a fairly large number of very specific error
values. It is anticipated that additional error values will also
have to be defined along with the new messages and parameters
required for MIDCOM.
Megaco: 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. If
the same transaction id is received more than once, the receiving
entity silently discards the message, thus providing some
protection against replay attacks.
Diameter: Diameter provides an extensive set of failure reasons in
the base protocol.
COPS: COPS uses an error object to identify a particular COPS
protocol error. The error sub-code field may contain additional
detailed COPS client (MIDCOM Middlebox) specific error codes.
2.2.7. Multiple Agents Operating on the Same Ruleset.
SNMP: T, RSIP: P, Megaco: P, Diameter: T, COPS: P
SNMP: The SNMP framework supports multiple managers working on the
same managed objects. The View-based Access Control Model (VACM,
RFC 3415 [14]) even offers means to customize the access rights of
different managers in a fine-grained way.
RSIP: RSIP neither explicitly permits nor precludes an operation on
a binding by a host that had not originally create the binding.
However, to support this requirement, the RSIP semantics must be
extended to explicitly permit any authorized host to request
operations on a binding; this does not require a change to the
protocol.
Megaco: If the Megaco state machine on the Middle Box is decoupled
from the Middle Box policy rule management, this requirement can
be met with local policies on the Middle Box. However, this
violates the spirit of the Megaco protocol, thus Megaco is
considered partially compliant to this requirement.
Diameter: The Diameter protocol, as currently defined, would allow
multiple agents to operate on the same ruleset.
COPS: It is possible to use COPS to operate the same resource with
multiple agents. An underlying resource management function,
separate from the COPS state machine, on the Middlebox will handle
the arbitration when resource conflicts happen.
2.2.8. Transport of Filtering Rules
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a
MIDCOM MIB module. SMI, the language used for defining MIB
modules, is flexible enough to allow the implementation of a MIB
module to meet the semantics of this requirement.
RSIP: To support this requirement, a new optional enumeration
parameter, transportProtocol, can be added to the RSIP
ASSIGN_REQUESTs. When the parameter is included, the binding
created applies only to the use of the bound addresses and ports,
by the specific transportProtocol. When the parameter is not
included, the binding applies to the use of all the bound
addresses and ports, by any transport protocol, thus maintaining
backward compatibility with the current definition of RSIP.
Megaco: Megaco protocol can meet this requirement by defining a new
property for the transport of filtering rules.
Diameter: While Diameter defines the promising IPFilterRule data
type (see 2.1.12 above), there is no existing message, which would
convey this to a Middlebox along with other required MIDCOM
attributes. A new MIDCOM application extension of Diameter would
have to be defined.
COPS: The COPS protocol can meet this requirement by using a COPS
MIDCOM specific client or a MIDCOM specific PIB.
2.2.9. Mapped Port Parity
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a
MIDCOM MIB module.
RSIP: To support this requirement, a new optional boolean
parameter, portOddity, can be added to the RSIP ASSIGN_REQUESTs.
If the parameter is TRUE, the remote port number of the binding
created would have the same oddity as the local port. If the
parameter is not specified, or is FALSE, the remote port’s oddity
is independent of the local port’s oddity, thus maintaining
backward compatibility with the current definition of RSIP.
Megaco: Megaco can be easily extended using a MIDCOM specific
Package to support this feature.
Diameter: This capability is not part of the current IPFilterRule
type definition. Rather than modify the IPFilterRule type, MIDCOM
could group it with other AVPs which add the missing information.
COPS: The COPS protocol has all the flexibility to meet this
requirement by using a COPS MIDCOM specific client or a MIDCOM
specific PIB.
2.2.10. Consecutive Range of Port Numbers
SNMP: P+, RSIP: T, Megaco: P+, Diameter: P+, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a
MIDCOM MIB module. SMI, the language used for defining MIB
modules, is flexible enough to allow the implementation of a MIB
module to meet the semantics of this requirement.
RSIP: The ports parameter of the RSIP ASSIGN_REQUESTs specifically
allows multiple, consecutive port numbers to be specified.
Megaco: Megaco can be easily extended using a MIDCOM specific
Package to support this feature.
Diameter: This capability is not part of the current IPFilterRule
type definition. Rather than modify the IPFilterRule type, MIDCOM
could group it with other AVPs which add the missing information.
COPS: The COPS protocol has all the flexibility to meet this
requirement by using a COPS MIDCOM specific client or a MIDCOM
specific PIB.
2.2.11. More Precise Rulesets Contradicting Overlapping Rulesets
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: T, COPS: P+
SNMP: This requirement can be met by an appropriate definition of a
MIDCOM MIB module.
RSIP: To support this requirement, a new optional boolean
parameter, overlapOK, can be added to the RSIP ASSIGN_REQUESTs.
If the parameter is TRUE, the binding may overlap with an existing
binding. If the parameter is unspecified, or is FALSE, the
binding will not overlap with an existing binding, thus
maintaining backward compatibility with the current definition of
RSIP.
Megaco: This requirement would be met if the policy in the
Middlebox allows contradictory, overlapping policy rules to be
installed.
Diameter: Allowed by the IPFilterRule semantics described in
Appendix D.
COPS: The COPS protocol has all the flexibility to meet this
requirement by using a COPS MIDCOM specific client or a MIDCOM
specific PIB.
2.3. General Security Requirements
This section contains the individual protocols as evaluated against
the General Security requirements from section 2.3 of the
requirements document [1]. A short description of each of the
protocols is provided to substantiate the evaluation.
2.3.1. Message Authentication, Confidentiality and Integrity
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 includes the User-based Security Model (USM,
RFC 3414 [11]), which defines three standardized methods for
providing authentication, confidentiality, and integrity.
Additionally, USM has specific built-in mechanisms for preventing
replay attacks including unique protocol engine IDs, timers and
counters per engine and time windows for the validity of messages.
RSIP: This requirement can be met by operating RSIP over IPSec. 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 these functions with the combined usage
of IPSEC [22] or TLS [21].
Diameter: Diameter relies on either IPSEC or TLS for these
functions.
COPS: COPS has built-in message level security for authentication,
replay protection, and message integrity. COPS can also use TLS
or IPSec, thus reusing existing security mechanisms that have
interoperated in the markets.
2.3.2. Optional Confidentiality Protection
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 includes the User-based Security Model, which defines
three standardized methods for providing authentication,
confidentiality, and integrity, and is open to add further
methods. The method to use can be optionally chosen.
RSIP: Refer to 2.3.1.
Megaco: Refer to 2.3.1
Diameter: Implementation support of IPSEC ESP (RFC 2406 [23]) in
Diameter applications is not optional. Deployment of either IPSEC
or TLS is optional.
COPS: Refer to 2.3.1.
2.3.3. Operate Across Untrusted Domains
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: The User-based Security Model of SNMPv3 defines three
standardized methods for providing authentication,
confidentiality, and integrity, and it is open to add further
methods. These methods operate securely across untrusted domains.
RSIP: Refer to 2.3.1.
Megaco: Refer to 2.3.1.
Diameter: The Diameter specification [24] recommends the use of
TLS [21] across untrusted domains.
COPS: Refer to 2.3.1
2.3.4. Mitigates Replay Attacks on Control Messages
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: The User-based Security Model for SNMPv3 has specific built-
in mechanisms for preventing replay attacks including unique
protocol engine IDs, timers and counters per engine and time
windows for the validity of messages.
RSIP: Refer to 2.3.1
Megaco: Megaco commands and responses include matching transaction
identifiers. The recipient receiving the same transaction id
multiple times 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.
Diameter: Diameter requires that implementations support the replay
protection mechanisms of IPSEC.
COPS: Refer to 2.3.1
3. Conclusions
The overall statistics with regards to the number of Fully Compliant,
Partially Compliant (P+ and P) and Failing Compliancy requirements
for each of the protocols is summarized in table 1.
T P+ P F
-----------------------------------------------------------------
SNMP 22 5 0 0
RSIP 17 7 3 0
Megaco 19 5 3 0
Diameter 21 5 1 0
COPS 20 5 2 0
Table 1: Totals across all Requirements
In considering the P+ category of compliancy, an important aspect is
the mechanism for support of extensibility. The extension mechanism
provided by SNMP and COPS-PR using MIBs and PIBs respectively,
provides extensions with no impact to the protocol. Diameter
extensions require protocol changes, thus has a higher impact,
although the extensions can be handled by other Diameter entities
without being understood. Megaco’s extension mechanisms of packages
also requires protocol changes that must be understand by both
sending and receiving entities, also being considered higher impact.
The RSIP extension mechanism has the largest impact on the existing
protocol and is based upon defining the necessary new parameters.
The SNMP management framework meets all the specified MIDCOM protocol
requirements with the appropriate design of a MIDCOM MIB module.
SNMP is a proven technology with stable and proven development tools,
already has extensions defined to support NAT configuration and
policy-based management. SNMPv3 is a full standard, is more mature
and has undergone more validation than the other protocols in
the evaluation, and has been deployed to manage large-scale real-
world networks (e.g., DOCSIS cable modem networks). The
applicability of SNMP to the MIDCOM framework has a restriction in
that it assumes the MIDCOM PDP is part of the Middlebox.
RSIP fully meets many of the MIDCOM requirements. However, it does
require additions and extensions to meet several of the requirements.
RSIP would also require several framework elements to be added to the
MIDCOM framework as identified in section 1.2.3. In addition, the
tunneling required for RSIP as described in section 1.2.4, results in
RSIP not being acceptable by the WG as the MIDCOM protocol.
Megaco fully meets most of the key requirements for the MIDCOM
Protocol. Additional extensions in the form of a new Termination /
Package definition would be required for MIDCOM to meet several of
the requirements. In order to meet the remaining requirements,
modeling the underlying Middlebox resources (e.g., filters, policy
rules) as separate elements from the Megaco entities might allow the
usage of the protocol as-is, satisfying some of the resource access
control requirements.
The Diameter evaluation indicated a good overall fit. Some partially
met requirements were identified that could be addressed by a new
application extension. However, the Diameter architecture may be too
heavy for the MIDCOM application and clearly much of the Diameter
base is not needed. In addition, Diameter is the only protocol, at
the time of this evaluation, for which the RFCs had not yet been
published. Other than these reservations, the protocol is a good fit
to MIDCOM requirements.
The COPS evaluation indicates that the protocol meets the majority of
the MIDCOM protocol requirements by using the protocol’s native
extension techniques, with COPS-PR being explicitly required to meet
requirements 2.1.3 and 2.2.3. In order to fully satisfy one
partially met requirement, 2.1.1, the COPS model would need to allow
a PDP to establish communication with a PEP. While not explicitly
prohibited by the COPS model, this would require additions, in the
form of local policy, to ensure the proper establishment of an
authorized association.
4. Security Considerations
Security considerations for the MIDCOM protocol are covered by the
comparison against the specific Security requirements in the MIDCOM
requirements document [1] and are specifically addressed by section
2.1.8 and section 2.3.
5. References
5.1. Normative References
[1] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
"Middlebox Communications (MIDCOM) Protocol Requirements", RFC
3304, August 2002.
[2] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A.
Rayhan, "Middlebox Communications Architecture and Framework",
RFC 3303, August 2002.
[3] Rose, M. and K. McCloghrie, "Management Information Base for
Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, March 1991.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", STD 62, RFC 3411,
December 2002.
[6] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[7] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[8] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[9] Presuhn, R. (Ed.), "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[10] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[11] Blumenthal, U. and B. Wijnen, "User-based Security Model(USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", STD 62, RFC 3414, December 2002.
[12] Presuhn, R. (Ed.), "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62, RFC 3416,
December 2002.
[13] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", STD
62, RFC 3413, December 2002.
[14] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", STD 62, RFC 3415, December 2002.
[15] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction
to Version 3 of the Internet-Standard Network Management
Framework", RFC 3410, December 2002.
[16] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C.
Wang, "Definitions of Managed Objects for Network Address
Translators (NAT)", RFC 4008, March 2005.
[17] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm
Specific IP: Framework", RFC 3102, October 2001.
[18] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm
Specific IP: Protocol Specification", RFC 3103, October 2001.
[19] Montenegro, G. and M. Borella, "RSIP Support for End-to-end
Ipsec", RFC 3104, October 2001.
[20] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B., and
J. Segers, "Megaco Protocol Version 1.0", RFC 3015, October
2001.
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[22] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[23] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload",
RFC 2406, November 1998.
[24] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[25] Durham, D. (Ed.), Boyle, J., Cohen, R., Herzog, S., Rajan, R.,
and A. Sastry, "The COPS (Common Open Policy Service) Protocol",
RFC 2748, January 2000.
[26] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS
Usage for Policy Provisioning", RFC 3084, March 2001.
5.2. Informative References
[27] Raz, D., Schoenwalder, J., and B. Sugla, "An SNMP Application
Level Gateway for Payload Address Translation", RFC 2962,
October 2000.
[28] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
6. Acknowledgements
The editor would like to acknowledge the constructive feedback
provided by Joel M. Halpern on the individual protocol evaluation
contributions. In addition, a thanks to Elwyn Davies, Christopher
Martin, Bob Penfield, Scott Brim and Martin Stiemerling for
contributing to the mailing list discussion on the document content.
Appendix A - SNMP Overview
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 3411 [5]. A more
detailed introduction and applicability statements for the SNMP
Management Framework can be found in RFC 3410 [15].
o Mechanisms for describing and naming objects and events for the
purpose of management. The current version of this Structure of
Management Information (SMI) is called SMIv2 and described in RFC
2578 [6], RFC 2579 [7] and RFC 2580 [8].
o Message protocols for transferring management information. The
current version of the message protocol is called SNMPv3 and
described in RFC 3412 [10], RFC 3414 [11] and RFC 3417 [9].
o Protocol operations for accessing management information. The
current version of the protocol operations and associated PDU
formats is described in RFC 3416 [12].
o A set of fundamental applications described in RFC 3413 [13] and
the view-based access control mechanism described in RFC 3415