Definitions of Managed Objects for Middlebox Communication
Extracted elements (27)
Atomicity of MIDCOM transactions is not fully guaranteed when mapped to SNMP, since configuration transactions may require multiple SNMP SET operations. However, the MIB still provides sufficient atomicity for RFC 3304 requirements: during non-atomic monitoring transactions, the middlebox notifies the client of all state changes so the client can reconcile or repeat the query.
MIDCOM reply messages can be realized two ways: (1) an SNMP notification optionally followed by GET transactions, or (2) polling via SNMP GET transactions until processing completes. The polling approach requires more operations but is more reliable because SNMP notifications are sent as unreliable UDP packets.
SNMP has no direct support for sessions, so MIDCOM sessions are modeled statically. Authentication and authorization are performed per-message using SNMPv3 (USM for authentication, VACM for access control) rather than per-session. Per-message security is overhead compared to per-session mechanisms, but it satisfies MIDCOM security requirements.
The midcomRuleOwner is used as the initial index for all three main tables (midcomRuleTable, midcomGroupTable, midcomResourceTable), enabling VACM-based access control where each MIDCOM client is restricted to entries indexed by its own securityName or groupName.
To avoid confusion between MIDCOM's use of 'agent' (the trusted third party) and SNMP's use of 'agent' (the server), this document renames the MIDCOM agent to 'MIDCOM client'. The SNMP manager corresponds to the MIDCOM client, and the SNMP agent corresponds to the MIDCOM middlebox/server.
Multiple MIDCOM clients may create policy rules that share the same underlying NAT binding or firewall rule. MIDCOM-MIB implementations must manage shared resource properties (e.g., lifetime, precedence) such that all clients are served, and must communicate resource changes to all affected clients.
SNMP notifications are sent as unreliable UDP packets and may be dropped before reaching the MIDCOM client. Clients expecting an asynchronous notification on a specific transaction must poll the middlebox periodically using SNMP GET transactions to monitor transaction status when notifications may be lost.
The ifTable interface index can change after device re-initialization when physical interfaces are added or removed. MIDCOM clients SHOULD check whether the middlebox has been re-initialized before using interface index values, as silent index reassignment could cause MIDCOM-MIB objects to reference unintended interfaces.
The MIDCOM-MIB requires MIDCOM clients to specify address tuples A0 (internal endpoint) and A3 (external endpoint). Applications such as FTP using the PORT command (rather than PASV) that only know one address realm when configuring the middlebox cannot comply with this requirement when the middlebox provides twice-NAT functionality.
An implementation of MIDCOM-MIB SHOULD configure a notification target for each MIDCOM client with access to midcomRuleTable, with individual entries in snmpNotifyFilterProfileTable per client, and SHOULD allow clients to start and stop notification generation targeted at themselves by granting write access to snmpNotifyFilterType.
MIDCOM-MIB implementations MUST track interface changes of IP interface indices in the ifTable. After a re-initialization, implementations MUST ensure each InterfaceIndexOrZero instance still points to the same interface; for any instance where this is not possible, all affected entries MUST be terminated, disabled, or deleted per the DESCRIPTION clause of the respective object.
SNMP Command Responders implementing the MIDCOM-MIB SHOULD use the authPriv security level for all users accessing MIDCOM-MIB managed objects. Given that controlling firewalls and NATs is highly sensitive, this provides both authentication and encryption for MIDCOM traffic.
SNMP Command Responders instantiating the MIDCOM-MIB SHOULD use VACM to control access to midcomRuleTable and midcomGroupTable. Individual MIDCOM clients SHOULD only have access to entries they created, restricted to entries whose initial index matches their SNMP securityName or VACM groupName, for read, write, and notify access.
To prevent idempotency problems when retransmitting SNMP SET requests for lifetime changes (midcomRuleLifetime, midcomRuleMaxIdleTime), it is RECOMMENDED to include snmpSetSerialNo in SET requests, or to set the SNMP retransmission timer lower than the smallest requested lifetime or idle time value. MIDCOM clients MAY avoid this entirely by disabling retransmissions.
Four address tuples A0–A3 are defined in each midcomRuleEntry: A0 is the internal endpoint, A1 is the middlebox inside address (virtual endpoint on the internal side), A2 is the middlebox outside address (virtual endpoint on the external side), and A3 is the external endpoint. Each tuple carries an IP version, IP address, prefix length, and port.
The midcomConfigFirewallTable configures how MIDCOM-MIB policy rules are mapped to firewall rules per IP interface, providing midcomConfigFirewallGroupId (the firewall rule group name) and midcomConfigFirewallPriority (the priority). All MIDCOM policy rules at a given interface share the same priority in the firewall implementation.
The midcomConfigIfBits BITS object in midcomConfigIfTable reports per-interface middlebox capabilities: ipv4, ipv6, addressWildcards, portWildcards, firewall, nat, portTranslation, protocolTranslation, twiceNat, and inside (indicating NAT inside interface). Interface index 0 denotes capabilities available on all interfaces. midcomConfigIfEnabled indicates whether these capabilities are currently active.
The midcomGroupTable has one entry per policy rule group, auto-created when a midcomRuleTable entry uses a new midcomGroupIndex and auto-deleted when the last member entry is removed. midcomGroupLifetime reflects the maximum remaining lifetime across all established member rules and can be written to change all member lifetimes at once (setting it to 0 terminates all member rules).
The midcomResourceTable augments midcomRuleTable with information about middlebox resources allocated per policy rule: NAT binding identifiers (midcomRscNatInternalAddrBindId, midcomRscNatExternalAddrBindId), NAT session identifiers (midcomRscNatSessionId1/2), and firewall rule identifier (midcomRscFirewallRuleId). Entries are only valid when midcomRuleOperStatus is reserved(7) or enabled(8). Resource identifiers may reference NAT-MIB (RFC 4008) or be vendor-proprietary.
The midcomRuleTable is the core transaction table, indexed by midcomRuleOwner, midcomGroupIndex, and midcomRuleIndex. It holds request and result parameters for policy rules including address tuples A0–A3, transport protocol, port range, lifetime, idle time, and administrative/operational status. Entries are created by writing to midcomRuleRowStatus and expire when both midcomRuleLifetime and midcomRuleStorageTime reach 0.
The midcomStatistics subtree provides scalar counters tracking MIDCOM-MIB usage: midcomCurrentOwners, midcomTotalRejectedRuleEntries, midcomCurrentActiveReserveRules, midcomCurrentActiveEnableRules, midcomTotalExpiredReserveRules, midcomTotalTerminatedReserveRules, midcomTotalTerminatedOnRqReserveRules, and analogous counters for policy enable rules.
Three SNMP notifications are defined: midcomUnsolicitedRuleEvent (ARE transaction — rule expiration, idle timeout, or internal termination), midcomSolicitedRuleEvent (PRR, PER, and RLC transaction replies), and midcomSolicitedGroupEvent (GLC transaction reply). Clients can selectively filter solicited notifications via snmpNotifyFilterTable and use polling instead.
This document registers the MIDCOM-MIB module under the IANA-assigned OID space within mib-2. The MIB defines the midcomMIB object, compliance statements, object groups, and notification groups for configuring and monitoring firewalls and NATs via SNMP.
Unauthorized access to MIDCOM service configuration (midcomConfigFirewallTable, midcomCapabilities subtree) could allow an attacker to alter firewall rule priorities or disable capabilities. Write access to configuration objects SHOULD be restricted more strictly than write access to transaction objects, and typically should not be granted to MIDCOM clients.
Unauthorized middlebox configuration is the primary threat: an attacker who can write to the MIDCOM-MIB could open unintended pinholes in firewalls or create unauthorized NAT bindings. SNMPv3 with authPriv security level and VACM-based access control restricted to rule owners are the required mitigations.
Unauthorized read access to midcomRuleTable and midcomGroupTable exposes information about existing firewall pinholes and NAT sessions, enabling targeted attacks. VACM SHOULD be configured so each MIDCOM client can only read entries it owns, and monitoring applications with broader read access SHOULD be granted only the minimum necessary scope.
midcomRuleOperStatus tracks a policy rule through states: initializing, transient (processing), error (request rejected), reserved(7), enabled(8), timedOut(9), and terminated(11). Writing reserve(1) to midcomRuleAdminStatus initiates a PRR transaction; writing enable(2) initiates a PER transaction. A lifetime of 0 returned in a notification signals failure.