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]. RFC5189] into two subtrees, one for policy rule control and one for policy rule group control.
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.
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.
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.
o midcomConfigFirewallPriority This object indicates the priority assigned to all firewall rules of the MIDCOM server. 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.
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.
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.
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.
section 18.104.22.168, 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. 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. 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. 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.
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). 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).
- 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.
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.
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.