RFC 4097
Middlebox Communications (MIDCOM) Protocol Evaluation
RFC 4097: Middlebox Communications (MIDCOM) Protocol Evaluation 💖
okay bestie, let's start with the title block 🎀
- Working group: Network Working Group
- Author: M. Barnes, Ed., from Nortel Networks 🧚
- Category: Informational
- Date: June 2005
- Obsoletes / Updates: the title block doesn't list any RFCs this one obsoletes or updates
Status of This Memo ✨
This memo is here to share information with the Internet community 🌸 It is not a standard of any kind, and anyone can pass it around freely with no limits on distribution.
Copyright Notice 🌈
Copyright (C) The Internet Society (2005).
Abstract 🦋
ngl, this is the highlight reel. The doc evaluates five protocols to see if they could be the MIDCOM (Middlebox Communications) protocol: SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) 💅 Each one gets a summary against the MIDCOM requirements and the MIDCOM framework, then the doc details how well each protocol meets each requirement, and finally it wraps up with a conclusion on how they all did 🔥
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 ..................................................... 42Overview 🌟
okay so this doc is an evaluation of how well SNMP, RSIP, Megaco, Diameter and COPS could work as the MIDCOM protocol 💖 It gives an overview of each protocol and general statements on how well each one fits, based on the MIDCOM framework [2] and requirements [1] documents.
The way the evaluation worked was super chill: individuals volunteered to write a document evaluating one specific protocol. So some protocols that could've been a good fit aren't in here, because nobody stepped up to champion them 🫶 The documents that did have volunteers were posted to the list for discussion, the feedback got folded in, and the updated versions became the base for this WG document.
Section 1 lists the proposed protocols that went into the evaluation, with some background and how each one lines up (or doesn't) with the framework [2] 🎀 Section 2 goes through the proposals one requirement at a time, against the Requirements [1] ✨ Section 3 is the summary: a table with a number breakdown for each protocol, in these categories: Fully met, Partially met through the use of extensions, Partially met through other changes to the protocol, or Failing to be met 📊 The summary isn't meant to crown a winner. It's just info to feed into the bigger protocol decision process 💅
To make this a complete evaluation, some of the background and deeper details are tucked into the Appendices. Those cover the enhancements and applications of each protocol that make it comply with the MIDCOM framework and requirements 🧚
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 get read the way BCP 14, RFC 2119 [4] says 🙈
1. Protocol Proposals 👑
these five protocols got submitted to the MIDCOM WG for consideration:
- SNMP
- RSIP
- Megaco
- Diameter
- COPS
Each one gets a rundown of how it fits the MIDCOM framework 🦋
1.1. SNMP 🎀
This section gives the general vibe on whether SNMP could be the MIDCOM protocol 🌸 The big picture and specifics live in Appendix A. This evaluation only looks at SNMPv3, since that's the one with the security MIDCOM needs. SNMPv1 and SNMPv2c would be a no-go, because they've been declared Historic and their messages have only trivial security 💀 The existing NAT and Firewall Control support is covered in section 1.1.2, and the differences between the SNMP framework and the MIDCOM framework are in section 1.1.3.
1.1.1. SNMP General Applicability ✨
SNMPv3's biggest selling points are that it's mature and well understood, it's already deployed in plenty of places, and there are mature toolsets for SNMP managers and agents 🔥
The smarts live in MIB modules, not in the messaging protocol 🧠 MIB modules define a data model of the info that can be collected and configured for a managed function. The SNMP messaging protocol just carries that data in a standard format without needing to know what it means. The endpoints are the ones that understand the semantics.
Because SNMPv1 and SNMPv2c had no real security, and because configuration needs varied so much between vendors, very few MIB modules ever got built for standardized configuration across vendors 😭 Monitoring only needs a least-common-denominator subset of info, though, so tons of MIB modules were made for standardized monitoring. The result is that SNMP has mostly been used for monitoring instead of configuring network nodes 📊
SNMPv3 is built on the design of the widely deployed SNMPv1 and SNMPv2c versions 💖 It keeps the separation between data modeling (MIBs) and the protocol that moves the data, so all existing MIBs work with SNMPv3. It also uses the SMIv2 standard and shares operations and transport with SNMPv2c. The big difference is that SNMPv3 adds strong message security and controlled access to data 🔐
SNMPv3 uses the architecture in RFC 3411 [5], where every SNMP entity can do certain jobs: generating requests, responding to requests, generating asynchronous notifications, receiving notifications, and proxy-forwarding SNMP messages 🧚 SNMP reads and manipulates virtual databases of operational parameters and statistics specific to each managed application, and those databases are defined in MIB modules 🎀
1.1.2. SNMP Existing Support for NAT and Firewall Control 🌈
For configuring NATs, there's a NAT MIB module [16] already. It meets all of the MIDCOM NAT control requirements except for grouping of policy rules (requirement 2.2.3.) 🙈 To cover that gap, the NAT MIB module needs an extra grouping table.
Firewall control with SNMP is a different story 😬 The existing work only covers monitoring firewalls, not configuring them. More work is needed to develop MIBs for configuring firewalls.
1.1.3. Architectural Differences between SNMP and MIDCOM 🦋
the SNMP management framework gives you functions equivalent to the ones in the MIDCOM framework, but there are a few architectural differences 👀
Traditionally, SNMP entities are called Manager and Agent. These are now understood as entities built to support certain configurations of SNMPv3 functions. A traditional manager can generate requests and receive notifications, and a traditional agent can respond to requests and generate notifications. Here's where it gets confusing: SNMP's use of "agent" is different from how MIDCOM uses it. The SNMP Manager corresponds to the MIDCOM agent, and the SNMP Agent corresponds to the MIDCOM PDP. This evaluation assumes the MIDCOM PDP (SNMP Agent) is physically part of the middlebox, which the MIDCOM framework allows as described in section 6.0 of [2]. So for this evaluation, the SNMP agent is the Middlebox 💅
The evaluation assumes that, but SNMP doesn't actually force that setup 🧚
Proxy means different things to different people 😅 SNMP can use intermediate entities to forward messages or help distribute policies to the middlebox, kind of like the proxy features of the other candidate protocols. But proxies add configuration and deployment complexity, and the MIDCOM requirements don't need them. So this evaluation doesn't consider a proxy agent or mid-level manager. More on SNMP proxy capabilities is in Appendix A 🎀
Even though the SNMP management framework doesn't have a concept of a session, session-like associations can still be set up through managed objects ✨ To build the MIDCOM protocol on SNMP, you'd need a MIDCOM MIB module. Every request from the MIDCOM agent (SNMP manager) to the Middlebox (SNMP agent) would use write access to managed objects in that MIDCOM MIB module. The Middlebox (SNMP agent) signals its replies by changing those managed objects, and the MIDCOM agent (SNMP manager) picks them up by reading or polling the corresponding managed object, if needed 💖
1.2. RSIP 🌸
The RSIP framework is defined in RFC 3102 [17], and the detailed protocol is in RFC 3103 [18] 🦋
1.2.1. Framework Elements in Common to MIDCOM and RSIP ✨
okay so these framework elements are shared by MIDCOM and RSIP 💖 (listed by their MIDCOM names, with the RSIP name in parentheses):
- Hosts
- Applications
- Middleboxes (RSIP gateways) 🎀
- Private domain (private realm)
- External domain (public realm)
- Middlebox communication protocol (RSIP)
- MIDCOM agent registration (host registration)
- MIDCOM session (RSIP session)
- MIDCOM Filter (local / remote address and port number(s) pairs)
1.2.2. MIDCOM Framework Elements Not Supported by RSIP 🙈
RSIP doesn't support these MIDCOM framework elements, bestie:
- 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.
- MIDCOM agents. RSIP makes no distinction between applications and agents, so address assignment operations can be performed equally by applications and agents.
- 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. That joint determination is not addressed by the RSIP framework, nor is it specifically precluded.
1.2.3. RSIP Framework Elements Not Supported by MIDCOM 🦋
these 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:
- RSIP client: that portion of the application (or agent) that talks to the RSIP gateway using RSIP.
- RSIP server: that portion of an RSIP gateway that talks to applications using RSIP.
- 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.
- 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.
- 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 a real perk: the public realm IP addresses and port numbers are known to the private realm host application, so 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
okay Megaco is a master-slave, transaction-oriented protocol defined in RFC 3015 [20]. In it, Media Gateway Controllers (MGC) control the operation of Media Gateways (MG) 🎀. It was originally designed to control IP Telephony gateways, and it's used between an application-unaware device (the Media Gateway) and an intelligent entity (the Media Gateway Controller) that has application awareness.
The Megaco model includes the following key concepts, and they're giving structure 💅:
- 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.
- 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.
- 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.
- 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.
- 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.
- Events and signals: A Termination can be programmed to perform certain actions or to detect certain events and notify the Agent.
- 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's 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 🎀
Okay so COPS is a simple query and response protocol that lets a policy server (the Policy Decision Point, or PDP) and its clients (the Policy Enforcement Points, or PEPs) swap policy info back and forth 🔄. It was literally built to be simple and extensible, and it's giving clean design energy ✨. Here are the main characteristics:
- The protocol uses a client/server model 🤝. The PEP sends requests, updates, and deletions to the remote PDP, and the PDP sends decisions back to the PEP.
- The protocol uses TCP as its transport protocol so messages between policy clients and the server get reliable delivery 📦.
- The protocol is extensible 🧩. It's designed to lean on self-identifying objects, so it can carry all kinds of client-specific info without the COPS protocol itself needing to change.
- The protocol was made for the general administration, configuration, and enforcement of policies 📋.
- COPS gives you message level security for authentication, replay protection, and message integrity 🔐. It can also use existing security protocols like IPSEC [22] or TLS [21] to authenticate and secure the channel between the PEP and the PDP.
- The protocol is stateful in two main ways 🧠:
- (1) Request/Decision state is shared and kept in sync, in a transactional way, between client and server. Requests from the client PEP get installed or remembered by the remote PDP until the PEP explicitly deletes them. Meanwhile, Decisions from the remote PDP can show up asynchronously at any time for a request state that's currently installed.
- (2) State from different events (Request/Decision pairs) can be linked together. The server might respond to new queries differently because of previously installed, related Request/Decision state(s). Main character memory, literally 💅.
- The protocol is also stateful because it lets the server push configuration info down to the client, and then lets the server remove that state from the client once it stops applying 🧹.
1.5.2. Comparison of COPS and the MIDCOM Framework 🦋
In the MIDCOM framework, the Middlebox enforces the policy that an application-aware Agent controls 🛡️. So if we compare it to the COPS architecture, the Middlebox is the PEP (COPS Client) and the MIDCOM Agent is the PDP (COPS Policy Server). The big difference is in who starts the session 👀. MIDCOM requires that the MIDCOM Agent establish the session, whereas COPS says a PEP (Middlebox) establishes communication with a PDP (MIDCOM Agent). Opposite vibes, bestie 🙃.
2. Item Level Compliance Evaluation 📝
This section reviews how well each protocol complies with each of the MIDCOM Requirements [1]. Here's the key we'll use to rate each protocol's compliance:
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,
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 checks how the proposed protocols stack up against the protocol machinery requirements from section 2.1 of the requirements document [1]. Each protocol gets a short description so the rating has receipts 🧾.
2.1.1. Ability to Establish Association Between Agent and Middlebox. 🤝
SNMP: T, RSIP: P+, Megaco: P, Diameter: T, COPS: P
SNMP: SNMPv3 gives you mutual authentication at the user level (the user can be an application or a host if you want) using shared secrets 🔑. Each authenticated principal belongs to a group with access rights that control what the principal can do with specific subsets of data. If authentication fails, it can generate an SNMP notification, which is an administrator-configurable choice 🔔.
RSIP: RSIP lets sessions get established between middleboxes and applications and MIDCOM agents. To let the middlebox authorize whoever's asking, you'd have to add authorization credentials to the session establishment request 🎟️.
Megaco: There's a directionality piece hiding in this requirement, since the MA starts the authorized session. Megaco sets this association up the other way around, meaning the Middlebox (MG) starts it 🔄. If you don't count that restriction, Megaco has the syntax and semantics ready for the endpoint to start the connection too 💫.
Diameter: Even though this is out of scope, Diameter describes several ways to discover a peer 🗺️. Once it has one, a Diameter node sets up a transport connection (TCP, TLS, or SCTP) to that peer. Then the two peers swap Capability Exchange Request/Answer messages to identify each other and figure out which Diameter applications each one supports 🪪.
If the connection between two peers drops, Diameter has procedures for bringing it back 🔁. To catch lost connectivity fast, Diameter provides the Device-Watchdog Request/Answer messages, which get used when traffic between the two peers is low 🐕. And it has an extensive state machine that governs the relationship between two peers 🧠.
COPS: COPS doesn't fully meet the directionality part of the requirement 🙈. The COPS definition lets a PEP (Middlebox) start communication with a PDP (MIDCOM Agent). However, nothing explicitly stops a PDP from starting communication with a PEP. The PEP could use local policies to decide what to do when an unknown PDP contacts it, and those actions in the local policies would make sure an authorized association gets set up properly 📜.
2.1.2. Agent Can Relate to Multiple Middleboxes 🌐
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP: An SNMP manager can talk to several Middleboxes at the same time 📡.
RSIP: RSIP sessions are identified by their IP source and destination addresses and their TCP / UDP port numbers 🪪. So each RSIP client can talk to multiple servers, and each server can talk to multiple clients 👯. However, RSIP never explicitly included agents in its design. The architecture and semantics of RSIP messages don't rule agents out, so RSIP could definitely be extended to explicitly include them, which is why it's rated partially compliant here 🥲.
Megaco: Megaco lets an MA control several Middleboxes 🎛️. Every message carries an identifier for the endpoint that sent it, so the recipient can tell where it came from 📬.
Diameter: Diameter allows connections to more than one peer, and it actually encourages that for better reliability 💪. Whether the Diameter connection state machine is too heavy to handle the number of connections needed is still up for discussion 🤔.
COPS: COPS PDPs are designed to talk to 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 talk to several SNMP managers at the same time 📣.
RSIP: Refer to 2.1.2 🔗.
Megaco: Megaco has the concept of Virtual Media Gateways (VMG), which let multiple MGCs talk to the same MG at once 🌸. Applying this model to MIDCOM would let the same middlebox (MG) have associations with multiple MIDCOM Agents (MGCs) 🧚.
Diameter: Diameter allows connections to more than one peer and encourages it for reliability 🛟. Whether the connection state machine is too heavy for the number of connections needed is still a matter for discussion 🤷♀️. As far as Diameter peering goes, the Middlebox and Agent play symmetric roles ⚖️.
COPS: The COPS-PR framework says a PEP should have a unique PDP to get effective policy control 👑. The COPS-PR protocol would still allow a PEP to talk to 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: SNMP's architectural design can allow race conditions to happen 😬. But SNMPv3 defines mechanisms to prevent them, like view-based access control and advisory locking 🔒. MIB modules can also have special functionality, like RMONs OwnerString, to prevent conflicts 🛡️. SNMP agents behave deterministically when multiple managers access them, which matters a lot for several management applications, and SNMP supports that 💯.
RSIP: All RSIP requests are defined to be atomic ⚛️. Near-simultaneous requests get executed as if they were sequential 🧃.
Megaco: Megaco uses VMGs to make these interactions deterministic and avoid resource access conflicts 🎀. Each VMG has a single owner in an MGC, and no Terminations can overlap between multiple VMGs 🚫. Megaco messages also include the identifier of the sending entity, so the MG can easily tell who to send the response to, or who to asynchronously report certain events to 📮.
Diameter: Diameter depends partly on the transport protocol to provide flow control when the server gets heavily loaded 🚦. It also has application-layer messaging to say it's too busy or out of space, using the Diameter_TOO_BUSY and Diameter_OUT_OF_SPACE result codes 🙅♀️.
COPS: COPS has built-in support for clear state and policy instances 🧼. That would make it possible to create 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 persists across reboots, so a known startup state can be established 🌅. The manager can poll the agent to figure out the current state 🔍.
RSIP: RSIP assumes that on middlebox start-up, no sessions are defined and no allocations have been made 🌱. Basically, all resources get released on restart after a failure 🔄.
Megaco: Megaco has extensive audit capabilities to sync states between the MG and the MGC 🔎. It also lets the MGC do mass resets as well as individual resets 💥. The MGC can always release resources in the MG, and the MG can initiate the release of resources by the MGC too 🤝.
Diameter: The Diameter documentation doesn't talk about how atomic message processing is, so that would have to be specified in the MIDCOM extension 📝.
COPS: The COPS protocol keeps states synchronized between Middleboxes and MA, so 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: okay so the middlebox's status can get reported with asynchronous messages, or the agent can just poll for it. 🫶
RSIP: every RSIP client request gets an explicit server response, no cap 💅 And if a client wants to check the server's status, it can send a QUERY request to ask directly. 🔍
Megaco: Megaco has really thorough audit capabilities so the MG can report its status to the MGC, and it can also send some status updates using the ServiceChange command. It's giving reliable reporting 💖
Diameter: Diameter has a bunch of response codes that let a server say "hey, something's wrong" about its overall status. And in the extreme case, the Disconnect-Peer-Request lets you end a connection gracefully and tell the other side why you're leaving. Very polite breakup energy 🥹✨
COPS: the COPS Report message exists to flag asynchronous conditions and events. That's literally its whole thing 🌸
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. Two options, both iconic 👑
RSIP: an RSIP server can send an unsolicited DE_REGISTER_RESPONSE to make an RSIP host give up all of its bindings and end its relationship with the RSIP gateway. Harsh, but it works 💀 For less serious stuff, the server can send an asynchronous ERROR_RESPONSE instead. 🙈
Megaco: Megaco handles event notifications with the Notify command. Simple and clean 🦋
Diameter: either peer in a connection is allowed to start transactions, so the middlebox can totally originate its own messages. The protocol supports middlebox-originated messages, which is so main character of it 🔥
COPS: same deal as before, the COPS Report message is built for asynchronous conditions and events. 💜
2.1.8. Mutual Authentication 🔐
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 meets this one. It supports user authentication and explicitly supports symmetric secret key encryption between the MIDCOM agent (the SNMP manager) and the middlebox (the SNMP agent), so mutual authentication is covered. The default authentication and encryption methods are specified in RFC 3414 [11] (MD5, SHA-1, and DES). Different users at the same management application (the MIDCOM agent) can authenticate with different methods, and more methods can be added to SNMPv3 entities whenever they're needed. Flexible and very secure-coded 🎀
RSIP: this requirement can be met by running RSIP over IPSec, as described in RFC 3104 [19]. The RSIP framework recommends that all communication between an RSIP host and gateway be authenticated. Authentication happens through a message hash appended to the end of each RSIP protocol packet. That hash can authenticate the host and gateway to each other, provide message integrity, and avoid replay attacks with an anti-replay counter. Lowkey though, the message hash and replay counter parameters would still need to be defined for the RSIP protocol, so there's some homework left 📝
Megaco: Megaco provides for the use of IPSec [22] for all security mechanisms, including mutual authentication, integrity check, and encryption. IKE is recommended, with support for RSA signatures and public key encryption. Very "lock it down" vibes 🔒✨
Diameter: the Diameter base protocol assumes that messages are secured using either IPSec or TLS [21]. If you go with TLS, peers have to mutually authenticate themselves. No exceptions, bestie 🫡
COPS: COPS has built-in message-level security for authentication, replay protection, and message integrity, which is iconic. COPS can also use TLS or IPSec on top of that. Double protection 💖🛡️
2.1.9. Termination of Session by Either Party 👋
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: every SNMPv3 message is authenticated and authorized, so each message kind of counts as its own session, and that session ends automatically after processing. Processing can be stopped for a bunch of reasons, like security, and a response is sent back either way. 🙃
Either peer can stop operating and become unavailable for further operations. If a principal's authentication or authorization parameters change between operations, that can stop further authentication or authorization for security reasons. Hard reset energy 🔄
Also, managed objects can be defined to make sessions that last beyond processing a single message. In that case, the MIB module would need to specify who is responsible for cleaning up those objects after normal or abnormal termination. Someone has to take out the trash 🗑️
RSIP: an RSIP client can end a session with a DE_REGISTER_REQUEST. An RSIP server can end a session with an unsolicited DE_REGISTER_RESPONSE, and after that, if the client keeps sending requests on that session, the server answers them with a REGISTER_FIRST error. Rude but clear 💅
Megaco: the Megaco protocol lets both peers end the association, as long as they give a proper reason code. Good manners 🫶
Diameter: either peer in a connection can send a Disconnect-Peer-Request to end the connection gracefully. Both sides get to leave politely ✨
COPS: COPS lets both the PEP and the PDP terminate a session. Equal opportunity ending 👑
2.1.10. Indication of Success or Failure ✅❌
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: every operation request gets a matching response message with an error status that says whether it worked. For complex requests that the middlebox can't finish right away, the MIB module might also send asynchronous notifications about how the whole transaction went, and/or provide pollable objects that show the success or failure of the complete transaction. For example, see ifAdminStatus and ifOperStatus in RFC 2863 [28]. Very informative 📊
RSIP: every RSIP request gets a paired RSIP response if it succeeded, or an ERROR_RESPONSE if it didn't. No ghosting here 👻🚫
Megaco: Megaco defines a special descriptor called an Error descriptor, which carries the error code and an optional explanatory string. Like a little note saying what went wrong 📝💖
Diameter: every Diameter request is matched by a response, and that response includes a result code plus other info. Never left on read 💅
COPS: the COPS Report message directly fulfills this requirement. Easy win 🏆
2.1.11. Version Interworking 🔀
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP: SNMP keeps the protocol that carries data separate from the data that defines extra management functionality. Extra functionality can be added easily through MIBs. Capability exchange in SNMP is usually one-directional: managers can query the middlebox (the SNMP agent) to figure out which MIBs it supports. On top of that, multiple message versions can be supported at the same time, and each one is identified by a version number in the message header. Very organized, very on-brand 🗂️🌸
RSIP: every RSIP message contains a version parameter. Simple and to the point 🦋
Megaco: version interworking and negotiation are supported for both the protocol and any extension Packages. Flexible across the board ✨
Diameter: the Capabilities Exchange Request/Answer lets two peers figure out what each one supports, including protocol version and specific applications. Getting to know each other first, iykyk 🫶
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 lets the client and server communicate the features and capabilities they support, which would allow seamless version interworking. Smooth and no drama 💅🌈
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 how conflicts get resolved, can be defined in the MIB module definition. The SNMPConf policy MIB defines mechanisms for deterministic behaviour when rule sets overlap. Predictable and organized 📋
RSIP: all requests for allocating IP addresses, ports, or both that would result in rule overlap get rejected by an RSIP server with a LOCAL_ADDR_INUSE error. No double-booking allowed 🚫👯
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 behaviour for the Megaco protocol elements needs to be specified as part of a new MIDCOM-specific Package. Still some work to do here, not gonna lie 🥺
Diameter: the IPFilterRule type specification, which would probably be used as the type of a Policy Rule AVP, comes with an extensive semantic description that gives a deterministic outcome. An individual Agent can't know that outcome unless it knows all of the Policy Rules installed on the Middlebox. Rules for the appropriate direction are evaluated in order, and the first matched rule ends 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 how it applies to this requirement are provided in Appendix D. Very detailed, very slay 🧚
COPS: the COPS protocol provides transactional communication between the PEP and PDP, so the behaviour is totally deterministic as long as the middlebox state machine is designed correctly. The COPS protocol features encourage and support good state machine design. Good habits built right in 💖
2.2. Protocol Semantics 🧠
This section has the individual protocols evaluated against the protocol semantic requirements from section 2.2 of the requirements document [1]. Each protocol gets a short description so the evaluation has something to stand on. Receipts, bestie 📚✨
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. Built different 🌟
RSIP: all RSIP messages consist of three mandatory fields (protocol version, message type, and message length) followed by a sequence of parameterType / length / value 3-tuples. New messages can be defined by giving new values to the message type field. New parameter types can be defined, and existing messages can be extended, by defining new parameterType values. If new messages, parameters, or both get added in a non-backward-compatible way, a new value of the protocol version field may be defined. This may be desirable even if the additions are backward compatible. Versioning with a plan 🎀
Megaco: Megaco is easily extensible through new Packages, which let you define new attributes and behaviour of a Termination. Plug-and-play energy 🔌💜
Diameter: Diameter gives a great deal of flexibility for extensions. That includes vendor-defined commands and AVPs, plus the ability to flag each AVP as must-understand or ignorable if it isn't understood. Extremely customizable, no cap 💅👑
COPS: the COPS protocol is extensible, since it was designed to separate the Protocol from the Policy Control Information. Clean separation, clean extensions 🦋✨
2.2.2. Support of Multiple Middlebox Types ✨
SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T 🎀
SNMP: okay so SNMP is literally built to manage different kinds of devices with different capabilities 🧚 First, the managed object sysObjectID from basic MIB-II [3] tells you what type of box you're looking at. For boxes whose capabilities can change, SNMP can check whether the matching MIBs are available 💅
RSIP: all types of middleboxes are supported as long as the ruleset action is permit 🦋 Any other action would need a brand new RSIP message parameter with values for permit and whatever other actions you want 🌸
Megaco: Megaco can handle multiple Middlebox types on the same interface in two ways 💖 You can design the properties that represent the Policy Rules so they support this, or you can use multiple terminations in the same session, each one representing one type of action. In the second option, the Megaco Context is a handy way to manage the related terminations as a group ✨ Just know that the idea of flow between terminations in a context doesn't apply here, so you'd have to throw that part out 🙈
Diameter: any extra AVPs or values you need must be specified as part of the MIDCOM application extension (see <2.2.8> below) 🫶
COPS: COPS lets a PDP hand filters and actions to multiple PEP functions through one single COPS session 👑
2.2.3. Ruleset Groups 🌈
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: this one can be done in the SNMP management framework by defining a MIB module properly 💜 The SNMPConf WG has already defined an SNMP Policy MIB that lets you define policy rulesets and group them together 🍓
RSIP: RSIP currently only lets you assign one IP address, or an address and port range, to a bind-ID 🥺 To get rulesets working, RSIP could add an optional bind-ID parameter to the ASSIGN_REQUESTs so you can extend an existing ruleset instead of making a new one. The FREE_REQUESTs would also need to be extended with optional local and remote address and port parameters 🔥
Megaco: the Megaco context can group terminations so they get managed together 🦋 For example, you can delete all of the terminations, each one an instantiation of a Policy Rule, in one command by doing a wildcarded Subtract from the context. Again, the idea of media flows between terminations in a context wouldn't matter for this use of the protocol 💀
Diameter: Diameter allows message syntax definitions where several instances of the same AVP can be present, like a Policy Rule AVP whose syntax and low-level semantics come from the IPFilterRule type definition ✨ If you need tighter grouping, the Diameter base types include the Grouped type 🧁 MIDCOM can decide how to use these features to meet the ruleset group requirement when it defines its application extension to Diameter 🎀
COPS: the COPS-PR Handle State can be used to link a set of closely related policy objects together 💖 As the Middlebox learns about more requirements, it adds those resource requirements under the same handle ID, and that's the aggregation you need 🫶
2.2.4. Lifetime Extension ⏳
SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+
SNMP: again, the SNMP management framework can handle this with a properly defined MIB module 🌸 The SNMPConf WG has developed a Policy MIB module that includes a pmPolicySchedule object with a modifiable lifetime 💅
RSIP: a client can ask for an explicit lease time when it requests one or more IP addresses, ports, or both 🦋 The server can grant the requested lease time or pick one itself if none was requested. After that, the lease time can be extended if the server grants a client's EXTEND_REQUEST 🍓
Megaco: the MG can tell the MGC that a policy rule is about to expire 🔔 The MGC can then either extend or delete the matching Termination 🧚
Diameter: the Diameter concept of a session includes session lifetime, grace period, and lifetime extension ✨ It may make sense to tie the Diameter session to the lifetime of a MIDCOM Policy Rule, and then lifetime extension comes ready-made 👑
COPS: COPS lets a PDP send unsolicited decisions to the PEP 🙈 These unsolicited events matter to the COPS MIDCOM specific client or to the MIDCOM specific PIB, which still needs to be defined. This would let the PDP 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: if a read operation hits unknown attributes, those get flagged as exceptions in the Response message, but the rest of the read still succeeds 🌈 For a write (a SET request), every attribute gets validated before anything is written 🛡️ If any attributes are unknown, the request fails, no writes happen, the unknown attributes are flagged as exceptions in the Response message, and the error status is reported 😭
RSIP: every option of every request is fully specified 💅 Parameters that aren't understood must be reported in an ERROR_RESPONSE with an EXTRA_PARM error value, and the whole request is otherwise ignored 🙅♀️
Megaco: Megaco entities send Error codes in response messages 🎀 If a command marked "Optional" in a transaction fails, the remaining commands keep going ✨ The specified requirement, though, is about rules for processing properties, and those need to be defined in a new Package 🧩
Diameter: mandatory versus optional status of AVPs is fully supported, as long as it's enabled in the AVP definition 🫶 There's no guidance on returning diagnostic information for optional AVPs 🤷♀️
COPS: COPS lets the PEP and PDP exchange capabilities and limitations, so well-known outcomes are understood even when there are unknown attributes 🦋 There's also clear error handling for when a request gets rejected 💖
2.2.6. Actionable Failure Reasons 🛠️
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP: SNMPv3 returns error codes and exception codes in Response messages, so the requestor can modify the request 💅 Errors and exceptions point to the attribute that caused the problem, and an error code tells you what kind of error it was 🍓
If you want, a MIB can be designed to give more data about error conditions, either through asynchronous notifications or polled objects 🌸
RSIP: RSIP defines a pretty large number of very specific error values ✨ It's expected that additional error values will also need to be defined along with the new messages and parameters MIDCOM requires 🧚
Megaco: the MG can send Error codes in response messages so the MGC can change how it behaves 👑 Megaco uses transaction identifiers to match a response to its command. If the same transaction id shows up more than once, the receiving entity silently discards the message, which gives 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 can carry extra 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 lets you 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 didn't originally create the binding 🤔 To support this requirement, the RSIP semantics would need to be extended to explicitly permit any authorized host to request operations on a binding. This doesn't require a change to the protocol itself 🦋
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, that goes against the spirit of the Megaco protocol, so Megaco is considered partially compliant with this requirement 😬
Diameter: as currently defined, the Diameter protocol would allow multiple agents to operate on the same ruleset 💖
COPS: it's possible to use COPS to operate the same resource with multiple agents 🫶 A resource management function on the Middlebox, separate from the COPS state machine, handles 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 defining a MIDCOM MIB module properly 💜 SMI, the language used to define MIB modules, is flexible enough to implement a MIB module that meets this requirement's semantics 🍓
RSIP: to support this, a new optional enumeration parameter, transportProtocol, can be added to the RSIP ASSIGN_REQUESTs 🧁 When the parameter is included, the binding only applies to the use of the bound addresses and ports by that specific transportProtocol. When it isn't included, the binding applies to the use of all the bound addresses and ports by any transport protocol, which keeps backward compatibility with the current definition of RSIP 🌸
Megaco: the Megaco protocol can meet this requirement by defining a new property for the transport of filtering rules ✨
Diameter: Diameter defines the promising IPFilterRule data type (see 2.1.12 above), but no existing message conveys this to a Middlebox along with the 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+
Okay so this one is about keeping the odd/even vibe of a port the same on both sides 🦋 Here's how each protocol handles it.
SNMP: bestie, this is totally doable with an appropriate definition of a MIDCOM MIB module 💅
RSIP: to make this work, you'd add a new optional boolean parameter called portOddity to the ASSIGN_REQUESTs. If it's TRUE, the remote port number of the binding created has the same oddity as the local port. If it's not specified, or it's FALSE, the remote port's oddity is independent of the local port's oddity. That keeps RSIP backward compatible with its current definition 🫶
Megaco: Megaco can be easily extended with a MIDCOM specific Package to support this feature 🎀
Diameter: this capability isn't in the current IPFilterRule type definition. But instead of modifying that type, MIDCOM could group it with other AVPs that add the missing information 🧚
COPS: the COPS protocol has all the flexibility to meet this, 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: a MIDCOM MIB module can handle this one. SMI, the language used to define MIB modules, is flexible enough for a MIB module to meet the semantics of this requirement 🌸
RSIP: the ports parameter of the ASSIGN_REQUESTs specifically allows multiple, consecutive port numbers to be specified. No notes 👑
Megaco: Megaco can be easily extended with a MIDCOM specific Package to support this feature 🎀
Diameter: this capability isn't in the current IPFilterRule type definition. Instead of modifying that type, MIDCOM could group it with other AVPs that add the missing information 🧚
COPS: COPS 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, a new optional boolean parameter called overlapOK can be added to the ASSIGN_REQUESTs. If it's TRUE, the binding may overlap with an existing binding. If it's unspecified, or it's FALSE, the binding will not overlap with an existing binding. That keeps RSIP backward compatible with its current definition ✨
Megaco: this 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: COPS has all the flexibility to meet this, by using a COPS MIDCOM specific client or a MIDCOM specific PIB 💖
2.3. General Security Requirements 🔐
This section checks each protocol against the General Security requirements from section 2.3 of the requirements document [1]. Each protocol gets a short description so the evaluation has receipts 🧾
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. USM also 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 can be met by operating RSIP over IPSec. The RSIP framework recommends that 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 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 through 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, which reuses 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. (Already covered, bestie 🙈)
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. A recipient that receives the same transaction id multiple times would discard the message, which gives some protection against replay attacks. If even stronger protection against replay attacks 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 for the number of Fully Compliant, Partially Compliant (P+ and P), and Failing Compliancy requirements for each protocol are 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 RequirementsLet's talk about P+ compliancy, because extensibility is a big deal here 🧚 The extension mechanism for SNMP and COPS-PR, which use MIBs and PIBs respectively, gives extensions with no impact to the protocol. Diameter extensions require protocol changes, so they have a higher impact, although other Diameter entities can handle the extensions without understanding them. Megaco's extension mechanisms of packages also require protocol changes that must be understand by both sending and receiving entities, which is also considered higher impact. The RSIP extension mechanism has the largest impact on the existing protocol, since it's based on defining the necessary new parameters 😭
SNMP meets all the specified MIDCOM protocol requirements with an appropriate design of a MIDCOM MIB module. It's a proven technology with stable, proven development tools, and it already has extensions defined for NAT configuration and policy-based management 🌟 SNMPv3 is a full standard, it's more mature, and it has been through more validation than the other protocols in the evaluation. It has also been deployed to manage large-scale real-world networks (e.g., DOCSIS cable modem networks). The one catch is that SNMP's applicability to the MIDCOM framework is restricted, because it assumes the MIDCOM PDP is part of the Middlebox 🤏
RSIP fully meets many of the MIDCOM requirements, but it needs additions and extensions to meet several others. It would also need several framework elements added to the MIDCOM framework, as identified in section 1.2.3. On top of that, the tunneling RSIP requires, as described in section 1.2.4, means the WG found RSIP not acceptable as the MIDCOM protocol 💔
Megaco fully meets most of the key requirements for the MIDCOM Protocol. Several requirements would still need extensions in the form of a new Termination / Package definition. For the remaining requirements, modeling the underlying Middlebox resources (e.g., filters, policy rules) as separate elements from the Megaco entities might let the protocol be used as-is, which would satisfy some of the resource access control requirements 🎀
The Diameter evaluation shows 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 isn't needed. Also, at the time of this evaluation, Diameter was the only protocol whose RFCs had not yet been published. Apart from these reservations, the protocol is a good fit for the MIDCOM requirements 🦋
The COPS evaluation shows the protocol meets the majority of the MIDCOM protocol requirements by using its native extension techniques, with COPS-PR explicitly required to meet requirements 2.1.3 and 2.2.3. To fully satisfy one partially met requirement, 2.1.1, the COPS model would need to let a PDP establish communication with a PEP. The COPS model doesn't explicitly prohibit this, but it would take additions, in the form of local policy, to make sure an authorized association is set up properly 🧐
4. Security Considerations 🔐
This part is serious business, bestie. Security considerations for the MIDCOM protocol are covered by the comparison against the specific Security requirements in the MIDCOM requirements document [1], and they're specifically addressed by section 2.1.8 and section 2.3 🚨
5. References 📚
5.1. Normative References 📚✨
okay so these are the must-read docs the spec leans on, and I'm keeping every single one 💅
- [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 🌸
these ones are extra reading, nice to have but not required 🫶
- [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 💖
big thank-you to the editor's crew! 🫶 Joel M. Halpern gave super constructive feedback on the individual protocol evaluation contributions. Also a shoutout to Elwyn Davies, Christopher Martin, Bob Penfield, Scott Brim and Martin Stiemerling for jumping into the mailing list discussion about the document content. 🌈
Appendix A - SNMP Overview 🦋
okay so the SNMP Management Framework currently has five major components 👑:
- 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].
- 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].
- 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].
- Protocol operations for accessing management information. The current version of the protocol operations and associated PDU formats is described in RFC 3416 [12].
- A set of fundamental applications described in RFC 3413 [13] and the view-based access control mechanism described in RFC 3415 [14].
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. 🧚
A.1 SNMPv3 Proxy Forwarding 🎀
SNMPv3 proxy forwarding (RFC 3413 [13]) gives you a standardized way to set up an intermediate node that forwards SNMP messages. A command generating entity sends requests to a proxy forwarding entity, and that proxy forwards the request on to a third entity.
One SNMP entity can wear two hats 🧢: it can be the SNMP agent that monitors and configures the node it lives on, and it can also be an intermediate node in a proxy relationship so it can monitor and configure additional entities.
Each entity is identified by a unique engineID value, specifically so proxies can work across addressing domains and/or trust domains. An SNMPv3 message contains two engineIDs - one identifies the database used for message security, and one identifies the source (or target) of the contained data. Message security is applied between the originator and the proxy, and then again between the proxy and the end-target. The PDU carries the engineID of the node whose data is in the message, and that goes end-to-end, unchanged by the proxy. 🔥
SNMPv3 proxy was designed to be a standard SNMP approach for dropping an intermediate node into the middle of communications for all kinds of scenarios. It can cross addressing domains, such as IPv4 and IPv6, cross SNMP version domains, such as SNMPv3 and SNMPv1, cross security mechanism domains, such as DES and AES, and give you a single point of management contact for a subset of the network, such as managing a private network through a NAT device or a VPN endpoint. 💅
A.2 Proxies Versus Application Level Gateways 💜
ngl this is the tea ☕: proxies are generally preferred over Application Level Gateways (ALGs) for SNMP. ALGs typically modify the headers and content of messages. SNMP is a protocol designed for troubleshooting network (mis-)configurations, so an operator needs to see the actual configuration. When addresses inside SNMP data get translated, it causes confusion and hides the actual configuration of a managed device from the operator. ALGs also bring security vulnerabilities and other complexities related to modifying SNMP data. 🙈
SNMP proxies can modify message headers without modifying the contained data. That skips the headaches of translating the payload data, while still allowing application level translation of addresses. ✨
The issues of ALGs versus proxies for SNMP Payload Address Translation are discussed at length in RFC 2962 [27]. 📖
Appendix B - RSIP with Tunneling 🌈
NAT requires ALGs (Application Layer Gateways) in middleboxes without MIDCOM, and application modifications or agents for middleboxes with MIDCOM. 🍓
support for NAT without tunneling could easily be added to the RSIP control protocol. NAT would be defined as a new, null tunnel type. Support for the NAT null tunnels could be implemented in hosts, or in applications or application agents. 🧚
if support for NAT null tunnels were implemented in hosts, no modifications to applications would be required, and no application agents or ALGs would be required. This has obvious advantages 🤩. On top of the NAT null tunnel, the host would have to implement an RSIP / MIDCOM client (or a STUN client), and the middlebox would have to implement an RSIP / MIDCOM server, or a STUN server would have to be available beyond the middlebox. Note that the STUN client / server approach may not work with all types of middleboxes. ⚠️
if support for NAT null tunnels were not implemented in hosts, then applications would have to be modified, or application agents or ALGs would have to be implemented. This has the advantage over tunnels (whether null or not) of not requiring modification to hosts, but it would require modifying host applications or implementing application agents, both of which would include an RSIP / MIDCOM client, plus an RSIP/MIDCOM server in the middlebox. Again, in some situations, STUN could be used instead of RSIP / MIDCOM. 🙃
tunneled or not, an RSIP / MIDCOM server is needed in the middlebox. Tunneled, the host needs to be modified, but not the application. Untunneled, an agent must be added or the application must be modified, but there would be no host modifications. The advantages and disadvantages of tunneling would need to be evaluated when considering RSIP. 🦋
Appendix C - Megaco Modeling Approach 🦋
okay so, to model Middlebox stuff like firewalls, NAT, etc., we need a brand new Middlebox Termination type defined inside Megaco 💅. If policy-rule overlap or modification by multiple Agents is NOT required, then a policy rule is basically the same thing as a Termination (see Figure 1). The bits of a policy rule, like the filter, action, life-time, creator, and so on, are just different properties of a Termination ✨. Using the Virtual Media Gateway (VMG) concept lets multiple MA's play with the same MB without any conflicts 🫶.
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | |
+-------------|---------|----------|-----------+
| +---------+ | +-------------+ |
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 you need multiple agents to manipulate the same Middlebox resource (like a Policy rule or a filter) 🌸, that resource has to be kept separate from the Termination. The MA manipulates the policy rule by changing the properties of its associated Termination, which is the whole trick! For example, if overlapping policy rule manipulation is needed, then a Termination shall be associated with a single policy rule, but a policy rule may be associated with more than one Termination 🧚. So a Termination can share a policy rule with another Termination, or have a policy rule that only partially overlaps with another's. This model lets two MAs, each controlling a distinct Termination (see Figure 2), manipulate the same or overlapping policy rules 🎀. In Figure 2, policy rules 1 and 2 overlap and are shared by MA-1 and MA-2.
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | | MB
+-------------|---------|----------|-----------+
| +-----------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
------------------|Ty|----+ +---|Tx|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| .... | | | | +--/------\---+ |
| +-------|---+ | / \ |
| | +----/----------\------------------
| +------+----+------+ +------+ |IF4
| |Policy1 Policy2 | |Policy| |
| | | | | | 3 | |
| +----+------+------+ +------+ |
+----------------------------------------------+
Tx: Termination x
Ty: Termination y
Tz: Termination z
MA: MIDCOM Agent
IF: Interface
MB: Middlebox
Figure 2.This only works if the Agent and the Middlebox both stick to these 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. If the modification is accepted, the initial MIDCOM agent may be notified 👑.
Appendix D - Diameter IPFilter Rule 🌈
the IPFilterRule format is derived from the OctetString AVP Base Format 🍓. It uses UTF-8 encoding and has the same requirements as the UTF8String. Packets may be filtered based on the following info that comes with them ✨:
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP typesRules for the right direction get evaluated in order, and the first rule that matches ends the evaluation 💜. Each packet is only evaluated once. If no rule matches, the packet gets dropped if the last rule evaluated was a permit, and passed if the last rule was a deny 🙈.
IPFilterRule filters MUST follow the format:
action dir proto from src to dst [options]Here's the breakdown of the pieces 🦋:
action permit - Allow packets that match the rule.
deny - Drop packets that match the rule.
dir "in" is from the terminal, "out" is to the
terminal.
proto An IP protocol specified by number. The "ip"
keyword means any protocol will match.
src and dst <address/mask> [ports]The <address/mask> may be specified as one of these:
ipno An IPv4 or IPv6 number in dotted-
quad or canonical IPv6 form. Only
this exact IP number will match the
rule.
ipno/bits An IP number as above with a mask
width of the form 1.2.3.4/24. In
this case, all IP numbers from
1.2.3.0 to 1.2.3.255 will match.
The bit width MUST be valid for the
IP version and the IP number MUST
NOT have bits set beyond the mask.
For a match to occur, the same IP
version must be present in the
packet that was used in describing
the IP address. To test for a
particular IP version, the bits part
can be set to zero. The keyword
"any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned"
is the address or set of addresses
assigned to the terminal. For IPv4,
a typical first rule is often
"deny in ip! assigned"Heads up, the bit width MUST be valid for the IP version, and the IP number MUST NOT have bits set beyond the mask 🙅♀️. Also, for a match to happen, the packet has to use the same IP version as the one used to describe the address. And if you want to test for a particular IP version, just set the bits part to zero 🫠.
You can flip the sense of a match by putting the not modifier (!) in front of an address, which matches all the other addresses instead. This doesn't change how port numbers get selected ✨.
With the TCP, UDP and SCTP protocols, you can specify optional ports like this:
{port|port-port}[,ports[,...]]The '-' notation specifies a range of ports (including the boundaries) 🎀.
Fragmented packets with a non-zero offset (aka not the first fragment) will never match a rule that has one or more port specifications. Check the frag option for details on matching fragmented packets 🧚.
Here are the options you can use 💅:
options:
frag Match if the packet is a fragment and this is not
the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or
TCP/UDP port specifications.
ipoptions spec
Match if the IP header contains the comma
separated list of options specified in spec. The
supported IP options are:
ssrr (strict source route), lsrr (loose source
route), rr (record packet route) and ts
(timestamp). The absence of a particular option
may be denoted with a '!'.
tcpoptions spec
Match if the TCP header contains the comma
separated list of options specified in spec. The
supported TCP options are:
mss (maximum segment size), window (tcp window
advertisement), sack (selective ack), ts (rfc1323
timestamp) and cc (rfc1644 t/tcp connection
count). The absence of a particular option may
be denoted with a '!'.
established
TCP packets only. Match packets that have the RST
or ACK bits set.
setup TCP packets only. Match packets that have the SYN
bit set but no ACK bit.
tcpflags spec
TCP packets only. Match if the TCP header
contains the comma separated list of flags
specified in spec. The supported TCP flags are:
fin, syn, rst, psh, ack and urg. The absence of a
particular flag may be denoted with a '!'. A rule
that contains a tcpflags specification can never
match a fragmented packet that has a non-zero
offset. See the frag option for details on
matching fragmented packets.
icmptypes types
ICMP packets only. Match if the ICMP type is in
the list types. The list may be specified as any
combination of ranges or individual types
separated by commas. Both the numeric values and
the symbolic values listed below can be used. The
supported ICMP types are:
echo reply (0), destination unreachable (3),
source quench (4), redirect (5), echo request
(8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13),
timestamp reply (14), information request (15),
information reply (16), address mask request (17)
and address mask reply (18).There is one kind of packet the access device MUST always discard: an IP fragment with a fragment offset of one. It's a valid packet, but it only has one use, which is trying to get around firewalls 🙀.
An access device that can't interpret or apply a deny rule MUST terminate the session 🚫. An access device that can't interpret or apply a permit rule MAY apply a more restrictive rule 🌸. An access device MAY also apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure 🛡️.
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations 💖.
Contributors ✨
okay bestie, these are the people who wrote the main content for this doc 🫶 each protocol got its own individual document first, and these are the key contributors behind them 💜
- RSIP 🎀: Jim Renkel
- SNMP 🦋:
- Juergen Quittek, NEC Europe Ltd., EMail:
quittek@ccrle.nec.de - David Harrington, Co-chair SNMPv3 WG, EMail:
dbh@enterasys.com
- Juergen Quittek, NEC Europe Ltd., EMail:
- Megaco 🌈:
- Sanjoy Sen
- Cedric Aoun, Nortel, EMail:
cedric.aoun@nortel.com - Tom Taylor, Nortel, EMail:
taylor@nortel.com
- Diameter 👑: Tom Taylor, Nortel, EMail:
taylor@nortel.com(yes, Tom is in two places, he's clearly a main character 💅) - COPS 🌸:
- Cedric Aoun, Nortel, EMail:
cedric.aoun@nortel.com - Kwok-Ho Chan, Nortel, EMail:
khchan@nortel.com - Louis-Nicolas Hamer
- Reinaldo Penno, EMail:
rpenno@juniper.net - Sanjoy Sen
- Cedric Aoun, Nortel, EMail:
Author's Address 🧚
Mary Barnes, the author, is at:
- Nortel
- 2201 Lakeside Blvd.
- Richardson, TX USA
- Phone: 1-972-684-5432
- EMail:
mary.barnes@nortel.com
Full Copyright Statement 💖
Copyright (C) The Internet Society (2005).
The rights, licenses and restrictions in BCP 78 apply to this document, and except as that says otherwise, the authors keep all their rights 🔥
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 💀
Intellectual Property 🦋
The IETF doesn't take a side on whether any Intellectual Property Rights or other rights could apply to building or using the tech in this document. It also doesn't say whether licenses for those rights exist or are available, and it hasn't independently gone looking for any such rights 🙈 If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses, or the results of any attempt to get a general license or permission to use proprietary rights for implementing or using this spec, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🌈
The IETF invites anyone who's interested to flag any copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 🍓
Funding for the RFC Editor function is currently provided by the Internet
gement
📦 where this page comes from
- ietf: rfc4097 2005-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms