Roxen Community: RFC 5190 Definitions of Managed Objects for Middlebox Communication (Standards Track)

[Text version]

Network Working Group
Request for Comments: 5190
Category: Standards Track J. Quittek
M. Stiemerling
NEC
P. Srisuresh
Kazeon Systems
March 2008
Status of This Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189.

Table of Contents
1. Introduction ....................................................4 2. The Internet-Standard Management Framework ......................4 3. Overview ........................................................4 3.1. Terminology ................................................5 4. Realizing the MIDCOM Protocol with SNMP .........................6 4.1. MIDCOM Sessions ............................................6 4.1.1. Authentication and Authorization ....................6 4.2. MIDCOM Transactions ........................................7 4.2.1. Asynchronous Transactions ...........................7 4.2.2. Configuration Transactions ..........................8 4.2.3. Monitoring Transactions ............................11 4.2.4. Atomicity of MIDCOM Transactions ...................12 4.2.4.1. Asynchronous MIDCOM Transactions ..........12 4.2.4.2. Session Establishment and Termination Transactions ..................12 4.2.4.3. Monitoring Transactions ...................13 4.2.4.4. Lifetime Change Transactions ..............13 4.2.4.5. Transactions Establishing New Policy Rules ..............................14 4.2.5. Access Control .....................................14 4.3. Access Control Policies ...................................14 5. Structure of the MIB Module ....................................15 5.1. Transaction Objects .......................................16 5.1.1. midcomRuleTable ....................................17 5.1.2. midcomGroupTable ...................................19 5.2. Configuration Objects .....................................20 5.2.1. Capabilities .......................................20 5.2.2. midcomConfigFirewallTable ..........................21 5.3. Monitoring Objects ........................................22 5.3.1. midcomResourceTable ................................22 5.3.2. midcomStatistics ...................................24 5.4. Notifications .............................................25 6. Recommendations for Configuration and Operation ................26 6.1. Security Model Configuration ..............................26 6.2. VACM Configuration ........................................27 6.3. Notification Configuration ................................28 6.4. Simultaneous Access .......................................28 6.5. Avoiding Idempotency Problems .............................29 6.6. Interface Indexing Problems ...............................29 6.7. Applicability Restrictions ................................30 7. Usage Examples for MIDCOM Transactions .........................30 7.1. Session Establishment (SE) ................................31 7.2. Session Termination (ST) ..................................31 7.3. Policy Reserve Rule (PRR) .................................31 7.4. Policy Enable Rule (PER) after PRR ........................33 7.5. Policy Enable Rule (PER) without Previous PRR .............34
7.6. Policy Rule Lifetime Change (RLC) .........................35 7.7. Policy Rule List (PRL) ....................................35 7.8. Policy Rule Status (PRS) ..................................35 7.9. Asynchronous Policy Rule Event (ARE) ......................36 7.10. Group Lifetime Change (GLC) ..............................36 7.11. Group List (GL) ..........................................36 7.12. Group Status (GS) ........................................37 8. Usage Examples for Monitoring Objects ..........................37 8.1. Monitoring NAT Resources ..................................37 8.2. Monitoring Firewall Resources .............................38 9. Definitions ....................................................38 10. Security Considerations .......................................85 10.1. General Security Issues ..................................85 10.2. Unauthorized Middlebox Configuration .....................86 10.3. Unauthorized Access to Middlebox Configuration ...........87 10.4. Unauthorized Access to MIDCOM Service Configuration ......88 11. Acknowledgements ..............................................88 12. IANA Considerations ...........................................88 13. Normative References ..........................................88 14. Informative References ........................................90
1. Introduction

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow controlling middleboxes.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].

Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].

3. Overview

The managed objects defined in this document serve for controlling firewalls and Network Address Translators (NATs). As defined in [RFC3234], firewalls and NATs belong to the group of middleboxes. A middlebox is a device on the datagram path between source and destination, which performs other functions than just IP routing. As outlined in [RFC3303], firewalls and NATs are potential obstacles to packet streams, for example, if dynamically negotiated UDP or TCP port numbers are used, as in many peer-to-peer communication applications.

As one possible solution for this problem, the IETF MIDCOM working group defined a framework [RFC3303], requirements [RFC3304], and protocol semantics [RFC5189] for communication between applications and middleboxes acting as firewalls, NATs, or a combination of both. The MIDCOM architecture and framework define a model in which trusted third parties can be delegated to assist middleboxes in performing their operations, without requiring application intelligence being embedded in the middleboxes. This trusted third party is referred to as the MIDCOM agent. The MIDCOM protocol is defined between a MIDCOM agent and a middlebox. The managed objects defined in this document can be used for dynamically configuring middleboxes on the datagram path to permit datagrams traversing the middleboxes. This way, applications can, for example, request pinholes at firewalls and address bindings at NATs.
Besides managed objects for controlling the middlebox operation, this document also defines managed objects that provide information on middlebox resource usage (such as firewall pinholes, NAT bindings, NAT sessions, etc.) affected by requests.
Since firewalls and NATs are critical devices concerning network security, security issues of middlebox communication need to be considered very carefully.

3.1. Terminology

The terminology used in this document is fully aligned with the terminology defined in [RFC5189] except for the term 'MIDCOM agent'. For this term, there is a conflict between the MIDCOM terminology and the SNMP terminology. The roles of entities participating in SNMP communication are called 'manager' and 'agent' with the agent acting as server for requests from the manager. This use of the term 'agent' is different from its use in the MIDCOM framework: The SNMP manager corresponds to the MIDCOM agent and the SNMP agent corresponds to the MIDCOM middlebox, also called MIDCOM server. In order to avoid confusion in this document specifying a MIB module, we replace the term 'MIDCOM agent' with 'MIDCOM client'. Whenever the term 'agent' is used in this document, it refers to the SNMP agent. Figure 1 sketches the entities of MIDCOM in relationship to SNMP manager and SNMP agent.
+---------+ MIDCOM +-----------+ | MIDCOM |<~ ~ ~ ~ ~ ~ ~ ~>| MIDCOM | | Client | Transaction | middlebox | | | | (server) | +---------+ +-----------+ ^ ^ | | v v +---------+ +-----------+ | SNMP | SNMP | SNMP | | Manager |<===============>| Agent | +---------+ Protocol +-----------+
Figure 1: Mapping of MIDCOM to SNMP
4. Realizing the MIDCOM Protocol with SNMP

In order to realize middlebox communication as described in [RFC5189], several aspects and properties of the MIDCOM protocol need to be mapped to SNMP capabilities and expressed in terms of the Structure of Management Information version 2 (SMIv2).

Basic concepts to be mapped are MIDCOM sessions and MIDCOM transactions. For both, access control policies need to be supported.

4.1. MIDCOM Sessions

SNMP has no direct support for sessions. Therefore, they need to be modeled. A MIDCOM session is stateful and has a context that is valid for several transactions. For SNMP, a context is valid for a single transaction only, for example, covering just a single request/reply pair of messages.

Properties of sessions that are utilized by the MIDCOM semantics and not available in SNMP need to be modeled. Particularly, the middlebox needs to be able to authenticate MIDCOM clients, authorize access to policy rules, and send notification messages concerning policy rules to MIDCOM clients participating in a session. In the MIDCOM-MIB module, authentication and access control are performed on a per-message basis using an SNMPv3 security model, such as the User-based Security Model (USM) [RFC3414], for authentication, and the View-based Access Control Model (VACM) [RFC3415] for access control. Sending notifications to MIDCOM clients is controlled by access control models such as VACM and a mostly static configuration of objects in the SNMP-TARGET-MIB [RFC3413] and the SNMP- NOTIFICATION-MIB [RFC3413].
This session model is static except that the MIDCOM client can switch on and off the generation of SNMP notifications that the middlebox sends. Recommended configurations of VACM and the SNMP-TARGET-MIB and the SNMP-NOTIFICATION-MIB that can serve for modeling a session are described in detail in section 6.

4.1.1. Authentication and Authorization

MIDCOM sessions are required for providing authentication, authorization, and encryption for messages exchanged between a MIDCOM client and a middlebox. SNMPv3 provides these features on a per- message basis instead of a per-session basis applying a security model and an access control model, such as USM and VACM. Per-message
security mechanisms can be considered as overhead compared to per- session security mechanisms, but it certainly satisfies the security requirements of middlebox communication.
For each authenticated MIDCOM client, access to the MIDCOM-MIB, particularly to policy rules, should be configured as part of the VACM configuration of the SNMP agent.

4.2. MIDCOM Transactions

