diff options
Diffstat (limited to 'doc/rfc/rfc4097.txt')
| -rw-r--r-- | doc/rfc/rfc4097.txt | 2467 |
1 files changed, 2467 insertions, 0 deletions
diff --git a/doc/rfc/rfc4097.txt b/doc/rfc/rfc4097.txt new file mode 100644 index 0000000..7f3c267 --- /dev/null +++ b/doc/rfc/rfc4097.txt @@ -0,0 +1,2467 @@ + + + + + + +Network Working Group M. Barnes, Ed. +Request for Comments: 4097 Nortel Networks +Category: Informational June 2005 + + + Middlebox Communications (MIDCOM) Protocol Evaluation + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document provides an evaluation of the applicability of SNMP + (Simple Network Management Protocol), RSIP (Realm Specific Internet + Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as + the MIDCOM (Middlebox Communications) protocol. A summary of each of + the proposed protocols against the MIDCOM requirements and the MIDCOM + framework is provided. Compliancy of each of the protocols against + each requirement is detailed. A conclusion summarizes how each of + the protocols fares in the evaluation. + +Table of Contents + + Overview.......................................................... 2 + Conventions Used in This Document................................. 3 + 1. Protocol Proposals............................................ 3 + 1.1. SNMP.................................................... 3 + 1.2. RSIP.................................................... 5 + 1.3. Megaco.................................................. 7 + 1.4. Diameter................................................ 8 + 1.5. COPS.................................................... 10 + 2. Item Level Compliance Evaluation.............................. 11 + 2.1. Protocol Machinery...................................... 11 + 2.2. Protocol Semantics...................................... 20 + 2.3. General Security Requirements........................... 27 + 3. Conclusions................................................... 29 + 4. Security Considerations....................................... 30 + 5. References.................................................... 31 + 5.1. Normative References.................................... 31 + 5.2. Informative References.................................. 33 + 6. Acknowledgements.............................................. 33 + + + +Barnes Informational [Page 1] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + Appendix A - SNMP Overview........................................ 34 + Appendix B - RSIP with Tunneling.................................. 35 + Appendix C - Megaco Modeling Approach............................. 37 + Appendix D - Diameter IPFilter Rule............................... 39 + Contributors ..................................................... 42 + +Overview + + This document provides an evaluation of the applicability of SNMP + (Simple Network Management Protocol), RSIP (Realm Specific Internet + Protocol), Megaco, Diameter and COPS (Common Open Policy Service) as + the MIDCOM (Middlebox Communications) protocol. This evaluation + provides overviews of the protocols and general statements of + applicability based upon the MIDCOM framework [2] and requirements + [1] documents. + + The process for the protocol evaluation was fairly straightforward as + individuals volunteered to provide an individual document evaluating + a specific protocol. Thus, some protocols that might be considered + as reasonably applicable as the MIDCOM protocol are not evaluated in + this document since there were no volunteers to champion the work. + The individual protocol documents for which there were volunteers + were submitted for discussion on the list with feedback being + incorporated into an updated document. The updated versions of these + documents formed the basis for the content of this WG document. + + Section 1 contains a list of the proposed protocols submitted for the + purposes of the protocol evaluation with some background information + on the protocols and similarities and differences with regards to the + applicability to the framework [2] provided. + + Section 2 provides the item level evaluation of the proposed + protocols against the Requirements [1]. + + Section 3 provides a summary of the evaluation. A table containing a + numerical breakdown for each of the protocols, with regards to its + applicability to the requirements, for the following categories is + provided: Fully met, Partially met through the use of extensions, + Partially met through other changes to the protocol, or Failing to be + met. This summary is not meant to provide a conclusive statement of + the suitability of the protocols, but rather to provide information + to be considered as input into the overall protocol decision process. + + In order for this document to serve as a complete evaluation of the + protocols, some of the background information and more detailed + aspects of the proposals documenting enhancements and applications of + the protocols to comply with the MIDCOM framework and requirements + are included in Appendices. + + + +Barnes Informational [Page 2] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +Conventions Used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [4]. + +1. Protocol Proposals + + The following protocols were submitted to the MIDCOM WG for + consideration: + + o SNMP + o RSIP + o Megaco + o Diameter + o COPS + + The following provides an overview of each of the protocols and the + applicability of each protocol to the MIDCOM framework. + +1.1. SNMP + + This section provides a general statement with regards to the + applicability of SNMP as the MIDCOM protocol. A general overview and + some specific details of SNMP are provided in Appendix A. This + evaluation of SNMP is specific to SNMPv3, which provides the security + required for MIDCOM usage. SNMPv1 and SNMPv2c would be inappropriate + for MIDCOM since they have been declared Historic, and because their + messages have only trivial security. Some specifics with regards to + existing support for NAT and Firewall Control are provided in section + 1.1.2. The differences between the SNMP framework and the MIDCOM + framework are addressed in section 1.1.3. + +1.1.1. SNMP General Applicability + + The primary advantages of SNMPv3 are that it is a mature, well + understood protocol, currently deployed in various scenarios, with + mature toolsets available for SNMP managers and agents. + + Application intelligence is captured in MIB modules, rather than in + the messaging protocol. MIB modules define a data model of the + information that can be collected and configured for a managed + functionality. The SNMP messaging protocol transports the data in a + standardized format without needing to understand the semantics of + the data being transferred. The endpoints of the communication + understand the semantics of the data. + + + + + +Barnes Informational [Page 3] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly + due to variations in configuration requirements across vendors, few + MIB modules have been developed that enable standardized + configuration of managed devices across vendors. Since monitoring + can be done using only a least-common-denominator subset of + information across vendors, many MIB modules have been developed to + provide standardized monitoring of managed devices. As a result, + SNMP has been used primarily for monitoring rather than for + configuring network nodes. + + SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c + versions. Specifically, SNMPv3 shares the separation of data + modeling (MIBs) from the protocol to transfer data, so all existing + MIBs can be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, + and it shares operations and transport with SNMPv2c. The major + difference between SNMPv3 and earlier versions is the addition of + strong message security and controlled access to data. + + SNMPv3 uses the architecture detailed in RFC 3411 [5], where all SNMP + entities are capable of performing certain functions, such as the + generation of requests, response to requests, the generation of + asynchronous notifications, the receipt of notifications, and the + proxy-forwarding of SNMP messages. SNMP is used to read and + manipulate virtual databases of managed-application-specific + operational parameters and statistics, which are defined in MIB + modules. + +1.1.2. SNMP Existing Support for NAT and Firewall Control + + For configuring NATs, a NAT MIB module [16] has been developed. The + NAT MIB module meets all of the MIDCOM requirements concerning NAT + control with the exception of grouping of policy rules (requirement + 2.2.3.). In order to support this, an additional grouping table in + the NAT MIB module is required. + + Existing work for firewall control with SNMP only considered the + monitoring of firewalls and not the configuration. Further work is + required towards the development of MIBs for configuring firewalls. + +1.1.3. Architectural Differences between SNMP and MIDCOM + + The SNMP management framework provides functions equivalent to those + defined by the MIDCOM framework, although there are a few + architectural differences. + + Traditionally, SNMP entities have been called Manager and Agent. + Manager and agent are now recognized as entities designed to support + particular configurations of SNMPv3 functions. A traditional manager + + + +Barnes Informational [Page 4] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + is an entity capable of generating requests and receiving + notifications, and a traditional agent is an entity capable of + responding to requests and generating notifications. The SNMP use of + the term agent is different from its use in the MIDCOM framework: The + SNMP Manager corresponds to the MIDCOM agent and the SNMP Agent + corresponds to the MIDCOM PDP. The SNMP evaluation assumes that the + MIDCOM PDP (SNMP Agent) is physically part of the middlebox, which is + allowed by the MIDCOM framework as described in section 6.0 of [2]. + Thus, for the purpose of this evaluation, the SNMP agent corresponds + to the Middlebox. + + While this evaluation is based on the assumption that the SNMP agent + corresponds to the middlebox, SNMP does not force such a restriction. + + Proxy means many things to many people. SNMP can be deployed using + intermediate entities to forward messages, or to help distribute + policies to the middlebox, similar to the proxy capabilities of the + other candidate protocols. Since proxy adds configuration and + deployment complexity and is not necessary to meet the specified + MIDCOM requirements, the use of a proxy agent or mid-level manager is + not considered in this evaluation. Further details on SNMP proxy + capabilities are provided in Appendix A. + + Although the SNMP management framework does not have the concept of a + session, session-like associations can be established through the use + of managed objects. In order to implement the MIDCOM protocol based + on SNMP, a MIDCOM MIB module is required. All requests from the + MIDCOM agent to the Middlebox would be performed using write access + to managed objects defined in the MIDCOM MIB module. Replies to + requests are signaled by the Middlebox (SNMP agent), by modifying the + managed objects. The MIDCOM agent (SNMP manager) can receive this + information by reading or polling, if required, the corresponding + managed object. + +1.2. RSIP + + The RSIP framework and detailed protocol are defined in RFC 3102 [17] + and RFC 3103 [18] respectively. + +1.2.1. Framework Elements in Common to MIDCOM and RSIP + + The following framework elements are common to MIDCOM and RSIP listed + by their MIDCOM names, with the RSIP name indicated in parenthesis: + + o Hosts + o Applications + o Middleboxes (RSIP gateways) + o Private domain (private realm) + + + +Barnes Informational [Page 5] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + o External domain (public realm) + o Middlebox communication protocol (RSIP) + o MIDCOM agent registration (host registration) + o MIDCOM session (RSIP session) + o MIDCOM Filter (local / remote address and port number(s) pairs) + +1.2.2. MIDCOM Framework Elements Not Supported by RSIP + + The following MIDCOM framework elements are not supported by RSIP: + + o Policy actions and rules. RSIP always implicitly assumes a permit + action. To support MIDCOM, a more general and explicit action + parameter would have to be defined. RSIP requests specifying + local / remote address and port number(s) pairs would have to be + extended to include an action parameter, in MIDCOM rules. + + o MIDCOM agents. RSIP makes no distinction between applications and + agents; address assignment operations can be performed equally by + applications and agents. + + o Policy Decision Points. RSIP assumes that middleboxes grant or + deny requests with reference to a policy known to them; the policy + could be determined jointly by the middlebox and a policy decision + point; such joint determination is not addressed by the RSIP + framework, nor is it specifically precluded. + +1.2.3. RSIP Framework Elements Not Supported by MIDCOM + + The following elements are unique to the RSIP framework. If RSIP + were adopted as the basis for the MIDCOM protocol, they could be + added to the MIDCOM framework: + + o RSIP client: that portion of the application (or agent) that talks + to the RSIP gateway using RSIP. + + o RSIP server: that portion of an RSIP gateway that talks to + applications using RSIP. + + o Realm Specific Address IP (RSA-IP) and Realm Specific Address and + Port IP (RSAP-IP): RSIP distinguishes between filters that include + all ports on an IP address and those that do not. + + o Demultiplexing Fields: Any set of packet header or payload fields + that an RSIP gateway uses to route an incoming packet to an RSIP + host. RSIP allows a gateway to perform, and an application to + control, packet routing to hosts in the private domain based on + more than IP header fields. + + + + +Barnes Informational [Page 6] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + o Host-to-middlebox tunnels: RSIP assumes that data communicated + between a private realm host and a public realm host is + transferred through the private realm by a tunnel between the + inner host and the middle box, where it is converted to and from + native IP based communications to the public realm host. + +1.2.4. Comparison of MIDCOM and RSIP Frameworks + + RSIP with tunneling, has the advantage that the public realm IP + addresses and port numbers are known to the private realm host + application, thus no translation is needed for protocols such as SDP, + the FTP control protocol, RTSP, SMIL, etc. However, this does + require that an RSIP server and a tunneling protocol be implemented + in the middlebox and an RSIP client and the tunneling protocol be + implemented in the private realm host. The host modifications can + generally be made without modification to the host application or + requiring the implementation of a host application agent. This is + viewed as a significant advantage over NAT (Network Address + Translation). + + Further details on the evaluation of RSIP with regards to tunneling + in the context of NAT support are available in Appendix B of this + document. + +1.3. Megaco + +1.3.1. Megaco Architectural Model + + Megaco is a master-slave, transaction-oriented protocol defined in + RFC 3015 [20] in which Media Gateway Controllers (MGC) control the + operation of Media Gateways (MG). Originally designed to control IP + Telephony gateways, it is used between an application-unaware device + (the Media Gateway) and an intelligent entity (the Media Gateway + Controller) having application awareness. + + The Megaco model includes the following key concepts: + + 1. Terminations: Logical entities on the MG that act as sources or + sink of packet streams. A termination can be physical or + ephemeral and is associated with a single MGC. + + 2. Context: An association between Terminations for sharing media + between the Terminations. Terminations can be added, subtracted + from a Context and can be moved from one Context to another. A + Context and all of its Terminations are associated with a single + MGC. + + + + + +Barnes Informational [Page 7] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 3. Virtual Media Gateways: A physical MG can be partitioned into + multiple virtual MGs allowing multiple Controllers to interact + with disjoint sets of Contexts/Terminations within a single + physical device. + + 4. Transactions/Messages: Each Megaco command applies to one + Termination within a Context and generates a unique response. + Commands may be replicated implicitly so that they act on all + Terminations of a given Context through wildcarding of Termination + identifiers. Multiple commands addressed to different Contexts + can be grouped in a Transaction structure. Similarly, multiple + Transactions can be concatenated into a Message. + + 5. Descriptors/Properties: A Termination is described by a number of + characterizing parameters or Properties, which are grouped in a + set of Descriptors that are included in commands and responses. + + 6. Events and signals: A Termination can be programmed to perform + certain actions or to detect certain events and notify the Agent. + + 7. Packages: Packages are groups of properties, events, etc. + associated with a Termination. Packages are simple means of + extending the protocol to serve various types of devices or + Middleboxes. + +1.3.2. Comparison of the Megaco and MIDCOM Architectural Frameworks + + In the MIDCOM architecture, the Middlebox plays the role of an + application-unaware device being controlled by the application-aware + Agent. In the Megaco architecture, the Media Gateway controller + serves a role similar to the MIDCOM Agent (MA) and the Media Gateway + serves a role similar to the Middlebox (MB). One major difference + between the Megaco model and the MIDCOM protocol requirements is that + MIDCOM requires that the MIDCOM Agent establish the session. + Whereas, the Megaco definition is that a MG (Middlebox) establishes + communication with an MGC (MIDCOM Agent). + +1.4. Diameter + +1.4.1. Diameter Architecture + + Diameter is designed to support AAA for network access. It is meant + to operate through networks of Diameter nodes, which both act upon + and route messages toward their final destinations. Endpoints are + characterized as either clients, which perform network access + control, or servers, which handle authentication, authorization and + accounting requests for a particular realm. Intermediate nodes + perform relay, proxy, redirect, and translation services. Design + + + +Barnes Informational [Page 8] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 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. + + + + + + + +Barnes Informational [Page 9] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +1.5. COPS + + Overall, COPS, defined in RFC 2748 [25], and COPS-PR, defined in RFC + 3084 [26], have similar compliancy with regards to the MIDCOM + protocol requirements. In this document, references to COPS are + generally applicable to both COPS and COPS-PR. However, COPS-PR is + explicitly identified to meet two of the requirements. The only + other major difference between COPS-PR and COPS, as applied to the + MIDCOM protocol, would be the description of the MIDCOM policy rule + attributes with COPS-PR MIDCOM PIB attributes rather than COPS MIDCOM + client specific objects. + +1.5.1. COPS Protocol Architecture + + COPS is a simple query and response protocol that can be used to + exchange policy information between a policy server (Policy Decision + Point or PDP) and its clients (Policy Enforcement Points or PEPs). + COPS was defined to be a simple and extensible protocol. The main + characteristics of COPS include the following: + + 1. The protocol employs a client/server model. The PEP sends + requests, updates, and deletions to the remote PDP and the PDP + returns decisions back to the PEP. + + 2. The protocol uses TCP as its transport protocol for reliable + exchange of messages between policy clients and a server. + + 3. The protocol is extensible in that it is designed to leverage + self-identifying objects and can support diverse client specific + information without requiring modification of the COPS protocol. + + 4. The protocol was created for the general administration, + configuration, and enforcement of policies. + + 5. COPS provides message level security for authentication, replay + protection, and message integrity. COPS can make use of existing + protocols for security such as IPSEC [22] or TLS [21] to + authenticate and secure the channel between the PEP and the PDP. + + 6. The protocol is stateful in two main aspects: + + (1) Request/Decision state is shared and kept synchronized in a + transactional manner between client and server. Requests from + the client PEP are installed or remembered by the remote PDP + until they are explicitly deleted by the PEP. At the same + time, Decisions from the remote PDP can be generated + asynchronously at any time for a currently installed request + state. + + + +Barnes Informational [Page 10] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + (2) State from various events (Request/Decision pairs) may be + inter-associated. The server may respond to new queries + differently because of previously installed, related + Request/Decision state(s). + + 7. The protocol is also stateful in that it allows the server to push + configuration information to the client, and then allows the + server to remove such state from the client when it is no longer + applicable. + +1.5.2. Comparison of COPS and the MIDCOM Framework + + In the MIDCOM framework, the Middlebox enforces the policy controlled + by an application-aware Agent. Thus, when compared to the COPS + architecture, the Middlebox serves as the PEP (COPS Client) and the + MIDCOM Agent serves as the PDP (COPS Policy Server). One major + difference between the COPS protocol model and the MIDCOM protocol + requirements is that MIDCOM requires that the MIDCOM Agent establish + the session. Whereas, the COPS definition is that a PEP (Middlebox) + establishes communication with a PDP (MIDCOM Agent). + +2. Item Level Compliance Evaluation + + This section contains a review of the protocol's level of compliance + to each of the MIDCOM Requirements [1]. The following key will be + used to identify the level of compliancy of each of the individual + protocols: + + T = Total Compliance. Meets the requirement fully. + + P+ = Partial Compliance+. Fundamentally meets the requirement + through the use of extensions (e.g., packages, additional + parameters, etc). + + P = Partial Compliance. Meets some aspect of the requirement, + however, the necessary changes require more than an extension + and/or are inconsistent with the design intent of the + protocol. + + F = Failed Compliance. Does not meet the requirement. + +2.1. Protocol Machinery + + This section describes the compliancy of the proposed protocols + against the protocol machinery requirements from section 2.1 of the + requirements document [1]. A short description of each of the + protocols is provided to substantiate the evaluation. + + + + +Barnes Informational [Page 11] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +2.1.1. Ability to Establish Association Between Agent and Middlebox. + + SNMP: T, RSIP: P+, Megaco: P, Diameter: T, COPS: P + + SNMP: SNMPv3 provides mutual authentication at the user level + (where the user can be an application or a host if desired) via + shared secrets. Each authenticated principal is associated with a + group that has access rights that control the principals ability + to perform operations on specific subsets of data. Failure to + authenticate can generate a SNMP notification (administrator + configurable choice). + + RSIP: RSIP allows sessions to be established between middleboxes + and applications and MIDCOM agents. Authorization credentials + would have to be added to the session establishment request to + allow the middlebox to authorize the session requestor. + + Megaco: There is a directionality component implicit in this + requirement in that the MA initiates the establishment of the + authorized session. Megaco defines this association to be + established in the opposite direction, i.e., the Middlebox(MG) + initiates the establishment. If this restriction is not + considered, then Megaco makes the syntax and semantics available + for the endpoint to initiate the connection. + + Diameter: Although this is out of scope, the Diameter specification + describes several ways to discover a peer. Having done so, a + Diameter node establishes a transport connection (TCP, TLS, or + SCTP) to the peer. The two peers then exchange Capability + Exchange Request/Answer messages to identify each other and + determine the Diameter applications each supports. + + If the connection between two peers is lost, Diameter prescribes + procedures whereby it may be re-established. To ensure that loss + of connectivity is detected quickly, Diameter provides the + Device-Watchdog Request/Answer messages, to be used when traffic + between the two peers is low. + + Diameter provides an extensive state machine to govern the + relationship between two peers. + + COPS: COPS does not meet the directionality part of the + requirement. The definition of COPS allows a PEP (Middlebox) to + establish communication with a PDP (MIDCOM Agent). However, + nothing explicitly prohibits a PDP from establishing communication + + + + + + +Barnes Informational [Page 12] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + with a PEP. The PEP could have local policies dictating what + action to take when it is contacted by an unknown PDP. These + actions, defined in the local policies, would ensure the proper + establishment of an authorized association. + +2.1.2. Agent Can Relate to Multiple Middleboxes + + SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T + + SNMP: An SNMP manager can communicate simultaneously with several + Middleboxes. + + RSIP: RSIP sessions are identified by their IP source and + destination addresses and their TCP / UDP port numbers. Thus each + RSIP client can communicate with multiple servers, and each server + can communicate with multiple clients. However, RSIP did not + explicitly include agents in its design. The architecture and + semantics of RSIP messages do not preclude agents, thus the RSIP + architecture could certainly be extended to explicitly include + agents; therefore RSIP is deemed partially compliant to this + requirement. + + Megaco: Megaco allows an MA to control several Middleboxes. Each + message carries an identifier of the endpoint that transmitted the + message allowing the recipient to determine the source. + + Diameter: Diameter allows connection to more than one peer (and + encourages this for improved reliability). Whether the Diameter + connection state machine is too heavy to support the number of + connections needed is a matter for discussion. + + COPS: COPS PDPs are designed to communicate with several PEPs. + +2.1.3. Middlebox Can Relate to Multiple Agents + + SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T + + SNMP: An SNMP agent can communicate with several SNMP managers + Simultaneously. + + RSIP: Refer to 2.1.2. + + Megaco: Megaco has the concept of Virtual Media Gateways (VMG), + allowing multiple MGCs to communicate simultaneously with the same + MG. Applying this model to MIDCOM would allow the same middlebox + (MG) to have associations with multiple MIDCOM Agents (MGCs). + + + + + +Barnes Informational [Page 13] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + Diameter: Diameter allows connection to more than one peer and + encourages this for improved reliability. Whether the Diameter + connection state machine is too heavy to support the number of + connections needed is a matter for discussion. The Middlebox and + Agent play symmetric roles as far as Diameter peering is + concerned. + + COPS: The COPS-PR framework specifies that a PEP should have a + unique PDP in order to achieve effective policy control. The + COPS-PR protocol would allow the scenario whereby a PEP + establishes communication with multiple PDPs by creating a COPS + client instance per PDP. + +2.1.4. Deterministic Outcome When Multiple Requests are Presented to + the Middlebox Simultaneously + + SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T + + SNMP: While the architectural design of SNMP can permit race + conditions to occur, there are mechanisms defined as part of the + SNMPv3 standard, such as view-based access control and advisory + locking that can be used to prevent the conditions, and MIB + modules may also contain special functionality, such as RMONs + OwnerString, to prevent conflicts. Deterministic behavior of SNMP + agents when being accessed by multiple managers is important for + several management applications and supported by SNMP. + + RSIP: All RSIP requests are defined to be atomic. Near simultaneous + requests are executed as is they were sequential. + + Megaco: Megaco supports the concept of VMGs to make these + interactions deterministic and to avoid resource access conflicts. + Each VMG has a single owner, in a MGC, and there can be no overlap + between the sets of Terminations belonging to multiple VMGs. The + Megaco protocol messages also include the identifier of the + sending entity, so that the MG can easily determine to whom to + send the response or asynchronously report certain events. + + Diameter: Diameter depends partly upon the transport protocol to + provide flow control when the server becomes heavily loaded. It + also has application-layer messaging to indicate that it is too + busy or out of space (Diameter_TOO_BUSY and Diameter_OUT_OF_SPACE + result codes). + + COPS: COPS has built-in support for clear state and policy + instances. This would allow the creation of well-behaved MIDCOM + state machines. + + + + +Barnes Informational [Page 14] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +2.1.5. Known and Stable State + + SNMP: T, RSIP: T, Megaco: T, Diameter: P, COPS: T + + SNMP: Requests are atomic in SNMP. MIB modules can define which + data is persistent across reboots, so a known startup state can be + established. The manager can poll the agent to determine the + current state. + + RSIP: RSIP assumes that on middlebox start-up no sessions are + defined, and thus no allocations have been made. In effect, all + resources are released upon restart after failure. + + Megaco: Megaco has extensive audit capabilities to synchronize + states between the MG and the MGC. Megaco also provides the MGC + with the ability to do mass resets, as well as individual resets. + The MGC can always release resources in the MG. The MG can also + initiate the release of resources by the MGC. + + Diameter: Diameter documentation does not discuss the degree of + atomicity of message processing, so this would have to be + specified in the MIDCOM extension. + + COPS: The COPS protocol maintains synchronized states between + Middleboxes and MA hence all the states are known on both sides. + +2.1.6. Middlebox Status Report + + SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T + + SNMP: The status of a middlebox can be reported using asynchronous + communications, or via polling. + + RSIP: All RSIP client requests have explicit server responses. + Additionally, a client may explicitly request server status using + a QUERY request. + + Megaco: Megaco has extensive audit capabilities for the MG to + report status information to the MGC. It can also report some + status updates using the ServiceChange command. + + Diameter: Diameter provides a number of response codes by means of + which a server can indicate error conditions reflecting status of + the server as a whole. The Disconnect-Peer-Request provides a + means in the extreme case to terminate a connection with a peer + gracefully, informing the other end about the reason for the + disconnection. + + + + +Barnes Informational [Page 15] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + COPS: The COPS Report message is designed to indicate any + asynchronous conditions/events. + +2.1.7. Middlebox Can Generate Unsolicited Messages + + SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T + + SNMP: SNMPv3 supports both confirmed and unconfirmed asynchronous + notifications. + + RSIP: An RSIP server will send an unsolicited DE_REGISTER_RESPONSE + to force an RSIP host to relinquish all of its bindings and + terminate its relationship with the RSIP gateway. An RSIP server + can send an asynchronous ERROR_RESPONSE to indicate less severe + conditions. + + Megaco: Megaco supports the asynchronous notification of events + using the Notify command. + + Diameter: The Diameter protocol permits either peer in a connection + to originate transactions. Thus the protocol supports Middlebox- + originated messages. + + COPS: The COPS Report message is designed to indicate any + asynchronous conditions/events. + +2.1.8. Mutual Authentication + + SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T + + SNMP: SNMPv3 meets this requirement. SNMPv3 supports user + authentication and explicitly supports symmetric secret key + encryption between MIDCOM agent (SNMP manager) and Middlebox (SNMP + agent), thus supporting mutual authentication. The default + authentication and encryption methods are specified in RFC 3414 + [11] (MD5, SHA-1, and DES). Different users at the same + management application (MIDCOM agent) can authenticate themselves + with different authentication and encryption methods, and + additional methods can be added to SNMPv3 entities as needed. + + RSIP: This requirement can be met by operating RSIP over IPSec as + described in RFC 3104 [19]. The RSIP framework recommends all + communication between an RSIP host and gateway be authenticated. + Authentication, in the form of a message hash appended to the end + of each RSIP protocol packet, can serve to authenticate the RSIP + host and gateway to one another, provide message integrity, and + + + + + +Barnes Informational [Page 16] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + avoid replay attacks with an anti-replay counter. However, the + message hash and replay counter parameters would need to be + defined for the RSIP protocol. + + Megaco: Megaco provides for the use of IPSec [22] for all security + mechanisms including mutual authentication, integrity check and + encryption. Use of IKE is recommended with support of RSA + signatures and public key encryption. + + Diameter: The Diameter base protocol assumes that messages are + secured by using either IPSec or TLS [21]. Diameter requires that + when using the latter, peers must mutually authenticate + themselves. + + COPS: COPS has built-in message level security for authentication, + replay protection, and message integrity. COPS can also use TLS + or IPSec. + +2.1.9. Termination of session by either party + + SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T + + SNMP: Each SNMPv3 message is authenticated and authorized, so each + message could be considered to have its own session, which + automatically terminates after processing. Processing may be + stopped for a number of reasons, such as security, and a response + is sent. + + Either peer may stop operating, and be unavailable for further + operations. The authentication and/or authorization parameters of + a principal may be changed between operations if desired, to + prevent further authentication or authorization for security + reasons. + + Additionally, managed objects can be defined for realizing + sessions that persist beyond processing of a single message. The + MIB module would need to specify the responsibility for cleanup of + the objects following normal/abnormal termination. + + RSIP: An RSIP client may terminate a session with a + DE_REGISTER_REQUEST. An RSIP server may terminate a session with + an unsolicited DE_REGISTER_RESPONSE, and then respond to + subsequent requests on the session with a REGISTER_FIRST error. + + Megaco: The Megaco protocol allows both peers to terminate the + association with proper reason code. + + + + + +Barnes Informational [Page 17] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + Diameter: Either peer in a connection may issue a Disconnect-Peer- + Request to end the connection gracefully. + + COPS: COPS allows both the PEP and PDP to terminate a session. + +2.1.10. Indication of Success or Failure + + SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T + + SNMP: Each operation request has a corresponding response message + that contains an error status to indicate success or failure. For + complex requests that the middlebox cannot complete immediately, + the corresponding MIB module may be designed to also provide + asynchronous notifications of the success or failure of the + complete transaction, and/or may provide pollable objects that + indicate the success or failure of the complete transaction. For + example, see ifAdminStatus and ifOperStatus in RFC 2863 [28]. + + RSIP: All RSIP requests result in a paired RSIP response if the + request was successful or an ERROR_RESPONSE if the request was not + successful. + + Megaco: Megaco defines a special descriptor called an Error + descriptor that contains the error code and an optional + explanatory string. + + Diameter: Every Diameter request is matched by a response, and this + response contains a result code as well as other information. + + COPS: The COPS Report message directly fulfills this requirement. + +2.1.11. Version Interworking + + SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T + + SNMP: SNMP has a separation of the protocol to carry data, and the + data that defines additional management functionality. Additional + functionality can be added easily through MIBs. Capability + exchange in SNMP is usually uni-directional. Managers can query + the middlebox (SNMP agent) to determine which MIBs are supported. + In addition, multiple message versions can be supported + simultaneously, and are identified by a version number in the + message header. + + RSIP: Each RSIP message contains a version parameter. + + Megaco: Version interworking and negotiation are supported both for + the protocol and any extension Packages. + + + +Barnes Informational [Page 18] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + Diameter: The Capabilities Exchange Request/Answer allows two peers + to determine information about what each supports, including + protocol version and specific applications. + + COPS: The COPS protocol can carry a MIDCOM version number and + capability negotiation between the COPS client and the COPS + server. This capability negotiation mechanism allows the COPS + client and server to communicate the supported + features/capabilities. This would allow seamless version + interworking. + +2.1.12. Deterministic Behaviour in the Presence of Overlapping + Rules + + SNMP: T, RSIP: T, Megaco: P, Diameter: T, COPS: T + + SNMP: Rulesets would be defined in MIBs. The priority of rulesets, + and the resolution of conflict, can be defined in the MIB module + definition. The SNMPConf policy MIB defines mechanisms to achieve + deterministic behavior in the presence of overlapping rule sets. + + RSIP: All requests for allocation of IP addresses, or ports or both + resulting in rule overlap are rejected by an RSIP server with a + LOCAL_ADDR_INUSE error. + + Megaco: This is met with the help of a model that separates Megaco + protocol elements from the overlapping Policy rules (see Appendix + C). However, new behavior for the Megaco protocol elements needs + to be specified as part of a new MIDCOM specific Package. + + Diameter: The IPFilterRule type specification, which would probably + be used as the type of a Policy Rule AVP, comes with an extensive + semantic description providing a deterministic outcome, which the + individual Agent cannot know unless it knows all of the Policy + Rules installed on the Middlebox. Rules for the appropriate + direction are evaluated in order, with the first matched rule + terminating the evaluation. Each packet is evaluated once. If no + rule matches, the packet is dropped if the last rule evaluated was + a permit, and passed if the last rule was a deny. The + IPFilterRule format and further details on its applicability to + this requirement are provided in Appendix D. + + COPS: The COPS protocol provides transactional-based communication + between the PEP and PDP, hence the behavior is totally + deterministic provided the middlebox state machine is designed + correctly. The COPS protocol features encourage and support good + state machine design. + + + + +Barnes Informational [Page 19] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +2.2. Protocol Semantics + + This section contains the individual protocols as evaluated against + the protocol semantic requirements from section 2.2 of the + requirements document [1]. A short description of each of the + protocols is provided to substantiate the evaluation. + +2.2.1. Extensibility + + SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T + + SNMP: Extensibility is a basic feature of the SNMP management + Framework. + + RSIP: All RSIP messages consist of three mandatory fields (protocol + version, message type, and message length) and a sequence of + parameterType / length / value 3-tuples. New messages may be + defined by defining new values for the message type field. New + parameter types may be defined, and existing messages may be + extended, by defining new parameterType values. If new messages, + parameters, or both are added in a non-backward compatible way, a + new value of the protocol version field may be defined. This may + be desirable even of the additions are backward compatible. + + Megaco: Megaco is easily extensible through new Packages, which + allow definition of new attributes and behavior of a Termination. + + Diameter: Diameter provides a great deal of flexibility for + extensions, including allowance for vendor-defined commands and + AVPs and the ability to flag each AVP as must-understand or + ignorable if not understood. + + COPS: The COPS protocol is extensible, since it was designed to + separate the Protocol from the Policy Control Information. + +2.2.2. Support of Multiple Middlebox Types + + SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T + + SNMP: SNMP explicitly supports managing different device types with + different capabilities. First the managed object called + sysObjectID from basic MIB-II [3] identifies the type of box. For + boxes with variable capabilities, SNMP can check the availability + of corresponding MIBs. + + + + + + + +Barnes Informational [Page 20] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + RSIP: All types of middleboxes are supported so long as the ruleset + action is permit. Other actions would require the definition of a + new RSIP message parameter with values for permit and the other + desired actions. + + Megaco: Megaco can support multiple Middlebox types on the same + interface either by designing the properties representing the + Policy Rules to provide this support, or by using multiple + terminations in the same session, each representing one type of + action. In the latter case, the Megaco Context can be used as a + convenient means of managing the related terminations as a group. + However, the inherent idea of flow between terminations of a + context is irrelevant and would have to be discarded. + + Diameter: Any necessary additional AVPs or values must be specified + as part of the MIDCOM application extension (see <2.2.8> below). + + COPS: COPS allows a PDP to provide filters and actions to multiple + PEP functions through a single COPS session. + +2.2.3. Ruleset Groups + + SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T + + SNMP: This requirement can be realized via the SNMP management + framework by an appropriate definition of a MIB module. The + SNMPConf WG has already defined an SNMP Policy MIB that permits + the definitions of policy rulesets and grouping of rulesets. + + RSIP: RSIP currently only allows one IP address, or address and + port range, to be assigned to a bind-ID. RSIP could implement + rulesets as required by adding an optional bind-ID parameter to + the ASSIGN_REQUESTs to extend an existing ruleset rather than + creating a new one. Similarly, the FREE_REQUESTs would have to be + extended by adding optional, local and remote, address and port + parameters. + + Megaco: The Megaco context can be used to group terminations to be + managed together. For example, all of the terminations, each + representing an instantiation of a Policy Rule, can be deleted in + one command by doing a wildcarded Subtract from the context. + However, the inherent idea of media flows between terminations of + a context would be irrelevant in this application of the protocol. + + Diameter: Diameter allows message syntax definitions where multiple + instances of the same AVP (for example, a Policy Rule AVP whose + syntax and low-level semantics are defined by the IPFilterRule + type definition) may be present. If a tighter grouping is + + + +Barnes Informational [Page 21] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + required, the set of Diameter base types includes the Grouped + type. MIDCOM can choose how to make use of these capabilities to + meet the ruleset group requirement when defining its application + extension to the Diameter protocol. + + COPS: The COPS-PR Handle State may be used to associate the set of + closely related policy objects. As the Middlebox learns + additional requirements, the Middlebox adds these resource + requirements under the same handle ID, which constitutes the + required aggregation. + +2.2.4. Lifetime Extension + + SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+ + + SNMP: This requirement can be realized via the SNMP management + framework by an appropriate definition of a MIB module. The + SNMPConf WG has developed a Policy MIB module that includes a + pmPolicySchedule object with a modifiable lifetime. + + RSIP: A client may request an explicit lease time when a request is + made to assign one or more IP addresses, ports or both. The + server may grant the requested lease time, or assign one if none + was requested. Subsequently, the lease time may be extended if a + client's EXTEND_REQUEST is granted by the server. + + Megaco: The MG can report the imminent expiry of a policy rule to + the MGC, which can then extend or delete the corresponding + 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. + + + + + + + + + + +Barnes Informational [Page 22] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +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. + + + + +Barnes Informational [Page 23] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 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. + + + +Barnes Informational [Page 24] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +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. + + + + +Barnes Informational [Page 25] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 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. + + + + + + +Barnes Informational [Page 26] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 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. + + + +Barnes Informational [Page 27] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +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 + + + + +Barnes Informational [Page 28] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 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 + + + + + +Barnes Informational [Page 29] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 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. + + + + + +Barnes Informational [Page 30] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +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. + + + + +Barnes Informational [Page 31] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + [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. + + + + +Barnes Informational [Page 32] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes Informational [Page 33] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +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 + [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]) provides a standardized + mechanism to configure an intermediate node to forward SNMP messages. + A command generating entity sends requests to a proxy forwarding + entity that forwards the request to a third entity. + + One SNMP entity may serve both functions as the SNMP agent to monitor + and configure the node on which it is resident, and as an + intermediate node in a proxy relationship to permit monitoring and + configuration of additional entities. + + Each entity is identified by a unique engineID value, specifically to + support proxy between addressing domains and/or trust domains. An + SNMPv3 message contains two engineIDs- one to identify the database + to be used for message security, and one to identify the source (or + target) of the contained data. Message security is applied between + the originator and the proxy, and then between the proxy and the + + + +Barnes Informational [Page 34] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + end-target. The PDU contains the engineID of the node whose data is + contained in the message, which passes end-to-end, unchanged by the + proxy. + + SNMPv3 proxy was designed to provide a standard SNMP approach to + inserting an intermediate node in the middle of communications for a + variety of scenarios. SNMPv3 proxy can support crossing addressing + domains, such as IPv4 and IPv6, crossing SNMP version domains, such + as SNMPv3 and SNMPv1, crossing security mechanism domains, such as + DES and AES, and for providing 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 + + Proxies are generally preferred to Application Level Gateways for + SNMP. ALGs typically modify the headers and content of messages. + SNMP is a protocol designed for troubleshooting network (mis-) + configurations. Because an operator needs to understand the actual + configuration, the translation of addresses within SNMP data causes + confusion, hiding the actual configuration of a managed device from + the operator. ALGs also introduce security vulnerabilities, and + other complexities related to modifying SNMP data. + + SNMP Proxies can modify message headers without modifying the + contained data. This avoids the issues associated with translating + the payload data, while permitting 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. In + addition to the NAT null tunnel, the host would have to implement an + RSIP / MIDCOM client (or a STUN client) and the middlebox would have + + + +Barnes Informational [Page 35] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 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 + would require the modification of host applications or the + implementation of application agents, both of which would include an + RSIP / MIDCOM client, and the implementation of 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/disadvantages of tunneling would need to be evaluated in + considering RSIP. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barnes Informational [Page 36] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +Appendix C - Megaco Modeling Approach + + To model the Middlebox functions such as firewall, NAT etc., a new + Middlebox Termination type needs to be defined within Megaco. If + policy-rule overlap or modification by multiple Agents is NOT + required, then a policy rule is equivalent to a Termination (see + Figure 1). The various components of a Policy rule such as filter, + action, life-time, creator etc. are described as various properties + of a Termination. Use of the Virtual Media Gateway (VMG) concept + allows for conflict-free interaction of multiple MA's with the same + MB. + + +-------+ +-------+ + | MA-1 | | MA-2 | + | | | | + +-------+ |IF2 +-------+ + | | | + +-------------|---------|----------|-----------+ + | +---------+ | +-------------+ | + 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. + + + + + + + + + + + + + + + + +Barnes Informational [Page 37] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + If it is required to allow multiple agents manipulate the same + Middlebox resource (e.g., a Policy rule or a filter), the latter + needs to be kept separate from the Termination (the Policy rule is + manipulated by the MA by manipulating the properties of the + associated Termination). For example, if overlapping policy rule + manipulation is required, then a Termination shall be associated with + a single policy rule, but a policy rule may be associated with more + than one Termination. Thus, a Termination can share a policy rule + with another Termination, or have a policy rule partially overlapping + with that of another Termination. This model allows two MAs, + controlling two distinct Terminations (see Figure 2), manipulate the + same or overlapping policy rules. In Figure 2, policy rules 1 and 2 + are overlapping and they are shared by MA-1 and MA-2. + + +-------+ +-------+ + | MA-1 | | MA-2 | + | | | | + +-------+ |IF2 +-------+ + | | | MB + +-------------|---------|----------|-----------+ + | +-----------+ | +-------------+ | + IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3 + ------------------|Ty|----+ +---|Tx|--|Tz|---------------- + | | +--+ | | | +--+ +--+ | | + | .... | | | | +--/------\---+ | + | +-------|---+ | / \ | + | | +----/----------\------------------ + | +------+----+------+ +------+ |IF4 + | |Policy1 Policy2 | |Policy| | + | | | | | | 3 | | + | +----+------+------+ +------+ | + +----------------------------------------------+ + + Tx: Termination x + Ty: Termination y + Tz: Termination z + MA: MIDCOM Agent + IF: Interface + MB: Middlebox + + Figure 2. + + This requires that the Agent and the Middlebox adhere to the + following principles: + + (1) Only one Termination has read/write access to a filter at any + time. + + + + +Barnes Informational [Page 38] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + (2) When the policy rule is being modified by a new agent (i.e., not + the one that created the policy) the Middlebox makes a policy + decision and decides whether to accept the requested modification + or not. In the case the modification is accepted the initial + MIDCOM agent may be notified. + +Appendix D - Diameter IPFilter Rule + + The IPFilterRule format is derived from the OctetString AVP Base + Format. It uses the UTF-8 encoding and has the same requirements as + the UTF8String. Packets may be filtered based on the following + information that is associated with it: + + 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 types + + Rules for the appropriate direction are evaluated in order, with the + first matched rule terminating the evaluation. Each packet is + evaluated once. If no rule matches, the packet is dropped if the + last rule evaluated was a permit, and passed if the last rule was a + deny. + + IPFilterRule filters MUST follow the format: + + action dir proto from src to dst [options] + + 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] + + + + + + + + + +Barnes Informational [Page 39] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + The <address/mask> may be specified as: + + 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" + + The sense of the match can be inverted by + preceding an address with the not modifier (!), + causing all other addresses to be matched + instead. This does not affect the selection of + port numbers. + + With the TCP, UDP and SCTP protocols, optional + ports may be specified as: + + {port|port-port}[,ports[,...]] + + The '-' notation specifies a range of ports + (including boundaries). + + Fragmented packets that have a non-zero offset + (i.e., not the first fragment) will never match + a rule that has one or more port + specifications. See the frag option for + details on matching fragmented packets. + + + + +Barnes Informational [Page 40] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 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. + + + + + +Barnes Informational [Page 41] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + 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 that the access device MUST always + discard, that is an IP fragment with a fragment offset of one. This + is a valid packet, but it only has one use, to try to circumvent + firewalls. + + An access device that is unable to interpret or apply a deny rule + MUST terminate the session. An access device that is unable to + interpret or apply a permit rule MAY apply a more restrictive rule. + An access device MAY 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 + + The following identifies the key contributors who provided the + primary content for this document in the form of individual documents + for each protocol: + + RSIP: + + Jim Renkel + + SNMP: + + Juergen Quittek + NEC Europe Ltd. + EMail: quittek@ccrle.nec.de + + + + +Barnes Informational [Page 42] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + + David Harrington + Co-chair SNMPv3 WG + EMail: dbh@enterasys.com + + 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 + + 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 + +Author's Address + + Mary Barnes + Nortel + 2201 Lakeside Blvd. + Richardson, TX USA + + Phone: 1-972-684-5432 + EMail: mary.barnes@nortel.com + + + +Barnes Informational [Page 43] + +RFC 4097 MIDCOM Protocol Evaluation June 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain 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 takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet + gement + + + + + + +Barnes Informational [Page 44] + |