tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5190

 
 
 

Definitions of Managed Objects for Middlebox Communication

Part 2 of 4, p. 15 to 38
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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 RFC Part