[RFC5189] defines the MIDCOM protocol semantics in terms of transactions and transaction parameters. Transactions are grouped into request-reply transactions and asynchronous transactions.

SNMP offers simple transactions that in general cannot be mapped one-to-one to MIDCOM transactions. This section describes how the MIDCOM-MIB module implements MIDCOM transactions using SNMP transactions. The concerned MIDCOM transactions are asynchronous transactions and request-reply transactions. Within the set of request-reply transactions, we distinguish configuration transactions and monitoring transactions, because they are implemented in slightly different ways by using SNMP transactions.
The SNMP terminology as defined in [RFC3411] does not use the concept of transactions, but of SNMP operations. For the considerations in this section, we use the terms SNMP GET transaction and SNMP SET transaction. An SNMP GET transaction consists of an SNMP Read Class operation and an SNMP Response Class operation. An SNMP SET transaction consists of an SNMP Write Class operation and an SNMP Response Class operation.

4.2.1. Asynchronous Transactions

Asynchronous transactions can easily be modeled by SNMP Notification Class operations. An asynchronous transaction contains a notification message with one to three parameters. The message can be realized as an SNMP Notification Class operation with the parameters implemented as managed objects contained in the notification.
+--------------+ notification +------------+ | MIDCOM client|<--------------| middlebox | +--------------+ message +------------+
MIDCOM asynchronous transaction
+--------------+ SNMP +------------+ | SNMP manager |<--------------| SNMP agent | +--------------+ notification +------------+
Implementation of MIDCOM asynchronous transaction
Figure 2: MIDCOM asynchronous transaction mapped to SNMP Notification Class operation
One of the parameters is the transaction identifier that should be unique per middlebox. It does not have to be unique for all notifications sent by the particular SNMP agent, but for all sent notifications that are defined by the MIDCOM-MIB module.
Note that SNMP notifications are usually sent as unreliable UDP packets and may be dropped before they reach their destination. If a MIDCOM client is expecting an asynchronous notification on a specific transaction, it would be the job of the MIDCOM client to poll the middlebox periodically and monitor the transaction in case notifications are lost along the way.

4.2.2. Configuration Transactions

All request-reply transactions contain a request message, a reply message, and potentially also a set of notifications. In general, they cannot be modeled by just having a single SNMP message per MIDCOM message, because some of the MIDCOM messages carry a large set of parameters that do not necessarily fit into an SNMP message consisting of a single UDP packet only.

For configuration transactions, the MIDCOM request message can be modeled by one or more SNMP SET transactions. The action of sending the MIDCOM request to the middlebox is realized by writing the parameters contained in the message to managed objects at the SNMP agent. If necessary, the SNMP SET transaction includes creating these managed objects. If not all parameters of the MIDCOM request message can be set by a single SNMP SET transaction, then more than one SET transaction is used; see Figure 3. Completion of the last of the SNMP transactions indicates that all required parameters are set and that processing of the MIDCOM request message can start at the middlebox.
Please note that a single SNMP SET transaction consists of an SNMP SET request message and an SNMP SET reply message. Both are sent as unreliable UDP packets and may be dropped before they reach their destination. If the SNMP SET request message or the SNMP reply message is lost, then the SNMP manager (the MIDCOM client) needs to take action, for example, by just repeating the SET transaction or by first checking the success of the initial write transaction with an SNMP GET transaction and then only repeating the SNMP SET transaction if necessary.
+--------------+ request +------------+ | MIDCOM client|-------------->| middlebox | +--------------+ message +------------+
MIDCOM request message
+--------------+ +------------+ | | SNMP SET | | | |-------------->| | | | message | | | | | | | | SNMP SET | | | |<--------------| | | | reply message | | | SNMP manager | | SNMP agent | | | SNMP SET | | | |- - - - - - - >| | | | message | | | | | | | | SNMP SET | | | |< - - - - - - -| | | | reply message | | | | | | | | . . . | | +--------------+ +------------+
Implementation of MIDCOM request message by one or more SNMP SET transactions
Figure 3: MIDCOM request message mapped to SNMP SET transactions
The MIDCOM reply message can be modeled in two ways. The first way is an SNMP Notification Class operation optionally followed by one or more SNMP GET transactions as shown in Figure 4. The MIDCOM server informs the MIDCOM client about the end of processing the request by sending an SNMP notification. If possible, the SNMP notification carries all reply parameters. If this is not possible, then the SNMP manager has to perform additional SNMP GET transactions as long as necessary to receive all of the reply parameters.
+--------------+ reply +------------+ | MIDCOM client|<--------------| middlebox | +--------------+ message +------------+
MIDCOM reply message
+--------------+ +------------+ | | SNMP | | | |<--------------| | | | notification | | | | | | | | SNMP GET | | | |-------------->| | | | message | | | SNMP manager | | SNMP agent | | | SNMP GET | | | |<--------------| | | | reply message | | | | | | | | SNMP GET | | | |- - - - - - - >| | | | message | | | | | | | | SNMP GET | | | |< - - - - - - -| | | | reply message | | | | | | | | . . . | | +--------------+ +------------+
Implementation of MIDCOM reply message by an SNMP notification and one or more SNMP GET transactions
Figure 4: MIDCOM reply message mapped to SNMP notification and optional GET transactions
The second way replaces the SNMP Notification Class operation by a polling operation of the SNMP manager. The manager polls status information at the SNMP agent using SNMP GET transactions until it detects the end of the processing of the request. Then it uses one or more SNMP GET transactions to receive all of the reply parameters. Note that this second way requires more SNMP operations, but is more reliable than the first way using an SNMP Notification Class operation.

4.2.3. Monitoring Transactions

The realization of MIDCOM monitoring transactions in terms of SNMP transactions is simpler. The request message is very short and just specifies a piece of information that the MIDCOM client wants to retrieve.
+--------------+ request +------------+ | |-------------->| | | | message | | | MIDCOM client| | middlebox | | | reply | | | |<--------------| | +--------------+ message +------------+
MIDCOM monitoring transaction
+--------------+ +------------+ | | SNMP GET | | | |-------------->| | | | message | | | | | | | | SNMP GET | | | |<--------------| | | | reply message | | | SNMP manager | | SNMP agent | | | SNMP GET | | | |- - - - - - - >| | | | message | | | | | | | | SNMP GET | | | |< - - - - - - -| | | | reply message | | | | | | | | . . . | | +--------------+ +------------+
Implementation of MIDCOM monitoring transaction by one or more SNMP GET messages
Figure 5: MIDCOM monitoring transaction mapped to SNMP GET transactions
Since monitoring is a strength of SNMP, there are sufficient means to realize MIDCOM monitoring transactions simpler than MIDCOM configuration transactions.
All MIDCOM monitoring transactions can be realized as a sequence of SNMP GET transactions. The number of SNMP GET transactions required depends on the amount of information to be retrieved.

4.2.4. Atomicity of MIDCOM Transactions

Given the realizations of MIDCOM transactions by means of SNMP transactions, atomicity of the MIDCOM transactions is not fully guaranteed anymore. However, this section shows that atomicity provided by the MIB module specified in section 9 is still sufficient for meeting the MIDCOM requirements specified in [RFC3304].

4.2.4.1. Asynchronous MIDCOM Transactions

There are two asynchronous MIDCOM transactions: Asynchronous Session Termination (AST) and Asynchronous Policy Rule Event (ARE). The very static realization of MIDCOM sessions in the MIDCOM-MIB, as described by section 4.1, does not anymore support the asynchronous termination of a session. Therefore, the AST transaction is not modeled. For the ARE, atomicity is maintained, because it is modeled by a single atomic SNMP notification transaction.

In addition, the MIDCOM-MIB supports an Asynchronous Group Event transaction, which is an aggregation of a set of ARE transactions. Also, this MIDCOM transaction is implemented by a single SNMP transaction.

4.2.4.2. Session Establishment and Termination Transactions

The MIDCOM-MIB models MIDCOM sessions in a very static way. The only dynamic actions within these transactions are enabling and disabling the generation of SNMP notifications at the SNMP agent.

For the Session Establishment (SE) transaction, the MIDCOM client first reads the middlebox capabilities. It is not relevant whether or not this action is atomic because a dynamic change of the middlebox capabilities is not to be expected. Therefore, also non- atomic implementations of this action are acceptable.
Then, the MIDCOM agent needs to enable the generation of SNMP notifications at the middlebox. This can be realized by writing to a single managed object in the SNMP-NOTIFICATION-MIB [RFC3413]. But even other implementations are acceptable, because atomicity is not required for this step. For the Session Termination (ST) transaction, the only required action is disabling the generation of SNMP notifications at the middlebox. As for the SE transaction, this action can be realized atomically by using the SNMP-NOTIFICATION-MIB, but also other implementations are acceptable because atomicity is not required for this action.

