idnits 2.17.1 draft-stiemerling-midcom-mib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 9 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2499 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7492 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 107, but not defined == Missing Reference: 'RFC3234' is mentioned on line 127, but not defined == Missing Reference: 'RFC3414' is mentioned on line 207, but not defined == Missing Reference: 'RFC3415' is mentioned on line 209, but not defined == Unused Reference: 'RFC3411' is defined on line 2436, but no explicit reference was found in the text == Unused Reference: 'RFC2574' is defined on line 2443, but no explicit reference was found in the text == Unused Reference: 'NAT-TERM' is defined on line 2453, but no explicit reference was found in the text == Unused Reference: 'RFC2246' is defined on line 2456, but no explicit reference was found in the text == Unused Reference: 'RFC2402' is defined on line 2459, but no explicit reference was found in the text == Unused Reference: 'RFC2406' is defined on line 2462, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3303 ** Downref: Normative reference to an Informational RFC: RFC 3304 -- Possible downref: Non-RFC (?) normative reference: ref. 'RFCXXXX' ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (Obsoleted by RFC 4303, RFC 4305) Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft J. Quittek 2 Document: draft-stiemerling-midcom-mib-00.txt M. Stiemerling 3 Expires: April 2003 NEC Europe Ltd. 4 October 2003 6 Definitions of Managed Objects for Middlebox Communication 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Distribution of this document is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This memo defines a portion of the Management Information Base (MIB) 38 for use with network management protocols in the Internet community. 39 In particular, it describes a set of managed objects that allow 40 configuring middleboxes, such as firewalls and network address 41 translators, in order to enable communication across these devices. 42 The definitions of managed objects in this documents follows closely 43 the MIDCOM semantics defined in RFC XXXX. 45 Table of Contents 47 1 Introduction ................................................. 2 48 2 The Internet-Standard Management Framework ................... 2 49 3 Overview ..................................................... 2 50 3.1 Terminology ................................................ 3 51 4 Realizing the MIDCOM Protocol with SNMP ...................... 3 52 4.1 MIDCOM Sessions ............................................ 3 53 4.1.1 Authentication and Authorization ......................... 4 54 4.2 MIDCOM Transactions ........................................ 4 55 4.2.1 Asynchronous Transactions ................................ 4 56 4.2.2 Configuration Transactions ............................... 6 57 4.2.3 Configuration Transactions ............................... 8 58 4.2.4 Atomicity or Transactions ................................ 10 59 4.2.4.1 Asynchronous Transactions .............................. 10 60 4.2.4.2 Session Establishment and Termination Transactions ..... 10 61 4.2.4.3 Monitoring Transactions ................................ 10 62 4.2.4.4 Lifetime Change Transactions ........................... 11 63 4.2.4.5 Transactions Establishing New Policy Rules ............. 11 64 4.2.5 Access Control ........................................... 11 65 4.3 Access Control Policies .................................... 11 66 5 Structure of the MIB module .................................. 12 67 5.1 midcomCapabilities ......................................... 12 68 5.2 midcomSessionTable ......................................... 13 69 5.3 midcomRuleTable ............................................ 14 70 5.4 midcomGroupTable ........................................... 16 71 5.5 midcomEvent ................................................ 17 72 6 Definitions .................................................. 17 73 7 Usage Examples ............................................... 42 74 7.1 Session Establishment (SE) ................................. 43 75 7.2 Session Termination (ST) ................................... 44 76 7.3 Asynchronous Session Termination (AST) ..................... 44 77 7.4 Policy Reserve Rule (PRR) .................................. 44 78 7.5 Policy Enable Rule (PER) after PRR ......................... 45 79 7.6 Policy Enable Rule (PER) without previous PRR .............. 46 80 7.7 Policy Rule Lifetime Change (RLC) .......................... 47 81 7.8 Policy Rule List (PRL) ..................................... 47 82 7.9 Policy Rule Status (PRS) ................................... 47 83 7.10 Asynchronous Policy Rule Event (ARE) ...................... 47 84 7.11 Group Lifetime Change (GLC) ............................... 48 85 7.12 Group List (GL) ........................................... 48 86 7.13 Group Status (GS) ......................................... 48 87 7.14 Using Notifications For Negative Replies Only ............. 48 88 7.15 Not Using Notifications For Replies ....................... 48 89 8 Security Considerations ...................................... 49 90 9 Open Issues .................................................. 49 91 10 Normative References ........................................ 49 92 11 Informative References ...................................... 50 93 12 Authors' Addresses .......................................... 51 94 13 Full Copyright Statement .................................... 51 96 1. Introduction 98 This memo defines a portion of the Management Information Base (MIB) 99 for use with network management protocols in the Internet community. 100 In particular, it describes a set of managed objects that allow 101 monitoring of running instances of robust header compression. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in RFC 106 2119 [RFC2119]. 108 2. The Internet-Standard Management Framework 110 For a detailed overview of the documents that describe the current 111 Internet-Standard Management Framework, please refer to section 7 of 112 RFC 3410 [RFC3410]. 114 Managed objects are accessed via a virtual information store, termed 115 the Management Information Base or MIB. MIB objects are generally 116 accessed through the Simple Network Management Protocol (SNMP). 117 Objects in the MIB are defined using the mechanisms defined in the 118 Structure of Management Information (SMI). This memo specifies a MIB 119 module that is compliant to the SMIv2, which is described in STD 58, 120 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 121 [RFC2580]. 123 3. Overview 125 The managed objects defined in this document serve for controlling 126 firewalls and Network Address Translators (NATs). As defined in 127 [RFC3234], firewalls and NATs belong to the group of middleboxes. A 128 middlebox is a device on the datagram path between source and 129 destination, which performs other functions than just IP routing. As 130 outlined in [RFC3303], firewalls and NATs are potential obstacles to 131 packet streams, for example if dynamically negotiated UDP or TCP port 132 numbers are used, as in many peer-to-peer communication applications. 134 As one possible solution for this problem, the IETF MIDCOM working 135 group defined a framework [RFC3303], requirements [RFC3304] and 136 protocol semantics [RFCXXXX] for communication between applications 137 and middleboxes acting as firewalls, NATs or a combination of both. 139 The managed objects defined in this document can be used for 140 dynamically configuring middleboxes on the datagram path in order to 141 enable datagram streams to pass the middlebox. This way, 142 applications can request pinholes at firewalls and address bindings 143 at NATs. 145 Since firewalls and NATs are critical devices concerning network 146 security, security issues of middlebox communication need to be 147 considered very carefully. 149 3.1. Terminology 151 The terminology used in this document is fully aligned with the 152 terminology defined in [RFCXXXX]. 154 There is a conflict between the MIDCOM terminology and the SNMP 155 terminology. The roles of entities participating in SNMP 156 communication are called 'manager' and 'agent' with the agent acting 157 as server for requests from the manager. This use of the term 'agent' 158 is different to its use in the MIDCOM framework: The SNMP manager 159 corresponds to the MIDCOM agent and the SNMP agent corresponds to the 160 MIDCOM middlebox. In order to avoid confusion, the term agent is 161 only used in combination with a prefix: either as MIDCOM agent or as 162 SNMP agent. 164 As also mentioned in RFCXXXX, please note that ... bindings!! 166 4. Realizing the MIDCOM Protocol with SNMP 168 In order to realize middlebox communication as described in RFC XXXX, 169 several aspects and properties of the MIDCOM protocol need to be 170 mapped to SNMP capabilities and expressed in terms of the Structure 171 of Management Information version 2 (SMIv2). 173 Basic concepts to be mapped are MIDCOM sessions and MIDCOM 174 transactions. For both, access control policies need to be 175 supported. 177 4.1. MIDCOM Sessions 179 SNMP has no direct support for sessions. Therefore, they need to be 180 modeled. A session is stateful and has a context that is valid for 181 several transactions. For SNMP, a context is valid for a single 182 transaction only, for example covering just a single request/reply 183 pair of messages. 185 Properties of sessions that are utlized by the MIDCOM semantics and 186 not avaiable in SNMP need to be modeled. Particularly, the middlebox 187 needs to be able to send notification messages to agents 188 participating in a session. 190 The midcomSessionTable described in more detail in Section 5.1 191 provides this information. Each MIDCOM agent that opens a session 192 has to create an entry in the midcomSessionTable. This entry 193 identifies the MIDCOM agent as participant of a session and gives the 194 middlebox sufficient information for sending notifications. The 195 MIDCOM-MIB module requires a MIDCOM agent to create an entry in the 196 midcomSessionTable before it creates or modifies MIDCOM policy rules. 197 Without creating an entry in the session table, the MIDCOM agent 198 cannot access any MIDCOM policy rule and it will not receive any 199 notification indicating state changes at the middlebox. 201 4.1.1. Authentication and Authorization 203 MIDCOM sessions are required to provide authentication, authorization 204 and encryption for messages exchanged between MIDCOM agent and 205 middlebox. SNMPv3 provides these features on a per-message basis 206 instead of a per-session basis. This more fine-grained security 207 based on the User-based Security Model (USM, [RFC3414]) providing 208 authentication and the View-based Access control Model (VACM, 209 [RFC3415]) that can be used for authorization of access to managed 210 objects. This can be considered as overhead compared to per-session 211 security mechanisms, but it completely satisfies the security 212 requirements of middlebox communication. 214 Any MIDCOM agent that wants to start a session by creating an entry 215 in the session table needs to authenticate itself as an SNMP user. 216 For the authenticated user, access rights must be given as part of 217 the VACM configuration of the SNMP agent. 219 4.2. MIDCOM Transactions 221 RFCXXXX defines the MIDCOM protocol semantics in terms of 222 transactions and transaction parameters. Transactions are grouped 223 into request-reply transactions and asynchronous transactions. 225 SNMP offers simple transactions that in general cannot be mapped ono- 226 to-one to MIDCOM transactions. This section describes how the MIDCOM 227 MIB module implements MIDCOM transactions using SNMP transactions. 228 The concerned MIDCOM transactions are asynchronous transactions a and 229 request-reply transactions. Within the set of request-reply 230 transactions we distinguish configuration transactions and monitoring 231 transactions, because they are implemented in slightly different ways 232 by using SNMP transactions. 234 4.2.1. Asynchronous Transactions 236 Asynchronous transactions can easily be modeled by SNMP 237 notifications. An asynchronous transaction contains a notification 238 message with one to three parameters. The message can be realized as 239 an SNMP notification with the parameters implemented as managed 240 objects contained in the notification. 242 +--------------+ notification +------------+ 243 | MIDCOM agent |<--------------| middlebox | 244 +--------------+ message +------------+ 246 MIDCOM asynchronous transaction 248 +--------------+ SNMP +------------+ 249 | SNMP manager |<--------------| SNMP agent | 250 +--------------+ notification +------------+ 252 Implementation of MIDCOM asynchronous transaction 254 Figure 1: MIDCOM asynchronous transaction 255 mapped to SNMP notification 257 One of the parameters is the transaction identifier that should be 258 unique per middlebox. It does not have to be unique for all 259 notifications sent by the particular SNMP agent, but for all sent 260 notifications that are defined by the MIDCOM MIB module. 262 4.2.2. Configuration Transactions 264 All request-reply transactions contain a request message, a reply 265 message and potentially also a set of notifications. In general they 266 cannot be modeled by just having one SNMP message per MIDCOM message, 267 because some of the MIDCOM messages carry a large set of parameters 268 that do not necessarily fit into an SNMP message consisting of a 269 single UDP packet only. 271 For configuration transactions the MIDCOM request message can be 272 modeled by one or more SNMP set transactions. The action of sending 273 the MIDCOM request to the middlebox if realized by writing the 274 parameters contained in the message to managed objects at the SNMP 275 agent. If necessary, the SNMP set transaction includes creating 276 these managed objects. If not all parameters of the MIDCOM request 277 message can be set by a single SNMP set transaction, then more than 278 one set transactions are used, see Figure 2. The last one of these 279 messages must clearly indicate that now all parameters are set and 280 that processing of the MIDCOM request message can start at the 281 middlebox. 283 +--------------+ request +------------+ 284 | MIDCOM agent |-------------->| middlebox | 285 +--------------+ message +------------+ 287 MIDCOM request message 289 +--------------+ +------------+ 290 | | SNMP set | | 291 | |-------------->| | 292 | | message | | 293 | | | | 294 | | SNMP set | | 295 | |<--------------| | 296 | | reply message | | 297 | SNMP manager | | SNMP agent | 298 | | SNMP set | | 299 | |- - - - - - - >| | 300 | | message | | 301 | | | | 302 | | SNMP set | | 303 | |< - - - - - - -| | 304 | | reply message | | 305 | | | | 306 | | . . . | | 307 +--------------+ +------------+ 309 Implementation of MIDCOM request message 310 by one or more SNMP set messages 312 Figure 2: MIDCOM request message 313 mapped to SNMP set transactions 315 Please note that a single SNMP set transaction consists of an SNMP 316 set request message and an SNMP set reply message. Both are sent as 317 unreliable UDP packets and may be dropped before they reach their 318 destination. If the SNMP set request message is lost, then the SNMP 319 agent repeats the message after receiving no reply for a specified 320 time. Also if the SNMP set reply message is lost, the SNMP agent 321 retransmit the SNMP set message. But this time, the SNMP agent 322 receives the same message twice and must make sure that it accepts 323 the second message as it did the first one and that it sends an SNMP 324 reply message again. 326 The MIDCOM reply message can be modeled by an SNMP norification 327 transaction optionally followed by one or more SNMP get transactions 328 as shown in Figure 3. The SNMP agent informs the SNMP manager about 329 the end of processing the request by sending an SNMP notification. 331 If possible, the SNMP notification carries all reply parameters. If 332 this is not possible, then the SNMP manager has to perform additional 333 SNMP get transactions as long as is needed to receive all of the 334 reply parameters. 336 +--------------+ reply +------------+ 337 | MIDCOM agent |<--------------| middlebox | 338 +--------------+ message +------------+ 340 MIDCOM reply message 342 +--------------+ +------------+ 343 | | SNMP | | 344 | |<--------------| | 345 | | notification | | 346 | | | | 347 | | SNMP get | | 348 | |-------------->| | 349 | | message | | 350 | SNMP manager | | SNMP agent | 351 | | SNMP get | | 352 | |<--------------| | 353 | | reply message | | 354 | | | | 355 | | SNMP get | | 356 | |- - - - - - - >| | 357 | | message | | 358 | | | | 359 | | SNMP get | | 360 | |< - - - - - - -| | 361 | | reply message | | 362 | | | | 363 | | . . . | | 364 +--------------+ +------------+ 366 Implementation of MIDCOM reply message 367 by an SNMP notification 368 and one or more SNMP set messages 370 Figure 3: MIDCOM reply message 371 mapped to SNMP notification and optional get transactions 373 4.2.3. Configuration Transactions 375 The realization of MIDCOM monitoring transactions in terms of SNMP 376 transactions is simpler. The request message is very short and just 377 specifies a piece of information that the MIDCOM agent wants to 378 retrieve. 380 Since monitoring is the stronghold of SNMP, there are sufficient 381 means to realize MIDCOM monitoring transactions simpler than MIDCOM 382 configuration transactions. 384 All MIDCOM monitoring transactions can be realized as a sequence of 385 SNMP get transactions. If one or more SNMP get transactions are 386 required depends on the amount of information that is to be 387 retrieved. 389 +--------------+ request +------------+ 390 | |-------------->| | 391 | | message | | 392 | MIDCOM agent | | middlebox | 393 | | reply | | 394 | |<--------------| | 395 +--------------+ message +------------+ 397 MIDCOM monitoring transaction 399 +--------------+ +------------+ 400 | | SNMP get | | 401 | |-------------->| | 402 | | message | | 403 | | | | 404 | | SNMP get | | 405 | |<--------------| | 406 | | reply message | | 407 | SNMP manager | | SNMP agent | 408 | | SNMP get | | 409 | |- - - - - - - >| | 410 | | message | | 411 | | | | 412 | | SNMP get | | 413 | |< - - - - - - -| | 414 | | reply message | | 415 | | | | 416 | | . . . | | 417 +--------------+ +------------+ 419 Implementation of MIDCOM monitoring transaction 420 by one or more SNMP get messages 422 Figure 4: MIDCOM monitoring transaction 423 mapped to SNMP get transactions 425 4.2.4. Atomicity or Transactions 427 Given the realizations of MIDCOM transactions by means of SNMP 428 transactions, atomicity of the MIDCOM transactions is not guaranteed 429 anymore. Therefore, we analyze the potential loss of atomicity for 430 each MIDCOM transaction. 432 4.2.4.1. Asynchronous Transactions 434 There are two asynchronous MIDCOM transactions: Asynchronous Session 435 Termination (AST) and Asynchronous policy Rule Event (ARE). For both 436 atomicity is maintained, because each of them is modeled by a single 437 atomic SNMP notification transaction. 439 4.2.4.2. Session Establishment and Termination Transactions 441 For the Session Establishment (SE) transaction and the Session 442 Termination (ST) atomicity is maintained. The ST transaction has 443 very few parameters. The request parameters can be transmitted by a 444 single SNMP set request message and the reply parameters can be 445 transmitted by a single SNMP notifications message. 447 Basically, the same holds for SE, but it needs more explanations. 448 The SE transaction include the optional transmission of 449 authentication challenges and authentication replies. These are not 450 required if SNMPv3 is used, because SNMPv3 provides all required 451 means for authentication. Also, the SE transaction includes 452 tranmission of middlebox capabilities from the middlebox to the 453 agent. But for this transmission, there is no atomicity requirement, 454 because these capabilities are static and can be transmitted piece by 455 piece. 457 Therefore, the SE transaction is implemented by an SNMP set 458 transaction modeling the request message and an SNMP notification 459 transaction modeling the reply message excluding the transfer of 460 middlebox capabilities. In the MIDCOM MIB module the middlebox 461 capabilities are provided by a set of managed objects that can be 462 read by the MIDCOM agent at any time using SNMP get transactions. 464 4.2.4.3. Monitoring Transactions 466 For the monitoring transactions Policy Rule List (PRL), Policy Rule 467 Status (PRS) Group List (GL) und Group Status (GS) atomicity is not 468 given anymore, because they are implemented by potentially more than 469 one SNMP get operations. The potential problem is that while the 470 monitoring transaction is performed, the monitored items may change. 471 For example, while reading a long list of policies, new policies may 472 be added and already read policies may be deleted. This is not in 473 line with the protcol semantics. However, it is acceptable because 474 it i not in conflict with the MIDCOM requirement requesting the 475 middlebox state to be stable and known by the MIDCOM agent, because 476 the middlebox notifies the MIDCOM agent on all changes to its state 477 that are performed during the monitoring transaction by sending 478 notifications. The MIDCOM agent can then either repeat the 479 monitoring transaction or integrate the result of the monitoring 480 transaction with the information received via notifications during 481 the transaction. In both cases, the MIDCOM agent will finally know 482 the state of the middlebox. 484 4.2.4.4. Lifetime Change Transactions 486 For the policy Rule Lifetime Change (RLC) transaction and the Group 487 Lifetime Change (GLC) transaction atomicity is maintained. They both 488 have very few parameters for request message and reply message. The 489 request parameters can be transmitted by a single SNMP set request 490 message and the reply parameters can be transmitted by a single SNMP 491 notifications message. 493 4.2.4.5. Transactions Establishing New Policy Rules 495 To be done: Discuss atomicity of PRR and PER. 497 4.2.5. Access Control 499 Since SNMP does not offer per-session authentication and 500 authorization, authentication and authorization are performed per 501 SNMP message sent from the MIDCOM agent to the middlebox. 503 For each transaction, the MIDCOM agent has to authenticate itself as 504 an SNMP user according to USM. Then the user's access rights to all 505 resources affected by the transaction are checked. Access right 506 control is realized by configuring the VACM mechanisms at the SNMP 507 agent. 509 4.3. Access Control Policies 511 Potentially, a middlebox has to control access for a large set of 512 agents and to a large set of policy rules configuring firewall 513 pinholes and NAT bindings. Therefore it can be beneficial to use 514 access control policies for specifying access control rules. 515 Generating, provisioning and managing these policies is out of scope 516 of this MIB module. 518 However, if such access control policy system is used, then the SNMP 519 agent acts as policy enforcement point. An access control policy 520 system must transform all active policies into configurations of the 521 SNMP agent's User Based Security Model (USM) and the View-based 522 Access Control Model (VACM). 524 The mechanisms of USM allow an access control policy system to 525 enforce MIDCOM agent authentication rules and general access control 526 of MIDCOM agents to middlebox control. 528 The mechanisms of VACM can be used to enforce access control of 529 authenticated agents to MIDCOM policy rules based on the concept of 530 ownership. For example, an access control policy can specify that 531 MIDCOM policy rules owned by user A, cannot be accessed at all by 532 user B, can be read by user C, and can be read and modified by user 533 D. 535 Further access control policies can control access to concrete 536 middlebox resources. These are enforces, when a MIDCOM request is 537 processed. For example an authenticated MIDCOM agent may be 538 authorized to request new MIDCOM policies to be established, but only 539 for certain IP address ranges. The enforcement of this kind of 540 policies cannot be realized by using available SNMP mechanisms, but 541 needs to be performed by the individual MIB module implementation. 543 5. Structure of the MIB module 545 This section presents the structure of the MIB module that is 546 specified in Section 5. The MIB is structured strictly according to 547 the MIDCOM semantics described in [RFCXXXX]. 549 The MIDCOM semantics definition is structured into three major 550 sections: session control, policy rule control and policy rule group 551 control. Accordingly, the MIDCOM MIB module contains three tables: 552 the midcomSessionTable, the midcomRuleTable and the midcomGroupTable. 553 Additionally, a set of scalar managed objects describe the middlebox 554 capabilities. 556 5.1. midcomCapabilities 558 Information on middlebox capabilites is provided by the 559 midcomCapabilities group of managed objects. The following objects 560 are defined: 562 o midcomCapabFirewall 563 This is a boolean object indicating whether or not the middlebox 564 acts as firewall. 566 o midcomCapabNat 567 This is a boolean object indicating whether or not the middlebox 568 acts as network address translator. 570 o midcomCapabPortTranslation 571 This is a boolean object indicating whether or not the middlebox 572 is capable of performing port translation. 574 o midcomCapabProtocolTranslation 575 This is a boolean object indicating whether or not the middlebox 576 is capable of performing protocol translation. 578 o midcomCapabTwiceNat 579 This is a boolean object indicating whether or not the middlebox 580 acts twice-NAT. 582 o midcomCapabInsideIpVersions 583 This objects lists the IP versions available at the inside of 584 the middlebox. 586 o midcomCapabOutsideIpVersions 587 This objects lists the IP versions available at the outside of 588 the middlebox. 590 o midcomCapabInsideWildcards 591 This is a boolean object indicating whether or not the middlebox 592 is capable of performing IP address wildcarding at the inside. 594 o midcomCapabOutsideWildcards 595 This is a boolean object indicating whether or not the middlebox 596 is capable of performing IP address wildcarding at the outside. 598 o midcomCapabPortWildcards 599 This is a boolean object indicating whether or not the middlebox 600 is capable of performing wilcarding of port numbers. 602 o midcomCapabPersistentRules 603 This is a boolean object indicating whether or not the middlebox 604 is capable of storing policy rules persistently. 606 o midcomCapabMaxLifetime 607 This object indicates the maximum lifetime that this middlebox 608 allows policy rules to have. 610 5.2. midcomSessionTable 612 The midcomSessionTable models MIDCOM sessions. For opening a 613 session, a MIDCOM agent has to create a row in this table. 615 Without an entry in the midcomSessionTable, no policy rules can be 616 established. New entries in the midcomRuleTable are created by 617 writing to the object called midcomSessionCreateRule in the 618 midcomSessionTable. The MIDCOM agent can specify the group 619 membership and the default rule storage time of created enties in the 620 midcomRuleTable by setting the corresponding objects in the 621 midcomSessionTable. 623 The midcomSessionTable is indexed by the SNMP user name of the 624 authenticated MIDCOM agent. 626 In particular, the midcomSessionTable contains the following objects: 628 o midcomSessionOwner 629 This string indicated the user that created and owns the 630 session. It is the index of this table. All policy rules (and 631 policy rule groups) have the same owner as the corresponding 632 entry in the midcomSessionTable from which they were created. 634 o midcomSessionIndex 635 An index that serves for distiguishing different sessions of the 636 same midcomSessionOwner. 638 o midcomSessionRuleGroupIndex 639 The group to which policy rules created from the same session 640 should be a member of. 642 o midcomSessionRuleStorageTime 643 The default time policy rules created from the same session 644 should be stored in the midcomPolicyTable after they are 645 terminated. 647 o midcomSessionRuleIndexNext 648 An object that can be read for obtaining an object identifier 649 pointing to a so far not exsiting entry in the midcomRuleTable. 651 o midcomSessionCreateRule 652 Writing a value read from midcomSessionRuleIndexNext to this 653 object creates a new entry in the midcomRuleTable. 655 o midcomSessionStorageType 656 This object indicates whether or not the session is volatile, 657 non-volatile, or permanent. Depending on the MIDCOM MIB 658 implementation this object may be writable. 660 o midcomSessionRowStatus 661 Writing to this object creates or deletes a row in the 662 midcomSessionTable, i.e. it opens or terminates a session, 663 respectively. 665 5.3. midcomRuleTable 667 The midcomRuleTable contains information about policy rules including 668 policy rules to be established, policy rules for which establishing 669 failed, establishe policy rules and terminated policy rules. 671 Entries in this table are indexed by the combination of a 672 midcomSessioOwner, a midcomGroupIndex and a midcomRuleIndex. The 673 midcomSessionOwner is the owner of the session from which the entry 674 was created, the midcomGroupIndex is the index of the group of which 675 the policy rule is a member. 677 Entries in this table can only be created by writing to 678 midcomSessionCreateRule in the midcomSessionTable. Entries are 679 removed, when their midcomRuleLifetime and midcomRuleStorageTime are 680 timed out by counting down to 0. A MIDCOM agent can explicitly 681 remove an entry by setting midcomRuleLifetime and 682 midcomRuleStorageTime to 0. 684 The table contains the following objects: 686 o midcomRuleIndex 687 The index of this entry must be unique in combination with the 688 midcomSessionOwner and the midcomGroupindex of the entry. 690 o midcomRuleAdminStatus 691 For establishing a new policy rule, a set of objects in this 692 entry needs to be written first. These objects are the request 693 parameters. Then, by writing either reserved(1) or enabled(2) 694 to this object, the MIDCOM MIB implementation starts processing 695 the parameters and tries to establish the specified policy rule. 697 o midcomRuleOperStatus 698 This read-only object indicates the current status of the entry. 699 The entry may have an initializing state, it may have a 700 transient state while processing requests, it may have an error 701 state after a request was rejected, it may have a state where a 702 policy rule is established, or it may have a terminated state. 704 o midcomRuleStorageType 705 This object indicates whether or not the policy rule is stored 706 as volatile, non-volatile, or permanent. Depending on the 707 MIDCOM MIB implementation this object may be writable. 709 o midcomRuleStorageTime 710 This object indicates how long the entry will still exist after 711 entering an error state or a termiantion state. 713 o midcomRuleError 714 This object is a string indicating the reason for entering an 715 error state. 717 o midcomRuleNatService 718 This object indicates which kind of NAT service is requested or 719 established, respectively. Possible NAT services are 720 traditional NAT and twice-NAT. 722 o midcomRuleTransportProtocol 723 This object indicates a transport protocol for which a policy 724 reserve rule or policy enable rule was requested or established, 725 respectively. 727 o midcomRulePortRange 728 This object indicates a port ramnge for which a policy reserve 729 rule or policy enable rule was requested or established, 730 respectively. 732 o midcomRulePortParity 733 This object indicates a port parity for which a policy reserve 734 rule or policy enable rule was requested or established, 735 respectively. 737 o midcomRuleFlowDirection 738 This object indicates a flow direction for which a policy enable 739 rule was requested or established, respectively. 741 o midcomRuleLifetime 742 This object indicates the reamining lifetime of an established 743 policy rule. The MIDCOM agent can change the remaining lifetime 744 by writing to it. 746 Beyond the listed objects, the table contains 14 further objects 747 describing address parameters. They include the IP version, IP 748 address and port number for the internal address (A0), inside address 749 (A1), outside address (A2) and external address (A3) and they include 750 interface numbers for A1 and A2. These objects serve as parameters 751 specifying a request or an established policy, respectively. 753 5.4. midcomGroupTable 755 The midcomGroupTable has an entry per existing polcy rule group. 756 Entries of this table are created automatically when creating entries 757 in the midcomRuleTable. Entries are automatically removed from this 758 table, when the last member entry is removed from the 759 midcomRuleTable. Entries cannot be created or removed explicitly by 760 the MIDCOM agent. 762 Entries are indexed by the midcomSessionOwner of the session from 763 which the policies belonging to the group where created. 765 an entry of the table contains the following objects: 767 o midcomGroupIndex 768 The index of this entry must be unique in combination with the 769 midcomSessionOwner of the entry. 771 o midcomGroupLifetime 772 This object indicates the maximum of the reamining lifetimes of 773 all established policy rules that are members of the group. The 774 MIDCOM agent can change the remaining lifetime of all member 775 policies by writing to this object. 777 5.5. midcomEvent 779 To be done: description of midcomSessionTermination, 780 midcomRuleEvent, midcomGroupEvent. 782 6. Definitions 784 MIDCOM-MIB DEFINITIONS ::= BEGIN 786 IMPORTS 787 MODULE-IDENTITY, OBJECT-TYPE, 788 NOTIFICATION-TYPE, Unsigned32, mib-2 789 FROM SNMPv2-SMI -- RFC2578 791 TruthValue, StorageType, RowStatus, 792 TimeInterval 793 FROM SNMPv2-TC -- RFC2579 795 MODULE-COMPLIANCE, OBJECT-GROUP 796 FROM SNMPv2-CONF -- RFC2580 798 SnmpAdminString 799 FROM SNMP-FRAMEWORK-MIB -- RFC3411 801 InetAddressType, InetAddress, 802 InetPortNumber 803 FROM INET-ADDRESS-MIB -- RFC 3291 805 InterfaceIndex 806 FROM IF-MIB; -- RFC2863 808 midcomMIB MODULE-IDENTITY 809 LAST-UPDATED "200310070333Z" -- October 07, 2003 810 ORGANIZATION "IETF Middlebox Communication Working Group" 811 CONTACT-INFO 812 "WG charter: 813 http://www.ietf.org/html.charters/midcom-charter.html 815 Mailing Lists: 816 General Discussion: midcom@ietf.org 817 To Subscribe: midcom-request@ietf.org 818 In Body: subscribe your_email_address 820 Editor: 821 Martin Stiemerling 822 NEC Europe Ltd. 824 Network Laboratories 825 Kurfuersten-Anlage 36 826 69221 Heidelberg 827 Germany 828 Tel: +49 6221 90511-13 829 Email: stiemerling@ccrle.nec.de" 830 DESCRIPTION 831 "This MIB module defines a set of basic objects for 832 configuring middleboxes, such as firewalls and network 833 address translators, in order to enable communication 834 across these devices. 836 There are four groups of managed objects defined 837 by this MIB module: 838 - objects describing middlebox capabilities 839 in the midcomCapabilities group, 840 - objects modeling MIDCOM sessions in the 841 midcomSessionTable 842 - objects modeling MIDCOM policy rules in the 843 midcomRuleTable 844 - objects modeling MIDCOM polcy rule groups in the 845 midcomGroupTable 847 Copyright (C) The Internet Society (2003). This version 848 of this MIB module is part of RFC yyyy; see the RFC 849 itself for full legal notices." 850 -- RFC Ed.: replace yyyy with actual RFC number & remove this notice 852 REVISION "200310070333Z" -- October 07, 2003 853 DESCRIPTION "Initial version, published as RFC yyyy." 854 -- RFC Ed.: replace yyyy with actual RFC number & remove this notice 856 ::= { mib-2 4444 } 857 -- 4444 to be assigned by IANA. 859 -- 860 -- main components of this MIB module 861 -- 863 midcomObjects OBJECT IDENTIFIER ::= { midcomMIB 1 } 864 midcomNotifications OBJECT IDENTIFIER ::= { midcomMIB 2 } 865 midcomConformance OBJECT IDENTIFIER ::= { midcomMIB 3 } 867 -- 868 -- Capabilities group 869 -- 870 -- The MIDCOM capabilities group contains a set of managed 871 -- objects describing the capabilities of the middlebox. 872 -- All objects in this group have MAX-ACCESS read-only. 874 -- 876 midcomCapabilities OBJECT IDENTIFIER ::= { midcomObjects 1 } 878 midcomCapabFirewall OBJECT-TYPE 879 SYNTAX TruthValue 880 MAX-ACCESS read-only 881 STATUS current 882 DESCRIPTION 883 "When retrieved, this object returns true(1) if the managed 884 node acts as firewall. Otherwise, it returns false(2)." 885 ::= { midcomCapabilities 1 } 887 midcomCapabNat OBJECT-TYPE 888 SYNTAX TruthValue 889 MAX-ACCESS read-only 890 STATUS current 891 DESCRIPTION 892 "When retrieved, this object returns true(1) if the managed 893 node acts as network address tranlator. Otherwise, it 894 returns false(2)." 895 ::= { midcomCapabilities 2 } 897 midcomCapabPortTranslation OBJECT-TYPE 898 SYNTAX TruthValue 899 MAX-ACCESS read-only 900 STATUS current 901 DESCRIPTION 902 "When retrieved, this object returns true(1) if the managed 903 node acts as network address translator and supports port 904 transaltion. Otherwise, it returns false(2)." 905 ::= { midcomCapabilities 3 } 907 midcomCapabProtocolTranslation OBJECT-TYPE 908 SYNTAX TruthValue 909 MAX-ACCESS read-only 910 STATUS current 911 DESCRIPTION 912 "When retrieved, this object returns true(1) if the managed 913 node acts as network address translator and supports protocol 914 transaltion. Otherwise, it returns false(2)." 915 ::= { midcomCapabilities 4 } 917 midcomCapabTwiceNat OBJECT-TYPE 918 SYNTAX TruthValue 919 MAX-ACCESS read-only 920 STATUS current 921 DESCRIPTION 922 "When retrieved, this object returns true(1) if the managed 923 node acts as twice network address translator. Otherwise, 924 it returns false(2)." 925 ::= { midcomCapabilities 5 } 927 midcomCapabInsideIpVersions OBJECT-TYPE 928 SYNTAX INTEGER { 929 ipv4(1), 930 ipv6(2), 931 both(3) 932 } 933 MAX-ACCESS read-only 934 STATUS current 935 DESCRIPTION 936 "When retrieved, this object returns ipv4(1) if the managed 937 node supports IPv4 only at the inside. It returns ipv6(2) 938 if it supports IPv6 only at the inside. Otherwise, if it 939 supports voth IP version, it returns both(3)." 940 ::= { midcomCapabilities 6 } 942 midcomCapabOutsideIpVersions OBJECT-TYPE 943 SYNTAX INTEGER { 944 ipv4(1), 945 ipv6(2), 946 both(3) 947 } 948 MAX-ACCESS read-only 949 STATUS current 950 DESCRIPTION 951 "When retrieved, this object returns ipv4(1) if the managed 952 node supports IPv4 only at the outside. It returns ipv6(2) 953 if it supports IPv6 only at the outside. Otherwise, if it 954 supports voth IP version, it returns both(3)." 955 ::= { midcomCapabilities 7 } 957 midcomCapabInsideWildcards OBJECT-TYPE 958 SYNTAX TruthValue 959 MAX-ACCESS read-only 960 STATUS current 961 DESCRIPTION 962 "When retrieved, this object returns true(1) if the managed 963 node supports IP address wildcarding at the inde. Otherwise, 964 it returns false(2)." 965 ::= { midcomCapabilities 8 } 967 midcomCapabOutsideWildcards OBJECT-TYPE 968 SYNTAX TruthValue 969 MAX-ACCESS read-only 970 STATUS current 971 DESCRIPTION 972 "When retrieved, this object returns true(1) if the managed 973 node supports IP address wildcarding at the outde. Otherwise, 975 it returns false(2)." 976 ::= { midcomCapabilities 9 } 978 midcomCapabPortWildcards OBJECT-TYPE 979 SYNTAX TruthValue 980 MAX-ACCESS read-only 981 STATUS current 982 DESCRIPTION 983 "When retrieved, this object returns true(1) if the managed 984 node supports port wildcarding. Otherwise, it returns 985 false(2)." 986 ::= { midcomCapabilities 10 } 988 midcomCapabPersistentRules OBJECT-TYPE 989 SYNTAX TruthValue 990 MAX-ACCESS read-only 991 STATUS current 992 DESCRIPTION 993 "When retrieved, this object returns true(1) if the managed 994 node can store policy rules persistently. Otherwise, it 995 returns false(2)." 996 ::= { midcomCapabilities 11 } 998 midcomCapabMaxLifetime OBJECT-TYPE 999 SYNTAX TimeInterval 1000 UNITS "centi-seconds" 1001 MAX-ACCESS read-only 1002 STATUS current 1003 DESCRIPTION 1004 "When retrieved, this object returns the maximum lifetime 1005 in centi-seconds, that this middlebox allows policy rules 1006 to have." 1007 ::= { midcomCapabilities 12 } 1009 -- 1010 -- Session group 1011 -- 1012 -- The midcomSessionTable models MIDCOM sessions. 1013 -- MIDCOM agents ( = SNMP managers ) that want to 1014 -- read, create or modify entries in the midcomRuleTable 1015 -- or midcomGroupTable need to have an entry in this table. 1016 -- 1017 -- The table contains objects identify a destination for 1018 -- notifications to be sent to the MIDCOM agent. 1019 -- Also it serves for creating new rows in the 1020 -- midcomRuleTable. 1021 -- 1023 midcomSession OBJECT IDENTIFIER ::= { midcomObjects 2 } 1024 midcomSessionIndexNext OBJECT-TYPE 1025 SYNTAX Unsigned32 1026 MAX-ACCESS read-only 1027 STATUS current 1028 DESCRIPTION 1029 "When retrieved, this object returns an unused session 1030 index for the USM user that issued the read-request. 1031 The returned value can be used for creating a new entry 1032 in the midcomSessionTable. 1034 A value retuned when reading this object is not returned 1035 again on subsequent read-requests as long as possible. 1036 This ensures that two SNMP managers authenticated as the 1037 same USM user can independently create sessions without 1038 facing race conditions." 1039 ::= { midcomSession 1 } 1041 midcomSessionTable OBJECT-TYPE 1042 SYNTAX SEQUENCE OF MidcomSessionEntry 1043 MAX-ACCESS not-accessible 1044 STATUS current 1045 DESCRIPTION 1046 "This table lists open MIDCOM sessions. 1048 The midcomSessionTable models MIDCOM sessions. 1049 MIDCOM agents ( = SNMP managers ) that want to 1050 read, create or modify entries in the midcomRuleTable 1051 or midcomGroupTable need to have an entry in this 1052 table. 1054 The table contains objects identify a destination for 1055 notifications to be sent to the MIDCOM agent. 1057 Also, it serves for creating new rows in the 1058 midcomRuleTable. 1060 The midcomSessionTable is indexed by its owner 1061 identified as USM user, and by a session index 1062 that allows distinguishing multiple sessions of 1063 the same USM users." 1064 ::= { midcomSession 2 } 1066 midcomSessionEntry OBJECT-TYPE 1067 SYNTAX MidcomSessionEntry 1068 MAX-ACCESS not-accessible 1069 STATUS current 1070 DESCRIPTION 1071 "An entry describing a particular MIDCOM session." 1072 INDEX { midcomSessionOwner, midcomSessionIndex } 1073 ::= { midcomSessionTable 1 } 1075 MidcomSessionEntry ::= SEQUENCE { 1076 midcomSessionOwner SnmpAdminString, 1077 midcomSessionIndex Unsigned32, 1078 midcomSessionRuleGroupIndex Unsigned32, 1079 midcomSessionRuleStorageTime TimeInterval, 1080 midcomSessionRuleIndexNext OBJECT IDENTIFIER, 1081 midcomSessionCreateRule OBJECT IDENTIFIER, 1082 midcomSessionStorageType StorageType, 1083 midcomSessionRowStatus RowStatus 1084 } 1086 midcomSessionOwner OBJECT-TYPE 1087 SYNTAX SnmpAdminString (SIZE (0..32)) 1088 MAX-ACCESS not-accessible 1089 STATUS current 1090 DESCRIPTION 1091 "The manager ( = MIDCOM agent ) who owns this row 1092 in the midcomSessionTable. 1094 Every policy rule created from a particular 1095 entry in the midcomSessionTable (i.e. entries 1096 in the midcomRuleTable) will be owned by the same 1097 midcomSessionOwner used to index the entry in the 1098 midcomSessionTable." 1099 ::= { midcomSessionEntry 1 } 1101 midcomSessionIndex OBJECT-TYPE 1102 SYNTAX Unsigned32 1103 MAX-ACCESS not-accessible 1104 STATUS current 1105 DESCRIPTION 1106 "This object allows distinguishing multiple concurrent 1107 sessions of the same USM user. Its value needs to be 1108 unique per USM user." 1109 ::= { midcomSessionEntry 2 } 1111 midcomSessionRuleGroupIndex OBJECT-TYPE 1112 SYNTAX Unsigned32 1113 MAX-ACCESS read-create 1114 STATUS current 1115 DESCRIPTION 1116 "This object determines the index of the MIDCOM policy 1117 rule group of which policy rules becomes a member when 1118 they are created by writing to midcomSessionCreateRule. 1120 The value 0 is not a valid group index. When this object 1121 has a value of 0, then a new group is created for each 1122 new policy rule generated by writing to 1123 midcomSessionCreateRule." 1124 DEFVAL { 0 } 1125 ::= { midcomSessionEntry 3 } 1127 midcomSessionRuleStorageTime OBJECT-TYPE 1128 SYNTAX TimeInterval 1129 UNITS "centi-seconds" 1130 MAX-ACCESS read-create 1131 STATUS current 1132 DESCRIPTION 1133 "This object indicates the default maximum amount of time 1134 information on a policy rule is kept as entry in the 1135 mibRuleTable after the entry reaches an error state or 1136 after the policy rule is terminated. The value of this 1137 object is used to initialize the midcomRuleStorageTime 1138 when a new entry in the midcomRuleTable is created. 1139 Changing the value of an midcomSessionRuleStorageTime 1140 instance does not affect any entry of the midcomRuleTable 1141 created previously." 1142 DEFVAL { 60000 } 1143 ::= { midcomSessionEntry 4 } 1145 midcomSessionRuleIndexNext OBJECT-TYPE 1146 SYNTAX OBJECT IDENTIFIER 1147 MAX-ACCESS read-only 1148 STATUS current 1149 DESCRIPTION 1150 "When retrieved, this object returns an object identifier 1151 pointing to a not yet existing row in the midcomRuleTable. 1153 The first index of the object identifier is the value of 1154 the midcomSessionOwner object of the actual entry in the 1155 midcomSessionTable. 1157 The second index is the value of the 1158 midcomSessionGroupIndex object of the actual entry in the 1159 midcomSessionTable, if this value is not 0. If the value 1160 is zero, then the second index is the midcomGroupIndex of 1161 a not yet existing entry in the midcomGroupTable. 1163 The third index is a so far unused policy rule index for 1164 members of the group identified by the second index. 1166 The returned value can be used for creating a new entry 1167 in the midcomRuleTable by writing it to 1168 midcomSessionCreateRule." 1169 ::= { midcomSessionEntry 5 } 1171 midcomSessionCreateRule OBJECT-TYPE 1172 SYNTAX OBJECT IDENTIFIER 1173 MAX-ACCESS read-write 1174 STATUS current 1175 DESCRIPTION 1176 "Writing to this object potentially creates a new entry in 1177 the midcomRuleTable. A value written to this object should 1178 be an object identifier pointing to a so far not existing 1179 entry in the midcomRuleTable. Also it should use the 1180 value of the midcomSessionOwner iobject of the acual 1181 entry in the midcomSessionTable as first index. If one 1182 of these constraints is not given, then the operation 1183 will result in an inconsistentValue error. 1185 Also, the value must use the midcomSessionOwner of 1186 the actual entry in the midcomSessionTable as first index. 1187 Valid values for writing to this object can be obtained 1188 by reading the midcomSessionRuleIndexNext object. 1190 If the value is valid, then the MIDCOM MIB implementation 1191 creates a new entry in the midcomRuleTable using the 1192 value." 1193 ::= { midcomSessionEntry 6 } 1195 midcomSessionStorageType OBJECT-TYPE 1196 SYNTAX StorageType 1197 MAX-ACCESS read-create 1198 STATUS current 1199 DESCRIPTION 1200 "to be done" 1201 DEFVAL { volatile } 1202 ::= { midcomSessionEntry 7 } 1204 midcomSessionRowStatus OBJECT-TYPE 1205 SYNTAX RowStatus 1206 MAX-ACCESS read-create 1207 STATUS current 1208 DESCRIPTION 1209 "Needed for creating sessions. Detailed description 1210 to be done." 1211 ::= { midcomSessionEntry 8 } 1213 -- 1214 -- Policy rule group 1215 -- 1216 -- The midcomRuleTable lists all current policy rules 1217 -- including policy reserve rules and policy enable rules. 1218 -- 1220 midcomRuleTable OBJECT-TYPE 1221 SYNTAX SEQUENCE OF MidcomRuleEntry 1222 MAX-ACCESS not-accessible 1223 STATUS current 1224 DESCRIPTION 1225 "This table lists all current policy rules. 1227 It is indexed by the midcomSessionOwner, the 1228 midcomGroupIndex and the midcomRuleIndex. 1229 This implies that a rule is member of exactly 1230 one group and that group membership cannot 1231 be changed. 1233 Entries in this table are created implicitly 1234 by writing to the midcomSessionTable. Entries 1235 are deleted by writing to midcomGroupLifetime 1236 or midcomRuleLifetime." 1237 ::= { midcomObjects 3 } 1239 midcomRuleEntry OBJECT-TYPE 1240 SYNTAX MidcomRuleEntry 1241 MAX-ACCESS not-accessible 1242 STATUS current 1243 DESCRIPTION 1244 "An entry describing a particular MIDCOM policy rule. 1245 It must be unque in combination with the 1246 midcomSessionOwner, the midcomGroupIndex, and the 1247 midcomRuleIndex of this entry." 1248 INDEX { midcomSessionOwner, midcomGroupIndex, midcomRuleIndex } 1249 ::= { midcomRuleTable 1 } 1251 MidcomRuleEntry ::= SEQUENCE { 1252 midcomRuleIndex Unsigned32, 1253 midcomRuleAdminStatus INTEGER, 1254 midcomRuleOperStatus INTEGER, 1255 midcomRuleStorageType StorageType, 1256 midcomRuleStorageTime TimeInterval, 1257 midcomRuleError SnmpAdminString, 1258 midcomRuleNatService INTEGER, 1259 midcomRuleInternalIpVersion InetAddressType, 1260 midcomRuleInternalIpAddr InetAddress, 1261 midcomRuleInternalPort InetPortNumber, 1262 midcomRuleInsideIpVersion InetAddressType, 1263 midcomRuleInsideIpAddr InetAddress, 1264 midcomRuleInsidePort InetPortNumber, 1265 midcomRuleInsideInterface InterfaceIndex, 1266 midcomRuleOutsideIpVersion InetAddressType, 1267 midcomRuleOutsideIpAddr InetAddress, 1268 midcomRuleOutsidePort InetPortNumber, 1269 midcomRuleOutsideInterface InterfaceIndex, 1270 midcomRuleExternalIpVersion InetAddressType, 1271 midcomRuleExternalIpAddr InetAddress, 1272 midcomRuleExternalPort InetPortNumber, 1273 midcomRuleTransportProtocol Unsigned32, -- defintion? 1274 midcomRulePortRange Unsigned32, 1275 midcomRulePortParity INTEGER, 1276 midcomRuleFlowDirection INTEGER, 1277 midcomRuleLifetime TimeInterval 1278 } 1280 midcomRuleIndex OBJECT-TYPE 1281 SYNTAX Unsigned32 1282 MAX-ACCESS not-accessible 1283 STATUS current 1284 DESCRIPTION 1285 "The value of this object must be unique in 1286 combination with the values of 1287 midcomSessionOwner and midcomGroupIndex. 1289 The value of this index is chosen by the MIDCOM 1290 MIB implementation when a new entry in this row 1291 is created." 1292 ::= { midcomRuleEntry 3 } 1294 midcomRuleAdminStatus OBJECT-TYPE 1295 SYNTAX INTEGER { 1296 reserved(1), 1297 enabled(2) 1298 } 1299 MAX-ACCESS read-write 1300 STATUS current 1301 DESCRIPTION 1302 "The value of this object indicates the desired status of 1303 the policy rule. See the definition of midcomRuleOperStatus 1304 for a description of the values. 1306 When the midcomRuleAdminStatus object is set, then the 1307 MIDCOM MIB implementation will try to read the respective 1308 relvant objects of the entry and try to achieve the 1309 corresponding midcomRuleOperStatus. 1311 Depending on whether the midcomRuleAdminStatus is set to 1312 reserved(1) or enabled(2) several entries in MidcomRuleEntry 1313 must be set. 1315 In the reserved(1) case these entries must be set for 1316 a request: 1317 - midcomRuleNatService 1318 - midcomRuleInternalIpVersion 1319 - midcomRuleInternalIpAddr 1320 - midcomRuleInternalPort 1321 - midcomRuleInsideInterface 1322 - midcomRuleOutsideInterface 1323 - midcomRuleExternalIpVersion 1324 - midcomRuleTransportProtocol 1325 - midcomRulePortRange 1326 - midcomRulePortParity 1328 In the enabled(2) case these entries must be set for a 1329 request: 1330 - midcomRuleInternalIpVersion 1331 - midcomRuleInternalIpAddr 1332 - midcomRuleInternalPort 1333 - midcomRuleInsideInterface 1334 - midcomRuleOutsideInterface 1335 - midcomRuleExternalIpVersion 1336 - midcomRuleExternalIpAddr 1337 - midcomRuleExternalPort 1338 - midcomRuleTransportProtocol 1339 - midcomRulePortRange 1340 - midcomRulePortParity 1341 - midcomRuleFlowDirection 1343 When retrieved, the object returns the last set value. If 1344 no value has been set, it returns one of the two possible 1345 values." 1346 ::= { midcomRuleEntry 4 } 1348 midcomRuleOperStatus OBJECT-TYPE 1349 SYNTAX INTEGER { 1350 newEntry(1), 1351 setting(2), 1352 checkingRequest(3), 1353 incorrectRequest(4), 1354 processingRequest(5), 1355 requestRejected(6), 1356 reserved(7), 1357 checkingTransitRequest(8), 1358 processingTransitRequest(9), 1359 enabled(10), 1360 timedOut(11), 1361 terminatedOnRequest(12), 1362 terminated(13), 1363 genericError(14) 1364 } 1365 MAX-ACCESS read-only 1366 STATUS current 1367 DESCRIPTION 1368 "The actual status of the policy rule. The 1369 midcomRuleOperStatus object may have the following values: 1371 - newEntry(1) indicates that the entry in the 1372 midcomRuleTable was created, but not modified yet. 1373 Such an entry needs to be filled with values specifying 1374 a request first. 1376 - setting(2) indicates that the entry has been already 1377 modified after generating it, but no request was made 1378 yet. 1380 - checkingRequest(3) indicates that midcomRuleAdminStatus 1381 has recently been set and that the MIDCOM MIB 1382 implementation is currently checking the parameters of 1383 the request. 1385 - incorrectRequest(4) indicates that checking a request 1386 resulted in detecting an incorrect value in one of the 1387 objects containing request parameters. The failure 1388 reason is indicated by the value of midcomRuleError. 1390 - processingRequest(5) indicates that 1391 midcomRuleAdminStatus has recently been set and that 1392 the MIDCOM MIB implementation is currently processing 1393 the request and trying to configure the middlebox 1394 accordingly. 1396 - requestRejected(6) indicates that a request to establish 1397 a policy rule specified by the entry was rejected. The 1398 reason of rejection is indicated by the value of 1399 midcomRuleError. 1401 - reserved(7) indicates that the entry describes an 1402 established policy reserve rule. 1403 These values of MidcomRuleEntry can be retrieved 1404 for a reserved policy rule: 1405 - midcomRuleNatService 1406 - midcomRuleInternalIpVersion 1407 - midcomRuleInternalIpAddr 1408 - midcomRuleInternalPort 1409 - midcomRuleInsideIpVersion 1410 - midcomRuleInsideIpAddr 1411 - midcomRuleInsidePort 1412 - midcomRuleInsideInterface 1413 - midcomRuleOutsideIpVersion 1414 - midcomRuleOutsideIpAddr 1415 - midcomRuleOutsidePort 1416 - midcomRuleExternalIpVersion 1417 - midcomRuleTransportProtocol 1418 - midcomRulePortRange 1419 - midcomRulePortParity 1420 - midcomRuleLifetime 1422 - checkingTransitRequest(8) indicates that after a policy 1423 reserve rule was established, midcomRuleAdminStatus has 1424 recently been set to enabled(10) and that the MIDCOM MIB 1425 implementation is currently checking the parameters of 1426 the request. 1428 - processingTransitRequest(9) indicates that after a policy 1429 reserve rule was established, midcomRuleAdminStatus has 1430 recently been set to enabled(10) and that the MIDCOM MIB 1431 implementation is currently processing the request and 1432 trying to configure the middlebox accordingly. 1434 - enabled(10) indicates that the entry describes an 1435 established policy enable rule. 1436 These values of MidcomRuleEntry can be retrieved 1437 for an enabled policy rule 1438 - midcomRuleInternalIpVersion 1439 - midcomRuleInternalIpAddr 1440 - midcomRuleInternalPort 1441 - midcomRuleInsideIpVersion 1442 - midcomRuleInsideIpAddr 1443 - midcomRuleInsidePort 1444 - midcomRuleInsideInterface 1445 - midcomRuleOutsideIpVersion 1446 - midcomRuleOutsideIpAddr 1447 - midcomRuleOutsidePort 1448 - midcomRuleOutsideInterface 1449 - midcomRuleExternalIpVersion 1450 - midcomRuleExternalIpAddr 1451 - midcomRuleExternalPort 1452 - midcomRuleTransportProtocol 1453 - midcomRulePortRange 1454 - midcomRulePortParity 1455 - midcomRuleFlowDirection 1456 - midcomRuleLifetime 1458 - timedOut(11) indicates that the lifetime of a previously 1459 established policy rule is expired and that the policy 1460 rule is terminated for this reason. 1462 - terminatedOnRequest(12) indicates that a previously 1463 established policy rule was terminated by an SNMP 1464 manager setting the midcomRuleLifetime to 0 or 1465 setting midcomGroupLifetime to 0. 1467 - terminated(13) indicates that a previously established 1468 policy rule was terminated by the MIDCOM MIB 1469 implementation for another reason than lifetime 1470 expiration or an explicit request from an SNMP 1471 manager. 1473 - genericError(14) indicates that the policy rule 1474 specified by the entry is not established due to 1475 an error condition not listed above. 1477 The states timedOut(11), terminatedOnRequest(12) and 1478 terminated(13) are referred to as termination states. 1480 The states incorrectRequest(4), requestRejected(6) 1481 and genericError(14) are referred to as error states. 1483 The checkingRequest(3), processingRequest(4), 1484 checkingTransitRequest(8) and checkingTransitRequest(9) 1485 states are transient states which will either lead to one 1486 of the error states or the reserved(7) state or the 1487 enabled(10) states." 1488 DEFVAL { newEntry } 1489 ::= { midcomRuleEntry 5 } 1491 midcomRuleStorageType OBJECT-TYPE 1492 SYNTAX StorageType 1493 MAX-ACCESS read-create 1494 STATUS current 1495 DESCRIPTION 1496 "This object defines whether this row and the policy 1497 rule controlled by this row are kept in volatile 1498 storage and lost upon reboot or if this row is 1499 backed up by non-volatile or permanent storage. 1501 Attempts to set this object to permanent will always 1502 fail with an inconsistentValue error. 1504 If midcomRuleStorageType has the value permanent(4), 1505 then all objects whose MAX-ACCESS value is read-write 1506 must be read-only." 1507 DEFVAL { volatile } 1508 ::= { midcomRuleEntry 6 } 1510 midcomRuleStorageTime OBJECT-TYPE 1511 SYNTAX TimeInterval 1512 UNITS "centi-seconds" 1513 MAX-ACCESS read-write 1514 STATUS current 1515 DESCRIPTION 1516 "The value of this object specifies how long this row 1517 can exist in the midcomRuleTable after the 1518 midcomRuleOperState switched to a termination state or 1519 to an error state. This object returns the remaining 1520 time that the row may exist before it is aged out. 1522 The object is initialized with the value of the 1523 associated midcomSessionStorageTime object. 1525 After expiration or termination of the context, the value 1526 of this object ticks backwards. The entry in the 1527 midcomRuleTable is destroyed when the value reaches 0. 1529 The value of this object may be set in order to increase 1530 or reduce the remaining time that the row may exist. 1531 Setting the value to 0 will destroy this entry as soon as 1532 the midcomRuleOperState switched to a termination state 1533 or to an error state. 1535 Note that there is no guarantee that the row is stored as 1536 long as this object indicates. At any time, the SNMP 1537 agent may decide to remove a row describing a terminated 1538 policy rule before the storage time of the corresponding 1539 row in the midcomRuleTable reaches the value of 0. In 1540 this case the information stored in this row is not 1541 anymore available." 1542 ::= { midcomRuleEntry 7 } 1544 midcomRuleError OBJECT-TYPE 1545 SYNTAX SnmpAdminString 1546 MAX-ACCESS read-only 1547 STATUS current 1548 DESCRIPTION 1549 "This object contains a descriptive error message if 1550 the transition into the operational status reserved(7) 1551 or enabled(10) failed. Implementations must reset the 1552 error message to a zero-length string when a new 1553 attempt to change the policy rule status to reserved(7) 1554 or enabled(10) is started." 1555 DEFVAL { ''H } 1556 ::= { midcomRuleEntry 8 } 1558 midcomRuleNatService OBJECT-TYPE 1559 SYNTAX INTEGER { 1560 traditionalNat(1), 1561 twiceNat(2) 1562 } 1563 MAX-ACCESS read-write 1564 STATUS current 1565 DESCRIPTION 1566 "The requested NAT service of the middlebox. Some NATs may 1567 have dual characters, like providing traditional and 1568 twice NAT service at the same time for different NAT bindings. 1569 This parameter determines the behaviour for this NAT binding. 1570 A firewall only middlebox ignores this parameter. 1572 The midcomRuleService is only available for policy reserve 1573 rules, indicated by midcomRuleAdminStatus set to reserved(1)." 1574 ::= { midcomRuleEntry 9 } 1576 midcomRuleInternalIpVersion OBJECT-TYPE 1577 SYNTAX InetAddressType 1578 MAX-ACCESS read-write 1579 STATUS current 1580 DESCRIPTION 1581 "IP version at the inside of the middlebox." 1582 ::= { midcomRuleEntry 10 } 1584 midcomRuleInternalIpAddr OBJECT-TYPE 1585 SYNTAX InetAddress 1586 MAX-ACCESS read-write 1587 STATUS current 1588 DESCRIPTION 1589 "The internal IP address at the middlebox." 1590 ::= { midcomRuleEntry 11 } 1592 midcomRuleInternalPort OBJECT-TYPE 1593 SYNTAX InetPortNumber 1594 MAX-ACCESS read-write 1595 STATUS current 1596 DESCRIPTION 1597 "The internal port at the middlebox." 1598 ::= { midcomRuleEntry 12 } 1600 midcomRuleInsideIpVersion OBJECT-TYPE 1601 SYNTAX InetAddressType 1602 MAX-ACCESS read-only 1603 STATUS current 1604 DESCRIPTION 1605 "IP version at the inside of the middlebox. 1606 The midcomRuleInsideIpVersion is set by the SNMP agent 1607 to the IP address type, when the middlebox is twice-NAT 1608 and twice-NAT service is requested. 1609 The midcomRuleInsideIpVersion must be set to unknown(0) when 1610 the NAT does not assign an inside IP address. Firewalls 1611 always return unkown(0), since no inside IP address is assigned." 1612 ::= { midcomRuleEntry 13 } 1614 midcomRuleInsideIpAddr OBJECT-TYPE 1615 SYNTAX InetAddress 1616 MAX-ACCESS read-only 1617 STATUS current 1618 DESCRIPTION 1619 "The inside IP address at the middlebox. 1620 The midcomRuleInsideIpAddr is set by the SNMP agent 1621 to the IP address, when the middlebox is twice-NAT 1622 and twice-NAT service is requested." 1623 ::= { midcomRuleEntry 14 } 1625 midcomRuleInsidePort OBJECT-TYPE 1626 SYNTAX InetPortNumber 1627 MAX-ACCESS read-only 1628 STATUS current 1629 DESCRIPTION 1630 "The inside port at the middlebox. 1631 The midcomRuleInsideIpPort is set by the SNMP agent 1632 to the IP port number, when the middlebox is twice-NAT 1633 and twice-NAT service is requested." 1634 ::= { midcomRuleEntry 15 } 1636 midcomRuleInsideInterface OBJECT-TYPE 1637 SYNTAX InterfaceIndex 1638 MAX-ACCESS read-write 1639 STATUS current 1640 DESCRIPTION 1641 "The interface at the inside of the middlebox." 1642 ::= { midcomRuleEntry 16 } 1644 midcomRuleOutsideIpVersion OBJECT-TYPE 1645 SYNTAX InetAddressType 1646 MAX-ACCESS read-only 1647 STATUS current 1648 DESCRIPTION 1649 "IP version at the outside of the middlebox. 1650 The midcomRuleOutsideIpVersion is set by the SNMP agent 1651 to the IP address type. 1652 Firewalls always return unkown(0), since no inside IP address 1653 is assigned." 1654 ::= { midcomRuleEntry 17 } 1656 midcomRuleOutsideIpAddr OBJECT-TYPE 1657 SYNTAX InetAddress 1658 MAX-ACCESS read-only 1659 STATUS current 1660 DESCRIPTION 1661 "The outside IP address at the middlebox. 1662 The midcomRuleOutsideIpAddr is set by the SNMP agent 1663 to the IP address." 1664 ::= { midcomRuleEntry 18 } 1666 midcomRuleOutsidePort OBJECT-TYPE 1667 SYNTAX InetPortNumber 1668 MAX-ACCESS read-only 1669 STATUS current 1670 DESCRIPTION 1671 "The outside port at the middlebox. 1672 The midcomRuleOutsideIpPort is set by the SNMP agent 1673 to the IP address type." 1674 ::= { midcomRuleEntry 19 } 1676 midcomRuleOutsideInterface OBJECT-TYPE 1677 SYNTAX InterfaceIndex 1678 MAX-ACCESS read-write 1679 STATUS current 1680 DESCRIPTION 1681 "The interface at the outside of the middlebox." 1682 ::= { midcomRuleEntry 20 } 1684 midcomRuleExternalIpVersion OBJECT-TYPE 1685 SYNTAX InetAddressType 1686 MAX-ACCESS read-write 1687 STATUS current 1688 DESCRIPTION 1689 "IP version at the external of the middlebox." 1690 ::= { midcomRuleEntry 21 } 1692 midcomRuleExternalIpAddr OBJECT-TYPE 1693 SYNTAX InetAddress 1694 MAX-ACCESS read-write 1695 STATUS current 1696 DESCRIPTION 1697 "The external IP address at the middlebox. 1699 The midcomExternalIpAddr is only available for policy 1700 enable rule requests, indicated by midcomRuleAdminStatus set 1701 to enabled(2)." 1702 ::= { midcomRuleEntry 22 } 1704 midcomRuleExternalPort OBJECT-TYPE 1705 SYNTAX InetPortNumber 1706 MAX-ACCESS read-write 1707 STATUS current 1708 DESCRIPTION 1709 "The external port at the middlebox. 1710 The midcomExternalPort is only available for policy 1711 enable rule requests, indicated by midcomRuleAdminStatus set 1712 to enabled(2)." 1713 ::= { midcomRuleEntry 23 } 1715 midcomRuleTransportProtocol OBJECT-TYPE 1716 SYNTAX Unsigned32 (0..255) 1717 MAX-ACCESS read-write 1718 STATUS current 1719 DESCRIPTION 1720 "The transport protocol." 1721 ::= { midcomRuleEntry 24 } 1723 midcomRulePortRange OBJECT-TYPE 1724 SYNTAX Unsigned32 (1..65535) 1725 MAX-ACCESS read-write 1726 STATUS current 1727 DESCRIPTION 1728 "The port range parameter specifies a number of 1729 consecutive port numbers. Its value is a positive integer. 1730 Together with the port number parameter this parameter defines 1731 a set of consecutive port numbers starting with the port number 1732 specified by the port number parameter as the lowest port 1733 number and having as many elements as specified by the port 1734 range parameter. A value of one specifies just a single port 1735 number." 1736 ::= { midcomRuleEntry 25 } 1738 midcomRulePortParity OBJECT-TYPE 1739 SYNTAX INTEGER { 1740 same(1), -- available for PER only 1741 any(2), -- available for PER and PRR 1742 odd(3), -- available for PRR only 1743 even(4) -- available for PRR only 1744 } 1745 MAX-ACCESS read-write 1746 STATUS current 1747 DESCRIPTION 1748 "The port parity parameter is differently used in the 1749 context of policy reserve rules (PRR, midcomRuleAdminStatus 1750 set to reserved(1)) and policy enable rules (PER, 1751 midcomRuleAdminStaus set to enabled(2)). In the context 1752 of a PRR, the value of the parameter may be 'odd', 1753 'even', or 'any'. It specifies the parity of the first 1754 (lowest) reserved port number. 1756 In the context of a PER, the port parity parameter 1757 indicates to the middlebox, whether or not port numbers 1758 allocated at the middlebox should have the same parity 1759 as the corresponding internal or external port numbers, 1760 respectively. In this context, the parameter has either 1761 the value 'same' or 'any'. If it has the value 'same', 1762 then the parity of the port number of A0 must be the 1763 same as the parity of the port number of A2, and the 1764 parity of the port number of A1 must be the same as the 1765 parity of the port number of A3. If the port parity 1766 parameter has the value 'any', then there are no constraints 1767 on the parity of any port number." 1768 ::= { midcomRuleEntry 26} 1770 midcomRuleFlowDirection OBJECT-TYPE 1771 SYNTAX INTEGER { 1772 inbound(1), 1773 outbound(2), 1774 bidirectional(3) 1775 } 1776 MAX-ACCESS read-write 1777 STATUS current 1778 DESCRIPTION 1779 "This parameter specifies the direction of enabled communication, 1780 either 'inbound', 'outbound', or 'bi-directional'. 1782 The midcomRuleFlowDirection is only available for policy 1783 enable rule requests, indicated by midcomRuleAdminStatus set 1784 to enabled(2)." 1785 ::= { midcomRuleEntry 27 } 1787 midcomRuleLifetime OBJECT-TYPE 1788 SYNTAX TimeInterval 1789 UNITS "centi-seconds" 1790 MAX-ACCESS read-write 1791 STATUS current 1792 DESCRIPTION 1793 "When retrieved, this object delivers the the reamining 1794 lifetime in centi-seconds of this policy rule. 1796 Successfully writing to this object modifies the 1797 lifetime of the policy rule. Successfully 1798 writing a value of 0 terminates the policy rule. 1800 Note that after a policy rule is terminated, 1801 still the entry will exist as long as indicated by 1802 the value of midcomRuleStorageTime. 1804 Writing to this object is processed by the SNMP agent 1805 according to the processing of a Policy Rule Lifetime Change 1806 (RLC) request as specified in RFC XXXX. Therefore, 1807 SNMP set requests to this object might be rejected or 1808 the value of the object after an accepted set operation 1809 may be different from the value that was contained in 1810 the SNMP set request." 1811 ::= { midcomRuleEntry 28 } 1813 -- 1814 -- Policy rule group group 1815 -- 1816 -- The midcomGroupTable lists all current policy rule groups. 1817 -- 1819 midcomGroupTable OBJECT-TYPE 1820 SYNTAX SEQUENCE OF MidcomGroupEntry 1821 MAX-ACCESS not-accessible 1822 STATUS current 1823 DESCRIPTION 1824 "This table lists all current policy rule groups. 1826 Entries in this table are created implicitely when 1827 entries in the midcomRuleTable are created. 1829 Like the midcomSessionTable and the midcomRuleTable, 1830 this table is indexed by an owner and an index that 1831 is unique per owner. 1833 The table serves for listing the existing groups and 1834 their remaining lifetimes and for changing lifetimes 1835 of groups and implicitly of all group members. 1836 Groups and all their member policy rules can be 1837 deleted by setting midcomGroupLifetime to 0." 1838 ::= { midcomObjects 4 } 1840 midcomGroupEntry OBJECT-TYPE 1841 SYNTAX MidcomGroupEntry 1842 MAX-ACCESS not-accessible 1843 STATUS current 1844 DESCRIPTION 1845 "An entry describing a particular MIDCOM session." 1846 INDEX { midcomSessionOwner, midcomGroupIndex } 1847 ::= { midcomGroupTable 1 } 1849 MidcomGroupEntry ::= SEQUENCE { 1850 midcomGroupIndex Unsigned32, 1851 midcomGroupLifetime TimeInterval 1852 } 1854 midcomGroupIndex OBJECT-TYPE 1855 SYNTAX Unsigned32 (1..4294967295) 1856 MAX-ACCESS not-accessible 1857 STATUS current 1858 DESCRIPTION 1859 "The index of this group for the midcomSessionOwner. 1860 A group is identified by the combination of 1861 midcomSessionOwner and midcomGroupIndex. 1863 The value of this index must be unique per 1864 midcomSessionOwner." 1865 ::= { midcomGroupEntry 2 } 1867 midcomGroupLifetime OBJECT-TYPE 1868 SYNTAX TimeInterval 1869 UNITS "centi-seconds" 1870 MAX-ACCESS read-write 1871 STATUS current 1872 DESCRIPTION 1873 "When retrieved, this object delivers the the maximum 1874 lifetime in centi-seconds of all member rules of this 1875 group, i.e. of all rows in the midcomRuleTable that 1876 have the same values for midcomSessionOwner and 1877 midcomGroupIndex. 1879 Successfully writing to this object modifies the 1880 lifetime of all member policies. Successfully 1881 writing a value of 0 deletes the group and all its 1882 member rules. 1884 Note that after a group is conceptually deleted, 1885 still the corresponding entry in the midcomGroupTable 1886 will exist as long as terminated member policy rules 1887 are stored as entries in the midcomRuleTable. 1889 Writing to this object is processed by the SNMP agent 1890 according to the processing of a Group Lifetime Change 1891 (GLC) request as specified in RFC XXXX. Therefore, 1892 SNMP set requests to this object might be rejected or 1893 the value of the object after an accepted set operation 1894 may be different from the value that was contained in 1895 the SNMP set request." 1896 ::= { midcomGroupEntry 3 } 1898 -- 1899 -- Notifications. The definition of midcomEvent makes notification 1900 -- registrations reversible (see STD 58, RFC 2578, Section 8.5). 1901 -- 1903 midcomEvent OBJECT IDENTIFIER ::= { midcomNotifications 0 } 1905 midcomSessionTermination NOTIFICATION-TYPE 1906 STATUS current 1907 DESCRIPTION 1908 "This notification can be generated for indicating 1909 that a session is terminated by the middlebox." 1910 ::= { midcomEvent 1 } 1912 midcomRuleEvent NOTIFICATION-TYPE 1913 OBJECTS { midcomRuleLifetime } 1914 STATUS current 1915 DESCRIPTION 1916 "This notification can be generated for indicating the 1917 change of a policy rule's lifetime." 1918 ::= { midcomEvent 2 } 1920 midcomGroupEvent NOTIFICATION-TYPE 1921 OBJECTS { midcomGroupLifetime } 1922 STATUS current 1923 DESCRIPTION 1924 "This notification can be generated for indicating the 1925 change of a policy rule group's lifetime." 1927 ::= { midcomEvent 3 } 1929 -- 1930 -- Conformance information 1931 -- 1933 midcomCompliances OBJECT IDENTIFIER ::= { midcomConformance 1 } 1934 midcomGroups OBJECT IDENTIFIER ::= { midcomConformance 2 } 1936 -- 1937 -- compliance statements 1938 -- 1940 -- This is the MIDCOM compliance definition ... 1941 -- 1943 midcomCompliance MODULE-COMPLIANCE 1944 STATUS current 1945 DESCRIPTION 1946 "The compliance statement for SNMP entities that 1947 implement the MIDCOM MIB. 1949 Note that compliance with this compliance 1950 statement requires compliance with the 1951 ifCompliance3 MODULE-COMPLIANCE statement of the 1952 IF-MIB [RFC2863]." 1953 MODULE -- this module 1954 MANDATORY-GROUPS { 1955 midcomCapabilitiesGroup, 1956 midcomSessionGroup, 1957 midcomRuleGroup, 1958 midcomNotificationsGroup 1959 } 1960 GROUP midcomGroupGroup 1961 DESCRIPTION 1962 "A compliant implementation does not have to implement 1963 the midcomGroupGroup." 1964 OBJECT midcomRuleInsideInterface 1965 MIN-ACCESS not-accessible 1966 DESCRIPTION 1967 "A compliant implementation does not have to implement 1968 object midcomRuleInsideInterface." 1969 OBJECT midcomRuleOutsideInterface 1970 MIN-ACCESS not-accessible 1971 DESCRIPTION 1972 "A compliant implementation does not have to implement 1973 object midcomRuleOutsideInterface." 1974 ::= { midcomCompliances 1 } 1976 midcomCapabilitiesGroup OBJECT-GROUP 1977 OBJECTS { 1978 midcomCapabFirewall, 1979 midcomCapabNat, 1980 midcomCapabPortTranslation, 1981 midcomCapabProtocolTranslation, 1982 midcomCapabTwiceNat, 1983 midcomCapabInsideIpVersions, 1984 midcomCapabOutsideIpVersions, 1985 midcomCapabInsideWildcards, 1986 midcomCapabOutsideWildcards, 1987 midcomCapabPortWildcards, 1988 midcomCapabPersistentRules, 1989 midcomCapabMaxLifetime 1990 } 1991 STATUS current 1992 DESCRIPTION 1993 "A collection of objects providing information about 1994 the capabilities of a middlebox." 1995 ::= { midcomGroups 1 } 1997 midcomSessionGroup OBJECT-GROUP 1998 OBJECTS { 1999 midcomSessionIndexNext, 2000 midcomSessionRuleGroupIndex, 2001 midcomSessionRuleStorageTime, 2002 midcomSessionRuleIndexNext, 2003 midcomSessionCreateRule, 2004 midcomSessionStorageType, 2005 midcomSessionRowStatus 2006 } 2007 STATUS current 2008 DESCRIPTION 2009 "A collection of objects providing information about 2010 MIDCOM sessions." 2011 ::= { midcomGroups 2 } 2013 midcomRuleGroup OBJECT-GROUP 2014 OBJECTS { 2015 midcomRuleAdminStatus, 2016 midcomRuleOperStatus, 2017 midcomRuleStorageType, 2018 midcomRuleStorageTime, 2019 midcomRuleError, 2020 midcomRuleNatService, 2021 midcomRuleInternalIpVersion, 2022 midcomRuleInternalIpAddr, 2023 midcomRuleInternalPort, 2024 midcomRuleInsideIpVersion, 2025 midcomRuleInsideIpAddr, 2026 midcomRuleInsidePort, 2027 midcomRuleInsideInterface, 2028 midcomRuleOutsideIpVersion, 2029 midcomRuleOutsideIpAddr, 2030 midcomRuleOutsidePort, 2031 midcomRuleOutsideInterface, 2032 midcomRuleExternalIpVersion, 2033 midcomRuleExternalIpAddr, 2034 midcomRuleExternalPort, 2035 midcomRuleTransportProtocol, 2036 midcomRulePortRange, 2037 midcomRulePortParity, 2038 midcomRuleFlowDirection, 2039 midcomRuleLifetime 2040 } 2041 STATUS current 2042 DESCRIPTION 2043 "A collection of objects providing information about 2044 policy rules." 2045 ::= { midcomGroups 3 } 2047 midcomGroupGroup OBJECT-GROUP 2048 OBJECTS { 2049 midcomGroupLifetime 2050 } 2051 STATUS current 2052 DESCRIPTION 2053 "A collection of objects providing information about 2054 policy rule groups." 2055 ::= { midcomGroups 4 } 2057 midcomNotificationsGroup OBJECT-GROUP 2058 OBJECTS { 2059 midcomSessionTermination, 2060 midcomRuleEvent, 2061 midcomGroupEvent 2062 } 2063 STATUS current 2064 DESCRIPTION 2065 "The notifications emitted by the midcomMIB." 2066 ::= { midcomGroups 5 } 2068 END 2070 7. Usage Examples 2072 This section presents some examples that explain how a manager can 2073 use the MIDCOM MIB defined in this memo. The purpose of these 2074 examples is to explain the steps that are normally used to perform 2075 MIDCOM transactions. For each MIDCOM transaction defined in the 2076 MIDCOM semantics in RFC XXXX, a sequence of SNMP operations is 2077 described, which realizes the transaction. 2079 We see three different ways, a MIDCOM agent can choose to operate on 2080 the MIDCOM MIB. The first one is in line with the MIDCOM semantics. 2081 It models MIDCOM transactions as described in section 4.2 using SNMP 2082 notifications for signaling completion of processing a transaction 2083 from the MIDCOM MIB implementation to the MIDCOM agent. 2085 The second way uses notifications in configuration transactions only 2086 in 'unexpected' cases, when a request failes. The third one does not 2087 use notifications at all in configuration transaction. We describe 2088 the realization of MIDCOM transactions for the first way of operating 2089 on the MIDCOM MIB. For the other two ways, just the differences to 2090 the first ways are summarized at the end of this section. 2092 7.1. Session Establishment (SE) 2094 This example explains the steps performed by an SNMP manager to 2095 establish a MIDCOM session. 2097 1. The MIDCOM agent first checks the middlebox capabilities by 2098 reading objects in the midcomCapabilities group. 2100 2. The MIDCOM agent reads the midcomSessionNextIndex object in order 2101 to receive an index for creating a session. 2103 3. The manager creates a row in the midcomSessionTable by issuing an 2104 SNMP set-request. The midcomSessionRowStatus object is set to 2105 createAndWait(5). The new row is indexed by the MIDCOM agent's 2106 USM user name and by the index read from the 2107 midcomSessionNextIndex object in step 2. 2109 4. If the MIDCOM agent wants to have policies stored in the 2110 midcomRuleTable for some time after they are terminated, then it 2111 sets the midcomSessionRuleStorageTime object to the desired value. 2112 Otherwise, the default value of zero will be applied to the 2113 storage time of entries in the midcomRuleTable as long as the 2114 MIDCOM agent does not change this object. 2116 5. If the agent wants to have all policy rules it creates to be 2117 member of the same policy rule group, then the MIDCOM agent should 2118 set the midcomSessionRuleGroupIndex to the group index that is to 2119 be used. 2121 7.2. Session Termination (ST) 2123 This example explains the steps performed by an SNMP manager to 2124 terminate a MIDCOM session. 2126 1. The manager sends an SNMP set-request to change the 2127 midcomSessionRowStatus object to destroy(6). This will remove the 2128 row from the midcomSessionTable but not have an effect on entries 2129 in the midcomRuleTable created from this session. 2131 7.3. Asynchronous Session Termination (AST) 2133 At any time, the MIDCOM MIB implementation may terminate a session. 2134 Only two steps are required for performing this transaction. 2136 1. The MIDCOM MIB implementation sends a midcomSessionTermination 2137 notification to the SNMP manager owning the session. 2139 2. The MIDCOM MIB implementation removes the corresponding row of the 2140 midcomSessionTable. This does not affect entries in other tables. 2142 7.4. Policy Reserve Rule (PRR) 2144 This example explains the steps performed by an SNMP manager to 2145 establish a policy reserve rule. 2147 1. If the new policy rule should become a member of an already 2148 existing policy rule group, then the SNMP manager sets the 2149 midcomSessionGroupIndex object to the index of that group. 2150 Otherwise, it sets this object to 0. 2152 2. The SNMP manager reads the midcomSessionRuleNextIndex for an open 2153 entry in the modcomSessionTable in order to receive an object 2154 identifier for creating a new entry in the midcomRuleTable. 2156 3. The SNMP manager sets the midcomSessionCreateRule object to the 2157 value read in step 2. This creates a new row in the 2158 midcomRuleTable that is addressed by the object idenitfier written 2159 to the midcomSessionCreateRule object. 2161 4. The SNMP manager sets the following objects in the new row of the 2162 midcomRuleTable to specify all request parameters of the PRR 2163 transaction: 2164 - midcomRuleNatService 2165 - midcomRuleInternalIpVersion 2166 - midcomRuleInternalIpAddr 2167 - midcomRuleInternalPort 2168 - midcomRuleInsideInterface 2169 - midcomRuleOutsideInterface 2170 - midcomRuleExternalIpVersion 2171 - midcomRuleTransportProtocol 2172 - midcomRulePortRange 2173 - midcomRulePortParity 2174 - midcomRuleLifeime 2176 5. The SNMP manager sets the midcomRuleAdminStatus objects in the new 2177 row of the midcomRuleTable to reserved(1). 2179 6. The SNMP manager waits for a midcomRuleEvent notification 2180 concerning the new row in the midcomSessionTable. 2182 7. After receiving the midcomRuleEvent notification SNMP manager 2183 checks the lifetime value carried by the notification. If it is 2184 greater than 0, the SNMP manager read all positive reply 2185 parameters of the PRR transaction: 2186 - midcomRuleInsideIpAddr 2187 - midcomRuleInsidePort 2188 - midcomRuleOutsideIpAddr 2189 - midcomRuleOutsidePort 2190 - midcomRuleLifetime 2192 If the lifetime equals 0, then SNMP manager reads the 2193 midcomRuleOperStatus and the midcomRuleError in order to analyze 2194 the failure reason. 2196 7.5. Policy Enable Rule (PER) after PRR 2198 This example explains the steps performed by an SNMP manager to 2199 establish a policy enable rule after a corresponding policy reserve 2200 rule was already established. 2202 1. The SNMP manager sets the following objects in the row of the 2203 established PRR in the midcomRuleTable to specify all request 2204 parameters of the PER transaction: 2205 - midcomRuleExternalIpAddr 2206 - midcomRuleExternalPort 2207 - midcomRulePortParity 2208 - midcomRuleFlowDirection 2210 2. The SNMP manager sets the midcomRuleAdminStatus objects in the row 2211 of the established PRR in the midcomRuleTable to enabled(1). 2213 3. The SNMP manager waits for a midcomRuleEvent notification 2214 concerning the new row in the midcomSessionTable. 2216 4. After receiving the midcomRuleEvent notification SNMP manager 2217 checks the lifetime value carried by the notification. If it is 2218 greater than 0, the SNMP manager read all positive reply 2219 parameters of the PER transaction: 2220 - midcomRuleInsideIpAddr 2221 - midcomRuleInsidePort 2222 - midcomRuleOutsideIpAddr 2223 - midcomRuleOutsidePort 2224 - midcomRuleLifetime 2226 If the lifetime equals 0, then SNMP manager reads the 2227 midcomRuleOperStatus and the midcomRuleError in order to analyze 2228 the failure reason. 2230 7.6. Policy Enable Rule (PER) without previous PRR 2232 This example explains the steps performed by an SNMP manager to 2233 establish a policy enable rule for which no PRR transaction has been 2234 performed before. 2236 1. Identical to step 1 for PRR. 2238 2. Identical to step 2 for PRR. 2240 3. Identical to step 3 for PRR. 2242 4. The SNMP manager sets the following objects in the new row of the 2243 midcomRuleTable to specify all request parameters of the PER 2244 transaction: 2245 - midcomRuleInternalIpVersion 2246 - midcomRuleInternalIpAddr 2247 - midcomRuleInternalPort 2248 - midcomRuleInsideInterface 2249 - midcomRuleOutsideInterface 2250 - midcomRuleExternalIpVersion 2251 - midcomRuleExternalIpAddr 2252 - midcomRuleExternalPort 2253 - midcomRuleTransportProtocol 2254 - midcomRulePortRange 2255 - midcomRulePortParity 2256 - midcomRuleFlowDirection 2257 - midcomRuleLifetime 2259 5. The SNMP manager sets the midcomRuleAdminStatus objects in the new 2260 row of the midcomRuleTable to enabled(1). 2262 6. Identical to step 6 for PRR. 2264 7. After receiving the midcomRuleEvent notification SNMP manager 2265 checks the lifetime value carried by the notification. If it is 2266 greater than 0, the SNMP manager read all positive reply 2267 parameters of the PRR transaction: 2268 - midcomRuleInsideIpAddr 2269 - midcomRuleInsidePort 2270 - midcomRuleOutsideIpAddr 2271 - midcomRuleOutsidePort 2272 - midcomRuleFlowDirection 2273 - midcomRuleLifetime 2275 If the lifetime equals 0, then SNMP manager reads the 2276 midcomRuleOperStatus and the midcomRuleError in order to analyze 2277 the failure reason. 2279 7.7. Policy Rule Lifetime Change (RLC) 2281 This example explains the steps performed by an SNMP manager to 2282 change the lifetime of a policy rule. Changing the lifetime to 0 2283 implies terminating the policy rule. 2285 1. The SNMP manager issues a set-request for writing the desired 2286 lifetime to the midcomRuleLifetime object in the corresponding row 2287 of the midcomRuleTable. 2289 2. The SNMP manager waits for a midcomRuleEvent notification 2290 concerning the corresponding row in the midcomRuleTable. 2292 3. After receiving the midcomRuleEvent notification SNMP manager 2293 checks the lifetime value carried by the notification. 2295 7.8. Policy Rule List (PRL) 2297 The SNMP agent can browse the list of policy rules by browsing the 2298 midcomRuleTable. For each observed row in this table, the SNMP agent 2299 should check the midcomRuleOperStatus in order to find out, if the 2300 row contains information about an established policy rule or of a 2301 rule that is under construction or already terminated. 2303 7.9. Policy Rule Status (PRS) 2305 The SNMP agent can retrieve all status information and properties of 2306 a policy rule by reading the managed objects in the corresponding row 2307 of the midcomRuleTable. 2309 7.10. Asynchronous Policy Rule Event (ARE) 2311 At any time, the MIDCOM MIB implementation may terminate a policy 2312 rule. in this case two steps are required for performing this 2313 transaction: 2315 1. The MIDCOM MIB implementation sends a midcomRuleEvent notification 2316 containing a lifetime value of 0 to the SNMP manager owning the 2317 session. 2319 2. If the midcomRuleStorageTime object in the corresponding row of 2320 the midcomRuleTable has a value of 0 then the MIDCOM MIB 2321 implementation removes the row from the table. Otherwise, it 2322 changes in this row the midcomRuleLifetime object to 0 and the 2323 midcomRuleOperStatus object to terminated(13). 2325 The procedure is the same if the lifetime of a policy rule expires. 2326 The only difference is that the midcomRuleOperStatus object is set to 2327 timedOut(11) instead of terminated(13). 2329 7.11. Group Lifetime Change (GLC) 2331 This example explains the steps performed by an SNMP manager to 2332 change the lifetime of a policy rule group. Changing the lifetime to 2333 0 implies terminating all member policies of the group. 2335 1. The SNMP manager issues a set-request for writing the desired 2336 lifetime to the midcomGroupLifetime object in the corresponding 2337 row of the midcomGroupTable. 2339 2. The SNMP manager waits for a midcomGroupEvent notification 2340 concerning the corresponding row in the midcomGroupTable. 2342 3. After receiving the midcomRuleEvent notification SNMP manager 2343 checks the lifetime value carried by the notification. 2345 7.12. Group List (GL) 2347 The SNMP agent can browse the list of policy rule groups by browsing 2348 the midcomGroupTable. For each observed row in this table, the SNMP 2349 agent should check the midcomGroupLifetime in order to find out, if 2350 the group does contain established policies. 2352 7.13. Group Status (GS) 2354 The SNMP agent can retrieve all member policies of a group by 2355 browsing the midcomRuleTable using the midcomGroupIndex of the 2356 particular group. For retriving the remaining lifetime of the group, 2357 the SNMP agent reads the midcomGroupLifetime object in the 2358 corresponding row of the midcomGroupTable. 2360 7.14. Using Notifications For Negative Replies Only 2362 To be done. 2364 7.15. Not Using Notifications For Replies 2366 To be done. 2368 8. Security Considerations 2370 Still to be completed. Very important for this module! More text 2371 here .... 2373 SNMP versions prior to SNMPv3 did not include adequate security. 2374 Even if the network itself is secure (for example by using IPSec), 2375 even then, there is no control as to who on the secure network is 2376 allowed to access and GET/SET (read/change/create/delete) the objects 2377 in this MIB module. 2379 It is REQUIRED that implementers consider the security features as 2380 provided by the SNMPv3 framework (see [RFC3410], section 8), 2381 including full support for the SNMPv3 cryptographic mechanisms (for 2382 authentication and privacy). 2384 For implementations of the MIDCOM MIB it is REQUIRED to deploy SNMPv3 2385 and to enable cryptographic security. It is then a customer/operator 2386 responsibility to ensure that the SNMP entity giving access to an 2387 instance of this MIB module is properly configured to give access to 2388 the objects only to those principals (users) that have legitimate 2389 rights to indeed GET or SET (change/create/delete) them. 2391 9. Open Issues 2393 - notification identifiers, transaction identifiers 2394 - effect on other MIB modules missing 2395 - security considerations not complete 2396 - discuss atomicity of PRR and PER transactions 2397 - grop lifetime: ref to semantics not appropriate 2398 - rule lifetime: ref to semantics not appropriate 2399 - centi-seconds or seconds? 2400 - session index requred? 2401 - DEFVAL for A0, A1, A2, A3 2402 - collision of midcomRulePortParity usage 2403 - redundant inside/outside IpVersions 2404 - missing description of midcomsessionIndexNext 2405 - means for configuring which notifications to receive 2406 - examples for using less notifications 2407 - a set of issues raised by David Harrington 2409 10. Normative References 2411 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 2412 Rayhan, "Middlebox communication architecture and 2413 framework", RFC 3303, August 2002. 2415 [RFC3304] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S. and M. Shore, 2416 "Middlebox Communications (midcom) Protocol Requirements", 2417 RFC 3304, August 2002. 2419 [RFCXXXX] Stiemerling, M., Quittek, J. and T. Tailor, "Middlebox 2420 Communications (midcom) protocol semantics", RFC XXXX, 2421 YYYYmonth 2003, . 2423 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 2424 Rose, M. and S. Waldbusser, "Structure of Management 2425 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 2426 1999. 2428 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 2429 Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", 2430 STD 58, RFC 2579, April 1999. 2432 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 2433 Rose, M. and S. Waldbusser, "Conformance Statements for 2434 SMIv2", STD 58, RFC 2580, April 1999. 2436 [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture 2437 for Describing Simple Network Management Protocol (SNMP) 2438 Management Frameworks", STD 62, RFC 3411, December 2002. 2440 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 2441 MIB", RFC 2863, June 2000. 2443 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 2444 (USM) for version 3 of the Simple Network Management 2445 Protocol (SNMPv3)", RFC 2574, April 1999. 2447 11. Informative References 2449 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 2450 "Introduction and Applicability Statements for Internet- 2451 Standard Management Framework", RFC 3410, December 2002. 2453 [NAT-TERM] Srisuresh,P., and Holdrege, M., "IP Network Translator (NAT) 2454 Terminology and Considerations", RFC 2663, August 1999. 2456 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2457 2246, January 1999. 2459 [RFC2402] Kent, S., and Atkinson, R., "IP Authentication Header", RFC 2460 2402, November 1998. 2462 [RFC2406] Kent, S., and Atkinson, R., "IP Encapsulating Security 2463 Payload (ESP)", RFC 2406, November 1998. 2465 12. Authors' Addresses 2467 Juergen Quittek 2468 NEC Europe Ltd. 2469 Network Laboratories 2470 Kurfuersten-Anlage 34 2471 69115 Heidelberg 2472 Germany 2474 Phone: +49 6221 90511-15 2475 EMail: quittek@ccrle.nec.de 2477 Martin Stiemerling 2478 NEC Europe Ltd. 2479 Network Laboratories 2480 Kurfuersten-Anlage 34 2481 69115 Heidelberg 2482 Germany 2484 Phone: +49 6221 90511-13 2485 Email: stiemerling@ccrle.nec.de 2487 13. Full Copyright Statement 2489 Copyright (C) The Internet Society (2003). All Rights Reserved. 2491 This document and translations of it may be copied and furnished to 2492 others, and derivative works that comment on or otherwise explain it 2493 or assist in its implementation may be prepared, copied, published 2494 and distributed, in whole or in part, without restriction of any 2495 kind, provided that the above copyright notice and this paragraph are 2496 included on all such copies and derivative works. However, this 2497 document itself may not be modified in any way, such as by removing 2498 the copyright notice or references to the Internet Society or other 2499 Internet organizations, except as needed for the purpose of 2500 developing Internet standards in which case the procedures for 2501 copyrights defined in the Internet Standards process must be 2502 followed, or as required to translate it into languages other than 2503 English. 2505 The limited permissions granted above are perpetual and will not be 2506 revoked by the Internet Society or its successors or assigns. 2508 This document and the information contained herein is provided on an 2509 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2510 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2511 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2512 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2513 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.