idnits 2.17.1 draft-ietf-midcom-mib-analysis-01.txt: -(635): 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 8 instances of lines with non-ascii characters in the document. 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 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([MDCMIB]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 2003) is 7492 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '81XMIB' is mentioned on line 315, but not defined == Missing Reference: 'RFC2574' is mentioned on line 604, but not defined ** Obsolete undefined reference: RFC 2574 (Obsoleted by RFC 3414) == Unused Reference: 'RFC3412' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC3413' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'RFC3414' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC3415' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'MDCPEV' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'RFC 2475' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC2564' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'RFC2594' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'RFC3290' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'DPCMIB' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'BRGMIB' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'BREMIB' is defined on line 763, but no explicit reference was found in the text == Unused Reference: '81xMIB' is defined on line 767, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-midcom-semantics-05 == Outdated reference: A later version (-09) exists of draft-ietf-nat-natmib-06 == 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? == 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: 5 errors (**), 0 flaws (~~), 23 warnings (==), 4 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-mib-analysis-01.txt Nortel Networks 3 Editor 5 Category: Informational 6 Expires: April 2004 October 2003 8 Middlebox Communications (MIDCOM) Protocol Managed Objects Analysis 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This document provides an analysis and identification of the managed 37 objects for dynamic configuration of middleboxes. The scope of the 38 middleboxes to which these managed objects apply is limited to NATs 39 and Firewalls. However, the managed objects as identified in this 40 document are intended to provide a baseline for the dynamic 41 configuration of other types of middleboxes. The applicability of 42 existing Management Information Base (MIB) modules to the MIDCOM 43 requirements, framework and semantics is described. Additional 44 managed objects are identified to satisfy the entirety of the MIDCOM 45 requirements, framework and semantics and to provide a complete 46 MIDCOM MIB for NATs and Firewalls to fully realize the requirements 47 of the MIDCOM protocol. The actual definition of any new managed 48 objects is provided in a separate document [MDCMIB]. 50 Table of Contents 52 1. SNMP Management Framework......................................3 53 2. MIDCOM Overview and SNMP Applicability.........................3 54 3. SNMP and the MIDCOM data model.................................4 55 3.1 Secure Communications......................................6 56 3.2 Device Configuration.......................................6 57 3.3 Service Configuration......................................7 58 3.4 Policy Coordination........................................8 59 4. Applicability of existing MIB modules..........................9 60 4.1 Network Address Translators (NAT) MIB.....................10 61 4.2 Policy Based Management MIB...............................11 62 4.3 IPsec Policy Configuration MIB............................11 63 4.4 Differentiated Services MIB...............................12 64 5. Additional MIDCOM specific managed objects....................12 65 6. Security Considerations.......................................13 66 7. Changes since last version....................................14 67 Normative References.............................................15 68 Informative References...........................................16 69 Appendix A � Analysis of the NATMIB against the MIDCOM semantics.18 70 Full Copyright Statement.........................................25 72 Overview 74 This intent of this document is to provide a detailed analysis of the 75 managed objects for dynamic configuration of middleboxes. The scope 76 of the middleboxes to which these managed objects are specifically 77 applied is limited to NATs and Firewalls. However, the resultant MIB 78 should be extensible and provide the basis for the development of 79 managed objects for 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 identifies 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. The actual 98 definition of the MIB module for new MIDCOM specific managed objects 99 is provided in a separate document [MDCMIB]. 101 Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 1. SNMP Management Framework 109 For a detailed overview of the documents that describe the current 110 Internet-Standard (SNMP) Management Framework, please refer to 111 section 7 of RFC 3410 [RFC3410]. 113 Managed objects are accessed via a virtual information store, termed 114 the Management Information Base or MIB. MIB objects are generally 115 accessed through the Simple Network Management Protocol (SNMP). 116 Objects in the MIB are defined using the mechanisms defined in the 117 Structure of Management Information (SMI). This memo specifies a MIB 118 module that is compliant to the SMIv2, which is described in STD 58, 119 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 120 2580[RFC2580]. 122 2. MIDCOM Overview and SNMP Applicability 124 The MIDCOM architecture and framework [RFC3303] defines a model in 125 which trusted third parties can be delegated to assist middleboxes in 126 performing their operations, without requiring application 127 intelligence be embedded in the middleboxes. This trusted third party 128 is referred to as the MIDCOM Agent. The MIDCOM protocol is defined 129 between the MIDCOM agent and middlebox. 131 The SNMP management framework provides functions equivalent to those 132 defined by the MIDCOM framework, although there are a few 133 architectural differences. 135 For SNMP, application intelligence is captured in MIB modules, rather 136 than in the messaging protocol. MIB modules define a data model of 137 the information that can be collected and configured for managed 138 functionality. The SNMP messaging protocol transports the data in a 139 standardized format without needing to understand the semantics of 140 the data being transferred. The endpoints of the communication 141 understand the semantics of the data. 143 Traditionally, the SNMP endpoints have been called Manager and Agent. 144 An SNMP manager is an entity capable of generating requests and 145 receiving notifications, and a SNMP agent is an entity capable of 146 responding to requests and generating notifications. As applied to 147 the MIDCOM framework, the SNMP Manager corresponds to the MIDCOM 148 agent and the SNMP Agent corresponds to the Middlebox. 150 The MIDCOM protocol is divided into three phases, per section 4 of 151 [RFC3303]: 152 . Session Setup 153 . Run-time (involving real-time configuration of the middlebox) 154 . Session Termination 155 A MIDCOM session is defined to be a lasting association between a 156 MIDCOM agent and a middlebox. The MIDCOM agent should initiate the 157 session prior to the start of the application. Although the SNMP 158 management framework does not have the concept of a session, session- 159 like associations can be established through the use of managed 160 objects. Requests from the MIDCOM agent to the Middlebox are 161 performed using write access to managed objects defined in MIB 162 modules. The middlebox (SNMP agent) responds to requests by sending 163 an SNMP response message indicating the success or failure of the 164 request. The MIDCOM agent (SNMP manager) MAY verify this information 165 by reading or polling the corresponding managed objects. 167 The MIDCOM Protocol semantics [MDCSEM] defines two basic transaction 168 types: request transactions and notify transactions. SNMPv3 uses the 169 architecture detailed in [RFC3411], where all SNMP entities are 170 capable of performing certain functions, such as the generation of 171 requests, response to requests, the generation of asynchronous 172 notifications, the receipt of notifications, and the proxy-forwarding 173 of SNMP messages. SNMP is used to read and manipulate a virtual 174 database (the MIB) composed of objects representing commands, 175 controls, status, and statistics, which are defined in managed- 176 application-specific MIB modules. 178 3. SNMP and the MIDCOM data model 180 This section provides a high level description and levels of 181 abstraction of the categories of data required to satisfy the MIDCOM 182 requirements and semantics as it relates to existing SNMP MIB 183 modules. 185 Application-specific MIB modules can be defined at varying levels of 186 abstraction. At the lowest level, vendor-specific, device-specific 187 parameters may be defined, for instance, to configure a specific 188 model of firewall. At a higher level, a MIB module may define an 189 abstracted view of firewall functionality that can be used to specify 190 a firewall policy, which an implementation can translate into the 191 necessary parameters to configure the specific model of firewall on 192 which the abstract MIB is implemented. At a higher level yet, a MIB 193 module may define service policies or business policies that end up 194 being translated into more detailed instructions, possibly into the 195 more detailed MIB module data schemas. It is common practice to have 196 one MIB module point to other MIB modules that contain less/more 197 concrete conceptual representations. 199 SNMP for the MIDCOM protocol can leverage the data schemas of many 200 existing MIB modules designed to permit secure communications, 201 configuration of devices, configuration of services and policy 202 coordination abstractions. The actual specification of the policies 203 is outside the scope of the MIDCOM protocol. 205 Many existing MIB modules provide monitoring capabilities that can be 206 applied to MIDCOM functionality. 208 The following diagram (Figure 1) summarizes the potential relevance 209 and reusability of the data schema of existing MIB models to the 210 MIDCOM architecture to satisfy the MIDCOM protocol framework, 211 requirements and semantics: 213 +----------------------+ 214 | Application | 215 | | 216 | +---------------+ | 217 | | MIDCOM agent | | 218 | | | | 219 | | | | 220 | +---------------+ | +------------+ 221 +------------^---------+ | | 222 . | Policy | 223 . | | 224 . | +--------+ | 225 Application . | | MIDCOM | | 226 Requests . /+-| PDP | | 227 (via SNMP) . / | +--------+ | 228 . / +------------+ 229 . / 230 . / 231 . / 232 . | 233 v v 234 +-------------------------------------------+ 235 | Middlebox * * | 236 | * a. * b. | 237 | v v | 238 | +-------------------------------+ | 239 | | Middlebox Communication | | 240 | | Protocol (MIDCOM) Interface | | 241 | +-------------------------------+ | 242 | * | 243 | * c. | 244 | v | 245 | +-------------------------------+ | 246 | | Dynamic Device/Service | | 247 | | Configuration | | 248 | +-------------------------------+ | 249 | | 250 +-------------------------------------------+ 252 Legend: .... Middlebox Communication Protocol (MIDCOM) 253 //// MIDCOM PDP Interface (outside scope of this 254 document) 255 **** Managed objects relevant to the MIDCOM Interface 256 (with the associated letters referencing the 257 MIB modules potentially applicable summarized 258 below: 260 a. gaps between existing MIB modules (b and c) and 261 MIDCOM requirements 262 b. POLICY-BASED-MANAGEMENT-MIB, DIFFSERV-CONFIG-MIB, 263 c. IPSEC-POLICY-MIB, NAT-MIB, DIFFSERV-MIB 265 Figure 1: Data relationships relevant to the MIDCOM Interface 267 3.1 Secure Communications 269 MIDCOM requirements include mutual authentication, message integrity 270 checking, timeliness checking to prevent replay, message encryption, 271 and authorization controls to ensure only certain agents can modify 272 certain subsets of middlebox configurations. MIDCOM requires secure 273 request-response capabilities and secure notifications. 275 SNMPv3 is designed to provide secure communications between two end- 276 points. SNMPv3 defines MIB modules to allow the monitoring and 277 configuration of all these security features. They are defined in 278 RFC3411-RFC3418, and RFC3410 provides an overview of these 279 capabilities. 281 3.2 Device Configuration 283 SNMP is the most commonly used standardized protocol for remotely 284 monitoring and manipulating the configuration of devices. There are a 285 large number of IETF standard and vendor-specific MIB modules 286 available. 288 Most IETF standard MIB modules do not provide much configuration 289 support because SNMPv1 and SNMPv2c were non-secure, and it is 290 difficult to standardize abstractions that provide enough information 291 to configure device implementations that require vendor-specific 292 parameters. There are many vendor-specific MIB modules that permit 293 configuration of the vendor's devices. 295 SNMP MIB modules are definitions of virtual databases with scalars 296 and tables of data. SNMP supports multiple mechanisms to define 297 relationships between entries in different tables. For example, 298 entries in multiple tables are often related by common indices. SNMP 299 uses a standardized hierarchical namespace, so the value of a field 300 in one table can serve as the index into another table. 302 The ability to define relationships between MIB module tables 303 (including tables in different MIB modules) allows an abstracted 304 configuration policy to point to a vendor-specific configuration MIB 305 module for more detailed instructions. 307 There are multiple ways to send policies to middleboxes, including 308 SNMP and COPS/PR and RADIUS/Diameter, and most policies are auto- 309 magically converted into low-level configuration commands that set 310 the correct operational parameters to enforce desired behavior. 312 Some middlebox functionalities are related to physical and logical 313 topologies that are created by dynamically manipulating device 314 configurations. Some MIB modules that can be used for topology 315 configuration would include the 802.1X MIB [81XMIB] and the 316 Interfaces MIB [RFC2863] to enable or disable a physical port or 317 logical interface, the Bridge MIB [BREMIB]to assign interfaces into 318 virtual LANs and to enable port mirroring functionality for IDS 319 usage, the Layer Two Tunneling MIB or IPSec MIB to create topology 320 tunnels for VPNs, and so on. 322 There are many IETF standard MIB modules that monitor traffic, which 323 can be used to verify that a policy is being enforced. Most 324 "transmission" MIB modules, those that fall under the { MIB-2 325 transmission } subtree relative to Interfaces MIB entries, provide 326 statistics about traffic going in or out of ports on a device. The 327 Bridge MIB can be used to monitor the amount of traffic being 328 forwarded into or out of virtual LANs, and so on. 330 3.3 Service Configuration 331 A middlebox may be able to support multiple types of services, and a 332 MIDCOM agent must determine which services are available and running, 333 and which have stopped running. Middlebox functionalities are 334 applications that run on a middlebox, and there are multiple MIB 335 modules designed to monitor applications and their operational 336 characteristics. Most of the MIB modules described here are for 337 monitoring only, but could be extended with application-specific MIB 338 modules for configuration and additional monitoring. 340 The Host Resources MIB [RFC2790] provides monitoring of hardware 341 resources, such as memory and CPU load, and monitors installed 342 applications, running applications, and application performance. 343 These can be used to do capability discovery for a middlebox, and 344 these factors can be important to consider before configuring 345 additional functionality or sessions on a middlebox. 347 The Network Services Monitoring MIB [RFC2788] module provides objects 348 for monitoring high-level concepts related to network services, such 349 as their current run status and their associations. This MIB works 350 with supplemental service-specific MIB modules, including 351 configuration objects. 353 The Systems Application MIB [RFC2287] monitors installed 354 applications, running applications, and running processes. The 355 installed application information can be important for determining 356 the actual capabilities of the model and version of firewall 357 installed. 359 However, MIDCOM is primarily about dynamically configuring middlebox 360 functionality, so MIB modules associated with configuration, 361 specifically any associated with the configuration of firewalls and 362 NATS, are the main focus. 364 The Diffserv MIB [RFC3289] describes the configuration and management 365 of a Differentiated Services interface in terms of one or more 366 Traffic Conditioning Blocks (TCB), each containing, arranged in the 367 specified order, by definition, zero or more classifiers, meters, 368 actions, algorithmic droppers, queues and schedulers. The "linked- 369 list" approach is very flexible, and could be used to configure some 370 firewall tasks. 372 The IPSec Policy MIB [IPCMIB] defines objects that could be reused 373 for purposes of filtering service-related traffic and subsequent 374 policy actions. 376 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. Although, the NAT MIB module appears to meet all of the 446 MIDCOM requirements concerning NAT control, a detailed evaluation 447 against the semantics highlights some areas requiring resolution. 449 The primary concerns arise from some fundamental views on the MIDCOM 450 MIB and its relation to the NAT (and FW) MIB(s), whether the 451 relationship is explicit or implicit, and whether the MIDCOM Agent 452 has a direct interface to the NAT (or FW) MIB(s). 454 Taking the perspective that the MIDCOM MIB has an explicit 455 relationship with the NAT MIB and that the MIDCOM Agent has a direct 456 interface to the NAT and FW MIBs results in the following position: 457 . PRRs have a direct relationship to NAT Binds. 458 . PERs have a direct relationship to NAT sessions and FW rules. 459 . Agent specific Group membership IDs should be assignable by 460 agents. 462 Taking the opposite perspective that the relationship between the 463 MIDCOM MIB and the NAT MIB is implicit and that the MIDCOM agent does 464 not have a direct interface to the NAT MIB and that its interface is 465 abstracted by the MIDCOM MIB results in the following position: 467 . PRR is an abstract entity, related to binds and address maps. 468 . PER is an abstract entity whose relationship goes beyond the 469 NAT session. 470 . Middlebox should assign and manage Group IDs for the agent. 472 Appendix A was put forth to provide a detailed analysis of some of 473 the specific issues. Once these issues are resolved, the impact will 474 be summarized in this section. 476 In addition, section 5 summarizes the current MIB proposals the 477 issues requiring resolution and WG consensus. 479 Additional MIB modules, such as those defined by SNMP Policy Based 480 Management MIB (as described in section 4.2), allowing the definition 481 of policy rulesets and grouping of policy rules are also required. 483 4.2 Policy Based Management MIB 485 This MIB defines managed objects that enable policy-based monitoring 486 and management of SNMP infrastructure. The Policy Based Management 487 MIB defines MIB objects for the following areas: roles, capabilities 488 and time. 490 [Editor's note: Although the policy interface itself to the middlebox 491 is out of scope for the MIDCOM protocol, the rules associated with 492 the MIB module(s) for MIDCOM are in scope and thus it is anticipated 493 that there is some reusability of the managed objects defined by the 494 PBMMIB, rather than of the entire application of this MIB itself. 495 This section will be expanded once more detailed analysis has been 496 completed]. 498 4.3 IPsec Policy Configuration MIB 500 The IPSEC-POLICY-MIB is a large MIB designed to support IPsec and IKE 501 management in a policy and rule oriented fashion. The MIB module is 502 divided into 3 portions, only one of which would be useful for reuse 503 with the MIDCOM MIB. Specifically, the IPSEC-POLICY-MIB provides a 504 generic mechanism for performing packet processing based on a rule 505 set, anticipated to provide the basis for a general FW MIB. Rules 506 within the IPSEC-POLICY-MIB are generic and simply bind a filter to 507 an action. Filters provided within the IPSEC-POLICY-MIB itself are 508 numerous and fairly complete for most common packet filtering usage 509 but externally defined filters (like those that may need to be 510 developed within a MIDCOM specific MIB module) are supported. The 511 actions encapsulated within the IPSEC-POLICY-MIB are mostly related 512 to IKE and IPsec and thus aren't very useful as applied to MIDCOM. 513 However, actions (like filters) can be externally defined. Compound 514 filter and action sequences can be defined for administrators that 515 need more complex boolean logic or need to chain multiple actions 516 together based on success/failure states. The compound mechanisms 517 are also generic and would let MIDCOM specific MIB elements to be 518 used within the compound bindings if necessary. 520 [Editor's note: this is an initial analysis; a more detailed analysis 521 to be included once the details are completed. The current proposal 522 is to separate the packet filtering aspects into a separate FW MIB. 523 However, progress on this is pending support for this proposal by the 524 WG involved. Otherwise, an independent FW MIB would need to be 525 defined.] 527 4.4 Differentiated Services MIB 529 The Diffserv MIB is a very powerful and flexible MIB module, however, 530 this flexibility is too broad in general for the MIDCOM protocol 531 requirements. In addition, the requirement for NAT support, and 532 specifically policy rule lifetimes in the MIDCOM protocol, further 533 highlight that the Diffserv MIB alone is unsuitable as the MIDCOM MIB 534 Module. 536 However, the Diffserv model of using different tables for data path 537 elements could be applied to the MIDCOM MIB module. The use of 538 RowPointers as connectors in the Diffserv MIB allows for the simple 539 extension of the MIB. The RowPointers, whether "next" or "specific", 540 may point to Entries defined in other MIB modules. This mechanism can 541 point to other, possibly vendor-specific, configuration MIB modules. 542 In addition, the reuse of some specific definitions out of the 543 DIFFSERV MIB module is worth further consideration for the MIDCOM MIB 544 module, (e.g. the diffServMultiFieldClfrTable). 546 [Editor's note: Once we start needing to fill in the gaps as 547 highlighted in item a of the diagram in Figure 1, this will be 548 revisited]. 550 4.5 Summary of applicability of existing MIB modules 552 < To Be Completed > 554 557 5. Additional MIDCOM specific managed objects 559 At this time, there have been two detailed proposals put forth by 560 members of the design team defining the MIDCOM MIB: 562 . draft-stiemerling-midcom-mib-00.txt 563 . draft-srisuresh-midcom-mib-00.txt 565 The primary differences between these two MIBs, as discussed in 566 section 4.1, arise from some fundamental views on the MIDCOM MIB and 567 its relation to the NAT and FW MIBs. 569 The following summarizes the issues currently being discussed within 570 the design team, some of which are also reflected in the detailed 571 NATMIB analysis in Appendix A and put forth for discussion on the 572 mailing list with regards to the MIDCOM semantics: 574 1. Session model versus transaction model. There's differing views 575 as to whether MIDCOM is session or transaction oriented. The 576 fundamental issue remains to determine which transactions rely 577 on a session model and how they can be realized through SNMP. 579 2. Level of abstraction of the MIDCOM MIB from the device. The 580 prevailing view seemed to be that the MIDCOM MIB could be 581 abstracted from the device, however, the flipside of that is 582 that it leaves a lot to implementation choice and thus was 583 deemed a potential pitfall. 585 3. Interfacing between MIDCOM MIB and existing NAT and FW MIBs. 586 This fundamentally relates to how much integration of MIDCOM 587 should there be with the existing NAT and FW MIBs and whether 588 there are separate MIDCOM "shims" to accomplish this. This 589 relates to the decision on the level of abstraction. 591 4. Extensions and restrictions to the MIDCOM semantics in support 592 of SNMP specifically (i.e. the semantics were written to be 593 protocol agnostic, however, the selection of SNMP as the MIDCOM 594 protocol imposes the need for some potential extensions and 595 restrictions to the semantics). 597 A single MIB [MDCMIB] document will be produced once these issues are 598 resolved. 600 6. Security Considerations 602 The MIDCOM requirements [RFC3304] defines the general security 603 requirements for the MIDCOM protocol. The SNMPv3 User-based Security 604 Model (USM, [RFC2574]) satisfies those requirements. USM defines 605 three standardized methods for providing authentication, 606 confidentiality, and integrity. The method to use can be optionally 607 chosen. The methods operate securely across untrusted domains. 608 Additionally, USM has specific built-in mechanisms for preventing 609 replay attacks including unique protocol engine IDs, timers and 610 counters per engine and time windows for the validity of messages. 612 7. Changes since last version 614 The following summarizes the major changes made from the �00 in 615 creating the �01 version of the WG document: 616 . Added Appendix A, providing a working version of a detailed 617 analysis of the NATMIB vs. the MIDCOM semantics. Updated 618 section 4.1 to reflect the analysis of the NATMIB to date. 619 . Summarized why there are 2 MIDCOM MIB proposals and the issues 620 related to the development of the MIDCOM MIB from design team 621 discussions and the WG mailing list MIDCOM semantics discussions 622 (section 5). 623 . Updated the current status of the IPSEC Policy Configuration MIB 624 as it applies to MIDCOM (section 4.3). 626 The following summarizes the major changes made from the �01 627 individual draft for the �00 WG document: 628 . Changed the focus of the document to be the identification of 629 the managed objects rather than the actual MIDCOM MIB. Any new 630 MIB modules required will be detailed in a separate document 631 upon completion of this analysis. This change does not impact 632 the majority of the content as the only content thus far has 633 been the analysis aspects. 635 The following summarizes the major changes made to the �01 version of 636 the individual document from the previous version (draft-barnes- 637 midcom-mib-00): 638 . Miscellaneous editorial changes include basic formatting and 639 changing references of mib to MIB, and mibs to MIB modules. 640 . Removed reference to SNMP proxy functionality as that's not 641 applicable to MIDCOM. 642 . Updated references to include additional informational 643 references for Diffserv and updated versions on some drafts. 644 . Incorporated "Protocol" into the title of the document. 645 . In general, attempted to clarify references to policy to be 646 specific to the rulesets as they apply to a session. 647 . Some minor re-arranging of text in section 2 to try to improve 648 the readability of the document. 649 . Clarified that the configuration relevant to MIDCOM is primarily 650 dynamic. 651 . Removed some of the non-relevant text in sections 3 (eg. 652 References to CLI in the configuration section and some details 653 in the Policy Coordination Section). Totally removed the Policy 654 Specification section since it is out of scope. 655 . Section 4: Added analysis on Diffserv MIB, IPSEC Policy Config 656 MIB and Policy Based Management MIB. 658 Normative References 660 [RFC3304] R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 661 Communications (MIDCOM) Protocol Requirements", RFC 3304, August, 662 2002. 664 [RFC3303] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. 665 Rayhan, "Middlebox Communications Architecture and Framework", RFC 666 3303, August, 2002. 668 [MDCSEM] Stiemerling, M., Quittek, J., Taylor, T., "MIDCOM Protocol 669 Semantics", draft-ietf-midcom-semantics-05.txt, October, 2003. 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", RFC 2119, March 1997. 674 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 675 Rose, M., and S. Waldbusser, "Structure of Management Information 676 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 678 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 679 Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 680 RFC 2579, April 1999. 682 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 683 Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 684 58, RFC 2580, April 1999. 686 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 687 Architecture for Describing SNMP Management Frameworks", STD 62, RFC 688 3411, November 2002. 690 [RFC3412] Case, J., Harrington D., Presuhn R., and B. Wijnen, 691 "Message Processing and Dispatching for the Simple Network Management 692 Protocol (SNMP)", STD 62, RFC 3412, November 2002. 694 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 695 STD 62, RFC 3413, November 2002. 697 [RFC3414] Blumenthal, U., and B. Wijnen, "User-based Security 698 Model(USM) for version 3 of the Simple Network Management Protocol 699 (SNMPv3)", STD 62, RFC 3414, November 2002. 701 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 702 Access Control Model (VACM) for the Simple Network Management 703 Protocol (SNMP)", STD 62, RFC 3415, November 2002. 705 [NATMIB] Raghunarayan, R., Pai, N., Rohit, R., Wang, C., Srisuresh, 706 P., "Definitions of Managed Objects for Network Address Translators 707 (NAT)", draft-ietf-nat-natmib-06.txt, September, 2003. 709 [PBMMIB] Waldbusser, S., Saperia, J., Hongal, T., "Policy Based 710 Management MIB", draft-ietf-snmpconf-pm-13.txt, March, 2003. 712 [IPCMIB] Baer, M., Charlet, R., Hardaker, W., Story, R., Wang, C., 713 "IPsec Policy Configuration MIB module", draft-ietf-ipsp-ipsec-conf- 714 MIB-06.txt, March, 2003. 716 [MDCMIB] TBD. 718 Informative References 720 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 721 "Introduction to Version 3 of the Internet-standard Network 722 Management Framework", 3410, November 2002. 724 [MDCPEV] Barnes, M., "Middlebox Communications (MIDCOM) Protocol 725 Evaluation", draft-ietf-midcom-protocol-eval-06.txt, November, 2002. 727 [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level 728 Managed Objects for Applications", RFC 2287, February 1998. 730 [RFC 2475] Blake, S., et al, "An Architecture for Differentiated 731 Service", RFC 2475, December 1998. 733 [RFC2564] C. Kalbfleisch, C. Krupczak, R.Presuhn, J. Saperia, 734 "Application Management MIB", May 1999. 736 [RFC2594] H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder, 737 "Definitions of Managed Objects for WWW Services", May 1999. 739 [RFC2663] P. Srisuresh, M. Holdrege, "IP Network Address Translator 740 (NAT) Terminology and Considerations", August 1999. 742 [RFC2788] N. Freed, S. Kille, "Network Services Monitoring MIB", RFC 743 2788, March 2000. 745 [RFC2790] S. Waldbusser, P. Grillo, "Host Resources MIB", March 2000. 747 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB 748 using SMIv2", RFC 2863, June 2000. 750 [RFC3289] Baker, F., Chan, K., Smith, A., "Management Information 751 Base for the Differentiated Services Architecture", RFC 3289, May 752 2002. 754 [RFC3290] Bernet, Y., et al, "An Informal Management Model for 755 Differentiated Services Routers", RFC 3290, May 2002. 757 [DPCMIB] Hazewinkel, H, Partain, D., "The Differentiated Services 758 Configuration MIB", draft-ietf-snmpconf-diffpolicy-05.txt, June 2002. 760 [BRGMIB] Norseth, K.C. and Bell, E., "Definitions of Managed Objects 761 for Bridges", draft-ietf-bridge-bridgeMIB-smiv2-04.txt, October 2002. 763 [BREMIB] Ngai, V., "Definitions of Managed Objects for Bridges with 764 Traffic Classes, Multicast Filtering and Virtual LAN Extensions", 765 draft-ietf-bridge-ext-v2-01.txt, September 2002. 767 [81xMIB] Norseth, K.C. "Definitions for Port Access Control (IEEE 768 802.1X) MIB", draft-ietf-bridge-8021x-01.txt, February, 2003. 770 Acknowledgements 772 The authors would like to thank Randy Presuhn and Pyda Srisuresh for 773 their comments and feedback on the initial version of this document. 775 Contributors' Addresses 777 The following individuals participated in the MIDCOM MIB design team 778 and thus provided implicit and explicit content for this document: 780 Wes Hardaker 781 Sparta 782 P.O. Box 382 783 Davis, CA 95617 784 USA 786 EMail: hardaker@tislabs.com 788 David Harrington, Co-chair SNMPv3 WG 789 Enterasys Networks 790 35 Industrial Way 791 Rochester, NH 03867-5005 792 USA 794 Phone: +1 603-337-2614 795 EMail: dbh@enterasys.com 797 Juergen Quittek 798 NEC Europe Ltd. 799 Network Laboratories 800 Kurfuersten-Anlage 36 801 69115 Heidelberg 802 Germany 804 Phone: +49 6221 90511-15 805 EMail: quittek@ccrle.nec.de 807 Martin Stiemerling 808 NEC Europe Ltd. 809 Network Laboratories 810 Adenauerplatz 6 811 69115 Heidelberg 812 Germany 814 Phone: +49 6221 90511-13 815 Email: stiemerling@ccrle.nec.de 817 Tom Taylor 818 Nortel Networks 819 1852 Lorraine Ave. 820 Ottawa, Ontario 821 Canada K1H 6Z8 823 Phone: +1 613 736 0961 824 Email: taylor@nortelnetworks.com 826 Editor's Address 828 Mary Barnes 829 Nortel Networks 830 2380 Performance Drive 831 Richardson, TX 75082 832 USA 834 Phone: 1-972-684-5432 835 Email: mbarnes@nortelnetworks.com 837 Appendix A � Analysis of the NATMIB against the MIDCOM semantics 839 This is an analysis of how the MIDCOM semantics requests and 840 notifications could be reflected by changes in the NAT MIB, and vice 841 versa. It compares [MDCSEM] with [NATMIB]. It does not reflect a 842 consensus of the design team, but rather is put forth as a position 843 (authored by Tom Taylor, edited by Mary) for discussion and presents 844 some issues requiring resolution in order to fully understand the 845 impact on the applicability of the NATMIB to MIDCOM from the 846 perspective of the MIDCOM semantics. 848 A.1 NAT MIB Summary 850 The NAT MIB as defined in draft-ietf-nat-natmib-06.txt consists of 851 the following tables. Based upon design team discussions, the group 852 and owner will be deleted from the next version of the NAT MIB, 853 wherever they appear. The following annotation applies to the 854 summary: 855 RC = Read-Create; RO = Read-Only 857 Config: Interface table 858 Index 859 Public/private RC 860 Type of NAT across this interface (basic, NAPT, bidirectional, 861 twice-NAT) RC 862 Map name (for all maps relating to this interface) RC 863 Housekeeping stuff (storage type, active/inactive) RC 865 Config: Address map table 866 Map name (as given in interface table) 867 Map sub-index 868 OwnerID RC 869 GroupID RO 870 Static/dynamic entry type RC 871 Trigger for mapping: inbound source, inbound destination, outbound 872 source, outbound destination RC 873 Local address/port range RC 874 Global address/port range RC 875 UDP/TCP/ICMP/other RC 876 Housekeeping stuff (storage type, active/inactive) RC 878 Translation: Address bind table 879 Local (private) address type and value (index) 880 Owner RO 881 Group RO 882 Global (public) address type and value RC 883 BindID RO 884 Unidirectional/bidirectional � 885 same as underlying address map entry RC 886 Static/dynamic RC 887 Map name in address map table RC 888 Number of active sessions using this bind RO 889 Maximum life of bind while no sessions active RC 890 Accumulated idle time with no sessions active RO 891 Number of inbound packets successfully translated using this bind 892 entry RO 893 Number of inbound packets successfully translated using this bind 894 entry RO 895 Active/inactive status RC 897 Translation: Address-port bind table (applies to NAPT) 898 Local (private) address type and value (index) 899 Local port. For ICMP query-id is used instead of port. (index) 900 Protocol. "None" => all IP. (index) 901 Owner RO 902 Group RO 903 Global (public) address type and value RC 904 Global port RC 905 BindID -- same as in address bind table RO 906 Unidirectional/bidirectional -- same as underlying address map 907 entry RC 908 Static/dynamic RC 909 Map name in address map table RC 910 Number of active sessions using this bind RO 911 Maximum life of bind while no sessions active RC 912 Accumulated idle time with no sessions active RO 913 Number of inbound packets successfully translated using this bind 914 entry RO 915 Number of inbound packets successfully translated using this bind 916 entry RO 917 Active/inactive status RC 919 Translation: session table 920 BindID in bind tables (index) 921 SessionId (index) 922 Owner RO 923 Group RO 924 In/out (relative to private network) RC 925 Session up time RO 926 Protocol RC 927 Original private address type and port (A0) RC 928 Translated private address type and port (A2) RC 929 Original public address type and port (A3) RC 930 Translated public address type and port (A1) RC 931 Maximum life of session while no packets detected RC 932 Accumulated idle time since last packet detected RO 933 Other bindID in case of twice-NAT RC 934 Number of inbound packets successfully translated in this session 935 RO 936 Number of inbound packets successfully translated in this session 937 RO 938 Active/inactive status RC 940 A.2 General remarks 942 E-mail discussion has indicated that an interface is a logical point 943 of attachment to a given subnetwork. 945 There is debate over whether it is possible to have flows from one 946 private interface to another. The [NATMIB] authors did not expect 947 that this could happen and it is not described in [RFC2663], for 948 example. The MIB structure always assumes that flows are between a 949 private and a public interface. 951 The NATMIB seems to provide redundant mapping capability, in that the 952 same mapping can be specified either on the public or on the private 953 interface through which a given flow passes. The assumption is, 954 based on the comments for the NATMIB natConfAddrMapTranslationEntity, 955 that the mapping is always specified on the public side for the 956 translation between the interior endpoint address A0 and the 957 intermediate exterior address A2. For twice-NAT, the mapping between 958 the exterior endpoint address A3 and the interior endpoint address A1 959 is specified on the private interface. (A0, A1, A2, and A3 as 960 described in [MDCSEM]. These may designate a range of ports as well 961 as an address, depending on the protocol.) 963 A further note from the same comments in the NATMIB is that "inbound" 964 is always toward the NAT, "outbound" is always away from it. The 965 specific example given in the comments is a session flow from a 966 private to a public interface. On the public interface, it would be 967 seen in the NATMIB as "outbound", while on the private interface it 968 is seen as "inbound". 970 The difference between the address map and the bind tables appears to 971 be as follows: 972 - the bind tables deal with mapping between specific address/port 973 pairs rather than ranges; 974 - a bind may be automatically deleted after a certain amount of time 975 without an active associated session; 976 - certain statistics are captured. 978 It is not clear how the unidirectional/bidirectional setting for a 979 bind entry is derived from the parent address map. One possibility 980 is that it comes from the type of NAT service provided on the 981 interface. The other is that it is determined by seeing if the 982 address map includes sub-entries for both inbound and outbound 983 triggers. 985 A.3 Interaction between PRR and the NAT MIB 987 [RFC2663] (NAT terminology) does not distinguish between mapping and 988 binding, saying only that binding is the first step in the NAT 989 translation process. This may have led to some confusion in 990 discussions amongst design team members, depending on what was meant 991 by "binding". The key question is whether an address map is allowed 992 to exist with no bindings referring to it. If this is possible only 993 in some implementations or is generally impossible, then PRR MUST 994 affect both the address map table and the address and address-port 995 bind tables. Otherwise, it can be argued that PRR should just affect 996 the address map table. As indicated below, this allows the MIDCOM 997 MIB to implement the MIDCOM concept of a fixed rule lifetime, in 998 contrast to (and over-riding) the traditional NAT concept of maximum 999 idle time. 1001 PRR requests the reservation of an external address A2 to which the 1002 internal endpoint address A0 will be mapped, and in the twice-NAT 1003 case also asks for the reservation of an internal address A1 on the 1004 interface to which A0 is connected. The unspecified external address 1005 A3 will be mapped to A1. The relevant parameters of PRR are: 1006 - service type: traditional or twice-NAT 1007 - transport protocol 1008 - internal address type and value (potentially wildcarded, if 1009 allowed by the NAT implementation) 1010 - internal starting port number and range 1011 - parity of the starting external port 1012 - external address type 1013 - internal (private) interface (optional) 1014 - external (public) interface (optional) 1015 - requested reservation lifetime. 1017 groupID has been omitted from this list because it is a MIDCOM rather 1018 than a NAT issue. The requested reservation lifetime is not an 1019 existing NAT concept, but has an important bearing on how the PRR is 1020 reflected in the NAT MIB, per the arguments below. 1022 The response to PRR includes the assigned external address(es) and 1023 port(s). 1025 A.3.1 Preliminary Comments 1027 According to the NAT MIB, the NAT type is a configured property of 1028 the interface and therefore cannot be arbitrarily chosen. It is for 1029 this reason that this analysis suggests that the service type 1030 parameter should not be present in the PRR. 1032 The internal interface parameter should only be needed if the MIDCOM 1033 agent is acting on behalf of an internal endpoint, which is served by 1034 a different interface. Otherwise it would be expected that the 1035 middlebox would use the internal interface on which the PRR arrived. 1037 It's not clear how the MIDCOM agent would know the applicable 1038 interface identifier and whether it has to use it. It seems there is 1039 a good argument for expecting that the MIDCOM agent and the internal 1040 endpoint are served by the same internal interface, simply because 1041 the MIDCOM agent is, by assumption, on the signalling path for the 1042 application. 1044 The value of having the external interface parameter isn't apparent. 1045 Either the internal address-port A0 is already covered by a binding 1046 or it is not. If it is, the external address is determined by the 1047 existing bind. If it is not, it should be up to the middlebox to 1048 choose the external interface, based on existing mapping table 1049 entries, load balancing considerations, etc. 1051 The possibility that A0 is a range of addresses rather than a single 1052 address is problematic. The problem comes about if different 1053 addresses within the range are covered by different existing bindings 1054 or map entries pointing to different external addresses. It's 1055 anticipated that it will be necessary to have a return code 1056 indicating that assignment could not be made due to conflict. 1057 Alternatively we can disallow wildcarding of A0 -- something that 1058 would seem to make sense in terms of application requirements. 1060 We have to accept the possibility that a PER following a PRR may 1061 fail. This may be because the middlebox has selected an external 1062 interface at the PRR stage through which A3 turns out to be 1063 unreachable. The second possibility is in the twice-NAT case and has 1064 been discussed already on the list: A3 when it becomes known may turn 1065 out to be contained in a binding that conflicts with the mapping to 1066 internal address A1. 1068 A.3.2 Choosing A1 and A2 1070 The PRR must always result in the assignment of an intermediate 1071 external address A2. It attempts to select A2 (address and ports, if 1072 applicable) according to the following possibilities in decreasing 1073 order of preference: 1075 (1) protocol and local address A0 from the PRR match an active bind 1076 on any public interface. In this case, the address part of A2 1077 is determined uniquely by the bind; the port part may be 1078 determined by active bind(s), may conflict with active binds, or 1079 may have to be chosen arbitrarily by the middlebox to match the 1080 requested range and parity. Conflict occurs if existing binds 1081 prevent the assignment of consecutive ports in the requested 1082 range or disagree with the requested parity. The PRR fails as a 1083 result. 1085 (2) local address A0 appears in an address map entry on any public 1086 interface and, if applicable, the internal port range in the PRR 1087 is included in the local port range for the map entry. In this 1088 case, the address part of A2 may be determined uniquely by the 1089 address map entry or may have to be selected from the possible 1090 range, and similarly for the ports. There is the remote 1091 possibility of a parity conflict if port mapping is determined 1092 uniquely but is of the wrong parity. 1094 (3) no applicable bind or address map entry is found. In this case 1095 the middlebox assigns A2, address and ports, based on internal 1096 logic. 1098 If the NAT type on the internal interface is "twice-NAT", the PRR 1099 must also result in the assignment of an intermediate internal 1100 address A1 on that interface. The middlebox selects address A1 (and 1101 ports, if applicable) from eligible possibilities for the internal 1102 interface based on internal logic. 1104 A.3.3 Effect of Assigning A1 and A2 On the NAT MIB 1106 Once A2 (and A1, if applicable) have been determined, the middlebox 1107 must create address map entries to support them. This is where the 1108 concept of reservation life is significant. Since the operation of 1109 the requested reservation lifetime is different from the maximum idle 1110 time assigned to binds, it seems best implemented by making the 1111 address map entries static. The lifetime is then controlled and 1112 reflected by the MIDCOM MIB rather than the NAT MIB. 1114 Creating new address map entries is straightforward if none 1115 previously existed. The question is what to do when an applicable 1116 address map entry already exists. The alternatives are to do 1117 nothing, to create a new entry overlapping with the existing entry, 1118 or else split the existing entry into multiple entries, including one 1119 matching the assigned address and ports and as many others as 1120 necessary to cover the original range. 1122 Relying on the existing entry alone ("do nothing") requires that a 1123 reference count be attached to the address map entry in the NAT MIB 1124 to record the number of MIDCOM policy rules relying on it. This 1125 count is increased by 1 if the original entry was created by means 1126 other than a MIDCOM request. The count is reduced by 1 each time a 1127 MIDCOM policy rule lifetime expires or the rule is deleted, or if the 1128 non-MIDCOM process originally responsible for creating the address 1129 map entry decides to delete it. When the count reaches zero the 1130 address map entry, all child binds, and all sessions deriving from 1131 those binds are deleted. One problem with the "do nothing" approach 1132 is that if the original process creating the entry was not a MIDCOM 1133 request and no longer requires the entry, the scope of the entry 1134 (address range, port range) will in general be broader than required 1135 by the dependent MIDCOM policy rules. As will be seen when the 1136 MIDCOM query primitives are discussed, this approach will require 1137 some redundancy between the MIDCOM and NAT MIBs. 1139 The overlapping entry approach avoids the need for reference counts 1140 and provides a precise match to each MIDCOM request. However, the 1141 non-MIDCOM entries must be flagged to ensure that they are the ones 1142 non-MIDCOM processes use to create binds. The MIDCOM MIB records the 1143 map name and sub-index of the address map entry corresponding to a 1144 given policy rule, so no policy rule linking information is be needed 1145 in the NAT MIB itself. This approach has the advantage that it 1146 avoids the redundancy referred to in the previous paragraph. 1148 The entry split approach is not really practical. To ensure that 1149 deletions by MIDCOM and by non-MIDCOM processes were handled 1150 correctly, the fragments of the original range would have to be 1151 identified by the original address map entry sub-index as well as a 1152 new one for each fragment. Reference counts might also be needed. 1153 Moreover, the number of address map entries would grow more rapidly 1154 than with the overlapping address map entry approach. 1156 1158 Full Copyright Statement 1160 Copyright (C) The Internet Society (2003). All Rights Reserved. 1162 This document and translations of it may be copied and furnished to 1163 others, and derivative works that comment on or otherwise explain it 1164 or assist in its implementation may be prepared, copied, published 1165 and distributed, in whole or in part, without restriction of any 1166 kind, provided that the above copyright notice and this paragraph 1167 are included on all such copies and derivative works. However, this 1168 document itself may not be modified in any way, such as by removing 1169 the copyright notice or references to the Internet Society or other 1170 Internet organizations, except as needed for the purpose of 1171 developing Internet standards in which case the procedures for 1172 copyrights defined in the Internet Standards process must be 1173 followed, or as required to translate it into languages other than 1174 English. The limited permissions granted above are perpetual and 1175 will not be revoked by the Internet Society or its successors or 1176 assigns. This document and the information contained 1177 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1178 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1179 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1180 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1181 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1182 PARTICULAR PURPOSE.