4.2.4.3. Monitoring Transactions

Potentially, the monitoring transactions Policy Rule List (PRL), Policy Rule Status (PRS), Group List (GL), and Group Status (GS) are not atomic, because these transactions may be implemented by more than one SNMP GET operation.

The problem that might occur is that while the monitoring transaction is performed, the monitored items may change. For example, while reading a long list of policies, new policies may be added and already read policies may be deleted. This is not in line with the protocol semantics. However, it is not in direct conflict with the MIDCOM requirement requesting the middlebox state to be stable and known by the MIDCOM client, because the middlebox notifies the MIDCOM client on all changes to its state that are performed during the monitoring transaction by sending notifications.
If the MIDCOM client receives such a notification while performing a monitoring transaction (or shortly after completing it), the MIDCOM client can then either repeat the monitoring transaction or integrate the result of the monitoring transaction with the information received via notifications during the transaction. In both cases, the MIDCOM client will know the state of the middlebox.

4.2.4.4. Lifetime Change Transactions

For the policy Rule Lifetime Change (RLC) transaction and the Group Lifetime Change (GLC) transaction, atomicity is maintained. They both have very few parameters for the request message and the reply message. The request parameters can be transmitted by a single SNMP SET request message, and the reply parameters can be transmitted by a single SNMP notification message. In order to prevent idempotency problems by retransmitting an SNMP request after a lost SNMP reply, it is RECOMMENDED that either snmpSetSerialNo (see [RFC3418]) is included in the corresponding SNMP SET request or the value of the SNMP retransmission timer be lower than the smallest requested lifetime value. The same recommendation applies to the smallest requested value for the midcomRuleStorageTime. MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack such that no retransmissions are sent.

4.2.4.5. Transactions Establishing New Policy Rules

Analogous to the monitoring transactions, the atomicity may not be given for Policy Reserve Rule (PRR) and Policy Enable Rule (PER) transactions. Both transactions are potentially implemented using more than one SNMP SET operation and GET operation for obtaining transaction reply parameters. The solution for this loss of atomicity is the same as for the monitoring transactions.

There is an additional atomicity problem for PRR and PER. If transferring request parameters requires more than a single SET operation, then there is the potential problem that multiple MIDCOM clients sharing the same permissions are able to access the same policy rule. In this case, a client could alter request parameters already set by another client before the first client could complete the request. However, this is acceptable since usually only one agent is creating a policy rule and filling it subsequently. It can also be assumed that in most cases where clients share permissions, they act in a more or less coordinated way avoiding such interferences.
All atomicity problems caused by using multiple SNMP SET transactions for implementing the MIDCOM request message can be avoided by transferring all request parameters with a single SNMP SET transaction.

4.2.5. Access Control

Since SNMP does not offer per-session authentication and authorization, authentication and authorization are performed per SNMP message sent from the MIDCOM client to the middlebox.

For each transaction, the MIDCOM client has to authenticate itself as an authenticated principal, such as a USM user. Then, the principal's access rights to all resources affected by the transaction are checked. Access right control is realized by configuring the access control mechanisms, such as VACM, at the SNMP agent.

4.3. Access Control Policies

Potentially, a middlebox has to control access for a large set of MIDCOM clients and to a large set of policy rules configuring firewall pinholes and NAT bindings. Therefore, it can be beneficial to use access control policies for specifying access control rules. Generating, provisioning, and managing these policies are out of scope of this MIB module.
However, if such an access control policy system is used, then the SNMP agent acts as a policy enforcement point. An access control policy system must transform all active policies into configurations of, for example, the SNMP agent's View-based Access Control Model (VACM).
The mechanisms of access control models, such as VACM, allow an access control policy system to enforce MIDCOM client authentication rules and general access control of MIDCOM clients to middlebox control.
The mechanisms of VACM can be used to enforce access control of authenticated clients to MIDCOM-MIB policy rules based on the concept of ownership. For example, an access control policy can specify that MIDCOM-MIB policy rules owned by user A cannot be accessed at all by user B, can be read by user C, and can be read and modified by user D.
Further access control policies can control access to concrete middlebox resources. These are enforced, when a MIDCOM request is processed. For example, an authenticated MIDCOM client may be authorized to request new MIDCOM policies to be established, but only for certain IP address ranges. The enforcement of this kind of policies may not be realizable using available SNMP mechanisms, but needs to be performed by the individual MIB module implementation.

5. Structure of the MIB Module

The MIB module defined in section 9 contains three kinds of managed objects:
- Transaction objects Transaction objects are required for implementing the MIDCOM protocol requirements defined in [RFC3304] and the MIDCOM protocol semantics defined in [RFC5189].
- Configuration objects Configuration objects can be used for retrieving middlebox capability information (mandatory) and for setting parameters of the implementation of transaction objects (optional).
- Monitoring objects The optional monitoring objects provide information about used resources and about MIDCOM transaction statistics.
The transaction objects are organized in two tables: the midcomRuleTable and the midcomGroupTable. Entity relationships of entries of these tables and the midcomResourceTable from the monitoring objects are illustrated by Figure 6.
+--------------------+ | midcomRuleEntry | | indexed by | | midcomRuleOwner | | midcomGroupIndex | | midcomRuleIndex | +--------------------+ 1...n | | 1 | | 1 | | 1 +--------------------+ +---------------------+ | midcomGroupEntry | | midcomResourceEntry | | indexed by | | indexed by | | midcomRuleOwner | | midcomRuleOwner | | midcomGroupIndex | | midcomGroupIndex | +--------------------+ | midcomRuleIndex | +---------------------+ | | | | | | v v v NAT Firewall other MIB MIB MIB
Figure 6: Entity relationships of table entries
A MIDCOM client can create and delete entries in the midcomRuleTable. Entries in the midcomGroupTable are generated automatically as soon as there is an entry in the midcomRuleTable using the midcomGroupIndex. The midcomGroupTable can be used as shortcut for accessing all member rules with a single transaction. MIDCOM clients can group policy rules for various purposes. For example, they can assign a unique value for the midcomGroupIndex to all rules belonging to a single application or an application session served by the MIDCOM agent.
The midcomResourceTable augments the midcomRuleTable by information on the relationship of entries of the midcomRuleTable to resources listed in other MIB modules, such as the NAT-MIB [RFC4008].

5.1. Transaction Objects

The transaction objects are structured according to the MIDCOM semantics described in [RFC5189] into two subtrees, one for policy rule control and one for policy rule group control.

5.1.1. midcomRuleTable

The midcomRuleTable contains information about policy rules including policy rules to be established, policy rules for which establishing failed, established policy rules, and terminated policy rules.

