RFC 5190
Definitions of Managed Objects for Middlebox Communication
Pages: 92
Proposed Standard
Proposed Standard
Part 2 of 4 – Pages 15 to 38
5. Structure of the MIB Module
The MIB module defined in section 9 contains three kinds of managed objects: - Transaction objects Transaction objects are required for implementing the MIDCOM protocol requirements defined in [RFC3304] and the MIDCOM protocol semantics defined in [RFC5189]. - Configuration objects Configuration objects can be used for retrieving middlebox capability information (mandatory) and for setting parameters of the implementation of transaction objects (optional). - Monitoring objects The optional monitoring objects provide information about used resources and about MIDCOM transaction statistics. The transaction objects are organized in two tables: the midcomRuleTable and the midcomGroupTable. Entity relationships of
entries of these tables and the midcomResourceTable from the monitoring objects are illustrated by Figure 6. +--------------------+ | midcomRuleEntry | | indexed by | | midcomRuleOwner | | midcomGroupIndex | | midcomRuleIndex | +--------------------+ 1...n | | 1 | | 1 | | 1 +--------------------+ +---------------------+ | midcomGroupEntry | | midcomResourceEntry | | indexed by | | indexed by | | midcomRuleOwner | | midcomRuleOwner | | midcomGroupIndex | | midcomGroupIndex | +--------------------+ | midcomRuleIndex | +---------------------+ | | | | | | v v v NAT Firewall other MIB MIB MIB Figure 6: Entity relationships of table entries A MIDCOM client can create and delete entries in the midcomRuleTable. Entries in the midcomGroupTable are generated automatically as soon as there is an entry in the midcomRuleTable using the midcomGroupIndex. The midcomGroupTable can be used as shortcut for accessing all member rules with a single transaction. MIDCOM clients can group policy rules for various purposes. For example, they can assign a unique value for the midcomGroupIndex to all rules belonging to a single application or an application session served by the MIDCOM agent. The midcomResourceTable augments the midcomRuleTable by information on the relationship of entries of the midcomRuleTable to resources listed in other MIB modules, such as the NAT-MIB [RFC4008].5.1. Transaction Objects
The transaction objects are structured according to the MIDCOM semantics described in [RFC5189] into two subtrees, one for policy rule control and one for policy rule group control.
5.1.1. midcomRuleTable
The midcomRuleTable contains information about policy rules including policy rules to be established, policy rules for which establishing failed, established policy rules, and terminated policy rules. Entries in this table are indexed by the combination of midcomRuleOwner, midcomGroupIndex, and midcomRuleIndex. The midcomRuleOwner is the owner of the rule; the midcomGroupIndex is the index of the group of which the policy rule is a member. midcomRuleOwner is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-based Access Control Model (VACM [RFC3415]) and allows a management application to identify its entries. Entries in this table are created by writing to midcomRuleRowStatus. Entries are removed when both their midcomRuleLifetime and midcomRuleStorageTime are timed out by counting down to 0. A MIDCOM client can explicitly remove an entry by setting midcomRuleLifetime and midcomRuleStorageTime to 0. The table contains the following columnar objects: o midcomRuleIndex The index of this entry must be unique in combination with the midcomRuleOwner and the midcomGroupIndex of the entry. o midcomRuleAdminStatus For establishing a new policy rule, a set of objects in this entry needs to be written first. These objects are the request parameters. Then, by writing either reserve(1) or enable(2) to this object, the MIDCOM-MIB implementation is triggered to start processing the parameters and tries to establish the specified policy rule. o midcomRuleOperStatus This read-only object indicates the current status of the entry. The entry may have an initializing state, it may have a transient state while processing requests, it may have an error state after a request was rejected, it may have a state where a policy rule is established, or it may have a terminated state. o midcomRuleStorageType This object indicates whether or not the policy rule is stored as volatile, non-volatile, or permanent. Depending on the MIDCOM- MIB implementation, this object may be writable.
o midcomRuleStorageTime
This object indicates how long the entry will still exist after
entering an error state or a termination state.
o midcomRuleError
This object is a string indicating the reason for entering an
error state.
o midcomRuleInterface
This object indicates the IP interface for which enforcement of a
policy rule is requested or performed, respectively.
o midcomRuleFlowDirection
This object indicates a flow direction for which a policy enable
rule was requested or established, respectively.
o midcomRuleMaxIdleTime
This object indicates the maximum idle time of the policy rule in
seconds. If no packet to which the policy rule applies passes
the middlebox for the time specified by midcomRuleMaxIdleTime,
then the policy rule enters a termination state.
o midcomRuleTransportProtocol
This object indicates a transport protocol for which a policy
reserve rule or policy enable rule was requested or established,
respectively.
o midcomRulePortRange
This object indicates a port range for which a policy reserve
rule or policy enable rule was requested or established,
respectively.
o midcomRuleLifetime
This object indicates the remaining lifetime of an established
policy rule. The MIDCOM client can change the remaining lifetime
by writing to it.
Beyond the listed objects, the table contains 10 further objects
describing address parameters. They include the IP version, IP
address, prefix length and port number for the internal address (A0),
inside address (A1), outside address (A2), and external address (A3).
These objects serve as parameters specifying a request or an
established policy, respectively.
A0, A1, A2, and A3 are address tuples defined according to the MIDCOM
semantics [RFC5189]. Each of them identifies either a communication
endpoint at an internal or external device or an allocated address at
the middlebox.
+----------+ +----------+ | internal | A0 A1 +-----------+ A2 A3 | external | | endpoint +----------+ middlebox +----------+ endpoint | +----------+ +-----------+ +----------+ Figure 7: Address tuples A0 - A3 - A0 - internal endpoint: Address tuple A0 specifies a communication endpoint of a device within the internal network, with respect to the middlebox. - A1 - middlebox inside address: Address tuple A1 specifies a virtual communication endpoint at the middlebox within the internal network. A1 is the destination address for packets passing from the internal endpoint to the middlebox and is the source for packets passing from the middlebox to the internal endpoint. - A2 - middlebox outside address: Address tuple A2 specifies a virtual communication endpoint at the middlebox within the external network. A2 is the destination address for packets passing from the external endpoint to the middlebox and is the source for packets passing from the middlebox to the external endpoint. - A3 - external endpoint: Address tuple A3 specifies a communication endpoint of a device within the external network, with respect to the middlebox. The MIDCOM-MIB requires the MIDCOM client to specify address tuples A0 and A3. This might be a problem for applications that are not designed in a firewall-friendly way. An example is an FTP application that uses the PORT command (instead of the recommended PASV command). The problem only occurs when the middlebox offers twice-NAT functionality, and it can be fixed following recommendations for firewall-friendly communication.5.1.2. midcomGroupTable
The midcomGroupTable has an entry per existing policy rule group. Entries in this table are created automatically when creating member entries in the midcomRuleTable. Entries are automatically removed from this table when the last member entry is removed from the midcomRuleTable. Entries cannot be created or removed explicitly by the MIDCOM client.
Entries are indexed by the midcomRuleOwner of the rules that belong
to the group and by a specific midcomGroupIndex. This allows each
midcomRuleOwner to maintain its own independent group namespace.
An entry of the table contains the following objects:
o midcomGroupIndex
The index of this entry must be unique in combination with the
midcomRuleOwner of the entry.
o midcomGroupLifetime
This object indicates the maximum of the remaining lifetimes of
all established policy rules that are members of the group. The
MIDCOM client can change the remaining lifetime of all member
policies by writing to this object.
5.2. Configuration Objects
The configuration subtree contains middlebox capability and
configuration information. Some of the contained objects are
(optionally) writable and can also be used for configuring the
middlebox service.
The capabilities subtree contains some general capability information
and detailed information per supported IP interface. The
midcomConfigFirewallTable can be used to configure how the MIDCOM-MIB
implementation creates firewall rules in its firewall modules.
Note that typically, configuration objects are not intended to be
written by MIDCOM clients. In general, write access to these objects
needs to be restricted more strictly than write access to transaction
objects.
5.2.1. Capabilities
Information on middlebox capabilities, i.e., capabilities of the
MIDCOM-MIB implementation, is provided by the midcomCapabilities
subtree of managed objects. The following objects are defined:
o midcomConfigMaxLifetime
This object indicates the maximum lifetime that this middlebox
allows policy rules to have.
o midcomConfigPersistentRules
This is a boolean object indicating whether or not the middlebox
is capable of storing policy rules persistently.
Further capabilities are provided by the midcomConfigIfTable per
IP interface. This table contains just two objects. The first
one is a BITS object called midcomConfigIfBits containing the
following bit values:
o ipv4 and ipv6
These two bit values provide information on which IP versions are
supported by the middlebox at the indexed interface.
o addressWildcards and portWildcards
These two bit values provide information on wildcarding supported
by the middlebox at the indexed interface.
o firewall and nat
These two bit values provide information on availability of
firewall and NAT functionality at the indexed interface.
o portTranslation, protocolTranslation, and twiceNat
These three bit values provide information on the kind of NAT
functionality available at the indexed interface.
o inside
This bit indicates whether or not the indexed interface is an
inside interface with respect to NAT functionality.
The second object, called midcomConfigIfEnabled, indicates whether
the middlebox capabilities described by midcomConfigIfBits are
available or not available at the indexed IP interface.
The midcomConfigIfTable uses index 0 for indicating capabilities that
are available for all interfaces.
5.2.2. midcomConfigFirewallTable
The midcomConfigFirewallTable serves for configuring how policy rules
created by MIDCOM clients are realized as firewall rules of a
firewall implementation. Particularly, the priority used for
MIDCOM-MIB policy rules can be configured. For a single firewall
implementation at a particular IP interface, all MIDCOM-MIB policy
rules are realized as firewall rules with the same priority. Also, a
firewall rule group name can be configured. The table is indexed by
the IP interface index.
An entry of the table contains the following objects:
o midcomConfigFirewallGroupId
This object indicates the firewall rule group to which all
firewall rules of the MIDCOM server are assigned.
o midcomConfigFirewallPriority
This object indicates the priority assigned to all firewall rules
of the MIDCOM server.
5.3. Monitoring Objects
The monitoring objects are structured into two subtrees: the resource
subtree and the statistics subtree. The resource subtree provides
information about which resources are used by which policy rule. The
statistics subtree provides statistics about the usage of transaction
objects.
5.3.1. midcomResourceTable
Information about resource usage per policy rule is provided by the
midcomResourceTable. Each entry in the midcomResourceTable describes
resource usage of exactly one policy rule.
Resources are NAT resources and firewall resources, depending on the
type of middlebox. Used NAT resources include NAT bindings and NAT
sessions. NAT address mappings are not covered. For firewalls,
firewall filter rules are considered as resources.
The values provided by the following objects on NAT binds and NAT
sessions may refer to the detailed resource usage description in the
NAT-MIB module [RFC4008].
The values provided by the following objects on firewall rules may
refer to more detailed firewall resource usage descriptions in other
MIB modules.
Entries in the midcomResourceTable are only valid if the
midcomRuleOperStatus object of the corresponding entry in the
midcomRuleTable has a value of either reserved(7) or enabled(8).
An entry of the table contains the following objects:
o midcomRscNatInternalAddrBindMode
This object indicates whether the binding of the internal address
is an address NAT binding or an address-port NAT binding.
o midcomRscNatInternalAddrBindId
This object identifies the NAT binding for the internal address
in the NAT engine.
o midcomRscNatExternalAddrBindMode
This object indicates whether the binding of the external address
is an address NAT binding or an address-port NAT binding.
o midcomRscNatExternalAddrBindId
This object identifies the NAT binding for the external address
in the NAT engine.
o midcomRscNatSessionId1
This object links to the first NAT session associated with one of
the above NAT bindings.
o midcomRscNatSessionId2
This object links to the optional second NAT session associated
with one of the above NAT bindings.
o midcomRscFirewallRuleId
This object indicates the firewall rule for this policy rule.
The MIDCOM-MIB module does not require a middlebox to implement
further specific middlebox (NAT, firewall, etc.) MIB modules as, for
example, the NAT-MIB module [RFC4008].
The resource identifiers in the midcomResourceTable may be vendor
proprietary in the cases where the middlebox does not implement the
NAT-MIB [RFC4008] or a firewall MIB. The MIDCOM-MIB module affects
NAT binding and sessions, as well as firewall pinholes. It is
intentionally not specified in the MIDCOM-MIB module how these NAT
and firewall resources are allocated and managed, since this depends
on the MIDCOM-MIB implementation and middlebox's capabilities.
However, the midcomResourceTable is useful for understanding which
resources are affected by which MIDCOM-MIB transaction.
The midcomResourceTable is beneficial to the middlebox administrator
in that the table lists all MIDCOM transactions and the middlebox
specific resources to which these transactions refer. For instance,
multiple MIDCOM clients might end up using the same NAT bind, yet
each MIDCOM client might define a Lifetime parameter and
directionality for the bind that is specific to the transaction.
MIDCOM-MIB implementations are responsible for impacting underlying
middlebox resources so as to satisfy the sometimes overlapping
requirements on the same resource from multiple MIDCOM clients.
Managing these resources is not a trivial task for MIDCOM-MIB
implementers. It is possible that different MIDCOM-MIB policy rules
owned by different MIDCOM clients share a NAT binding or a firewall
rule. Then common properties, for example, the lifetime of the
resource, need to be managed such that all clients are served well
and changes to these resources need to be communicated to all
affected clients. Also, dependencies between resources, for example,
the precedence order of firewall rules, need to be considered
carefully in order to avoid that different policy rules -- potentially owned by different clients -- influence each other. MIDCOM clients may use the midcomResourceTable of the MIDCOM-MIB module in conjunction with the NAT-MIB module [RFC4008] to determine which resources of the NAT are used for MIDCOM. The NAT-MIB module stores the configured NAT bindings and sessions, and MIDCOM clients can use the information of the midcomResourceTable to sort out those NAT resources that are used by the MIDCOM-MIB module.5.3.2. midcomStatistics
The statistics subtree contains a set of non-columnar objects that provide 'MIDCOM protocol statistics', i.e., statistics about the usage of transaction objects. o midcomCurrentOwners This object indicates the number of different values for midcomRuleOwner for all current entries in the midcomRuleTable. o midcomOwnersTotal This object indicates the summarized number of all different values that occurred for midcomRuleOwner in the midcomRuleTable current and in the past. o midcomTotalRejectedRuleEntries This object indicates the total number of failed attempts to create an entry in the midcomRuleTable. o midcomCurrentRulesIncomplete This object indicates the total number of policy rules that have not been fully loaded into a table row of the midcomRuleTable. o midcomTotalIncorrectReserveRules This object indicates the total number of policy reserve rules that were rejected because the request was incorrect. o midcomTotalRejectedReserveRules This object indicates the total number of policy reserve rules that were failed while being processed. o midcomCurrentActiveReserveRules This object indicates the number of currently active policy reserve rules in the midcomRuleTable. o midcomTotalExpiredReserveRules This object indicates the total number of expired policy reserve rules.
o midcomTotalTerminatedOnRqReserveRules
This object indicates the total number of policy reserve rules
that were terminated on request.
o midcomTotalTerminatedReserveRules
This object indicates the total number of policy reserve rules
that were terminated, but not on request.
o midcomTotalIncorrectEnableRules
This object indicates the total number of policy enable rules
that were rejected because the request was incorrect.
o midcomTotalRejectedEnableRules
This object indicates the total number of policy enable rules
that were failed while being processed.
o midcomCurrentActiveEnableRules
This object indicates the number of currently active policy
enable rules in the midcomRuleTable.
o midcomTotalExpiredEnableRules
This object indicates the total number of expired policy enable
rules.
o midcomTotalTerminatedOnRqEnableRules
This object indicates the total number of policy enable rules
that were terminated on request.
o midcomTotalTerminatedEnableRules
This object indicates the total number of policy enable rules
that were terminated, but not on request.
5.4. Notifications
For informing MIDCOM clients about state changes of MIDCOM-MIB
implementations, three notifications can be used. They notify the
MIDCOM client about state changes of individual policy rules or of
groups of policy rules. Different notifications are used for
different kinds of transactions.
For asynchronous transactions, unsolicited notifications are used.
The only asynchronous transaction that needs to be modeled by the
MIDCOM-MIB is the Asynchronous Policy Rule Event (ARE). The ARE may
be caused by the expiration of a policy rule lifetime, the expiration
of the idle time, or an internal change in policy rule lifetime by
the MIDCOM-MIB implementation for whatever reason.
For configuration transactions, solicited notifications are used. This concerns the Policy Reserve Rule (PRR) transaction, the Policy Enable Rule (PER) transaction, the Policy Rule Lifetime Change (RLC) transaction, and the Group Lifetime Change (GLC) transaction. The separation between unsolicited and solicited notifications gives the implementer of a MIDCOM client some freedom to make design decisions on how to model the MIDCOM reply message as described at the end of section 4.2.2. Depending on the choice, processing of solicited notifications may not be required. In such a case, delivery of solicited notification may be disabled, for example, by an appropriate configuration of the snmpNotifyFilterTable such that solicited notifications are filtered differently to unsolicited notifications. o midcomUnsolicitedRuleEvent This notification can be generated for indicating the change of a policy rule's state or lifetime. It is used for performing the ARE transaction. o midcomSolicitedRuleEvent This notification can be generated for indicating the requested change of a policy rule's state or lifetime. It is used for performing PRR, PER, and RLC transactions. o midcomSolicitedGroupEvent This notification can be generated for indicating the requested change of a policy rule group's lifetime. It is used for performing the GLC transaction.6. Recommendations for Configuration and Operation
Configuring MIDCOM-MIB security is highly sensitive for obvious reasons. This section gives recommendations for securely configuring the SNMP agent acting as MIDCOM server. In addition, recommendations for avoiding idempotency problems are given and restrictions of MIDCOM-MIB applicability to a special set of applications are discussed.6.1. Security Model Configuration
Since controlling firewalls and NATs is highly sensitive, it is RECOMMENDED that SNMP Command Responders implementing the MIDCOM-MIB module use the authPriv security level for all users that may access managed objects of the MIDCOM-MIB module.
6.2. VACM Configuration
Entries in the midcomRuleTable and the midcomGroupTable provide information about existing firewall pinholes and/or NAT sessions. They also could be used for manipulating firewall pinholes and/or NAT sessions. Therefore, access control to these objects is essential and should be restrictive. It is RECOMMENDED that SNMP Command Responders instantiating an implementation of the MIDCOM-MIB module use VACM for controlling access to managed objects in the midcomRuleTable and the midcomGroupTable. It is further RECOMMENDED that individual MIDCOM clients, acting as SNMP Command Generators, only have access to an entry in the midcomRuleTable, the midcomResourceTable, or the midcomGroupTable, if they created the entry directly in the midcomRuleTable or indirectly in the midcomGroupTable and midcomResourceTable. Exceptions to this recommendation are situations where access by multiple MIDCOM clients to managed objects is explicitly required. One example is fail-over for MIDCOM agents where the stand-by MIDCOM agent needs the same access rights to managed objects as the currently active MIDCOM agent. Another example is a supervisor MIDCOM agent that monitors activities of other MIDCOM agents and/or may be used by network management systems to modify entries in tables of the MIDCOM-MIB. For this reason, all three tables listed above have the midcomRuleOwner as initial index. It is RECOMMENDED that MIDCOM clients acting as SNMP Command Generator have access to the midcomRuleTable and the midcomGroupTable restricted to entries with the initial index matching either their SNMP securityName or their VACM groupName. It is RECOMMENDED that they do not have access to entries in these tables with initial indices other than their SNMP securityName or their VACM groupName. It is RECOMMENDED that this VACM configuration is applied to read access, write access, and notify access for all objects in the midcomRuleTable and the midcomGroupTable. Note that less restrictive access rights MAY be granted to other users, for example, to a network management application, that monitors MIDCOM policy rules.
6.3. Notification Configuration
For each MIDCOM client that has access to the midcomRuleTable, a notification target SHOULD be configured at a Command Responder instantiating an implementation of the MIDCOM-MIB. It is RECOMMENDED that such a configuration be retrievable from the Command Responder via the SNMP-TARGET-MIB [RFC3413]. For each entry of the snmpTargetAddrTable that is related to a MIDCOM client, there SHOULD be an individual corresponding entry in the snmpTargetParamsTable. An implementation of the MIDCOM-MIB SHOULD also implement the SNMP- NOTIFICATION-MIB [RFC3413]. An instance of an implementation of the MIDCOM-MIB SHOULD have an individual entry in the snmpNotifyFilterProfileTable for each MIDCOM client that has access to the midcomRuleTable. An instance of an implementation of the MIDCOM-MIB SHOULD allow MIDCOM clients to start and stop the generation of notifications targeted at themselves. This SHOULD be realized by giving the MIDCOM clients write access to the snmpNotifyFilterTable. If appropriate entries of the snmpNotifyFilterTable are established in advance, then this can be achieved by granting MIDCOM clients write access only to the columnar object snmpNotifyFilterType. It is RECOMMENDED that VACM be configured such that each MIDCOM agent can only access entries in the snmpTargetAddrTable, the snmpTargetParamsTable, the snmpNotifyFilterProfileTable, and the snmpFilterTable that concern that particular MIDCOM agent. Typically, read access to the snmpTargetAddrTable, the snmpTargetParamsTable, and the snmpNotifyFilterProfileTable is sufficient. Write access may be required for objects of the snmpFilterTable.6.4. Simultaneous Access
Situations with two MIDCOM clients simultaneously modifying the same policy rule should be avoided. For each entry in the midcomRuleTable, there should be only one client at a time that modifies it. If two MIDCOM clients share the same midcomRuleOwner index of the midcomRuleTable, then conflicts can be avoided, for example, by - scheduling access times, as, for example, in the fail-over case; - using different midcomGroupIndex values per client; or - using non-overlapping intervals for values of the midcomRuleIndex per client.
6.5. Avoiding Idempotency Problems
As already discussed in section 4.2.4.4, the following recommendation is given for avoiding idempotency problems. In general, idempotency problems can be solved by including snmpSetSerialNo (see [RFC3418]) in SNMP SET requests. In case this feature is not used, it is RECOMMENDED that the value of the SNMP retransmission timer of a MIDCOM client (acting as SNMP Command Generator) is lower than the smallest requested value for any rule lifetime or rule idle time in order to prevent idempotency problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime when retransmitting an SNMP SET request after a lost SNMP reply. MIDCOM client implementations MAY completely avoid this problem by configuring their SNMP stack such that no retransmissions are sent. Similar considerations apply to MIDCOM-MIB implementations acting as Notification Originator when sending a notification (midcomUnsolicitedRuleEvent, midcomSolicitedRuleEvent or midcomSolicitedGroupEvent) containing the remaining lifetime of a policy rule or a policy rule group, respectively.6.6. Interface Indexing Problems
A well-known problem of MIB modules is indexing IP interfaces after a re-initialization of the managed device. The index for interfaces provided by the ifTable (see IF-MIB in [RFC2863]) may change during re-initialization, for example, when physical interfaces are added or removed. The MIDCOM-MIB module uses the interface index for indicating at which interface which policy rule is (or is to be) applied. Also, this index is used for indicating how policy rules are prioritized at certain interfaces. The MIDCOM-MIB module specification requires that information provided is always correct. This implies that after re-initialization, interface index values of policy rules or firewall configurations may have changed even though they still refer to the same interface as before the re-initialization. MIDCOM client implementations need to be aware of this potential behavior. It is RECOMMENDED that before writing the value or using the value of indices that depend on the ifTable the MIDCOM client checks if the middlebox has been re-initialized recently.
MIDCOM-MIB module implementations MUST track interface changes of IP interface indices in the ifTable. This implies that after a re- initialization of a middlebox, a MIDCOM-MIB implementation MUST make sure that each instance of an interface index in the MIDCOM-MIB tables still points to the same interface as before the re- initialization. For any instance for which this is not possible, all affected entries in tables of the MIDCOM-MIB module MUST be either terminated, disabled, or deleted, as specified in the DESCRIPTION clause of the respective object. This concerns all objects in the MIDCOM-MIB module that are of type InterfaceIndexOrZero.6.7. Applicability Restrictions
As already discussed in section 5.1.1, the MIDCOM-MIB requires the MIDCOM client to specify address tuples A0 and A3. This can be a problem for applications that do not have this information available when they need to configure the middlebox. For some applications, there are usage scenarios where address information is only available for a single address realm, A0 and A1 in the private realm or A2 and A3 in the public realm. An example is an FTP application using the PORT command (instead of the PASV command). The problem occurs when the middlebox offers twice-NAT functionality.7. Usage Examples for MIDCOM Transactions
This section presents some examples that explain how a MIDCOM client acting as SNMP manager can use the MIDCOM-MIB module defined in this memo. The purpose of these examples is to explain the steps that are required to perform MIDCOM transactions. For each MIDCOM transaction defined in the MIDCOM semantics [RFC5189], a sequence of SNMP operations that realizes the transaction is described. The examples described below are recommended procedures for MIDCOM clients. Clients may choose to operate differently. For example, they may choose not to receive solicited notifications on completion of a transaction, but to poll the MIDCOM-MIB instead until the transaction is completed. This can be achieved by performing step 2 of the SE transaction (see below) differently. The MIDCOM agent then creates an entry in the snmpNotifyFilterTable such that only the midcomUnsolicitedRuleEvent may pass the filter and is sent to the MIDCOM client. In this case, the PER, PRR, and RLC transactions require a polling loop wherever in the example below the MIDCOM client waits for a notification.
7.1. Session Establishment (SE)
The MIDCOM-MIB realizes most properties of MIDCOM sessions in a very static way. Only the generation of notifications targeted at the MIDCOM client is enabled by the client for session establishment. 1. The MIDCOM client checks the middlebox capabilities by reading objects in the midcomCapabilitiesGroup. 2. The MIDCOM client enables generation of notifications on events concerning the policy rules controlled by the client. If the SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3 of this document, then the agent just has to change the value of a object snmpNotifyFilterType in the corresponding entry of the snmpNotifyFilterTable from included(1) to excluded(2).7.2. Session Termination (ST)
For terminating a session, the MIDCOM client just disables the generation of notifications for this client. 1. The MIDCOM client disables generation of notifications on events concerning the policy rules controlled by the client. If the SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3 of this document, then the agent just has to change the value of a object snmpNotifyFilterType in the corresponding entry of the snmpNotifyFilterTable from included(1) to excluded(2).7.3. Policy Reserve Rule (PRR)
This example explains steps that may be performed by a MIDCOM client to establish a policy reserve rule. 1. The MIDCOM client creates a new entry in the midcomRuleTable by writing to midcomRuleRowStatus. The chosen value for index object midcomGroupIndex determines the group membership of the created rule. Note that choosing an unused value for midcomGroupIndex creates a new entry in the midcomGroupTable. 2. The MIDCOM client sets the following objects in the new entry of the midcomRuleTable to specify all request parameters of the PRR transaction: - midcomRuleMaxIdleTime - midcomRuleInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion
- midcomRuleExternalIpVersion
- midcomRuleInternalIpAddr
- midcomRuleInternalIpPrefixLength
- midcomRuleInternalPort
- midcomRuleLifetime
Note that several of these parameters have default values that can
be used.
3. The MIDCOM client sets the midcomRuleAdminStatus objects in the
new row of the midcomRuleTable to reserve(1).
4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification
concerning the new policy rule in the midcomRuleTable. Waiting
for the notification is timed out after a pre-selected maximum
waiting time. In case of a timeout while waiting for the
notification or if the client does not use notifications, the
MIDCOM client retrieves the status of the midcomRuleEntry by one
or more SNMP GET operations.
5. After receiving the midcomSolicitedRuleEvent notification, the
MIDCOM client checks the lifetime value carried by the
notification. If it is greater than 0, the MIDCOM client reads
all positive reply parameters of the PRR transaction:
- midcomRuleOutsideIpAddr
- midcomRuleOutsidePort
- midcomRuleMaxIdleTime
- midcomRuleLifetime
If the lifetime equals 0, then the MIDCOM client reads the
midcomRuleOperStatus and the midcomRuleError in order to analyze
the failure reason.
6. Optionally, after receiving the midcomSolicitedRuleEvent
notification with a lifetime value greater than 0, the MIDCOM
client may check the midcomResourceTable for the middlebox
resources allocated for this policy reserve rule. Note that PRR
does not necessarily allocate any middlebox resource visible in
the NAT-MIB module or in a firewall MIB module, since it does a
reservation only. If, however, the PRR overlaps with already
existing PERs, then the PRR may be related to middlebox resources
visible in other MIB modules.
7.4. Policy Enable Rule (PER) after PRR
This example explains steps that may be performed by a MIDCOM client to establish a policy enable rule after a corresponding policy reserve rule was already established. 1. The MIDCOM client sets the following objects in the row of the established PRR in the midcomRuleTable to specify all request parameters of the PER transaction: - midcomRuleMaxIdleTime - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleFlowDirection Note that several of these parameters have default values that can be used. 2. The MIDCOM client sets the midcomRuleAdminStatus objects in the row of the established PRR in the midcomRuleTable to enable(1). 3. The MIDCOM client awaits a midcomSolicitedRuleEvent notification concerning the new row in the midcomRuleTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomRuleEntry by one or more SNMP GET operations. 4. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification. If it is greater than 0, the MIDCOM client reads all positive reply parameters of the PER transaction: - midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleMaxIdleTime If the lifetime equals 0, then the MIDCOM client reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason. 5. Optionally, after receiving the midcomSolicitedRuleEvent notification with a lifetime value greater than 0, the MIDCOM client may check the midcomResourceTable for the allocated middlebox resources for this policy enable rule.
7.5. Policy Enable Rule (PER) without Previous PRR
This example explains steps that may be performed by a MIDCOM client to establish a policy enable rule for which no PRR transaction has been performed before. 1. Identical to step 1 for PRR (section 7.3). 2. Identical to step 2 for PRR (section 7.3). 3. The MIDCOM client sets the following objects in the new row of the midcomRuleTable to specify all request parameters of the PER transaction: - midcomRuleInterface - midcomRuleFlowDirection - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleLifetime Note that several of these parameters have default values that can be used. 4. The MIDCOM client sets the midcomRuleAdminStatus objects in the new row of the midcomRuleTable to enable(1). 5. Identical to step 4 for PRR (section 7.3). 6. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification. If it is greater than 0, the MIDCOM client reads all positive reply parameters of the PRR transaction: - midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleMaxIdleTime
If the lifetime equals 0, then the MIDCOM client reads the
midcomRuleOperStatus and the midcomRuleError in order to analyze
the failure reason.
7. Optionally, after receiving the midcomSolicitedRuleEvent
notification with a lifetime value greater than 0, the MIDCOM
client may check the midcomResourceTable for the allocated
middlebox resources for this policy enable rule.
7.6. Policy Rule Lifetime Change (RLC)
This example explains steps that may be performed by a MIDCOM client
to change the lifetime of a policy rule. Changing the lifetime to 0
implies terminating the policy rule.
1. The MIDCOM client issues a SET request for writing the desired
lifetime to the midcomRuleLifetime object in the corresponding row of
the midcomRuleTable. This does not have any effect if the lifetime
is already expired.
2. The MIDCOM client awaits a midcomSolicitedRuleEvent notification
concerning the corresponding row in the midcomRuleTable. Waiting for
the notification is timed out after a pre-selected maximum waiting
time. In case of a timeout while waiting for the notification or if
the client does not use notifications, the MIDCOM client retrieves
the status of the midcomRuleEntry by one or more SNMP GET operations.
3. After receiving the midcomSolicitedRuleEvent notification MIDCOM
client checks the lifetime value carried by the notification.
7.7. Policy Rule List (PRL)
The SNMP agent can browse the list of policy rules by browsing the
midcomRuleTable. For each observed row in this table, the SNMP agent
should check the midcomRuleOperStatus in order to find out if the row
contains information about an established policy rule or of a rule
that is under construction or already terminated.
7.8. Policy Rule Status (PRS)
The SNMP agent can retrieve all status information and properties of
a policy rule by reading the managed objects in the corresponding row
of the midcomRuleTable.
7.9. Asynchronous Policy Rule Event (ARE)
There are two different triggers for the ARE. It may be triggered by the expiration of a policy rule's lifetime or the expiration of the idle time. But beyond this, the MIDCOM-MIB implementation may terminate a policy rule at any time. In all cases, two steps are required for performing this transaction: 1. The MIDCOM-MIB implementation sends a midcomUnsolicitedRuleEvent notification containing a lifetime value of 0 to the MIDCOM client owning the rule. 2. If the midcomRuleStorageTime object in the corresponding row of the midcomRuleTable has a value of 0, then the MIDCOM-MIB implementation removes the row from the table. Otherwise, it sets in this row the midcomRuleLifetime object to 0 and changes the midcomRuleOperStatus object. If the event was triggered by policy lifetime expiration, then the midcomRuleOperStatus is set to timedOut(9); otherwise, it is set to terminated(11).7.10. Group Lifetime Change (GLC)
This example explains steps that may be performed by a MIDCOM client to change the lifetime of a policy rule group. Changing the lifetime to 0 implies terminating all member policies of the group. 1. The MIDCOM client issues a SET request for writing the desired lifetime to the midcomGroupLifetime object in the corresponding row of the midcomGroupTable. 2. The MIDCOM client waits for a midcomSolicitedGroupEvent notification concerning the corresponding row in the midcomGroupTable. Waiting for the notification is timed out after a pre-selected maximum waiting time. In case of a timeout while waiting for the notification or if the client does not use notifications, the MIDCOM client retrieves the status of the midcomGroupEntry by one or more SNMP GET operations. 3. After receiving the midcomSolicitedRuleEvent notification, the MIDCOM client checks the lifetime value carried by the notification.7.11. Group List (GL)
The SNMP agent can browse the list of policy rule groups by browsing the midcomGroupTable. For each observed row in this table, the SNMP agent should check the midcomGroupLifetime in order to find out if the group does contain established policies.
7.12. Group Status (GS)
The SNMP agent can retrieve all member policies of a group by browsing the midcomRuleTable using the midcomGroupIndex of the particular group. For retrieving the remaining lifetime of the group, the SNMP agent reads the midcomGroupLifetime object in the corresponding row of the midcomGroupTable.8. Usage Examples for Monitoring Objects
This section presents some examples that explain how a MIDCOM client can use the midcomResourceTable to correlate policy rules with the used middlebox resources. One example is given for middleboxes implementing the NAT-MIB and another one is given for firewalls.8.1. Monitoring NAT Resources
When a rule in the midcomRuleTable is executed, it directly impacts the middlebox resources. The midcomResourceTable provides the information on the relationships between the MIDCOM-MIB policy rules and the middlebox resources used for enforcing these rules. A MIDCOM-MIB policy rule will cause the creation or modification of up to two NAT bindings and up to two NAT sessions. Two NAT bindings are impacted in the case of a session being subject to twice-NAT. Two NAT bindings may also be impacted when midcomRulePortRange is set to pair(2) in the policy rule. In the majority of cases, where traditional NAT is implemented, only a single NAT binding may be adequate. Note, however, that this BindId is set to 0 if the middlebox is implementing symmetric NAT function. Two NAT sessions are created or modified only when the midcomRulePortRange is set to pair(2) in the policy rule. When support for the NAT-MIB module is also available at the middlebox, the parameters in the combination of the midcomRuleTable and the midcomResourceTable for a given rule can be used to index the corresponding BIND and NAT session resources effected in the NAT-MIB. These parameters are valuable to monitor the impact on the NAT module, even when the NAT-MIB module is not implemented at the middlebox. The impact of MIDCOM rules on the NAT resources is important because a MIDCOM rule not only can create BINDs and NAT sessions, but also is capable of modifying the NAT objects that already exist. For example, FlowDirection and MaxIdleTime parameters in a MIDCOM rule directly affect the TranslationEntity and MaxIdleTime of the associated NAT bind object. Likewise, MaxIdleTime in a MIDCOM rule
has a direct impact on the MaxIdleTime of the associated NAT session object. The lifetime parameter in the MIDCOM rule directly impacts the lifetime of all the impacted NAT BIND and NAT session objects.8.2. Monitoring Firewall Resources
When a MIDCOM-MIB policy rule is established at a middlebox with firewall capabilities, this may lead to the creation of one or more new firewall rules. Note that in general a single firewall rule per MIDCOM-MIB policy rule will be sufficient. For each policy rule, a MIDCOM client can explore the corresponding firewall filter rule by reading the midcomResourceEntry in the midcomResourceTable that corresponds to the midcomRuleEntry describing the rule. The identification of the firewall filter rule is stored in object midcomRscFirewallRuleId. The value of midcomRscFirewallRuleId may correspond directly to any firewall filter rule number or to an entry in a locally available firewall MIB module.
(page 38 continued on part 3)