Skip to main content

Middlebox Communications (MIDCOM) Protocol Evaluation
draft-ietf-midcom-protocol-eval-06

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4097.
Author Mary Barnes
Last updated 2015-10-14 (Latest revision 2002-11-21)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4097 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Scott O. Bradner
Send notices to (None)
draft-ietf-midcom-protocol-eval-06
Internet Draft                                               M. Barnes 
 Document: draft-ietf-midcom-protocol-eval-06.txt                Editor 
 Category: Informational                                Nortel Networks 
 Expires: May 2003                                           Nov. 2002 
  
           Middlebox Communications (MIDCOM) Protocol Evaluation  
      
 Status of this Memo  
     
    This document is an Internet-Draft and is in full conformance with 
    all provisions of Section 10 of RFC2026.  
         
    Internet-Drafts are working documents of the Internet Engineering 
    Task Force (IETF), its areas, and its working groups.  Note that 
    other groups may also distribute working documents as Internet-
    Drafts.  
         
    Internet-Drafts are draft documents valid for a maximum of six 
    months and may be updated, replaced, or obsoleted by other 
    documents at any time. It is inappropriate to use Internet-Drafts 
    as reference material or to cite them other than as "work in 
    progress."  
         
    The list of current Internet-Drafts can be accessed at  
         http://www.ietf.org/ietf/1id-abstracts.txt  
    The list of Internet-Draft Shadow Directories can be accessed at  
         http://www.ietf.org/shadow.html.  
         
 Abstract  
     
    This document provides an evaluation of the applicability of SNMP, 
    RSIP, Megaco, Diameter and COPS as the MIDCOM 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 
     
    1 Protocol Proposals.............................................2 
       1.1 SNMP......................................................3 
       1.2 RSIP......................................................4 
       1.3 Megaco....................................................6 
       1.4 Diameter..................................................7 
       1.5 COPS......................................................8 
    2 Item Level Compliance Evaluation...............................9 
       2.1 Protocol machinery........................................9 
       2.2 Protocol semantics.......................................16 
       2.3 General Security Requirements............................22 
    3 Conclusions...................................................24 
    Security Considerations.........................................25 
    Normative References............................................25 
    Informative References..........................................27 
    Appendix A - SNMP Overview......................................29 
    Appendix B - RSIP with tunneling................................30 
    Appendix C - Megaco Modeling Approach...........................31 
    Appendix D - Diameter IPFilter Rule.............................32 
    Intellectual Property Statements................................35 
    Full Copyright Statement........................................35 
        
  
  
 Barnes                    Expires û May 2003                 [Page 1] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
 Overview  
         
    This document provides an evaluation of the applicability of SNMP, 
    RSIP, Megaco, Diameter and COPS as the MIDCOM 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 draft 
    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 draft.  The 
    updated versions of these drafts formed the basis for the content 
    of this WG document.  
     
    Section 1 contains a list of the proposed protocols submitted for 
    the purposes of the protocol evaluation with some background 
    information on the protocols and similarities and differences with 
    regards to the applicability to the framework [2] provided.  
     
    Section 2 provides the item level evaluation of the proposed 
    protocols against the Requirements [1]. 
     
    Section 3 provides a summary of the evaluation.  A table containing 
    a numerical breakdown for each of the protocols, with regards to 
    its applicability to the requirements, for the following categories 
    is provided: Fully met, Partially met through the use of 
    extensions, Partially met through other changes to the protocol, or 
    Failing to be met.  This summary is not meant to provide a 
    conclusive statement of the suitability of the protocols, but 
    rather to provide information to be considered as input into the 
    overall protocol decision process. 
     
    In order for this document to serve as a complete evaluation of the 
    protocols, some of the background information and more detailed 
    aspects of the proposals documenting enhancements and applications 
    of the protocols to comply with the MIDCOM framework and 
    requirements are included in Appendices.    
     
 Conventions used in this document  
         
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
    this document are to be interpreted as described in 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  
     
  
  
 Barnes                    Expires - May 2003                 [Page 2] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    The following provides an overview of each of the protocols and the 
    applicability of each protocol to the MIDCOM framework. 
  
 1.1 SNMP 
     
    This section provides a general statement with regards to the 
    applicability of SNMP as the MIDCOM protocol. A general overview 
    and some specific details of SNMP are provided in Appendix A. This 
    evaluation of SNMP is specific to SNMPv3, which provides the 
    security required for MIDCOM usage. SNMPv1 and SNMPv2c would be 
    inappropriate for MIDCOM since they have been declared Historic, 
    and because their messages have only trivial security.  Some 
    specifics with regards to existing support for NAT and Firewall 
    Control are provided in section 1.1.2.  The differences between the 
    SNMP framework and the MIDCOM framework are addressed in section 
    1.1.3. 
     
  
    1.1.1 SNMP General Applicability 
     
    The primary advantages of SNMPv3 are that it is a mature, well 
    understood protocol, currently deployed in various scenarios, with 
    mature toolsets available for SNMP managers and agents.  
     
    Application intelligence is captured in MIB modules, rather than in 
    the messaging protocol. MIB modules define a data model of the 
    information that can be collected and configured for a managed 
    functionality. The SNMP messaging protocol transports the data in a 
    standardized format without needing to understand the semantics of 
    the data being transferred. The endpoints of the communication 
    understand the semantics of the data. 
     
    Partly due to the lack of security in SNMPv1 and SNMPv2c, and 
    partly due to variations in configuration requirements across 
    vendors, few MIB modules have been developed that enable 
    standardized configuration of managed devices across vendors. Since 
    monitoring can be done using only a least-common-denominator subset 
    of information across vendors, many MIB modules have been developed 
    to provide standardized monitoring of managed devices. As a result, 
    SNMP has been used primarily for monitoring rather than for 
    configuring network nodes. 
         
    SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c 
    versions. Specifically, SNMPv3 shares the separation of data 
    modeling (MIBs) from the protocol to transfer data, so all existing 
    MIBs can be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, 
    and it shares operations and transport with SNMPv2c. The major 
    difference between SNMPv3 and earlier versions is the addition of 
    strong message security and controlled access to data. 
     
    SNMPv3 uses the architecture detailed in RFC2571, 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 
  
  
 Barnes                    Expires - May 2003                 [Page 3] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
     
    For configuring NATs, there is currently a NAT MIB module [NAT-MIB] 
    under development. The NAT MIB module meets all of the MIDCOM 
    requirements concerning NAT control with the exception of grouping 
    of policy rules (requirement 2.2.3.). In order to support this, an 
    additional grouping table in the NAT MIB module is required.  
     
    Existing work for firewall control with SNMP only considered the 
    monitoring of firewalls and not the configuration. Further work is 
    required towards the development of MIBs for configuring firewalls.  
     
    1.1.3 Architectural Differences between SNMP and MIDCOM 
     
    The SNMP management framework provides functions equivalent to 
    those defined by the MIDCOM framework, although there are a few 
    architectural differences.  
     
    Traditionally, SNMP entities have been called Manager and Agent. 
    Manager and agent are now recognized as entities designed to 
    support particular configurations of SNMPv3 functions. A 
    traditional manager is an entity capable of generating requests and 
    receiving notifications, and a traditional agent is an entity 
    capable of responding to requests and generating notifications.  
    The SNMP use of the term agent is different from its use in the 
    MIDCOM framework: The SNMP Manager corresponds to the MIDCOM agent 
    and the SNMP Agent corresponds to the MIDCOM PDP.  The SNMP 
    evaluation assumes that the MIDCOM PDP (SNMP Agent) is physically 
    part of the middlebox, which is allowed by the MIDCOM framework as 
    described in section 6.0 of [2].  Thus, for the purpose of this 
    evaluation, the SNMP agent corresponds to the Middlebox.  
     
    While this evaluation is based on the assumption that the SNMP 
    agent corresponds to the middlebox, SNMP does not force such a 
    restriction.  
      
    Proxy means many things to many people. SNMP can be deployed using 
    intermediate entities to forward messages, or to help distribute 
    policies to the middlebox, similar to the proxy capabilities of the 
    other candidate protocols. Since proxy adds configuration and 
    deployment complexity and is not necessary to meet the specified 
    MIDCOM requirements, the use of a proxy agent or mid-level manager 
    is not considered in this evaluation. Further details on SNMP proxy 
    capabilities are provided in Appendix A.  
  
    Although the SNMP management framework does not have the concept of 
    a session, session-like associations can be established through the 
    use of managed objects. In order to implement the MIDCOM protocol 
    based on SNMP, a MIDCOM MIB module is required. All requests from 
    the MIDCOM agent to the Middlebox would be performed using write 
    access to managed objects defined in the MIDCOM MIB module. Replies 
    to requests are signaled by the Middlebox (SNMP agent), by 
    modifying the managed objects. The MIDCOM agent (SNMP manager) can 
    receive this information by reading or polling, if required, the 
    corresponding managed object. 
  
 1.2 RSIP 
     
    1.2.1 Framework elements in common to MIDCOM and RSIP 
     
  
  
 Barnes                    Expires - May 2003                 [Page 4] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    The following framework elements are common to MIDCOM and RSIP 
    listed by their MIDCOM names, with the RSIP name indicated in 
    parenthesis: 
     
    o Hosts 
    o Applications 
    o Middleboxes (RSIP gateways) 
    o Private domain (private realm) 
    o External domain (public realm) 
    o Middlebox communication protocol (RSIP) 
    o MIDCOM agent registration (host registration) 
    o MIDCOM session (RSIP session) 
    o MIDCOM Filter (local / remote address and port number(s) pairs) 
     
    1.2.2 MIDCOM Framework elements not supported by RSIP 
     
    The following MIDCOM framework elements are not supported by RSIP:  
     
    o  Policy actions and rules. RSIP always implicitly assumes a 
       permit action. To support MIDCOM, a more general and explicit 
       action parameter would have to be defined. RSIP requests 
       specifying local / remote address and port number(s) pairs would 
       have to be extended to include an action parameter, in MIDCOM 
       rules. 
        
    o  MIDCOM agents. RSIP makes no distinction between applications 
       and agents; address assignment operations can be performed 
       equally by applications and agents. 
        
    o  Policy Decision Points. RSIP assumes that middleboxes grant or 
       deny requests with reference to a policy known to them; the 
       policy could be determined jointly by the middlebox and a policy 
       decision point; such joint determination is not addressed by the 
       RSIP framework, nor is it specifically precluded. 
     
    1.2.3 RSIP Framework elements not supported by MIDCOM 
     
    The following elements are unique to the RSIP framework. If RSIP 
    were adopted as the basis for the MIDCOM protocol, they could be 
    added to the MIDCOM framework: 
     
    o RSIP client: that portion of the application (or agent) that 
      talks to the RSIP gateway using RSIP. 
     
    o RSIP server: that portion of an RSIP gateway that talks to 
      applications using RSIP. 
        
    o Realm Specific Address IP (RSA-IP) and Realm Specific Address and 
      Port IP (RSAP-IP): RSIP distinguishes between filters that 
      include all ports on an IP address and those that do not. 
        
    o Demultiplexing Fields: Any set of packet header or payload fields 
      that an RSIP gateway uses to route an incoming packet to an RSIP 
      host. RSIP allows a gateway to perform, and an application to 
      control, packet routing to hosts in the private domain based on 
      more than IP header fields. 
        
    o Host-to-middlebox tunnels: RSIP assumes that data communicated 
      between a private realm host and a public realm host is 
      transferred through the private realm by a tunnel between the 
  
  
 Barnes                    Expires - May 2003                 [Page 5] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
      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 in which 
    Media Gateway Controllers (MGC) control the operation of Media 
    Gateways (MG). Originally designed to control IP Telephony   
    gateways, it is used between an application-unaware device (the 
    Media Gateway) and an intelligent entity (the Media Gateway   
    Controller) having application awareness.    
                   
    The Megaco model includes the following key concepts:   
                   
    1. Terminations: Logical entities on the MG that act as sources or   
    sink of packet streams. A termination can be physical or ephemeral 
    and is associated with a single MGC.   
                   
    2. Context: An association between Terminations for sharing media   
    between the Terminations. Terminations can be added, subtracted 
    from a Context and can be moved from one Context to another. A 
    Context and all of its Terminations are associated with a single 
    MGC.   
                   
    3. Virtual Media Gateways: A physical MG can be partitioned into   
    multiple virtual MGs allowing multiple Controllers to interact with 
    disjoint sets of Contexts/Terminations within a single physical 
    device.   
                   
    4. Transactions/Messages: Each Megaco command applies to one   
    Termination within a Context and generates a unique response.  
    Commands may be replicated implicitly so that they act on all   
    Terminations of a given Context through wildcarding of Termination   
    identifiers. Multiple commands addressed to different Contexts can   
    be grouped in a Transaction structure. Similarly, multiple   
    Transactions can be concatenated into a Message.   
                   
  
  
 Barnes                    Expires - May 2003                 [Page 6] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    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 the MIDCOM Agent (MA) and 
    the Media Gateway serves a role similar to the Middlebox (MB). One 
    major difference between the Megaco model and the MIDCOM protocol 
    requirements is that MIDCOM requires that the MIDCOM Agent 
    establish the session. Whereas, the Megaco definition is that a MG 
    (Middlebox) establishes communication with an MGC (MIDCOM Agent). 
     
     
 1.4 Diameter 
     
    1.4.1 Diameter Architecture  
         
    Diameter is designed to support AAA for network access.  It is 
    meant to operate through networks of Diameter nodes, which both act 
    upon and route messages toward their final destinations.  Endpoints 
    are characterized as either clients, which perform network access 
    control, or servers, which handle authentication, authorization and 
    accounting requests for a particular realm.  Intermediate nodes 
    perform relay, proxy, redirect, and translation services.  Design 
    requirements for the protocol [29] 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 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 
  
  
 Barnes                    Expires - May 2003                 [Page 7] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    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 and COPS-PR 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 [IPSEC] or TLS to authenticate  
  
  
 Barnes                    Expires - May 2003                 [Page 8] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    and secure the channel between the PEP and the PDP.  
         
    6. The protocol is stateful in two main aspects:   
    (1)  Request/Decision state is shared and kept synchronized in a  
    transactional manner between client and server. Requests from the 
    client PEP are installed or remembered by the remote PDP until they 
    are explicitly deleted by the PEP. At the same time, Decisions from 
    the remote PDP can be generated asynchronously at any time for a 
    currently installed request state.  
    (2) State from various events (Request/Decision pairs) may be 
    inter-associated. The server may respond to new queries differently 
    because of previously installed, related Request/Decision state(s).  
         
    7. The protocol is also stateful in that it allows the server to 
    push configuration information to the client, and then allows the 
    server to remove such state from the client when it is no longer 
    applicable. 
     
    1.5.2 Comparison of COPS and the MIDCOM Framework  
         
    In the MIDCOM framework, the Middlebox enforces the policy   
    controlled by an application-aware Agent. Thus, when compared to 
    the COPS architecture, the Middlebox serves as the PEP (COPS 
    Client) and the MIDCOM Agent serves as the PDP (COPS Policy 
    Server).  One major difference between the COPS protocol model and 
    the MIDCOM protocol requirements is that MIDCOM requires that the 
    MIDCOM Agent establish the session.  Whereas, the COPS definition 
    is that a PEP (Middlebox) establishes communication with a PDP 
    (MIDCOM Agent). 
     
 2 Item Level Compliance Evaluation 
     
    This section contains a review of the protocol's level of 
    compliance to each of the MIDCOM Requirements [1]. The following 
    key will be used to identify the level of compliancy of each of the 
    individual protocols: 
     
    T = Total Compliance.  Meets the requirement fully. 
     
    P+ = Partial Compliance+.  Fundamentally meets the requirement   
          through the use of extensions (e.g. packages, additional 
          parameters, etc).  
           
    P = Partial Compliance.  Meets some aspect of the requirement,  
          however, the necessary changes require more than an extension 
          and/or are inconsistent with the design intent of the 
          protocol.  
           
    F = Failed Compliance.  Does not meet the requirement.  
  
     
 2.1 Protocol machinery 
     
    This section describes the compliancy of the proposed protocols 
    against the protocol machinery requirements from section 2.1 of the 
    requirements document [1].  A short description of each of the 
    protocols is provided to substantiate the evaluation.  
     
    2.1.1 Ability to establish association between Agent and Middlebox. 
     
  
  
 Barnes                    Expires - May 2003                 [Page 9] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    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 principalÆs ability 
    to perform operations on specific subsets of data. Failure to 
    authenticate can generate a SNMP notification (administrator 
    configurable choice). 
  
    RSIP: RSIP allows sessions to be established between middleboxes 
    and applications and MIDCOM agents. Authorization credentials would 
    have to be added to the session establishment request to allow the 
    middlebox to authorize the session requestor. 
     
    Megaco: There is a directionality component implicit in this    
    requirement in that the MA initiates the establishment   
    of the authorized session. Megaco defines this association to   
    be established in the opposite direction, i.e., the Middlebox(MG) 
    initiates the establishment. If this restriction is not considered, 
    then Megaco makes the syntax and semantics available for the 
    endpoint to initiate the connection. 
     
    Diameter: Although this is out of scope, the Diameter specification 
    describes several ways to discover a peer.  Having done so, a 
    Diameter node establishes a transport connection (TCP, TLS, or 
    SCTP) to the peer.  The two peers then exchange Capability Exchange 
    Request/Answer messages to identify each other and determine the 
    Diameter applications each supports.  
     
    If the connection between two peers is lost, Diameter prescribes 
    procedures whereby it may be re-established.  To ensure that loss 
    of connectivity is detected quickly, Diameter provides the Device-
    Watchdog Request/Answer messages, to be used when traffic between 
    the two peers is low.  
         
    Diameter provides an extensive state machine to govern the 
    relationship between two peers. 
     
    COPS: COPS does not meet the directionality part of the 
    requirement. The definition of COPS allows a PEP (Middlebox) to 
    establish communication with a PDP (MIDCOM Agent). However, nothing 
    explicitly prohibits a PDP from establishing communication with a 
    PEP. The PEP could have local policies dictating what action to 
    take when it is contacted by an unknown PDP. These actions, defined 
    in the local policies, would ensure the proper establishment of an 
    authorized association. 
     
  
    2.1.2 Agent can relate to multiple Middleboxes 
     
    SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T 
     
    SNMP:  An SNMP manager can communicate simultaneously with several 
    Middleboxes. 
     
    RSIP: RSIP sessions are identified by their IP source and 
    destination addresses and their TCP / UDP port numbers. Thus each 
    RSIP client can communicate with multiple servers, and each server 
    can communicate with multiple clients. However, RSIP did not 
  
  
 Barnes                    Expires - May 2003                [Page 10] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    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 Middle Boxes. Each 
    message carries an identifier of the endpoint that transmitted the 
    message allowing the recipient to determine the source. 
     
    Diameter: Diameter allows connection to more than one peer (and 
    encourages this for improved reliability).  Whether the Diameter 
    connection state machine is too heavy to support the number of 
    connections needed is a matter for discussion. 
     
    COPS: COPS PDPs are designed to communicate with several PEPs. 
     
     
    2.1.3 Middlebox can relate to multiple Agents     
     
    SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T 
     
    SNMP:  An SNMP agent can communicate with several SNMP managers 
    Simultaneously. 
     
    RSIP: Refer to 2.1.2. 
     
    Megaco: Megaco has the concept of Virtual Media Gateways (VMG), 
    allowing multiple MGCs to communicate simultaneously with the same 
    MG. Applying this model to MIDCOM would allow the same middlebox 
    (MG) to have associations with multiple MIDCOM Agents (MGCs). 
  
    Diameter: Diameter allows connection to more than one peer and 
    encourages this for improved reliability.  Whether the Diameter 
    connection state machine is too heavy to support the number of 
    connections needed is a matter for discussion. The Middlebox and 
    Agent play symmetric roles as far as Diameter peering is concerned. 
     
    COPS: The COPS-PR framework specifies that a PEP should have a 
    unique PDP in order to achieve effective policy control. The COPS-
    PR protocol would allow the scenario whereby a PEP establishes 
    communication with multiple PDPs by creating a COPS client instance 
    per PDP.  
  
  
    2.1.4 Deterministic outcome when multiple requests are presented to 
    the Middlebox simultaneously 
     
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP:  While the architectural design of SNMP can permit race 
    conditions to occur, there are mechanisms defined as part of the 
    SNMPv3 standard, such as view-based access control and advisory 
    locking that can be used to prevent the conditions, and MIB modules 
    may also contain special functionality, such as RMONÆs 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. 
     
     
  
  
 Barnes                    Expires - May 2003                [Page 11] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    RSIP: All RSIP requests are defined to be atomic. Near simultaneous 
    requests are executed as is they were sequential. 
  
    Megaco: Megaco supports the concept of VMGs to make these 
    interactions deterministic and to avoid resource access conflicts. 
    Each VMG has a single owner, in a MGC, and there can be no overlap 
    between the sets of Terminations belonging to multiple VMGs. The 
    Megaco protocol messages also include the identifier of the sending 
    entity, so that the MG can easily determine to whom to send the 
    response or asynchronously report certain events. 
     
    Diameter: Diameter depends partly upon the transport protocol to 
    provide flow control when the server becomes heavily loaded. It 
    also has application-layer messaging to indicate that it is too 
    busy or out of space (Diameter_TOO_BUSY and Diameter_OUT_OF_SPACE 
    result codes). 
     
    COPS: COPS has built-in support for clear state and policy 
    instances. This would allow the creation of well-behaved MIDCOM 
    state machines. 
         
     
    2.1.5 Known and stable state 
     
    SNMP: T, RSIP: T, Megaco: T, Diameter: P, COPS: T 
     
    SNMP:  Requests are atomic in SNMP. MIB modules can define which 
    data is persistent across reboots, so a known startup state can be 
    established. The manager can poll the agent to determine the 
    current state.  
     
    RSIP: RSIP assumes that on middlebox start-up no sessions are 
    defined, and thus no allocations have been made. In effect, all 
    resources are released upon restart after failure. 
  
    Megaco: Megaco has extensive audit capabilities to synchronize 
    states between the MG and the MGC. Megaco also provides the   
    MGC with the ability to do mass resets, as well as individual   
    resets. The MGC can always release resources in the MG. The MG can 
    also initiate the release of resources by the MGC.    
     
    Diameter: Diameter documentation does not discuss the degree of 
    atomicity of message processing, so this would have to be specified 
    in the MIDCOM extension. 
     
    COPS: The COPS protocol maintains synchronized states between  
    Middleboxes and MA hence all the states are known on both sides. 
  
     
    2.1.6 Middlebox status report 
     
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP:  The status of a middlebox can be reported using asynchronous 
    communications, or via polling.  
     
    RSIP: All RSIP client requests have explicit server responses. 
    Additionally, a client may explicitly request server status using 
    a QUERY request. 
  
  
  
 Barnes                    Expires - May 2003                [Page 12] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    Megaco: Megaco has extensive audit capabilities for the MG to 
    report status information to the MGC.  It can also report some 
    status updates using the ServiceChange command.   
     
    Diameter: Diameter provides a number of response codes by means of 
    which a server can indicate error conditions reflecting status of 
    the server as a whole.  The Disconnect-Peer-Request provides a 
    means in the extreme case to terminate a connection with a peer 
    gracefully, informing the other end about the reason for the 
    disconnection. 
     
    COPS: The COPS Report message is designed to indicate any 
    asynchronous conditions/events. 
     
     
    2.1.7 Middlebox can generate unsolicited messages 
     
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP:  SNMPv3 supports both confirmed and unconfirmed asynchronous 
    notifications.  
     
    RSIP: An RSIP server will send an unsolicited DE_REGISTER_RESPONSE 
    to force an RSIP host to relinquish all of its bindings and 
    terminate its relationship with the RSIP gateway. An RSIP server 
    can send an asynchronous ERROR_RESPONSE to indicate less severe 
    conditions. 
  
    Megaco: Megaco supports the asynchronous notification of events 
    using the Notify command. 
     
    Diameter: The Diameter protocol permits either peer in a connection 
    to originate transactions.  Thus the protocol supports Middlebox-
    originated messages. 
     
    COPS: The COPS Report message is designed to indicate any 
    asynchronous conditions/events. 
     
  
    2.1.8 Mutual authentication 
  
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP: SNMPv3 meets this requirement. SNMPv3 supports user 
    authentication and explicitly supports symmetric secret key 
    encryption between MIDCOM agent (SNMP manager) and Middlebox (SNMP 
    agent), thus supporting mutual authentication. The default 
    authentication and encryption methods are specified in RFC 2574 
    (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. 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-
  
  
 Barnes                    Expires - May 2003                [Page 13] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    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 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.  Diameter requires that when 
    using the latter, peers must mutually authenticate themselves.   
     
    COPS: COPS has built-in message level security for authentication,  
    replay protection, and message integrity. COPS can also use TLS or  
    IPSec. 
  
  
    2.1.9 Termination of session by either party 
     
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP: Each SNMPv3 message is authenticated and authorized, so each 
    message could be considered to have its own session, which 
    automatically terminates after processing. Processing may be 
    stopped for a number of reasons, such as security, and a response 
    is sent.  
     
    Either peer may stop operating, and be unavailable for further 
    operations. The authentication and/or authorization parameters of a 
    principal may be changed between operations if desired, to prevent 
    further authentication or authorization for security reasons. 
     
    Additionally, managed objects can be defined for realizing sessions 
    that persist beyond processing of a single message. The MIB module 
    would need to specify the responsibility for cleanup of the objects 
    following normal/abnormal termination. 
  
    RSIP: An RSIP client may terminate a session with a 
    DE_REGISTER_REQUEST. An RSIP server may terminate a session with an 
    unsolicited DE_REGISTER_RESPONSE, and then respond to subsequent 
    requests on the session with a REGISTER_FIRST error. 
     
    Megaco: The Megaco protocol allows both peers to terminate the 
    association with proper reason code. 
     
    Diameter: Either peer in a connection may issue a Disconnect-Peer-
    Request to end the connection gracefully.  
     
    COPS: COPS allows both the PEP and PDP to terminate a session. 
     
  
    2.1.10 Indication of success or failure 
     
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP: Each operation request has a corresponding response message 
    that contains an error status to indicate success or failure. For 
    complex requests that the middlebox cannot complete immediately, 
    the corresponding MIB module may be designed to also provide 
    asynchronous notifications of the success or failure of the 
  
  
 Barnes                    Expires - May 2003                [Page 14] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    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 RFC2863 [33].  
  
    RSIP: All RSIP requests result in a paired RSIP response if the 
    request was successful or an ERROR_RESPONSE if the request was not 
    successful. 
     
    Megaco: Megaco defines a special descriptor called an Error 
    descriptor that contains the error code and an optional explanatory 
    string. 
     
    Diameter: Every Diameter request is matched by a response, and this 
    response contains a result code as well as other information. 
     
    COPS: The COPS Report message directly fulfills this requirement. 
     
     
    2.1.11 Version interworking 
     
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP: SNMP has a separation of the protocol to carry data, and the 
    data that defines additional management functionality. Additional 
    functionality can be added easily through MIBs. Capability exchange 
    in SNMP is usually uni-directional. Managers can query the 
    middlebox (SNMP agent) to determine which MIBs are supported. In 
    addition, multiple message versions can be supported 
    simultaneously, and are identified by a version number in the 
    message header. 
     
    RSIP: Each RSIP message contains a version parameter. 
     
    Megaco: Version interworking and negotiation are supported both for 
    the protocol and any extension Packages. 
     
    Diameter: The Capabilities Exchange Request/Answer allows two peers 
    to determine information about what each supports, including 
    protocol version and specific applications. 
     
    COPS: The COPS protocol can carry a MIDCOM version number and 
    capability negotiation between the COPS client and the COPS server.  
    This capability negotiation mechanism allows the COPS client and  
    server to communicate the supported features/capabilities. This 
    would allow seamless version interworking. 
     
     
    2.1.12 Deterministic behaviour in the presence of overlapping  
    rules 
     
    SNMP: T, RSIP: T, Megaco: P, Diameter: T, COPS: T 
     
    SNMP: Rulesets would be defined in MIBs. The priority of rulesets, 
    and the resolution of conflict, can be defined in the MIB module 
    definition. The SNMPConf policy MIB defines mechanisms to achieve 
    deterministic behavior in the presence of overlapping rule sets. 
  
    RSIP: All requests for allocation of IP addresses, or ports or both 
    resulting in rule overlap are rejected by an RSIP server with a 
    LOCAL_ADDR_INUSE error.  
  
  
 Barnes                    Expires - May 2003                [Page 15] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
     
    Megaco: This is met with the help of a model that separates Megaco 
    protocol elements from the overlapping Policy rules (see   
    Appendix C). However, new behavior for the Megaco protocol elements   
    needs to be specified as part of a new MIDCOM specific Package.  
     
    Diameter: The IPFilterRule type specification, which would probably 
    be used as the type of a Policy Rule AVP, comes with an extensive 
    semantic description providing a deterministic outcome, which the 
    individual Agent cannot know unless it knows all of the Policy 
    Rules installed on the Middlebox. Rules for the appropriate 
    direction are evaluated in order, with the first matched rule 
    terminating the evaluation. Each packet is evaluated once. If no 
    rule matches, the packet is dropped if the last rule evaluated was 
    a permit, and passed if the last rule was a deny. The IPFilterRule 
    format and further details on its applicability to this requirement 
    are provided in Appendix D.  
     
    COPS: The COPS protocol provides transactional-based communication  
    between the PEP and PDP, hence the behavior is totally 
    deterministic provided the middlebox state machine is designed 
    correctly. The COPS protocol features encourage and support good  
    state machine design. 
     
     
 2.2 Protocol semantics 
     
    This section contains the individual protocols as evaluated against 
    the protocol semantic requirements from section 2.2 of the 
    requirements document [1]. A short description of each of the 
    protocols is provided to substantiate the evaluation. 
     
  2.2.1 Extensibility 
     
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP: Extensibility is a basic feature of the SNMP management 
    Framework. 
     
    RSIP: All RSIP messages consist of three mandatory fields (protocol 
    version, message type, and message length) and a sequence of 
    parameterType / length / value 3-tuples. New messages may be 
    defined by defining new values for the message type field. New 
    parameter types may be defined, and existing messages may be 
    extended, by defining new parameterType values. If new messages,  
    parameters, or both are added in a non-backward compatible way, a 
    new value of the protocol version field may be defined. This may 
    be desirable even of the additions are backward compatible. 
     
    Megaco: Megaco is easily extensible through new Packages, which 
    allow definition of new attributes and behavior of a Termination. 
     
    Diameter: Diameter provides a great deal of flexibility for 
    extensions, including allowance for vendor-defined commands and 
    AVPs and the ability to flag each AVP as must-understand or 
    ignorable if not understood.   
     
  
  
 Barnes                    Expires - May 2003                [Page 16] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    COPS: The COPS protocol is extensible, since it was designed to 
    separate the Protocol from the Policy Control Information.  
  
  2.2.2 Support of multiple Middlebox types 
     
    SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T 
     
    SNMP: SNMP explicitly supports managing different device types with 
    different capabilities. First the managed object called sysObjectID 
    from basic MIB-II [3] identifies the type of box. For boxes with 
    variable capabilities, SNMP can check the availability of 
    corresponding MIBs. 
     
    RSIP: All types of middleboxes are supported so long as the ruleset 
    action is permit. Other actions would require the definition of a 
    new RSIP message parameter with values for permit and the other 
    desired actions. 
     
    Megaco: Megaco can support multiple Middlebox types on the same 
    interface either by designing the properties representing the 
    Policy Rules to provide this support, or by using multiple 
    terminations in the same session, each representing one type of 
    action.  In the latter case, the Megaco Context can be used as a 
    convenient means of managing the related terminations as a group.  
    However, the inherent idea of flow between terminations of a 
    context is irrelevant and would have to be discarded. 
     
    Diameter: Any necessary additional AVPs or values must be specified 
    as part of the MIDCOM application extension (see <2.2.8> below). 
     
    COPS: COPS allows a PDP to provide filters and actions to multiple 
    PEP functions through a single COPS session. 
  
 2.2.3 Ruleset groups 
     
    SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T 
     
    SNMP: This requirement can be realized via the SNMP management 
    framework by an appropriate definition of a MIB module. The 
    SNMPConf WG has already defined an SNMP Policy MIB that permits the 
    definitions of policy rulesets and grouping of rulesets. 
     
    RSIP: RSIP currently only allows one IP address, or address and 
    port range, to be assigned to a bind-ID. RSIP could implement 
    rulesets as required by adding an optional bind-ID parameter to the 
    ASSIGN_REQUESTs to extend an existing ruleset rather than creating 
    a new one. Similarly, the FREE_REQUESTs would have to be extended 
    by adding optional, local and remote, address and port parameters. 
     
    Megaco: The Megaco context can be used to group terminations to be 
    managed together.  For example, all of the terminations, each 
    representing an instantiation of a Policy Rule, can be deleted in 
    one command by doing a wildcarded Subtract from the context.  
    However, the inherent idea of media flows between terminations of a 
    context would be irrelevant in this application of the protocol. 
     
  
  
 Barnes                    Expires - May 2003                [Page 17] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    Diameter: Diameter allows message syntax definitions where multiple 
    instances of the same AVP (for example, a Policy Rule AVP whose 
    syntax and low-level semantics are defined by the IPFilterRule type 
    definition) may be present.  If a tighter grouping is required, the 
    set of Diameter base types includes the Grouped type.  MIDCOM can 
    choose how to make use of these capabilities to meet the ruleset 
    group requirement when defining its application extension to the 
    Diameter protocol. 
     
    COPS: The COPS-PR Handle State may be used to associate the set of 
    closely related policy objects. As the Middlebox learns additional 
    requirements, the Middlebox adds these resource requirements under 
    the same handle ID, which constitutes the required aggregation. 
  
 2.2.4 Lifetime extension 
     
    SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+ 
     
    SNMP: This requirement can be realized via the SNMP management 
    framework by an appropriate definition of a MIB module. The 
    SNMPConf WG has developed a Policy MIB module that includes a 
    pmPolicySchedule object with a modifiable lifetime. 
     
    RSIP: A client may request an explicit lease time when a request is 
    made to assign one or more IP addresses, ports or both. The server 
    may grant the requested lease time, or assign one if none was 
    requested. Subsequently, the lease time may be extended if a 
    client's EXTEND_REQUEST is granted by the server. 
     
    Megaco: The MG can report the imminent expiry of a policy rule to 
    the MGC, which can then extend or delete the corresponding 
    Termination. 
     
    Diameter: The Diameter concept of a session includes the session 
    lifetime, grace period, and lifetime extension.  It may make sense 
    to associate the Diameter session with the lifetime of a MIDCOM 
    Policy Rule, in which case support for lifetime extension comes 
    ready-made. 
     
    COPS: COPS allows a PDP to send unsolicited decisions to the PEP.  
    However, the unsolicited events will be relevant to the COPS MIDCOM  
    specific client or the MIDCOM specific PIB which needs to be  
    defined. This would allow the PDP to extend the lifetime of an  
    existing ruleset. 
     
 2.2.5 Handling of Mandatory/optional nature of unknown attributes 
     
    SNMP: T, RSIP: T, Megaco: P+, Diameter: P+, COPS: T 
     
    SNMP: Unknown attributes in a read operation are flagged as 
    exceptions in the Response message, but the rest of the read 
    succeeds. In a write operation (a SET request), all attributes are 
    validated before the write is performed. If there are unknown 
    attributes, the request fails and no writes are done. Unknown 
    attributes are flagged as exceptions in the Response message, and 
    the error status is reported.  
     
  
  
 Barnes                    Expires - May 2003                [Page 18] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    RSIP: All options of all requests are fully specified. Not 
    understood parameters must be reported by an ERROR_RESPONSE with an 
    EXTRA_PARM error value, with the entire request otherwise ignored. 
     
    Megaco: Megaco entities provide Error codes in response messages. 
    If a command marked "Optional" in a transaction fails, the 
    remaining commands will continue.  However, the specified 
    requirement deals with rules of processing properties that need 
    definition in new Package. 
     
    Diameter: Indication of the mandatory or optional status of AVPs is 
    fully supported, provided it is enabled in the AVP definition.  No  
    guidance is imposed regarding the return of diagnostic information  
    for optional AVPs.   
     
    COPS: COPS provides for the exchange of capabilities and 
    limitations between the PEP and PDP to ensure well-known outcomes 
    are understood for scenarios with unknown attributes. There is also 
    clear error handling for situations when the request is rejected. 
  
  2.2.6 Actionable failure reasons 
     
    SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T 
     
    SNMP: The SNMPv3 protocol returns error codes and exception codes 
    in Response messages, to permit the requestor to modify their 
    request. Errors and exceptions indicate the attribute that caused 
    the error, and an error code identifies the nature of the error 
    encountered. 
     
    If desired, a MIB can be designed to provide additional data about 
    error conditions either via asynchronous notifications or polled 
    objects. 
     
    RSIP: RSIP defines a fairly large number of very specific error 
    values. It is anticipated that additional error values will also 
    have to be defined along with the new messages and parameters 
    required for MIDCOM.  
     
    Megaco: The MG can provide Error codes in response messages 
    allowing the MGC to modify its behavior.  Megaco uses transaction 
    identifiers for correlation between a response and a command. If 
    the same transaction id is received more than once, the receiving 
    entity silently discards the message, thus providing some 
    protection against replay attacks. 
     
    Diameter: Diameter provides an extensive set of failure reasons in 
    the base protocol. 
     
    COPS: COPS uses an error object to identify a particular COPS 
    protocol error. The error sub-code field may contain additional 
    detailed COPS client (MIDCOM Middlebox) specific error codes.  
     
  2.2.7 Multiple Agents operating on the same ruleset. 
     
    SNMP: T, RSIP: P, Megaco: P, Diameter: T, COPS: P 
     
  
  
 Barnes                    Expires - May 2003                [Page 19] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    SNMP: The SNMP framework supports multiple managers working on the 
    same managed objects. The View-based Access Control Model (VACM, 
    [RFC2575]) even offers means to customize the access rights of 
    different managers in a fine-grained way. 
     
    RSIP: RSIP neither explicitly permits nor precludes an operation on 
    a binding by a host that had not originally create the binding. 
    However, to support this requirement, the RSIP semantics must be 
    extended to explicitly permit any authorized host to request 
    operations on a binding; this does not require a change to the 
    protocol. 
     
    Megaco: If the Megaco state machine on the Middle Box is decoupled 
    from the Middle Box policy rule management, this requirement can be 
    met with local policies on the Middle Box. However, this violates 
    the spirit of the Megaco protocol, thus Megaco is considered 
    partially compliant to this requirement. 
     
    Diameter: The Diameter protocol, as currently defined, would allow 
    multiple agents to operate on the same ruleset.   
     
    COPS: It is possible to use COPS to operate the same resource with 
    multiple agents.  An underlying resource management function, 
    separate from the COPS state machine, on the Middlebox will handle 
    the arbitration when resource conflicts happen. 
  
  2.2.8 Transport of filtering rules 
     
    SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+ 
     
    SNMP: This requirement can be met by an appropriate definition of a 
    MIDCOM MIB module. SMI, the language used for defining MIB modules, 
    is flexible enough to allow the implementation of a MIB module to 
    meet the semantics of this requirement. 
     
    RSIP: To support this requirement, a new optional enumeration 
    parameter, transportProtocol, can be added to the RSIP 
    ASSIGN_REQUESTs.  When the parameter is included, the binding 
    created applies only to the use of the bound addresses and ports, 
    by the specific transportProtocol. When the parameter is not 
    included, the binding applies to the use of all the bound addresses 
    and ports, by any transport protocol, thus maintaining backward 
    compatibility with the current definition of RSIP. 
     
    Megaco: Megaco protocol can meet this requirement by defining a new 
    property for the transport of filtering rules. 
     
    Diameter: While Diameter defines the promising IPFilterRule data 
    type (see 2.1.12 above), there is no existing message, which would 
    convey this to a Middlebox along with other required MIDCOM 
    attributes.  A new MIDCOM application extension of Diameter would 
    have to be defined. 
     
    COPS: The COPS protocol can meet this requirement by using a COPS 
    MIDCOM specific client or a MIDCOM specific PIB. 
  
  
  
 Barnes                    Expires - May 2003                [Page 20] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
  2.2.9 Mapped port parity 
     
    SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+ 
     
    SNMP: This requirement can be met by an appropriate definition of a 
    MIDCOM MIB module.  
     
    RSIP: To support this requirement, a new optional boolean 
    parameter, portOddity, can be added to the RSIP ASSIGN_REQUESTs.  
    If the parameter is TRUE, the remote port number of the binding 
    created would have the same oddity as the local port. If the 
    parameter is not specified, or is FALSE, the remote port's oddity 
    is independent of the local port's oddity, thus maintaining 
    backward compatibility with the current definition of RSIP. 
     
    Megaco: Megaco can be easily extended using a MIDCOM specific 
    Package to support this feature.   
     
    Diameter: This capability is not part of the current IPFilterRule 
    type definition.  Rather than modify the IPFilterRule type, MIDCOM 
    could group it with other AVPs which add the missing information. 
     
    COPS: The COPS protocol has all the flexibility to meet this 
    requirement by using a COPS MIDCOM specific client or a MIDCOM 
    specific PIB. 
  
 2.2.10 Consecutive range of port numbers 
     
    SNMP: P+, RSIP: T, Megaco: P+, Diameter: P+, COPS: P+ 
     
    SNMP: This requirement can be met by an appropriate definition of a 
    MIDCOM MIB module. SMI, the language used for defining MIB modules, 
    is flexible enough to allow the implementation of a MIB module to 
    meet the semantics of this requirement. 
     
    RSIP: The ports parameter of the RSIP ASSIGN_REQUESTs specifically 
    allows multiple, consecutive port numbers to be specified. 
     
    Megaco: Megaco can be easily extended using a MIDCOM specific 
    Package to support this feature. 
     
    Diameter: This capability is not part of the current IPFilterRule 
    type definition.  Rather than modify the IPFilterRule type, MIDCOM 
    could group it with other AVPs which add the missing information. 
     
    COPS: The COPS protocol has all the flexibility to meet this 
    requirement by using a COPS MIDCOM specific client or a MIDCOM 
    specific PIB. 
  
  2.2.11 More precise rulesets contradicting overlapping rulesets 
     
    SNMP: P+, RSIP: P+, Megaco: P+, Diameter: T, COPS: P+ 
     
    SNMP: This requirement can be met by an appropriate definition of a 
    MIDCOM MIB module.  
     
  
  
 Barnes                    Expires - May 2003                [Page 21] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    RSIP: To support this requirement, a new optional boolean 
    parameter, overlapOK, can be added to the RSIP ASSIGN_REQUESTs.  If 
    the parameter is TRUE, the binding may overlap with an existing 
    binding. If the parameter is unspecified, or is FALSE, the binding 
    will not overlap with an existing binding, thus maintaining 
    backward compatibility with the current definition of RSIP. 
     
    Megaco: This requirement would be met if the policy in the 
    Middlebox allows contradictory, overlapping policy rules to be 
    installed. 
     
    Diameter: Allowed by the IPFilterRule semantics described in 
    Appendix D. 
     
    COPS: The COPS protocol has all the flexibility to meet this 
    requirement by using a COPS MIDCOM specific client or a MIDCOM 
    specific PIB. 
     
  
 2.3 General Security Requirements 
     
    This section contains the individual protocols as evaluated against 
    the General Security requirements from section 2.3 of the 
    requirements document [1]. A short description of each of the 
    protocols is provided to substantiate the evaluation. 
     
  2.3.1 Message Authentication, confidentiality and Integrity 
  
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP:  SNMPv3 includes the User-based Security Model (USM, 
    [RFC2574]), 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 or TLS. 
     
    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                    Expires - May 2003                [Page 22] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
  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 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 [28] recommends the use of TLS 
    across untrusted domains. 
     
    COPS: Refer to 2.3.1 
     
  2.3.4 Mitigates Replay Attacks on Control Messages 
  
    SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 
     
    SNMP:  The User-based Security Model for SNMPv3 has specific built-
    in mechanisms for preventing replay attacks including unique 
    protocol engine IDs, timers and counters per engine and time 
    windows for the validity of messages. 
     
    RSIP: Refer to 2.3.1 
  
    Megaco: Megaco commands and responses include matching transaction   
    identifiers. The recipient receiving the same transaction id 
    multiple times would discard the message, thus providing some 
    protection against replay attacks. If even stronger protection 
    against replay attack is needed, Megaco provides for the use of 
    IPSec or TLS.   
     
    Diameter: Diameter requires that implementations support the replay 
    protection mechanisms of IPSEC. 
  
  
 Barnes                    Expires - May 2003                [Page 23] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
     
    COPS: Refer to 2.3.1 
  
 3 Conclusions 
  
    The overall statistics with regards to the number of Fully 
    Compliant, Partially Compliant (P+ and P) and Failing Compliancy 
    requirements for each of the protocols is summarized in table 1.  
     
     
                  T            P+           P            F         
    ----------------------------------------------------------------- 
    SNMP          22           5            0            0 
    RSIP          17           7            3            0 
    Megaco        19           5            3            0 
    Diameter      21           5            1            0 
    COPS          20           5            2            0 
     
                  Table 1: Totals across all Requirements 
                                       
    In considering the P+ category of compliancy, an important aspect 
    is the mechanism for support of extensibility. The extension 
    mechanism provided by SNMP and COPS-PR using MIBs and PIBs 
    respectively, provides extensions with no impact to the protocol.  
    Diameter extensions require protocol changes, thus has a higher 
    impact, although the extensions can be handled by other Diameter 
    entities without being understood.  Megaco's extension mechanisms 
    of packages also requires protocol changes that must be understand 
    by both sending and receiving entities, also being considered 
    higher impact. The RSIP extension mechanism has the largest impact 
    on the existing protocol and is based upon defining the necessary 
    new parameters. 
     
    The SNMP management framework meets all the specified MIDCOM 
    protocol requirements with the appropriate design of a MIDCOM MIB 
    module. SNMP is a proven technology with stable and proven 
    development tools, already has extensions defined to support NAT 
    configuration and policy-based management.  SNMPv3 is a full 
    standard, is more mature and has undergone more validation than the 
    other protocols in the evaluation, and has been deployed to manage 
    large-scale real-world networks (e.g. DOCSIS cable modem networks). 
    The applicability of SNMP to the MIDCOM framework has a restriction 
    in that it assumes the MIDCOM PDP is part of the Middlebox. 
     
    RSIP fully meets many of the MIDCOM requirements. However, it does 
    require additions and extensions to meet several of the 
    requirements. RSIP would also require several framework elements to 
    be added to the MIDCOM framework as identified in section 1.2.3. In 
    addition, the tunneling required for RSIP as described in section 
    1.2.4, results in RSIP not being acceptable by the WG as the MIDCOM 
    protocol. 
     
    Megaco fully meets most of the key requirements for the MIDCOM   
    Protocol.  Additional extensions in the form of a new Termination / 
    Package definition would be required for MIDCOM to meet several of 
    the requirements.  In order to meet the remaining requirements, 
    modeling the underlying Middlebox resources (e.g., filters, policy 
    rules) as separate elements from the Megaco entities might allow 
    the usage of the protocol as-is, satisfying some of the resource 
    access control requirements.  
  
  
 Barnes                    Expires - May 2003                [Page 24] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
     
    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 in the evaluation for which the RFCs are not yet 
    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.  
  
     
 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. 
  
         
 Normative References  
     
    [1] R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 
    Communications (MIDCOM) Protocol Requirements", RFC 3304, August, 
    2002. 
     
    [2] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, 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", RFC 1213, 
    March, 1991. 
     
    [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
    Levels", RFC 2119, March 1997. 
  
    [5] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 
    for Describing SNMP Management Frameworks", STD 62, RFC 3411, 
    November 2002. 
     
    [6] Rose, M., and K. McCloghrie, "Structure and Identification of 
    Management Information for TCP/IP-based Internets", STD 16, RFC 
    1155, May 1990. 
     
    [7] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, 
    RFC 1212, March 1991. 
     
    [8] M. Rose, "A Convention for Defining Traps for use with the 
    SNMP", RFC 1215, March 1991. 
     
  
  
 Barnes                    Expires - May 2003                [Page 25] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    [9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 
    M., and S. Waldbusser, "Structure of Management Information Version 
    2 (SMIv2)", STD 58, RFC 2578, April 1999. 
     
    [10] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 
    Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 
    58, RFC 2579, April 1999. 
     
    [11] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 
    Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", 
    STD 58, RFC 2580, April 1999. 
     
    [12] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 
    Network Management Protocol", STD 15, RFC 1157, May 1990. 
     
    [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 
    "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 
     
    [14] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 
    "Transport Mappings for Version 2 of the Simple Network 
    Management Protocol (SNMPv2)", RFC 1906, January 1996. 
     
    [15] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 
    Processing and Dispatching for the Simple Network Management 
    Protocol (SNMP)", STD 62, RFC 3412, November 2002. 
     
    [16] Blumenthal, U., and B. Wijnen, "User-based Security Model(USM) 
    for version 3 of the Simple Network Management Protocol (SNMPv3)", 
    STD 62, RFC 3414, November 2002. 
     
    [17] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 
    "Protocol Operations for Version 2 of the Simple Network Management 
    Protocol (SNMPv2)", RFC 1905, January 1996. 
  
    [18] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 
    STD 62, RFC 3413, November 2002. 
     
    [19] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 
    Control Model (VACM) for the Simple Network Management Protocol 
    (SNMP)", STD 62, RFC 3415, November 2002. 
     
    [20] Case, J., Mundy, R., Partain, D., and B. Stewart, 
    "Introduction to Version 3 of the Internet-standard Network 
    Management Framework", 3410, November 2002. 
  
    [21] M. Borella, J. Lo, D. Grabelsky, G. Montenegro, "Realm 
    Specific IP: Framework", RFC 3102, October, 2001. 
     
    [22] M. Borella, D. Grabelsky, J. Lo, K. Taniguchi, "Realm Specific 
    IP: Protocol Specification",_RFC 3103, October 2001. 
     
    [23] G. Montenegro, M. Borella, "RSIP Support for End-to-end 
    Ipsec", RFC 3104, October 2001. 
     
    [24] J. Kempf, G. Montenegro, "Finding an RSIP Server with SLP", 
    RFC 3105, October 2001. 
  
    [25] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. 
    Segers, "Megaco Protocol Version 1.0", RFC 3015, November, 2000. 
  
  
  
 Barnes                    Expires - May 2003                [Page 26] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    [26] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, 
    November 1998.  
     
    [27] S. Kent, R. Atkinson, "IP Encapsulating Security Payload",  
    RFC 2406, November 1998.  
  
    [28] P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney,  
    "Diameter Base Protocol", draft-ietf-aaa-diameter-15.txt, IETF  
    work in progress, October 2002.  
              
    [29] P. Calhoun, G. Zorn, P. Pan, H. Akhtar, "Diameter Framework 
    Document", draft-ietf-aaa-diameter-framework-01.txt, IETF work in 
    progress, March 2001.  
              
    [30]  P. Calhoun, W. Bulley, A. Rubens, J. Haag, G. Zorn, D. 
    Spence, "Diameter NASREQ Application", draft-ietf-aaa-diameter-
    nasreq-09.txt, IETF work in progress, March 2002. 
  
    [31]  D.Durham et al, "The COPS (Common Open Policy Service)  
    Protocol", RFC 2748, January 2000.  
           
    [32] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie,  F. 
    Reichmeyer, J. Seligson, A. Smith, R. Yavatkar,  "COPS Usage       
    for Policy Provisioning", RFC 3084, March 2001. 
     
    [33] D. Raz, J. Schoenwalder, B. Sugla, "An SNMP Application Level 
    Gateway for Payload Address Translation", RFC 2962, October 2000. 
     
 Informative References  
     
    [34] K. McCloghrie, F. Kastenholz, " The Interfaces Group MIB", RFC 
    2863, June, 2000. 
     
 Contributors 
   
 The following identifies the key contributors who provided the primary 
 content for this document in the form of individual drafts for each 
 protocol:  
  
    RSIP  
     
      Jim Renkel 
      The CommWorks Corp., a 3Com company 
      3800 Golf Rd.              Phone:  +1.847.262.2539 
      Rolling Meadows, IL, USA   Email:james_renkel@commworks.com        
     
    SNMP 
     
      Juergen Quittek 
      NEC Europe Ltd. 
      Network Laboratories 
      Kurfuersten-Anlage 34   
      69115 Heidelberg           Phone: +49 6221 90511-15 
      Germany                    Email: quittek@ccrle.nec.de 
     
      David Harrington           Co-chair SNMPv3 WG 
      Enterasys Networks 
      35 Industrial Way          Phone: +1 603-337-2614 
      Rochester, NH 03867-5005   EMail: dbh@enterasys.com 
                   
  
  
 Barnes                    Expires - May 2003                [Page 27] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    Megaco 
     
      Sanjoy Sen 
              
      Cedric Aoun  
      Nortel Networks            Email: cedric.aoun@nortelnetworks.com   
                   
      Tom Taylor   
      Nortel Networks            Email: taylor@nortelnetworks.com 
     
    Diameter 
     
      Tom Taylor  
      Nortel Networks  
      1852 Lorraine Ave.  
      Ottawa, Ontario            Phone:  +1 613 736 0961  
      Canada  K1H 6Z8            Email:  taylor@nortelnetworks.com  
         
    COPS 
     
      Cedric Aoun  
      Nortel Networks  
      FRANCE                     Email: cedric.aoun@nortelnetworks.com  
         
      Kwok-Ho Chan  
      Nortel Networks  
      600 Technology Park Drive 
      Billerica, MA 01821        Email: khchan@nortelnetworks.com  
         
      Louis-Nicolas Hamer  
      Nortel Networks 
      PO Box 3511 Station C 
      Ottawa, Ontario            Phone: +1 613.768.3409 
      Canada  K1Y 4H7            Email: nhamer@nortelnetworks.com  
         
      Reinaldo Penno  
      Nortel Networks  
      2305 Mission College Boulevard  
      Building SC9    
      Santa Clara, CA 95054      Email: rpenno@nortelnetworks.com  
         
      Sanjoy Sen  
       
  
 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 draft content.  
  
 Author's Address 
         
    Mary Barnes  
    Nortel Networks 
    2380 Performance Drive         Phone:  1-972-684-5432  
    Richardson, TX USA             Email:  mbarnes@nortelnetworks.com  
        
     
  
  
 Barnes                    Expires - May 2003                [Page 28] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
 Appendix A - SNMP Overview  
     
    The SNMP Management Framework presently consists of five major 
    components: 
     
       o An overall architecture, described in RFC 3411 [RFC3411]. A 
         more detailed introduction and applicability statements for 
         the SNMP Management Framework can be found in RFC 3410 
         [RFC3410]. 
     
       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 called 
         SMIv2 and described in RFC 2578 [RFC2578], RFC 2579 [RFC2579] 
         and RFC 2580 [RFC2580]. 
  
       o Message protocols for transferring management information.  
         The current version of the message protocol is called SNMPv3 
         and described in RFC 3412 [RFC3412], RFC 3414 [RFC3414] and 
         RFC 3417 [RFC3417]. 
  
       o Protocol operations for accessing management information.  The 
         current version of the protocol operations and associated PDU 
         formats is described in RFC 3416 [RFC3416]. 
  
       o A set of fundamental applications described in RFC 3413 
         [RFC3413] and the view-based access control mechanism 
         described in RFC 3415 [RFC2415]. 
     
     
    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 (RFC3413) 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 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 
  
  
 Barnes                    Expires - May 2003                [Page 29] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    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 RFC2962. 
      
     
 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 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 
  
  
 Barnes                    Expires - May 2003                [Page 30] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
    advantages/disadvantages of tunneling would need to be evaluated in 
    considering RSIP.  
  
 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.   
                    
     
    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   
    MAËs, 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   
  
  
 Barnes                    Expires - May 2003                [Page 31] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
              +-------------|---------|----------|-----------+        
              |       +-----------+   | +-------------+      |   
          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.   
    (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.  
  
  
 Barnes                    Expires - May 2003                [Page 32] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
      
    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]  
      
                        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  
  
  
 Barnes                    Expires - May 2003                [Page 33] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
                        a rule that has one or more port  
                        specifications.  See the frag option for  
                        details on matching fragmented packets.  
      
           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),  
  
  
 Barnes                    Expires - May 2003                [Page 34] 

                       MIDCOM Protocol Evaluation        November 2002 
  
  
                      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. 
     
 Intellectual Property Statements  
  
    The IETF has been notified of intellectual property rights claimed 
    in regard to some or all of the specification contained in this 
    document.  For more information consult the online list of claimed 
    rights. 
      
 Full Copyright Statement 
     
    Copyright (C) The Internet Society (2002).  All Rights Reserved. 
        
    This document and translations of it may be copied and furnished to 
    others, and derivative works that comment on or otherwise explain 
    it 
    or assist in its implementation may be prepared, copied, published 
    and distributed, in whole or in part, without restriction of any 
    kind, provided that the above copyright notice and this paragraph 
    are included on all such copies and derivative works.  However, 
    this 
    document itself may not be modified in any way, such as by removing 
    the copyright notice or references to the Internet Society or other 
    Internet organizations, except as needed for the purpose of 
    developing Internet standards in which case the procedures for 
    copyrights defined in the Internet Standards process must be 
    followed, or as required to translate it into languages other than 
    English.  The limited permissions granted above are perpetual and 
    will not be revoked by the Internet Society or its successors or 
    assigns.  This document and the information contained 
    herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 
    THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." 
  
     
  
  
  
 Barnes                    Expires - May 2003                [Page 35]