Entries in this table are indexed by the combination of midcomRuleOwner, midcomGroupIndex, and midcomRuleIndex. The midcomRuleOwner is the owner of the rule; the midcomGroupIndex is the index of the group of which the policy rule is a member.
midcomRuleOwner is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-based Access Control Model (VACM [RFC3415]) and allows a management application to identify its entries.
Entries in this table are created by writing to midcomRuleRowStatus. Entries are removed when both their midcomRuleLifetime and midcomRuleStorageTime are timed out by counting down to 0. A MIDCOM client can explicitly remove an entry by setting midcomRuleLifetime and midcomRuleStorageTime to 0.
The table contains the following columnar objects:
o midcomRuleIndex The index of this entry must be unique in combination with the midcomRuleOwner and the midcomGroupIndex of the entry.
o midcomRuleAdminStatus For establishing a new policy rule, a set of objects in this entry needs to be written first. These objects are the request parameters. Then, by writing either reserve(1) or enable(2) to this object, the MIDCOM-MIB implementation is triggered to start processing the parameters and tries to establish the specified policy rule.
o midcomRuleOperStatus This read-only object indicates the current status of the entry. The entry may have an initializing state, it may have a transient state while processing requests, it may have an error state after a request was rejected, it may have a state where a policy rule is established, or it may have a terminated state.
o midcomRuleStorageType This object indicates whether or not the policy rule is stored as volatile, non-volatile, or permanent. Depending on the MIDCOM- MIB implementation, this object may be writable.
o midcomRuleStorageTime This object indicates how long the entry will still exist after entering an error state or a termination state.
o midcomRuleError This object is a string indicating the reason for entering an error state.
o midcomRuleInterface This object indicates the IP interface for which enforcement of a policy rule is requested or performed, respectively.
o midcomRuleFlowDirection This object indicates a flow direction for which a policy enable rule was requested or established, respectively.
o midcomRuleMaxIdleTime This object indicates the maximum idle time of the policy rule in seconds. If no packet to which the policy rule applies passes the middlebox for the time specified by midcomRuleMaxIdleTime, then the policy rule enters a termination state.
o midcomRuleTransportProtocol This object indicates a transport protocol for which a policy reserve rule or policy enable rule was requested or established, respectively.
o midcomRulePortRange This object indicates a port range for which a policy reserve rule or policy enable rule was requested or established, respectively.
o midcomRuleLifetime This object indicates the remaining lifetime of an established policy rule. The MIDCOM client can change the remaining lifetime by writing to it.
Beyond the listed objects, the table contains 10 further objects describing address parameters. They include the IP version, IP address, prefix length and port number for the internal address (A0), inside address (A1), outside address (A2), and external address (A3). These objects serve as parameters specifying a request or an established policy, respectively.
A0, A1, A2, and A3 are address tuples defined according to the MIDCOM semantics [RFC5189]. Each of them identifies either a communication endpoint at an internal or external device or an allocated address at the middlebox.
+----------+ +----------+ | internal | A0 A1 +-----------+ A2 A3 | external | | endpoint +----------+ middlebox +----------+ endpoint | +----------+ +-----------+ +----------+
Figure 7: Address tuples A0 - A3
- A0 - internal endpoint: Address tuple A0 specifies a communication endpoint of a device within the internal network, with respect to the middlebox.
- A1 - middlebox inside address: Address tuple A1 specifies a virtual communication endpoint at the middlebox within the internal network. A1 is the destination address for packets passing from the internal endpoint to the middlebox and is the source for packets passing from the middlebox to the internal endpoint.
- A2 - middlebox outside address: Address tuple A2 specifies a virtual communication endpoint at the middlebox within the external network. A2 is the destination address for packets passing from the external endpoint to the middlebox and is the source for packets passing from the middlebox to the external endpoint.
- A3 - external endpoint: Address tuple A3 specifies a communication endpoint of a device within the external network, with respect to the middlebox.
The MIDCOM-MIB requires the MIDCOM client to specify address tuples A0 and A3. This might be a problem for applications that are not designed in a firewall-friendly way. An example is an FTP application that uses the PORT command (instead of the recommended PASV command). The problem only occurs when the middlebox offers twice-NAT functionality, and it can be fixed following recommendations for firewall-friendly communication.

5.1.2. midcomGroupTable

The midcomGroupTable has an entry per existing policy rule group. Entries in this table are created automatically when creating member entries in the midcomRuleTable. Entries are automatically removed from this table when the last member entry is removed from the midcomRuleTable. Entries cannot be created or removed explicitly by the MIDCOM client.
Entries are indexed by the midcomRuleOwner of the rules that belong to the group and by a specific midcomGroupIndex. This allows each midcomRuleOwner to maintain its own independent group namespace.
An entry of the table contains the following objects:
o midcomGroupIndex The index of this entry must be unique in combination with the midcomRuleOwner of the entry.
o midcomGroupLifetime This object indicates the maximum of the remaining lifetimes of all established policy rules that are members of the group. The MIDCOM client can change the remaining lifetime of all member policies by writing to this object.
5.2. Configuration Objects

The configuration subtree contains middlebox capability and configuration information. Some of the contained objects are (optionally) writable and can also be used for configuring the middlebox service.

The capabilities subtree contains some general capability information and detailed information per supported IP interface. The midcomConfigFirewallTable can be used to configure how the MIDCOM-MIB implementation creates firewall rules in its firewall modules.
Note that typically, configuration objects are not intended to be written by MIDCOM clients. In general, write access to these objects needs to be restricted more strictly than write access to transaction objects.

5.2.1. Capabilities

Information on middlebox capabilities, i.e., capabilities of the MIDCOM-MIB implementation, is provided by the midcomCapabilities subtree of managed objects. The following objects are defined:
o midcomConfigMaxLifetime This object indicates the maximum lifetime that this middlebox allows policy rules to have.
o midcomConfigPersistentRules This is a boolean object indicating whether or not the middlebox is capable of storing policy rules persistently.
Further capabilities are provided by the midcomConfigIfTable per IP interface. This table contains just two objects. The first one is a BITS object called midcomConfigIfBits containing the following bit values:
o ipv4 and ipv6 These two bit values provide information on which IP versions are supported by the middlebox at the indexed interface.
o addressWildcards and portWildcards These two bit values provide information on wildcarding supported by the middlebox at the indexed interface.
o firewall and nat These two bit values provide information on availability of firewall and NAT functionality at the indexed interface.
o portTranslation, protocolTranslation, and twiceNat These three bit values provide information on the kind of NAT functionality available at the indexed interface.
o inside This bit indicates whether or not the indexed interface is an inside interface with respect to NAT functionality.
The second object, called midcomConfigIfEnabled, indicates whether the middlebox capabilities described by midcomConfigIfBits are available or not available at the indexed IP interface.
The midcomConfigIfTable uses index 0 for indicating capabilities that are available for all interfaces.

5.2.2. midcomConfigFirewallTable

The midcomConfigFirewallTable serves for configuring how policy rules created by MIDCOM clients are realized as firewall rules of a firewall implementation. Particularly, the priority used for MIDCOM-MIB policy rules can be configured. For a single firewall implementation at a particular IP interface, all MIDCOM-MIB policy rules are realized as firewall rules with the same priority. Also, a firewall rule group name can be configured. The table is indexed by the IP interface index.

An entry of the table contains the following objects:
o midcomConfigFirewallGroupId This object indicates the firewall rule group to which all firewall rules of the MIDCOM server are assigned.
o midcomConfigFirewallPriority This object indicates the priority assigned to all firewall rules of the MIDCOM server.
5.3. Monitoring Objects

The monitoring objects are structured into two subtrees: the resource subtree and the statistics subtree. The resource subtree provides information about which resources are used by which policy rule. The statistics subtree provides statistics about the usage of transaction objects.

5.3.1. midcomResourceTable

Information about resource usage per policy rule is provided by the midcomResourceTable. Each entry in the midcomResourceTable describes resource usage of exactly one policy rule.

Resources are NAT resources and firewall resources, depending on the type of middlebox. Used NAT resources include NAT bindings and NAT sessions. NAT address mappings are not covered. For firewalls, firewall filter rules are considered as resources.
The values provided by the following objects on NAT binds and NAT sessions may refer to the detailed resource usage description in the NAT-MIB module [RFC4008].
The values provided by the following objects on firewall rules may refer to more detailed firewall resource usage descriptions in other MIB modules.
Entries in the midcomResourceTable are only valid if the midcomRuleOperStatus object of the corresponding entry in the midcomRuleTable has a value of either reserved(7) or enabled(8).
An entry of the table contains the following objects:
o midcomRscNatInternalAddrBindMode This object indicates whether the binding of the internal address is an address NAT binding or an address-port NAT binding.
o midcomRscNatInternalAddrBindId This object identifies the NAT binding for the internal address in the NAT engine.
o midcomRscNatExternalAddrBindMode This object indicates whether the binding of the external address is an address NAT binding or an address-port NAT binding.
o midcomRscNatExternalAddrBindId This object identifies the NAT binding for the external address in the NAT engine.
o midcomRscNatSessionId1 This object links to the first NAT session associated with one of the above NAT bindings.
o midcomRscNatSessionId2 This object links to the optional second NAT session associated with one of the above NAT bindings.
o midcomRscFirewallRuleId This object indicates the firewall rule for this policy rule.
The MIDCOM-MIB module does not require a middlebox to implement further specific middlebox (NAT, firewall, etc.) MIB modules as, for example, the NAT-MIB module [RFC4008].
The resource identifiers in the midcomResourceTable may be vendor proprietary in the cases where the middlebox does not implement the NAT-MIB [RFC4008] or a firewall MIB. The MIDCOM-MIB module affects NAT binding and sessions, as well as firewall pinholes. It is intentionally not specified in the MIDCOM-MIB module how these NAT and firewall resources are allocated and managed, since this depends on the MIDCOM-MIB implementation and middlebox's capabilities. However, the midcomResourceTable is useful for understanding which resources are affected by which MIDCOM-MIB transaction.
The midcomResourceTable is beneficial to the middlebox administrator in that the table lists all MIDCOM transactions and the middlebox specific resources to which these transactions refer. For instance, multiple MIDCOM clients might end up using the same NAT bind, yet each MIDCOM client might define a Lifetime parameter and directionality for the bind that is specific to the transaction. MIDCOM-MIB implementations are responsible for impacting underlying middlebox resources so as to satisfy the sometimes overlapping requirements on the same resource from multiple MIDCOM clients.
Managing these resources is not a trivial task for MIDCOM-MIB implementers. It is possible that different MIDCOM-MIB policy rules owned by different MIDCOM clients share a NAT binding or a firewall rule. Then common properties, for example, the lifetime of the resource, need to be managed such that all clients are served well and changes to these resources need to be communicated to all affected clients. Also, dependencies between resources, for example, the precedence order of firewall rules, need to be considered carefully in order to avoid that different policy rules -- potentially owned by different clients -- influence each other.
MIDCOM clients may use the midcomResourceTable of the MIDCOM-MIB module in conjunction with the NAT-MIB module [RFC4008] to determine which resources of the NAT are used for MIDCOM. The NAT-MIB module stores the configured NAT bindings and sessions, and MIDCOM clients can use the information of the midcomResourceTable to sort out those NAT resources that are used by the MIDCOM-MIB module.

