idnits 2.17.1 draft-ietf-midcom-mib-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4265. 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 abstract seems to contain references ([I-D.ietf-midcom-RFC3989-bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 700 has weird spacing: '...irewall othe...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (December 6, 2007) is 5979 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) ** Obsolete normative reference: RFC 4008 (Obsoleted by RFC 7658) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft J. Quittek 2 Document: draft-ietf-midcom-mib-11.txt M. Stiemerling 3 Intended Status: Standards Track NEC 4 Expires: June 6, 2008 P. Srisuresh 5 Consultant 6 December 6, 2007 8 Definitions of Managed Objects for Middlebox Communication 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 15, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This memo defines a portion of the Management Information Base (MIB) 42 for use with network management protocols in the Internet community. 43 In particular, it describes a set of managed objects that allow 44 configuring middleboxes, such as firewalls and network address 45 translators, in order to enable communication across these devices. 46 The definitions of managed objects in this documents follow closely 47 the MIDCOM semantics defined in [I-D.ietf-midcom-rfc3989-bis]. 49 Table of Contents 51 1 Introduction ................................................. 3 52 2 The Internet-Standard Management Framework ................... 3 53 3 Overview ..................................................... 3 54 3.1 Terminology ................................................ 4 55 4 Realizing the MIDCOM Protocol with SNMP ...................... 4 56 4.1 MIDCOM Sessions ............................................ 5 57 4.1.1 Authentication and Authorization ......................... 5 58 4.2 MIDCOM Transactions ........................................ 6 59 4.2.1 Asynchronous Transactions ................................ 6 60 4.2.2 Configuration Transactions ............................... 7 61 4.2.3 Monitoring Transactions .................................. 10 62 4.2.4 Atomicity of MIDCOM Transactions ......................... 11 63 4.2.4.1 Asynchronous MIDCOM Transactions ....................... 11 64 4.2.4.2 Session Establishment and Termination Transactions ..... 11 65 4.2.4.3 Monitoring Transactions ................................ 12 66 4.2.4.4 Lifetime Change Transactions ........................... 12 67 4.2.4.5 Transactions Establishing New Policy Rules ............. 12 68 4.2.5 Access Control ........................................... 13 69 4.3 Access Control Policies .................................... 13 70 5 Structure of the MIB module .................................. 15 71 5.1 Transaction Objects ........................................ 16 72 5.1.1 midcomRuleTable .......................................... 16 73 5.1.2 midcomGroupTable ......................................... 19 74 5.2 Configuration Objects ...................................... 19 75 5.2.1 Capabilities ............................................. 20 76 5.2.2 midcomConfigFirewallTable ................................ 20 77 5.3 Monitoring Objects ......................................... 21 78 5.3.1 midcomResourceTable ...................................... 21 79 5.3.2 midcomStatistics ......................................... 23 80 5.4 Notifications .............................................. 24 81 6 Recommendations for Configuration and Operation .............. 26 82 6.1 Security Model Configuration ............................... 26 83 6.2 VACM Configuration ......................................... 26 84 6.3 Notification Configuration ................................. 27 85 6.4 Simultaneous Access ........................................ 27 86 6.5 Avoiding Idempotency Problems .............................. 28 87 6.6 Interface Indexing Problems ................................ 28 88 6.7 Applicability Restrictions ................................. 29 89 7 Usage Examples for MIDCOM Transactions ....................... 30 90 7.1 Session Establishment (SE) ................................. 30 91 7.2 Session Termination (ST) ................................... 30 92 7.3 Policy Reserve Rule (PRR) .................................. 31 93 7.4 Policy Enable Rule (PER) after PRR ......................... 32 94 7.5 Policy Enable Rule (PER) without previous PRR .............. 33 95 7.6 Policy Rule Lifetime Change (RLC) .......................... 34 96 7.7 Policy Rule List (PRL) ..................................... 34 97 7.8 Policy Rule Status (PRS) ................................... 34 98 7.9 Asynchronous Policy Rule Event (ARE) ....................... 34 99 7.10 Group Lifetime Change (GLC) ............................... 35 100 7.11 Group List (GL) ........................................... 35 101 7.12 Group Status (GS) ......................................... 35 102 8 Usage Examples for Monitoring Objects ........................ 36 103 8.1 Monitoring NAT Resources ................................... 36 104 8.2 Monitoring Firewall Resources .............................. 36 105 9 Definitions .................................................. 38 106 10 Security Considerations ..................................... 83 107 10.1 General Security Issues ................................... 83 108 10.2 Unauthorized Middlebox Configuration ...................... 84 109 10.3 Unauthorized Access to Middlebox Configuration ............ 85 110 10.4 Unauthorized Access to MIDCOM Service Configuration ....... 85 111 11 Acknowledgements ............................................ 85 112 12 IANA Considerations ......................................... 86 113 13 Normative References ........................................ 86 114 14 Informative References ...................................... 87 115 15 Authors' Addresses .......................................... 88 117 1. Introduction 119 This memo defines a portion of the Management Information Base (MIB) 120 for use with network management protocols in the Internet community. 121 In particular, it describes a set of managed objects that allow 122 controlling middleboxes. 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. The Internet-Standard Management Framework 130 For a detailed overview of the documents that describe the current 131 Internet-Standard Management Framework, please refer to section 7 of 132 RFC 3410 [RFC3410]. 134 Managed objects are accessed via a virtual information store, termed 135 the Management Information Base or MIB. MIB objects are generally 136 accessed through the Simple Network Management Protocol (SNMP). 137 Objects in the MIB are defined using the mechanisms defined in the 138 Structure of Management Information (SMI). This memo specifies a MIB 139 module that is compliant to the SMIv2, which is described in STD 58, 140 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 141 [RFC2580]. 143 3. Overview 145 The managed objects defined in this document serve for controlling 146 firewalls and Network Address Translators (NATs). As defined in 147 [RFC3234], firewalls and NATs belong to the group of middleboxes. A 148 middlebox is a device on the datagram path between source and 149 destination, which performs other functions than just IP routing. As 150 outlined in [RFC3303], firewalls and NATs are potential obstacles to 151 packet streams, for example if dynamically negotiated UDP or TCP port 152 numbers are used, as in many peer-to-peer communication applications. 154 As one possible solution for this problem, the IETF MIDCOM working 155 group defined a framework [RFC3303], requirements [RFC3304] and 156 protocol semantics [I-D.ietf-midcom-rfc3989-bis] for communication 157 between applications and middleboxes acting as firewalls, NATs or a 158 combination of both. The MIDCOM architecture and framework defines a 159 model in which trusted third parties can be delegated to assist 160 middleboxes in performing their operations, without requiring 161 application intelligence being embedded in the middleboxes. This 162 trusted third party is referred to as the MIDCOM Agent. The MIDCOM 163 protocol is defined between a MIDCOM agent and a middlebox. 165 The managed objects defined in this document can be used for 166 dynamically configuring middleboxes on the datagram path to permit 167 datagrams traversing the middleboxes. This way, applications can, 168 for example, request pinholes at firewalls and address bindings at 169 NATs. 171 Besides managed objects for controlling the middlebox operation, this 172 document also defines managed objects that provide information on 173 middlebox resource usage (such as firewall pinholes, NAT bindings, 174 NAT sessions, etc.) affected by requests. 176 Since firewalls and NATs are critical devices concerning network 177 security, security issues of middlebox communication need to be 178 considered very carefully. 180 3.1. Terminology 182 The terminology used in this document is fully aligned with the 183 terminology defined in [I-D.ietf-midcom-rfc3989-bis] except for the 184 term 'MIDCOM agent'. For this term there is a conflict between the 185 MIDCOM terminology and the SNMP terminology. The roles of entities 186 participating in SNMP communication are called 'manager' and 'agent' 187 with the agent acting as server for requests from the manager. This 188 use of the term 'agent' is different to its use in the MIDCOM 189 framework: The SNMP manager corresponds to the MIDCOM agent and the 190 SNMP agent corresponds to the MIDCOM middlebox, also called MIDCOM 191 server. In order to avoid confusion in this document specifying a 192 MIB module, we replace the term 'MIDCOM agent' by 'MIDCOM client'. 193 Whenever the term 'agent' is used in this document, it refers to the 194 SNMP agent. Figure 1 sketches the entities of MIDCOM in relationship 195 to SNMP manager and SNMP agent. 197 +---------+ MIDCOM +-----------+ 198 | MIDCOM |<~ ~ ~ ~ ~ ~ ~ ~>| MIDCOM | 199 | Client | Transaction | middlebox | 200 | | | (server) | 201 +---------+ +-----------+ 202 ^ ^ 203 | | 204 v v 205 +---------+ +-----------+ 206 | SNMP | SNMP | SNMP | 207 | Manager |<===============>| Agent | 208 +---------+ Protocol +-----------+ 210 Figure 1: Mapping of MIDCOM to SNMP 212 4. Realizing the MIDCOM Protocol with SNMP 214 In order to realize middlebox communication as described in [I- 215 D.ietf-midcom-rfc3989-bis], several aspects and properties of the 216 MIDCOM protocol need to be mapped to SNMP capabilities and expressed 217 in terms of the Structure of Management Information version 2 218 (SMIv2). 220 Basic concepts to be mapped are MIDCOM sessions and MIDCOM 221 transactions. For both, access control policies need to be 222 supported. 224 4.1. MIDCOM Sessions 226 SNMP has no direct support for sessions. Therefore, they need to be 227 modeled. A MIDCOM session is stateful and has a context that is 228 valid for several transactions. For SNMP, a context is valid for a 229 single transaction only, for example covering just a single 230 request/reply pair of messages. 232 Properties of sessions that are utilized by the MIDCOM semantics and 233 not available in SNMP need to be modeled. Particularly, the 234 middlebox needs to be able to authenticate MIDCOM clients, authorize 235 access to policy rules, and send notification messages concerning 236 policy rules to MIDCOM clients participating in a session. In the 237 MIDCOM MIB module, authentication and access control are performed on 238 a per-message base using an SNMPv3 security model, such as the User- 239 based Security Model (USM) [RFC3414], for authentication, and the 240 View-based Access control Model (VACM) [RFC3415] for access control. 241 Sending notifications to MIDCOM clients is controlled by access 242 control models such as VACM and a mostly static configuration of 243 objects in the SNMP-TARGET-MIB [RFC3413] and the SNMP-NOTIFICATION- 244 MIB [RFC3413]. 246 This session model is static except that the MIDCOM client can switch 247 on and off the generation of SNMP notifications that the middlebox 248 sends. Recommended configurations of VACM and the SNMP-TARGET-MIB 249 and the SNMP-NOTIFICATION-MIB that can serve for modeling a session 250 are described in detail in section 6. 252 4.1.1. Authentication and Authorization 254 MIDCOM sessions are required for providing authentication, 255 authorization and encryption for messages exchanged between a MIDCOM 256 client and a middlebox. SNMPv3 provides these features on a per- 257 message basis instead of a per-session basis applying a security 258 model and an access control model, such as USM and VACM. Per-message 259 security mechanisms can be considered as overhead compared to per- 260 session security mechanisms, but it certainly satisfies the security 261 requirements of middlebox communication. 263 For each authenticated MIDCOM client, access to the MIDCOM-MIB, 264 particularly to policy rules, should be configured as part of the 265 VACM configuration of the SNMP agent. 267 4.2. MIDCOM Transactions 269 [I-D.ietf-midcom-rfc3989-bis] defines the MIDCOM protocol semantics 270 in terms of transactions and transaction parameters. Transactions 271 are grouped into request-reply transactions and asynchronous 272 transactions. 274 SNMP offers simple transactions that in general cannot be mapped one- 275 to-one to MIDCOM transactions. This section describes how the MIDCOM 276 MIB module implements MIDCOM transactions using SNMP transactions. 277 The concerned MIDCOM transactions are asynchronous transactions and 278 request-reply transactions. Within the set of request-reply 279 transactions we distinguish configuration transactions and monitoring 280 transactions, because they are implemented in slightly different ways 281 by using SNMP transactions. 283 The SNMP terminology as defined in [RFC3411] does not use the concept 284 of transactions, but of SNMP operations. For the considerations in 285 this section we use the terms SNMP get transaction and SNMP set 286 transaction. An SNMP get transaction consists of an SNMP Read Class 287 operation and an SNMP Response Class operation. An SNMP set 288 transaction consists of an SNMP Write Class operation and an SNMP 289 Response Class operation. 291 4.2.1. Asynchronous Transactions 293 Asynchronous transactions can easily be modeled by SNMP Notification 294 Class operations. An asynchronous transaction contains a 295 notification message with one to three parameters. The message can 296 be realized as an SNMP Notification Class operation with the 297 parameters implemented as managed objects contained in the 298 notification. 300 +--------------+ notification +------------+ 301 | MIDCOM client|<--------------| middlebox | 302 +--------------+ message +------------+ 304 MIDCOM asynchronous transaction 306 +--------------+ SNMP +------------+ 307 | SNMP manager |<--------------| SNMP agent | 308 +--------------+ notification +------------+ 310 Implementation of MIDCOM asynchronous transaction 312 Figure 2: MIDCOM asynchronous transaction 313 mapped to SNMP Notification Class operation 315 One of the parameters is the transaction identifier that should be 316 unique per middlebox. It does not have to be unique for all 317 notifications sent by the particular SNMP agent, but for all sent 318 notifications that are defined by the MIDCOM MIB module. 320 Note, SNMP notifications are usually sent as unreliable UDP packets 321 and may be dropped before they reach their destination. If a MIDCOM 322 client is expecting an asynchronous notification on a specific 323 transaction, it would be the job of the MIDCOM client to poll the 324 middlebox periodically and monitor the transaction in case 325 notifications are lost along the way. 327 4.2.2. Configuration Transactions 329 All request-reply transactions contain a request message, a reply 330 message and potentially also a set of notifications. In general they 331 cannot be modeled by just having a single SNMP message per MIDCOM 332 message, because some of the MIDCOM messages carry a large set of 333 parameters that do not necessarily fit into an SNMP message 334 consisting of a single UDP packet only. 336 For configuration transactions the MIDCOM request message can be 337 modeled by one or more SNMP set transactions. The action of sending 338 the MIDCOM request to the middlebox is realized by writing the 339 parameters contained in the message to managed objects at the SNMP 340 agent. If necessary, the SNMP set transaction includes creating 341 these managed objects. If not all parameters of the MIDCOM request 342 message can be set by a single SNMP set transaction, then more than 343 one set transaction are used, see Figure 3. Completion of the last 344 of the SNMP transactions indicates that all required parameters are 345 set and that processing of the MIDCOM request message can start at 346 the middlebox. 348 Please note that a single SNMP set transaction consists of an SNMP 349 set request message and an SNMP set reply message. Both are sent as 350 unreliable UDP packets and may be dropped before they reach their 351 destination. If the SNMP set request message or the SNMP reply 352 message is lost, then the SNMP manager (the MIDCOM client) needs to 353 take action, for example by just repeating the set transaction or by 354 first checking the success of the initial write transaction with an 355 SNMP get transaction and then only repeating the SNMP set transaction 356 if necessary. 358 +--------------+ request +------------+ 359 | MIDCOM client|-------------->| middlebox | 360 +--------------+ message +------------+ 362 MIDCOM request message 364 +--------------+ +------------+ 365 | | SNMP set | | 366 | |-------------->| | 367 | | message | | 368 | | | | 369 | | SNMP set | | 370 | |<--------------| | 371 | | reply message | | 372 | SNMP manager | | SNMP agent | 373 | | SNMP set | | 374 | |- - - - - - - >| | 375 | | message | | 376 | | | | 377 | | SNMP set | | 378 | |< - - - - - - -| | 379 | | reply message | | 380 | | | | 381 | | . . . | | 382 +--------------+ +------------+ 384 Implementation of MIDCOM request message 385 by one or more SNMP set transactions 387 Figure 3: MIDCOM request message 388 mapped to SNMP set transactions 390 The MIDCOM reply message can be modeled in two ways. The first way 391 is an SNMP Notification Class operation optionally followed by one or 392 more SNMP get transactions as shown in Figure 4. The MIDCOM server 393 informs the MIDCOM client about the end of processing the request by 394 sending an SNMP notification. If possible, the SNMP notification 395 carries all reply parameters. If this is not possible, then the SNMP 396 manager has to perform additional SNMP get transactions as long as 397 necessary to receive all of the reply parameters. 399 +--------------+ reply +------------+ 400 | MIDCOM client|<--------------| middlebox | 401 +--------------+ message +------------+ 403 MIDCOM reply message 405 +--------------+ +------------+ 406 | | SNMP | | 407 | |<--------------| | 408 | | notification | | 409 | | | | 410 | | SNMP get | | 411 | |-------------->| | 412 | | message | | 413 | SNMP manager | | SNMP agent | 414 | | SNMP get | | 415 | |<--------------| | 416 | | reply message | | 417 | | | | 418 | | SNMP get | | 419 | |- - - - - - - >| | 420 | | message | | 421 | | | | 422 | | SNMP get | | 423 | |< - - - - - - -| | 424 | | reply message | | 425 | | | | 426 | | . . . | | 427 +--------------+ +------------+ 429 Implementation of MIDCOM reply message 430 by an SNMP notification 431 and one or more SNMP get transactions 433 Figure 4: MIDCOM reply message 434 mapped to SNMP notification and optional get transactions 436 The second way replaces the SNMP Notification Class operation by a 437 polling operation of the SNMP manager. The manager polls status 438 information at the SNMP agent using SNMP get transactions until it 439 detects the end of the processing of the request. Then it uses one 440 or more SNMP get transaction to receive all of the reply parameters. 441 Note that this second way requires more SNMP operations, but is more 442 reliable than the first way using an SNMP Notification Class 443 operation. 445 4.2.3. Monitoring Transactions 447 The realization of MIDCOM monitoring transactions in terms of SNMP 448 transactions is simpler. The request message is very short and just 449 specifies a piece of information that the MIDCOM client wants to 450 retrieve. 452 +--------------+ request +------------+ 453 | |-------------->| | 454 | | message | | 455 | MIDCOM client| | middlebox | 456 | | reply | | 457 | |<--------------| | 458 +--------------+ message +------------+ 460 MIDCOM monitoring transaction 462 +--------------+ +------------+ 463 | | SNMP get | | 464 | |-------------->| | 465 | | message | | 466 | | | | 467 | | SNMP get | | 468 | |<--------------| | 469 | | reply message | | 470 | SNMP manager | | SNMP agent | 471 | | SNMP get | | 472 | |- - - - - - - >| | 473 | | message | | 474 | | | | 475 | | SNMP get | | 476 | |< - - - - - - -| | 477 | | reply message | | 478 | | | | 479 | | . . . | | 480 +--------------+ +------------+ 482 Implementation of MIDCOM monitoring transaction 483 by one or more SNMP get messages 485 Figure 5: MIDCOM monitoring transaction 486 mapped to SNMP get transactions 488 Since monitoring is a strength of SNMP, there are sufficient means to 489 realize MIDCOM monitoring transactions simpler than MIDCOM 490 configuration transactions. 492 All MIDCOM monitoring transactions can be realized as a sequence of 493 SNMP get transactions. The number of SNMP get transactions required 494 depends on the amount of information to be retrieved. 496 4.2.4. Atomicity of MIDCOM Transactions 498 Given the realizations of MIDCOM transactions by means of SNMP 499 transactions, atomicity of the MIDCOM transactions is not fully 500 guaranteed anymore. However, this section shows that atomicity 501 provided by the MIB module specified in section 9 is still sufficient 502 for meeting the MIDCOM requirements specified in [RFC3304]. 504 4.2.4.1. Asynchronous MIDCOM Transactions 506 There are two asynchronous MIDCOM transactions: Asynchronous Session 507 Termination (AST) and Asynchronous policy Rule Event (ARE). The very 508 static realization of MIDCOM sessions in the MIDCOM-MIB, as described 509 by section 4.1, does not anymore support the asynchronous termination 510 of a session. Therefore, the AST transaction is not modeled. For 511 the ARE, atomicity is maintained, because it is modeled by a single 512 atomic SNMP notification transaction. 514 In addition, the MIDCOM-MIB supports an Asynchronous Group Event 515 transaction which is an aggregation of a set of ARE transactions. 516 Also this MIDCOM transaction is implemented by a single SNMP 517 transaction. 519 4.2.4.2. Session Establishment and Termination Transactions 521 The MIDCOM-MIB models MIDCOM sessions in a very static way. The only 522 dynamic actions within these transactions are enabling and disabling 523 the generation of SNMP notifications at the SNMP agent. 525 For the Session Establishment (SE) transaction the MIDCOM client 526 first reads the middlebox capabilities. It is not relevant whether 527 or not this action is atomic because a dynamic change of the 528 middlebox capabilities is not to be expected. Therefore, also non- 529 atomic implementations of this action are acceptable. 531 Then the MIDCOM agent needs to enable generation of SNMP 532 notifications at the middlebox. This can be realized by writing to a 533 single managed object in the SNMP-NOTIFICATION-MIB [RFC3413]. But 534 even other implementations are acceptable, because atomicity is not 535 required for this step. 537 For the Session Termination (ST) transaction the only required action 538 is disabling the generation of SNMP notifications at the middlebox. 539 As for the SE transaction, this action can be realized atomically by 540 using the SNMP-NOTIFICATION-MIB, but also other implementations are 541 acceptable because atomicity is not required for this action. 543 4.2.4.3. Monitoring Transactions 545 Potentially, the monitoring transactions Policy Rule List (PRL), 546 Policy Rule Status (PRS), Group List (GL), and Group Status (GS) are 547 not atomic, because these transactions may be implemented by more 548 than one SNMP get operations. 550 The problem that might occur is that while the monitoring transaction 551 is performed, the monitored items may change. For example, while 552 reading a long list of policies, new policies may be added and 553 already read policies may be deleted. This is not in line with the 554 protocol semantics. However, it is not in direct conflict with the 555 MIDCOM requirement requesting the middlebox state to be stable and 556 known by the MIDCOM client, because the middlebox notifies the MIDCOM 557 client on all changes to its state that are performed during the 558 monitoring transaction by sending notifications. 560 If the MIDCOM client receives such a notification while performing a 561 monitoring transaction (or shortly after completing it), the MIDCOM 562 client can then either repeat the monitoring transaction or integrate 563 the result of the monitoring transaction with the information 564 received via notifications during the transaction. In both cases, 565 the MIDCOM client will know the state of the middlebox. 567 4.2.4.4. Lifetime Change Transactions 569 For the policy Rule Lifetime Change (RLC) transaction and the Group 570 Lifetime Change (GLC) transaction atomicity is maintained. They both 571 have very few parameters for the request message and the reply 572 message. The request parameters can be transmitted by a single SNMP 573 set request message and the reply parameters can be transmitted by a 574 single SNMP notification message. In order to prevent idempotency 575 problems by retransmitting an SNMP request after a lost SNMP reply, 576 it is RECOMMENDED that either snmpSetSerialNo (see [RFC3418]) is 577 included in the corresponding SNMP SET request or the value of the 578 SNMP retransmission timer is lower than the smallest requested 579 lifetime value. The same recommendation applies to the smallest 580 requested value for the midcomRuleStorageTime. MIDCOM client 581 implementations MAY completely avoid this problem by configuring 582 their SNMP stack such that no retransmissions are sent. 584 4.2.4.5. Transactions Establishing New Policy Rules 586 Analogous to the monitoring transactions, the atomicty may not be 587 given for Policy Reserve Rule (PRR) and Policy Enable Rule (PER) 588 transactions. Both transactions are potentially implemented using 589 more than one SNMP set and get operations for obtaining transaction 590 reply parameters. The solution for this loss of atomicity is the 591 same as for the monitoring transactions. 593 There is an additional atomicity problem for PRR and PER. If 594 transferring request parameters requires more than a single set 595 operation, then there is the potential problem that multiple MIDCOM 596 clients sharing the same permissions are able to access the same 597 policy rule. In this case a client could alter request parameters 598 already set by another client before the first client could complete 599 the request. However, this is acceptable since usually only one 600 agent is creating a policy rule and filling it subsequently. It can 601 also be assumed that in most cases where clients share permissions, 602 they act in a more or less coordinated way avoiding such 603 interferences. 605 All atomicity problems caused by using multiple SNMP set transactions 606 for implementing the MIDCOM request message can be avoided by 607 transferring all request parameters with a single SNMP set 608 transaction. 610 4.2.5. Access Control 612 Since SNMP does not offer per-session authentication and 613 authorization, authentication and authorization are performed per 614 SNMP message sent from the MIDCOM client to the middlebox. 616 For each transaction, the MIDCOM client has to authenticate itself as 617 an authenticated principal, such as a USM user. Then the principal's 618 access rights to all resources affected by the transaction are 619 checked. Access right control is realized by configuring the access 620 control mechanisms, such as VACM, at the SNMP agent. 622 4.3. Access Control Policies 624 Potentially, a middlebox has to control access for a large set of 625 MIDCOM clients and to a large set of policy rules configuring 626 firewall pinholes and NAT bindings. Therefore it can be beneficial 627 to use access control policies for specifying access control rules. 628 Generating, provisioning and managing these policies is out of scope 629 of this MIB module. 631 However, if such access control policy system is used, then the SNMP 632 agent acts as policy enforcement point. An access control policy 633 system must transform all active policies into configurations of, for 634 example, the SNMP agent's View-based Access Control Model (VACM). 636 The mechanisms of access control models, such as VACM, allow an 637 access control policy system to enforce MIDCOM client authentication 638 rules and general access control of MIDCOM clients to middlebox 639 control. 641 The mechanisms of VACM can be used to enforce access control of 642 authenticated clients to MIDCOM-MIB policy rules based on the concept 643 of ownership. For example, an access control policy can specify that 644 MIDCOM-MIB policy rules owned by user A, cannot be accessed at all by 645 user B, can be read by user C, and can be read and modified by user 646 D. 648 Further access control policies can control access to concrete 649 middlebox resources. These are enforced, when a MIDCOM request is 650 processed. For example an authenticated MIDCOM client may be 651 authorized to request new MIDCOM policies to be established, but only 652 for certain IP address ranges. The enforcement of this kind of 653 policies may not be realizable using available SNMP mechanisms, but 654 needs to be performed by the individual MIB module implementation. 656 5. Structure of the MIB module 658 The MIB module defined in section 9 contains three kinds of managed 659 objects: 661 - Transaction objects 662 Transaction objects are required for implementing the MIDCOM 663 protocol requirements defined in [RFC3304] and the MIDCOM 664 protocol semantics defined in [I-D.ietf-midcom-rfc3989-bis]. 666 - Configuration objects 667 Configuration objects can be used for retrieving middlebox 668 capability information (mandatory) and for setting parameters of 669 the implementation of transaction objects (optional). 671 - Monitoring objects 672 The optional monitoring objects that provide information about 673 used resources and about MIDCOM transaction statistics. 675 The transaction objects are organized in two tables: the 676 midcomRuleTable and the midcomGroupTable. Entity relationships of 677 entries of these tables and the midcomResourceTable from the 678 monitoring objects are illustrated by Figure 6. 680 +--------------------+ 681 | midcomRuleEntry | 682 | indexed by | 683 | midcomRuleOwner | 684 | midcomGroupIndex | 685 | midcomRuleIndex | 686 +--------------------+ 687 1...n | | 1 688 | | 689 1 | | 1 690 +--------------------+ +---------------------+ 691 | midcomGroupEntry | | midcomResourceEntry | 692 | indexed by | | indexed by | 693 | midcomRuleOwner | | midcomRuleOwner | 694 | midcomGroupIndex | | midcomGroupIndex | 695 +--------------------+ | midcomRuleIndex | 696 +---------------------+ 697 | | | 698 | | | 699 v v v 700 NAT Firewall other 701 MIB MIB MIB 703 Figure 6: Entity relationships of table entries 705 A MIDCOM client can create and delete entries in the midcomRuleTable. 706 Entries in the midcomGroup table are generated automatically as soon 707 as there is an entry in the midcomRuleTable using the 708 midcomGroupIndex. The midcomGroupTable can be used as shortcut for 709 accessing all member rules with a single transaction. MIDCOM clients 710 can group policy rules for various purposes. For example, they can 711 assign a unique value for the midcomGroupIndex to all rules belonging 712 to a single application or an application session served by the 713 MIDCOM agent. 715 The midcomResourceTable augments the midcomRuleTable by information 716 on the relationship of entries of the midcomRuleTable to resources 717 listed in other MIB modules, such as the NAT MIB [RFC4008]. 719 5.1. Transaction Objects 721 The transaction objects are structured according to the MIDCOM 722 semantics described in [I-D.ietf-midcom-rfc3989-bis] into two 723 subtrees, one for policy rule control and one for policy rule group 724 control. 726 5.1.1. midcomRuleTable 728 The midcomRuleTable contains information about policy rules including 729 policy rules to be established, policy rules for which establishing 730 failed, established policy rules and terminated policy rules. 732 Entries in this table are indexed by the combination of 733 midcomRuleOwner, midcomGroupIndex and midcomRuleIndex. The 734 midcomRuleOwner is the owner of the rule; the midcomGroupIndex is the 735 index of the group of which the policy rule is a member. 737 midcomRuleOwner is of type SnmpAdminString, a textual convention that 738 allows for use of the SNMPv3 View-Based Access Control Model (VACM 739 [RFC3415]) and allows a management application to identify its 740 entries. 742 Entries in this table are created by writing to midcomRuleRowStatus. 743 Entries are removed, when both, their midcomRuleLifetime and 744 midcomRuleStorageTime, are timed out by counting down to 0. A MIDCOM 745 client can explicitly remove an entry by setting midcomRuleLifetime 746 and midcomRuleStorageTime to 0. 748 The table contains the following columnar objects: 750 o midcomRuleIndex 751 The index of this entry must be unique in combination with the 752 midcomRuleOwner and the midcomGroupIndex of the entry. 754 o midcomRuleAdminStatus 755 For establishing a new policy rule, a set of objects in this 756 entry needs to be written first. These objects are the request 757 parameters. Then, by writing either reserve(1) or enable(2) to 758 this object, the MIDCOM MIB implementation is triggered to start 759 processing the parameters and tries to establish the specified 760 policy rule. 762 o midcomRuleOperStatus 763 This read-only object indicates the current status of the entry. 764 The entry may have an initializing state, it may have a 765 transient state while processing requests, it may have an error 766 state after a request was rejected, it may have a state where a 767 policy rule is established, or it may have a terminated state. 769 o midcomRuleStorageType 770 This object indicates whether or not the policy rule is stored 771 as volatile, non-volatile, or permanent. Depending on the 772 MIDCOM MIB implementation this object may be writable. 774 o midcomRuleStorageTime 775 This object indicates how long the entry will still exist after 776 entering an error state or a termination state. 778 o midcomRuleError 779 This object is a string indicating the reason for entering an 780 error state. 782 o midcomRuleInterface 783 This object indicates the IP interface for which enforcement of 784 a policy rule is requested or performed, respectively. 786 o midcomRuleFlowDirection 787 This object indicates a flow direction for which a policy enable 788 rule was requested or established, respectively. 790 o midcomRuleMaxIdleTime 791 This object indicates the maximum idle time of the policy rule 792 in seconds. If no packet to which the policy rule applies 793 passes the middlebox for the time specified by 794 midcomRuleMaxIdleTime, then the policy rule enters a termination 795 state. 797 o midcomRuleTransportProtocol 798 This object indicates a transport protocol for which a policy 799 reserve rule or policy enable rule was requested or established, 800 respectively. 802 o midcomRulePortRange 803 This object indicates a port range for which a policy reserve 804 rule or policy enable rule was requested or established, 805 respectively. 807 o midcomRuleLifetime 808 This object indicates the remaining lifetime of an established 809 policy rule. The MIDCOM client can change the remaining 810 lifetime by writing to it. 812 Beyond the listed objects, the table contains 10 further objects 813 describing address parameters. They include the IP version, IP 814 address, prefix length and port number for the internal address (A0), 815 inside address (A1), outside address (A2) and external address (A3). 816 These objects serve as parameters specifying a request or an 817 established policy, respectively. 819 A0, A1, A2 and A3 are address tuples defined according to the MIDCOM 820 semantics [I-D.ietf-midcom-rfc3989-bis]. Each of them identifies 821 either a communication endpoint at an internal or external device or 822 an allocated address at the middlebox. 824 +----------+ +----------+ 825 | internal | A0 A1 +-----------+ A2 A3 | external | 826 | endpoint +----------+ middlebox +----------+ endpoint | 827 +----------+ +-----------+ +----------+ 829 Figure 7: Address tuples A0 - A3 831 - A0 - internal endpoint: address tuple A0 specifies a 832 communication endpoint of a device within the - with respect to 833 the middlebox - internal network. 835 - A1 - middlebox inside address: address tuple A1 specifies a 836 virtual communication endpoint at the middlebox within the 837 internal network. A1 is the destination address for packets 838 passing from the internal endpoint to the middlebox, and is the 839 source for packets passing from the middlebox to the internal 840 endpoint. 842 - A2 - middlebox outside address: address tuple A2 specifies a 843 virtual communication endpoint at the middlebox within the 844 external network. A2 is the destination address for packets 845 passing from the external endpoint to the middlebox, and is the 846 source for packets passing from the middlebox to the external 847 endpoint. 849 - A3 - external endpoint: address tuple A3 specifies a 850 communication endpoint of a device within the - with respect to 851 the middlebox - external network. 853 The MIDCOM-MIB requires the MIDCOM client to specify address tuples 854 A0 and A3. This might be a problem for applications that are not 855 designed in a firewall-friendly way. An example is a FTP application 856 that uses the PORT command (instead of the recommended PASV command). 857 The problem only occurs when the middlebox offers twice-NAT 858 functionality and it can be fixed following recommendations for 859 firewall-friendly communication. 861 5.1.2. midcomGroupTable 863 The midcomGroupTable has an entry per existing policy rule group. 864 Entries of this table are created automatically when creating member 865 entries in the midcomRuleTable. Entries are automatically removed 866 from this table, when the last member entry is removed from the 867 midcomRuleTable. Entries cannot be created or removed explicitly by 868 the MIDCOM client. 870 Entries are indexed by the midcomRuleOwner of the rules that belong 871 to the group and by a specific midcomGroupIndex. This allows each 872 midcomRuleOwner to maintain its own independent group name space. 874 An entry of the table contains the following objects: 876 o midcomGroupIndex 877 The index of this entry must be unique in combination with the 878 midcomRuleOwner of the entry. 880 o midcomGroupLifetime 881 This object indicates the maximum of the remaining lifetimes of 882 all established policy rules that are members of the group. The 883 MIDCOM client can change the remaining lifetime of all member 884 policies by writing to this object. 886 5.2. Configuration Objects 888 The configuration subtree contains middlebox capability and 889 configuration information. Some of the contained objects are 890 (optionally) writable and can also be used for configuring the 891 middlebox service. 893 The capabilities subtree contains some general capability information 894 and detailed information per supported IP interface. The 895 midcomConfigFirewallTable can be used to configure how the MIDCOM MIB 896 implementation creates firewall rules in its firewall modules. 898 Note that typically, configuration objects are not intended to be 899 written by MIDCOM clients. In general, write access to these objects 900 needs to be restricted more strictly than write access to transaction 901 objects. 903 5.2.1. Capabilities 905 Information on middlebox capabilities, i.e. capabilities of the 906 MIDCOM MIB implementation, is provided by the midcomCapabilities 907 subtree of managed objects. The following objects are defined: 909 o midcomConfigMaxLifetime 910 This object indicates the maximum lifetime that this middlebox 911 allows policy rules to have. 913 o midcomConfigPersistentRules 914 This is a boolean object indicating whether or not the middlebox 915 is capable of storing policy rules persistently. 917 Further capabilities are provided by the midcomConfigIfTable per IP 918 interface. This table contains just two objects. The first one is a 919 BITS object called midcomConfigIfBits containing the following bit 920 values: 922 o ipv4 and ipv6 923 These two bit values provide information on which IP versions 924 are supported by the middlebox at the indexed interface. 926 o addressWildcards and portWildcards 927 These two bit values provide information on wildcarding 928 supported by the middlebox at the indexed interface. 930 o firewall and nat 931 These two bit values provide information on availability of 932 firewall and NAT functionality at the indexed interface. 934 o portTranslation, protocolTranslation, and twiceNat 935 These three bit values provide information on the kind of NAT 936 functionality available at the indexed interface. 938 o inside 939 This bit indicates whether or not the indexed interface is an 940 inside interface with respect to NAT functionality. 942 The second object called midcomConfigIfEnabled indicates whether or 943 not the middlebox capabilities described by midcomConfigIfBits are 944 available or not available at the indexed IP interface. 946 The midcomConfigIfTable uses index 0 for indicating capabilities that 947 are available for all interfaces. 949 5.2.2. midcomConfigFirewallTable 951 The midcomConfigFirewallTable serves for configuring how policy rules 952 created by MIDCOM clients are realized as firewall rules of a 953 firewall implementation. Particularly, the priority used for MIDCOM- 954 MIB policy rules can be configured. For a single firewall 955 implementation at a particular IP interface, all MIDCOM-MIB policy 956 rules are realized as firewall rules with the same priority. Also a 957 firewall rule group name can be configured. The table is indexed by 958 the IP interface index. 960 An entry of the table contains the following objects: 962 o midcomConfigFirewallGroupId 963 The firewall rule group to which all firewall rules of the 964 MIDCOM server are assigned. 966 o midcomConfigFirewallPriority 967 The priority assigned to all firewall rules of the MIDCOM 968 server. 970 5.3. Monitoring Objects 972 The monitoring objects are structured into two subtrees: the resource 973 subtree and the statistics subtree. The resource subtree provides 974 information about which resources are used by which policy rule. The 975 statistics subtree provide statistics about the usage of transaction 976 objects. 978 5.3.1. midcomResourceTable 980 Information about resource usage per policy rule is provided by the 981 midcomResourceTable. Each entry in the midcomResourceTable describes 982 resource usage of exactly one policy rule. 984 Resources are NAT resources and firewall resources, depending on the 985 type of middlebox. Used NAT resources include NAT bindings and NAT 986 sessions. NAT address mappings are not covered. For firewalls, 987 firewall filter rules are considered as resources. 989 The values provided by the following objects on NAT binds and NAT 990 sessions may refer to the detailed resource usage description in the 991 NAT-MIB module [RFC4008]. 993 The values provided by the following objects on firewall rules may 994 refer to more detailed firewall resource usage descriptions in other 995 MIB modules. 997 Entries in the midcomResourceTable are only valid if the 998 midcomRuleOperStatus object of the corresponding entry in the 999 midcomRuleTable has a value of either reserved(7) or enabled(8). 1001 An entry of the table contains the following objects: 1003 o midcomRscNatInternalAddrBindMode 1004 This object indicates whether the binding of the internal 1005 address is an address NAT binding or an address-port NAT 1006 binding. 1008 o midcomRscNatInternalAddrBindId 1009 This object identifies the NAT binding for the internal address 1010 in the NAT engine. 1012 o midcomRscNatExternalAddrBindMode 1013 This object indicates whether the binding of the external 1014 address is an address NAT binding or an address-port NAT 1015 binding. 1017 o midcomRscNatExternalAddrBindId 1018 This object identifies the NAT binding for the external address 1019 in the NAT engine. 1021 o midcomRscNatSessionId1 1022 This object links to the first NAT session associated with one 1023 of the above NAT bindings. 1025 o midcomRscNatSessionId2 1026 This object links to the optional second NAT session associated 1027 with one of the above NAT bindings. 1029 o midcomRscFirewallRuleId 1030 The firewall rule for this policy rule. 1032 The MIDCOM MIB module does not require a middlebox to implement 1033 further specific middlebox (NAT, firewall, etc.) MIB modules as, for 1034 example, the NAT MIB module [RFC4008]. 1036 The resource identifiers in midcomResourceTable may be vendor 1037 proprietary in the cases where the middlebox does not implement the 1038 NAT-MIB [RFC4008] or a firewall MIB. The MIDCOM MIB module affects 1039 NAT binding and sessions, as well as firewall pinholes. It is 1040 intentionally not specified in the MIDCOM MIB module how these NAT 1041 and firewall resources are allocated and managed, since this depends 1042 on the MIDCOM MIB implementation and middlebox's capabilities. 1043 However, the midcomResourceTable is useful for understanding which 1044 resources are affected by which MIDCOM MIB transaction. 1046 The midcomResourceTable is beneficial to the middlebox administrator 1047 in that the table lists all MIDCOM transactions and the middlebox 1048 specific resources these transactions refer to. For instance, 1049 multiple MIDCOM clients might end up using the same NAT Bind, yet 1050 each MIDCOM client might define a Lifetime parameter and 1051 directionality for the bind that is specific to the transaction. 1052 MIDCOM MIB implementations are responsible for impacting underlying 1053 middlebox resources so as to satisfy the sometimes overlapping 1054 requirements on the same resource from multiple MIDCOM clients. 1056 Managing these resources is not a trivial task for MIDCOM MIB 1057 implementers. It is possible that different MIDCOM-MIB policy rules 1058 owned by different MIDCOM clients share a NAT binding or a firewall 1059 rule. Then common properties, for example, the lifetime of the 1060 resource, need to be managed such that all clients are served well 1061 and changes to these resources need to be communicated to all 1062 affected clients. Also dependencies between resources, for example, 1063 the precedence order of firewall rules, need to be considered 1064 carefully in order to avoid that different policy rules - potentially 1065 owned by different clients - influence each other. 1067 MIDCOM clients may use the midcomResourceTable of the MIDCOM MIB 1068 module in conjunction with the NAT MIB module [RFC4008] to determine 1069 which resources of the NAT are used for MIDCOM. The NAT MIB module 1070 stores the configured NAT bindings and sessions and MIDCOM clients 1071 can use the information of the midcomResourceTable to sort out those 1072 NAT resources that are used by the MIDCOM MIB module. 1074 5.3.2. midcomStatistics 1076 The statistics subtree contains a set of non-columnar objects that 1077 provide 'MIDCOM protocol statistics' i.e. statistics about the usage 1078 of transaction objects. 1080 o midcomCurrentOwners 1081 This object indicates the number of different values for 1082 midcomRuleOwner for all current entries in the midcomRuleTable. 1084 o midcomOwnersTotal 1085 This object indicates the summarized number of all different 1086 values that occured for midcomRuleOwner in the midcomRuleTable 1087 current and in the past. 1089 o midcomTotalRejectedRuleEntries 1090 This object indicates the total number of failed attempts to 1091 create an entry in the midcomRuleTable. 1093 o midcomCurrentRulesIncomplete 1094 This object indicates the total number of policy rules that have 1095 not been fully loaded into a table row of the midcomRuleTable. 1097 o midcomTotalIncorrectReserveRules 1098 This object indicates the total number of policy reserve rules 1099 that were rejected because the request was incorrect. 1101 o midcomTotalRejectedReserveRules 1102 This object indicates the total number of policy reserve rules 1103 that were failed while being processed. 1105 o midcomCurrentActiveReserveRules 1106 This object indicates the number of currently active policy 1107 reserve rules in the midcomRuleTable. 1109 o midcomTotalExpiredReserveRules 1110 This object indicates the total number of expired policy reserve 1111 rules. 1113 o midcomTotalTerminatedOnRqReserveRules 1114 This object indicates the total number of policy reserve rules 1115 that were terminated on request. 1117 o midcomTotalTerminatedReserveRules 1118 This object indicates the total number of policy reserve rules 1119 that were terminated, but not on request. 1121 o midcomTotalIncorrectEnableRules 1122 This object indicates the total number of policy enable rules 1123 that were rejected because the request was incorrect. 1125 o midcomTotalRejectedEnableRules 1126 This object indicates the total number of policy enable rules 1127 that were failed while being processed. 1129 o midcomCurrentActiveEnableRules 1130 This object indicates the number of currently active policy 1131 enable rules in the midcomRuleTable. 1133 o midcomTotalExpiredEnableRules 1134 This object indicates the total number of expired policy enable 1135 rules. 1137 o midcomTotalTerminatedOnRqEnableRules 1138 This object indicates the total number of policy enable rules 1139 that were terminated on request. 1141 o midcomTotalTerminatedEnableRules 1142 This object indicates the total number of policy enable rules 1143 that were terminated, but not on request. 1145 5.4. Notifications 1147 For informing MIDCOM clients about state changes of MIDCOM-MIB 1148 implementations, three notifications can be used. They notify the 1149 MIDCOM client about state changes of individual policy rules or of 1150 groups of policy rules, respectively. Different notifications are 1151 used for different kinds of transactions. 1153 For asynchronous transactions unsolicited notifications are used. 1154 The only asynchronous transaction that needs to be modeled by the 1155 MIDCOM-MIB is the Asynchronous Policy Rule Event (ARE). The ARE may 1156 be caused by the expiration of a policy rule lifetime, the expiration 1157 of the idle time or due to an internal change in policy rule lifetime 1158 by the MIDCOM-MIB implementation for whatever reason. 1160 For configuration transactions solicited notifications are used. 1161 This concerns the Policy Reserve Rule (PRR) transaction, the Policy 1162 Enable Rule (PER) transaction, the Policy Rule Lifetime Change (RLC) 1163 transaction, and the Group Lifetime Change (GLC) transaction. 1165 The separation between unsolicited and solicited notifications gives 1166 the implementer of a MIDCOM client some freedom to make design 1167 decisions on how to model the MIDCOM reply message as described at 1168 the end of section 4.2.2. Depending on the choice, processing of 1169 solicited notifications may not be required. In such a case, 1170 delivery of solicited notification may be disabled, for example, by 1171 an appropriate configuration of the snmpNotifyFilterTable such that 1172 solicited notifications are filtered differently to unsolicited 1173 notifications. 1175 o midcomUnsolicitedRuleEvent 1176 This notification can be generated for indicating the change of 1177 a policy rule's state or lifetime. It is used for performing 1178 the ARE transaction. 1180 o midcomSolicitedRuleEvent 1181 This notification can be generated for indicating the requested 1182 change of a policy rule's state or lifetime. It is used for 1183 performing PRR, PER and RLC transactions. 1185 o midcomSolicitedGroupEvent 1186 This notification can be generated for indicating the requested 1187 change of a policy rule group's lifetime. It is used for 1188 performing the GLC transaction. 1190 6. Recommendations for Configuration and Operation 1192 Configuring MIDCOM-MIB security is highly sensitive for obvious 1193 reasons. This section gives recommendations for securely configuring 1194 the SNMP agent acting as MIDCOM server. In addition, recommendations 1195 for avoiding idempotency problems are given and restrictions of 1196 MIDCOM-MIB applicabiltiy to a special set of applications is 1197 discussed. 1199 6.1. Security Model Configuration 1201 Since controlling firewalls and NATs is highly sensitive, it is 1202 RECOMMENDED that SNMP Command Responders implementing the MIDCOM-MIB 1203 module use the authPriv security level for all users that may access 1204 managed objects of the MIDCOM-MIB module. 1206 6.2. VACM Configuration 1208 Entries in the midcomRuleTable and the midcomGroupTable provide 1209 information about existing firewall pinholes and/or NAT sessions. 1210 They also could be used for manipulating firewall pinholes and/or NAT 1211 sessions. Therefore access control to these objects is essential and 1212 should be restrictive. 1214 It is RECOMMENDED that SNMP Command Responders instantiating an 1215 implementation of the MIDCOM-MIB module use VACM for controlling 1216 access to managed objects in the midcomRuleTable and the 1217 midcomGroupTable. 1219 It is further RECOMMENDED, that individual MIDCOM clients, acting as 1220 SNMP Command Generators, only have access to an entry in the 1221 midcomRuleTable, the midcomResourceTable, or the midcomGroupTable, if 1222 they created the entry directly in the midcomRuleTable or indirectly 1223 in the midcomGroupTable and midcomResourceTable. Exceptions to this 1224 recommendation are situations where access by multiple MIDCOM clients 1225 to managed objects is explicitly required. One example is fail-over 1226 for MIDCOM agents where the stand-by MIDCOM agent needs the same 1227 access rights to managed objects as the currently active MIDCOM 1228 agent. Another example is a supervisor MIDCOM agent that monitors 1229 activities of other MIDCOM agents and/or may be used by network 1230 management systems to modify entries in tables of the MIDCOM-MIB. 1232 For this reason, all three tables listed above have the 1233 midcomRuleOwner as initial index. It is RECOMMENDED that MIDCOM 1234 clients acting as SNMP Command Generator have access to the 1235 midcomRuleTable and the midcomGroupTable restricted to entries with 1236 the initial index matching either their SNMP securityName or their 1237 VACM groupName. It is RECOMMENDED that they do not have access to 1238 entries in these tables with initial indices other than their SNMP 1239 securityName or their VACM groupName. It is RECOMMENDED that this 1240 VACM configuration is applied to read access, write access, and 1241 notify access for all objects in the midcomRuleTable and the 1242 midcomGroupTable. 1244 Note that less restrictive access right MAY be granted to other 1245 users, for example, to a network management application, that 1246 monitors MIDCOM policy rules. 1248 6.3. Notification Configuration 1250 For each MIDCOM client that has access to the midcomRuleTable, a 1251 notification target SHOULD be configured at a Command Responder 1252 instantiating an implementation of the MIDCOM-MIB. It is RECOMMENDED 1253 that such a configuration be retrievable from the Command Responder 1254 via the SNMP-TARGET-MIB [RFC3413]. 1256 For each entry of the snmpTargetAddrTable that is related to a MIDCOM 1257 client, there SHOULD be an individual corresponding entry in the 1258 snmpTargetParamsTable. 1260 An implementation of the MIDCOM-MIB SHOULD also implement the SNMP- 1261 NOTIFICATION-MIB [RFC3413]. An instance of an implementation of the 1262 MIDCOM-MIB SHOULD have an individual entry in the 1263 snmpNotifyFilterProfileTable for each MIDCOM client that has access 1264 to the midcomRuleTable. 1266 An instance of an implementation of the MIDCOM-MIB SHOULD allow 1267 MIDCOM clients to start and stop the generation of notifications 1268 targeted at themselves. This SHOULD be realized by giving the MIDCOM 1269 clients write access to the snmpNotifyFilterTable. If appropriate 1270 entries of the snmpNotifyFilterTable are established in advance, then 1271 this can be achieved by granting MIDCOM clients write access only to 1272 the columnar object snmpNotifyFilterType. 1274 It is RECOMMENDED that VACM is configured such that each MIDCOM agent 1275 can only access entries in the snmpTargetAddrTable, the 1276 snmpTargetParamsTable, the snmpNotifyFilterProfileTable, and the 1277 snmpFilterTable that concern that particular MIDCOM agent. 1278 Typically, read access to the snmpTargetAddrTable, the 1279 snmpTargetParamsTable, and the snmpNotifyFilterProfileTable is 1280 sufficient. Write access may be required for objects of the 1281 snmpFilterTable. 1283 6.4. Simultaneous Access 1285 Situations with two MIDOCM clients simultaneously modifying the same 1286 policy rule should be avoided. For each entry in the midcomRuleTable 1287 there should be only one client at a time that modifies it. If two 1288 MIDCOM clients share the same midcomRuleOwner index of the 1289 midcomRuleTable, then conflicts can be avoided, for example, by 1290 - scheduling access times, as for example in the fail-over case, 1291 - using different midcomGroupIndex values per client, or 1292 - using non overlapping intervals for values of the 1293 midcomRuleIndex per client. 1295 6.5. Avoiding Idempotency Problems 1297 As already discussed in section 4.2.4.4, the following recommendation 1298 is given for avoiding idempotency problems. 1300 In general, idempotency problems can be solved by including 1301 snmpSetSerialNo (see [RFC3418]) in SNMP SET requests. 1303 In case this feature is not used, it is RECOMMENDED that the value of 1304 the SNMP retransmission timer of a MIDCOM client (acting as SNMP 1305 Command Generator) is lower than the smallest requested value for any 1306 rule lifetime or rule idle time in order to prevent idempotency 1307 problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime 1308 when retransmitting an SNMP SET request after a lost SNMP reply. 1310 MIDCOM client implementations MAY completely avoid this problem by 1311 configuring their SNMP stack such that no retransmissions are sent. 1313 Similar considerations apply to MIDOM-MIB implementations acting as 1314 Notification Originator when sending a notification 1315 (midcomUnsolicitedRuleEvent, midcomSolicitedRuleEvent or 1316 midcomSolicitedGroupEvent) containing the remaining lifetime of a 1317 policy rule or a policy rule group, respectively. 1319 6.6. Interface Indexing Problems 1321 A well known problem of MIB modules is indexing IP interfaces after a 1322 re-initialization of the managed device. The index for interfaces 1323 provided by the ifTable (see IF-MIB in RFC2863) may change during re- 1324 initialization, for example, when physical interfaces are added or 1325 removed. 1327 The MIDCOM MIB module uses the interface index for indicating at 1328 which interface which policy rule is (or is to be) applied. Also 1329 this index is used for indicating how policy rules are prioritized at 1330 certain interfaces. The MIDCOM MIB module specification requires 1331 that information provided is always correct. This implies that after 1332 re-initialization interface index values of policy rules or firewall 1333 configurations may have changed even though they still refer to the 1334 same interface as before the re-initialization. 1336 MIDCOM client implementation need to be aware of this potential 1337 behavior. It is RECOMMENDED that before writing the value or using 1338 the value of indices that depend on the ifTable, that the MIDCOM 1339 client checks if the middlebox has been re-initialized recently. 1341 MIDCOM MIB module implementations MUST track interface changes of IP 1342 interface indices in the ifTable. This implies that after a re- 1343 initialization of a middlebox, a MIDCOM MIB implementation MUST make 1344 sure that each instance of an interface index in the MIDCOM MIB 1345 tables, still points to the same interface as before the re- 1346 initialization. For any instance for which this is not possible, all 1347 affected entries in tables of the MIDCOM MIB module MUST be either 1348 terminated, disabled, or deleted, as specified in the DESCRIPTION 1349 clause of the respective object. This concerns all objects in the 1350 MIDCOM MIB module that are of type InterfaceIndexOrZero. 1352 6.7. Applicability Restrictions 1354 As already discussed in section 5.1.1, the MIDCOM-MIB requires the 1355 MIDCOM client to specify address tuples A0 and A3. This can be a 1356 problem for applications that do not have this information available 1357 when they need to configure the middlebox. For some applications 1358 there are usage scenarios where address information is only available 1359 for a single address realm, A0 and A1 in the private realm or A2 and 1360 A3 in the public realm. An example is a FTP application using the 1361 PORT command (instead of the PASV command). The problem occurs when 1362 the middlebox offers twice-NAT functionality. 1364 7. Usage Examples for MIDCOM Transactions 1366 This section presents some examples that explain how a MIDCOM client 1367 acting as SNMP manager can use the MIDCOM MIB module defined in this 1368 memo. The purpose of these examples is to explain the steps that are 1369 required to perform MIDCOM transactions. For each MIDCOM transaction 1370 defined in the MIDCOM semantics [I-D.ietf-midcom-rfc3989-bis], a 1371 sequence of SNMP operations which realizes the transaction is 1372 described. 1374 The examples described below are recommended procedures for MIDCOM 1375 clients. Clients may choose to operate differently. 1377 For example, they may choose not to receive solicited notifications 1378 on completion of a transaction, but to poll the MIDCOM-MIB instead 1379 until the transaction is completed. This can be achieved by 1380 performing step 2 of the SE transaction (see below) differently. The 1381 MIDCOM agent then creates an entry in the snmpNotifyFilterTable such 1382 that only the midcomUnsolicitedRuleEvent may pass the filter and is 1383 sent to the MIDCOM client. In this case, the PER, PRR, and RLC 1384 transactions require a polling loop wherever in the example below the 1385 MIDCOM client waits for a notification. 1387 7.1. Session Establishment (SE) 1389 The MIDCOM-MIB realizes most properties of MIDCOM sessions in a very 1390 static way. Only the generation of notifications targeted at the 1391 MIDCOM client is enabled by the client for session establishment. 1393 1. The MIDCOM client checks the middlebox capabilities by reading 1394 objects in the midcomCapabilitiesGroup. 1396 2. The MIDCOM client enables generation of notifications on events 1397 concerning the policy rules controlled by the client. If the 1398 SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3 1399 of this document, then the agent just has to change the value of a 1400 object snmpNotifyFilterType in the corresponding entry of the 1401 snmpNotifyFilterTable from included(1) to excluded(2). 1403 7.2. Session Termination (ST) 1405 For terminating a session, the MIDCOM client just disables the 1406 generation of notifications for this client. 1408 1. The MIDCOM client disables generation of notifications on events 1409 concerning the policy rules controlled by the client. If the 1410 SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3 1411 of this document, then the agent just has to change the value of a 1412 object snmpNotifyFilterType in the corresponding entry of the 1413 snmpNotifyFilterTable from included(1) to excluded(2). 1415 7.3. Policy Reserve Rule (PRR) 1417 This example explains steps that may be performed by a MIDCOM client 1418 to establish a policy reserve rule. 1420 1. The MIDCOM client creates a new entry in the midcomRuleTable by 1421 writing to midcomRuleRowStatus. The chosen value for index object 1422 midcomGroupIndex determines the group membership of the created 1423 rule. Note that choosing an unused value for midcomGroupIndex 1424 creates a new entry in the midcomGroupTable. 1426 2. The MIDCOM client sets the following objects in the new entry of 1427 the midcomRuleTable to specify all request parameters of the PRR 1428 transaction: 1429 - midcomRuleMaxIdleTime 1430 - midcomRuleInterface 1431 - midcomRuleTransportProtocol 1432 - midcomRulePortRange 1433 - midcomRuleInternalIpVersion 1434 - midcomRuleExternalIpVersion 1435 - midcomRuleInternalIpAddr 1436 - midcomRuleInternalIpPrefixLength 1437 - midcomRuleInternalPort 1438 - midcomRuleLifetime 1439 Note, that several of these parameters have default values that 1440 can be used. 1442 3. The MIDCOM client sets the midcomRuleAdminStatus objects in the 1443 new row of the midcomRuleTable to reserve(1). 1445 4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification 1446 concerning the new policy rule in the midcomRuleTable. Waiting 1447 for the notification is timed out after a pre-selected maximum 1448 waiting time. In case of a timeout while waiting for the 1449 notification or if the client does not use notifications, the 1450 MIDCOM client retrieves the status of the midcomRuleEntry by one 1451 or more SNMP get operation. 1453 5. After receiving the midcomSolicitedRuleEvent notification MIDCOM 1454 client checks the lifetime value carried by the notification. If 1455 it is greater than 0, the MIDCOM client reads all positive reply 1456 parameters of the PRR transaction: 1457 - midcomRuleOutsideIpAddr 1458 - midcomRuleOutsidePort 1459 - midcomRuleMaxIdleTime 1460 - midcomRuleLifetime 1462 If the lifetime equals 0, then MIDCOM client reads the 1463 midcomRuleOperStatus and the midcomRuleError in order to analyze 1464 the failure reason. 1466 6. Optionally, after receiving the midcomSolicitedRuleEvent 1467 notification with a lifetime value greater than 0 the MIDCOM 1468 client may check midcomResourceTable for the middlebox resources 1469 allocated for this policy reserve rule. Note that PRR does not 1470 necessarily allocate any middlebox resource visible in the NAT MIB 1471 module or in a firewall MIB module, since it does a reservation 1472 only. If however, the PRR overlaps with already existing PERs, 1473 then the PRR may be related to middlebox resources visible in 1474 other MIB modules. 1476 7.4. Policy Enable Rule (PER) after PRR 1478 This example explains steps that may be performed by a MIDCOM client 1479 to establish a policy enable rule after a corresponding policy 1480 reserve rule was already established. 1482 1. The MIDCOM client sets the following objects in the row of the 1483 established PRR in the midcomRuleTable to specify all request 1484 parameters of the PER transaction: 1485 - midcomRuleMaxIdleTime 1486 - midcomRuleExternalIpAddr 1487 - midcomRuleExternalIpPrefixLength 1488 - midcomRuleExternalPort 1489 - midcomRuleFlowDirection 1490 Note, that several of these parameters have default values that 1491 can be used. 1493 2. The MIDCOM client sets the midcomRuleAdminStatus objects in the 1494 row of the established PRR in the midcomRuleTable to enable(1). 1496 3. The MIDCOM client awaits a midcomSolicitedRuleEvent notification 1497 concerning the new row in the midcomRuleTable. Waiting for the 1498 notification is timed out after a pre-selected maximum waiting 1499 time. In case of a timeout while waiting for the notification or 1500 if the client does not use notifications, the MIDCOM client 1501 retrieves the status of the midcomRuleEntry by one or more SNMP 1502 get operation. 1504 4. After receiving the midcomSolicitedRuleEvent notification, the 1505 MIDCOM client checks the lifetime value carried by the 1506 notification. If it is greater than 0, the MIDCOM client reads 1507 all positive reply parameters of the PER transaction: 1508 - midcomRuleInsideIpAddr 1509 - midcomRuleInsidePort 1510 - midcomRuleMaxIdleTime 1512 If the lifetime equals 0, then the MIDCOM client reads the 1513 midcomRuleOperStatus and the midcomRuleError in order to analyze 1514 the failure reason. 1516 5. Optionally, after receiving the midcomSolicitedRuleEvent 1517 notification with a lifetime value greater than 0 the MIDCOM 1518 client may check midcomResourceTable for the allocated middlebox 1519 resources for this policy enable rule. 1521 7.5. Policy Enable Rule (PER) without previous PRR 1523 This example explains steps that may be performed by a MIDCOM client 1524 to establish a policy enable rule for which no PRR transaction has 1525 been performed before. 1527 1. Identical to step 1 for PRR (section 7.3). 1529 2. Identical to step 2 for PRR (section 7.3). 1531 3. The MIDCOM client sets the following objects in the new row of the 1532 midcomRuleTable to specify all request parameters of the PER 1533 transaction: 1534 - midcomRuleInterface 1535 - midcomRuleFlowDirection 1536 - midcomRuleTransportProtocol 1537 - midcomRulePortRange 1538 - midcomRuleInternalIpVersion 1539 - midcomRuleExternalIpVersion 1540 - midcomRuleInternalIpAddr 1541 - midcomRuleInternalIpPrefixLength 1542 - midcomRuleInternalPort 1543 - midcomRuleExternalIpAddr 1544 - midcomRuleExternalIpPrefixLength 1545 - midcomRuleExternalPort 1546 - midcomRuleLifetime 1547 Note, that several of these parameters have default values that 1548 can be used. 1550 4. The MIDCOM client sets the midcomRuleAdminStatus objects in the 1551 new row of the midcomRuleTable to enable(1). 1553 5. Identical to step 4 for PRR (section 7.3). 1555 6. After receiving the midcomSolicitedRuleEvent notification MIDCOM 1556 client checks the lifetime value carried by the notification. If 1557 it is greater than 0, the MIDCOM client reads all positive reply 1558 parameters of the PRR transaction: 1559 - midcomRuleInsideIpAddr 1560 - midcomRuleInsidePort 1561 - midcomRuleOutsideIpAddr 1562 - midcomRuleOutsidePort 1563 - midcomRuleMaxIdleTime 1565 If the lifetime equals 0, then MIDCOM client reads the 1566 midcomRuleOperStatus and the midcomRuleError in order to analyze 1567 the failure reason. 1569 7. Optionally, after receiving the midcomSolicitedRuleEvent 1570 notification with a lifetime value greater than 0 the MIDCOM 1571 client may check midcomResourceTable for the allocated middlebox 1572 resources for this policy enable rule. 1574 7.6. Policy Rule Lifetime Change (RLC) 1576 This example explains steps that may be performed by a MIDCOM client 1577 to change the lifetime of a policy rule. Changing the lifetime to 0 1578 implies terminating the policy rule. 1580 1. The MIDCOM client issues a set-request for writing the desired 1581 lifetime to the midcomRuleLifetime object in the corresponding row 1582 of the midcomRuleTable. This does not have any effect if the 1583 lifetime is already expired. 1585 2. The MIDCOM client awaits a midcomSolicitedRuleEvent notification 1586 concerning the corresponding row in the midcomRuleTable. Waiting 1587 for the notification is timed out after a pre-selected maximum 1588 waiting time. In case of a timeout while waiting for the 1589 notification or if the client does not use notifications, the 1590 MIDCOM client retrieves the status of the midcomRuleEntry by one 1591 or more SNMP get operation. 1593 3. After receiving the midcomSolicitedRuleEvent notification MIDCOM 1594 client checks the lifetime value carried by the notification. 1596 7.7. Policy Rule List (PRL) 1598 The SNMP agent can browse the list of policy rules by browsing the 1599 midcomRuleTable. For each observed row in this table, the SNMP agent 1600 should check the midcomRuleOperStatus in order to find out, if the 1601 row contains information about an established policy rule or of a 1602 rule that is under construction or already terminated. 1604 7.8. Policy Rule Status (PRS) 1606 The SNMP agent can retrieve all status information and properties of 1607 a policy rule by reading the managed objects in the corresponding row 1608 of the midcomRuleTable. 1610 7.9. Asynchronous Policy Rule Event (ARE) 1612 There are two different triggers for the ARE event. It may be 1613 triggered by the expiration of a policy rule's lifetime or the 1614 expiration of the idle time. But beyond this, the MIDCOM MIB 1615 implementation may terminate a policy rule at any time. In all cases 1616 two steps are required for performing this transaction: 1618 1. The MIDCOM MIB implementation sends a midcomUnsolicitedRuleEvent 1619 notification containing a lifetime value of 0 to the MIDCOM client 1620 owning the rule. 1622 2. If the midcomRuleStorageTime object in the corresponding row of 1623 the midcomRuleTable has a value of 0 then the MIDCOM MIB 1624 implementation removes the row from the table. Otherwise, it sets 1625 in this row the midcomRuleLifetime object to 0 and changes the 1626 midcomRuleOperStatus object. If the event was triggered by policy 1627 lifetime expiration, then the midcomRuleOperStatus is set to 1628 timedOut(9), otherwise, it is set to terminated(11). 1630 7.10. Group Lifetime Change (GLC) 1632 This example explains steps that may be performed by a MIDCOM client 1633 to change the lifetime of a policy rule group. Changing the lifetime 1634 to 0 implies terminating all member policies of the group. 1636 1. The MIDCOM client issues a set-request for writing the desired 1637 lifetime to the midcomGroupLifetime object in the corresponding 1638 row of the midcomGroupTable. 1640 2. The MIDCOM client waits for a midcomSolicitedGroupEvent 1641 notification concerning the corresponding row in the 1642 midcomGroupTable. Waiting for the notification is timed out after 1643 a pre-selected maximum waiting time. In case of a timeout while 1644 waiting for the notification or if the client does not use 1645 notifications, the MIDCOM client retrieves the status of the 1646 midcomGroupEntry by one or more SNMP get operation. 1648 3. After receiving the midcomSolicitedRuleEvent notification MIDCOM 1649 client checks the lifetime value carried by the notification. 1651 7.11. Group List (GL) 1653 The SNMP agent can browse the list of policy rule groups by browsing 1654 the midcomGroupTable. For each observed row in this table, the SNMP 1655 agent should check the midcomGroupLifetime in order to find out, if 1656 the group does contain established policies. 1658 7.12. Group Status (GS) 1660 The SNMP agent can retrieve all member policies of a group by 1661 browsing the midcomRuleTable using the midcomGroupIndex of the 1662 particular group. For retrieving the remaining lifetime of the 1663 group, the SNMP agent reads the midcomGroupLifetime object in the 1664 corresponding row of the midcomGroupTable. 1666 8. Usage Examples for Monitoring Objects 1668 This section presents some examples that explain how a MIDCOM client 1669 can use the midcomResourceTable to correlate policy rules with the 1670 used middlebox resources. One example is given for middleboxes 1671 implementing the NAT MIB and another one is given for firewalls. 1673 8.1. Monitoring NAT Resources 1675 When a rule in midcomRuleTable is executed, it directly impacts the 1676 middlebox resources. The midcomResourceTable provides the 1677 information on the relationships between the MIDCOM-MIB policy rules 1678 and the middlebox resources used for enforcing these rules. 1680 A MIDCOM-MIB policy rule will cause the creation or modification of 1681 up to two NAT bindings and up to two NAT sessions. Two NAT bindings 1682 are impacted in the case of a session being subject to twice-NAT. 1683 Two NAT bindings may also be impacted when midcomRulePortRange is set 1684 to pair(2) in the policy rule. In the majority of cases, where 1685 traditional NAT is implemented, only a single NAT binding may be 1686 adequate. Note, however, this BindId is set to 0 if the middlebox is 1687 implementing symmetric NAT function. Two NAT sessions are created or 1688 modified only when midcomRulePortRange is set to pair(2) in the 1689 policy rule. 1691 When support for the NAT MIB module is also available at the 1692 middlebox, the parameters in the combination of midcomRuleTable and 1693 the midcomResourceTable for a given rule can be used to index the 1694 corresponding BIND and NAT session resources effected in the NAT MIB. 1695 These parameters are valuable to monitor the impact on the NAT 1696 module, even when the NAT MIB module is not implemented at the 1697 middlebox. 1699 The impact of MIDCOM rules on the NAT resources is important because 1700 a MIDCOM rule can not only create BINDs and NAT sessions, but is also 1701 capable of modifying the NAT objects that already exist. For 1702 example, FlowDirection, and MaxIdleTime parameters in a MIDCOM rule 1703 directly effect the TranslationEntity and MaxIdleTime of the 1704 associated NAT bind object. Likewise, MaxIdleTime in a MIDCOM rule 1705 has a direct impact on the MaxIdleTime of the associated NAT session 1706 object. The lifetime parameter in the MIDCOM rule directly impacts 1707 the lifetime of all the impacted NAT BIND and NAT session objects. 1709 8.2. Monitoring Firewall Resources 1711 When a MIDCOM-MIB policy rule is established at a middlebox with 1712 firewall capabilities, this may lead to the creation of one or more 1713 new firewall rules. Note that in general a single firewall rule per 1714 MIDCOM-MIB policy rule will be sufficient. For each policy rule, a 1715 MIDCOM client can explore the corresponding firewall filter rule by 1716 reading the midcomResourceEntry in the midcomResourceTable that 1717 corresponds to the midcomRuleEntry describing the rule. The 1718 identification of the firewall filter rule is stored in object 1719 midcomRscFirewallRuleId. The value of midcomRscFirewallRuleId may 1720 correspond directly to any firewall filter rule number or to an entry 1721 in a locally available firewall MIB module. 1723 9. Definitions 1725 The following MIB module imports from [RFC2578], [RFC2579], 1726 [RFC2580], [RFC2863], [RFC3411], [RFC4001], and [RFC4008]. 1728 MIDCOM-MIB DEFINITIONS ::= BEGIN 1730 IMPORTS 1731 MODULE-IDENTITY, OBJECT-TYPE, 1732 NOTIFICATION-TYPE, Unsigned32, 1733 Counter32, Gauge32, mib-2 1734 FROM SNMPv2-SMI -- RFC2578 1736 TEXTUAL-CONVENTION, TruthValue, 1737 StorageType, RowStatus 1738 FROM SNMPv2-TC -- RFC2579 1740 MODULE-COMPLIANCE, OBJECT-GROUP, 1741 NOTIFICATION-GROUP 1742 FROM SNMPv2-CONF -- RFC2580 1744 SnmpAdminString 1745 FROM SNMP-FRAMEWORK-MIB -- RFC3411 1747 InetAddressType, InetAddress, 1748 InetPortNumber, 1749 InetAddressPrefixLength 1750 FROM INET-ADDRESS-MIB -- RFC4001 1752 InterfaceIndexOrZero 1753 FROM IF-MIB -- RFC2863 1755 NatBindIdOrZero 1756 FROM NAT-MIB; -- RFC4008 1758 midcomMIB MODULE-IDENTITY 1759 LAST-UPDATED "200708091011Z" -- August 09, 2007 1760 ORGANIZATION "IETF Middlebox Communication Working Group" 1761 CONTACT-INFO 1762 "WG charter: 1763 http://www.ietf.org/html.charters/midcom-charter.html 1765 Mailing Lists: 1766 General Discussion: midcom@ietf.org 1767 To Subscribe: midcom-request@ietf.org 1768 In Body: subscribe your_email_address 1770 Co-editor: 1771 Juergen Quittek 1772 NEC Europe Ltd. 1774 Network Laboratories 1775 Kurfuersten-Anlage 36 1776 69115 Heidelberg 1777 Germany 1778 Tel: +49 6221 4342-115 1779 Email: quittek@netlab.nec.de 1781 Co-editor: 1782 Martin Stiemerling 1783 NEC Europe Ltd. 1784 Network Laboratories 1785 Kurfuersten-Anlage 36 1786 69115 Heidelberg 1787 Germany 1788 Tel: +49 6221 4342-113 1789 Email: stiemerling@netlab.nec.de 1791 Co-editor: 1792 P. Srisuresh 1793 Caymas Systems, Inc. 1794 1179-A North McDowell Blvd. 1795 Petaluma, CA 94954 1796 USA 1797 Tel: +1 707 283-5063 1798 Email: srisuresh@yahoo.com" 1800 DESCRIPTION 1801 "This MIB module defines a set of basic objects for 1802 configuring middleboxes, such as firewalls and network 1803 address translators, in order to enable communication 1804 across these devices. 1806 Managed objects defined in this MIB module are structured 1807 in three kinds of objects: 1808 - transaction objects required according to the MIDCOM 1809 protocol requirements defined in RFC 3304 and according 1810 to the MIDCOM protocol semantics defined in RFC 3989, 1811 - configuration objects that can be used for retrieving or 1812 setting parameters of the implementation of transaction 1813 objects, 1814 - optional monitoring objects that provide information 1815 about used resource and statistics 1817 The transaction objects, are organized in two subtrees: 1818 - objects modeling MIDCOM policy rules in the 1819 midcomRuleTable 1820 - objects modeling MIDCOM policy rule groups in the 1821 midcomGroupTable 1823 Note that typically, configuration objects are not intended 1824 to be written by MIDCOM clients. In general, write access 1825 to these objects needs to be restricted more strictly than 1826 write access to objects in the transaction subtrees. 1828 Copyright (C) The Internet Society (2006). This version 1829 of this MIB module is part of RFC yyyy; see the RFC 1830 itself for full legal notices." 1831 -- RFC Ed.: replace yyyy with actual RFC number & remove this notice 1833 REVISION "200708091011Z" -- August 09, 2007 1834 DESCRIPTION "Initial version, published as RFC yyyy." 1835 -- RFC Ed.: replace yyyy with actual RFC number and 1836 -- remove this notice 1838 ::= { mib-2 xxxxx } 1839 -- RFC Ed.: replace xxxxx with IANA-assigned number and 1840 -- remove this note 1842 -- 1843 -- main components of this MIB module 1844 -- 1846 midcomNotifications OBJECT IDENTIFIER ::= { midcomMIB 0 } 1847 midcomObjects OBJECT IDENTIFIER ::= { midcomMIB 1 } 1848 midcomConformance OBJECT IDENTIFIER ::= { midcomMIB 2 } 1850 -- Transaction objects required according to the MIDCOM 1851 -- protocol requirements defined in RFC 3304 and according to 1852 -- the MIDCOM protocol semantics defined in RFC 3989 1853 midcomTransaction OBJECT IDENTIFIER ::= { midcomObjects 1 } 1855 -- Configuration objects that can be used for retrieving 1856 -- middlebox capability information (mandatory) and for 1857 -- setting parameters of the implementation of transaction 1858 -- objects (optional) 1859 midcomConfig OBJECT IDENTIFIER ::= { midcomObjects 2 } 1861 -- Optional monitoring objects that provide information about 1862 -- used resource and statistics 1863 midcomMonitoring OBJECT IDENTIFIER ::= { midcomObjects 3 } 1865 -- 1866 -- Transaction Objects 1867 -- 1868 -- Transaction objects are structured according to the MIDCOM 1869 -- protocol semantics into two groups: 1870 -- - the policy rules group containing objects that model 1871 -- policy rules, and 1872 -- - the group group containing objects modeling policy rule 1873 -- groups. 1875 -- 1876 -- Policy rule subtree 1877 -- 1878 -- The midcomRuleTable lists policy rules 1879 -- including policy reserve rules and policy enable rules. 1880 -- 1882 midcomRuleTable OBJECT-TYPE 1883 SYNTAX SEQUENCE OF MidcomRuleEntry 1884 MAX-ACCESS not-accessible 1885 STATUS current 1886 DESCRIPTION 1887 "This table lists policy rules. 1889 It is indexed by the midcomRuleOwner, the 1890 midcomGroupIndex and the midcomRuleIndex. 1891 This implies that a rule is member of exactly 1892 one group and that group membership cannot 1893 be changed. 1895 Entries can be deleted by writing to 1896 midcomGroupLifetime or midcomRuleLifetime 1897 and potentially also to midcomRuleStorageTime." 1898 ::= { midcomTransaction 3 } 1900 midcomRuleEntry OBJECT-TYPE 1901 SYNTAX MidcomRuleEntry 1902 MAX-ACCESS not-accessible 1903 STATUS current 1904 DESCRIPTION 1905 "An entry describing a particular MIDCOM policy rule." 1906 INDEX { midcomRuleOwner, midcomGroupIndex, midcomRuleIndex } 1907 ::= { midcomRuleTable 1 } 1909 MidcomRuleEntry ::= SEQUENCE { 1910 midcomRuleOwner SnmpAdminString, 1911 midcomRuleIndex Unsigned32, 1912 midcomRuleAdminStatus INTEGER, 1913 midcomRuleOperStatus INTEGER, 1914 midcomRuleStorageType StorageType, 1915 midcomRuleStorageTime Unsigned32, 1916 midcomRuleError SnmpAdminString, 1917 midcomRuleInterface InterfaceIndexOrZero, 1918 midcomRuleFlowDirection INTEGER, 1919 midcomRuleMaxIdleTime Unsigned32, 1920 midcomRuleTransportProtocol Unsigned32, 1921 midcomRulePortRange INTEGER, 1922 midcomRuleInternalIpVersion InetAddressType, 1923 midcomRuleExternalIpVersion InetAddressType, 1924 midcomRuleInternalIpAddr InetAddress, 1925 midcomRuleInternalIpPrefixLength InetAddressPrefixLength, 1926 midcomRuleInternalPort InetPortNumber, 1927 midcomRuleExternalIpAddr InetAddress, 1928 midcomRuleExternalIpPrefixLength InetAddressPrefixLength, 1929 midcomRuleExternalPort InetPortNumber, 1930 midcomRuleInsideIpAddr InetAddress, 1931 midcomRuleInsidePort InetPortNumber, 1932 midcomRuleOutsideIpAddr InetAddress, 1933 midcomRuleOutsidePort InetPortNumber, 1934 midcomRuleLifetime Unsigned32, 1935 midcomRuleRowStatus RowStatus 1936 } 1938 midcomRuleOwner OBJECT-TYPE 1939 SYNTAX SnmpAdminString (SIZE (0..32)) 1940 MAX-ACCESS not-accessible 1941 STATUS current 1942 DESCRIPTION 1943 "The manager who owns this row in the midcomRuleTable. 1945 This object SHOULD uniquely identify an authenticated 1946 MIDCOM client. This object is part of the table index to 1947 allow for the use of the SNMPv3 View-Based Access Control 1948 Model (RFC 3415, VACM)." 1949 ::= { midcomRuleEntry 1 } 1951 midcomRuleIndex OBJECT-TYPE 1952 SYNTAX Unsigned32 (1..4294967295) 1953 MAX-ACCESS not-accessible 1954 STATUS current 1955 DESCRIPTION 1956 "The value of this object must be unique in 1957 combination with the values of the objects 1958 midcomRuleOwner and midcomGroupIndex in this row." 1959 ::= { midcomRuleEntry 3 } 1961 midcomRuleAdminStatus OBJECT-TYPE 1962 SYNTAX INTEGER { 1963 reserve(1), 1964 enable(2), 1965 notSet(3) 1966 } 1967 MAX-ACCESS read-write 1968 STATUS current 1969 DESCRIPTION 1970 "The value of this object indicates the desired status of 1971 the policy rule. See the definition of midcomRuleOperStatus 1972 for a description of the values. 1974 When a midcomRuleEntry is created without explicitly setting 1975 this object, its value will be notSet(3). 1977 However, a set request can only set this object to either 1978 reserve(1) or enable(2). Attempts to set this object to 1979 notSet(3) will always fail with an 'inconsistentValue' 1980 error. Note that this error code is SNMP specific. If the 1981 MIB module is used with other protocols than SNMP, errors 1982 with similar semantics specific to those protocols should 1983 be returned. 1985 When the midcomRuleAdminStatus object is set, then the 1986 MIDCOM MIB implementation will try to read the respective 1987 relevant objects of the entry and try to achieve the 1988 corresponding midcomRuleOperStatus. 1990 Setting midcomRuleAdminStatus to value reserve(1) when 1991 object midcomRuleOperStatus has a value of reserved(7) 1992 does not have any effect on the policy rule. 1993 Setting midcomRuleAdminStatus to value enable(2) when 1994 object midcomRuleOperStatus has a value of enabled(8) 1995 does not have any effect on the policy rule. 1997 Depending on whether the midcomRuleAdminStatus is set to 1998 reserve(1) or enable(2) several objects must be set in 1999 advance. They serve as parameters of the policy rule to be 2000 established 2002 When object midcomRuleAdminStatus is set to reserve(1), 2003 then the following objects in the same entry are of 2004 relevance: 2005 - midcomRuleInterface 2006 - midcomRuleTransportProtocol 2007 - midcomRulePortRange 2008 - midcomRuleInternalIpVersion 2009 - midcomRuleExternalIpVersion 2010 - midcomRuleInternalIpAddr 2011 - midcomRuleInternalIpPrefixLength 2012 - midcomRuleInternalPort 2013 - midcomRuleLifetime 2014 MIDCOM MIB implementation may also consider the value 2015 of object midcomRuleMaxIdleTime when establishing 2016 a reserve rule. 2018 When object midcomRuleAdminStatus is set to enable(2), 2019 then the following objects in the same entry are of 2020 relevance: 2021 - midcomRuleInterface 2022 - midcomRuleFlowDirection 2023 - midcomRuleMaxIdleTime 2024 - midcomRuleTransportProtocol 2025 - midcomRulePortRange 2026 - midcomRuleInternalIpVersion 2027 - midcomRuleExternalIpVersion 2028 - midcomRuleInternalIpAddr 2029 - midcomRuleInternalIpPrefixLength 2030 - midcomRuleInternalPort 2031 - midcomRuleExternalIpAddr 2032 - midcomRuleExternalIpPrefixLength 2033 - midcomRuleExternalPort 2034 - midcomRuleLifetime 2036 When retrieved, the object returns the last set value. 2037 If no value has been set, it returns the default value 2038 notSet(3)." 2039 DEFVAL { notSet } 2040 ::= { midcomRuleEntry 4 } 2042 midcomRuleOperStatus OBJECT-TYPE 2043 SYNTAX INTEGER { 2044 newEntry(1), 2045 setting(2), 2046 checkingRequest(3), 2047 incorrectRequest(4), 2048 processingRequest(5), 2049 requestRejected(6), 2050 reserved(7), 2051 enabled(8), 2052 timedOut(9), 2053 terminatedOnRequest(10), 2054 terminated(11), 2055 genericError(12) 2056 } 2057 MAX-ACCESS read-only 2058 STATUS current 2059 DESCRIPTION 2060 "The actual status of the policy rule. The 2061 midcomRuleOperStatus object may have the following values: 2063 - newEntry(1) indicates that the entry in the 2064 midcomRuleTable was created, but not modified yet. 2065 Such an entry needs to be filled with values specifying 2066 a request first. 2068 - setting(2) indicates that the entry has been already 2069 modified after generating it, but no request was made 2070 yet. 2072 - checkingRequest(3) indicates that midcomRuleAdminStatus 2073 has recently been set and that the MIDCOM MIB 2074 implementation is currently checking the parameters of 2075 the request. This is a transient state. The value of 2076 this object will change to either incorrectRequest(4) 2077 or processingRequest(5) without any external 2078 interaction. A MIDCOM MIB implementation MAY return 2079 this value while checking request parameters. 2081 - incorrectRequest(4) indicates that checking a request 2082 resulted in detecting an incorrect value in one of the 2083 objects containing request parameters. The failure 2084 reason is indicated by the value of midcomRuleError. 2086 - processingRequest(5) indicates that 2087 midcomRuleAdminStatus has recently been set and that 2088 the MIDCOM MIB implementation is currently processing 2089 the request and trying to configure the middlebox 2090 accordingly. This is a transient state. The value of 2091 this object will change to either requestRejected(6), 2092 reserved(7) or enabled(8) without any external 2093 interaction. A MIDCOM MIB implementation MAY return 2094 this value while processing a request. 2096 - requestRejected(6) indicates that a request to establish 2097 a policy rule specified by the entry was rejected. The 2098 reason of rejection is indicated by the value of 2099 midcomRuleError. 2101 - reserved(7) indicates that the entry describes an 2102 established policy reserve rule. 2103 These values of MidcomRuleEntry are meaningful 2104 for a reserved policy rule: 2105 - midcomRuleMaxIdleTime 2106 - midcomRuleInterface 2107 - midcomRuleTransportProtocol 2108 - midcomRulePortRange 2109 - midcomRuleInternalIpVersion 2110 - midcomRuleExternalIpVersion 2111 - midcomRuleInternalIpAddr 2112 - midcomRuleInternalIpPrefixLength 2113 - midcomRuleInternalPort 2114 - midcomRuleOutsideIpAddr 2115 - midcomRuleOutsidePort 2116 - midcomRuleLifetime 2118 - enabled(8) indicates that the entry describes an 2119 established policy enable rule. 2120 These values of MidcomRuleEntry are meaningful 2121 for an enabled policy rule: 2123 - midcomRuleFlowDirection 2124 - midcomRuleInterface 2125 - midcomRuleMaxIdleTime 2126 - midcomRuleTransportProtocol 2127 - midcomRulePortRange 2128 - midcomRuleInternalIpVersion 2129 - midcomRuleExternalIpVersion 2130 - midcomRuleInternalIpAddr 2131 - midcomRuleInternalIpPrefixLength 2132 - midcomRuleInternalPort 2133 - midcomRuleExternalIpAddr 2134 - midcomRuleExternalIpPrefixLength 2135 - midcomRuleExternalPort 2136 - midcomRuleInsideIpAddr 2137 - midcomRuleInsidePort 2138 - midcomRuleOutsideIpAddr 2139 - midcomRuleOutsidePort 2140 - midcomRuleLifetime 2142 - timedOut(9) indicates that the lifetime of a previously 2143 established policy rule has expired and that the policy 2144 rule is terminated for this reason. 2146 - terminatedOnRequest(10) indicates that a previously 2147 established policy rule was terminated by an SNMP 2148 manager setting the midcomRuleLifetime to 0 or 2149 setting midcomGroupLifetime to 0. 2151 - terminated(11) indicates that a previously established 2152 policy rule was terminated by the MIDCOM MIB 2153 implementation for another reason than lifetime 2154 expiration or an explicit request from a MIDCOM client. 2156 - genericError(12) indicates that the policy rule 2157 specified by the entry is not established due to 2158 an error condition not listed above. 2160 The states timedOut(9), terminatedOnRequest(10) and 2161 terminated(11) are referred to as termination states. 2163 The states incorrectRequest(4), requestRejected(6) 2164 and genericError(12) are referred to as error states. 2166 The checkingRequest(3) and processingRequest(4) 2167 states are transient states which will either lead to 2168 one of the error states or the reserved(7) state or the 2169 enabled(8) states. MIDCOM MIB implementations MAY return 2170 these values when checking or processing requests." 2171 DEFVAL { newEntry } 2172 ::= { midcomRuleEntry 5 } 2174 midcomRuleStorageType OBJECT-TYPE 2175 SYNTAX StorageType 2176 MAX-ACCESS read-write 2177 STATUS current 2178 DESCRIPTION 2179 "When retrieved, this object returns the storage 2180 type of the policy rule. Writing to this object can 2181 change the storage type of the particular row from 2182 volatile(2) to nonVolatile(3) or vice versa. 2184 Attempts to set this object to permanent will always 2185 fail with an 'inconsistentValue' error. Note that this 2186 error code is SNMP specific. If the MIB module is used 2187 with other protocols than SNMP, errors with similar 2188 semantics specific to those protocols should be 2189 returned. 2191 If midcomRuleStorageType has the value permanent(4), 2192 then all objects in this row whose MAX-ACCESS value 2193 is read-write must be read-only." 2194 DEFVAL { volatile } 2195 ::= { midcomRuleEntry 6 } 2197 midcomRuleStorageTime OBJECT-TYPE 2198 SYNTAX Unsigned32 2199 UNITS "seconds" 2200 MAX-ACCESS read-write 2201 STATUS current 2202 DESCRIPTION 2203 "The value of this object specifies how long this row 2204 can exist in the midcomRuleTable after the 2205 midcomRuleOperStatus switched to a termination state or 2206 to an error state. This object returns the remaining 2207 time that the row may exist before it is aged out. 2209 After expiration or termination of the context, the value 2210 of this object ticks backwards. The entry in the 2211 midcomRuleTable is destroyed when the value reaches 0. 2213 The value of this object may be set in order to increase 2214 or reduce the remaining time that the row may exist. 2215 Setting the value to 0 will destroy this entry as soon as 2216 the midcomRuleOperStatus switched to a termination state 2217 or to an error state. 2219 Note that there is no guarantee that the row is stored as 2220 long as this object indicates. At any time, the MIDCOM 2221 MIB implementation may decide to remove a row describing 2222 a terminated policy rule before the storage time of the 2223 corresponding row in the midcomRuleTable reaches the 2224 value of 0. In this case the information stored in this 2225 row is not anymore available. 2227 If object midcomRuleStorageType indicates that the policy 2228 rule has storage type permanent(4), then this object has 2229 a constant value of 4294967295." 2230 DEFVAL { 0 } 2231 ::= { midcomRuleEntry 7 } 2233 midcomRuleError OBJECT-TYPE 2234 SYNTAX SnmpAdminString 2235 MAX-ACCESS read-only 2236 STATUS current 2237 DESCRIPTION 2238 "This object contains a descriptive error message if 2239 the transition into the operational status reserved(7) 2240 or enabled(8) failed. Implementations must reset the 2241 error message to a zero-length string when a new 2242 attempt to change the policy rule status to reserved(7) 2243 or enabled(8) is started. 2245 RECOMMENDED values to be returned in particular cases 2246 include 2247 - 'lack of IP addresses' 2248 - 'lack of port numbers' 2249 - 'lack of resources' 2250 - 'specified NAT interface does not exist' 2251 - 'specified NAT interface does not support NAT' 2252 - 'conflict with already existing policy rule' 2253 - 'no internal IP wildcarding allowed' 2254 - 'no external IP wildcarding allowed' 2256 The semantics of these error messages and the corresponding 2257 behavior of the MIDCOM MIB implementation are specified 2258 in sections 2.3.9 and 2.3.10 of RFC 3989." 2259 REFERENCE 2260 "RFC 3989, sections 2.3.9 and 2.3.10" 2261 DEFVAL { ''H } 2262 ::= { midcomRuleEntry 8 } 2264 midcomRuleInterface OBJECT-TYPE 2265 SYNTAX InterfaceIndexOrZero 2266 MAX-ACCESS read-write 2267 STATUS current 2268 DESCRIPTION 2269 "This object indicates the IP interface for which 2270 enforcement of a policy rule is requested or performed, 2271 respectively. 2273 The interface is identified by its index in the ifTable 2274 (see IF-MIB in RFC2863). If the object has a value of 0, 2275 then no particular interface is indicated. 2277 This object is used as input to a request for establishing 2278 a policy rule as well as for indicating the properties of 2279 an established policy rule. 2281 If object midcomRuleOperStatus of the same entry has the 2282 value newEntry(1) or setting(2), then this object can be 2283 written by a manager in order to request its preference 2284 concerning the interface at which it requests NAT service. 2285 The default value of 0 indicates that the manager does not 2286 have a preferred interface or does not have sufficient 2287 topology information for specifying one. Writing to this 2288 object in any state other than newEntry(1) or setting(2) 2289 will always fail with an 'inconsistentValue' error. 2290 Note that this error code is SNMP specific. If the MIB 2291 module is used with other protocols than SNMP, errors with 2292 similar semantics specific to those protocols should be 2293 returned. 2295 If object midcomRuleOperStatus of the same entry has the 2296 value reserved(7) or enabled(8), then this object indicates 2297 the interface at which NAT service for this rule is 2298 performed. If NAT service is not required for enforcing 2299 the policy rule, then the value of this object is 0. Also 2300 if the MIDCOM MIB implementation cannot indicate an 2301 interface, because it does not have this information or 2302 because NAT service is not offered at a particular single 2303 interface, then the value of the object is 0. 2305 Note that the index of a particular interface in the ifTable 2306 may change after a re-initialization of the middlebox, for 2307 example, after adding another interface to it. In such a 2308 case the value of this object may change, but the interface 2309 referred to by the MIDCOM MIB MUST still be the same. 2310 If after a re-initilization of the middlebox, the interface 2311 referred to before re-initilization cannot be uniquely 2312 mapped anymore to a particular entry in the ifTable, then 2313 the value of object midcomRuleOperStatus of the same entry 2314 MUST be changed to terminated(11). 2316 If object midcomRuleOperStatus of the same entry has a 2317 value other than newEntry(1), setting(2), reserved(7) or 2318 enabled(8), then the value of this object is irrelevant." 2319 DEFVAL { 0 } 2320 ::= { midcomRuleEntry 9 } 2322 midcomRuleFlowDirection OBJECT-TYPE 2323 SYNTAX INTEGER { 2324 inbound(1), 2325 outbound(2), 2326 biDirectional(3) 2327 } 2328 MAX-ACCESS read-write 2329 STATUS current 2330 DESCRIPTION 2331 "This parameter specifies the direction of enabled 2332 communication, either inbound(1), outbound(2), or 2333 biDirectional(3). 2335 The semantics of this object depends on the protocol 2336 the rule relates to. If the rule is independent of 2337 the transport protocol (midcomRuleTransportProtocol 2338 has value of 0) or if the transport protocol is UDP, 2339 then the value of midcomRuleFlowDirection indicates 2340 the direction of packets traversing the middlebox. 2342 In this case, value inbound(1) indicates that packets 2343 are traversing from outside to inside, value outbound(2) 2344 indicates that packets are traversing from inside to 2345 outside. For both values, inbound(1) and outbound(2) 2346 packets can traverse the middlebox only uni-directional. 2347 A bi-directional flow is indicated by value 2348 biDirectional(3). 2350 If the transport protocol is TCP, the packet flow is 2351 always bi-directional, but the value of 2352 midcomRuleFlowDirection indicates that: 2354 - inbound(1): bi-directional TCP packet flow. 2355 First packet, with TCP SYN flag set, must arrive 2356 at an outside interface of the middlebox. 2358 - outbound(2): bi-directional TCP packet flow. 2359 First packet, with TCP SYN flag set, must arrive 2360 at an inside interface of the middlebox. 2362 - biDirectional(3): bi-directional TCP packet flow. 2363 First packet, with TCP SYN flag set, may arrive 2364 at an inside or an outside interface of the middlebox. 2366 This object is used as input to a request for 2367 establishing a policy enable rule as well as for 2368 indicating the properties of an established policy rule. 2370 If object midcomRuleOperStatus of the same entry has a 2371 value of either newEntry(1), setting(2) or reserved(7), 2372 then this object can be written by a manager in order to 2373 specify a requested direction to be enabled by a policy 2374 rule. Writing to this object in any state other than 2375 newEntry(1), setting(2) or reserved(7) will always fail 2376 with an 'inconsistentValue' error. 2377 Note that this error code is SNMP specific. If the MIB 2378 module is used with other protocols than SNMP, errors with 2379 similar semantics specific to those protocols should be 2380 returned. 2382 If object midcomRuleOperStatus of the same entry has the 2383 value enabled(8), then this object indicates the enabled 2384 flow direction. 2386 If object midcomRuleOperStatus of the same entry has a 2387 value other than newEntry(1), setting(2), reserved(7) or 2388 enabled(8), then the value of this object is irrelevant." 2389 DEFVAL { outbound } 2390 ::= { midcomRuleEntry 10 } 2392 midcomRuleMaxIdleTime OBJECT-TYPE 2393 SYNTAX Unsigned32 2394 UNITS "seconds" 2395 MAX-ACCESS read-write 2396 STATUS current 2397 DESCRIPTION 2398 "Maximum idle time of the policy rule in seconds. 2400 If no packet to which the policy rule applies passes the 2401 middlebox for the specified midcomRuleMaxIdleTime, then 2402 the policy rule enters the termination state timedOut(9). 2404 A value of 0 indicates that the policy does not require 2405 an individual idle time and that instead, a default idle 2406 time chosen by the middlebox is used. 2408 A value of 4294967295 ( = 2^32 - 1 ) indicates that the 2409 policy does not time out if it is idle. 2411 This object is used as input to a request for 2412 establishing a policy enable rule as well as for 2413 indicating the properties of an established policy rule. 2415 If object midcomRuleOperStatus of the same entry has a 2416 value of either newEntry(1), setting(2) or reserved(7), 2417 then this object can be written by a manager in order to 2418 specify a maximum idle time for the policy rule to be 2419 requested. Writing to this object in any state other 2420 than newEntry(1), setting(2) or reserved(7) will always 2421 fail with an 'inconsistentValue' error. 2422 Note that this error code is SNMP specific. If the MIB 2423 module is used with other protocols than SNMP, errors with 2424 similar semantics specific to those protocols should be 2425 returned. 2427 If object midcomRuleOperStatus of the same entry has the 2428 value enabled(8), then this object indicates the maximum 2429 idle time of the policy rule. Note that even if a maximum 2430 idle time greater than zero was requested, the middlebox 2431 may not be able to support maximum idle times and set the 2432 value of this object to zero when entering state 2433 enabled(8). 2435 If object midcomRuleOperStatus of the same entry has a 2436 value other than newEntry(1), setting(2), reserved(7) or 2437 enabled(8), then the value of this object is irrelevant." 2438 DEFVAL { 0 } 2439 ::= { midcomRuleEntry 11 } 2441 midcomRuleTransportProtocol OBJECT-TYPE 2442 SYNTAX Unsigned32 (0..255) 2443 MAX-ACCESS read-write 2444 STATUS current 2445 DESCRIPTION 2446 "The transport protocol. 2448 Valid values for midcomRuleTransportProtocol 2449 other than zero are defined at: 2450 http://www.iana.org/assignments/protocol-numbers 2452 This object is used as input to a request for establishing 2453 a policy rule as well as for indicating the properties of 2454 an established policy rule. 2456 If object midcomRuleOperStatus of the same entry has a 2457 value of either newEntry(1) or setting(2), then this 2458 object can be written by a manager in order to specify a 2459 requested transport protocol. If translation of an IP 2460 address only is requested, then this object must have the 2461 default value 0. Writing to this object in any state 2462 other than newEntry(1) or setting(2) will always fail 2463 with an 'inconsistentValue' error. 2464 Note that this error code is SNMP specific. If the MIB 2465 module is used with other protocols than SNMP, errors with 2466 similar semantics specific to those protocols should be 2467 returned. 2469 If object midcomRuleOperStatus of the same entry has the 2470 value reserved(7) or enabled(8), then this object 2471 indicates which transport protocol is enforced by this 2472 policy rule. A value of 0 indicates a rule acting on IP 2473 addresses only. 2475 If object midcomRuleOperStatus of the same entry has a 2476 value other than newEntry(1), setting(2), reserved(7) or 2477 enabled(8), then the value of this object is irrelevant." 2478 DEFVAL { 0 } 2479 ::= { midcomRuleEntry 12 } 2481 midcomRulePortRange OBJECT-TYPE 2482 SYNTAX INTEGER { 2483 single(1), 2484 pair(2) 2485 } 2486 MAX-ACCESS read-write 2487 STATUS current 2488 DESCRIPTION 2489 "The range of port numbers. 2491 This object is used as input to a request for establishing 2492 a policy rule as well as for indicating the properties of 2493 an established policy rule. It is relevant to the 2494 operation of the MIDCOM MIB implementation only if the 2495 value of object midcomTransportProtocol in the same entry 2496 has a value other than 0. 2498 If object midcomRuleOperStatus of the same entry has the 2499 value newEntry(1) or setting(2), then this object can be 2500 written by a manager in order to specify the requested 2501 size of the port range. With single(1) just a single 2502 port number is requested, with pair(2) a consecutive pair 2503 of port numbers is requested with the lower number being 2504 even. Requesting a consecutive pair of port numbers may 2505 be used by RTP [RFC3550] and may even be required to 2506 support older RTP applications. 2508 Writing to this object in any state other than 2509 newEntry(1), setting(2) or reserved(7) will always fail 2510 with an 'inconsistentValue' error. 2511 Note that this error code is SNMP specific. If the MIB 2512 module is used with other protocols than SNMP, errors with 2513 similar semantics specific to those protocols should be 2514 returned. 2516 If object midcomRuleOperStatus of the same entry has a 2517 value of either reserved(7) or enabled(8), then this 2518 object will have the value which it had before the 2519 transition to this state. 2521 If object midcomRuleOperStatus of the same entry has a 2522 value other than newEntry(1), setting(2), reserved(7) or 2523 enabled(8), then the value of this object is irrelevant." 2524 DEFVAL { single } 2525 ::= { midcomRuleEntry 13} 2527 midcomRuleInternalIpVersion OBJECT-TYPE 2528 SYNTAX InetAddressType 2529 MAX-ACCESS read-write 2530 STATUS current 2531 DESCRIPTION 2532 "IP version of the internal address (A0) and the inside 2533 address (A1). Allowed values are ipv4(1), ipv6(2), 2534 ipv4z(3), and ipv6z(4). 2536 This object is used as input to a request for establishing 2537 a policy rule as well as for indicating the properties of 2538 an established policy rule. 2540 If object midcomRuleOperStatus of the same entry has the 2541 value newEntry(1) or setting(2), then this object can be 2542 written by a manager in order to specify the IP version 2543 required at the inside of the middlebox. Writing to this 2544 object in any state other than newEntry(1) or setting(2) 2545 will always fail with an 'inconsistentValue' error. 2546 Note that this error code is SNMP specific. If the MIB 2547 module is used with other protocols than SNMP, errors with 2548 similar semantics specific to those protocols should be 2549 returned. 2551 If object midcomRuleOperStatus of the same entry has the 2552 value reserved(7) or enabled(8), then this object 2553 indicates the internal/inside IP version. 2555 If object midcomRuleOperStatus of the same entry has a 2556 value other than newEntry(1), setting(2), reserved(7) or 2557 enabled(8), then the value of this object is irrelevant." 2558 DEFVAL { ipv4 } 2559 ::= { midcomRuleEntry 14 } 2561 midcomRuleExternalIpVersion OBJECT-TYPE 2562 SYNTAX InetAddressType 2563 MAX-ACCESS read-write 2564 STATUS current 2565 DESCRIPTION 2566 "IP version of the external address (A3) and the outside 2567 address (A2). Allowed values are ipv4(1) and ipv6(2). 2569 This object is used as input to a request for establishing 2570 a policy rule as well as for indicating the properties of 2571 an established policy rule. 2573 If object midcomRuleOperStatus of the same entry has the 2574 value newEntry(1) or setting(2), then this object can be 2575 written by a manager in order to specify the IP version 2576 required at the outside of the middlebox. Writing to 2577 this object in any state other than newEntry(1) or 2578 setting(2) will always fail with an 'inconsistentValue' 2579 error. 2580 Note that this error code is SNMP specific. If the MIB 2581 module is used with other protocols than SNMP, errors with 2582 similar semantics specific to those protocols should be 2583 returned. 2585 If object midcomRuleOperStatus of the same entry has the 2586 value reserved(7) or enabled(8), then this object 2587 indicates the external/outside IP version. 2589 If object midcomRuleOperStatus of the same entry has a 2590 value other than newEntry(1), setting(2), reserved(7) or 2591 enabled(8), then the value of this object is irrelevant." 2592 DEFVAL { ipv4 } 2593 ::= { midcomRuleEntry 15 } 2595 midcomRuleInternalIpAddr OBJECT-TYPE 2596 SYNTAX InetAddress 2597 MAX-ACCESS read-write 2598 STATUS current 2599 DESCRIPTION 2600 "The internal IP address (A0). 2602 This object is used as input to a request for establishing 2603 a policy rule as well as for indicating the properties of 2604 an established policy rule. 2606 If object midcomRuleOperStatus of the same entry has the 2607 value newEntry(1) or setting(2), then this object can be 2608 written by a manager in order to specify the internal IP 2609 address for which a reserve policy rule or a enable policy 2610 rule is requested to be established. Writing to this 2611 object in any state other than newEntry(1) or setting(2) 2612 will always fail with an 'inconsistentValue' error. 2613 Note that this error code is SNMP specific. If the MIB 2614 module is used with other protocols than SNMP, errors with 2615 similar semantics specific to those protocols should be 2616 returned. 2618 If object midcomRuleOperStatus of the same entry has the 2619 value reserved(7) or enabled(8), then this object will 2620 have the value which it had before the transition to this 2621 state. 2623 If object midcomRuleOperStatus of the same entry has a 2624 value other than newEntry(1), setting(2), reserved(7) or 2625 enabled(8), then the value of this object is irrelevant." 2626 ::= { midcomRuleEntry 16 } 2628 midcomRuleInternalIpPrefixLength OBJECT-TYPE 2629 SYNTAX InetAddressPrefixLength 2630 MAX-ACCESS read-write 2631 STATUS current 2632 DESCRIPTION 2633 "The prefix length of the internal IP address used for 2634 wildcarding. A value of 0 indicates a full wildcard; 2635 in this case the value of midcomRuleInternalIpAddr is 2636 irrelevant. If midcomRuleInternalIpVersion has a value 2637 of ipv4(1) then a value > 31 indicates no wildcarding 2638 at all. If midcomRuleInternalIpVersion has a value 2639 of ipv4(2) then a value > 127 indicates no wildcarding 2640 at all. A MIDCOM MIB implementation that does not 2641 support IP address wildcarding MUST implement this object 2642 as read-only with a value of 128. A MIDCOM that does 2643 not support wildcarding based on prefix length MAY 2644 restrict allowed values for this object to 0 and 128. 2646 This object is used as input to a request for establishing 2647 a policy rule as well as for indicating the properties of 2648 an established policy rule. 2650 If object midcomRuleOperStatus of the same entry has the 2651 value newEntry(1) or setting(2), then this object can be 2652 written by a manager in order to specify the internal IP 2653 address for which a reserve policy rule or a enable policy 2654 rule is requested to be established. Writing to this 2655 object in any state other than newEntry(1) or setting(2) 2656 will always fail with an 'inconsistentValue' error. 2657 Note that this error code is SNMP specific. If the MIB 2658 module is used with other protocols than SNMP, errors with 2659 similar semantics specific to those protocols should be 2660 returned. 2662 If object midcomRuleOperStatus of the same entry has the 2663 value reserved(7) or enabled(8), then this object will 2664 have the value which it had before the transition to this 2665 state. 2667 If object midcomRuleOperStatus of the same entry has a 2668 value other than newEntry(1), setting(2), reserved(7) or 2669 enabled(8), then the value of this object is irrelevant." 2670 DEFVAL { 128 } 2671 ::= { midcomRuleEntry 17 } 2673 midcomRuleInternalPort OBJECT-TYPE 2674 SYNTAX InetPortNumber 2675 MAX-ACCESS read-write 2676 STATUS current 2677 DESCRIPTION 2678 "The internal port number. A value of 0 is a wildcard. 2680 This object is used as input to a request for establishing 2681 a policy rule as well as for indicating the properties of 2682 an established policy rule. It is relevant to the 2683 operation of the MIDCOM MIB implementation only if the 2684 value of object midcomTransportProtocol in the same entry 2685 has a value other than 0. 2687 If object midcomRuleOperStatus of the same entry has the 2688 value newEntry(1) or setting(2), then this object can be 2689 written by a manager in order to specify the port number 2690 for which a reserve policy rule or a enable policy rule is 2691 requested to be established. Writing to this object in 2692 any state other than newEntry(1) or setting(2) will always 2693 fail with an 'inconsistentValue' error. 2694 Note that this error code is SNMP specific. If the MIB 2695 module is used with other protocols than SNMP, errors with 2696 similar semantics specific to those protocols should be 2697 returned. 2699 If object midcomRuleOperStatus of the same entry has the 2700 value reserved(7) or enabled(8), then this object will 2701 have the value which it had before the transition to this 2702 state. 2704 If object midcomRuleOperStatus of the same entry has a 2705 value other than newEntry(1), setting(2), reserved(7) or 2706 enabled(8), then the value of this object is irrelevant." 2707 DEFVAL { 0 } 2708 ::= { midcomRuleEntry 18 } 2710 midcomRuleExternalIpAddr OBJECT-TYPE 2711 SYNTAX InetAddress 2712 MAX-ACCESS read-write 2713 STATUS current 2714 DESCRIPTION 2715 "The external IP address (A3). 2717 This object is used as input to a request for establishing 2718 a policy rule as well as for indicating the properties of 2719 an established policy rule. 2721 If object midcomRuleOperStatus of the same entry has the 2722 value newEntry(1), setting(2) or reserved(7), then this 2723 object can be written by a manager in order to specify the 2724 external IP address for which an enable policy rule is 2725 requested to be established. Writing to this object in 2726 any state other than newEntry(1), setting(2) or reserved(7) 2727 will always fail with an 'inconsistentValue' error. 2728 Note that this error code is SNMP specific. If the MIB 2729 module is used with other protocols than SNMP, errors with 2730 similar semantics specific to those protocols should be 2731 returned. 2733 If object midcomRuleOperStatus of the same entry has the 2734 value enabled(8), then this object will have the value 2735 which it had before the transition to this state. 2737 If object midcomRuleOperStatus of the same entry has a 2738 value other than newEntry(1), setting(2), reserved(7) or 2739 enabled(8), then the value of this object is irrelevant." 2740 ::= { midcomRuleEntry 19 } 2742 midcomRuleExternalIpPrefixLength OBJECT-TYPE 2743 SYNTAX InetAddressPrefixLength 2744 MAX-ACCESS read-write 2745 STATUS current 2746 DESCRIPTION 2747 "The prefix length of the external IP address used for 2748 wildcarding. A value of 0 indicates a full wildcard; 2749 in this case the value of midcomRuleExternalIpAddr is 2750 irrelevant. If midcomRuleExternalIpVersion has a value 2751 of ipv4(1) then a value > 31 indicates no wildcarding 2752 at all. If midcomRuleExternalIpVersion has a value 2753 of ipv4(2) then a value > 127 indicates no wildcarding 2754 at all. A MIDCOM MIB implementation that does not 2755 support IP address wildcarding MUST implement this object 2756 as read-only with a value of 128. A MIDCOM that does 2757 not support wildcarding based on prefix length MAY 2758 restrict allowed values for this object to 0 and 128. 2760 This object is used as input to a request for establishing 2761 a policy rule as well as for indicating the properties of 2762 an established policy rule. 2764 If object midcomRuleOperStatus of the same entry has the 2765 value newEntry(1), setting(2) or reserved(7), then this 2766 object can be written by a manager in order to specify the 2767 external IP address for which an enable policy rule is 2768 requested to be established. Writing to this object in 2769 any state other than newEntry(1), setting(2) or reserved(7) 2770 will always fail with an 'inconsistentValue' error. 2771 Note that this error code is SNMP specific. If the MIB 2772 module is used with other protocols than SNMP, errors with 2773 similar semantics specific to those protocols should be 2774 returned. 2776 If object midcomRuleOperStatus of the same entry has the 2777 value enabled(8), then this object will have the value 2778 which it had before the transition to this state. 2780 If object midcomRuleOperStatus of the same entry has a 2781 value other than newEntry(1), setting(2), reserved(7) or 2782 enabled(8), then the value of this object is irrelevant." 2783 DEFVAL { 128 } 2784 ::= { midcomRuleEntry 20 } 2786 midcomRuleExternalPort OBJECT-TYPE 2787 SYNTAX InetPortNumber 2788 MAX-ACCESS read-write 2789 STATUS current 2790 DESCRIPTION 2791 "The external port number. A value of 0 is a wildcard. 2793 This object is used as input to a request for establishing 2794 a policy rule as well as for indicating the properties of 2795 an established policy rule. It is relevant to the 2796 operation of the MIDCOM MIB implementation only if the 2797 value of object midcomTransportProtocol in the same entry 2798 has a value other than 0. 2800 If object midcomRuleOperStatus of the same entry has the 2801 value newEntry(1), setting(2) or reserved(7), then this 2802 object can be written by a manager in order to specify the 2803 external port number for which an enable policy rule is 2804 requested to be established. Writing to this object in 2805 any state other than newEntry(1), setting(2) or reserved(7) 2806 will always fail with an 'inconsistentValue' error. 2807 Note that this error code is SNMP specific. If the MIB 2808 module is used with other protocols than SNMP, errors with 2809 similar semantics specific to those protocols should be 2810 returned. 2812 If object midcomRuleOperStatus of the same entry has the 2813 value enabled(8), then this object will have the value 2814 which it had before the transition to this state. 2816 If object midcomRuleOperStatus of the same entry has a 2817 value other than newEntry(1), setting(2), reserved(7) or 2818 enabled(8), then the value of this object is irrelevant." 2819 DEFVAL { 0 } 2820 ::= { midcomRuleEntry 21 } 2822 midcomRuleInsideIpAddr OBJECT-TYPE 2823 SYNTAX InetAddress 2824 MAX-ACCESS read-only 2825 STATUS current 2826 DESCRIPTION 2827 "The inside IP address at the middlebox (A1). 2829 The value of this object is relevant only if 2830 object midcomRuleOperStatus of the same entry has 2831 a value of either reserved(7) or enabled(8)." 2832 ::= { midcomRuleEntry 22 } 2834 midcomRuleInsidePort OBJECT-TYPE 2835 SYNTAX InetPortNumber 2836 MAX-ACCESS read-only 2837 STATUS current 2838 DESCRIPTION 2839 "The inside port number at the middlebox. 2840 A value of 0 is a wildcard. 2842 The value of this object is relevant only if 2843 object midcomRuleOperStatus of the same entry has 2844 a value of either reserved(7) or enabled(8)." 2845 ::= { midcomRuleEntry 23 } 2847 midcomRuleOutsideIpAddr OBJECT-TYPE 2848 SYNTAX InetAddress 2849 MAX-ACCESS read-only 2850 STATUS current 2851 DESCRIPTION 2852 "The outside IP address at the middlebox (A2). 2854 The value of this object is relevant only if 2855 object midcomRuleOperStatus of the same entry has 2856 a value of either reserved(7) or enabled(8)." 2857 ::= { midcomRuleEntry 24 } 2859 midcomRuleOutsidePort OBJECT-TYPE 2860 SYNTAX InetPortNumber 2861 MAX-ACCESS read-only 2862 STATUS current 2863 DESCRIPTION 2864 "The outside port number at the middlebox. 2865 A value of 0 is a wildcard. 2867 The value of this object is relevant only if 2868 object midcomRuleOperStatus of the same entry has 2869 a value of either reserved(7) or enabled(8)." 2870 ::= { midcomRuleEntry 25 } 2872 midcomRuleLifetime OBJECT-TYPE 2873 SYNTAX Unsigned32 2874 UNITS "seconds" 2875 MAX-ACCESS read-write 2876 STATUS current 2877 DESCRIPTION 2878 "The remaining lifetime in seconds of this policy rule. 2880 Lifetime of a policy rule starts when object 2881 midcomRuleOperStatus in the same entry enters either 2882 state reserved(7) or state enabled(8). 2884 This object is used as input to a request for establishing 2885 a policy rule as well as for indicating the properties of 2886 an established policy rule. 2888 If object midcomRuleOperStatus of the same entry has a 2889 value of either newEntry(1) or setting(2), then this 2890 object can be written by a manager in order to specify 2891 the requested lifetime of a policy rule to be established. 2893 If object midcomRuleOperStatus of the same entry has a 2894 value of either reserved(7) or enabled(8), indicates the 2895 (continuously decreasing) remaining lifetime of the 2896 established policy rule. Note that when entering state 2897 reserved(7) or enabled(8), the MIDCOM MIB implementation 2898 can choose a lifetime shorter than the one requested. 2900 Unlike other parameters of the policy rule, this parameter 2901 can still be written in state reserved(7) and enabled(8). 2902 Writing to this object is processed by the MIDCOM MIB 2903 implementation by choosing a lifetime value that is 2904 greater than zero and less than or equal to the minimum 2905 of the requested value and the value specified by by 2906 object midcomConfigMaxLifetime: 2908 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 2910 whereas: 2911 - lt_granted is the actually granted lifetime by the 2912 MIDCOM MIB implementation 2913 - lt_requested is the requested lifetime of the MIDCOM 2914 client 2915 - lt_maximum is the value of object 2916 midcomConfigMaxLifetime 2918 SNMP set requests to this object may be rejected or the 2919 value of the object after an accepted set operation may be 2920 less than the value that was contained in the SNMP set 2921 request. 2923 Successfully writing a value of 0 terminates the policy 2924 rule. Note that after a policy rule is terminated, still 2925 the entry will exist as long as indicated by the value of 2926 midcomRuleStorageTime. 2928 Writing to this object in any state other than 2929 newEntry(1), setting(2), reserved(7) or enabled(7) 2930 will always fail with an 'inconsistentValue' error. 2931 Note that this error code is SNMP specific. If the MIB 2932 module is used with other protocols than SNMP, errors with 2933 similar semantics specific to those protocols should be 2934 returned. 2936 If object midcomRuleOperStatus of the same entry has a 2937 value other than newEntry(1), setting(2), reserved(7) or 2938 enabled(8), then the value of this object is irrelevant." 2939 DEFVAL { 180 } 2940 ::= { midcomRuleEntry 26 } 2942 midcomRuleRowStatus OBJECT-TYPE 2943 SYNTAX RowStatus 2944 MAX-ACCESS read-create 2945 STATUS current 2946 DESCRIPTION 2947 "A control that allows entries to be added and removed from 2948 this table. 2950 Entries can also be removed from this table by setting 2951 objects midcomRuleLifetime and midcomRuleStorageTime of 2952 an entry to 0. 2954 Attempts to set a row notInService(2) where the value 2955 of the midcomRuleStorageType object is permanent(4) or 2956 readOnly(5) will result in an 'notWritable' error. 2957 Note that this error code is SNMP specific. If the MIB 2958 module is used with other protocols than SNMP, errors with 2959 similar semantics specific to those protocols should be 2960 returned. 2962 The value of this object has no effect on whether other 2963 objects in this conceptual row can be modified." 2964 ::= { midcomRuleEntry 27 } 2966 -- 2967 -- Policy rule group subtree 2968 -- 2969 -- The midcomGroupTable lists all current policy rule groups. 2970 -- 2972 midcomGroupTable OBJECT-TYPE 2973 SYNTAX SEQUENCE OF MidcomGroupEntry 2974 MAX-ACCESS not-accessible 2975 STATUS current 2976 DESCRIPTION 2977 "This table lists all current policy rule groups. 2979 Entries in this table are created or removed 2980 implicitly when entries in the midcomRuleTable are 2981 created or removed, respectively. A group entry 2982 in this table only exists as long as there are 2983 member rules of this group in the midcomRuleTable. 2985 The table serves for listing the existing groups and 2986 their remaining lifetimes and for changing lifetimes 2987 of groups and implicitly of all group members. 2988 Groups and all their member policy rules can only be 2989 deleted by deleting all member policies in the 2990 midcomRuleTable. 2992 Setting midcomGroupLifetime will result in setting 2993 the lifetime of all policy members to the same value." 2994 ::= { midcomTransaction 4 } 2996 midcomGroupEntry OBJECT-TYPE 2997 SYNTAX MidcomGroupEntry 2998 MAX-ACCESS not-accessible 2999 STATUS current 3000 DESCRIPTION 3001 "An entry describing properties of a particular 3002 MIDCOM policy rule group." 3003 INDEX { midcomRuleOwner, midcomGroupIndex } 3004 ::= { midcomGroupTable 1 } 3006 MidcomGroupEntry ::= SEQUENCE { 3007 midcomGroupIndex Unsigned32, 3008 midcomGroupLifetime Unsigned32 3009 } 3011 midcomGroupIndex OBJECT-TYPE 3012 SYNTAX Unsigned32 (1..4294967295) 3013 MAX-ACCESS not-accessible 3014 STATUS current 3015 DESCRIPTION 3016 "The index of this group for the midcomRuleOwner. 3017 A group is identified by the combination of 3018 midcomRuleOwner and midcomGroupIndex. 3020 The value of this index must be unique per 3021 midcomRuleOwner." 3022 ::= { midcomGroupEntry 2 } 3024 midcomGroupLifetime OBJECT-TYPE 3025 SYNTAX Unsigned32 3026 UNITS "seconds" 3027 MAX-ACCESS read-write 3028 STATUS current 3029 DESCRIPTION 3030 "When retrieved, this object delivers the maximum 3031 lifetime in seconds of all member rules of this group, 3032 i.e. of all rows in the midcomRuleTable that have the 3033 same values for midcomRuleOwner and midcomGroupIndex. 3035 Successfully writing to this object modifies the 3036 lifetime of all member policies. Successfully 3037 writing a value of 0 terminates all member policies 3038 and implicitly deletes the group as soon as all member 3039 entries are removed from the midcomRuleTable. 3041 Note that after a group's lifetime is expired or is 3042 set to 0, still the corresponding entry in the 3043 midcomGroupTable will exist as long as terminated 3044 member policy rules are stored as entries in the 3045 midcomRuleTable. 3047 Writing to this object is processed by the MIDCOM MIB 3048 implementation by choosing a lifetime value that is 3049 greater than zero and less than or equal to the minimum 3050 of the requested value and the value specified by object 3051 midcomConfigMaxLifetime: 3053 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) 3055 whereas: 3056 - lt_granted is the actually granted lifetime by the 3057 MIDCOM MIB implementation 3058 - lt_requested is the requested lifetime of the MIDCOM 3059 client 3060 - lt_maximum is the value of object 3061 midcomConfigMaxLifetime 3063 SNMP set requests to this object may be rejected or the 3064 value of the object after an accepted set operation may be 3065 less than the value that was contained in the SNMP set 3066 request." 3067 ::= { midcomGroupEntry 3 } 3069 -- 3070 -- Configuration Objects 3071 -- 3072 -- Configuration objects that can be used for retrieving 3073 -- middlebox capability information (mandatory) and for 3074 -- setting parameters of the implementation of transaction 3075 -- objects (optional). 3076 -- 3077 -- Note that typically configuration objects are not intended 3078 -- to be written by MIDCOM clients. In general, write access 3079 -- to these objects needs to be restricted more strictly than 3080 -- write access to transaction objects. 3081 -- 3083 -- 3084 -- Capabilities subtree 3085 -- 3086 -- This subtree contains objects to which MIDCOM clients should 3087 -- have read access. 3088 -- 3090 midcomConfigMaxLifetime OBJECT-TYPE 3091 SYNTAX Unsigned32 3092 UNITS "seconds" 3093 MAX-ACCESS read-write 3094 STATUS current 3095 DESCRIPTION 3096 "When retrieved, this object returns the maximum lifetime 3097 in seconds, that this middlebox allows policy rules to 3098 have." 3099 ::= { midcomConfig 1 } 3101 midcomConfigPersistentRules OBJECT-TYPE 3102 SYNTAX TruthValue 3103 MAX-ACCESS read-write 3104 STATUS current 3105 DESCRIPTION 3106 "When retrieved, this object returns true(1) if the 3107 MIDCOM-MIB implementation can store policy rules 3108 persistently. Otherwise, it returns false(2). 3110 A value of true(1) indicates that there may be 3111 entries in the midcomRuleTable with object 3112 midcomRuleStorageType set to value nonVolatile(3)." 3113 ::= { midcomConfig 2 } 3115 midcomConfigIfTable OBJECT-TYPE 3116 SYNTAX SEQUENCE OF MidcomConfigIfEntry 3117 MAX-ACCESS not-accessible 3118 STATUS current 3119 DESCRIPTION 3120 "This table indicates capabilities of the MIDCOM-MIB 3121 implementation per IP interface. 3123 The table is indexed by the object midcomConfigIfIndex. 3125 For indexing a single interface, this object contains 3126 the value of the ifIndex object that is associated 3127 with the interface. If an entry with 3128 midcomConfigIfIndex = 0 occurs, then bits set in 3129 objects of this entry apply to all interfaces for which 3130 there is no entry in this table with the interface's 3131 index." 3132 ::= { midcomConfig 3 } 3134 midcomConfigIfEntry OBJECT-TYPE 3135 SYNTAX MidcomConfigIfEntry 3136 MAX-ACCESS not-accessible 3137 STATUS current 3138 DESCRIPTION 3139 "An entry describing the capabilities of a middlebox 3140 with respect to the indexed IP interface." 3141 INDEX { midcomConfigIfIndex } 3142 ::= { midcomConfigIfTable 1 } 3144 MidcomConfigIfEntry ::= SEQUENCE { 3145 midcomConfigIfIndex InterfaceIndexOrZero, 3146 midcomConfigIfBits BITS, 3147 midcomConfigIfEnabled TruthValue 3148 } 3150 midcomConfigIfIndex OBJECT-TYPE 3151 SYNTAX InterfaceIndexOrZero 3152 MAX-ACCESS not-accessible 3153 STATUS current 3154 DESCRIPTION 3155 "The index of an entry in the midcomConfigIfTable. 3157 For values different from zero, this object 3158 identifies an IP interface by containing the same 3159 value as the ifIndex object associated with the 3160 interface. 3162 Note that the index of a particular interface in the ifTable 3163 may change after a re-initialization of the middlebox, for 3164 example, after adding another interface to it. In such a 3165 case the value of this object may change, but the interface 3166 referred to by the MIDCOM MIB MUST still be the same. 3167 If after a re-initilization of the middlebox, the interface 3168 referred to before re-initilization cannot be uniquely 3169 mapped anymore to a particular entry in the ifTable, then 3170 the value of object midcomConfigIfEnabled of the same entry 3171 MUST be changed to false(2). 3173 If the object has a value of 0, then values 3174 specified by further objects of the same entry 3175 apply to all interfaces for which there is no 3176 explicit entry in the midcomConfigIfTable." 3177 ::= { midcomConfigIfEntry 1 } 3179 midcomConfigIfBits OBJECT-TYPE 3180 SYNTAX BITS { 3181 ipv4(0), 3182 ipv6(1), 3183 addressWildcards(2), 3184 portWildcards(3), 3185 firewall(4), 3186 nat(5), 3187 portTranslation(6), 3188 protocolTranslation(7), 3189 twiceNat(8), 3190 inside(9) 3191 } 3192 MAX-ACCESS read-only 3193 STATUS current 3194 DESCRIPTION 3195 "When retrieved, this object returns a set of bits 3196 indicating the capabilities (or configuration) of 3197 the middlebox with respect to the referenced IP interface. 3198 If the index equals 0, then all set bits apply to all 3199 interfaces. 3201 If the ipv4(0) bit is set, then the middlebox supports 3202 IPv4 at the indexed IP interface. 3204 If the ipv6(1) bit is set, then the middlebox supports 3205 IPv6 at the indexed IP interface. 3207 If the addressWildcards(2) bit is set, then the 3208 middlebox supports IP address wildcarding at the indexed 3209 IP interface. 3211 If the portWildcards(3) bit is set, then the 3212 middlebox supports port wildcarding at the indexed 3213 IP interface. 3215 If the firewall(4) bit is set, then the middlebox offers 3216 firewall functionality at the indexed interface. 3218 If the nat(5) bit is set, then the middlebox offers 3219 network address translation service at the indexed 3220 interface. 3222 If the portTranslation(6) bit is set, then the middlebox 3223 offers port translation service at the indexed interface. 3224 This bit is only relevant if nat(5) is set. 3226 If the protocolTranslation(7) bit is set, then the 3227 middlebox offers protocol translation service between 3228 IPv4 and IPv6 at the indexed interface. This bit is only 3229 relevant if nat(5) is set. 3231 If the twiceNat(8) bit is set, then the middlebox offers 3232 twice network address translation service at the indexed 3233 interface. This bit is only relevant if nat(5) is set. 3235 If the inside(9) bit is set, then the indexed interface is 3236 an inside interface with respect to NAT functionality. 3237 Otherwise, it is an outside interface. This bit is only 3238 relevant if nat(5) is set. An SNMP agent supporting both, 3239 the MIDCOM-MIB module and the NAT-MIB module SHOULD ensure 3240 that the value of this object is consistent with the values 3241 of corresponding objects in the NAT-MIB module." 3242 ::= { midcomConfigIfEntry 2 } 3244 midcomConfigIfEnabled OBJECT-TYPE 3245 SYNTAX TruthValue 3246 MAX-ACCESS read-write 3247 STATUS current 3248 DESCRIPTION 3249 "The value of this object indicates the availability of 3250 the middlebox service described by midcomConfigIfBits 3251 at the indexed IP interface. 3253 By writing to this object, the MIDCOM support for the 3254 entire IP interface can be switched on or off. Setting 3255 this object to false(2) immediately stops middlebox 3256 support at the indexed IP interface. This implies that 3257 all policy rules that use NAT or firewall resources at 3258 the indexed IP interface are terminated immediately. 3259 In this case, the MIDCOM agent MUST send 3260 midcomUnsolicitedRuleEvent to all MIDCOM clients that 3261 have access to one of the terminated rules." 3262 DEFVAL { true } 3263 ::= { midcomConfigIfEntry 3 } 3265 -- 3266 -- Firewall subtree 3267 -- 3268 -- This subtree contains the firewall configuration table 3269 -- 3271 midcomConfigFirewallTable OBJECT-TYPE 3272 SYNTAX SEQUENCE OF MidcomConfigFirewallEntry 3273 MAX-ACCESS not-accessible 3274 STATUS current 3275 DESCRIPTION 3276 "This table lists the firewall configuration per IP interface. 3278 It can be used for configuring how policy rules created by 3279 MIDCOM clients are realized as firewall rules of a firewall 3280 implementation. Particularly, the priority used for MIDCOM 3281 policy rules can be configured. For a single firewall 3282 implementation at a particular IP interface, all MIDCOM 3283 policy rules are realized as firewall rules with the same 3284 priority. Also a firewall rule group name can be configured. 3286 The table is indexed by the object midcomConfigFirewallIndex. 3287 For indexing a single interface, this object contains the 3288 value of the ifIndex object that is associated with the 3289 interface. If an entry with midcomConfigFirewallIndex = 0 3290 occurs, then bits set in objects of this entry apply to all 3291 interfaces for which there is no entry in this table for the 3292 interface's index." 3293 ::= { midcomConfig 4 } 3295 midcomConfigFirewallEntry OBJECT-TYPE 3296 SYNTAX MidcomConfigFirewallEntry 3297 MAX-ACCESS not-accessible 3298 STATUS current 3299 DESCRIPTION 3300 "An entry describing a particular set of 3301 firewall resources." 3302 INDEX { midcomConfigFirewallIndex } 3303 ::= { midcomConfigFirewallTable 1 } 3305 MidcomConfigFirewallEntry ::= SEQUENCE { 3306 midcomConfigFirewallIndex InterfaceIndexOrZero, 3307 midcomConfigFirewallGroupId SnmpAdminString, 3308 midcomConfigFirewallPriority Unsigned32 3309 } 3311 midcomConfigFirewallIndex OBJECT-TYPE 3312 SYNTAX InterfaceIndexOrZero 3313 MAX-ACCESS not-accessible 3314 STATUS current 3315 DESCRIPTION 3316 "The index of an entry in the midcomConfigFirewallTable. 3318 For values different from zero, this object identifies an 3319 IP inteface by containing the same value as the ifIndex 3320 object associated with the interface. 3322 Note that the index of a particular interface in the ifTable 3323 may change after a re-initialization of the middlebox, for 3324 example, after adding another interface to it. In such a 3325 case the value of this object may change, but the interface 3326 referred to by the MIDCOM MIB MUST still be the same. 3327 If after a re-initilization of the middlebox, the interface 3328 referred to before re-initilization cannot be uniquely 3329 mapped anymore to a particular entry in the ifTable, then 3330 the entry in the midcomConfigFirewallTable MUST be deleted. 3332 If the object has a value of 0, then values specified by 3333 further objects of the same entry apply to all interfaces 3334 for which there is no explicit entry in the 3335 midcomConfigFirewallTable." 3336 ::= { midcomConfigFirewallEntry 1 } 3338 midcomConfigFirewallGroupId OBJECT-TYPE 3339 SYNTAX SnmpAdminString 3340 MAX-ACCESS read-write 3341 STATUS current 3342 DESCRIPTION 3343 "The firewall rule group to which all firewall rules are 3344 assigned that the MIDCOM server creates for the interface 3345 indicated by object midcomConfigFirewallIndex. If the 3346 value of object midcomConfigFirewallIndex is 0, then all 3347 firewall rules of the MIDCOM server that are created for 3348 interfaces with no specific entry in the 3349 midcomConfigFirewallTable are assigned to the firewall 3350 rule group indicated by the value of this object." 3351 ::= { midcomConfigFirewallEntry 2 } 3353 midcomConfigFirewallPriority OBJECT-TYPE 3354 SYNTAX Unsigned32 3355 MAX-ACCESS read-write 3356 STATUS current 3357 DESCRIPTION 3358 "The priority assigned to all firewall rules that the 3359 MIDCOM server creates for the interface indicated by 3360 object midcomConfigFirewallIndex. If the value of object 3361 midcomConfigFirewallIndex is 0, then this priority is 3362 assigned to all firewall rules of the MIDCOM server that 3363 are created for interfaces for which there is no specific 3364 entry in the midcomConfigFirewallTable." 3365 ::= { midcomConfigFirewallEntry 3 } 3367 -- 3368 -- Monitoring Objects 3369 -- 3370 -- Monitoring objects are structured into two groups, 3371 -- the midcomResourceGroup providing information about used 3372 -- resources and the midcomStatisticsGroup providing information 3373 -- about MIDCOM transaction statistics. 3375 -- 3376 -- Resources subtree 3377 -- 3378 -- The MIDCOM resources subtree contains a set of managed 3379 -- objects describing the currently used resources of NAT 3380 -- and firewall implementations. 3381 -- 3383 -- 3384 -- Textual conventions for objects of the resource subtree 3385 -- 3387 MidcomNatBindMode ::= TEXTUAL-CONVENTION 3388 STATUS current 3389 DESCRIPTION 3390 "An indicator of the kind of NAT resources used by a policy 3391 rule. This definition corresponds to the definition of 3392 NatBindMode in the NAT-MIB (RFC4008). Value none(3) can 3393 be used to indicate that the policy rule does not use 3394 any NAT binding. 3395 " 3396 SYNTAX INTEGER { 3397 addressBind(1), 3398 addressPortBind(2), 3399 none(3) 3400 } 3402 MidcomNatSessionIdOrZero ::= TEXTUAL-CONVENTION 3403 DISPLAY-HINT "d" 3404 STATUS current 3405 DESCRIPTION 3406 "A unique ID that is assigned to each NAT session by 3407 a NAT implementation. This definition corresponds to 3408 the definition of NatSessionId in the NAT-MIB (RFC4008). 3409 Value 0 can be used to indicate that policy rule does 3410 not use any NAT binding" 3411 SYNTAX Unsigned32 3413 -- 3414 -- The MIDCOM resource table 3415 -- 3417 midcomResourceTable OBJECT-TYPE 3418 SYNTAX SEQUENCE OF MidcomResourceEntry 3419 MAX-ACCESS not-accessible 3420 STATUS current 3421 DESCRIPTION 3422 "This table lists all used middlebox resources per 3423 MIDCOM policy rule. 3425 The midcomResourceTable augments the 3426 midcomRuleTable." 3427 ::= { midcomMonitoring 1 } 3429 midcomResourceEntry OBJECT-TYPE 3430 SYNTAX MidcomResourceEntry 3431 MAX-ACCESS not-accessible 3432 STATUS current 3433 DESCRIPTION 3434 "An entry describing a particular set of middlebox 3435 resources." 3436 AUGMENTS { midcomRuleEntry } 3437 ::= { midcomResourceTable 1 } 3439 MidcomResourceEntry ::= SEQUENCE { 3440 midcomRscNatInternalAddrBindMode MidcomNatBindMode, 3441 midcomRscNatInternalAddrBindId NatBindIdOrZero, 3442 midcomRscNatInsideAddrBindMode MidcomNatBindMode, 3443 midcomRscNatInsideAddrBindId NatBindIdOrZero, 3444 midcomRscNatSessionId1 MidcomNatSessionIdOrZero, 3445 midcomRscNatSessionId2 MidcomNatSessionIdOrZero, 3446 midcomRscFirewallRuleId Unsigned32 3447 } 3449 midcomRscNatInternalAddrBindMode OBJECT-TYPE 3450 SYNTAX MidcomNatBindMode 3451 MAX-ACCESS read-only 3452 STATUS current 3453 DESCRIPTION 3454 "An indication whether this policy rule uses an address 3455 NAT bind or an address-port NAT bind for binding the 3456 internal address. 3458 If the MIDCOM MIB module is operated together with 3459 the NAT MIB module (RFC 4008) then object 3460 midcomRscNatInternalAddrBindMode contains the same 3461 value as the corresponding object 3462 natSessionPrivateSrcEPBindMode of the NAT MIB module." 3463 ::= { midcomResourceEntry 4 } 3465 midcomRscNatInternalAddrBindId OBJECT-TYPE 3466 SYNTAX NatBindIdOrZero 3467 MAX-ACCESS read-only 3468 STATUS current 3469 DESCRIPTION 3470 "This object references to the allocated internal NAT 3471 bind that is used by this policy rule. A NAT bind 3472 describes the mapping of internal addresses to 3473 outside addresses. MIDCOM MIB implementations can 3474 read this object to learn the corresponding NAT bind 3475 resource for this particular policy rule. 3477 If the MIDCOM MIB module is operated together with 3478 the NAT MIB module (RFC 4008) then object 3479 midcomRscNatInternalAddrBindId contains the same 3480 value as the corresponding object 3481 natSessionPrivateSrcEPBindId of the NAT MIB module." 3482 ::= { midcomResourceEntry 5 } 3484 midcomRscNatInsideAddrBindMode OBJECT-TYPE 3485 SYNTAX MidcomNatBindMode 3486 MAX-ACCESS read-only 3487 STATUS current 3488 DESCRIPTION 3489 "An indication whether this policy rule uses an address 3490 NAT bind or an address-port NAT bind for binding the 3491 external address. 3493 If the MIDCOM MIB module is operated together with 3494 the NAT MIB module (RFC 4008) then object 3495 midcomRscNatInsideAddrBindMode contains the same 3496 value as the corresponding object 3497 natSessionPrivateDstEPBindMode of the NAT MIB module." 3498 ::= { midcomResourceEntry 6 } 3500 midcomRscNatInsideAddrBindId OBJECT-TYPE 3501 SYNTAX NatBindIdOrZero 3502 MAX-ACCESS read-only 3503 STATUS current 3504 DESCRIPTION 3505 "This object references to the allocated external NAT 3506 bind that is used by this policy rule. A NAT bind 3507 describes the mapping of external addresses to 3508 inside addresses. MIDCOM MIB implementations can 3509 read this object to learn the corresponding NAT bind 3510 resource for this particular policy rule. 3512 If the MIDCOM MIB module is operated together with the 3513 NAT MIB module (RFC 4008) then object 3514 midcomRscNatInsideAddrBindId contains the same 3515 value as the corresponding object 3516 natSessionPrivateDstEPBindId of the NAT MIB module." 3517 ::= { midcomResourceEntry 7 } 3519 midcomRscNatSessionId1 OBJECT-TYPE 3520 SYNTAX MidcomNatSessionIdOrZero 3521 MAX-ACCESS read-only 3522 STATUS current 3523 DESCRIPTION 3524 "This object references to the first allocated NAT 3525 session for this policy rule. MIDCOM MIB 3526 implementations can read this object to learn 3527 whether a NAT session for a particular policy rule is 3528 used or not. A value of 0 means that no NAT session 3529 is allocated for this policy rule. A value other than 3530 0 references to the NAT session." 3531 ::= { midcomResourceEntry 8 } 3533 midcomRscNatSessionId2 OBJECT-TYPE 3534 SYNTAX MidcomNatSessionIdOrZero 3535 MAX-ACCESS read-only 3536 STATUS current 3537 DESCRIPTION 3538 "This object references to the second allocated NAT 3539 session for this policy rule. MIDCOM MIB 3540 implementations can read this object to learn 3541 whether a NAT session for a particular policy rule is 3542 used or not. A value of 0 means that no NAT session 3543 is allocated for this policy rule. A value other than 3544 0 references to the NAT session." 3545 ::= { midcomResourceEntry 9 } 3547 midcomRscFirewallRuleId OBJECT-TYPE 3548 SYNTAX Unsigned32 3549 MAX-ACCESS read-only 3550 STATUS current 3551 DESCRIPTION 3552 "This object references to the allocated firewall 3553 rule in the firewall engine for this policy rule. 3554 MIDCOM MIB implementations can read this value to 3555 learn whether a firewall rule for this particular 3556 policy rule is used or not. A value of 0 means that 3557 no firewall rule is allocated for this policy rule. 3558 A value other than 0 references to the firewall rule 3559 number within the firewall engine." 3560 ::= { midcomResourceEntry 10 } 3562 -- 3563 -- Statistics subtree 3564 -- 3565 -- The MIDCOM statistics subtree contains a set of managed 3566 -- objects providing statistics about the usage of transaction 3567 -- objects. 3568 -- 3570 midcomStatistics OBJECT IDENTIFIER ::= { midcomMonitoring 2 } 3572 midcomCurrentOwners OBJECT-TYPE 3573 SYNTAX Gauge32 3574 MAX-ACCESS read-only 3575 STATUS current 3576 DESCRIPTION 3577 "The number of different values for midcomRuleOwner 3578 for all current entries in the midcomRuleTable." 3579 ::= { midcomStatistics 1 } 3581 midcomTotalRejectedRuleEntries OBJECT-TYPE 3582 SYNTAX Counter32 3583 MAX-ACCESS read-only 3584 STATUS current 3585 DESCRIPTION 3586 "The total number of failed attempts to create an entry 3587 in the midcomRuleTable." 3588 ::= { midcomStatistics 2 } 3590 midcomCurrentRulesIncomplete OBJECT-TYPE 3591 SYNTAX Gauge32 3592 MAX-ACCESS read-only 3593 STATUS current 3594 DESCRIPTION 3595 "The current number of policy rules that are incomplete. 3597 Policy rules are loaded via row entries in midcomRuleTable. 3598 This object counts policy rules that are loaded but not 3599 fully specified, i.e., they are in state newEntry(1) or 3600 setting(2)." 3601 ::= { midcomStatistics 3 } 3603 midcomTotalIncorrectReserveRules OBJECT-TYPE 3604 SYNTAX Counter32 3605 MAX-ACCESS read-only 3606 STATUS current 3607 DESCRIPTION 3608 "The total number of policy reserve rules that failed 3609 parameter check and entered state incorrectRequest(4)." 3610 ::= { midcomStatistics 4 } 3612 midcomTotalRejectedReserveRules OBJECT-TYPE 3613 SYNTAX Counter32 3614 MAX-ACCESS read-only 3615 STATUS current 3616 DESCRIPTION 3617 "The total number of policy reserve rules that failed 3618 while being processed and entered state requestRejected(6)." 3619 ::= { midcomStatistics 5 } 3621 midcomCurrentActiveReserveRules OBJECT-TYPE 3622 SYNTAX Gauge32 3623 MAX-ACCESS read-only 3624 STATUS current 3625 DESCRIPTION 3626 "The number of currently active policy reserve rules." 3627 ::= { midcomStatistics 6 } 3629 midcomTotalExpiredReserveRules OBJECT-TYPE 3630 SYNTAX Counter32 3631 MAX-ACCESS read-only 3632 STATUS current 3633 DESCRIPTION 3634 "The total number of expired policy reserve rules 3635 (entered termination state timedOut(9))." 3636 ::= { midcomStatistics 7 } 3638 midcomTotalTerminatedOnRqReserveRules OBJECT-TYPE 3639 SYNTAX Counter32 3640 MAX-ACCESS read-only 3641 STATUS current 3642 DESCRIPTION 3643 "The total number of policy reserve rules that were 3644 terminated on request (entered termination state 3645 terminatedOnRequest(10))." 3646 ::= { midcomStatistics 8 } 3648 midcomTotalTerminatedReserveRules OBJECT-TYPE 3649 SYNTAX Counter32 3650 MAX-ACCESS read-only 3651 STATUS current 3652 DESCRIPTION 3653 "The total number of policy reserve rules that were 3654 terminated, but not on request (entered termination state 3655 terminated(11))." 3656 ::= { midcomStatistics 9 } 3658 midcomTotalIncorrectEnableRules OBJECT-TYPE 3659 SYNTAX Counter32 3660 MAX-ACCESS read-only 3661 STATUS current 3662 DESCRIPTION 3663 "The total number of policy enable rules that failed 3664 parameter check and entered state incorrectRequest(4)." 3665 ::= { midcomStatistics 10 } 3667 midcomTotalRejectedEnableRules OBJECT-TYPE 3668 SYNTAX Counter32 3669 MAX-ACCESS read-only 3670 STATUS current 3671 DESCRIPTION 3672 "The total number of policy enable rules that failed 3673 while being processed and entered state requestRejected(6)." 3674 ::= { midcomStatistics 11 } 3676 midcomCurrentActiveEnableRules OBJECT-TYPE 3677 SYNTAX Gauge32 3678 MAX-ACCESS read-only 3679 STATUS current 3680 DESCRIPTION 3681 "The number of currently active policy enable rules." 3682 ::= { midcomStatistics 12 } 3684 midcomTotalExpiredEnableRules OBJECT-TYPE 3685 SYNTAX Counter32 3686 MAX-ACCESS read-only 3687 STATUS current 3688 DESCRIPTION 3689 "The total number of expired policy enable rules 3690 (entered termination state timedOut(9))." 3691 ::= { midcomStatistics 13 } 3693 midcomTotalTerminatedOnRqEnableRules OBJECT-TYPE 3694 SYNTAX Counter32 3695 MAX-ACCESS read-only 3696 STATUS current 3697 DESCRIPTION 3698 "The total number of policy enable rules that were 3699 terminated on request (entered termination state 3700 terminatedOnRequest(10))." 3701 ::= { midcomStatistics 14 } 3703 midcomTotalTerminatedEnableRules OBJECT-TYPE 3704 SYNTAX Counter32 3705 MAX-ACCESS read-only 3706 STATUS current 3707 DESCRIPTION 3708 "The total number of policy enable rules that were 3709 terminated, but not on request (entered termination state 3710 terminated(11))." 3711 ::= { midcomStatistics 15 } 3713 -- 3714 -- Notifications. 3715 -- 3717 midcomUnsolicitedRuleEvent NOTIFICATION-TYPE 3718 OBJECTS { midcomRuleOperStatus, midcomRuleLifetime } 3719 STATUS current 3720 DESCRIPTION 3721 "This notification is generated whenever the value of 3722 midcomRuleOperStatus enters any error state or any 3723 termination state without an explicit trigger by a 3724 MIDCOM client." 3726 ::= { midcomNotifications 1 } 3728 midcomSolicitedRuleEvent NOTIFICATION-TYPE 3729 OBJECTS { midcomRuleOperStatus, midcomRuleLifetime } 3730 STATUS current 3731 DESCRIPTION 3732 "This notification is generated whenever the value 3733 of midcomRuleOperStatus enters one of the states 3734 {reserved, enabled, any error state, any termination state} 3735 as a result of a MIDCOM agent writing successfully to 3736 object midcomRuleAdminStatus. 3738 In addition, it is generated when the lifetime of 3739 a rule was changed by successfully writing to object 3740 midcomRuleLifetime." 3741 ::= { midcomNotifications 2 } 3743 midcomSolicitedGroupEvent NOTIFICATION-TYPE 3744 OBJECTS { midcomGroupLifetime } 3745 STATUS current 3746 DESCRIPTION 3747 "This notification is generated for indicating that the 3748 lifetime of all member rules of the group was changed by 3749 successfully writing to object midcomGroupLifetime. 3751 Note that this notification is only sent if the lifetime 3752 of a group was changed by successfully writing to object 3753 midcomGroupLifetime. No notification is sent 3754 - if a group's lifetime is changed by writing to object 3755 midcomRuleLifetime of any of its member policies, 3756 - if a group's lifetime expires (in this case 3757 notifications are sent for all member policies) 3758 - if the group is terminated by terminating the last 3759 of its member policies without writing to object 3760 midcomGroupLifetime." 3761 ::= { midcomNotifications 3 } 3763 -- 3764 -- Conformance information 3765 -- 3767 midcomCompliances OBJECT IDENTIFIER ::= { midcomConformance 1 } 3768 midcomGroups OBJECT IDENTIFIER ::= { midcomConformance 2 } 3770 -- 3771 -- compliance statements 3772 -- 3774 -- This is the MIDCOM compliance definition ... 3776 -- 3778 midcomCompliance MODULE-COMPLIANCE 3779 STATUS current 3780 DESCRIPTION 3781 "The compliance statement for implementations of the 3782 MIDCOM MIB module. 3784 Note that compliance with this compliance 3785 statement requires compliance with the 3786 ifCompliance3 MODULE-COMPLIANCE statement of the 3787 IF-MIB [RFC2863]." 3788 MODULE -- this module 3789 MANDATORY-GROUPS { 3790 midcomRuleGroup, 3791 midcomNotificationsGroup, 3792 midcomCapabilitiesGroup, 3793 midcomStatisticsGroup 3794 } 3795 GROUP midcomConfigFirewallGroup 3796 DESCRIPTION 3797 "A compliant implementation does not have to implement 3798 the midcomConfigFirewallGroup." 3799 GROUP midcomResourceGroup 3800 DESCRIPTION 3801 "A compliant implementation does not have to implement 3802 the midcomResourceGroup." 3803 OBJECT midcomRuleInternalIpPrefixLength 3804 MIN-ACCESS read-only 3805 DESCRIPTION 3806 "Write access is not required. When write access is 3807 not supported return 128 as the value of this object. 3808 A value of 128 means that the function represented by 3809 this option is not supported." 3810 OBJECT midcomRuleExternalIpPrefixLength 3811 MIN-ACCESS read-only 3812 DESCRIPTION 3813 "Write access is not required. When write access is 3814 not supported return 128 as the value of this object. 3815 A value of 128 means that the function represented by 3816 this option is not supported." 3817 OBJECT midcomRuleMaxIdleTime 3818 MIN-ACCESS read-only 3819 DESCRIPTION 3820 "Write access is not required. When write access is 3821 not supported return 0 as the value of this object. 3822 A value of 0 means that the function represented by 3823 this option is not supported." 3824 OBJECT midcomRuleInterface 3825 MIN-ACCESS read-only 3826 DESCRIPTION 3827 "Write access is not required." 3828 OBJECT midcomConfigMaxLifetime 3829 MIN-ACCESS read-only 3830 DESCRIPTION 3831 "Write access is not required." 3832 OBJECT midcomConfigPersistentRules 3833 MIN-ACCESS read-only 3834 DESCRIPTION 3835 "Write access is not required." 3836 OBJECT midcomConfigIfEnabled 3837 MIN-ACCESS read-only 3838 DESCRIPTION 3839 "Write access is not required." 3840 OBJECT midcomConfigFirewallGroupId 3841 MIN-ACCESS read-only 3842 DESCRIPTION 3843 "Write access is not required." 3844 OBJECT midcomConfigFirewallPriority 3845 MIN-ACCESS read-only 3846 DESCRIPTION 3847 "Write access is not required." 3848 ::= { midcomCompliances 1 } 3850 midcomRuleGroup OBJECT-GROUP 3851 OBJECTS { 3852 midcomRuleAdminStatus, 3853 midcomRuleOperStatus, 3854 midcomRuleStorageType, 3855 midcomRuleStorageTime, 3856 midcomRuleError, 3857 midcomRuleInterface, 3858 midcomRuleFlowDirection, 3859 midcomRuleMaxIdleTime, 3860 midcomRuleTransportProtocol, 3861 midcomRulePortRange, 3862 midcomRuleInternalIpVersion, 3863 midcomRuleExternalIpVersion, 3864 midcomRuleInternalIpAddr, 3865 midcomRuleInternalIpPrefixLength, 3866 midcomRuleInternalPort, 3867 midcomRuleExternalIpAddr, 3868 midcomRuleExternalIpPrefixLength, 3869 midcomRuleExternalPort, 3870 midcomRuleInsideIpAddr, 3871 midcomRuleInsidePort, 3872 midcomRuleOutsideIpAddr, 3873 midcomRuleOutsidePort, 3874 midcomRuleLifetime, 3875 midcomRuleRowStatus, 3876 midcomGroupLifetime 3877 } 3878 STATUS current 3879 DESCRIPTION 3880 "A collection of objects providing information about 3881 policy rules and policy rule groups." 3882 ::= { midcomGroups 1 } 3884 midcomCapabilitiesGroup OBJECT-GROUP 3885 OBJECTS { 3886 midcomConfigMaxLifetime, 3887 midcomConfigPersistentRules, 3888 midcomConfigIfBits, 3889 midcomConfigIfEnabled 3890 } 3891 STATUS current 3892 DESCRIPTION 3893 "A collection of objects providing information about 3894 the capabilities of a middlebox." 3895 ::= { midcomGroups 2 } 3897 midcomConfigFirewallGroup OBJECT-GROUP 3898 OBJECTS { 3899 midcomConfigFirewallGroupId, 3900 midcomConfigFirewallPriority 3901 } 3902 STATUS current 3903 DESCRIPTION 3904 "A collection of objects providing information about 3905 the firewall rule group and firewall rule priority to 3906 be used by firewalls loaded through MIDCOM." 3907 ::= { midcomGroups 3 } 3909 midcomResourceGroup OBJECT-GROUP 3910 OBJECTS { 3911 midcomRscNatInternalAddrBindMode, 3912 midcomRscNatInternalAddrBindId, 3913 midcomRscNatInsideAddrBindMode, 3914 midcomRscNatInsideAddrBindId, 3915 midcomRscNatSessionId1, 3916 midcomRscNatSessionId2, 3917 midcomRscFirewallRuleId 3918 } 3919 STATUS current 3920 DESCRIPTION 3921 "A collection of objects providing information about 3922 the used NAT and firewall resources." 3923 ::= { midcomGroups 4 } 3925 midcomStatisticsGroup OBJECT-GROUP 3926 OBJECTS { 3927 midcomCurrentOwners, 3928 midcomTotalRejectedRuleEntries, 3929 midcomCurrentRulesIncomplete, 3930 midcomTotalIncorrectReserveRules, 3931 midcomTotalRejectedReserveRules, 3932 midcomCurrentActiveReserveRules, 3933 midcomTotalExpiredReserveRules, 3934 midcomTotalTerminatedOnRqReserveRules, 3935 midcomTotalTerminatedReserveRules, 3936 midcomTotalIncorrectEnableRules, 3937 midcomTotalRejectedEnableRules, 3938 midcomCurrentActiveEnableRules, 3939 midcomTotalExpiredEnableRules, 3940 midcomTotalTerminatedOnRqEnableRules, 3941 midcomTotalTerminatedEnableRules 3942 } 3943 STATUS current 3944 DESCRIPTION 3945 "A collection of objects providing statistical 3946 information about the MIDCOM server." 3947 ::= { midcomGroups 5 } 3949 midcomNotificationsGroup NOTIFICATION-GROUP 3950 NOTIFICATIONS { 3951 midcomUnsolicitedRuleEvent, 3952 midcomSolicitedRuleEvent, 3953 midcomSolicitedGroupEvent 3954 } 3955 STATUS current 3956 DESCRIPTION 3957 "The notifications emitted by the midcomMIB." 3958 ::= { midcomGroups 6 } 3960 END 3962 10. Security Considerations 3964 Obviously, securing access to firewall and NAT configuration is 3965 extremely important for maintaining network security. This section 3966 first describes general security issues of the MIDCOM MIB module and 3967 then discusses three concrete security threats: unauthorized 3968 middlebox configuration, unauthorized access to middlebox 3969 configuration information and unauthorized access to the MIDCOM 3970 service configuration. 3972 10.1. General Security Issues 3974 There are a number of management objects defined in this MIB module 3975 with a MAX-ACCESS clause of read-write and/or read-create. Such 3976 objects may be considered sensitive or vulnerable in some network 3977 environments. But also access to managed objects with a MAX-ACCESS 3978 clause of read-only may be considered sensitive or vulnerable. The 3979 support for SET and GET operations in a non-secure environment 3980 without proper protection can have a negative effect on network 3981 operations. 3983 SNMP versions prior to SNMPv3 did not include adequate security. 3984 Even if the network itself is secure (for example by using IPsec), 3985 even then, there is no control as to who on the secure network is 3986 allowed to access and GET/SET (read/change/create/delete) the objects 3987 in this MIB module. 3989 Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. 3991 Compliant MIDCOM MIB implementations MUST support SNMPv3 security 3992 services including data integrity, identity authentication, data 3993 confidentiality, and replay protection.. 3995 It is REQUIRED that the implementations support the security features 3996 as provided by the SNMPv3 framework. Specifically, the use of the 3997 User-based Security Model RFC 3414 [RFC3414] and the View- based 3998 Access Control Model RFC 3415 [RFC3415] is RECOMMENDED. 4000 It is then a customer/operator responsibility to ensure that the SNMP 4001 entity giving access to an instance of this MIB, is properly 4002 configured to give access to the objects only to those principals 4003 (users) that have legitimate rights to indeed GET or SET 4004 (change/create/delete) them. 4006 To facilitate the provisioning of access control by a security 4007 administrator using the View-Based Access Control Model (VACM) 4008 defined in RFC 3415 [RFC3415] for tables in which multiple users may 4009 need to independently create or modify entries, the initial index is 4010 used as an "owner index". This is supported by the midcomRuleTable 4011 and the midcomGroupTable. Each of them uses midcomRuleOwner as 4012 initial index. midcomRuleOwner has the syntax of SnmpAdminString, 4013 and can thus be trivially mapped to a SNMP securityName or a 4014 groupName as defined in VACM, in accordance with a security policy. 4016 All entries in the two mentioned tables belonging to a particular 4017 user will have the same value for this initial index. For a given 4018 user's entries in a particular table, the object identifiers for the 4019 information in these entries will have the same subidentifiers 4020 (except for the "column" subidentifier) up to the end of the encoded 4021 owner index. To configure VACM to permit access to this portion of 4022 the table, one would create vacmViewTreeFamilyTable entries with the 4023 value of vacmViewTreeFamilySubtree including the owner index portion, 4024 and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. 4025 More elaborate configurations are possible. 4027 10.2. Unauthorized Middlebox Configuration 4029 The most dangerous threat to network security related to the MIDCOM 4030 MIB module is unauthorized access to facilities for establishing 4031 policy rules. In such a case, unauthorized principals would write to 4032 the midcomRuleTable for opening firewall pinholes and/or for creating 4033 NAT maps, bindings and/or sessions. Establishing policies can be 4034 used to gain access to networks and systems that are protected by 4035 firewalls and/or NATs. 4037 If this protection is removed by unauthorized access to MIDCOM MIB 4038 policies, then the resulting degradation of network security can be 4039 severe. Confidential information protected by a firewall might 4040 become accessible to unauthorized principals, attacks exploiting 4041 security leaks of systems in the protected network might become 4042 possible from external networks and it might be possible to stop 4043 firewalls blocking denial of service attacks. 4045 MIDCOM MIB implementations MUST provide means for strict 4046 authentication, message integrity check and write access control to 4047 managed objects that can be used for establishing policy rules. 4048 These are objects in the midcomRuleTable and midcomGroupTable with a 4049 MAX-ACCESS clause of read-write and/or read-create. 4051 Particularly sensitive is write access to the managed object 4052 midcomRuleAdminStatus, because writing it causes policy rules to be 4053 established. 4055 Also writing to other managed objects in the two tables can make 4056 security vulnerable if it interferes with the authorized 4057 establishment of a policy rule, for example by wildcarding a policy 4058 rule after the corresponding entry in the midcomRuleTable is created, 4059 but before the authorized owner establishes the rule by writing to 4060 midcomRuleAdminStatus. 4062 Not only unauthorized establishment, but also unauthorized lifetime 4063 extension of an existing policy rule may be considered sensitive or 4064 vulnerable in some network environments. Therefore, means for strict 4065 authentication, message integrity check and write access control to 4066 managed object midcomGroupLifetime MUST be provided by MIDCOM MIB 4067 implementations. 4069 10.3. Unauthorized Access to Middlebox Configuration 4071 Another threat to network security is unauthorized access to entries 4072 in the midcomRuleTable. The entries contain information about 4073 existing pinholes in the firewall and/or about the current NAT 4074 configuration. This information can be used for attacking the 4075 internal network from outside. Therefore, a MIDCOM MIB 4076 implementation MUST also provide means for read access control to the 4077 midcomRuleTable. 4079 Also, a MIDCOM MIB implementation SHOULD provide means for protecting 4080 different authenticated MIDCOM agents from each other, such that, for 4081 example, an authenticated user can only read entries in the 4082 midcomRuleTable for which the initial index midcomRuleOwner matches 4083 the client's SNMP securityName or VACM groupName. 4085 10.4. Unauthorized Access to MIDCOM Service Configuration 4087 There are three objects with a MAX-ACCESS clause of read-write that 4088 configure the MIDCOM service: midcomConfigIfEnabled, 4089 midcomFirewallGroupId and midcomFirewallPriority. 4091 Unauthorized writing to object midcomConfigIfEnabled can cause 4092 serious interruptions of network service. 4094 Writing to midcomFirewallGroupId and/or midcomFirewallPriority can be 4095 used to increase or reduce the priority of firewall rules that are 4096 generated when a policy rule is established in the midcomRuleTable. 4097 Increasing the priority might permit firewall rules generated via the 4098 MIDCOM MIB module to overrule basic security rules at the firewall 4099 that should have higher priority than the ones generated via the 4100 MIDCOM MIB module. 4102 Therefore also for these objects, means for strict control of write 4103 access MUST be provided by a MIDCOM MIB implementation. 4105 11. Acknowledgements 4107 This memo is based on a long history of discussion within the MIDCOM 4108 MIB design team. Many thanks to Mary Barnes, Jeff Case, Wes 4109 Hardaker, David Harrington and Tom Taylor for fruitful comments and 4110 recommendations and to Juergen Schoenwaelder acting as very 4111 constructive MIB doctor. 4113 12. IANA Considerations 4115 This document requires an OID assignment to be made by IANA: 4117 Descriptor OBJECT IDENTIFIER value 4118 ---------- ----------------------- 4119 midcomMIB { mib-2 xxxxx } 4121 13. Normative References 4123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4124 Requirement Levels", BCP 14, RFC 2119, March 1997. 4126 [I-D.ietf-midcom-rfc3989-bis] 4127 Stiemerling, M., Quittek, J. and T. Tailor, "Middlebox 4128 Communications (MIDCOM) Protocol Semantics", work in 4129 progress, June 2007. 4131 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 4132 Rose, M. and S. Waldbusser, "Structure of Management 4133 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 4134 1999. 4136 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 4137 Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", 4138 STD 58, RFC 2579, April 1999. 4140 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 4141 Rose, M. and S. Waldbusser, "Conformance Statements for 4142 SMIv2", STD 58, RFC 2580, April 1999. 4144 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 4145 MIB", RFC 2863, June 2000. 4147 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture 4148 for Describing Simple Network Management Protocol (SNMP) 4149 Management Frameworks", STD 62, RFC 3411, December 2002. 4151 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 4152 Management Protocol Applications", STD 62, RFC 3413, 4153 December 2002. 4155 [RFC3414] Blumenthal, U., and B. Wijnen, "User-based Security Model 4156 (USM) for version 3 of the Simple Network Management 4157 Protocol (SNMPv3)", RFC 3414, December 2002. 4159 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 4160 Simple Network Management Protocol (SNMP)", STD 62, RFC 4161 3418, December 2002. 4163 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 4164 "RTP: A Transport Protocol for Real-Time Applications", STD 4165 64, RFC 3550, July 2003. 4167 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 4168 Schoenwaelder, "Textual Conventions for Internet Network 4169 Addresses", RFC 4001, February 2005. 4171 [RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. 4172 Wang, "Definitions of Managed Objects for Network Address 4173 Translators (NAT)", RFC 4008, March 2005. 4175 14. Informative References 4177 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 4178 "Introduction and Applicability Statements for Internet- 4179 Standard Management Framework", RFC 3410, December 2002. 4181 [RFC3234] Carpenter, B., and S. Brim, "Middleboxes: Taxonomy and 4182 Issues", RFC 3234, February 2002. 4184 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 4185 Rayhan, "Middlebox communication architecture and 4186 framework", RFC 3303, August 2002. 4188 [RFC3304] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S. and M. Shore, 4189 "Middlebox Communications (midcom) Protocol Requirements", 4190 RFC 3304, August 2002. 4192 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 4193 Access Control Model (VACM) for the Simple Network 4194 Management Protocol (SNMP)", STD 62, RFC 3415, December 4195 2002. 4197 15. Authors' Addresses 4199 Juergen Quittek 4200 NEC Europe Ltd. 4201 Network Laboratories 4202 Kurfuersten-Anlage 36 4203 69115 Heidelberg 4204 Germany 4206 Phone: +49 6221 4342-115 4207 EMail: quittek@nw.neclab.eu 4209 Martin Stiemerling 4210 NEC Europe Ltd. 4211 Network Laboratories 4212 Kurfuersten-Anlage 36 4213 69115 Heidelberg 4214 Germany 4216 Phone: +49 6221 4342-113 4217 Email: stiemerling@nw.neclab.eu 4219 Pyda Srisuresh 4220 Consultant 4221 20072 Pacifica Dr. 4222 Cupertino, CA 95014 4223 USA 4224 Tel: +1 408 836 4773 4225 Email: srisuresh@yahoo.com 4227 Full Copyright Statement 4229 Copyright (C) The IETF Trust (2007). 4231 This document is subject to the rights, licenses and restrictions 4232 contained in BCP 78, and except as set forth therein, the authors 4233 retain all their rights. 4235 This document and the information contained herein are provided on an 4236 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4237 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4238 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4239 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4240 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4241 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4243 Intellectual Property 4245 The IETF takes no position regarding the validity or scope of any 4246 Intellectual Property Rights or other rights that might be claimed to 4247 pertain to the implementation or use of the technology described in 4248 this document or the extent to which any license under such rights 4249 might or might not be available; nor does it represent that it has 4250 made any independent effort to identify any such rights. Information 4251 on the procedures with respect to rights in RFC documents can be 4252 found in BCP 78 and BCP 79. 4254 Copies of IPR disclosures made to the IETF Secretariat and any 4255 assurances of licenses to be made available, or the result of an 4256 attempt made to obtain a general license or permission for the use of 4257 such proprietary rights by implementers or users of this 4258 specification can be obtained from the IETF on-line IPR repository at 4259 http://www.ietf.org/ipr. 4261 The IETF invites any interested party to bring to its attention any 4262 copyrights, patents or patent applications, or other proprietary 4263 rights that may cover technology that may be required to implement 4264 this standard. Please address the information to the IETF at 4265 ietf-ipr@ietf.org. 4267 Acknowledgment 4269 Funding for the RFC Editor function is provided by the IETF 4270 Administrative Support Activity (IASA).