idnits 2.17.1 draft-barnes-midcom-mib-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. 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 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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.) -- The document date (June 2003) is 7614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '81XMIB' is mentioned on line 313, but not defined == Missing Reference: 'RFC2574' is mentioned on line 531, but not defined ** Obsolete undefined reference: RFC 2574 (Obsoleted by RFC 3414) == Unused Reference: 'RFC3412' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'RFC3413' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC3414' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'RFC3415' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'MDCPEV' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC 2475' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'RFC2564' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC2594' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'RFC3290' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'DPCMIB' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'BRGMIB' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'BREMIB' is defined on line 661, but no explicit reference was found in the text == Unused Reference: '81xMIB' is defined on line 665, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3304 ** Downref: Normative reference to an Informational RFC: RFC 3303 == Outdated reference: A later version (-08) exists of draft-ietf-midcom-semantics-02 ** Downref: Normative reference to an Informational draft: draft-ietf-midcom-semantics (ref. 'MDCSEM') == Outdated reference: A later version (-09) exists of draft-ietf-nat-natmib-05 == Outdated reference: A later version (-15) exists of draft-ietf-snmpconf-pm-13 -- No information found for draft-ietf-ipsp-ipsec-conf-MIB - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPCMIB' == Outdated reference: A later version (-09) exists of draft-ietf-snmpconf-diffpolicy-05 -- No information found for draft-ietf-bridge-bridgeMIB-smiv2 - is the name correct? == Outdated reference: A later version (-07) exists of draft-ietf-bridge-ext-v2-01 == Outdated reference: A later version (-03) exists of draft-ietf-bridge-8021x-01 Summary: 7 errors (**), 0 flaws (~~), 22 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Barnes 2 Document: draft-barnes-midcom-mib-01.txt Nortel Networks 3 Wes Hardaker 4 Sparta 5 D. Harrington 6 Enterasys Networks 7 M. Stiemerling 8 Category: Standards Track NEC Europe Ltd. 9 Expires: December 2003 June 2003 11 Middlebox Communications (MIDCOM) Protocol Managed Objects 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes and defines the managed objects for dynamic 40 configuration of middleboxes. The scope of the middleboxes to which 41 these managed objects apply is limited to NATs and Firewalls. 42 However, the MIB module as defined by this document is intended to 43 provide a baseline for the dynamic configuration of other types of 44 middleboxes. The applicability of existing Management Information 45 Base (MIB) modules to the MIDCOM requirements, framework and 46 semantics is described. Additional managed objects are defined to 47 satisfy the entirety of the MIDCOM requirements, framework and 48 semantics, providing a complete MIDCOM MIB for NATs and Firewalls to 49 fully realize the requirements of the MIDCOM protocol. 51 Table of Contents 53 1. SNMP Management Framework......................................3 54 2. MIDCOM Overview and SNMP Applicability.........................3 55 3. SNMP and the MIDCOM data model.................................4 56 3.1 Secure Communications......................................6 57 3.2 Device Configuration.......................................6 58 3.3 Service Configuration......................................7 59 3.4 Policy Coordination........................................8 60 4. Applicability of existing MIB modules..........................9 61 4.1 Network Address Translators (NAT) MIB.....................10 62 4.2 Policy Based Management MIB...............................10 63 4.3 IPsec Policy Configuration MIB............................10 64 4.4 Differentiated Services MIB...............................11 65 5. Additional MIDCOM specific managed objects....................11 66 6. Security Considerations.......................................12 67 7. Changes since last version....................................12 68 Normative References.............................................12 69 Informative References...........................................14 70 Full Copyright Statement.........................................16 72 Overview 74 This intent of this document is to define a Management Information 75 base (MIB) for dynamic configuration of middleboxes. The scope of the 76 middleboxes to which this MIB is specifically applied is limited to 77 NATs and Firewalls. However, this MIB is intended to be extensible 78 and provide a baseline for the development of managed objects for 79 configuring other types of middleboxes. 81 Section 1 provides an overview of the SNMP Management Framework. 82 Section 2 provides further background on SNMP and its applicability 83 to the MIDCOM Protocol Framework, Requirements and semantics. 85 Section 3 provides a high level overview of some existing MIB modules 86 potentially relevant and reusable, which satisfy the MIDCOM 87 requirements and semantics, and relate to the MIDCOM architecture and 88 framework. 90 Section 4 provides a detailed discussion of existing MIB modules, 91 defining the level of applicability to the MIDCOM protocol 92 requirements, framework and semantics and re-usability for the MIDCOM 93 MIB. 95 Section 5 defines the additional MIDCOM specific managed objects 96 required to satisfy some of the requirements and to provide a linkage 97 between the existing MIB modules applicable to MIDCOM. 99 Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 1. SNMP Management Framework 107 For a detailed overview of the documents that describe the current 108 Internet-Standard (SNMP) Management Framework, please refer to 109 section 7 of RFC 3410 [RFC3410]. 111 Managed objects are accessed via a virtual information store, termed 112 the Management Information Base or MIB. MIB objects are generally 113 accessed through the Simple Network Management Protocol (SNMP). 114 Objects in the MIB are defined using the mechanisms defined in the 115 Structure of Management Information (SMI). This memo specifies a MIB 116 module that is compliant to the SMIv2, which is described in STD 58, 117 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 118 2580[RFC2580]. 120 2. MIDCOM Overview and SNMP Applicability 122 The MIDCOM architecture and framework [RFC3303] defines a model in 123 which trusted third parties can be delegated to assist middleboxes in 124 performing their operations, without requiring application 125 intelligence be embedded in the middleboxes. This trusted third party 126 is referred to as the MIDCOM Agent. The MIDCOM protocol is defined 127 between the MIDCOM agent and middlebox. 129 The SNMP management framework provides functions equivalent to those 130 defined by the MIDCOM framework, although there are a few 131 architectural differences. 133 For SNMP, application intelligence is captured in MIB modules, rather 134 than in the messaging protocol. MIB modules define a data model of 135 the information that can be collected and configured for managed 136 functionality. The SNMP messaging protocol transports the data in a 137 standardized format without needing to understand the semantics of 138 the data being transferred. The endpoints of the communication 139 understand the semantics of the data. 141 Traditionally, the SNMP endpoints have been called Manager and Agent. 142 An SNMP manager is an entity capable of generating requests and 143 receiving notifications, and a SNMP agent is an entity capable of 144 responding to requests and generating notifications. As applied to 145 the MIDCOM framework, the SNMP Manager corresponds to the MIDCOM 146 agent and the SNMP Agent corresponds to the Middlebox. 148 The MIDCOM protocol is divided into three phases, per section 4 of 149 [RFC3303]: 150 . Session Setup 151 . Run-time (involving real-time configuration of the middlebox) 152 . Session Termination 153 A MIDCOM session is defined to be a lasting association between a 154 MIDCOM agent and a middlebox. The MIDCOM agent should initiate the 155 session prior to the start of the application. Although the SNMP 156 management framework does not have the concept of a session, session- 157 like associations can be established through the use of managed 158 objects. Requests from the MIDCOM agent to the Middlebox are 159 performed using write access to managed objects defined in MIB 160 modules. The middlebox (SNMP agent) responds to requests by sending 161 an SNMP response message indicating the success or failure of the 162 request. The MIDCOM agent (SNMP manager) MAY verify this information 163 by reading or polling the corresponding managed objects. 165 The MIDCOM Protocol semantics [MDCSEM] defines two basic transaction 166 types: request transactions and notify transactions. SNMPv3 uses the 167 architecture detailed in [RFC3411], where all SNMP entities are 168 capable of performing certain functions, such as the generation of 169 requests, response to requests, the generation of asynchronous 170 notifications, the receipt of notifications, and the proxy-forwarding 171 of SNMP messages. SNMP is used to read and manipulate a virtual 172 database (the MIB) which is composed of objects representing 173 commands, controls, status, and statistics, which are defined in 174 managed-application-specific MIB modules. 176 3. SNMP and the MIDCOM data model 178 This section provides a high level description and levels of 179 abstraction of the categories of data required to satisfy the MIDCOM 180 requirements and semantics as it relates to existing SNMP MIB 181 modules. 183 Application-specific MIB modules can be defined at varying levels of 184 abstraction. At the lowest level, vendor-specific, device-specific 185 parameters may be defined, for instance, to configure a specific 186 model of firewall. At a higher level, a MIB module may define an 187 abstracted view of firewall functionality that can be used to specify 188 a firewall policy, which an implementation can translate into the 189 necessary parameters to configure the specific model of firewall on 190 which the abstract MIB is implemented. At a higher level yet, a MIB 191 module may define service policies or business policies that end up 192 being translated into more detailed instructions, possibly into the 193 more detailed MIB module data schemas. It is common practice to have 194 one MIB module point to other MIB modules that contain less/more 195 concrete conceptual representations. 197 SNMP for the MIDCOM protocol can leverage the data schemas of many 198 existing MIB modules designed to permit secure communications, 199 configuration of devices, configuration of services and policy 200 coordination abstractions. The actual specification of the policies 201 is outside the scope of the MIDCOM protocol. 203 Many existing MIB modules provide monitoring capabilities that can be 204 applied to MIDCOM functionality. 206 The following diagram (Figure 1) summarizes the potential relevance 207 and reusability of the data schema of existing MIB models to the 208 MIDCOM architecture to satisfy the MIDCOM protocol framework, 209 requirements and semantics: 211 +----------------------+ 212 | Application | 213 | | 214 | +---------------+ | 215 | | MIDCOM agent | | 216 | | | | 217 | | | | 218 | +---------------+ | +------------+ 219 +------------^---------+ | | 220 . | Policy | 221 . | | 222 . | +--------+ | 223 Application . | | MIDCOM | | 224 Requests . /+-| PDP | | 225 (via SNMP) . / | +--------+ | 226 . / +------------+ 227 . / 228 . / 229 . / 230 . | 231 v v 232 +-------------------------------------------+ 233 | Middlebox * * | 234 | * a. * b. | 235 | v v | 236 | +-------------------------------+ | 237 | | Middlebox Communication | | 238 | | Protocol (MIDCOM) Interface | | 239 | +-------------------------------+ | 240 | * | 241 | * c. | 242 | v | 243 | +-------------------------------+ | 244 | | Dynamic Device/Service | | 245 | | Configuration | | 246 | +-------------------------------+ | 247 | | 248 +-------------------------------------------+ 250 Legend: .... Middlebox Communication Protocol (MIDCOM) 251 //// MIDCOM PDP Interface (outside scope of this 252 document) 253 **** Managed objects relevant to the MIDCOM Interface 254 (with the associated letters referencing the 255 MIB modules potentially applicable summarized 256 below: 258 a. gaps between existing MIB modules (b and c) and 259 MIDCOM requirements 260 b. POLICY-BASED-MANAGEMENT-MIB, DIFFSERV-CONFIG-MIB, 261 c. IPSEC-POLICY-MIB, NAT-MIB, DIFFSERV-MIB 263 Figure 1: Data relationships relevant to the MIDCOM Interface 265 3.1 Secure Communications 267 MIDCOM requirements include mutual authentication, message integrity 268 checking, timeliness checking to prevent replay, message encryption, 269 and authorization controls to ensure only certain agents can modify 270 certain subsets of middlebox configurations. MIDCOM requires secure 271 request-response capabilities and secure notifications. 273 SNMPv3 is designed to provide secure communications between two end- 274 points. SNMPv3 defines MIB modules to allow the monitoring and 275 configuration of all these security features. They are defined in 276 RFC3411-RFC3418, and RFC3410 provides an overview of these 277 capabilities. 279 3.2 Device Configuration 281 SNMP is the most commonly used standardized protocol for remotely 282 monitoring and manipulating the configuration of devices. There are a 283 large number of IETF standard and vendor-specific MIB modules 284 available. 286 Most IETF standard MIB modules do not provide much configuration 287 support because SNMPv1 and SNMPv2c were non-secure, and it is 288 difficult to standardize abstractions that provide enough information 289 to configure device implementations that require vendor-specific 290 parameters. There are many vendor-specific MIB modules that permit 291 configuration of the vendor's devices. 293 SNMP MIB modules are definitions of virtual databases with scalars 294 and tables of data. SNMP supports multiple mechanisms to define 295 relationships between entries in different tables. For example, 296 entries in multiple tables are often related by common indices. SNMP 297 uses a standardized hierarchical namespace, so the value of a field 298 in one table can serve as the index into another table. 300 The ability to define relationships between MIB module tables 301 (including tables in different MIB modules) allows an abstracted 302 configuration policy to point to a vendor-specific configuration MIB 303 module for more detailed instructions. 305 There are multiple ways to send policies to middleboxes, including 306 SNMP and COPS/PR and RADIUS/Diameter, and most policies are auto- 307 magically converted into low-level configuration commands that set 308 the correct operational parameters to enforce desired behavior. 310 Some middlebox functionalities are related to physical and logical 311 topologies that are created by dynamically manipulating device 312 configurations. Some MIB modules that can be used for topology 313 configuration would include the 802.1X MIB [81XMIB] and the 314 Interfaces MIB [RFC2863] to enable or disable a physical port or 315 logical interface, the Bridge MIB [BREMIB]to assign interfaces into 316 virtual LANs and to enable port mirroring functionality for IDS 317 usage, the Layer Two Tunneling MIB or IPSec MIB to create topology 318 tunnels for VPNs, and so on. 320 There are many IETF standard MIB modules that monitor traffic, which 321 can be used to verify that a policy is being enforced. Most 322 "transmission" MIB modules, those that fall under the { MIB-2 323 transmission } subtree relative to Interfaces MIB entries, provide 324 statistics about traffic going in or out of ports on a device. The 325 Bridge MIB can be used to monitor the amount of traffic being 326 forwarded into or out of virtual LANs, and so on. 328 3.3 Service Configuration 330 A middlebox may be able to support multiple types of services, and a 331 MIDCOM agent must determine which services are available and running, 332 and which have stopped running. Middlebox functionalities are 333 applications that run on a middlebox, and there are multiple MIB 334 modules designed to monitor applications and their operational 335 characteristics. Most of the MIB modules described here are for 336 monitoring only, but could be extended with application-specific MIB 337 modules for configuration and additional monitoring. 339 The Host Resources MIB [RFC2790] provides monitoring of hardware 340 resources, such as memory and CPU load, and monitors installed 341 applications, running applications, and application performance. 342 These can be used to do capability discovery for a middlebox, and 343 these factors can be important to consider before configuring 344 additional functionality or sessions on a middlebox. 346 The Network Services Monitoring MIB [RFC2788] module provides objects 347 for monitoring high-level concepts related to network services, such 348 as their current run status and their associations. This MIB works 349 with supplemental service-specific MIB modules, including 350 configuration objects. 352 The Systems Application MIB [RFC2287] monitors installed 353 applications, running applications, and running processes. The 354 installed application information can be important for determining 355 the actual capabilities of the model and version of firewall 356 installed. 358 However, MIDCOM is primarily about dynamically configuring middlebox 359 functionality, so MIB modules associated with configuration, 360 specifically any associated with the configuration of firewalls and 361 NATS, are the main focus. 363 The Diffserv MIB [RFC3289] describes the configuration and management 364 of a Differentiated Services interface in terms of one or more 365 Traffic Conditioning Blocks (TCB), each containing, arranged in the 366 specified order, by definition, zero or more classifiers, meters, 367 actions, algorithmic droppers, queues and schedulers. The "linked- 368 list" approach is very flexible, and could be used to configure some 369 firewall tasks. 371 The IPSec Policy MIB [IPCMIB] defines objects that could be reused 372 for purposes of filtering service-related traffic and subsequent 373 policy actions. 375 3.4 Policy Coordination 377 To properly coordinate policy application, it is necessary to 378 determine if a device has the capabilities needed to effectively 379 enforce a policy, and to coordinate the application of policies 380 according to time constraints, priorities, rule groupings, policy 381 sessions, and so on. 383 The SNMPCONF working has developed a number of MIB modules designed 384 for the purpose of policy coordination. 386 Many policies are dependent on factors that are not so much traffic- 387 related as business related. For example, the role that a device 388 serves in the network or the geographic location of a device may 389 impact a policy. The SNMPCONF Policy MIB [PBMMIB] allows an 390 administrator to define roles, and associate them with policies. 392 The SNMPCONF MIB modules include a policy download table, a policy 393 registration table, and a scheduling function for defining when a 394 policy should be made active and when it should be made dormant. Time 395 schedules can be grouped for easier manipulation, and wildcards are 396 supported. To ease integration with other policy efforts, the 397 schedule table is modeled after the Policy Core Information Model 398 scheduler. 400 SNMPCONF provides a capabilities table to advertise the functionality 401 available for policy enforcement, including configuration parameters 402 to enable a MIDCOM agent to be notified when new capabilities are 403 installed on a system. Capabilities may be available on some 404 components of a system and not others, such as a board in a chassis, 405 but also may be accessible only in certain logical partitions, such 406 as the community profile (more accurately, the SNMPv3 context) of the 407 super-user. 409 SNMPCONF defines tracking tables, so an administrator can determine 410 which elements are being controlled by which policies. The MIB also 411 includes debugging tables for logging policy enforcement run-time 412 exceptions. An administrator can disable policies in place, if they 413 desire. 415 4. Applicability of existing MIB modules 417 This section summarizes the details of the applicability of existing 418 MIB modules to the MIDCOM data model. As highlighted in Figure 1, 419 the MIDCOM protocol itself is only defined to be the interface from 420 the MIDCOM agent (SNMP manager) to the middlebox or MIDCOM Interface. 421 However, requests from the MIDCOM agent to the MIDCOM Interface must 422 be evaluated against the installed policies and must contain all the 423 data required for the specific device/service configuration. In 424 addition, the session setup reply includes capabilities of the 425 middlebox, several of which relate to policies. Thus, although the 426 Policy interface itself is out of scope of the MIDCOM protocol, the 427 correlation of the policy related data in the form of rules to the 428 data associated with the MIDCOM Interface is imperative. In effect, 429 an instance of the "MIDCOM MIB" comprises the data from the semantics 430 evaluated against the policy and applied to configure the 431 device/service. 433 Several of the MIB modules discussed in section 3 were analyzed and 434 and the following were found to have general applicability and 435 varying levels of re-usability for MIDCOM: 436 . Network Address Translators (NAT) MIB [NATMIB] 437 . Policy Based Management MIB [PBMMIB] 438 . IPsec Policy Configuration MIB [IPCMIB] 439 . Differentiated Services MIB [RFC3289] 441 4.1 Network Address Translators (NAT) MIB 443 The NAT MIB module [NATMIB] is intended to be used for configuration 444 as well as monitoring of a device capable of traditional NAT 445 functions. The NAT MIB module appears to meet all of the MIDCOM 446 requirements concerning NAT control. Additional MIB modules, such as 447 those defined by SNMP Policy Based Management MIB (as described in 448 section 4.2), allowing the definition of policy rulesets and grouping 449 of policy rules also required. 451 4.2 Policy Based Management MIB 453 This MIB defines managed objects that enable policy-based monitoring 454 and management of SNMP infrastructure. The Policy Based Management 455 MIB defines MIB objects for the following areas: roles, capabilities 456 and time. 458 [Editor's note: Although the policy interface itself to the middlebox 459 is out of scope for the MIDCOM protocol, the rules associated with 460 the MIB module(s) for MIDCOM are in scope and thus it is anticipated 461 that there is some reusability of the mangaged objects defined by the 462 PBMMIB, rather than of the entire application of this MIB itself. 463 This section will be expanded once more detailed analysis has been 464 completed]. 466 4.3 IPsec Policy Configuration MIB 468 The IPSEC-POLICY-MIB is a large MIB designed to support IPsec and IKE 469 management in a policy and rule oriented fashion. The MIB module is 470 divided into 3 portions, only one of which would be useful for reuse 471 with the MIDCOM MIB. Specifically, the IPSEC-POLICY-MIB provides a 472 generic mechanism for performing packet processing based on a rule 473 set. Rules within the IPSEC-POLICY-MIB are generic and simply bind a 474 filter to an action. Filters provided within the IPSEC-POLICY-MIB 475 itself are numerous and fairly complete for most common packet 476 filtering usage but externally defined filters (like those that may 477 need to be developed within a MIDCOM specific MIB module) are 478 supported. The actions encapsulated within the IPSEC-POLICY-MIB are 479 mostly related to IKE and IPsec and thus aren't very useful as 480 applied to MIDCOM. However, actions (like filters) can be externally 481 defined. Compound filter and action sequences can be defined for 482 administrators that need more complex boolean logic or need to chain 483 multiple actions together based on success/failure states. The 484 compound mechanisms are also generic and would let MIDCOM specific 485 MIB elements to be used within the compound bindings if necessary. 487 [Editor's note: this is an initial analysis; a more detailed analysis 488 to be included once the details are completed]. 490 4.4 Differentiated Services MIB 492 The Diffserv MIB is a very powerful and flexible MIB module, however, 493 this flexibility is too broad in general for the MIDCOM protocol 494 requirements. In addition, the requirement for NAT support, and 495 specifically policy rule lifetimes in the MIDCOM protocol, further 496 highlight that the Diffserv MIB alone is unsuitable as the MIDCOM MIB 497 Module. 499 However, the Diffserv model of using different tables for data path 500 elements could be applied to the MIDCOM MIB module. The use of 501 RowPointers as connectors in the Diffserv MIB allows for the simple 502 extension of the MIB. The RowPointers, whether "next" or "specific", 503 may point to Entries defined in other MIB modules. This mechanism can 504 point to other, possibly vendor-specific, configuration MIB modules. 505 In addition, the reuse of some specific definitions out of the 506 DIFFSERV MIB module is worth further consideration for the MIDCOM MIB 507 module, (e.g. the diffServMultiFieldClfrTable). 509 [Editor's note: Once we start needing to fill in the gaps as 510 highlighted in item a of the diagram in Figure 1, this will be 511 revisited]. 513 4.5 Summary of applicability of existing MIB modules 515 < To Be Completed > 517 520 5. Additional MIDCOM specific managed objects 521 525 < To Be Completed > 527 6. Security Considerations 529 The MIDCOM requirements [RFC3304] defines the general security 530 requirements for the MIDCOM protocol. The SNMPv3 User-based Security 531 Model (USM, [RFC2574]) satisfies those requirements. USM defines 532 three standardized methods for providing authentication, 533 confidentiality, and integrity. The method to use can be optionally 534 chosen. The methods operate securely across untrusted domains. 535 Additionally, USM has specific built-in mechanisms for preventing 536 replay attacks including unique protocol engine IDs, timers and 537 counters per engine and time windows for the validity of messages. 539 7. Changes since last version 541 The following summarizes the major changes made to this document from 542 the previous version (draft-barnes-midcom-mib-00): 543 . Miscellaneous editorial changes include basic formatting and 544 changing references of mib to MIB, and mibs to MIB modules. 545 . Removed reference to SNMP proxy functionality as that's not 546 applicable to MIDCOM. 547 . Updated references to include additional informational 548 references for Diffserv and updated versions on some drafts. 549 . Incorporated "Protocol" into the title of the document. 550 . In general, attempted to clarify references to policy to be 551 specific to the rulesets as they apply to a session. 552 . Some minor re-arranging of text in section 2 to try to improve 553 the readability of the document. 554 . Clarified that the configuration relevant to MIDCOM is primarily 555 dynamic. 556 . Removed some of the non-relevant text in sections 3 (eg. 557 References to CLI in the configuration section and some details 558 in the Policy Coordination Section). Totally removed the Policy 559 Specification section since it is out of scope. 561 Normative References 563 [RFC3304] R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 564 Communications (MIDCOM) Protocol Requirements", RFC 3304, August, 565 2002. 567 [RFC3303] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. 568 Rayhan, "Middlebox Communications Architecture and Framework", RFC 569 3303, August, 2002. 571 [MDCSEM] Stiemerling, M., Quittek, J., Taylor, T., "MIDCOM Protocol 572 Semantics", draft-ietf-midcom-semantics-02.txt, May, 2003. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", RFC 2119, March 1997. 577 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 578 Rose, M., and S. Waldbusser, "Structure of Management Information 579 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 581 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 582 Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 583 RFC 2579, April 1999. 585 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 586 Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 587 58, RFC 2580, April 1999. 589 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 590 Architecture for Describing SNMP Management Frameworks", STD 62, RFC 591 3411, November 2002. 593 [RFC3412] Case, J., Harrington D., Presuhn R., and B. Wijnen, 594 "Message Processing and Dispatching for the Simple Network Management 595 Protocol (SNMP)", STD 62, RFC 3412, November 2002. 597 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 598 STD 62, RFC 3413, November 2002. 600 [RFC3414] Blumenthal, U., and B. Wijnen, "User-based Security 601 Model(USM) for version 3 of the Simple Network Management Protocol 602 (SNMPv3)", STD 62, RFC 3414, November 2002. 604 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 605 Access Control Model (VACM) for the Simple Network Management 606 Protocol (SNMP)", STD 62, RFC 3415, November 2002. 608 [NATMIB] Raghunarayan, R., Pai, N., Rohit, R., Wang, C., Srisuresh, 609 P., "Definitions of Managed Objects for Network Address Translators 610 (NAT)", draft-ietf-nat-natmib-05.txt, November, 2002. 612 [PBMMIB] Waldbusser, S., Saperia, J., Hongal, T., "Policy Based 613 Management MIB", draft-ietf-snmpconf-pm-13.txt, March, 2003. 615 [IPCMIB] Baer, M., Charlet, R., Hardaker, W., Story, R., Wang, C., 616 "IPsec Policy Configuration MIB module", draft-ietf-ipsp-ipsec-conf- 617 MIB-06.txt, March, 2003. 619 Informative References 621 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 622 "Introduction to Version 3 of the Internet-standard Network 623 Management Framework", 3410, November 2002. 625 [MDCPEV] Barnes, M., "Middlebox Communications (MIDCOM) Protocol 626 Evaluation", draft-ietf-midcom-protocol-eval-06.txt, November, 2002. 628 [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level 629 Managed Objects for Applications", RFC 2287, February 1998. 631 [RFC 2475] Blake, S., et al, "An Architecture for Differentiated 632 Service", RFC 2475, December 1998. 634 [RFC2564] C. Kalbfleisch, C. Krupczak, R.Presuhn, J. Saperia, 635 "Application Management MIB", May 1999. 637 [RFC2594] H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder, 638 "Definitions of Managed Objects for WWW Services", May 1999. 640 [RFC2788] N. Freed, S. Kille, "Network Services Monitoring MIB", RFC 641 2788, March 2000. 643 [RFC2790] S. Waldbusser, P. Grillo, "Host Resources MIB", March 2000. 645 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB 646 using SMIv2", RFC 2863, June 2000. 648 [RFC3289] Baker, F., Chan, K., Smith, A., "Management Information 649 Base for the Differentiated Services Architecture", RFC 3289, May 650 2002. 652 [RFC3290] Bernet, Y., et al, "An Informal Management Model for 653 Differentiated Services Routers", RFC 3290, May 2002. 655 [DPCMIB] Hazewinkel, H, Partain, D., "The Differentiated Services 656 Configuration MIB", draft-ietf-snmpconf-diffpolicy-05.txt, June 2002. 658 [BRGMIB] Norseth, K.C. and Bell, E., "Definitions of Managed Objects 659 for Bridges", draft-ietf-bridge-bridgeMIB-smiv2-04.txt, October 2002. 661 [BREMIB] Ngai, V., "Definitions of Managed Objects for Bridges with 662 Traffic Classes, Multicast Filtering and Virtual LAN Extensions", 663 draft-ietf-bridge-ext-v2-01.txt, September 2002. 665 [81xMIB] Norseth, K.C. "Definitions for Port Access Control (IEEE 666 802.1X) MIB", draft-ietf-bridge-8021x-01.txt, February, 2003. 668 Acknowledgements 670 The authors would like to thank Randy Presuhn and Pyda Srisuresh for 671 their comments and feedback on the initial version of this document. 673 Authors' Address 675 Mary Barnes 676 Nortel Networks 677 2380 Performance Drive 678 Richardson, TX 75082 679 USA 681 Phone: 1-972-684-5432 682 Email: mbarnes@nortelnetworks.com 684 Wes Hardaker 685 686 USA 688 Phone: 689 EMail: hardaker@tislabs.com 691 David Harrington, Co-chair SNMPv3 WG 692 Enterasys Networks 693 35 Industrial Way 694 Rochester, NH 03867-5005 695 USA 697 Phone: +1 603-337-2614 698 EMail: dbh@enterasys.com 700 Martin Stiemerling 701 NEC Europe Ltd. 702 Network Laboratories 703 Adenauerplatz 6 704 69115 Heidelberg 705 Germany 706 Phone: +49 6221 90511-13 707 Email: stiemerling@ccrle.nec.de 709 Full Copyright Statement 711 Copyright (C) The Internet Society (2003). All Rights Reserved. 713 This document and translations of it may be copied and furnished to 714 others, and derivative works that comment on or otherwise explain it 715 or assist in its implementation may be prepared, copied, published 716 and distributed, in whole or in part, without restriction of any 717 kind, provided that the above copyright notice and this paragraph 718 are included on all such copies and derivative works. However, this 719 document itself may not be modified in any way, such as by removing 720 the copyright notice or references to the Internet Society or other 721 Internet organizations, except as needed for the purpose of 722 developing Internet standards in which case the procedures for 723 copyrights defined in the Internet Standards process must be 724 followed, or as required to translate it into languages other than 725 English. The limited permissions granted above are perpetual and 726 will not be revoked by the Internet Society or its successors or 727 assigns. This document and the information contained 728 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 729 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 730 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 731 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 732 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 733 PARTICULAR PURPOSE.