5.3.2. midcomStatistics

The statistics subtree contains a set of non-columnar objects that provide 'MIDCOM protocol statistics', i.e., statistics about the usage of transaction objects.
o midcomCurrentOwners This object indicates the number of different values for midcomRuleOwner for all current entries in the midcomRuleTable.
o midcomOwnersTotal This object indicates the summarized number of all different values that occurred for midcomRuleOwner in the midcomRuleTable current and in the past.
o midcomTotalRejectedRuleEntries This object indicates the total number of failed attempts to create an entry in the midcomRuleTable.
o midcomCurrentRulesIncomplete This object indicates the total number of policy rules that have not been fully loaded into a table row of the midcomRuleTable.
o midcomTotalIncorrectReserveRules This object indicates the total number of policy reserve rules that were rejected because the request was incorrect.
o midcomTotalRejectedReserveRules This object indicates the total number of policy reserve rules that were failed while being processed.
o midcomCurrentActiveReserveRules This object indicates the number of currently active policy reserve rules in the midcomRuleTable.
o midcomTotalExpiredReserveRules This object indicates the total number of expired policy reserve rules.
o midcomTotalTerminatedOnRqReserveRules This object indicates the total number of policy reserve rules that were terminated on request.
o midcomTotalTerminatedReserveRules This object indicates the total number of policy reserve rules that were terminated, but not on request.
o midcomTotalIncorrectEnableRules This object indicates the total number of policy enable rules that were rejected because the request was incorrect.
o midcomTotalRejectedEnableRules This object indicates the total number of policy enable rules that were failed while being processed.
o midcomCurrentActiveEnableRules This object indicates the number of currently active policy enable rules in the midcomRuleTable.
o midcomTotalExpiredEnableRules This object indicates the total number of expired policy enable rules.
o midcomTotalTerminatedOnRqEnableRules This object indicates the total number of policy enable rules that were terminated on request.
o midcomTotalTerminatedEnableRules This object indicates the total number of policy enable rules that were terminated, but not on request.
5.4. Notifications

For informing MIDCOM clients about state changes of MIDCOM-MIB implementations, three notifications can be used. They notify the MIDCOM client about state changes of individual policy rules or of groups of policy rules. Different notifications are used for different kinds of transactions.

For asynchronous transactions, unsolicited notifications are used. The only asynchronous transaction that needs to be modeled by the MIDCOM-MIB is the Asynchronous Policy Rule Event (ARE). The ARE may be caused by the expiration of a policy rule lifetime, the expiration of the idle time, or an internal change in policy rule lifetime by the MIDCOM-MIB implementation for whatever reason. For configuration transactions, solicited notifications are used. This concerns the Policy Reserve Rule (PRR) transaction, the Policy Enable Rule (PER) transaction, the Policy Rule Lifetime Change (RLC) transaction, and the Group Lifetime Change (GLC) transaction.
The separation between unsolicited and solicited notifications gives the implementer of a MIDCOM client some freedom to make design decisions on how to model the MIDCOM reply message as described at the end of section 4.2.2. Depending on the choice, processing of solicited notifications may not be required. In such a case, delivery of solicited notification may be disabled, for example, by an appropriate configuration of the snmpNotifyFilterTable such that solicited notifications are filtered differently to unsolicited notifications.
o midcomUnsolicitedRuleEvent This notification can be generated for indicating the change of a policy rule's state or lifetime. It is used for performing the ARE transaction.
o midcomSolicitedRuleEvent This notification can be generated for indicating the requested change of a policy rule's state or lifetime. It is used for performing PRR, PER, and RLC transactions.
o midcomSolicitedGroupEvent This notification can be generated for indicating the requested change of a policy rule group's lifetime. It is used for performing the GLC transaction.
6. Recommendations for Configuration and Operation

Configuring MIDCOM-MIB security is highly sensitive for obvious reasons. This section gives recommendations for securely configuring the SNMP agent acting as MIDCOM server. In addition, recommendations for avoiding idempotency problems are given and restrictions of MIDCOM-MIB applicability to a special set of applications are discussed.

6.1. Security Model Configuration

Since controlling firewalls and NATs is highly sensitive, it is RECOMMENDED that SNMP Command Responders implementing the MIDCOM-MIB module use the authPriv security level for all users that may access managed objects of the MIDCOM-MIB module.

6.2. VACM Configuration

Entries in the midcomRuleTable and the midcomGroupTable provide information about existing firewall pinholes and/or NAT sessions. They also could be used for manipulating firewall pinholes and/or NAT sessions. Therefore, access control to these objects is essential and should be restrictive.

It is RECOMMENDED that SNMP Command Responders instantiating an implementation of the MIDCOM-MIB module use VACM for controlling access to managed objects in the midcomRuleTable and the midcomGroupTable.
It is further RECOMMENDED that individual MIDCOM clients, acting as SNMP Command Generators, only have access to an entry in the midcomRuleTable, the midcomResourceTable, or the midcomGroupTable, if they created the entry directly in the midcomRuleTable or indirectly in the midcomGroupTable and midcomResourceTable. Exceptions to this recommendation are situations where access by multiple MIDCOM clients to managed objects is explicitly required. One example is fail-over for MIDCOM agents where the stand-by MIDCOM agent needs the same access rights to managed objects as the currently active MIDCOM agent. Another example is a supervisor MIDCOM agent that monitors activities of other MIDCOM agents and/or may be used by network management systems to modify entries in tables of the MIDCOM-MIB.
For this reason, all three tables listed above have the midcomRuleOwner as initial index. It is RECOMMENDED that MIDCOM clients acting as SNMP Command Generator have access to the midcomRuleTable and the midcomGroupTable restricted to entries with the initial index matching either their SNMP securityName or their VACM groupName. It is RECOMMENDED that they do not have access to entries in these tables with initial indices other than their SNMP securityName or their VACM groupName. It is RECOMMENDED that this VACM configuration is applied to read access, write access, and notify access for all objects in the midcomRuleTable and the midcomGroupTable.
Note that less restrictive access rights MAY be granted to other users, for example, to a network management application, that monitors MIDCOM policy rules.

6.3. Notification Configuration

For each MIDCOM client that has access to the midcomRuleTable, a notification target SHOULD be configured at a Command Responder instantiating an implementation of the MIDCOM-MIB. It is RECOMMENDED that such a configuration be retrievable from the Command Responder via the SNMP-TARGET-MIB [RFC3413].

For each entry of the snmpTargetAddrTable that is related to a MIDCOM client, there SHOULD be an individual corresponding entry in the snmpTargetParamsTable.
An implementation of the MIDCOM-MIB SHOULD also implement the SNMP- NOTIFICATION-MIB [RFC3413]. An instance of an implementation of the MIDCOM-MIB SHOULD have an individual entry in the snmpNotifyFilterProfileTable for each MIDCOM client that has access to the midcomRuleTable.
An instance of an implementation of the MIDCOM-MIB SHOULD allow MIDCOM clients to start and stop the generation of notifications targeted at themselves. This SHOULD be realized by giving the MIDCOM clients write access to the snmpNotifyFilterTable. If appropriate entries of the snmpNotifyFilterTable are established in advance, then this can be achieved by granting MIDCOM clients write access only to the columnar object snmpNotifyFilterType.
It is RECOMMENDED that VACM be configured such that each MIDCOM agent can only access entries in the snmpTargetAddrTable, the snmpTargetParamsTable, the snmpNotifyFilterProfileTable, and the snmpFilterTable that concern that particular MIDCOM agent. Typically, read access to the snmpTargetAddrTable, the snmpTargetParamsTable, and the snmpNotifyFilterProfileTable is sufficient. Write access may be required for objects of the snmpFilterTable.

