idnits 2.17.1 draft-ietf-midcom-protocol-eval-06.txt: -(658): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1713): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 35 longer pages, the longest (page 2) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'NAT-MIB' on line 183 -- Looks like a reference, but probably isn't: 'IPSEC' on line 481 -- Looks like a reference, but probably isn't: 'RFC2575' on line 1139 -- Looks like a reference, but probably isn't: 'RFC2574' on line 1283 -- Looks like a reference, but probably isn't: 'RFC3411' on line 1678 -- Looks like a reference, but probably isn't: 'RFC3410' on line 1681 -- Looks like a reference, but probably isn't: 'RFC2578' on line 1686 -- Looks like a reference, but probably isn't: 'RFC2579' on line 1686 -- Looks like a reference, but probably isn't: 'RFC2580' on line 1687 -- Looks like a reference, but probably isn't: 'RFC3412' on line 1691 -- Looks like a reference, but probably isn't: 'RFC3414' on line 1691 -- Looks like a reference, but probably isn't: 'RFC3417' on line 1692 -- Looks like a reference, but probably isn't: 'RFC3416' on line 1696 -- Looks like a reference, but probably isn't: 'RFC3413' on line 1699 -- Looks like a reference, but probably isn't: 'RFC2415' on line 1700 == Unused Reference: '5' is defined on line 1475, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1479, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1483, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1486, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1491, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1495, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1499, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1503, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1506, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1509, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1513, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1517, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1521, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1525, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1528, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1532, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1536, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1539, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1542, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1545, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 1548, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 1553, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 1556, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 1567, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 1571, but no explicit reference was found in the text == Unused Reference: '32' is defined on line 1574, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 1583, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1906 (ref. '14') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1905 (ref. '17') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 3015 (ref. '25') (Obsoleted by RFC 3525) ** Obsolete normative reference: RFC 2402 (ref. '26') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '27') (Obsoleted by RFC 4303, RFC 4305) == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-15 == Outdated reference: A later version (-17) exists of draft-ietf-aaa-diameter-nasreq-09 Summary: 7 errors (**), 0 flaws (~~), 33 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Barnes 2 Document: draft-ietf-midcom-protocol-eval-06.txt Editor 3 Category: Informational Nortel Networks 4 Expires: May 2003 Nov. 2002 6 Middlebox Communications (MIDCOM) Protocol Evaluation 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document provides an evaluation of the applicability of SNMP, 32 RSIP, Megaco, Diameter and COPS as the MIDCOM protocol. A summary 33 of each of the proposed protocols against the MIDCOM requirements 34 and the MIDCOM framework is provided. Compliancy of each of the 35 protocols against each requirement is detailed. A conclusion 36 summarizes how each of the protocols fares in the evaluation. 38 Table of Contents 40 1 Protocol Proposals.............................................2 41 1.1 SNMP......................................................3 42 1.2 RSIP......................................................4 43 1.3 Megaco....................................................6 44 1.4 Diameter..................................................7 45 1.5 COPS......................................................8 46 2 Item Level Compliance Evaluation...............................9 47 2.1 Protocol machinery........................................9 48 2.2 Protocol semantics.......................................16 49 2.3 General Security Requirements............................22 50 3 Conclusions...................................................24 51 Security Considerations.........................................25 52 Normative References............................................25 53 Informative References..........................................27 54 Appendix A - SNMP Overview......................................29 55 Appendix B - RSIP with tunneling................................30 56 Appendix C - Megaco Modeling Approach...........................31 57 Appendix D - Diameter IPFilter Rule.............................32 58 Intellectual Property Statements................................35 59 Full Copyright Statement........................................35 60 MIDCOM Protocol Evaluation November 2002 62 Overview 64 This document provides an evaluation of the applicability of SNMP, 65 RSIP, Megaco, Diameter and COPS as the MIDCOM protocol. This 66 evaluation provides overviews of the protocols and general 67 statements of applicability based upon the MIDCOM framework [2] and 68 requirements [1] documents. 70 The process for the protocol evaluation was fairly straightforward 71 as individuals volunteered to provide an individual draft 72 evaluating a specific protocol. Thus, some protocols that might be 73 considered as reasonably applicable as the MIDCOM protocol are not 74 evaluated in this document since there were no volunteers to 75 champion the work. The individual protocol documents for which 76 there were volunteers were submitted for discussion on the list 77 with feedback being incorporated into an updated draft. The 78 updated versions of these drafts formed the basis for the content 79 of this WG document. 81 Section 1 contains a list of the proposed protocols submitted for 82 the purposes of the protocol evaluation with some background 83 information on the protocols and similarities and differences with 84 regards to the applicability to the framework [2] provided. 86 Section 2 provides the item level evaluation of the proposed 87 protocols against the Requirements [1]. 89 Section 3 provides a summary of the evaluation. A table containing 90 a numerical breakdown for each of the protocols, with regards to 91 its applicability to the requirements, for the following categories 92 is provided: Fully met, Partially met through the use of 93 extensions, Partially met through other changes to the protocol, or 94 Failing to be met. This summary is not meant to provide a 95 conclusive statement of the suitability of the protocols, but 96 rather to provide information to be considered as input into the 97 overall protocol decision process. 99 In order for this document to serve as a complete evaluation of the 100 protocols, some of the background information and more detailed 101 aspects of the proposals documenting enhancements and applications 102 of the protocols to comply with the MIDCOM framework and 103 requirements are included in Appendices. 105 Conventions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 109 this document are to be interpreted as described in RFC 2119 [4]. 111 1 Protocol Proposals 113 The following protocols were submitted to the MIDCOM WG for 114 consideration: 115 o SNMP 116 o RSIP 117 o Megaco 118 o Diameter 119 o COPS 120 MIDCOM Protocol Evaluation November 2002 122 The following provides an overview of each of the protocols and the 123 applicability of each protocol to the MIDCOM framework. 125 1.1 SNMP 127 This section provides a general statement with regards to the 128 applicability of SNMP as the MIDCOM protocol. A general overview 129 and some specific details of SNMP are provided in Appendix A. This 130 evaluation of SNMP is specific to SNMPv3, which provides the 131 security required for MIDCOM usage. SNMPv1 and SNMPv2c would be 132 inappropriate for MIDCOM since they have been declared Historic, 133 and because their messages have only trivial security. Some 134 specifics with regards to existing support for NAT and Firewall 135 Control are provided in section 1.1.2. The differences between the 136 SNMP framework and the MIDCOM framework are addressed in section 137 1.1.3. 139 1.1.1 SNMP General Applicability 141 The primary advantages of SNMPv3 are that it is a mature, well 142 understood protocol, currently deployed in various scenarios, with 143 mature toolsets available for SNMP managers and agents. 145 Application intelligence is captured in MIB modules, rather than in 146 the messaging protocol. MIB modules define a data model of the 147 information that can be collected and configured for a managed 148 functionality. The SNMP messaging protocol transports the data in a 149 standardized format without needing to understand the semantics of 150 the data being transferred. The endpoints of the communication 151 understand the semantics of the data. 153 Partly due to the lack of security in SNMPv1 and SNMPv2c, and 154 partly due to variations in configuration requirements across 155 vendors, few MIB modules have been developed that enable 156 standardized configuration of managed devices across vendors. Since 157 monitoring can be done using only a least-common-denominator subset 158 of information across vendors, many MIB modules have been developed 159 to provide standardized monitoring of managed devices. As a result, 160 SNMP has been used primarily for monitoring rather than for 161 configuring network nodes. 163 SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c 164 versions. Specifically, SNMPv3 shares the separation of data 165 modeling (MIBs) from the protocol to transfer data, so all existing 166 MIBs can be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, 167 and it shares operations and transport with SNMPv2c. The major 168 difference between SNMPv3 and earlier versions is the addition of 169 strong message security and controlled access to data. 171 SNMPv3 uses the architecture detailed in RFC2571, where all SNMP 172 entities are capable of performing certain functions, such as the 173 generation of requests, response to requests, the generation of 174 asynchronous notifications, the receipt of notifications, and the 175 proxy-forwarding of SNMP messages. SNMP is used to read and 176 manipulate virtual databases of managed-application-specific 177 operational parameters and statistics, which are defined in MIB 178 modules. 180 1.1.2 SNMP Existing Support for NAT and Firewall Control 181 MIDCOM Protocol Evaluation November 2002 183 For configuring NATs, there is currently a NAT MIB module [NAT-MIB] 184 under development. The NAT MIB module meets all of the MIDCOM 185 requirements concerning NAT control with the exception of grouping 186 of policy rules (requirement 2.2.3.). In order to support this, an 187 additional grouping table in the NAT MIB module is required. 189 Existing work for firewall control with SNMP only considered the 190 monitoring of firewalls and not the configuration. Further work is 191 required towards the development of MIBs for configuring firewalls. 193 1.1.3 Architectural Differences between SNMP and MIDCOM 195 The SNMP management framework provides functions equivalent to 196 those defined by the MIDCOM framework, although there are a few 197 architectural differences. 199 Traditionally, SNMP entities have been called Manager and Agent. 200 Manager and agent are now recognized as entities designed to 201 support particular configurations of SNMPv3 functions. A 202 traditional manager is an entity capable of generating requests and 203 receiving notifications, and a traditional agent is an entity 204 capable of responding to requests and generating notifications. 205 The SNMP use of the term agent is different from its use in the 206 MIDCOM framework: The SNMP Manager corresponds to the MIDCOM agent 207 and the SNMP Agent corresponds to the MIDCOM PDP. The SNMP 208 evaluation assumes that the MIDCOM PDP (SNMP Agent) is physically 209 part of the middlebox, which is allowed by the MIDCOM framework as 210 described in section 6.0 of [2]. Thus, for the purpose of this 211 evaluation, the SNMP agent corresponds to the Middlebox. 213 While this evaluation is based on the assumption that the SNMP 214 agent corresponds to the middlebox, SNMP does not force such a 215 restriction. 217 Proxy means many things to many people. SNMP can be deployed using 218 intermediate entities to forward messages, or to help distribute 219 policies to the middlebox, similar to the proxy capabilities of the 220 other candidate protocols. Since proxy adds configuration and 221 deployment complexity and is not necessary to meet the specified 222 MIDCOM requirements, the use of a proxy agent or mid-level manager 223 is not considered in this evaluation. Further details on SNMP proxy 224 capabilities are provided in Appendix A. 226 Although the SNMP management framework does not have the concept of 227 a session, session-like associations can be established through the 228 use of managed objects. In order to implement the MIDCOM protocol 229 based on SNMP, a MIDCOM MIB module is required. All requests from 230 the MIDCOM agent to the Middlebox would be performed using write 231 access to managed objects defined in the MIDCOM MIB module. Replies 232 to requests are signaled by the Middlebox (SNMP agent), by 233 modifying the managed objects. The MIDCOM agent (SNMP manager) can 234 receive this information by reading or polling, if required, the 235 corresponding managed object. 237 1.2 RSIP 239 1.2.1 Framework elements in common to MIDCOM and RSIP 240 MIDCOM Protocol Evaluation November 2002 242 The following framework elements are common to MIDCOM and RSIP 243 listed by their MIDCOM names, with the RSIP name indicated in 244 parenthesis: 246 o Hosts 247 o Applications 248 o Middleboxes (RSIP gateways) 249 o Private domain (private realm) 250 o External domain (public realm) 251 o Middlebox communication protocol (RSIP) 252 o MIDCOM agent registration (host registration) 253 o MIDCOM session (RSIP session) 254 o MIDCOM Filter (local / remote address and port number(s) pairs) 256 1.2.2 MIDCOM Framework elements not supported by RSIP 258 The following MIDCOM framework elements are not supported by RSIP: 260 o Policy actions and rules. RSIP always implicitly assumes a 261 permit action. To support MIDCOM, a more general and explicit 262 action parameter would have to be defined. RSIP requests 263 specifying local / remote address and port number(s) pairs would 264 have to be extended to include an action parameter, in MIDCOM 265 rules. 267 o MIDCOM agents. RSIP makes no distinction between applications 268 and agents; address assignment operations can be performed 269 equally by applications and agents. 271 o Policy Decision Points. RSIP assumes that middleboxes grant or 272 deny requests with reference to a policy known to them; the 273 policy could be determined jointly by the middlebox and a policy 274 decision point; such joint determination is not addressed by the 275 RSIP framework, nor is it specifically precluded. 277 1.2.3 RSIP Framework elements not supported by MIDCOM 279 The following elements are unique to the RSIP framework. If RSIP 280 were adopted as the basis for the MIDCOM protocol, they could be 281 added to the MIDCOM framework: 283 o RSIP client: that portion of the application (or agent) that 284 talks to the RSIP gateway using RSIP. 286 o RSIP server: that portion of an RSIP gateway that talks to 287 applications using RSIP. 289 o Realm Specific Address IP (RSA-IP) and Realm Specific Address and 290 Port IP (RSAP-IP): RSIP distinguishes between filters that 291 include all ports on an IP address and those that do not. 293 o Demultiplexing Fields: Any set of packet header or payload fields 294 that an RSIP gateway uses to route an incoming packet to an RSIP 295 host. RSIP allows a gateway to perform, and an application to 296 control, packet routing to hosts in the private domain based on 297 more than IP header fields. 299 o Host-to-middlebox tunnels: RSIP assumes that data communicated 300 between a private realm host and a public realm host is 301 transferred through the private realm by a tunnel between the 302 MIDCOM Protocol Evaluation November 2002 304 inner host and the middle box, where it is converted to and from 305 native IP based communications to the public realm host. 307 1.2.4. Comparison of MIDCOM and RSIP frameworks 309 RSIP with tunneling, has the advantage that the public realm IP 310 addresses and port numbers are known to the private realm host 311 application, thus no translation is needed for protocols such as 312 SDP, the FTP control protocol, RTSP, SMIL, etc.. However, this does 313 require that an RSIP server and a tunneling protocol be implemented 314 in the middlebox and an RSIP client and the tunneling protocol be 315 implemented in the private realm host. The host modifications can 316 generally be made without modification to the host application or 317 requiring the implementation of a host application agent. This is 318 viewed as a significant advantage over NAT (Network Address 319 Translation). 321 Further details on the evaluation of RSIP with regards to tunneling 322 in the context of NAT support are available in Appendix B of this 323 document. 325 1.3 Megaco 327 1.3.1 Megaco Architectural Model 329 Megaco is a master-slave, transaction-oriented protocol in which 330 Media Gateway Controllers (MGC) control the operation of Media 331 Gateways (MG). Originally designed to control IP Telephony 332 gateways, it is used between an application-unaware device (the 333 Media Gateway) and an intelligent entity (the Media Gateway 334 Controller) having application awareness. 336 The Megaco model includes the following key concepts: 338 1. Terminations: Logical entities on the MG that act as sources or 339 sink of packet streams. A termination can be physical or ephemeral 340 and is associated with a single MGC. 342 2. Context: An association between Terminations for sharing media 343 between the Terminations. Terminations can be added, subtracted 344 from a Context and can be moved from one Context to another. A 345 Context and all of its Terminations are associated with a single 346 MGC. 348 3. Virtual Media Gateways: A physical MG can be partitioned into 349 multiple virtual MGs allowing multiple Controllers to interact with 350 disjoint sets of Contexts/Terminations within a single physical 351 device. 353 4. Transactions/Messages: Each Megaco command applies to one 354 Termination within a Context and generates a unique response. 355 Commands may be replicated implicitly so that they act on all 356 Terminations of a given Context through wildcarding of Termination 357 identifiers. Multiple commands addressed to different Contexts can 358 be grouped in a Transaction structure. Similarly, multiple 359 Transactions can be concatenated into a Message. 361 MIDCOM Protocol Evaluation November 2002 363 5. Descriptors/Properties: A Termination is described by a number 364 of characterizing parameters or Properties, which are grouped in a 365 set of Descriptors that are included in commands and responses. 367 6. Events and signals: A Termination can be programmed to perform 368 certain actions or to detect certain events and notify the Agent. 370 7. Packages: Packages are groups of properties, events, etc. 371 associated with a Termination. Packages are simple means of 372 extending the protocol to serve various types of devices or 373 Middleboxes. 375 1.3.2 Comparison of the Megaco and MIDCOM Architectural Frameworks 377 In the MIDCOM architecture, the Middlebox plays the role of an 378 application-unaware device being controlled by the application- 379 aware Agent. In the Megaco architecture, the Media Gateway 380 controller serves a role similar to the the MIDCOM Agent (MA) and 381 the Media Gateway serves a role similar to the Middlebox (MB). One 382 major difference between the Megaco model and the MIDCOM protocol 383 requirements is that MIDCOM requires that the MIDCOM Agent 384 establish the session. Whereas, the Megaco definition is that a MG 385 (Middlebox) establishes communication with an MGC (MIDCOM Agent). 387 1.4 Diameter 389 1.4.1 Diameter Architecture 391 Diameter is designed to support AAA for network access. It is 392 meant to operate through networks of Diameter nodes, which both act 393 upon and route messages toward their final destinations. Endpoints 394 are characterized as either clients, which perform network access 395 control, or servers, which handle authentication, authorization and 396 accounting requests for a particular realm. Intermediate nodes 397 perform relay, proxy, redirect, and translation services. Design 398 requirements for the protocol [29] include robustness in the face 399 of bursty message loads and server failures, resistance to specific 400 DOS attacks and protection of message contents, and extensibility 401 including support for vendor-specific attributes and message types. 403 The protocol is designed as a base protocol to be supported by all 404 implementations, plus extensions devoted to specific applications. 405 Messages consist of a header and an aggregation of "Attribute-Value 406 Pairs (AVPs)", each of which is a tag-length-value construct. The 407 header includes a command code, which determines the processing of 408 the message and what other AVP types must or may be present. AVPs 409 are strongly typed. Some basic and compound types are provided by 410 the base protocol specification, while others may be added by 411 application extensions. One of the types provided in the base is 412 the IPFilterRule, which may be sufficient to express the Policy 413 Rules that MIDCOM deals with. 415 Messaging takes the form of request-answer exchanges. Some 416 exchanges may take multiple round-trips to complete. The protocol 417 is connection-oriented at both the transport and application 418 levels. In addition, the protocol is tied closely to the idea of 419 sessions, which relate sequences of message exchanges through use 420 of a common session identifier. Each application provides its own 421 MIDCOM Protocol Evaluation November 2002 423 definition of the semantics of a session. Multiple sessions may be 424 open simultaneously. 426 1.4.2 Comparison of Diameter With MIDCOM Architectural Requirements 428 The MIDCOM Agent does not perform the functions of a Diameter 429 client, nor does the Middlebox support the functions of a Diameter 430 server. Thus the MIDCOM application would introduce two new types 431 of endpoints into the Diameter architecture. Moreover, the MIDCOM 432 requirements do not at this time imply any type of intermediate 433 node. 435 A general assessment might be that Diameter meets and exceeds 436 MIDCOM architectural requirements, however the connection 437 orientation may be too heavy for the number of relationships the 438 Middlebox must support. Certainly the focus on extensibility, 439 request-response messaging orientation, and treatment of the 440 session, are all well-matched to what MIDCOM needs. At this point, 441 MIDCOM is focused on simple point-to-point relationships, so the 442 proxying and forwarding capabilities provided by Diameter are not 443 needed. Most of the commands and AVPs defined in the base protocol 444 are also surplus to MIDCOM requirements. 446 1.5 COPS 448 Overall, COPS and COPS-PR have similar compliancy with regards to 449 the MIDCOM protocol requirements. In this document, references to 450 COPS are generally applicable to both COPS and COPS-PR. However, 451 COPS-PR is explicitly identified to meet two of the requirements. 452 The only other major difference between COPS-PR and COPS, as 453 applied to the MIDCOM protocol, would be the description of the 454 MIDCOM policy rule attributes with COPS-PR MIDCOM PIB attributes 455 rather than COPS MIDCOM client specific objects. 457 1.5.1 COPS protocol architecture 459 COPS is a simple query and response protocol that can be used to 460 exchange policy information between a policy server (Policy 461 Decision Point or PDP) and its clients (Policy Enforcement Points 462 or PEPs). COPS was defined to be a simple and extensible protocol. 463 The main characteristics of COPS include the following: 465 1. The protocol employs a client/server model. The PEP sends 466 requests, updates, and deletions to the remote PDP and the PDP 467 returns decisions back to the PEP. 469 2. The protocol uses TCP as its transport protocol for reliable 470 exchange of messages between policy clients and a server. 472 3. The protocol is extensible in that it is designed to leverage 473 self-identifying objects and can support diverse client specific 474 information without requiring modification of the COPS protocol. 476 4. The protocol was created for the general administration, 477 configuration, and enforcement of policies. 479 5. COPS provides message level security for authentication, replay 480 protection, and message integrity. COPS can make use of existing 481 protocols for security such as IPSEC [IPSEC] or TLS to authenticate 482 MIDCOM Protocol Evaluation November 2002 484 and secure the channel between the PEP and the PDP. 486 6. The protocol is stateful in two main aspects: 487 (1) Request/Decision state is shared and kept synchronized in a 488 transactional manner between client and server. Requests from the 489 client PEP are installed or remembered by the remote PDP until they 490 are explicitly deleted by the PEP. At the same time, Decisions from 491 the remote PDP can be generated asynchronously at any time for a 492 currently installed request state. 493 (2) State from various events (Request/Decision pairs) may be 494 inter-associated. The server may respond to new queries differently 495 because of previously installed, related Request/Decision state(s). 497 7. The protocol is also stateful in that it allows the server to 498 push configuration information to the client, and then allows the 499 server to remove such state from the client when it is no longer 500 applicable. 502 1.5.2 Comparison of COPS and the MIDCOM Framework 504 In the MIDCOM framework, the Middlebox enforces the policy 505 controlled by an application-aware Agent. Thus, when compared to 506 the COPS architecture, the Middlebox serves as the PEP (COPS 507 Client) and the MIDCOM Agent serves as the PDP (COPS Policy 508 Server). One major difference between the COPS protocol model and 509 the MIDCOM protocol requirements is that MIDCOM requires that the 510 MIDCOM Agent establish the session. Whereas, the COPS definition 511 is that a PEP (Middlebox) establishes communication with a PDP 512 (MIDCOM Agent). 514 2 Item Level Compliance Evaluation 516 This section contains a review of the protocol's level of 517 compliance to each of the MIDCOM Requirements [1]. The following 518 key will be used to identify the level of compliancy of each of the 519 individual protocols: 521 T = Total Compliance. Meets the requirement fully. 523 P+ = Partial Compliance+. Fundamentally meets the requirement 524 through the use of extensions (e.g. packages, additional 525 parameters, etc). 527 P = Partial Compliance. Meets some aspect of the requirement, 528 however, the necessary changes require more than an extension 529 and/or are inconsistent with the design intent of the 530 protocol. 532 F = Failed Compliance. Does not meet the requirement. 534 2.1 Protocol machinery 536 This section describes the compliancy of the proposed protocols 537 against the protocol machinery requirements from section 2.1 of the 538 requirements document [1]. A short description of each of the 539 protocols is provided to substantiate the evaluation. 541 2.1.1 Ability to establish association between Agent and Middlebox. 543 MIDCOM Protocol Evaluation November 2002 545 SNMP: T, RSIP: P+, Megaco: P, Diameter: T, COPS: P 547 SNMP: SNMPv3 provides mutual authentication at the user level 548 (where the user can be an application or a host if desired) via 549 shared secrets. Each authenticated principal is associated with a 550 group that has access rights that control the principal�s ability 551 to perform operations on specific subsets of data. Failure to 552 authenticate can generate a SNMP notification (administrator 553 configurable choice). 555 RSIP: RSIP allows sessions to be established between middleboxes 556 and applications and MIDCOM agents. Authorization credentials would 557 have to be added to the session establishment request to allow the 558 middlebox to authorize the session requestor. 560 Megaco: There is a directionality component implicit in this 561 requirement in that the MA initiates the establishment 562 of the authorized session. Megaco defines this association to 563 be established in the opposite direction, i.e., the Middlebox(MG) 564 initiates the establishment. If this restriction is not considered, 565 then Megaco makes the syntax and semantics available for the 566 endpoint to initiate the connection. 568 Diameter: Although this is out of scope, the Diameter specification 569 describes several ways to discover a peer. Having done so, a 570 Diameter node establishes a transport connection (TCP, TLS, or 571 SCTP) to the peer. The two peers then exchange Capability Exchange 572 Request/Answer messages to identify each other and determine the 573 Diameter applications each supports. 575 If the connection between two peers is lost, Diameter prescribes 576 procedures whereby it may be re-established. To ensure that loss 577 of connectivity is detected quickly, Diameter provides the Device- 578 Watchdog Request/Answer messages, to be used when traffic between 579 the two peers is low. 581 Diameter provides an extensive state machine to govern the 582 relationship between two peers. 584 COPS: COPS does not meet the directionality part of the 585 requirement. The definition of COPS allows a PEP (Middlebox) to 586 establish communication with a PDP (MIDCOM Agent). However, nothing 587 explicitly prohibits a PDP from establishing communication with a 588 PEP. The PEP could have local policies dictating what action to 589 take when it is contacted by an unknown PDP. These actions, defined 590 in the local policies, would ensure the proper establishment of an 591 authorized association. 593 2.1.2 Agent can relate to multiple Middleboxes 595 SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T 597 SNMP: An SNMP manager can communicate simultaneously with several 598 Middleboxes. 600 RSIP: RSIP sessions are identified by their IP source and 601 destination addresses and their TCP / UDP port numbers. Thus each 602 RSIP client can communicate with multiple servers, and each server 603 can communicate with multiple clients. However, RSIP did not 604 MIDCOM Protocol Evaluation November 2002 606 explicitly include agents in its design. The architecture and 607 semantics of RSIP messages do not preclude agents, thus the RSIP 608 architecture could certainly be extended to explicitly include 609 agents; therefore RSIP is deemed partially compliant to this 610 requirement. 612 Megaco: Megaco allows an MA to control several Middle Boxes. Each 613 message carries an identifier of the endpoint that transmitted the 614 message allowing the recipient to determine the source. 616 Diameter: Diameter allows connection to more than one peer (and 617 encourages this for improved reliability). Whether the Diameter 618 connection state machine is too heavy to support the number of 619 connections needed is a matter for discussion. 621 COPS: COPS PDPs are designed to communicate with several PEPs. 623 2.1.3 Middlebox can relate to multiple Agents 625 SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T 627 SNMP: An SNMP agent can communicate with several SNMP managers 628 Simultaneously. 630 RSIP: Refer to 2.1.2. 632 Megaco: Megaco has the concept of Virtual Media Gateways (VMG), 633 allowing multiple MGCs to communicate simultaneously with the same 634 MG. Applying this model to MIDCOM would allow the same middlebox 635 (MG) to have associations with multiple MIDCOM Agents (MGCs). 637 Diameter: Diameter allows connection to more than one peer and 638 encourages this for improved reliability. Whether the Diameter 639 connection state machine is too heavy to support the number of 640 connections needed is a matter for discussion. The Middlebox and 641 Agent play symmetric roles as far as Diameter peering is concerned. 643 COPS: The COPS-PR framework specifies that a PEP should have a 644 unique PDP in order to achieve effective policy control. The COPS- 645 PR protocol would allow the scenario whereby a PEP establishes 646 communication with multiple PDPs by creating a COPS client instance 647 per PDP. 649 2.1.4 Deterministic outcome when multiple requests are presented to 650 the Middlebox simultaneously 652 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 654 SNMP: While the architectural design of SNMP can permit race 655 conditions to occur, there are mechanisms defined as part of the 656 SNMPv3 standard, such as view-based access control and advisory 657 locking that can be used to prevent the conditions, and MIB modules 658 may also contain special functionality, such as RMON�s OwnerString, 659 to prevent conflicts. Deterministic behavior of SNMP agents when 660 being accessed by multiple managers is important for several 661 management applications and supported by SNMP. 663 MIDCOM Protocol Evaluation November 2002 665 RSIP: All RSIP requests are defined to be atomic. Near simultaneous 666 requests are executed as is they were sequential. 668 Megaco: Megaco supports the concept of VMGs to make these 669 interactions deterministic and to avoid resource access conflicts. 670 Each VMG has a single owner, in a MGC, and there can be no overlap 671 between the sets of Terminations belonging to multiple VMGs. The 672 Megaco protocol messages also include the identifier of the sending 673 entity, so that the MG can easily determine to whom to send the 674 response or asynchronously report certain events. 676 Diameter: Diameter depends partly upon the transport protocol to 677 provide flow control when the server becomes heavily loaded. It 678 also has application-layer messaging to indicate that it is too 679 busy or out of space (Diameter_TOO_BUSY and Diameter_OUT_OF_SPACE 680 result codes). 682 COPS: COPS has built-in support for clear state and policy 683 instances. This would allow the creation of well-behaved MIDCOM 684 state machines. 686 2.1.5 Known and stable state 688 SNMP: T, RSIP: T, Megaco: T, Diameter: P, COPS: T 690 SNMP: Requests are atomic in SNMP. MIB modules can define which 691 data is persistent across reboots, so a known startup state can be 692 established. The manager can poll the agent to determine the 693 current state. 695 RSIP: RSIP assumes that on middlebox start-up no sessions are 696 defined, and thus no allocations have been made. In effect, all 697 resources are released upon restart after failure. 699 Megaco: Megaco has extensive audit capabilities to synchronize 700 states between the MG and the MGC. Megaco also provides the 701 MGC with the ability to do mass resets, as well as individual 702 resets. The MGC can always release resources in the MG. The MG can 703 also initiate the release of resources by the MGC. 705 Diameter: Diameter documentation does not discuss the degree of 706 atomicity of message processing, so this would have to be specified 707 in the MIDCOM extension. 709 COPS: The COPS protocol maintains synchronized states between 710 Middleboxes and MA hence all the states are known on both sides. 712 2.1.6 Middlebox status report 714 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 716 SNMP: The status of a middlebox can be reported using asynchronous 717 communications, or via polling. 719 RSIP: All RSIP client requests have explicit server responses. 720 Additionally, a client may explicitly request server status using 721 a QUERY request. 723 MIDCOM Protocol Evaluation November 2002 725 Megaco: Megaco has extensive audit capabilities for the MG to 726 report status information to the MGC. It can also report some 727 status updates using the ServiceChange command. 729 Diameter: Diameter provides a number of response codes by means of 730 which a server can indicate error conditions reflecting status of 731 the server as a whole. The Disconnect-Peer-Request provides a 732 means in the extreme case to terminate a connection with a peer 733 gracefully, informing the other end about the reason for the 734 disconnection. 736 COPS: The COPS Report message is designed to indicate any 737 asynchronous conditions/events. 739 2.1.7 Middlebox can generate unsolicited messages 741 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 743 SNMP: SNMPv3 supports both confirmed and unconfirmed asynchronous 744 notifications. 746 RSIP: An RSIP server will send an unsolicited DE_REGISTER_RESPONSE 747 to force an RSIP host to relinquish all of its bindings and 748 terminate its relationship with the RSIP gateway. An RSIP server 749 can send an asynchronous ERROR_RESPONSE to indicate less severe 750 conditions. 752 Megaco: Megaco supports the asynchronous notification of events 753 using the Notify command. 755 Diameter: The Diameter protocol permits either peer in a connection 756 to originate transactions. Thus the protocol supports Middlebox- 757 originated messages. 759 COPS: The COPS Report message is designed to indicate any 760 asynchronous conditions/events. 762 2.1.8 Mutual authentication 764 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 766 SNMP: SNMPv3 meets this requirement. SNMPv3 supports user 767 authentication and explicitly supports symmetric secret key 768 encryption between MIDCOM agent (SNMP manager) and Middlebox (SNMP 769 agent), thus supporting mutual authentication. The default 770 authentication and encryption methods are specified in RFC 2574 771 (MD5, SHA-1, and DES). Different users at the same management 772 application (MIDCOM agent) can authenticate themselves with 773 different authentication and encryption methods, and additional 774 methods can be added to SNMPv3 entities as needed. 776 RSIP: This requirement can be met by operating RSIP over IPSec. The 777 RSIP framework recommends all communication between an RSIP host 778 and gateway be authenticated. Authentication, in the form of a 779 message hash appended to the end of each RSIP protocol packet, can 780 serve to authenticate the RSIP host and gateway to one another, 781 provide message integrity, and avoid replay attacks with an anti- 782 MIDCOM Protocol Evaluation November 2002 784 replay counter. However, the message hash and replay counter 785 parameters would need to be defined for the RSIP protocol. 787 Megaco: Megaco provides for the use of IPSec for all security 788 mechanisms including mutual authentication, integrity check and 789 encryption. Use of IKE is recommended with support of RSA 790 signatures and public key encryption. 792 Diameter: The Diameter base protocol assumes that messages are 793 secured by using either IPSec or TLS. Diameter requires that when 794 using the latter, peers must mutually authenticate themselves. 796 COPS: COPS has built-in message level security for authentication, 797 replay protection, and message integrity. COPS can also use TLS or 798 IPSec. 800 2.1.9 Termination of session by either party 802 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 804 SNMP: Each SNMPv3 message is authenticated and authorized, so each 805 message could be considered to have its own session, which 806 automatically terminates after processing. Processing may be 807 stopped for a number of reasons, such as security, and a response 808 is sent. 810 Either peer may stop operating, and be unavailable for further 811 operations. The authentication and/or authorization parameters of a 812 principal may be changed between operations if desired, to prevent 813 further authentication or authorization for security reasons. 815 Additionally, managed objects can be defined for realizing sessions 816 that persist beyond processing of a single message. The MIB module 817 would need to specify the responsibility for cleanup of the objects 818 following normal/abnormal termination. 820 RSIP: An RSIP client may terminate a session with a 821 DE_REGISTER_REQUEST. An RSIP server may terminate a session with an 822 unsolicited DE_REGISTER_RESPONSE, and then respond to subsequent 823 requests on the session with a REGISTER_FIRST error. 825 Megaco: The Megaco protocol allows both peers to terminate the 826 association with proper reason code. 828 Diameter: Either peer in a connection may issue a Disconnect-Peer- 829 Request to end the connection gracefully. 831 COPS: COPS allows both the PEP and PDP to terminate a session. 833 2.1.10 Indication of success or failure 835 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 837 SNMP: Each operation request has a corresponding response message 838 that contains an error status to indicate success or failure. For 839 complex requests that the middlebox cannot complete immediately, 840 the corresponding MIB module may be designed to also provide 841 asynchronous notifications of the success or failure of the 842 MIDCOM Protocol Evaluation November 2002 844 complete transaction, and/or may provide pollable objects that 845 indicate the success or failure of the complete transaction. For 846 example, see ifAdminStatus and ifOperStatus in RFC2863 [33]. 848 RSIP: All RSIP requests result in a paired RSIP response if the 849 request was successful or an ERROR_RESPONSE if the request was not 850 successful. 852 Megaco: Megaco defines a special descriptor called an Error 853 descriptor that contains the error code and an optional explanatory 854 string. 856 Diameter: Every Diameter request is matched by a response, and this 857 response contains a result code as well as other information. 859 COPS: The COPS Report message directly fulfills this requirement. 861 2.1.11 Version interworking 863 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 865 SNMP: SNMP has a separation of the protocol to carry data, and the 866 data that defines additional management functionality. Additional 867 functionality can be added easily through MIBs. Capability exchange 868 in SNMP is usually uni-directional. Managers can query the 869 middlebox (SNMP agent) to determine which MIBs are supported. In 870 addition, multiple message versions can be supported 871 simultaneously, and are identified by a version number in the 872 message header. 874 RSIP: Each RSIP message contains a version parameter. 876 Megaco: Version interworking and negotiation are supported both for 877 the protocol and any extension Packages. 879 Diameter: The Capabilities Exchange Request/Answer allows two peers 880 to determine information about what each supports, including 881 protocol version and specific applications. 883 COPS: The COPS protocol can carry a MIDCOM version number and 884 capability negotiation between the COPS client and the COPS server. 885 This capability negotiation mechanism allows the COPS client and 886 server to communicate the supported features/capabilities. This 887 would allow seamless version interworking. 889 2.1.12 Deterministic behaviour in the presence of overlapping 890 rules 892 SNMP: T, RSIP: T, Megaco: P, Diameter: T, COPS: T 894 SNMP: Rulesets would be defined in MIBs. The priority of rulesets, 895 and the resolution of conflict, can be defined in the MIB module 896 definition. The SNMPConf policy MIB defines mechanisms to achieve 897 deterministic behavior in the presence of overlapping rule sets. 899 RSIP: All requests for allocation of IP addresses, or ports or both 900 resulting in rule overlap are rejected by an RSIP server with a 901 LOCAL_ADDR_INUSE error. 903 MIDCOM Protocol Evaluation November 2002 905 Megaco: This is met with the help of a model that separates Megaco 906 protocol elements from the overlapping Policy rules (see 907 Appendix C). However, new behavior for the Megaco protocol elements 908 needs to be specified as part of a new MIDCOM specific Package. 910 Diameter: The IPFilterRule type specification, which would probably 911 be used as the type of a Policy Rule AVP, comes with an extensive 912 semantic description providing a deterministic outcome, which the 913 individual Agent cannot know unless it knows all of the Policy 914 Rules installed on the Middlebox. Rules for the appropriate 915 direction are evaluated in order, with the first matched rule 916 terminating the evaluation. Each packet is evaluated once. If no 917 rule matches, the packet is dropped if the last rule evaluated was 918 a permit, and passed if the last rule was a deny. The IPFilterRule 919 format and further details on its applicability to this requirement 920 are provided in Appendix D. 922 COPS: The COPS protocol provides transactional-based communication 923 between the PEP and PDP, hence the behavior is totally 924 deterministic provided the middlebox state machine is designed 925 correctly. The COPS protocol features encourage and support good 926 state machine design. 928 2.2 Protocol semantics 930 This section contains the individual protocols as evaluated against 931 the protocol semantic requirements from section 2.2 of the 932 requirements document [1]. A short description of each of the 933 protocols is provided to substantiate the evaluation. 935 2.2.1 Extensibility 937 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 939 SNMP: Extensibility is a basic feature of the SNMP management 940 Framework. 942 RSIP: All RSIP messages consist of three mandatory fields (protocol 943 version, message type, and message length) and a sequence of 944 parameterType / length / value 3-tuples. New messages may be 945 defined by defining new values for the message type field. New 946 parameter types may be defined, and existing messages may be 947 extended, by defining new parameterType values. If new messages, 948 parameters, or both are added in a non-backward compatible way, a 949 new value of the protocol version field may be defined. This may 950 be desirable even of the additions are backward compatible. 952 Megaco: Megaco is easily extensible through new Packages, which 953 allow definition of new attributes and behavior of a Termination. 955 Diameter: Diameter provides a great deal of flexibility for 956 extensions, including allowance for vendor-defined commands and 957 AVPs and the ability to flag each AVP as must-understand or 958 ignorable if not understood. 960 MIDCOM Protocol Evaluation November 2002 962 COPS: The COPS protocol is extensible, since it was designed to 963 separate the Protocol from the Policy Control Information. 965 2.2.2 Support of multiple Middlebox types 967 SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T 969 SNMP: SNMP explicitly supports managing different device types with 970 different capabilities. First the managed object called sysObjectID 971 from basic MIB-II [3] identifies the type of box. For boxes with 972 variable capabilities, SNMP can check the availability of 973 corresponding MIBs. 975 RSIP: All types of middleboxes are supported so long as the ruleset 976 action is permit. Other actions would require the definition of a 977 new RSIP message parameter with values for permit and the other 978 desired actions. 980 Megaco: Megaco can support multiple Middlebox types on the same 981 interface either by designing the properties representing the 982 Policy Rules to provide this support, or by using multiple 983 terminations in the same session, each representing one type of 984 action. In the latter case, the Megaco Context can be used as a 985 convenient means of managing the related terminations as a group. 986 However, the inherent idea of flow between terminations of a 987 context is irrelevant and would have to be discarded. 989 Diameter: Any necessary additional AVPs or values must be specified 990 as part of the MIDCOM application extension (see <2.2.8> below). 992 COPS: COPS allows a PDP to provide filters and actions to multiple 993 PEP functions through a single COPS session. 995 2.2.3 Ruleset groups 997 SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T 999 SNMP: This requirement can be realized via the SNMP management 1000 framework by an appropriate definition of a MIB module. The 1001 SNMPConf WG has already defined an SNMP Policy MIB that permits the 1002 definitions of policy rulesets and grouping of rulesets. 1004 RSIP: RSIP currently only allows one IP address, or address and 1005 port range, to be assigned to a bind-ID. RSIP could implement 1006 rulesets as required by adding an optional bind-ID parameter to the 1007 ASSIGN_REQUESTs to extend an existing ruleset rather than creating 1008 a new one. Similarly, the FREE_REQUESTs would have to be extended 1009 by adding optional, local and remote, address and port parameters. 1011 Megaco: The Megaco context can be used to group terminations to be 1012 managed together. For example, all of the terminations, each 1013 representing an instantiation of a Policy Rule, can be deleted in 1014 one command by doing a wildcarded Subtract from the context. 1015 However, the inherent idea of media flows between terminations of a 1016 context would be irrelevant in this application of the protocol. 1018 MIDCOM Protocol Evaluation November 2002 1020 Diameter: Diameter allows message syntax definitions where multiple 1021 instances of the same AVP (for example, a Policy Rule AVP whose 1022 syntax and low-level semantics are defined by the IPFilterRule type 1023 definition) may be present. If a tighter grouping is required, the 1024 set of Diameter base types includes the Grouped type. MIDCOM can 1025 choose how to make use of these capabilities to meet the ruleset 1026 group requirement when defining its application extension to the 1027 Diameter protocol. 1029 COPS: The COPS-PR Handle State may be used to associate the set of 1030 closely related policy objects. As the Middlebox learns additional 1031 requirements, the Middlebox adds these resource requirements under 1032 the same handle ID, which constitutes the required aggregation. 1034 2.2.4 Lifetime extension 1036 SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+ 1038 SNMP: This requirement can be realized via the SNMP management 1039 framework by an appropriate definition of a MIB module. The 1040 SNMPConf WG has developed a Policy MIB module that includes a 1041 pmPolicySchedule object with a modifiable lifetime. 1043 RSIP: A client may request an explicit lease time when a request is 1044 made to assign one or more IP addresses, ports or both. The server 1045 may grant the requested lease time, or assign one if none was 1046 requested. Subsequently, the lease time may be extended if a 1047 client's EXTEND_REQUEST is granted by the server. 1049 Megaco: The MG can report the imminent expiry of a policy rule to 1050 the MGC, which can then extend or delete the corresponding 1051 Termination. 1053 Diameter: The Diameter concept of a session includes the session 1054 lifetime, grace period, and lifetime extension. It may make sense 1055 to associate the Diameter session with the lifetime of a MIDCOM 1056 Policy Rule, in which case support for lifetime extension comes 1057 ready-made. 1059 COPS: COPS allows a PDP to send unsolicited decisions to the PEP. 1060 However, the unsolicited events will be relevant to the COPS MIDCOM 1061 specific client or the MIDCOM specific PIB which needs to be 1062 defined. This would allow the PDP to extend the lifetime of an 1063 existing ruleset. 1065 2.2.5 Handling of Mandatory/optional nature of unknown attributes 1067 SNMP: T, RSIP: T, Megaco: P+, Diameter: P+, COPS: T 1069 SNMP: Unknown attributes in a read operation are flagged as 1070 exceptions in the Response message, but the rest of the read 1071 succeeds. In a write operation (a SET request), all attributes are 1072 validated before the write is performed. If there are unknown 1073 attributes, the request fails and no writes are done. Unknown 1074 attributes are flagged as exceptions in the Response message, and 1075 the error status is reported. 1077 MIDCOM Protocol Evaluation November 2002 1079 RSIP: All options of all requests are fully specified. Not 1080 understood parameters must be reported by an ERROR_RESPONSE with an 1081 EXTRA_PARM error value, with the entire request otherwise ignored. 1083 Megaco: Megaco entities provide Error codes in response messages. 1084 If a command marked "Optional" in a transaction fails, the 1085 remaining commands will continue. However, the specified 1086 requirement deals with rules of processing properties that need 1087 definition in new Package. 1089 Diameter: Indication of the mandatory or optional status of AVPs is 1090 fully supported, provided it is enabled in the AVP definition. No 1091 guidance is imposed regarding the return of diagnostic information 1092 for optional AVPs. 1094 COPS: COPS provides for the exchange of capabilities and 1095 limitations between the PEP and PDP to ensure well-known outcomes 1096 are understood for scenarios with unknown attributes. There is also 1097 clear error handling for situations when the request is rejected. 1099 2.2.6 Actionable failure reasons 1101 SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T 1103 SNMP: The SNMPv3 protocol returns error codes and exception codes 1104 in Response messages, to permit the requestor to modify their 1105 request. Errors and exceptions indicate the attribute that caused 1106 the error, and an error code identifies the nature of the error 1107 encountered. 1109 If desired, a MIB can be designed to provide additional data about 1110 error conditions either via asynchronous notifications or polled 1111 objects. 1113 RSIP: RSIP defines a fairly large number of very specific error 1114 values. It is anticipated that additional error values will also 1115 have to be defined along with the new messages and parameters 1116 required for MIDCOM. 1118 Megaco: The MG can provide Error codes in response messages 1119 allowing the MGC to modify its behavior. Megaco uses transaction 1120 identifiers for correlation between a response and a command. If 1121 the same transaction id is received more than once, the receiving 1122 entity silently discards the message, thus providing some 1123 protection against replay attacks. 1125 Diameter: Diameter provides an extensive set of failure reasons in 1126 the base protocol. 1128 COPS: COPS uses an error object to identify a particular COPS 1129 protocol error. The error sub-code field may contain additional 1130 detailed COPS client (MIDCOM Middlebox) specific error codes. 1132 2.2.7 Multiple Agents operating on the same ruleset. 1134 SNMP: T, RSIP: P, Megaco: P, Diameter: T, COPS: P 1135 MIDCOM Protocol Evaluation November 2002 1137 SNMP: The SNMP framework supports multiple managers working on the 1138 same managed objects. The View-based Access Control Model (VACM, 1139 [RFC2575]) even offers means to customize the access rights of 1140 different managers in a fine-grained way. 1142 RSIP: RSIP neither explicitly permits nor precludes an operation on 1143 a binding by a host that had not originally create the binding. 1144 However, to support this requirement, the RSIP semantics must be 1145 extended to explicitly permit any authorized host to request 1146 operations on a binding; this does not require a change to the 1147 protocol. 1149 Megaco: If the Megaco state machine on the Middle Box is decoupled 1150 from the Middle Box policy rule management, this requirement can be 1151 met with local policies on the Middle Box. However, this violates 1152 the spirit of the Megaco protocol, thus Megaco is considered 1153 partially compliant to this requirement. 1155 Diameter: The Diameter protocol, as currently defined, would allow 1156 multiple agents to operate on the same ruleset. 1158 COPS: It is possible to use COPS to operate the same resource with 1159 multiple agents. An underlying resource management function, 1160 separate from the COPS state machine, on the Middlebox will handle 1161 the arbitration when resource conflicts happen. 1163 2.2.8 Transport of filtering rules 1165 SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+ 1167 SNMP: This requirement can be met by an appropriate definition of a 1168 MIDCOM MIB module. SMI, the language used for defining MIB modules, 1169 is flexible enough to allow the implementation of a MIB module to 1170 meet the semantics of this requirement. 1172 RSIP: To support this requirement, a new optional enumeration 1173 parameter, transportProtocol, can be added to the RSIP 1174 ASSIGN_REQUESTs. When the parameter is included, the binding 1175 created applies only to the use of the bound addresses and ports, 1176 by the specific transportProtocol. When the parameter is not 1177 included, the binding applies to the use of all the bound addresses 1178 and ports, by any transport protocol, thus maintaining backward 1179 compatibility with the current definition of RSIP. 1181 Megaco: Megaco protocol can meet this requirement by defining a new 1182 property for the transport of filtering rules. 1184 Diameter: While Diameter defines the promising IPFilterRule data 1185 type (see 2.1.12 above), there is no existing message, which would 1186 convey this to a Middlebox along with other required MIDCOM 1187 attributes. A new MIDCOM application extension of Diameter would 1188 have to be defined. 1190 COPS: The COPS protocol can meet this requirement by using a COPS 1191 MIDCOM specific client or a MIDCOM specific PIB. 1193 MIDCOM Protocol Evaluation November 2002 1195 2.2.9 Mapped port parity 1197 SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+ 1199 SNMP: This requirement can be met by an appropriate definition of a 1200 MIDCOM MIB module. 1202 RSIP: To support this requirement, a new optional boolean 1203 parameter, portOddity, can be added to the RSIP ASSIGN_REQUESTs. 1204 If the parameter is TRUE, the remote port number of the binding 1205 created would have the same oddity as the local port. If the 1206 parameter is not specified, or is FALSE, the remote port's oddity 1207 is independent of the local port's oddity, thus maintaining 1208 backward compatibility with the current definition of RSIP. 1210 Megaco: Megaco can be easily extended using a MIDCOM specific 1211 Package to support this feature. 1213 Diameter: This capability is not part of the current IPFilterRule 1214 type definition. Rather than modify the IPFilterRule type, MIDCOM 1215 could group it with other AVPs which add the missing information. 1217 COPS: The COPS protocol has all the flexibility to meet this 1218 requirement by using a COPS MIDCOM specific client or a MIDCOM 1219 specific PIB. 1221 2.2.10 Consecutive range of port numbers 1223 SNMP: P+, RSIP: T, Megaco: P+, Diameter: P+, COPS: P+ 1225 SNMP: This requirement can be met by an appropriate definition of a 1226 MIDCOM MIB module. SMI, the language used for defining MIB modules, 1227 is flexible enough to allow the implementation of a MIB module to 1228 meet the semantics of this requirement. 1230 RSIP: The ports parameter of the RSIP ASSIGN_REQUESTs specifically 1231 allows multiple, consecutive port numbers to be specified. 1233 Megaco: Megaco can be easily extended using a MIDCOM specific 1234 Package to support this feature. 1236 Diameter: This capability is not part of the current IPFilterRule 1237 type definition. Rather than modify the IPFilterRule type, MIDCOM 1238 could group it with other AVPs which add the missing information. 1240 COPS: The COPS protocol has all the flexibility to meet this 1241 requirement by using a COPS MIDCOM specific client or a MIDCOM 1242 specific PIB. 1244 2.2.11 More precise rulesets contradicting overlapping rulesets 1246 SNMP: P+, RSIP: P+, Megaco: P+, Diameter: T, COPS: P+ 1248 SNMP: This requirement can be met by an appropriate definition of a 1249 MIDCOM MIB module. 1251 MIDCOM Protocol Evaluation November 2002 1253 RSIP: To support this requirement, a new optional boolean 1254 parameter, overlapOK, can be added to the RSIP ASSIGN_REQUESTs. If 1255 the parameter is TRUE, the binding may overlap with an existing 1256 binding. If the parameter is unspecified, or is FALSE, the binding 1257 will not overlap with an existing binding, thus maintaining 1258 backward compatibility with the current definition of RSIP. 1260 Megaco: This requirement would be met if the policy in the 1261 Middlebox allows contradictory, overlapping policy rules to be 1262 installed. 1264 Diameter: Allowed by the IPFilterRule semantics described in 1265 Appendix D. 1267 COPS: The COPS protocol has all the flexibility to meet this 1268 requirement by using a COPS MIDCOM specific client or a MIDCOM 1269 specific PIB. 1271 2.3 General Security Requirements 1273 This section contains the individual protocols as evaluated against 1274 the General Security requirements from section 2.3 of the 1275 requirements document [1]. A short description of each of the 1276 protocols is provided to substantiate the evaluation. 1278 2.3.1 Message Authentication, confidentiality and Integrity 1280 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 1282 SNMP: SNMPv3 includes the User-based Security Model (USM, 1283 [RFC2574]), which defines three standardized methods for providing 1284 authentication, confidentiality, and integrity. Additionally, USM 1285 has specific built-in mechanisms for preventing replay attacks 1286 including unique protocol engine IDs, timers and counters per 1287 engine and time windows for the validity of messages. 1289 RSIP: This requirement can be met by operating RSIP over IPSec. The 1290 RSIP framework recommends all communication between an RSIP host 1291 and gateway be authenticated. Authentication, in the form of a 1292 message hash appended to the end of each RSIP protocol packet, can 1293 serve to authenticate the RSIP host and gateway to one another, 1294 provide message integrity, and avoid replay attacks with an anti- 1295 replay counter. However, the message hash and replay counter 1296 parameters would need to be defined for the RSIP protocol. 1298 Megaco: Megaco provides for these functions with the combined usage 1299 of IPSEC or TLS. 1301 Diameter: Diameter relies on either IPSEC or TLS for these 1302 functions. 1304 COPS: COPS has built-in message level security for authentication, 1305 replay protection, and message integrity. COPS can also use TLS or 1306 IPSec, thus reusing existing security mechanisms that have 1307 interoperated in the markets. 1309 MIDCOM Protocol Evaluation November 2002 1311 2.3.2 Optional Confidentiality Protection 1313 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 1315 SNMP: SNMPv3 includes the User-based Security Model, which defines 1316 three standardized methods for providing authentication, 1317 confidentiality, and integrity, and is open to add further methods. 1318 The method to use can be optionally chosen. 1320 RSIP: Refer to 2.3.1. 1322 Megaco: Refer to 2.3.1 1324 Diameter: Implementation support of IPSEC ESP in Diameter 1325 applications is not optional. Deployment of either IPSEC or TLS is 1326 optional. 1328 COPS: Refer to 2.3.1. 1330 2.3.3 Operate Across Untrusted Domains 1332 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 1334 SNMP: The User-based Security Model of SNMPv3 defines three 1335 standardized methods for providing authentication, confidentiality, 1336 and integrity, and it is open to add further methods. These methods 1337 operate securely across untrusted domains. 1339 RSIP: Refer to 2.3.1. 1341 Megaco: Refer to 2.3.1. 1343 Diameter: The Diameter specification [28] recommends the use of TLS 1344 across untrusted domains. 1346 COPS: Refer to 2.3.1 1348 2.3.4 Mitigates Replay Attacks on Control Messages 1350 SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T 1352 SNMP: The User-based Security Model for SNMPv3 has specific built- 1353 in mechanisms for preventing replay attacks including unique 1354 protocol engine IDs, timers and counters per engine and time 1355 windows for the validity of messages. 1357 RSIP: Refer to 2.3.1 1359 Megaco: Megaco commands and responses include matching transaction 1360 identifiers. The recipient receiving the same transaction id 1361 multiple times would discard the message, thus providing some 1362 protection against replay attacks. If even stronger protection 1363 against replay attack is needed, Megaco provides for the use of 1364 IPSec or TLS. 1366 Diameter: Diameter requires that implementations support the replay 1367 protection mechanisms of IPSEC. 1369 MIDCOM Protocol Evaluation November 2002 1371 COPS: Refer to 2.3.1 1373 3 Conclusions 1375 The overall statistics with regards to the number of Fully 1376 Compliant, Partially Compliant (P+ and P) and Failing Compliancy 1377 requirements for each of the protocols is summarized in table 1. 1379 T P+ P F 1380 ----------------------------------------------------------------- 1381 SNMP 22 5 0 0 1382 RSIP 17 7 3 0 1383 Megaco 19 5 3 0 1384 Diameter 21 5 1 0 1385 COPS 20 5 2 0 1387 Table 1: Totals across all Requirements 1389 In considering the P+ category of compliancy, an important aspect 1390 is the mechanism for support of extensibility. The extension 1391 mechanism provided by SNMP and COPS-PR using MIBs and PIBs 1392 respectively, provides extensions with no impact to the protocol. 1393 Diameter extensions require protocol changes, thus has a higher 1394 impact, although the extensions can be handled by other Diameter 1395 entities without being understood. Megaco's extension mechanisms 1396 of packages also requires protocol changes that must be understand 1397 by both sending and receiving entities, also being considered 1398 higher impact. The RSIP extension mechanism has the largest impact 1399 on the existing protocol and is based upon defining the necessary 1400 new parameters. 1402 The SNMP management framework meets all the specified MIDCOM 1403 protocol requirements with the appropriate design of a MIDCOM MIB 1404 module. SNMP is a proven technology with stable and proven 1405 development tools, already has extensions defined to support NAT 1406 configuration and policy-based management. SNMPv3 is a full 1407 standard, is more mature and has undergone more validation than the 1408 other protocols in the evaluation, and has been deployed to manage 1409 large-scale real-world networks (e.g. DOCSIS cable modem networks). 1410 The applicability of SNMP to the MIDCOM framework has a restriction 1411 in that it assumes the MIDCOM PDP is part of the Middlebox. 1413 RSIP fully meets many of the MIDCOM requirements. However, it does 1414 require additions and extensions to meet several of the 1415 requirements. RSIP would also require several framework elements to 1416 be added to the MIDCOM framework as identified in section 1.2.3. In 1417 addition, the tunneling required for RSIP as described in section 1418 1.2.4, results in RSIP not being acceptable by the WG as the MIDCOM 1419 protocol. 1421 Megaco fully meets most of the key requirements for the MIDCOM 1422 Protocol. Additional extensions in the form of a new Termination / 1423 Package definition would be required for MIDCOM to meet several of 1424 the requirements. In order to meet the remaining requirements, 1425 modeling the underlying Middlebox resources (e.g., filters, policy 1426 rules) as separate elements from the Megaco entities might allow 1427 the usage of the protocol as-is, satisfying some of the resource 1428 access control requirements. 1430 MIDCOM Protocol Evaluation November 2002 1432 The Diameter evaluation indicated a good overall fit. Some 1433 partially met requirements were identified that could be addressed 1434 by a new application extension. However, the Diameter architecture 1435 may be too heavy for the MIDCOM application and clearly much of the 1436 Diameter base is not needed. In addition, Diameter is the only 1437 protocol in the evaluation for which the RFCs are not yet 1438 published. Other than these reservations, the protocol is a good 1439 fit to MIDCOM requirements. 1441 The COPS evaluation indicates that the protocol meets the majority 1442 of the MIDCOM protocol requirements by using the protocol's native 1443 extension techniques, with COPS-PR being explicitly required to 1444 meet requirements 2.1.3 and 2.2.3. In order to fully satisfy one 1445 partially met requirement, 2.1.1, the COPS model would need to 1446 allow a PDP to establish communication with a PEP. While not 1447 explicitly prohibited by the COPS model, this would require 1448 additions, in the form of local policy, to ensure the proper 1449 establishment of an authorized association. 1451 Security Considerations 1453 Security considerations for the MIDCOM protocol are covered by the 1454 comparison against the specific Security requirements in the MIDCOM 1455 requirements document [1] and are specifically addressed by section 1456 2.1.8 and section 2.3. 1458 Normative References 1460 [1] R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 1461 Communications (MIDCOM) Protocol Requirements", RFC 3304, August, 1462 2002. 1464 [2] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, 1465 "Middlebox Communications Architecture and Framework", RFC 3303, 1466 August, 2002. 1468 [3] Rose, M., and K. McCloghrie, "Management Information Base for 1469 Network Management of TCP/IP-based internets: MIB-II", RFC 1213, 1470 March, 1991. 1472 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1473 Levels", RFC 2119, March 1997. 1475 [5] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 1476 for Describing SNMP Management Frameworks", STD 62, RFC 3411, 1477 November 2002. 1479 [6] Rose, M., and K. McCloghrie, "Structure and Identification of 1480 Management Information for TCP/IP-based Internets", STD 16, RFC 1481 1155, May 1990. 1483 [7] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16, 1484 RFC 1212, March 1991. 1486 [8] M. Rose, "A Convention for Defining Traps for use with the 1487 SNMP", RFC 1215, March 1991. 1489 MIDCOM Protocol Evaluation November 2002 1491 [9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 1492 M., and S. Waldbusser, "Structure of Management Information Version 1493 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1495 [10] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1496 Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 1497 58, RFC 2579, April 1999. 1499 [11] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1500 Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", 1501 STD 58, RFC 2580, April 1999. 1503 [12] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1504 Network Management Protocol", STD 15, RFC 1157, May 1990. 1506 [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1507 "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 1509 [14] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1510 "Transport Mappings for Version 2 of the Simple Network 1511 Management Protocol (SNMPv2)", RFC 1906, January 1996. 1513 [15] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1514 Processing and Dispatching for the Simple Network Management 1515 Protocol (SNMP)", STD 62, RFC 3412, November 2002. 1517 [16] Blumenthal, U., and B. Wijnen, "User-based Security Model(USM) 1518 for version 3 of the Simple Network Management Protocol (SNMPv3)", 1519 STD 62, RFC 3414, November 2002. 1521 [17] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1522 "Protocol Operations for Version 2 of the Simple Network Management 1523 Protocol (SNMPv2)", RFC 1905, January 1996. 1525 [18] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 1526 STD 62, RFC 3413, November 2002. 1528 [19] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1529 Control Model (VACM) for the Simple Network Management Protocol 1530 (SNMP)", STD 62, RFC 3415, November 2002. 1532 [20] Case, J., Mundy, R., Partain, D., and B. Stewart, 1533 "Introduction to Version 3 of the Internet-standard Network 1534 Management Framework", 3410, November 2002. 1536 [21] M. Borella, J. Lo, D. Grabelsky, G. Montenegro, "Realm 1537 Specific IP: Framework", RFC 3102, October, 2001. 1539 [22] M. Borella, D. Grabelsky, J. Lo, K. Taniguchi, "Realm Specific 1540 IP: Protocol Specification",_RFC 3103, October 2001. 1542 [23] G. Montenegro, M. Borella, "RSIP Support for End-to-end 1543 Ipsec", RFC 3104, October 2001. 1545 [24] J. Kempf, G. Montenegro, "Finding an RSIP Server with SLP", 1546 RFC 3105, October 2001. 1548 [25] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. 1549 Segers, "Megaco Protocol Version 1.0", RFC 3015, November, 2000. 1551 MIDCOM Protocol Evaluation November 2002 1553 [26] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402, 1554 November 1998. 1556 [27] S. Kent, R. Atkinson, "IP Encapsulating Security Payload", 1557 RFC 2406, November 1998. 1559 [28] P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney, 1560 "Diameter Base Protocol", draft-ietf-aaa-diameter-15.txt, IETF 1561 work in progress, October 2002. 1563 [29] P. Calhoun, G. Zorn, P. Pan, H. Akhtar, "Diameter Framework 1564 Document", draft-ietf-aaa-diameter-framework-01.txt, IETF work in 1565 progress, March 2001. 1567 [30] P. Calhoun, W. Bulley, A. Rubens, J. Haag, G. Zorn, D. 1568 Spence, "Diameter NASREQ Application", draft-ietf-aaa-diameter- 1569 nasreq-09.txt, IETF work in progress, March 2002. 1571 [31] D.Durham et al, "The COPS (Common Open Policy Service) 1572 Protocol", RFC 2748, January 2000. 1574 [32] K. Chan, D. Durham, S. Gai, S. Herzog, K. McCloghrie, F. 1575 Reichmeyer, J. Seligson, A. Smith, R. Yavatkar, "COPS Usage 1576 for Policy Provisioning", RFC 3084, March 2001. 1578 [33] D. Raz, J. Schoenwalder, B. Sugla, "An SNMP Application Level 1579 Gateway for Payload Address Translation", RFC 2962, October 2000. 1581 Informative References 1583 [34] K. McCloghrie, F. Kastenholz, " The Interfaces Group MIB", RFC 1584 2863, June, 2000. 1586 Contributors 1588 The following identifies the key contributors who provided the primary 1589 content for this document in the form of individual drafts for each 1590 protocol: 1592 RSIP 1594 Jim Renkel 1595 The CommWorks Corp., a 3Com company 1596 3800 Golf Rd. Phone: +1.847.262.2539 1597 Rolling Meadows, IL, USA Email:james_renkel@commworks.com 1599 SNMP 1601 Juergen Quittek 1602 NEC Europe Ltd. 1603 Network Laboratories 1604 Kurfuersten-Anlage 34 1605 69115 Heidelberg Phone: +49 6221 90511-15 1606 Germany Email: quittek@ccrle.nec.de 1608 David Harrington Co-chair SNMPv3 WG 1609 Enterasys Networks 1610 35 Industrial Way Phone: +1 603-337-2614 1611 Rochester, NH 03867-5005 EMail: dbh@enterasys.com 1612 MIDCOM Protocol Evaluation November 2002 1614 Megaco 1616 Sanjoy Sen 1618 Cedric Aoun 1619 Nortel Networks Email: cedric.aoun@nortelnetworks.com 1621 Tom Taylor 1622 Nortel Networks Email: taylor@nortelnetworks.com 1624 Diameter 1626 Tom Taylor 1627 Nortel Networks 1628 1852 Lorraine Ave. 1629 Ottawa, Ontario Phone: +1 613 736 0961 1630 Canada K1H 6Z8 Email: taylor@nortelnetworks.com 1632 COPS 1634 Cedric Aoun 1635 Nortel Networks 1636 FRANCE Email: cedric.aoun@nortelnetworks.com 1638 Kwok-Ho Chan 1639 Nortel Networks 1640 600 Technology Park Drive 1641 Billerica, MA 01821 Email: khchan@nortelnetworks.com 1643 Louis-Nicolas Hamer 1644 Nortel Networks 1645 PO Box 3511 Station C 1646 Ottawa, Ontario Phone: +1 613.768.3409 1647 Canada K1Y 4H7 Email: nhamer@nortelnetworks.com 1649 Reinaldo Penno 1650 Nortel Networks 1651 2305 Mission College Boulevard 1652 Building SC9 1653 Santa Clara, CA 95054 Email: rpenno@nortelnetworks.com 1655 Sanjoy Sen 1657 Acknowledgements 1659 The editor would like to acknowledge the constructive feedback 1660 provided by Joel M. Halpern on the individual protocol evaluation 1661 contributions. In addition, a thanks to Elwyn Davies, Christopher 1662 Martin, Bob Penfield, Scott Brim and Martin Stiemerling for 1663 contributing to the mailing list discussion on the draft content. 1665 Author's Address 1667 Mary Barnes 1668 Nortel Networks 1669 2380 Performance Drive Phone: 1-972-684-5432 1670 Richardson, TX USA Email: mbarnes@nortelnetworks.com 1671 MIDCOM Protocol Evaluation November 2002 1673 Appendix A - SNMP Overview 1675 The SNMP Management Framework presently consists of five major 1676 components: 1678 o An overall architecture, described in RFC 3411 [RFC3411]. A 1679 more detailed introduction and applicability statements for 1680 the SNMP Management Framework can be found in RFC 3410 1681 [RFC3410]. 1683 o Mechanisms for describing and naming objects and events for 1684 the purpose of management. The current version of this 1685 Structure of Management Information (SMI) is called called 1686 SMIv2 and described in RFC 2578 [RFC2578], RFC 2579 [RFC2579] 1687 and RFC 2580 [RFC2580]. 1689 o Message protocols for transferring management information. 1690 The current version of the message protocol is called SNMPv3 1691 and described in RFC 3412 [RFC3412], RFC 3414 [RFC3414] and 1692 RFC 3417 [RFC3417]. 1694 o Protocol operations for accessing management information. The 1695 current version of the protocol operations and associated PDU 1696 formats is described in RFC 3416 [RFC3416]. 1698 o A set of fundamental applications described in RFC 3413 1699 [RFC3413] and the view-based access control mechanism 1700 described in RFC 3415 [RFC2415]. 1702 Managed objects are accessed via a virtual information store, 1703 termed the Management Information Base or MIB. Objects in the MIB 1704 are defined using the mechanisms defined in the SMI. 1706 A.1 SNMPv3 Proxy Forwarding 1708 SNMPv3 proxy forwarding (RFC3413) provides a standardized mechanism 1709 to configure an intermediate node to forward SNMP messages. A 1710 command generating entity sends requests to a proxy forwarding 1711 entity that forwards the request to a third entity. 1713 One SNMP entity may serve both functions � as the SNMP �agent� to 1714 monitor and configure the node on which it is resident, and as an 1715 intermediate node in a proxy relationship to permit monitoring and 1716 configuration of additional entities. 1718 Each entity is identified by a unique engineID value, specifically 1719 to support proxy between addressing domains and/or trust domains. 1720 An SNMPv3 message contains two engineIDs- one to identify the 1721 database to be used for message security, and one to identify the 1722 source (or target) of the contained data. Message security is 1723 applied between the originator and the proxy, and then between the 1724 proxy and the end-target. The PDU contains the engineID of the node 1725 whose data is contained in the message, which passes end-to-end, 1726 unchanged by the proxy. 1728 SNMPv3 proxy was designed to provide a standard SNMP approach to 1729 inserting an intermediate node in the middle of communications for 1730 a variety of scenarios. SNMPv3 proxy can support crossing 1731 addressing domains, such as IPv4 and IPv6, crossing SNMP version 1732 MIDCOM Protocol Evaluation November 2002 1734 domains, such as SNMPv3 and SNMPv1, crossing security mechanism 1735 domains, such as DES and AES, and for providing a single point of 1736 management contact for a subset of the network, such as managing a 1737 private network through a NAT device or a VPN endpoint. 1739 A.2 Proxies versus Application Level Gateways 1741 Proxies are generally preferred to Application Level Gateways for 1742 SNMP. ALGs typically modify the headers and content of messages. 1743 SNMP is a protocol designed for troubleshooting network (mis-) 1744 configurations. Because an operator needs to understand the actual 1745 configuration, the translation of addresses within SNMP data causes 1746 confusion, hiding the actual configuration of a managed device from 1747 the operator. ALGs also introduce security vulnerabilities, and 1748 other complexities related to modifying SNMP data. 1750 SNMP Proxies can modify message headers without modifying the 1751 contained data. This avoids the issues associated with translating 1752 the payload data, while permitting application level translation of 1753 addresses. 1755 The issues of ALGs versus proxies for SNMP Payload Address 1756 Translation are discussed at length in RFC2962. 1758 Appendix B - RSIP with tunneling 1760 NAT requires ALGs (Application Layer Gateways) in middleboxes 1761 without MIDCOM, and application modifications or agents for 1762 middleboxes with MIDCOM. 1764 Support for NAT without tunneling could easily be added to the RSIP 1765 control protocol. NAT would be defined as a new, null tunnel type. 1766 Support for the NAT null tunnels could be implemented in hosts, or 1767 in applications or application agents. 1769 If support for NAT null tunnels were implemented in hosts, no 1770 modifications to applications would be required, and no application 1771 agents or ALGs would be required. This has obvious advantages. In 1772 addition to the NAT null tunnel, the host would have to implement 1773 an RSIP / MIDCOM client (or a STUN client) and the middlebox would 1774 have to implement an RSIP / MIDCOM server, or a STUN server would 1775 have to be available _beyond_ the middlebox. Note that the STUN 1776 client / server approach may not work with all types of 1777 middleboxes. 1779 If support for NAT null tunnels were NOT implemented in hosts, then 1780 applications would have to be modified, or application agents or 1781 ALGs would have to be implemented. This has the advantage over 1782 tunnels (whether null or not) of not requiring modification to 1783 hosts, but would require the modification of host applications or 1784 the implementation of application agents, both of which would 1785 include an RSIP / MIDCOM client, and the implementation of an 1786 RSIP/MIDCOM server in the middlebox. Again, in some situations, 1787 STUN could be used instead of RSIP / MIDCOM. 1789 Tunneled or not, an RSIP / MIDCOM server is needed in the 1790 middlebox. Tunneled, the host needs to be modified, but not the 1791 application. Untunneled, an agent must be added or the application 1792 must be modified, but there would be no host modifications. The 1793 MIDCOM Protocol Evaluation November 2002 1795 advantages/disadvantages of tunneling would need to be evaluated in 1796 considering RSIP. 1798 Appendix C - Megaco Modeling Approach 1800 To model the Middlebox functions such as firewall, NAT etc., a new 1801 Middlebox Termination type needs to be defined within Megaco. If 1802 policy-rule overlap or modification by multiple Agents is NOT 1803 required, then a policy rule is equivalent to a Termination (see 1804 Figure 1). The various components of a Policy rule such as filter, 1805 action, life-time, creator etc. are described as various properties 1806 of a Termination. Use of the Virtual Media Gateway (VMG) concept 1807 allows for conflict-free interaction of multiple MA's with the same 1808 MB. 1810 +-------+ +-------+ 1811 | MA-1 | | MA-2 | 1812 | | | | 1813 +-------+ |IF2 +-------+ 1814 | | | 1815 +-------------|---------|----------|-----------+ 1816 | +---------+ | +-------------+ | 1817 IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3 1818 ----------| |Tx|-------+ +---|Ty|--|Tz|---------------- 1819 | | +--+ | | | +--+ +--+ | | 1820 | ....| | | +-------------+ | 1821 | +---------+ | | 1822 | +--------------------------------- 1823 | Middlebox | IF4 1824 +----------------------------------------------+ 1826 Tx: Termination x = Policy rule x 1827 Ty: Termination y = Policy rule y 1828 Tz: Termination z = Policy rule z 1829 MA: MIDCOM Agent 1830 IF: Interface 1832 Figure 1. 1834 If it is required to allow multiple agents manipulate the same 1835 Middlebox resource (e.g., a Policy rule or a filter), the latter 1836 needs to be kept separate from the Termination (the Policy rule is 1837 manipulated by the MA by manipulating the properties of the 1838 associated Termination). For example, if overlapping policy rule 1839 manipulation is required, then a Termination shall be associated 1840 with a single policy rule, but a policy rule may be associated with 1841 more than one Termination. Thus, a Termination can share a policy 1842 rule with another Termination, or have a policy rule partially 1843 overlapping with that of another Termination. This model allows two 1844 MA�s, controlling two distinct Terminations (see Figure 2), 1845 manipulate the same or overlapping policy rules. In Figure 2, 1846 policy rules 1 and 2 are overlapping and they are shared by MA-1 1847 and MA-2. 1848 +-------+ +-------+ 1849 | MA-1 | | MA-2 | 1850 | | | | 1851 +-------+ |IF2 +-------+ 1852 | | | MB 1853 MIDCOM Protocol Evaluation November 2002 1855 +-------------|---------|----------|-----------+ 1856 | +-----------+ | +-------------+ | 1857 IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3 1858 ------------------|Ty|----+ +---|Tx|--|Tz|---------------- 1859 | | +--+ | | | +--+ +--+ | | 1860 | .... | | | | +--/------\---+ | 1861 | +-------|---+ | / \ | 1862 | | +----/----------\------------------ 1863 | +------+----+------+ +------+ |IF4 1864 | |Policy1 Policy2 | |Policy| | 1865 | | | | | | 3 | | 1866 | +----+------+------+ +------+ | 1867 +----------------------------------------------+ 1869 Tx: Termination x 1870 Ty: Termination y 1871 Tz: Termination z 1872 MA: MIDCOM Agent 1873 IF: Interface 1874 MB: Middlebox 1876 Figure 2. 1878 This requires that the Agent and the Middlebox adhere to the 1879 following principles: 1881 (1) Only one Termination has read/write access to a filter at any 1882 time. 1883 (2) When the policy rule is being modified by a new agent (i.e. 1884 not the one that created the policy) the Middlebox makes a policy 1885 decision and decides whether to accept the requested modification 1886 or not. In the case the modification is accepted the initial MIDCOM 1887 agent may be notified. 1889 Appendix D - Diameter IPFilter Rule 1891 The IPFilterRule format is derived from the OctetString AVP Base 1892 Format. It uses the UTF-8 encoding and has the same requirements 1893 as the UTF8String. Packets may be filtered based on the following 1894 information that is associated with it: 1896 Direction (in or out) 1897 Source and destination IP address (possibly masked) 1898 Protocol 1899 Source and destination port (lists or ranges) 1900 TCP flags 1901 IP fragment flag 1902 IP options 1903 ICMP types 1905 Rules for the appropriate direction are evaluated in order, with 1906 the first matched rule terminating the evaluation. Each packet is 1907 evaluated once. If no rule matches, the packet is dropped if the 1908 last rule evaluated was a permit, and passed if the last rule was a 1909 deny. 1911 MIDCOM Protocol Evaluation November 2002 1913 IPFilterRule filters MUST follow the format: 1915 action dir proto from src to dst [options] 1917 action permit - Allow packets that match the rule. 1918 deny - Drop packets that match the rule. 1920 dir "in" is from the terminal, "out" is to the 1921 terminal. 1923 proto An IP protocol specified by number. The "ip" 1924 keyword means any protocol will match. 1926 src and dst
[ports] 1928 The
may be specified as: 1930 ipno An IPv4 or IPv6 number in dotted- 1931 quad or canonical IPv6 form. Only 1932 this exact IP number will match the 1933 rule. 1935 ipno/bits An IP number as above with a mask 1936 width of the form 1.2.3.4/24. In 1937 this case, all IP numbers from 1938 1.2.3.0 to 1.2.3.255 will match. 1939 The bit width MUST be valid for the 1940 IP version and the IP number MUST 1941 NOT have bits set beyond the mask. 1943 For a match to occur, the same IP 1944 version must be present in the 1945 packet that was used in describing 1946 the IP address. To test for a 1947 particular IP version, the bits part 1948 can be set to zero. The keyword 1949 "any" is 0.0.0.0/0 or the IPv6 1950 equivalent. The keyword "assigned" 1951 is the address or set of addresses 1952 assigned to the terminal. For IPv4, 1953 a typical first rule is often 1954 "deny in ip! assigned" 1956 The sense of the match can be inverted by 1957 preceding an address with the not modifier (!), 1958 causing all other addresses to be matched 1959 instead. This does not affect the selection of 1960 port numbers. 1962 With the TCP, UDP and SCTP protocols, optional 1963 ports may be specified as: 1965 {port|port-port}[,ports[,...]] 1967 The '-' notation specifies a range of ports 1968 (including boundaries). 1970 Fragmented packets that have a non-zero offset 1971 (i.e. not the first fragment) will never match 1972 MIDCOM Protocol Evaluation November 2002 1974 a rule that has one or more port 1975 specifications. See the frag option for 1976 details on matching fragmented packets. 1978 options: 1980 frag Match if the packet is a fragment and this is not 1981 the first fragment of the datagram. frag may not 1982 be used in conjunction with either tcpflags or 1983 TCP/UDP port specifications. 1985 ipoptions spec 1986 Match if the IP header contains the comma 1987 separated list of options specified in spec. The 1988 supported IP options are: 1990 ssrr (strict source route), lsrr (loose source 1991 route), rr (record packet route) and ts 1992 (timestamp). The absence of a particular option 1993 may be denoted with a '!'. 1995 tcpoptions spec 1996 Match if the TCP header contains the comma 1997 separated list of options specified in spec. The 1998 supported TCP options are: 2000 mss (maximum segment size), window (tcp window 2001 advertisement), sack (selective ack), ts (rfc1323 2002 timestamp) and cc (rfc1644 t/tcp connection 2003 count). The absence of a particular option may 2004 be denoted with a '!'. 2006 established 2007 TCP packets only. Match packets that have the RST 2008 or ACK bits set. 2010 setup TCP packets only. Match packets that have the SYN 2011 bit set but no ACK bit. 2013 tcpflags spec 2014 TCP packets only. Match if the TCP header 2015 contains the comma separated list of flags 2016 specified in spec. The supported TCP flags are: 2018 fin, syn, rst, psh, ack and urg. The absence of a 2019 particular flag may be denoted with a '!'. A rule 2020 that contains a tcpflags specification can never 2021 match a fragmented packet that has a non-zero 2022 offset. See the frag option for details on 2023 matching fragmented packets. 2025 icmptypes types 2026 ICMP packets only. Match if the ICMP type is in 2027 the list types. The list may be specified as any 2028 combination of ranges or individual types 2029 separated by commas. Both the numeric values and 2030 the symbolic values listed below can be used. The 2031 supported ICMP types are: 2033 echo reply (0), destination unreachable (3), 2034 MIDCOM Protocol Evaluation November 2002 2036 source quench (4), redirect (5), echo request 2037 (8), router advertisement (9), router 2038 solicitation (10), time-to-live exceeded (11), IP 2039 header bad (12), timestamp request (13), 2040 timestamp reply (14), information request (15), 2041 information reply (16), address mask request (17) 2042 and address mask reply (18). 2044 There is one kind of packet that the access device MUST always 2045 discard, that is an IP fragment with a fragment offset of one. This 2046 is a valid packet, but it only has one use, to try to circumvent 2047 firewalls. 2049 An access device that is unable to interpret or apply a deny rule 2050 MUST terminate the session. An access device that is unable to 2051 interpret or apply a permit rule MAY apply a more restrictive rule. 2052 An access device MAY apply deny rules of its own before the 2053 supplied rules, for example to protect the access device owner's 2054 infrastructure. 2056 The rule syntax is a modified subset of ipfw(8) from FreeBSD, and 2057 the ipfw.c code may provide a useful base for implementations. 2059 Intellectual Property Statements 2061 The IETF has been notified of intellectual property rights claimed 2062 in regard to some or all of the specification contained in this 2063 document. For more information consult the online list of claimed 2064 rights. 2066 Full Copyright Statement 2068 Copyright (C) The Internet Society (2002). All Rights Reserved. 2070 This document and translations of it may be copied and furnished to 2071 others, and derivative works that comment on or otherwise explain 2072 it 2073 or assist in its implementation may be prepared, copied, published 2074 and distributed, in whole or in part, without restriction of any 2075 kind, provided that the above copyright notice and this paragraph 2076 are included on all such copies and derivative works. However, 2077 this 2078 document itself may not be modified in any way, such as by removing 2079 the copyright notice or references to the Internet Society or other 2080 Internet organizations, except as needed for the purpose of 2081 developing Internet standards in which case the procedures for 2082 copyrights defined in the Internet Standards process must be 2083 followed, or as required to translate it into languages other than 2084 English. The limited permissions granted above are perpetual and 2085 will not be revoked by the Internet Society or its successors or 2086 assigns. This document and the information contained 2087 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 2088 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 2089 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 2090 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2091 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2092 PARTICULAR PURPOSE."