Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5190

Definitions of Managed Objects for Middlebox Communication

Pages: 92
Proposed Standard
Part 2 of 4 – Pages 15 to 38
First   Prev   Next

Top   ToC   RFC5190 - Page 15   prevText

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
Top   ToC   RFC5190 - Page 16
   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.
Top   ToC   RFC5190 - Page 17

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.
Top   ToC   RFC5190 - Page 18
   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.
Top   ToC   RFC5190 - Page 19
         +----------+                                 +----------+
         | 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.
Top   ToC   RFC5190 - Page 20
   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.
Top   ToC   RFC5190 - Page 21
       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.
Top   ToC   RFC5190 - Page 22
   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.
Top   ToC   RFC5190 - Page 23
   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
Top   ToC   RFC5190 - Page 24
   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.
Top   ToC   RFC5190 - Page 25
   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.
Top   ToC   RFC5190 - Page 26
   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.
Top   ToC   RFC5190 - Page 27

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.
Top   ToC   RFC5190 - Page 28

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.
Top   ToC   RFC5190 - Page 29

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.
Top   ToC   RFC5190 - Page 30
   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.
Top   ToC   RFC5190 - Page 31

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
Top   ToC   RFC5190 - Page 32
         - 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.
Top   ToC   RFC5190 - Page 33

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.
Top   ToC   RFC5190 - Page 34

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
Top   ToC   RFC5190 - Page 35
      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.
Top   ToC   RFC5190 - Page 36

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.
Top   ToC   RFC5190 - Page 37

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
Top   ToC   RFC5190 - Page 38
   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.


(page 38 continued on part 3)

Next Section