6.4. Simultaneous Access

Situations with two MIDCOM clients simultaneously modifying the same policy rule should be avoided. For each entry in the midcomRuleTable, there should be only one client at a time that modifies it. If two MIDCOM clients share the same midcomRuleOwner index of the midcomRuleTable, then conflicts can be avoided, for example, by
- scheduling access times, as, for example, in the fail-over case; - using different midcomGroupIndex values per client; or - using non-overlapping intervals for values of the midcomRuleIndex per client.
6.5. Avoiding Idempotency Problems

As already discussed in section 4.2.4.4, the following recommendation is given for avoiding idempotency problems.

In general, idempotency problems can be solved by including snmpSetSerialNo (see [RFC3418]) in SNMP SET requests.
In case this feature is not used, it is RECOMMENDED that the value of the SNMP retransmission timer of a MIDCOM client (acting as SNMP Command Generator) is lower than the smallest requested value for any rule lifetime or rule idle time in order to prevent idempotency problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime when retransmitting an SNMP SET request after a lost SNMP reply.
MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack such that no retransmissions are sent.
Similar considerations apply to MIDCOM-MIB implementations acting as Notification Originator when sending a notification (midcomUnsolicitedRuleEvent, midcomSolicitedRuleEvent or midcomSolicitedGroupEvent) containing the remaining lifetime of a policy rule or a policy rule group, respectively.

6.6. Interface Indexing Problems

A well-known problem of MIB modules is indexing IP interfaces after a re-initialization of the managed device. The index for interfaces provided by the ifTable (see IF-MIB in [RFC2863]) may change during re-initialization, for example, when physical interfaces are added or removed.

The MIDCOM-MIB module uses the interface index for indicating at which interface which policy rule is (or is to be) applied. Also, this index is used for indicating how policy rules are prioritized at certain interfaces. The MIDCOM-MIB module specification requires that information provided is always correct. This implies that after re-initialization, interface index values of policy rules or firewall configurations may have changed even though they still refer to the same interface as before the re-initialization.
MIDCOM client implementations need to be aware of this potential behavior. It is RECOMMENDED that before writing the value or using the value of indices that depend on the ifTable the MIDCOM client checks if the middlebox has been re-initialized recently. MIDCOM-MIB module implementations MUST track interface changes of IP interface indices in the ifTable. This implies that after a re- initialization of a middlebox, a MIDCOM-MIB implementation MUST make sure that each instance of an interface index in the MIDCOM-MIB tables still points to the same interface as before the re- initialization. For any instance for which this is not possible, all affected entries in tables of the MIDCOM-MIB module MUST be either terminated, disabled, or deleted, as specified in the DESCRIPTION clause of the respective object. This concerns all objects in the MIDCOM-MIB module that are of type InterfaceIndexOrZero.

6.7. Applicability Restrictions

As already discussed in section 5.1.1, the MIDCOM-MIB requires the MIDCOM client to specify address tuples A0 and A3. This can be a problem for applications that do not have this information available when they need to configure the middlebox. For some applications, there are usage scenarios where address information is only available for a single address realm, A0 and A1 in the private realm or A2 and A3 in the public realm. An example is an FTP application using the PORT command (instead of the PASV command). The problem occurs when the middlebox offers twice-NAT functionality.

7. Usage Examples for MIDCOM Transactions

This section presents some examples that explain how a MIDCOM client acting as SNMP manager can use the MIDCOM-MIB module defined in this memo. The purpose of these examples is to explain the steps that are required to perform MIDCOM transactions. For each MIDCOM transaction defined in the MIDCOM semantics [RFC5189], a sequence of SNMP operations that realizes the transaction is described.

The examples described below are recommended procedures for MIDCOM clients. Clients may choose to operate differently.
For example, they may choose not to receive solicited notifications on completion of a transaction, but to poll the MIDCOM-MIB instead until the transaction is completed. This can be achieved by performing step 2 of the SE transaction (see below) differently. The MIDCOM agent then creates an entry in the snmpNotifyFilterTable such that only the midcomUnsolicitedRuleEvent may pass the filter and is sent to the MIDCOM client. In this case, the PER, PRR, and RLC transactions require a polling loop wherever in the example below the MIDCOM client waits for a notification.

7.1. Session Establishment (SE)

The MIDCOM-MIB realizes most properties of MIDCOM sessions in a very static way. Only the generation of notifications targeted at the MIDCOM client is enabled by the client for session establishment.
1. The MIDCOM client checks the middlebox capabilities by reading objects in the midcomCapabilitiesGroup.
2. The MIDCOM client enables generation of notifications on events concerning the policy rules controlled by the client. If the SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3 of this document, then the agent just has to change the value of a object snmpNotifyFilterType in the corresponding entry of the snmpNotifyFilterTable from included(1) to excluded(2).
7.2. Session Termination (ST)

For terminating a session, the MIDCOM client just disables the generation of notifications for this client.
1. The MIDCOM client disables generation of notifications on events concerning the policy rules controlled by the client. If the SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3 of this document, then the agent just has to change the value of a object snmpNotifyFilterType in the corresponding entry of the snmpNotifyFilterTable from included(1) to excluded(2).
7.3. Policy Reserve Rule (PRR)

This example explains steps that may be performed by a MIDCOM client to establish a policy reserve rule.
1. The MIDCOM client creates a new entry in the midcomRuleTable by writing to midcomRuleRowStatus. The chosen value for index object midcomGroupIndex determines the group membership of the created rule. Note that choosing an unused value for midcomGroupIndex creates a new entry in the midcomGroupTable.
2. The MIDCOM client sets the following objects in the new entry of the midcomRuleTable to specify all request parameters of the PRR transaction:
- midcomRuleMaxIdleTime - midcomRuleInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleLifetime
Note that several of these parameters have default values that can be used.
3. The MIDCOM client sets the midcomRuleAdminStatus objects in the new row of the midcomRuleTable to reserve(1).
4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification concerning the new policy rule in the midcomRuleTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry by one or more SNMP GET operations.
5. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification. If it is greater than 0, the MIDCOM client reads all positive reply parameters of the PRR transaction:
- midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleMaxIdleTime - midcomRuleLifetime
If the lifetime equals 0, then the MIDCOM client reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason.
6. Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the middlebox resources allocated for this policy reserve rule. Note that PRR does not necessarily allocate any middlebox resource visible in the NAT-MIB module or in a firewall MIB module, since it does a reservation only. If, however, the PRR overlaps with already existing PERs, then the PRR may be related to middlebox resources visible in other MIB modules.
7.4. Policy Enable Rule (PER) after PRR

This example explains steps that may be performed by a MIDCOM client to establish a policy enable rule after a corresponding policy reserve rule was already established.
1. The MIDCOM client sets the following objects in the row of the established PRR in the midcomRuleTable to specify all request parameters of the PER transaction:
- midcomRuleMaxIdleTime - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleFlowDirection
Note that several of these parameters have default values that can be used.
2. The MIDCOM client sets the midcomRuleAdminStatus objects in the row of the established PRR in the midcomRuleTable to enable(1).
3. The MIDCOM client awaits a midcomSolicitedRuleEvent notification concerning the new row in the midcomRuleTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry by one or more SNMP GET operations.
4. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification. If it is greater than 0, the MIDCOM client reads all positive reply parameters of the PER transaction:
- midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleMaxIdleTime
If the lifetime equals 0, then the MIDCOM client reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason.
5. Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the allocated middlebox resources for this policy enable rule.
7.5. Policy Enable Rule (PER) without Previous PRR

This example explains steps that may be performed by a MIDCOM client to establish a policy enable rule for which no PRR transaction has been performed before.

1. Identical to step 1 for PRR (section 7.3).

2. Identical to step 2 for PRR (section 7.3).
3. The MIDCOM client sets the following objects in the new row of the midcomRuleTable to specify all request parameters of the PER transaction:
- midcomRuleInterface - midcomRuleFlowDirection - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleLifetime
Note that several of these parameters have default values that can be used.
4. The MIDCOM client sets the midcomRuleAdminStatus objects in the new row of the midcomRuleTable to enable(1).
5. Identical to step 4 for PRR (section 7.3).
6. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification. If it is greater than 0, the MIDCOM client reads all positive reply parameters of the PRR transaction:
- midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleMaxIdleTime
If the lifetime equals 0, then the MIDCOM client reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason.
7. Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the allocated middlebox resources for this policy enable rule.
7.6. Policy Rule Lifetime Change (RLC)

This example explains steps that may be performed by a MIDCOM client to change the lifetime of a policy rule. Changing the lifetime to 0 implies terminating the policy rule.

1. The MIDCOM client issues a SET request for writing the desired lifetime to the midcomRuleLifetime object in the corresponding row of the midcomRuleTable. This does not have any effect if the lifetime is already expired.

2. The MIDCOM client awaits a midcomSolicitedRuleEvent notification concerning the corresponding row in the midcomRuleTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry by one or more SNMP GET operations.

3. After receiving the midcomSolicitedRuleEvent notification MIDCOM client checks the lifetime value carried by the notification.

7.7. Policy Rule List (PRL)

The SNMP agent can browse the list of policy rules by browsing the midcomRuleTable. For each observed row in this table, the SNMP agent should check the midcomRuleOperStatus in order to find out if the row contains information about an established policy rule or of a rule that is under construction or already terminated.

7.8. Policy Rule Status (PRS)

The SNMP agent can retrieve all status information and properties of a policy rule by reading the managed objects in the corresponding row of the midcomRuleTable.

7.9. Asynchronous Policy Rule Event (ARE)

There are two different triggers for the ARE. It may be triggered by the expiration of a policy rule's lifetime or the expiration of the idle time. But beyond this, the MIDCOM-MIB implementation may terminate a policy rule at any time. In all cases, two steps are required for performing this transaction:
1. The MIDCOM-MIB implementation sends a midcomUnsolicitedRuleEvent notification containing a lifetime value of 0 to the MIDCOM client owning the rule.
2. If the midcomRuleStorageTime object in the corresponding row of the midcomRuleTable has a value of 0, then the MIDCOM-MIB implementation removes the row from the table. Otherwise, it sets in this row the midcomRuleLifetime object to 0 and changes the midcomRuleOperStatus object. If the event was triggered by policy lifetime expiration, then the midcomRuleOperStatus is set to timedOut(9); otherwise, it is set to terminated(11).
7.10. Group Lifetime Change (GLC)

This example explains steps that may be performed by a MIDCOM client to change the lifetime of a policy rule group. Changing the lifetime to 0 implies terminating all member policies of the group.
1. The MIDCOM client issues a SET request for writing the desired lifetime to the midcomGroupLifetime object in the corresponding row of the midcomGroupTable.
2. The MIDCOM client waits for a midcomSolicitedGroupEvent notification concerning the corresponding row in the midcomGroupTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomGroupEntry by one or more SNMP GET operations.
3. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification.
7.11. Group List (GL)

The SNMP agent can browse the list of policy rule groups by browsing the midcomGroupTable. For each observed row in this table, the SNMP agent should check the midcomGroupLifetime in order to find out if the group does contain established policies.

7.12. Group Status (GS)

The SNMP agent can retrieve all member policies of a group by browsing the midcomRuleTable using the midcomGroupIndex of the particular group. For retrieving the remaining lifetime of the group, the SNMP agent reads the midcomGroupLifetime object in the corresponding row of the midcomGroupTable.

8. Usage Examples for Monitoring Objects

This section presents some examples that explain how a MIDCOM client can use the midcomResourceTable to correlate policy rules with the used middlebox resources. One example is given for middleboxes implementing the NAT-MIB and another one is given for firewalls.

8.1. Monitoring NAT Resources

When a rule in the midcomRuleTable is executed, it directly impacts the middlebox resources. The midcomResourceTable provides the information on the relationships between the MIDCOM-MIB policy rules and the middlebox resources used for enforcing these rules.

A MIDCOM-MIB policy rule will cause the creation or modification of up to two NAT bindings and up to two NAT sessions. Two NAT bindings are impacted in the case of a session being subject to twice-NAT. Two NAT bindings may also be impacted when midcomRulePortRange is set to pair(2) in the policy rule. In the majority of cases, where traditional NAT is implemented, only a single NAT binding may be adequate. Note, however, that this BindId is set to 0 if the middlebox is implementing symmetric NAT function. Two NAT sessions are created or modified only when the midcomRulePortRange is set to pair(2) in the policy rule.
When support for the NAT-MIB module is also available at the middlebox, the parameters in the combination of the midcomRuleTable and the midcomResourceTable for a given rule can be used to index the corresponding BIND and NAT session resources effected in the NAT-MIB. These parameters are valuable to monitor the impact on the NAT module, even when the NAT-MIB module is not implemented at the middlebox.
The impact of MIDCOM rules on the NAT resources is important because a MIDCOM rule not only can create BINDs and NAT sessions, but also is capable of modifying the NAT objects that already exist. For example, FlowDirection and MaxIdleTime parameters in a MIDCOM rule directly affect the TranslationEntity and MaxIdleTime of the associated NAT bind object. Likewise, MaxIdleTime in a MIDCOM rule has a direct impact on the MaxIdleTime of the associated NAT session object. The lifetime parameter in the MIDCOM rule directly impacts the lifetime of all the impacted NAT BIND and NAT session objects.

8.2. Monitoring Firewall Resources

When a MIDCOM-MIB policy rule is established at a middlebox with firewall capabilities, this may lead to the creation of one or more new firewall rules. Note that in general a single firewall rule per MIDCOM-MIB policy rule will be sufficient. For each policy rule, a MIDCOM client can explore the corresponding firewall filter rule by reading the midcomResourceEntry in the midcomResourceTable that corresponds to the midcomRuleEntry describing the rule. The identification of the firewall filter rule is stored in object midcomRscFirewallRuleId. The value of midcomRscFirewallRuleId may correspond directly to any firewall filter rule number or to an entry in a locally available firewall MIB module.

9. Definitions

The following MIB module imports from [RFC2578], [RFC2579], [RFC2580], [RFC2863], [RFC3411], [RFC4001], and [RFC4008].
MIDCOM-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, Counter32, Gauge32, mib-2 FROM SNMPv2-SMI -- RFC 2578
TEXTUAL-CONVENTION, TruthValue, StorageType, RowStatus FROM SNMPv2-TC -- RFC 2579
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF -- RFC 2580
SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411
InetAddressType, InetAddress, InetPortNumber, InetAddressPrefixLength FROM INET-ADDRESS-MIB -- RFC 4001
InterfaceIndexOrZero FROM IF-MIB -- RFC 2863
NatBindIdOrZero FROM NAT-MIB; -- RFC 4008
midcomMIB MODULE-IDENTITY LAST-UPDATED "200708091011Z" -- August 09, 2007 ORGANIZATION "IETF Middlebox Communication Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/midcom-charter.html
Mailing Lists: General Discussion: midcom@ietf.org To Subscribe: midcom-request@ietf.org In Body: subscribe your_email_address
Co-editor: Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany Tel: +49 6221 4342-115 Email: quittek@nw.neclab.eu
Co-editor: Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany Tel: +49 6221 4342-113 Email: stiemerling@nw.neclab.eu
Co-editor: Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 U.S.A. Tel: +1 408 836-4773 Email: srisuresh@yahoo.com"
DESCRIPTION "This MIB module defines a set of basic objects for configuring middleboxes, such as firewalls and network
address translators, in order to enable communication across these devices.
Managed objects defined in this MIB module are structured in three kinds of objects: - transaction objects required according to the MIDCOM protocol requirements defined in RFC 3304 and according to the MIDCOM protocol semantics defined in RFC 3989, - configuration objects that can be used for retrieving or setting parameters of the implementation of transaction objects, - optional monitoring objects that provide information about used resource and statistics
The transaction objects are organized in two subtrees: - objects modeling MIDCOM policy rules in the midcomRuleTable - objects modeling MIDCOM policy rule groups in the midcomGroupTable
Note that typically, configuration objects are not intended to be written by MIDCOM clients. In general, write access to these objects needs to be restricted more strictly than write access to objects in the transaction subtrees.
Copyright © The Internet Society (2008). This version of this MIB module is part of RFC 5190; see the RFC itself for full legal notices."
REVISION "200708091011Z" -- August 09, 2007 DESCRIPTION "Initial version, published as RFC 5190." ::= { mib-2 171 }
-- -- main components of this MIB module --
midcomNotifications OBJECT IDENTIFIER ::= { midcomMIB 0 } midcomObjects OBJECT IDENTIFIER ::= { midcomMIB 1 } midcomConformance OBJECT IDENTIFIER ::= { midcomMIB 2 }
-- Transaction objects required according to the MIDCOM -- protocol requirements defined in RFC 3304 and according to -- the MIDCOM protocol semantics defined in RFC 3989 midcomTransaction OBJECT IDENTIFIER ::= { midcomObjects 1 }
-- Configuration objects that can be used for retrieving -- middlebox capability information (mandatory) and for -- setting parameters of the implementation of transaction -- objects (optional) midcomConfig OBJECT IDENTIFIER ::= { midcomObjects 2 }
-- Optional monitoring objects that provide information about -- used resource and statistics midcomMonitoring OBJECT IDENTIFIER ::= { midcomObjects 3 }
-- -- Transaction Objects -- -- Transaction objects are structured according to the MIDCOM -- protocol semantics into two groups: -- - objects modeling MIDCOM policy rules in the midcomRuleTable -- - objects modeling MIDCOM policy rule groups in the -- midcomGroupTable
-- -- Policy rule subtree -- -- The midcomRuleTable lists policy rules -- including policy reserve rules and policy enable rules. --
midcomRuleTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists policy rules.
It is indexed by the midcomRuleOwner, the midcomGroupIndex, and the midcomRuleIndex. This implies that a rule is a member of exactly one group and that group membership cannot be changed.
Entries can be deleted by writing to midcomGroupLifetime or midcomRuleLifetime and potentially also to midcomRuleStorageTime." ::= { midcomTransaction 3 }
midcomRuleEntry OBJECT-TYPE SYNTAX MidcomRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular MIDCOM policy rule."
INDEX { midcomRuleOwner, midcomGroupIndex, midcomRuleIndex } ::= { midcomRuleTable 1 }
MidcomRuleEntry ::= SEQUENCE { midcomRuleOwner SnmpAdminString, midcomRuleIndex Unsigned32, midcomRuleAdminStatus INTEGER, midcomRuleOperStatus INTEGER, midcomRuleStorageType StorageType, midcomRuleStorageTime Unsigned32, midcomRuleError SnmpAdminString, midcomRuleInterface InterfaceIndexOrZero, midcomRuleFlowDirection INTEGER, midcomRuleMaxIdleTime Unsigned32, midcomRuleTransportProtocol Unsigned32, midcomRulePortRange INTEGER, midcomRuleInternalIpVersion InetAddressType, midcomRuleExternalIpVersion InetAddressType, midcomRuleInternalIpAddr InetAddress, midcomRuleInternalIpPrefixLength InetAddressPrefixLength, midcomRuleInternalPort InetPortNumber, midcomRuleExternalIpAddr InetAddress, midcomRuleExternalIpPrefixLength InetAddressPrefixLength, midcomRuleExternalPort InetPortNumber, midcomRuleInsideIpAddr InetAddress, midcomRuleInsidePort InetPortNumber, midcomRuleOutsideIpAddr InetAddress, midcomRuleOutsidePort InetPortNumber, midcomRuleLifetime Unsigned32, midcomRuleRowStatus RowStatus }
midcomRuleOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The manager who owns this row in the midcomRuleTable.
This object SHOULD uniquely identify an authenticated MIDCOM client. This object is part of the table index to allow for the use of the SNMPv3 View-based Access Control Model (VACM, RFC 3415)." ::= { midcomRuleEntry 1 }
midcomRuleIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible
STATUS current DESCRIPTION "The value of this object must be unique in combination with the values of the objects midcomRuleOwner and midcomGroupIndex in this row." ::= { midcomRuleEntry 3 }
midcomRuleAdminStatus OBJECT-TYPE SYNTAX INTEGER { reserve(1), enable(2), notSet(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object indicates the desired status of the policy rule. See the definition of midcomRuleOperStatus for a description of the values.
When a midcomRuleEntry is created without explicitly setting this object, its value will be notSet(3).
However, a SET request can only set this object to either reserve(1) or enable(2). Attempts to set this object to notSet(3) will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned.
When the midcomRuleAdminStatus object is set, then the MIDCOM-MIB implementation will try to read the respective relevant objects of the entry and try to achieve the corresponding midcomRuleOperStatus.
Setting midcomRuleAdminStatus to value reserve(1) when object midcomRuleOperStatus has a value of reserved(7) does not have any effect on the policy rule. Setting midcomRuleAdminStatus to value enable(2) when object midcomRuleOperStatus has a value of enabled(8) does not have any effect on the policy rule.
Depending on whether the midcomRuleAdminStatus is set to reserve(1) or enable(2), several objects must be set in advance. They serve as parameters of the policy rule to be established.
When object midcomRuleAdminStatus is set to reserve(1), then the following objects in the same entry are of relevance: - midcomRuleInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleLifetime
MIDCOM-MIB implementation may also consider the value of object midcomRuleMaxIdleTime when establishing a reserve rule.
When object midcomRuleAdminStatus is set to enable(2), then the following objects in the same entry are of relevance: - midcomRuleInterface - midcomRuleFlowDirection - midcomRuleMaxIdleTime - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleLifetime
When retrieved, the object returns the last set value. If no value has been set, it returns the default value notSet(3)." DEFVAL { notSet } ::= { midcomRuleEntry 4 }
midcomRuleOperStatus OBJECT-TYPE SYNTAX INTEGER { newEntry(1), setting(2), checkingRequest(3), incorrectRequest(4), processingRequest(5),
requestRejected(6), reserved(7), enabled(8), timedOut(9), terminatedOnRequest(10), terminated(11), genericError(12) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual status of the policy rule. The midcomRuleOperStatus object may have the following values:
- newEntry(1) indicates that the entry in the midcomRuleTable was created, but not modified yet. Such an entry needs to be filled with values specifying a request first.
- setting(2) indicates that the entry has been already modified after generating it, but no request was made yet.
- checkingRequest(3) indicates that midcomRuleAdminStatus has recently been set and that the MIDCOM-MIB implementation is currently checking the parameters of the request. This is a transient state. The value of this object will change to either incorrectRequest(4) or processingRequest(5) without any external interaction. A MIDCOM-MIB implementation MAY return this value while checking request parameters.
- incorrectRequest(4) indicates that checking a request resulted in detecting an incorrect value in one of the objects containing request parameters. The failure reason is indicated by the value of midcomRuleError.
- processingRequest(5) indicates that midcomRuleAdminStatus has recently been set and that the MIDCOM-MIB implementation is currently processing the request and trying to configure the middlebox accordingly. This is a transient state. The value of this object will change to either requestRejected(6), reserved(7), or enabled(8) without any external interaction. A MIDCOM-MIB implementation MAY return this value while processing a request.
- requestRejected(6) indicates that a request to establish
a policy rule specified by the entry was rejected. The reason for rejection is indicated by the value of midcomRuleError.
- reserved(7) indicates that the entry describes an established policy reserve rule. These values of MidcomRuleEntry are meaningful for a reserved policy rule: - midcomRuleMaxIdleTime - midcomRuleInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleLifetime
- enabled(8) indicates that the entry describes an established policy enable rule. These values of MidcomRuleEntry are meaningful for an enabled policy rule:
- midcomRuleFlowDirection - midcomRuleInterface - midcomRuleMaxIdleTime - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleLifetime
- timedOut(9) indicates that the lifetime of a previously established policy rule has expired and that the policy rule is terminated for this reason.
- terminatedOnRequest(10) indicates that a previously established policy rule was terminated by an SNMP manager setting the midcomRuleLifetime to 0 or setting midcomGroupLifetime to 0.
- terminated(11) indicates that a previously established policy rule was terminated by the MIDCOM-MIB implementation for a reason other than lifetime expiration or an explicit request from a MIDCOM client.
- genericError(12) indicates that the policy rule specified by the entry is not established due to an error condition not listed above.
The states timedOut(9), terminatedOnRequest(10), and terminated(11) are referred to as termination states.
The states incorrectRequest(4), requestRejected(6), and genericError(12) are referred to as error states.
The checkingRequest(3) and processingRequest(5) states are transient states, which will lead to either one of the error states or the reserved(7) state or the enabled(8) state. MIDCOM-MIB implementations MAY return these values when checking or processing requests." DEFVAL { newEntry } ::= { midcomRuleEntry 5 }
midcomRuleStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "When retrieved, this object returns the storage type of the policy rule. Writing to this object can change the storage type of the particular row from volatile(2) to nonVolatile(3) or vice versa.
Attempts to set this object to permanent will always fail with an 'inconsistentValue' error. Note that this error code is SNMP specific. If the MIB module is used with other protocols than SNMP, errors with similar semantics specific to those protocols should be returned.
If midcomRuleStorageType has the value permanent(4), then all objects in this row whose MAX-ACCESS value is read-create must be read-only."
DEFVAL { volatile } ::= { midcomRuleEntry 6 }
midcomRuleStorageTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The value of this object specifies how long this row can exist in the midcomRuleTable after the midcomRuleOperStatus switched to a termination state or to an error state. This object returns the remaining time that the row may exist before it is aged out.
After expiration or termination of the