Internet Draft J. Quittek Document: draft-ietf-midcom-mib-01.txt M. Stiemerling Expires: October 2004 NEC Europe Ltd. P. Srisuresh Caymas Systems May 2004 Definitions of Managed Objects for Middlebox Communication <draft-ietf-midcom-mib-01.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC XXXX. Quittek, Stiemerling, Srisuresh [Page 1]
Internet-Draft MIDCOM MIB May 2004 Table of Contents 1 Introduction ................................................. 2 2 The Internet-Standard Management Framework ................... 2 3 Overview ..................................................... 2 3.1 Terminology ................................................ 3 4 Realizing the MIDCOM Protocol with SNMP ...................... 4 4.1 MIDCOM Sessions ............................................ 4 4.1.1 Authentication and Authorization ......................... 5 4.2 MIDCOM Transactions ........................................ 5 4.2.1 Asynchronous Transactions ................................ 5 4.2.2 Configuration Transactions ............................... 6 4.2.3 Monitoring Transactions .................................. 9 4.2.4 Atomicity of Transactions ................................ 10 4.2.4.1 Asynchronous Transactions .............................. 10 4.2.4.2 Session Establishment and Termination Transactions ..... 10 4.2.4.3 Monitoring Transactions ................................ 11 4.2.4.4 Lifetime Change Transactions ........................... 11 4.2.4.5 Transactions Establishing New Policy Rules ............. 11 4.2.5 Access Control ........................................... 12 4.3 Access Control Policies .................................... 12 5 Structure of the MIB module .................................. 13 5.1 Signaling Objects .......................................... 13 5.1.1 midcomSession ............................................ 13 5.1.2 midcomRuleTable .......................................... 14 5.1.3 midcomGroupTable ......................................... 17 5.2 Configuration Objects ...................................... 17 5.2.1 Capabilities ............................................. 18 5.2.2 midcomConfigFirewallTable ................................ 19 5.3 Monitoring Objects ......................................... 19 5.3.1 midcomResourceTable ...................................... 19 5.3.2 midcomStatistics ......................................... 21 5.4 Notifications .............................................. 22 6 Usage Examples ............................................... 23 6.1 Session Establishment (SE) ................................. 23 6.2 Session Termination (ST) ................................... 24 6.3 Asynchronous Session Termination (AST) ..................... 24 6.4 Policy Reserve Rule (PRR) .................................. 24 6.5 Policy Enable Rule (PER) after PRR ......................... 25 6.6 Policy Enable Rule (PER) without previous PRR .............. 26 6.7 Policy Rule Lifetime Change (RLC) .......................... 27 6.8 Policy Rule List (PRL) ..................................... 27 6.9 Policy Rule Status (PRS) ................................... 27 6.10 Asynchronous Policy Rule Event (ARE) ...................... 28 6.11 Group Lifetime Change (GLC) ............................... 28 6.12 Group List (GL) ........................................... 28 6.13 Group Status (GS) ......................................... 28 7 Definitions .................................................. 29 8 Security Considerations ...................................... 75 8.1 General Security Issues .................................... 75 Quittek, Stiemerling, Srisuresh [Page 2]
Internet-Draft MIDCOM MIB May 2004 8.2 Unauthorized Middlebox Configuration ....................... 76 tion ...................................................... 77 8.4 Unauthorized Access to MIDCOM Service Configuration ........ 78 9 Acknowledgements ............................................. 78 10 Open Issues ................................................. 78 11 Normative References ........................................ 79 12 Informative References ...................................... 79 13 Authors' Addresses .......................................... 80 14 IPR Notices ................................................. 80 15 Full Copyright Statement .................................... 81 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow controlling middleboxes. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Overview The managed objects defined in this document serve for controlling firewalls and Network Address Translators (NATs). As defined in [RFC3234], firewalls and NATs belong to the group of middleboxes. A middlebox is a device on the datagram path between source and destination, which performs other functions than just IP routing. As outlined in [RFC3303], firewalls and NATs are potential obstacles to packet streams, for example if dynamically negotiated UDP or TCP port Quittek, Stiemerling, Srisuresh [Page 3]
Internet-Draft MIDCOM MIB May 2004 numbers are used, as in many peer-to-peer communication applications. As one possible solution for this problem, the IETF MIDCOM working group defined a framework [RFC3303], requirements [RFC3304] and protocol semantics [RFCXXXX] for communication between applications and middleboxes acting as firewalls, NATs or a combination of both. The MIDCOM architecture and framework defines a model in which trusted third parties can be delegated to assist middleboxes in performing their operations, without requiring application intelligence being embedded in the middleboxes. This trusted third party is referred to as the MIDCOM Agent. The MIDCOM protocol is defined between the MIDCOM agent and middlebox. The managed objects defined in this document can be used for dynamically configuring middleboxes on the datagram path to permit datagrams traversing the middleboxes. This way, applications can, for example, request pinholes at firewalls and address bindings at NATs. Besides managed objects for controlling the middlebox operation, this document also defines managed objects that provide information on middlebox resource usage (such as firewall pinholes, NAT bindings, NAT sessions, etc.) effected by requests. Since firewalls and NATs are critical devices concerning network security, security issues of middlebox communication need to be considered very carefully. 3.1. Terminology The terminology used in this document is fully aligned with the terminology defined in [RFCXXXX] except for the term 'MIDCOM agent'. For this term there is a conflict between the MIDCOM terminology and the SNMP terminology. The roles of entities participating in SNMP communication are called 'manager' and 'agent' with the agent acting as server for requests from the manager. This use of the term 'agent' is different to its use in the MIDCOM framework: The SNMP manager corresponds to the MIDCOM agent and the SNMP agent corresponds to the MIDCOM middlebox. In order to avoid confusion in this document specifying a MIB module, we replace the term 'MIDCOM agent' by 'MIDCOM client'. Whenever the term 'agent' is used in this document, it refers to the SNMP agent. Figure 1 sketches the entities of MIDCOM in relationship to SNMP manager and SNMP agent. Quittek, Stiemerling, Srisuresh [Page 4]
Internet-Draft MIDCOM MIB May 2004 +---------+ MIDCOM +-----------+ | MIDCOM |<~ ~ ~ ~ ~ ~ ~ ~>| MIDCOM | | Client | Transaction | middlebox | +---------+ +-----------+ ^ ^ | | v v +---------+ +-----------+ | SNMP | SNMP | SNMP | | Manager |<===============>| Agent | +---------+ Protocol +-----------+ Figure 1: Mapping of MIDCOM to SNMP NOTE to the RFC Editor: Please replace in this document RFCXXXX with the approriate RFC number that will be assigned; the corresponding Internet draft is draft-ietf-midcom-semantics-07.txt. Please replace RFCXXYY with the appropriate RFC nummer that will be assigned; the corresponding Internet draft is draft-ietf-nat-natmib-09.txt 4. Realizing the MIDCOM Protocol with SNMP In order to realize middlebox communication as described in RFC XXXX, several aspects and properties of the MIDCOM protocol need to be mapped to SNMP capabilities and expressed in terms of the Structure of Management Information version 2 (SMIv2). Basic concepts to be mapped are MIDCOM sessions and MIDCOM transactions. For both, access control policies need to be supported. 4.1. MIDCOM Sessions SNMP has no direct support for sessions. Therefore, they need to be modeled. A session is stateful and has a context that is valid for several transactions. For SNMP, a context is valid for a single transaction only, for example covering just a single request/reply pair of messages. Properties of sessions that are utilized by the MIDCOM semantics and not avaiable in SNMP need to be modeled. Particularly, the middlebox needs to be able to send notification messages to MIDCOM clients participating in a session. The midcomSessionTable described in more detail in Section 5.1.1 provides this information. Each MIDCOM client that opens a session has to create an entry in the midcomSessionTable. This entry identifies the MIDCOM client as participant of a session and gives the middlebox sufficient information for sending notifications to the client. The MIDCOM-MIB module requires a MIDCOM client to create an Quittek, Stiemerling, Srisuresh [Page 5]
Internet-Draft MIDCOM MIB May 2004 entry in the midcomSessionTable before it creates or modifies MIDCOM policy rules. Without creating an entry in the session table, the MIDCOM client cannot create or modify any MIDCOM policy rule and it will not receive any notification indicating state changes at the middlebox. 4.1.1. Authentication and Authorization MIDCOM sessions are required to provide authentication, authorization and encryption for messages exchanged between MIDCOM client and middlebox. SNMPv3 provides these features on a per-message basis instead of a per-session basis. This more fine-grained security based on the User-based Security Model (USM, [RFC3414]) providing authentication and the View-based Access control Model (VACM, [RFC3415]) that can be used for authorization of access to managed objects. This can be considered as overhead compared to per-session security mechanisms, but it completely satisfies the security requirements of middlebox communication. Any MIDCOM client that wants to start a session by creating an entry in the session table needs to authenticate itself as an SNMP user. For the authenticated user, access should be thoroughly configured as part of the VACM configuration of the SNMP agent. 4.2. MIDCOM Transactions RFCXXXX defines the MIDCOM protocol semantics in terms of transactions and transaction parameters. Transactions are grouped into request-reply transactions and asynchronous transactions. SNMP offers simple transactions that in general cannot be mapped one- to-one to MIDCOM transactions. This section describes how the MIDCOM MIB module implements MIDCOM transactions using SNMP transactions. The concerned MIDCOM transactions are asynchronous transactions and request-reply transactions. Within the set of request-reply transactions we distinguish configuration transactions and monitoring transactions, because they are implemented in slightly different ways by using SNMP transactions. 4.2.1. Asynchronous Transactions Asynchronous transactions can easily be modeled by SNMP notifications. An asynchronous transaction contains a notification message with one to three parameters. The message can be realized as an SNMP notification with the parameters implemented as managed objects contained in the notification. Quittek, Stiemerling, Srisuresh [Page 6]
Internet-Draft MIDCOM MIB May 2004 +--------------+ notification +------------+ | MIDCOM client|<--------------| middlebox | +--------------+ message +------------+ MIDCOM asynchronous transaction +--------------+ SNMP +------------+ | SNMP manager |<--------------| SNMP agent | +--------------+ notification +------------+ Implementation of MIDCOM asynchronous transaction Figure 2: MIDCOM asynchronous transaction mapped to SNMP notification One of the parameters is the transaction identifier that should be unique per middlebox. It does not have to be unique for all notifications sent by the particular SNMP agent, but for all sent notifications that are defined by the MIDCOM MIB module. Note, asynchronous notifications are sent as unreliable UDP packets and may be dropped before they reach their destination. If a MIDCOM client is expecting asynchronous notification on a specific transaction, it would be the job of the MIDCOM client to poll the middlebox periodically and monitor the transaction in case notifications are lost along the way. 4.2.2. Configuration Transactions All request-reply transactions contain a request message, a reply message and potentially also a set of notifications. In general they cannot be modeled by just having one SNMP message per MIDCOM message, because some of the MIDCOM messages carry a large set of parameters that do not necessarily fit into an SNMP message consisting of a single UDP packet only. For configuration transactions the MIDCOM request message can be modeled by one or more SNMP set transactions. The action of sending the MIDCOM request to the middlebox is realized by writing the parameters contained in the message to managed objects at the SNMP agent. If necessary, the SNMP set transaction includes creating these managed objects. If not all parameters of the MIDCOM request message can be set by a single SNMP set transaction, then more than one set transactions are used, see Figure 3. The last one of these messages must clearly indicate that now all parameters are set and that processing of the MIDCOM request message can start at the Quittek, Stiemerling, Srisuresh [Page 7]
Internet-Draft MIDCOM MIB May 2004 middlebox. +--------------+ request +------------+ | MIDCOM client|-------------->| middlebox | +--------------+ message +------------+ MIDCOM request message +--------------+ +------------+ | | SNMP set | | | |-------------->| | | | message | | | | | | | | SNMP set | | | |<--------------| | | | reply message | | | SNMP manager | | SNMP agent | | | SNMP set | | | |- - - - - - - >| | | | message | | | | | | | | SNMP set | | | |< - - - - - - -| | | | reply message | | | | | | | | . . . | | +--------------+ +------------+ Implementation of MIDCOM request message by one or more SNMP set messages Figure 3: MIDCOM request message mapped to SNMP set transactions Please note that a single SNMP set transaction consists of an SNMP set request message and an SNMP set reply message. Both are sent as unreliable UDP packets and may be dropped before they reach their destination. If the SNMP set request message is lost, then the SNMP agent repeats the message after receiving no reply for a specified time. Also if the SNMP set reply message is lost, the SNMP agent retransmit the SNMP set message. But this time, the SNMP agent receives the same message twice and must make sure that it accepts the second message as it did the first one and that it sends an SNMP reply message again. The MIDCOM reply message can be modeled by an SNMP notification Quittek, Stiemerling, Srisuresh [Page 8]
Internet-Draft MIDCOM MIB May 2004 transaction optionally followed by one or more SNMP get transactions as shown in Figure 4. The SNMP agent informs the SNMP manager about the end of processing the request by sending an SNMP notification. If possible, the SNMP notification carries all reply parameters. If this is not possible, then the SNMP manager has to perform additional SNMP get transactions as long as is needed to receive all of the reply parameters. +--------------+ reply +------------+ | MIDCOM client|<--------------| middlebox | +--------------+ message +------------+ MIDCOM reply message +--------------+ +------------+ | | SNMP | | | |<--------------| | | | notification | | | | | | | | SNMP get | | | |-------------->| | | | message | | | SNMP manager | | SNMP agent | | | SNMP get | | | |<--------------| | | | reply message | | | | | | | | SNMP get | | | |- - - - - - - >| | | | message | | | | | | | | SNMP get | | | |< - - - - - - -| | | | reply message | | | | | | | | . . . | | +--------------+ +------------+ Implementation of MIDCOM reply message by an SNMP notification and one or more SNMP set messages Figure 4: MIDCOM reply message mapped to SNMP notification and optional get transactions Quittek, Stiemerling, Srisuresh [Page 9]
Internet-Draft MIDCOM MIB May 2004 4.2.3. Monitoring Transactions The realization of MIDCOM monitoring transactions in terms of SNMP transactions is simpler. The request message is very short and just specifies a piece of information that the MIDCOM client wants to retrieve. Since monitoring is a stronghold of SNMP, there are sufficient means to realize MIDCOM monitoring transactions simpler than MIDCOM configuration transactions. +--------------+ request +------------+ | |-------------->| | | | message | | | MIDCOM client| | middlebox | | | reply | | | |<--------------| | +--------------+ message +------------+ MIDCOM monitoring transaction +--------------+ +------------+ | | SNMP get | | | |-------------->| | | | message | | | | | | | | SNMP get | | | |<--------------| | | | reply message | | | SNMP manager | | SNMP agent | | | SNMP get | | | |- - - - - - - >| | | | message | | | | | | | | SNMP get | | | |< - - - - - - -| | | | reply message | | | | | | | | . . . | | +--------------+ +------------+ Implementation of MIDCOM monitoring transaction by one or more SNMP get messages Figure 5: MIDCOM monitoring transaction mapped to SNMP get transactions Quittek, Stiemerling, Srisuresh [Page 10]
Internet-Draft MIDCOM MIB May 2004 All MIDCOM monitoring transactions can be realized as a sequence of SNMP get transactions. If one or more SNMP get transactions are required depends on the amount of information that is to be retrieved. 4.2.4. Atomicity of Transactions Given the realizations of MIDCOM transactions by means of SNMP transactions, atomicity of the MIDCOM transactions is not fully guaranteed anymore. However, atomicity provided by the MIB module specified in section 6 is still sufficient for meeting the MIDCOM requirements specified in [RFC3304]. We show this by analyzing atomicity for all MIDCOM transactions. 4.2.4.1. Asynchronous Transactions There are two asynchronous MIDCOM transactions: Asynchronous Session Termination (AST) and Asynchronous policy Rule Event (ARE). For both atomicity is maintained, because each of them is modeled by a single atomic SNMP notification transaction. 4.2.4.2. Session Establishment and Termination Transactions For the Session Establishment (SE) transaction and the Session Termination (ST) atomicity is maintained. The ST transaction has very few parameters. The request parameters can be transmitted by a single SNMP set request message and the reply parameters can be transmitted by a single SNMP notifications message. Basically, the same holds for SE, but it needs more explanations. The SE transaction includes the optional transmission of authentication challenges and authentication replies. These are not required explicity, because SNMPv3 is used. SNMPv3 provides all required means for authentication. Also, the SE transaction includes tranmission of middlebox capabilities from the middlebox to the MIDCOM client. But for this transmission, there is no atomicity requirement, because these capabilities do not change frequently and can be transmitted piece by piece. Therefore, the SE transaction is implemented by an SNMP set transaction modeling the request message and an SNMP notification transaction modeling the reply message excluding the transfer of middlebox capabilities. In the MIDCOM MIB module the middlebox capabilities are provided by a set of managed objects that can be read by the MIDCOM client at any time using SNMP get transactions. Quittek, Stiemerling, Srisuresh [Page 11]
Internet-Draft MIDCOM MIB May 2004 4.2.4.3. Monitoring Transactions For the monitoring transactions Policy Rule List (PRL), Policy Rule Status (PRS) Group List (GL) und Group Status (GS) atomicity is not given anymore, because they are implemented by potentially more than one SNMP get operations. The problem that might occur is that while the monitoring transaction is performed, the monitored items may change. For example, while reading a long list of policies, new policies may be added and already read policies may be deleted. This is not in line with the protcol semantics. However, it is not in direct conflict with the MIDCOM requirement requesting the middlebox state to be stable and known by the MIDCOM client, because the middlebox notifies the MIDCOM client on all changes to its state that are performed during the monitoring transaction by sending notifications. If the MIDCOM client receives such a notification while performing a monitoring transaction (or shortly after completing it), the MIDCOM client can then either repeat the monitoring transaction or integrate the result of the monitoring transaction with the information received via notifications during the transaction. In both cases, the MIDCOM client will finally know the state of the middlebox. 4.2.4.4. Lifetime Change Transactions For the policy Rule Lifetime Change (RLC) transaction and the Group Lifetime Change (GLC) transaction atomicity is maintained. They both have very few parameters for request message and reply message. The request parameters can be transmitted by a single SNMP set request message and the reply parameters can be transmitted by a single SNMP notifications message. 4.2.4.5. Transactions Establishing New Policy Rules Analogous to the monitoring transactions, the atomiticty is not given for Policy Reserve Rule (PRR) and Policy Enable Rule (PER) transactions. Both transactions are potentially implemented using more than one SNMP set and get operations for obtaining transaction reply parameters. The solution for this loss of atomicity is the same as for the monitoring transactions. There is an additional atomicity problem for PRR and PER. If transferring request parameters requires more than a single set operation, then there is the potential problem that multiple MIDCOM clients sharing the same permissions are able to access the same policy rule. In this case a client could alter request parameters already set by another client before the other client could complete the request. However, this is acceptable since usually only one agent is creating a policy rule and filling it subsequently. It can Quittek, Stiemerling, Srisuresh [Page 12]
Internet-Draft MIDCOM MIB May 2004 also be assumed that in most cases where clients share permissions, they act in a more or less co-ordinated way avoiding such interferences. 4.2.5. Access Control Since SNMP does not offer per-session authentication and authorization, authentication and authorization are performed per SNMP message sent from the MIDCOM client to the middlebox. For each transaction, the MIDCOM client has to authenticate itself as an SNMP user according to USM. Then the user's access rights to all resources affected by the transaction are checked. Access right control is realized by configuring the VACM mechanisms at the SNMP agent. 4.3. Access Control Policies Potentially, a middlebox has to control access for a large set of MIDCOM clients and to a large set of policy rules configuring firewall pinholes and NAT bindings. Therefore it can be beneficial to use access control policies for specifying access control rules. Generating, provisioning and managing these policies is out of scope of this MIB module. However, if such access control policy system is used, then the SNMP agent acts as policy enforcement point. An access control policy system must transform all active policies into configurations of the SNMP agent's User Based Security Model (USM) and the View-based Access Control Model (VACM). The mechanisms of USM allow an access control policy system to enforce MIDCOM client authentication rules and general access control of MIDCOM clients to middlebox control. The mechanisms of VACM can be used to enforce access control of authenticated clients to MIDCOM policy rules based on the concept of ownership. For example, an access control policy can specify that MIDCOM policy rules owned by user A, cannot be accessed at all by user B, can be read by user C, and can be read and modified by user D. Further access control policies can control access to concrete middlebox resources. These are enforces, when a MIDCOM request is processed. For example an authenticated MIDCOM client may be authorized to request new MIDCOM policies to be established, but only for certain IP address ranges. The enforcement of this kind of policies cannot be realized by using available SNMP mechanisms, but needs to be performed by the individual MIB module implementation. Quittek, Stiemerling, Srisuresh [Page 13]
Internet-Draft MIDCOM MIB May 2004 5. Structure of the MIB module the MIB module defined in Section 6 contains three branches of managed objects: - Signaling objects The signaling branch contains objects that are required for implementing the MIDCOM protocol requirements defined in [RFC3304] and the MIDCOM protocol semantics defined in [RFCXXXX]. - Configuration objects Configuration objects can be used for retrieving middlebox capability information (mandatory) and for setting parameters of the implementation of objects in the signaling branch (optional). - Monitoring objects The optional monitoring objects that provide information about used resource and about MIDCOM signaling statistics. 5.1. Signaling Objects The signaling branch is structured according to the MIDCOM semantics described in [RFCXXXX]. It contains three groups of objects for session control, policy rule control and policy rule group control. 5.1.1. midcomSession The midcomSession group of managed objects models MIDCOM sessions. For opening a session, a MIDCOM client has to create a row in the contained midcomSessionTable. The scalar object midcomSessionIndexNext provides free indices to be used for creating entries in the midcomSessionTable. Without an entry in the midcomSessionTable, no policy rules can be established. The first index element, midcomSessionOwner, of the midcomSessionTable SHOULD uniquely identify an authenticated MIDCOM client. It is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415 [RFC3415], VACM) and allows a management application to identify its entries. The second index element, midcomSessionIndex, enables the same management application to have multiple open sessions. The midcomSessionTable contains the following objects: o midcomSessionOwner This string indicated the user that created and owns the session. It is the firswt index element of this table. All policy rules (and policy rule groups) have the same owner as the Quittek, Stiemerling, Srisuresh [Page 14]
Internet-Draft MIDCOM MIB May 2004 corresponding entry in the midcomSessionTable from which they were created. o midcomSessionIndex The second index element serves for distiguishing different sessions of the same midcomSessionOwner. o midcomSessionRuleGroupIndex The group for which a free index in the policyRuleTable is obtained by reading object midcomSessionRuleNewIndex. This object must be set properly before reading a free index from midcomSessionRuleIndexNext. o midcomSessionRuleIndexNext This object returns a part of an index that is so far unused in the midcomRuleTable. The full unused index is given by the combination of values of the objects midcomSessionOwner and midcomSessionRuleGroupIndex of the same row of the midcomSessionTable in combination with the returned value. o midcomSessionStorageType This object indicates whether or not the session is stored in volatile or non-volatile memory. Depending on the MIDCOM MIB implementation this object may be writable. o midcomSessionRowStatus Writing to this object creates or deletes an entry in the midcomSessionTable, i.e. it opens or terminates a session, respectively. 5.1.2. 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 midcomSessionOwner, midcomGroupIndex and midcomRuleIndex. The midcomSessionOwner is the owner of the session from which the entry was created, the midcomGroupIndex is the index of the group of which the policy rule is a member. midcomSessionOwner is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415 [RFC3415], VACM) and allows a management application to identify its entries. The second index element, midcomSessionIndex, enables the same management application to have multiple open sessions. Entries in this table can only be created after a valid value for the midcomRuleIndex has been read from midcomSessionRuleIndexNext in the corresponding entry of the midcomSessionTable. Entries are removed, Quittek, Stiemerling, Srisuresh [Page 15]
Internet-Draft MIDCOM MIB May 2004 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 midcomSessionOwner 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 will 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 midcomRuleNatService This object indicates which kind of NAT service is requested or established, respectively. Possible NAT services are traditional NAT and twice-NAT. o midcomRuleNatInterface This object indicates an IP interface at which NAT service is requested or performed, respectively. o midcomRuleFlowDirection This object indicates a flow direction for which a policy enable Quittek, Stiemerling, Srisuresh [Page 16]
Internet-Draft MIDCOM MIB May 2004 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 ramnge 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. o midcomRuleRowStatus This object allows entries to be added to the table. 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 [RFCXXXX]. 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 6: Addess tuples A0 - A3 - A0 - internal endpoint: address tuple A0 specifies a communication endpoint of a devices within the - with respect to Quittek, Stiemerling, Srisuresh [Page 17]
Internet-Draft MIDCOM MIB May 2004 the middlebox - internal network. - 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 devices within the - with respect to the middlebox - external network. 5.1.3. midcomGroupTable The midcomGroupTable has an entry per existing polcy rule group. Entries of 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 midcomSessionOwner of the session from which the policies belonging to the group where created and they are indexed by a specific midcomGroupIndex. An entry of the table contains the following objects: o midcomGroupIndex The index of this entry must be unique in combination with the midcomSessionOwner 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 branch contains middlebox capability and configuration information. Some of the contained objects are (optionally) writable and can also be used for configuring the Quittek, Stiemerling, Srisuresh [Page 18]
Internet-Draft MIDCOM MIB May 2004 middlebox service. The capabilities group 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 rules in used firewall implementations. Note that typically, objects in the configuration branch 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 objects in the signaling branch. 5.2.1. Capabilities Information on middlebox capabilites, i.e. capabilities of the MIDCOM MIB implementation, is provided by the midcomCapabilities group 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. Quittek, Stiemerling, Srisuresh [Page 19]
Internet-Draft MIDCOM MIB May 2004 The second object indicates whether or not 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 policy rules can be configured. For a single firewall implementation at a particular IP interface, all MIDCOM 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 The firewall rule group to which all firewall rules of the MIDCOM server are assigned. o midcomConfigFirewallPriority The priority assigned to all firewall rules of the MIDCOM server. 5.3. Monitoring Objects The monitoring branch contains two groups of objects: the resource group and the statistics group. The resource group provides information about which resources are used by which policy rule. The statistics group provide statistics about the usage of objects in the signaling branch. 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 provide by the following objects on NAT binds and NAT sessions may refer to the detailed resource usage description in the NAT-MIB module [RFCXXYY]. Quittek, Stiemerling, Srisuresh [Page 20]
Internet-Draft MIDCOM MIB May 2004 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 The firewall rule for this policy rule. MIDCOM MIB does not mandate a middlebox to implement MIB modules for the functions, such as firewall and NAT, the middlebox may support. The resource identifiers in midcomResourceTable may be vendor proprietary in the cases where the middlebox does not implement the NAT-MIB [RFC XXYY] or a firewall MIB. The MIDCOM MIB 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 capabilites. However, midcomResourceTable is useful for understanding which Quittek, Stiemerling, Srisuresh [Page 21]
Internet-Draft MIDCOM MIB May 2004 resources are affected by which MIDCOM MIB transaction. 5.3.2. midcomStatistics The statistics group contains a set of non-columnar objects that provide 'MIDCOM protocol statistics' i.e. statistics about the usage of objects in the signaling branch. o midcomSessionsRejected MIDCOM agents are required to establish a session prior to any further access to policy rules or groups. This object counts the rejected session establishment requests. o midcomSessionsCurrent This object indicates the total number of current established sessions. o midcomSessionsTotal This object indicates the total number of established sessions current and in the past. o midcomRuleEntriesRejected This object indicates the total number of failed attempts to create an entry in the midcomRuleTable. o midcomRulesIncomplete This object indicates the total number of policy rules that have not been fully loaded into a table row of midcomRuleTable. o midcomReserveRulesIncorrect This object indicates the total number of policy reserve rules that were rejected because the request was incorrect. o midcomReserveRulesRejected This object indicates the total number of policy reserve rules that were failed while being processed. o midcomReserveRulesActive This object indicates the number of currently active policy reserve rules in the midcomRuleTable. o midcomReserveRulesExpired This object indicates the total number of expired policy reserve rules. o midcomReserveRulesTerminatedOnRq This object indicates the total number of policy reserve rules that were terminated on request. Quittek, Stiemerling, Srisuresh [Page 22]
Internet-Draft MIDCOM MIB May 2004 o midcomReserveRulesTerminated This object indicates the total number of policy reserve rules that were terminated, but not on request. o midcomEnableRulesIncorrect This object indicates the total number of policy enable rules that were rejected because the request was incorrect. o midcomEnableRulesRejected This object indicates the total number of policy enable rules that were failed while being processed. o midcomEnableRulesActive This object indicates the number of currently active policy enable rules in the midcomRuleTable. o midcomEnableRulesExpired This object indicates the total number of expired policy enable rules. o midcomEnableRulesTerminatedOnRq This object indicates the total number of policy enable rules that were terminated on request. o midcomEnableRulesTerminated This object indicates the total number of policy enable rules that were terminated, but not on request. o midcomTransactionsRejected This object indicates the total number of rejected transactions. For example, a transaction is rejected when there is no session established for the requesting SNMP manager, i.e. no entry in midcomSessionTable. o midcomTransactionsFailed This object indicates the total number of failed transactions. These transactions were accepted (not rejected), but due to some reason they failed. For instance a transaction consisting of multiple SET operations is only performed with a single SET. o midcomTransactionsCompleted This object indicates the total number of successfully completed transactions at the MIDCOM server. 5.4. Notifications For informing MIDCOM clients about state changes of MIDCOM-MIB implementations, three notifications can be used: Quittek, Stiemerling, Srisuresh [Page 23]
Internet-Draft MIDCOM MIB May 2004 o midcomSessionTermination This notification can be generated for indicating that a session is terminated by the middlebox. o midcomRuleEvent This notification can be generated for indicating the change of a policy rule's state or lifetime. o midcomGroupEvent This notification can be generated for indicating the change of a policy rule group's lifetime. 6. Usage Examples This section presents some examples that explain how a MIDCOM client acting as SNMP manager can use the MIDCOM MIB 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 in [RFCXXXX], a sequence of SNMP operations is described, which realizes the transaction. We consider three different ways, a MIDCOM client can choose to operate on the MIDCOM MIB. The first one is in line with the MIDCOM semantics. It models MIDCOM transactions as described in section 4.2 using SNMP notifications for signaling completion of processing a transaction from the MIDCOM MIB implementation to the MIDCOM client. The second way uses notifications in configuration transactions only in 'unexpected' cases, when a request failes. The third one does not use notifications at all in configuration transaction. We describe the realization of MIDCOM transactions just for the first way of operating on the MIDCOM MIB. For the other two ways, no examples are given, but such can be easily constructed from the examples for the first way. 6.1. Session Establishment (SE) This example explains the steps performed by an SNMP manager to establish a MIDCOM session. 1. The MIDCOM client first checks the middlebox capabilities by reading objects in the midcomCapabilitiesGroup. 2. The MIDCOM client reads the midcomSessionNextIndex object in order to receive an index for creating a session. 3. The manager creates a row in the midcomSessionTable by issuing an SNMP set-request. The midcomSessionRowStatus object is set to createAndWait(5). The new row is indexed by the MIDCOM client's Quittek, Stiemerling, Srisuresh [Page 24]
Internet-Draft MIDCOM MIB May 2004 USM user name and by the index read from the midcomSessionNextIndex object in step 2. 4. If the MIDCOM client wants to have all policy rules it creates to be member of the same particular policy rule group, then the MIDCOM client should set the midcomSessionRuleGroupIndex to the group index that is to be used. 6.2. Session Termination (ST) This example explains the steps performed by an SNMP manager to terminate a MIDCOM session. 1. The manager sends an SNMP set-request to change the midcomSessionRowStatus object to destroy(6). This will remove the row from the midcomSessionTable but not have an effect on entries in the midcomRuleTable created from this session. 6.3. Asynchronous Session Termination (AST) At any time, the MIDCOM MIB implementation may terminate a session. Only two steps are required for performing this transaction. 1. The MIDCOM MIB implementation sends a midcomSessionTermination notification to the SNMP manager owning the session. 2. The MIDCOM MIB implementation removes the corresponding row of the midcomSessionTable. This does not affect entries in other tables. 6.4. Policy Reserve Rule (PRR) This example explains the steps performed by an SNMP manager to establish a policy reserve rule. 1. If the new policy rule should become a member of a particular (existing or not existing) policy rule group, then the SNMP manager sets the midcomSessionGroupIndex object to the index of that group. 2. The SNMP manager reads the midcomSessionRuleNewIndex from an open entry in the modcomSessionTable in order to trigger creation of a new entry in the midcomRuleTable. The new entry in the midcomRuleTable has the following index elements: midcomSessionOwner has the same value as the session from which the value of midcomSessionRuleNewIndex was read; midcomGroupIndex has the value of midcomSessionRuleGroupIndex at the time the value of midcomSessionRuleNewIndex was read; and midcomRuleIndex has the value read from midcomSessionRuleNextIndex. Quittek, Stiemerling, Srisuresh [Page 25]
Internet-Draft MIDCOM MIB May 2004 3. The SNMP manager sets the following objects in the new entry of the midcomRuleTable to specify all request parameters of the PRR transaction: - midcomRuleNatService - midcomRuleNatInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleLifetime Note, that several of these parameters have default values that can be used. 4. The SNMP manager sets the midcomRuleAdminStatus objects in the new row of the midcomRuleTable to reserve(1). 5. The SNMP manager waits for a midcomRuleEvent notification concerning the new policy rule in the midcomSessionTable. 6. After receiving the midcomRuleEvent notification SNMP manager checks the lifetime value carried by the notification. If it is greater than 0, the SNMP manager read all positive reply parameters of the PRR transaction: - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleLifetime If the lifetime equals 0, then SNMP manager reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason. 6.5. Policy Enable Rule (PER) after PRR This example explains the steps performed by an SNMP manager to establish a policy enable rule after a corresponding policy reserve rule was already established. 1. The SNMP manager 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. Quittek, Stiemerling, Srisuresh [Page 26]
Internet-Draft MIDCOM MIB May 2004 2. The SNMP manager sets the midcomRuleAdminStatus objects in the row of the established PRR in the midcomRuleTable to enable(1). 3. The SNMP manager waits for a midcomRuleEvent notification concerning the new row in the midcomSessionTable. 4. After receiving the midcomRuleEvent notification SNMP manager checks the lifetime value carried by the notification. If it is greater than 0, the SNMP manager read all positive reply parameters of the PER transaction: - midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleLifetime If the lifetime equals 0, then SNMP manager reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason. 6.6. Policy Enable Rule (PER) without previous PRR This example explains the steps performed by an SNMP manager to establish a policy enable rule for which no PRR transaction has been performed before. 1. Identical to step 1 for PRR. 2. Identical to step 2 for PRR. 3. The SNMP manager sets the following objects in the new row of the midcomRuleTable to specify all request parameters of the PER transaction: - midcomRuleNatService - midcomRuleNatInterface - midcomRuleFlowDirection - midcomRuleMaxIdleTime - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleLifetime Note, that several of these parameters have default values that can be used. Quittek, Stiemerling, Srisuresh [Page 27]
Internet-Draft MIDCOM MIB May 2004 4. The SNMP manager sets the midcomRuleAdminStatus objects in the new row of the midcomRuleTable to enable(1). 5. Identical to step 6 for PRR. 6. After receiving the midcomRuleEvent notification SNMP manager checks the lifetime value carried by the notification. If it is greater than 0, the SNMP manager read all positive reply parameters of the PRR transaction: - midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleLifetime If the lifetime equals 0, then SNMP manager reads the midcomRuleOperStatus and the midcomRuleError in order to analyze the failure reason. 6.7. Policy Rule Lifetime Change (RLC) This example explains the steps performed by an SNMP manager to change the lifetime of a policy rule. Changing the lifetime to 0 implies terminating the policy rule. 1. The SNMP manager issues a set-request for writing the desired lifetime to the midcomRuleLifetime object in the corresponding row of the midcomRuleTable. 2. The SNMP manager waits for a midcomRuleEvent notification concerning the corresponding row in the midcomRuleTable. 3. After receiving the midcomRuleEvent notification SNMP manager checks the lifetime value carried by the notification. 6.8. 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. 6.9. 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. Quittek, Stiemerling, Srisuresh [Page 28]
Internet-Draft MIDCOM MIB May 2004 6.10. Asynchronous Policy Rule Event (ARE) There are two different triggers for the ARE event. It may be triggered by the expiration of a policy rule's lifetime. But beyond this, the MIDCOM MIB implementation may terminate a policy rule at any time. In both cases two steps are required for performing this transaction: 1. The MIDCOM MIB implementation sends a midcomRuleEvent notification containing a lifetime value of 0 to the SNMP manager owning the session. 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). 6.11. Group Lifetime Change (GLC) This example explains the steps performed by an SNMP manager to change the lifetime of a policy rule group. Changing the lifetime to 0 implies terminating all member policies of the group. 1. The SNMP manager issues a set-request for writing the desired lifetime to the midcomGroupLifetime object in the corresponding row of the midcomGroupTable. 2. The SNMP manager waits for a midcomGroupEvent notification concerning the corresponding row in the midcomGroupTable. 3. After receiving the midcomRuleEvent notification SNMP manager checks the lifetime value carried by the notification. 6.12. 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. 6.13. 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. Quittek, Stiemerling, Srisuresh [Page 29]
Internet-Draft MIDCOM MIB May 2004 7. Definitions MIDCOM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI -- RFC2578 TEXTUAL-CONVENTION, TruthValue, StorageType, RowStatus FROM SNMPv2-TC -- RFC2579 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- RFC2580 SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC3411 InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- RFC 3291 ifIndex FROM IF-MIB -- RFC2863 NatBindIdOrZero FROM NAT-MIB; -- RFCXXYY -- currently from draft-ietf-nat-natmib-09.txt midcomMIB MODULE-IDENTITY LAST-UPDATED "200405041111Z" -- May 5, 2004 ORGANIZATION "IETF Middlebox Communication Working Group" CONTACT-INFO "WG charter: http://www.ietf.org/html.charters/midcom-charter.html Mailing Lists: General Discussion: midcom@ietf.org To Subscribe: midcom-request@ietf.org In Body: subscribe your_email_address Editor: Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Tel: +49 6221 90511-15 Quittek, Stiemerling, Srisuresh [Page 30]
Internet-Draft MIDCOM MIB May 2004 Email: quittek@ccrle.nec.de" DESCRIPTION "This MIB module defines a set of basic objects for configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices. Managed objects defined in this MIB module are structured in three branches: - signaling objects required according to the MIDCOM protocol requirements defined in RFC 3304 and according to the MIDCOM protocol semantics defined in RFC XXXX, - optional configuration objects that can be used for setting parameters of the implementation of objects in the signaling branch, - optional monitoring objects that provide information about used resource and statistics In the signaling objects branch there are four groups of managed objects defined: - objects describing middlebox capabilities in the midcomCapabilities group, - objects modeling MIDCOM sessions in the midcomSessionTable - objects modeling MIDCOM policy rules in the midcomRuleTable - objects modeling MIDCOM policy rule groups in the midcomGroupTable Note that typically, objects in the configuration branch are not intended to be used by MIDCOM clients. In general, access to these objects needs to be restricted more strictly than access to objects in the signaling branch. Copyright (C) The Internet Society (2004). This version of this MIB module is part of RFC yyyy; see the RFC itself for full legal notices." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice REVISION "200405041111Z" -- May 5, 2004 DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this notice ::= { mib-2 44444 } -- 44444 to be assigned by IANA. -- -- main components of this MIB module -- Quittek, Stiemerling, Srisuresh [Page 31]
Internet-Draft MIDCOM MIB May 2004 midcomObjects OBJECT IDENTIFIER ::= { midcomMIB 1 } midcomNotifications OBJECT IDENTIFIER ::= { midcomMIB 2 } midcomConformance OBJECT IDENTIFIER ::= { midcomMIB 3 } -- Signaling objects required according to the MIDCOM -- protocol requirements defined in RFC 3304 and according to -- the MIDCOM protocol semantics defined in RFC XXXX midcomSignaling OBJECT IDENTIFIER ::= { midcomObjects 1 } -- Configuration objects that can be used for retrieving -- middlebox capability information (mandatory) and for -- setting parameters of the implementation of objects in -- the signaling branch (optional) midcomConfig OBJECT IDENTIFIER ::= { midcomObjects 2 } -- Optional monitoring objects that provide information about -- used resource and statistics midcomMonitoring OBJECT IDENTIFIER ::= { midcomObjects 3 } -- -- Signaling Objects -- -- Signaling objects are structured according to the MIDCOM -- protocol semantics into three groups: -- - the session group containing objects that model MIDCOM -- sessions, -- - the policy rules group containing objects that model -- policy rules, and -- - the group group containing objects modeling policy rule -- groups. -- -- Session group -- -- The midcomSessionTable models MIDCOM sessions. -- MIDCOM clients ( = SNMP managers ) that want to -- read, create or modify entries in the midcomRuleTable -- or midcomGroupTable need to have an entry in this table. -- -- The table contains objects identify a destination for -- notifications to be sent to the MIDCOM client. -- Also it serves for creating new rows in the -- midcomRuleTable. -- midcomSessionIndexNext OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only Quittek, Stiemerling, Srisuresh [Page 32]
Internet-Draft MIDCOM MIB May 2004 STATUS current DESCRIPTION "When retrieved, this object returns an unused session index for the SNMP manager that issued the read-request. The returned value can be used for creating a new entry in the midcomSessionTable. A value returned when reading this object is not returned again on subsequent read-requests as long as possible. This ensures that two instances of SNMP managers authenticated as the same manager can independently create sessions without facing race conditions. A MIDCOM MIB implementation SHOULD reject set requests that try to create a row in the midcomSessionTable with an index that was not returned in response to a previous get request for midcomSessionIndexNext." ::= { midcomSignaling 1 } midcomSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists open MIDCOM sessions. The midcomSessionTable models MIDCOM sessions. MIDCOM clients ( = SNMP managers ) that want to read, create or modify entries in the midcomRuleTable or midcomGroupTable need to have an entry in this table. Only SNMP managers for which an entry in this table exists, will receive SNMP notifications concerning policy rule events or policy rule group events. A manager can create a new policy rule of the midcomRuleTable by reading midcomSessionRuleNewIndex in this table. The midcomSessionTable is indexed by its owner identified as SNMP manager, and by a session index that allows distinguishing multiple sessions of the same manager. midcomSessionOwner SHOULD uniquely identify an authenticated MIDCOM client. It is of type SnmpAdminString, that can be trivially mapped to a securityName or groupName as idefined in the View-Based Access Control Model (RFC 3415, VACM) and allows an management application to identify its entries. Quittek, Stiemerling, Srisuresh [Page 33]
Internet-Draft MIDCOM MIB May 2004 A MIDCOM session does exist as long as the corresponding conceptual row in midcomSessionTable is existent. There may exist several different MIDCOM sessions for the same owner; each session is identified by the index of midcomSessionOwner and midcomSessionIndex. MIDCOM clients may terminate a session at any time by writing successfully the value destroy(6) to object midcomSessionRowStatus. Upon this the MIDCOM MIB implementation finishes previous received transaction requests, and removes afterwards the corresponding row from midcomSessionTable for the particular index of midcomSessionOwner and midcomSessionIndex. No further requests for the session closed are accepted and no further asynchronous notifications are sent anymore. MIDCOM MIB implementations may terminate sessions at any time without a prior request of a MIDCOM client. MIDCOM MIB implementations do send an asynchronous session termination (AST) notification to the particular session owner indexed by midcomSessionOwner and midcomSessionIndex. Previous received requests are processed and afterwards the corresponding row in midcomSessionTable is removed. No further requests for the session closed are accepted and no further asynchronous notifications are sent anymore. The same midcomSessionOwner can access entries in midcomRuleTable and midcomGroupTable as long as at least one entry for this particular midcomSessionOwner does exist in midcomSessionTable. Entries in the rule and group table are inaccessible when there is no entry for the owner of them in midcomSessionTable. Note that session termination, either requested or asynchronously, does not affect entries in midcomRuleTable and midcomGroupTable." ::= { midcomSignaling 2 } midcomSessionEntry OBJECT-TYPE SYNTAX MidcomSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular MIDCOM session." INDEX { midcomSessionOwner, midcomSessionIndex } ::= { midcomSessionTable 1 } MidcomSessionEntry ::= SEQUENCE { midcomSessionOwner SnmpAdminString, Quittek, Stiemerling, Srisuresh [Page 34]
Internet-Draft MIDCOM MIB May 2004 midcomSessionIndex Unsigned32, midcomSessionRuleGroupIndex Unsigned32, midcomSessionRuleNewIndex Unsigned32, midcomSessionStorageType StorageType, midcomSessionRowStatus RowStatus } midcomSessionOwner OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The manager who owns this row in the midcomSessionTable. This object SHOULD uniquely identify an authenticated MIDCOM client. It is of type SnmpAdminString, a textual convention that allows for use of the SNMPv3 View-Based Access Control Model (RFC 3415, VACM) and allows an management application to identify its entries." ::= { midcomSessionEntry 1 } midcomSessionIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object allows distinguishing multiple concurrent sessions of the same SNMP manager. Its value needs to be unique per manager." ::= { midcomSessionEntry 2 } midcomSessionRuleGroupIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicated for which policy rule group a policy rule index is generated when object midcomSessionRuleNewIndex is read. If this object is not explicitly set at all, then all policy rules generated from this session will belong to the default group 0. Setting this object to the midcomGroupId of an existing or non-existing group will result in the next policy rule index created by reading objects midcomSessionRuleNewIndex to be generated as member of that group." DEFVAL { 0 } ::= { midcomSessionEntry 3 } Quittek, Stiemerling, Srisuresh [Page 35]
Internet-Draft MIDCOM MIB May 2004 midcomSessionRuleNewIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "Reading this object creates a new entry in the midcomRuleTable. Entries in this table can only be generated by reading this object. The index of the new entry of the midcomRuleTable consists of three elements. The first one is the midcomSession index of the entry at which the value of midcomSessionRuleNewIndex was read. The second index is the current value of midcomSessionRuleGroupIndex in the same entry of the midcomSessionTable. The third element is the value returned then this object is read. If a MIDCOM MIB implementation does not receive a write request to the midcomRuleAdminStatus object of a new created entry in a certain time interval starting a the time of creation, then it MAY remove the entry. This time interval MUST have a length of at least 60 seconds. This procedure for creating entries in the midcomRuleTable ensures that entries are only generated from open sessions." ::= { midcomSessionEntry 4 } midcomSessionStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "When retrieved, this object returns the storage type of the session. Writing to this object can change the storage type of the particular row from volatile(2) to nonVolatile(3) or vice versa. Attempts to set this object to permanent will always fail with an inconsistentValue error. If midcomSessionStorageType has the value permanent(4), then all objects in this row whose MAX-ACCESS value is read-create must be read-only." DEFVAL { volatile } ::= { midcomSessionEntry 5 } midcomSessionRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create Quittek, Stiemerling, Srisuresh [Page 36]
Internet-Draft MIDCOM MIB May 2004 STATUS current DESCRIPTION "A control that allows entries to be added and removed from this table. Attempts to destroy(6) a row or to set a row notInService(2) where the value of the midcomSessionStorageType object is permanent(4) or readOnly(5) will result in an inconsistentValue error. The value of this object has no effect on whether other objects in this conceptual row can be modified." ::= { midcomSessionEntry 6 } -- -- Policy rule group -- -- The midcomRuleTable lists policy rules -- including policy reserve rules and policy enable rules. -- midcomRuleTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists policy rules. It is indexed by the midcomSessionOwner, the midcomGroupIndex and the midcomRuleIndex. This implies that a rule is member of exactly one group and that group membership cannot be changed. Entries in this table can only be created by reading midcomSessionRuleNewIndex. The midcomGroupIndex can be chosen by the manager by setting midcomSessionRuleGroupIndex before reading midcomSessionRuleNewIndex. Entries are deleted by writing to midcomGroupLifetime or midcomRuleLifetime and potentially also to midcomRuleStorageTime. Entries also may be deleted by the MIDCOM MIBs implementation, if for at least 60 seconds after its creation, no write request to object midcomRuleAdminStatus was received. A MIDCOM MIB implmentation MUST ensure that managers can access this table only if they Quittek, Stiemerling, Srisuresh [Page 37]
Internet-Draft MIDCOM MIB May 2004 have a corresponding open session, i.e. a valid row in the midcomSessionTable." ::= { midcomSignaling 3 } midcomRuleEntry OBJECT-TYPE SYNTAX MidcomRuleEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular MIDCOM policy rule." INDEX { midcomSessionOwner, midcomGroupIndex, midcomRuleIndex } ::= { midcomRuleTable 1 } MidcomRuleEntry ::= SEQUENCE { midcomRuleIndex Unsigned32, midcomRuleAdminStatus INTEGER, midcomRuleOperStatus INTEGER, midcomRuleStorageType StorageType, midcomRuleStorageTime Unsigned32, midcomRuleError SnmpAdminString, midcomRuleNatService INTEGER, midcomRuleNatInterface Unsigned32, midcomRuleFlowDirection INTEGER, midcomRuleMaxIdleTime Unsigned32, midcomRuleTransportProtocol Unsigned32, midcomRulePortRange INTEGER, midcomRuleInternalIpVersion InetAddressType, midcomRuleExternalIpVersion InetAddressType, midcomRuleInternalIpAddr InetAddress, midcomRuleInternalIpPrefixLength Unsigned32, midcomRuleInternalPort InetPortNumber, midcomRuleExternalIpAddr InetAddress, midcomRuleExternalIpPrefixLength Unsigned32, midcomRuleExternalPort InetPortNumber, midcomRuleInsideIpAddr InetAddress, midcomRuleInsidePort InetPortNumber, midcomRuleOutsideIpAddr InetAddress, midcomRuleOutsidePort InetPortNumber, midcomRuleLifetime Unsigned32 } midcomRuleIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The value of this object must be unique in combination with the values of the objects midcomSessionOwner and midcomGroupIndex in this row. Quittek, Stiemerling, Srisuresh [Page 38]
Internet-Draft MIDCOM MIB May 2004 Allowed values for this index must be read from the midcomSessionTable. The MIDCOM MIB implementation SHOULD ensure that new row can only be generated for values of this index (in combination with midcomSessionOwner and midcomGroupIndex) that have been read from midcomSessionRuleNewIndex." ::= { midcomRuleEntry 3 } midcomRuleAdminStatus OBJECT-TYPE SYNTAX INTEGER { reserve(1), enable(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object indicates the desired status of the policy rule. See the definition of midcomRuleOperStatus for a description of the values. When the midcomRuleAdminStatus object is set, then the MIDCOM MIB implementation will try to read the respective relvant objects of the entry and try to achieve the corresponding midcomRuleOperStatus. Depending on whether the midcomRuleAdminStatus is set to reserve(1) or enable(2) several objects must be set in advance. They serve as parameters of the policy rule to be established When object midcomRuleAdminStatus is set to reserve(1), then the following objects in the same entry are of relevance: - midcomRuleNatService - midcomRuleNatInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleLifetime When object midcomRuleAdminStatus is set to enable(2), then the following objects in the same entry are of relevance: - midcomRuleNatInterface - midcomRuleFlowDirection - midcomRuleMaxIdleTime Quittek, Stiemerling, Srisuresh [Page 39]
Internet-Draft MIDCOM MIB May 2004 - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleLifetime When retrieved, the object returns the last set value. If no value has been set, it returns one of the two possible values." ::= { midcomRuleEntry 4 } midcomRuleOperStatus OBJECT-TYPE SYNTAX INTEGER { newEntry(1), setting(2), checkingRequest(3), incorrectRequest(4), processingRequest(5), requestRejected(6), reserved(7), enabled(8), timedOut(9), terminatedOnRequest(10), terminated(11), genericError(12) } MAX-ACCESS read-only STATUS current DESCRIPTION "The actual status of the policy rule. The midcomRuleOperStatus object may have the following values: - newEntry(1) indicates that the entry in the midcomRuleTable was created, but not modified yet. Such an entry needs to be filled with values specifying a request first. - setting(2) indicates that the entry has been already modified after generating it, but no request was made yet. - checkingRequest(3) indicates that midcomRuleAdminStatus has recently been set and that the MIDCOM MIB implementation is currently checking the parameters of Quittek, Stiemerling, Srisuresh [Page 40]
Internet-Draft MIDCOM MIB May 2004 the request. This is a transient state. The value of this object will change to either incorrectRequest(4) or processingRequest(5) without any external interaction. A MIDCOM MIB implementation MAY return this value while checking request parameters. - incorrectRequest(4) indicates that checking a request resulted in detecting an incorrect value in one of the objects containing request parameters. The failure reason is indicated by the value of midcomRuleError. - processingRequest(5) indicates that midcomRuleAdminStatus has recently been set and that the MIDCOM MIB implementation is currently processing the request and trying to configure the middlebox accordingly. This is a transient state. The value of this object will change to either requestRejected(6), reserved(7) or enabled(8) without any external interaction. A MIDCOM MIB implementation MAY return this value while processing a request. - requestRejected(6) indicates that a request to establish a policy rule specified by the entry was rejected. The reason of rejection is indicated by the value of midcomRuleError. - reserved(7) indicates that the entry describes an established policy reserve rule. These values of MidcomRuleEntry can be retrieved for a reserved policy rule: - midcomRuleNatService - midcomRuleNatInterface - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleLifetime - enabled(8) indicates that the entry describes an established policy enable rule. These values of MidcomRuleEntry can be retrieved for an enabled policy rule - midcomRuleNatService - midcomRuleNatInterface - midcomRuleFlowDirection Quittek, Stiemerling, Srisuresh [Page 41]
Internet-Draft MIDCOM MIB May 2004 - midcomRuleMaxIdleTime - midcomRuleTransportProtocol - midcomRulePortRange - midcomRuleInternalIpVersion - midcomRuleExternalIpVersion - midcomRuleInternalIpAddr - midcomRuleInternalIpPrefixLength - midcomRuleInternalPort - midcomRuleExternalIpAddr - midcomRuleExternalIpPrefixLength - midcomRuleExternalPort - midcomRuleInsideIpAddr - midcomRuleInsidePort - midcomRuleOutsideIpAddr - midcomRuleOutsidePort - midcomRuleLifetime - timedOut(9) indicates that the lifetime of a previously established policy rule is expired and that the policy rule is terminated for this reason. - terminatedOnRequest(10) indicates that a previously established policy rule was terminated by an SNMP manager setting the midcomRuleLifetime to 0 or setting midcomGroupLifetime to 0. - terminated(11) indicates that a previously established policy rule was terminated by the MIDCOM MIB implementation for another reason than lifetime expiration or an explicit request from an SNMP manager. - genericError(12) indicates that the policy rule specified by the entry is not established due to an error condition not listed above. The states timedOut(9), terminatedOnRequest(10) and terminated(11) are referred to as termination states. The states incorrectRequest(4), requestRejected(6) and genericError(12) are referred to as error states. The checkingRequest(3) and processingRequest(4) states are transient states which will either lead to one of the error states or the reserved(7) state or the enabled(8) states. MIDCOM MIB implementations MAY return these values when checking or processing requests." DEFVAL { newEntry } ::= { midcomRuleEntry 5 } Quittek, Stiemerling, Srisuresh [Page 42]
Internet-Draft MIDCOM MIB May 2004 midcomRuleStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-write STATUS current DESCRIPTION "When retrieved, this object returns the storage type of the policy rule. Writing to this object can change the storage type of the particular row from volatile(2) to nonVolatile(3) or vice versa. Attempts to set this object to permanent will always fail with an inconsistentValue error. If midcomRuleStorageType has the value permanent(4), then all objects in this row whose MAX-ACCESS value is read-write must be read-only." DEFVAL { volatile } ::= { midcomRuleEntry 6 } midcomRuleStorageTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object specifies how long this row can exist in the midcomRuleTable after the midcomRuleOperState switched to a termination state or to an error state. This object returns the remaining time that the row may exist before it is aged out. The object is initialized with the value of the associated midcomSessionStorageTime object. After expiration or termination of the context, the value of this object ticks backwards. The entry in the midcomRuleTable is destroyed when the value reaches 0. The value of this object may be set in order to increase or reduce the remaining time that the row may exist. Setting the value to 0 will destroy this entry as soon as the midcomRuleOperState switched to a termination state or to an error state. Note that there is no guarantee that the row is stored as long as this object indicates. At any time, the MIDCOM MIB implementation may decide to remove a row describing a terminated policy rule before the storage time of the corresponding row in the midcomRuleTable reaches the value of 0. In this case the information stored in this Quittek, Stiemerling, Srisuresh [Page 43]
Internet-Draft MIDCOM MIB May 2004 row is not anymore available." DEFVAL { 0 } ::= { midcomRuleEntry 7 } midcomRuleError OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a descriptive error message if the transition into the operational status reserved(7) or enabled(8) failed. Implementations must reset the error message to a zero-length string when a new attempt to change the policy rule status to reserved(7) or enabled(8) is started. RECOMMENDED values to be returned in particular cases include - 'lack of IP addresses' - 'lack of port numbers' - 'lack of resources' - 'specified NAT interface does not exist' - 'specified NAT interface does not support NAT' - 'conflict with already existing policy rule' - 'no internal IP wildcarding allowed' - 'no external IP wildcarding allowed'" DEFVAL { ''H } ::= { midcomRuleEntry 8 } midcomRuleNatService OBJECT-TYPE SYNTAX INTEGER { any(1), traditionalNat(2), twiceNat(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates a kind of NAT service. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to request its preference concerning the NAT service. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an inconsistentValue error. Quittek, Stiemerling, Srisuresh [Page 44]
Internet-Draft MIDCOM MIB May 2004 If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates which NAT service is performed for this rule. If not NAT service is required for enforcing the policy rule, then the value of this object is any(1). If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { any } ::= { midcomRuleEntry 9 } midcomRuleNatInterface OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "This object indicates an IP interface at which NAT service is requested, or performed. The interface is identified by its index in the ifTable (see IF-MIB in RFC2863). If the object has a value of 0, then no particular interface is indicated. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to request its preference concerning the interface at which it requests NAT service. The default value of 0 indicates that the manager does not have a preferred interface or does not have sufficient topology information for specifying one. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates the interface at which NAT service for this rule is performed. If not NAT service is required for enforcing the policy rule, then the value of this object is 0. Also if the MIDCOM MIB implementation cannot indicate an interface, because it does not have this information or because NAT service is not offered at a particular single interface, then the value of the object is 0. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." Quittek, Stiemerling, Srisuresh [Page 45]
Internet-Draft MIDCOM MIB May 2004 DEFVAL { 0 } ::= { midcomRuleEntry 10 } midcomRuleFlowDirection OBJECT-TYPE SYNTAX INTEGER { inbound(1), outbound(2), biDirectional(3) } MAX-ACCESS read-write STATUS current DESCRIPTION "This parameter specifies the direction of enabled communication, either inbound(1), outbound(2), or biDirectional(3). The semantics of this object depends on the protocol the rule relates to. If the rule is independent of the transport protocol (midcomRuleTransportProtocol has value of 0) or if the transport protocol is UDP, then the value of midcomRuleFlowDirection indicates the direction of packets traversing the middlebox. In this case, value inbound(1) indicates that packets are traversing from outside to inside, value outbound(2) indicates that packets are traversing from inside to outside. For both values, inbound(1) and outbound(2) packets can traverse the middelbox only uni-directional. A bi-directional flow is indicated by value biDirectional(3). If the transport protocol is TCP, the packet flow is always bi-directional, but the value of midcomRuleFlowDirection indicates that: - inbound(1): bi-directional TCP packet flow. First packet, with TCP SYN flag set, must arrive at an outside interface of the middlebox. - outbound(2): bi-directional TCP packet flow. First packet, with TCP SYN flag set, must arrive at an inside interface of the middlebox. - biDirectional(3): bi-directional TCP packet flow. First packet, with TCP SYN flag set, may arrive at an inside or an outside interface of the middlebox. This object is used as input to a request for establishing a policy enable rule as well as for indicating the properties of an established policy rule. Quittek, Stiemerling, Srisuresh [Page 46]
Internet-Draft MIDCOM MIB May 2004 If object midcomRuleOperStatus of the same entry has a value of either newEntry(1), setting(2) or reserved(7), then this object can be written by a manager in order to specify a requested direction to be enabled by a policy rule. Writing to this object in any state other than newEntry(1), setting(2) or reserved(7) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object indicates the enabled flow direction. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." ::= { midcomRuleEntry 11 } midcomRuleMaxIdleTime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "Maximum idle time of the policy rule in seconds. If no packet to which the policy rule applies passes the middlebox for the specified midcomRuleMaxIdleTime, then the policy rule enters the termination state timedOut(9). A value of 0 indicates that the policy does not time out if it is idle. This object is used as input to a request for establishing a policy enable rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has a value of either newEntry(1), setting(2) or reserved(7), then this object can be written by a manager in order to specify a maximum idle time for the policy rule to be requested. Writing to this object in any state other than newEntry(1), setting(2) or reserved(7) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object indicates the maximum idle time of the policy rule. Note that even if a maximum idle time greater than zero was requested, the middlebox may not be able to support maximum idle times and set the value of thie object to zero when entering state enabled(8). Quittek, Stiemerling, Srisuresh [Page 47]
Internet-Draft MIDCOM MIB May 2004 If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { 0 } ::= { midcomRuleEntry 12 } midcomRuleTransportProtocol OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-write STATUS current DESCRIPTION "The transport protocol. Valid values for midcomRuleTransportProtocol are the onces defined at: http://www.iana.org/assignments/protocol-numbers This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has a value of either newEntry(1) or setting(2), then this object can be written by a manager in order to specify a requested transport protocol. If translation of a full IP address is requested, then this object must have the default value 0. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates which transport protocol is enforced by this policy rule. A value of 0 indicates a rule acting on IP addresses only. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { 0 } ::= { midcomRuleEntry 13 } midcomRulePortRange OBJECT-TYPE SYNTAX INTEGER { single(1), pair(2) } MAX-ACCESS read-write STATUS current DESCRIPTION Quittek, Stiemerling, Srisuresh [Page 48]
Internet-Draft MIDCOM MIB May 2004 "The range of port numbers. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. It is relevant to the operation of the MIDCOM MIB implementation only if the value of object midcomTransportProtocol in the same entry has a value other than 0. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the requested size of the port range. With single(1) just a single port number is requested, with pair(2) a consecutive pair of port numbers is requested with the lower number being even. Requestimng the a consecutive pair of port numbers is required for supporting the RTP and RTCP protocols, see RFC1889. Writing to this object in any state other than newEntry(1), setting(2) or reserved(7) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8), then this object will have the value which it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { single } ::= { midcomRuleEntry 14} midcomRuleInternalIpVersion OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "IP version of the internal address (A0) and the inside address (A1). Allowed values are ipv4(1) and ipv6(2). This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the IP version reuqired at the inside of the middlebox. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an inconsistentValue error. Quittek, Stiemerling, Srisuresh [Page 49]
Internet-Draft MIDCOM MIB May 2004 If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates the internal/inside IP version. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { ipv4 } ::= { midcomRuleEntry 15 } midcomRuleExternalIpVersion OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-write STATUS current DESCRIPTION "IP version of the external address (A3) and the outside address (A2). Allowed values are ipv4(1) and ipv6(2). This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the IP version reuqired at the outside of the middlebox. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object indicates the external/outside IP version. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { ipv4 } ::= { midcomRuleEntry 16 } midcomRuleInternalIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The internal IP address. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. Quittek, Stiemerling, Srisuresh [Page 50]
Internet-Draft MIDCOM MIB May 2004 If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the internal IP address for which a reserve policy rule or a enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object will have the value which it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." ::= { midcomRuleEntry 17 } midcomRuleInternalIpPrefixLength OBJECT-TYPE SYNTAX Unsigned32 (0..128) MAX-ACCESS read-write STATUS current DESCRIPTION "The prefix length of the internal IP address used for wildcarding. A value of 0 indicates a full wildcard; in this case the value of midcomRuleInternalIpAddr is irrelevant. If midcomRuleInternalIpVersion has a value of ipv4(1) then a value > 31 indicates no wildcarding at all. If midcomRuleInternalIpVersion has a value of ipv4(2) then a value > 127 indicates no wildcarding at all. A MIDCOM MIB implementation that does not support IP address wildcarding MUST implement this object as read-only with a value of 128. A MIDCOM that does not support wildcarding based on prefix length MAY restrict allowed values for this object to 0 and 128. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the internal IP address for which a reserve policy rule or a enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object will Quittek, Stiemerling, Srisuresh [Page 51]
Internet-Draft MIDCOM MIB May 2004 have the value which it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { 128 } ::= { midcomRuleEntry 18 } midcomRuleInternalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-write STATUS current DESCRIPTION "The internal port number. A value of 0 is a wildcard. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. It is relevant to the operation of the MIDCOM MIB implementation only if the value of object midcomTransportProtocol in the same entry has a value other than 0. If object midcomRuleOperStatus of the same entry has the value newEntry(1) or setting(2), then this object can be written by a manager in order to specify the port number for which a reserve policy rule or a enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1) or setting(2) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value reserved(7) or enabled(8), then this object will have the value which it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { 0 } ::= { midcomRuleEntry 19 } midcomRuleExternalIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The external IP address. This object is used as input to a request for establishing Quittek, Stiemerling, Srisuresh [Page 52]
Internet-Draft MIDCOM MIB May 2004 a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1), setting(2) or reserved(7), then this object can be written by a manager in order to specify the external IP address for which an enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1), setting(2) or reserved(7) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object will have the value which it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." ::= { midcomRuleEntry 20 } midcomRuleExternalIpPrefixLength OBJECT-TYPE SYNTAX Unsigned32 (0..128) MAX-ACCESS read-write STATUS current DESCRIPTION "The prefix length of the external IP address used for wildcarding. A value of 0 indicates a full wildcard; in this case the value of midcomRuleExternalIpAddr is irrelevant. If midcomRuleExternalIpVersion has a value of ipv4(1) then a value > 31 indicates no wildcarding at all. If midcomRuleExternalIpVersion has a value of ipv4(2) then a value > 127 indicates no wildcarding at all. A MIDCOM MIB implementation that does not support IP address wildcarding MUST implement this object as read-only with a value of 128. A MIDCOM that does not support wildcarding based on prefix length MAY restrict allowed values for this object to 0 and 128. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has the value newEntry(1), setting(2) or reserved(7), then this object can be written by a manager in order to specify the external IP address for which an enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1), setting(2) or reserved(7) will always fail with an inconsistentValue error. Quittek, Stiemerling, Srisuresh [Page 53]
Internet-Draft MIDCOM MIB May 2004 If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object will have the value which it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { 128 } ::= { midcomRuleEntry 21 } midcomRuleExternalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-write STATUS current DESCRIPTION "The external port number. A value of 0 is a wildcard. This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. It is relevant to the operation of the MIDCOM MIB implementation only if the value of object midcomTransportProtocol in the same entry has a value other than 0. If object midcomRuleOperStatus of the same entry has the value newEntry(1), setting(2) or reserved(7), then this object can be written by a manager in order to specify the external port number for which an enable policy rule is requested to be established. Writing to this object in any state other than newEntry(1), setting(2) or reserved(7) will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has the value enabled(8), then this object will have the value which it had before the transition to this state. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { 0 } ::= { midcomRuleEntry 22 } midcomRuleInsideIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The inside IP address at the middlebox. This the value of this object is relevant only if Quittek, Stiemerling, Srisuresh [Page 54]
Internet-Draft MIDCOM MIB May 2004 object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8)." ::= { midcomRuleEntry 23 } midcomRuleInsidePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The inside port number at the middlebox. A value of 0 is a wildcard. This the value of this object is relevant only if object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8)." ::= { midcomRuleEntry 24 } midcomRuleOutsideIpAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The outside IP address at the middlebox. This the value of this object is relevant only if object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8)." ::= { midcomRuleEntry 25 } midcomRuleOutsidePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The outside port number at the middlebox. A value of 0 is a wildcard. This the value of this object is relevant only if object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8)." ::= { midcomRuleEntry 26 } midcomRuleLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The remaining lifetime in seconds of this policy rule. Quittek, Stiemerling, Srisuresh [Page 55]
Internet-Draft MIDCOM MIB May 2004 Lifetime of a policy rule starts when object midcomRuleOperStatus in the same entry enters either state reserved(7) or state enabled(8). This object is used as input to a request for establishing a policy rule as well as for indicating the properties of an established policy rule. If object midcomRuleOperStatus of the same entry has a value of either newEntry(1) or setting(2), then this object can be written by a manager in order to specify the requested lifetime of a policy rule to be established. If object midcomRuleOperStatus of the same entry has a value of either reserved(7) or enabled(8), indicates the (continuously decreasing) remaining lifetime of the established policy rule. Note that when entering state reserved(7) or enabled(8), the MIDCOM MIB implementation can choose a lifetime shorter than the one requested. Unlike other parameters of the policy rule, this parameter can still be written in state reserved(7) and enabled(8). Writing to this object is processed by the MIDCOM MIB implementation by choosing a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the MIDCOM MIB implementation at session startup: 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) whereas: - lt_granted is the actually granted lifetime by the MIDCOM MIB implementation - lt_requested is the requested lifetime of the MIDCOM client - lt_maximum is the maximum lifetime specified at session setup SNMP set requests to this object may be rejected or the value of the object after an accepted set operation may be less than the value that was contained in the SNMP set request. Successfully writing a value of 0 terminates the policy rule. Note that after a policy rule is terminated, still the entry will exist as long as indicated by the value of midcomRuleStorageTime. Writing to this object in any state other than newEntry(1), setting(2), reserved(7) or enabled(7) Quittek, Stiemerling, Srisuresh [Page 56]
Internet-Draft MIDCOM MIB May 2004 will always fail with an inconsistentValue error. If object midcomRuleOperStatus of the same entry has a value other than newEntry(1), setting(2), reserved(7) or enabled(8), then the value of this object is irrelevant." DEFVAL { 180 } ::= { midcomRuleEntry 27 } -- -- Policy rule group group -- -- The midcomGroupTable lists all current policy rule groups. -- midcomGroupTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all current policy rule groups. Entries in this table are created implicitely when entries in the midcomRuleTable are created. Like the midcomSessionTable and the midcomRuleTable, this table is indexed by an owner and an index that is unique per owner. The table serves for listing the existing groups and their remaining lifetimes and for changing lifetimes of groups and implicitly of all group members. Groups and all their member policy rules can be deleted by setting midcomGroupLifetime to 0." ::= { midcomSignaling 4 } midcomGroupEntry OBJECT-TYPE SYNTAX MidcomGroupEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular MIDCOM session." INDEX { midcomSessionOwner, midcomGroupIndex } ::= { midcomGroupTable 1 } MidcomGroupEntry ::= SEQUENCE { midcomGroupIndex Unsigned32, midcomGroupLifetime Unsigned32 } midcomGroupIndex OBJECT-TYPE Quittek, Stiemerling, Srisuresh [Page 57]
Internet-Draft MIDCOM MIB May 2004 SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of this group for the midcomSessionOwner. A group is identified by the combination of midcomSessionOwner and midcomGroupIndex. The value of this index must be unique per midcomSessionOwner." ::= { midcomGroupEntry 2 } midcomGroupLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "When retrieved, this object delivers the the maximum lifetime in seconds of all member rules of this group, i.e. of all rows in the midcomRuleTable that have the same values for midcomSessionOwner and midcomGroupIndex. Successfully writing to this object modifies the lifetime of all member policies. Successfully writing a value of 0 terminates all member policies and implicitly deletes the group as soon as all member entries are removed from the midcomRuleTable. Note that after a group's lifetime is expired or is set to 0, still the corresponding entry in the midcomGroupTable will exist as long as terminated member policy rules are stored as entries in the midcomRuleTable. Writing to this object is processed by the MIDCOM MIB implementation by choosing a lifetime value that is greater than zero and less than or equal to the minimum of the requested value and the maximum lifetime specified by the MIDCOM MIB implementation at session startup: 0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum) whereas: - lt_granted is the actually granted lifetime by the MIDCOM MIB implementation - lt_requested is the requested lifetime of the MIDCOM client - lt_maximum is the maximum lifetime specified at session setup Quittek, Stiemerling, Srisuresh [Page 58]
Internet-Draft MIDCOM MIB May 2004 SNMP set requests to this object may be rejected or the value of the object after an accepted set operation may be less than the value that was contained in the SNMP set request." ::= { midcomGroupEntry 3 } -- -- Configuration Objects -- -- Configuration objects that can be used for retrieving -- middlebox capability information (mandatory) and for -- setting parameters of the implementation of objects in -- the signaling branch (optional). -- -- Note that typically, objects in the configuration branch -- 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 objects in the signaling branch. -- -- -- Capabilities Group -- -- This group contains objects to which MIDCOM clients should -- have read access. -- midcomConfigMaxLifetime OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "When retrieved, this object returns the maximum lifetime in seconds, that this middlebox allows policy rules to have." ::= { midcomConfig 1 } midcomConfigPersistentRules OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "When retrieved, this object returns true(1) if the MIDCOM-MIB implementation can store policy rules persistently. Otherwise, it returns false(2)." ::= { midcomConfig 2 } Quittek, Stiemerling, Srisuresh [Page 59]
Internet-Draft MIDCOM MIB May 2004 midcomConfigIfTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomConfigIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table capabilities of the MIDCOM-MIB implementation per IP interface. It is indexed by ifIndex. If an entry with ifIndex = 0 occurs, then bits set in objects of this entry apply to all interfaces." ::= { midcomConfig 3 } midcomConfigIfEntry OBJECT-TYPE SYNTAX MidcomConfigIfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing The capabilites of a middlebox with respect to the indexed IP interface." INDEX { ifIndex } ::= { midcomConfigIfTable 1 } MidcomConfigIfEntry ::= SEQUENCE { midcomConfigIfBits BITS, midcomConfigIfEnabled TruthValue } midcomConfigIfBits OBJECT-TYPE SYNTAX BITS { ipv4(0), ipv6(1), addressWildcards(2), portWildcards(3), firewall(4), nat(5), portTranslation(6), protocolTranslation(7), twiceNat(8), inside(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "When retrieved, this object returns a set of bits indicating the capabilities (or configuration) of the middlebox with repect to the referenced IP interface. If the index equals 0, then all set bits apply to all interfaces. Quittek, Stiemerling, Srisuresh [Page 60]
Internet-Draft MIDCOM MIB May 2004 If the ipv4(0) bit is set, then the middlebox supports IPv4 at the indexed IP interface. If the ipv6(1) bit is set, then the middlebox supports IPv6 at the indexed IP interface. If the addressWildcards(2) bit is set, then the middlebox supports IP address wildcarding at the indexed IP interface. If the portWildcards(3) bit is set, then the middlebox supports port wildcarding at the indexed IP interface. If the firewall(4) bit is set, then the middlebox offers firewall functionality at the indexed interface. If the nat(5) bit is set, then the middlebox offers network address translation service at the indexed interface. If the portTranslation(6) bit is set, then the middlebox offers port translation service at the indexed interface. This bit is only relevant if nat(5) is set. If the protocolTranslation(7) bit is set, then the middlebox offers protocol translation service between IPv4 and IPv6 at the indexed interface. This bit is only relevant if nat(5) is set. If the twiceNat(8) bit is set, then the middlebox offers twice network address translation service at the indexed interface. This bit is only relevant if nat(5) is set. If the inside(9) bit is set, then the indexed interface is an inside interface with respect to NAT functionality. Otherwise, it is an outside interface. This bit is only relevant if nat(5) is set." ::= { midcomConfigIfEntry 2 } midcomConfigIfEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The value of this object indicates the availability of the middlebox service described by midcomCapabilitiesBits at the indexed IP interface. By writing to this object, the MIDCOM support for the Quittek, Stiemerling, Srisuresh [Page 61]
Internet-Draft MIDCOM MIB May 2004 entire IP interface can be switched on or off. Setting this object to false(2) immeadiately stops middlebox support at the indexed IP interface. This implies that all policy rules that use NAT or firewall resources at the indexed IP interface are terminated immediately. In this case, The midcom agent MUST send notifications to all MIDCOM clients with open sessions that have access to one of the terminated rules." DEFVAL { true } ::= { midcomConfigIfEntry 3 } -- -- Firewall Group -- -- This group contains the firewall configuration table -- midcomConfigFirewallTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomConfigFirewallEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the firewall configuration per IP interface. It can be used for configuring configuring how policy rules created by MIDCOM clients are realized as firewall rules of a firewall implementation. Particularly, the priority used for MIDCOm policy rules can be configured. For a single firewall implementation at a particular IP interface, all MIDCOM 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." ::= { midcomConfig 4 } midcomConfigFirewallEntry OBJECT-TYPE SYNTAX MidcomConfigFirewallEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular set of firewall resources." INDEX { ifIndex } ::= { midcomConfigFirewallTable 1 } MidcomConfigFirewallEntry ::= SEQUENCE { midcomConfigFirewallGroupId SnmpAdminString, midcomConfigFirewallPriority Unsigned32 -- Wes, what should be here? Quittek, Stiemerling, Srisuresh [Page 62]
Internet-Draft MIDCOM MIB May 2004 } midcomConfigFirewallGroupId OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "The firewall rule group to which all firewall rules of the MIDCOM server are assigned." ::= { midcomConfigFirewallEntry 2 } midcomConfigFirewallPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The priority assigned to all firewall rules of the MIDCOM server." ::= { midcomConfigFirewallEntry 3 } -- -- Monitoring Objects -- -- Monitoring objects are structured into two groups, -- the midcomResourceGroup providing infomation about used -- resources and the midcomStatisticsGroup providing information -- about MIDCOM signaling statistics. -- -- Resources group -- -- The MIDCOM resources group contains a set of managed -- objects describing the currently used resources of NAT -- and firewall implementations. -- -- -- Textual conventions for objects of the resource group -- MidcomNatBindMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An indicator of the kind of NAT resources used by a policy rule. This definition corresponds to the definition of NatBindMode in the NAT-MIB (RFCXXXX). Value none(3) can be used to indicate that the policy rule does not use any NAT binding. " Quittek, Stiemerling, Srisuresh [Page 63]
Internet-Draft MIDCOM MIB May 2004 SYNTAX INTEGER { addressBind(1), addressPortBind(2), none(3) } MidcomNatSessionIdOrZero ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique ID that is assigned to each NAT session by a NAT implementation. This definition corresponds to the definition of NatSessionId in the NAT-MIB (RFCXXXX). Value 0 can be used to indicate that policy rule does not use any NAT binding" SYNTAX Unsigned32 -- -- The MIDCOM resource table -- midcomResourceTable OBJECT-TYPE SYNTAX SEQUENCE OF MidcomResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all used middlebox resources per MIDCOM policy rule. The midcomResourceTable is indexed by session owner, group index, rule index. " ::= { midcomMonitoring 1 } midcomResourceEntry OBJECT-TYPE SYNTAX MidcomResourceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular set of middlebox resources." INDEX { midcomSessionOwner, midcomGroupIndex, midcomRuleIndex } ::= { midcomResourceTable 1 } MidcomResourceEntry ::= SEQUENCE { midcomRscNatInternalAddrBindMode MidcomNatBindMode, midcomRscNatInternalAddrBindId NatBindIdOrZero, midcomRscNatExternalAddrBindMode MidcomNatBindMode, midcomRscNatExternalAddrBindId NatBindIdOrZero, midcomRscNatSessionId1 MidcomNatSessionIdOrZero, Quittek, Stiemerling, Srisuresh [Page 64]
Internet-Draft MIDCOM MIB May 2004 midcomRscNatSessionId2 MidcomNatSessionIdOrZero, midcomRscFirewallRuleId Unsigned32 -- more input required on firewall resource information. } midcomRscNatInternalAddrBindMode OBJECT-TYPE SYNTAX MidcomNatBindMode MAX-ACCESS read-only STATUS current DESCRIPTION "An indication whether this policy rule uses an address NAT bind or an address-port NAT bind for binding the internal address." ::= { midcomResourceEntry 4 } midcomRscNatInternalAddrBindId OBJECT-TYPE SYNTAX NatBindIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object references to the allocated internal NAT bind that is used by this policy rule. A NAT bind describes the mapping of internal addresses to outside addresses. MIDCOM MIB implementations can read this object to learn the corresponding NAT bind resource for this particular policy rule." ::= { midcomResourceEntry 5 } midcomRscNatExternalAddrBindMode OBJECT-TYPE SYNTAX MidcomNatBindMode MAX-ACCESS read-only STATUS current DESCRIPTION "An indication whether this policy rule uses an address NAT bind or an address-port NAT bind for binding the external address." ::= { midcomResourceEntry 6 } midcomRscNatExternalAddrBindId OBJECT-TYPE SYNTAX NatBindIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object references to the allocated external NAT bind that is used by this policy rule. A NAT bind describes the mapping of external addresses to inside addresses. MIDCOM MIB implementations can read this object to learn the corresponding NAT bind resource for this particular policy rule." ::= { midcomResourceEntry 7 } Quittek, Stiemerling, Srisuresh [Page 65]
Internet-Draft MIDCOM MIB May 2004 midcomRscNatSessionId1 OBJECT-TYPE SYNTAX MidcomNatSessionIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object references to the first allocated NAT session for this policy rule. MIDCOM MIB implementations can read this object to learn whether a NAT session for a particular policy rule is used or not. A value of 0 means that no NAT session is allocated for this policy rule. A value other than 0 references to the NAT session." ::= { midcomResourceEntry 8 } midcomRscNatSessionId2 OBJECT-TYPE SYNTAX MidcomNatSessionIdOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This object references to the first allocated NAT session for this policy rule. MIDCOM MIB implementations can read this object to learn whether a NAT session for a particular policy rule is used or not. A value of 0 means that no NAT session is allocated for this policy rule. A value other than 0 references to the NAT session." ::= { midcomResourceEntry 9 } midcomRscFirewallRuleId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object references to the allocated firewall rule in the firewall engine for this policy rule. MIDCOM MIB implementations can read this value to learn whether a firewall rule for this particular policy rule is used or not. A value of 0 means that no firewall rule is allocated for this policy rule. A value other than 0 references to the firewall rule number within the firewall engine." ::= { midcomResourceEntry 10 } -- -- Statistics group -- -- The MIDCOM statistics group contains a set of managed -- objects providing statistics about the usage of objects -- in the signaling branch. -- Quittek, Stiemerling, Srisuresh [Page 66]
Internet-Draft MIDCOM MIB May 2004 midcomStatistics OBJECT IDENTIFIER ::= { midcomMonitoring 2 } midcomSessionsRejected OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of rejected MIDCOM sessions. The MIDCOM MIB module can rejected sessions that are not authorized or unknown." ::= { midcomStatistics 1 } midcomSessionsCurrent OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently established MIDCOM sessions. This object equals the number of rows in the midcomSessionTable and gives the number of MIDCOM clients (=SNMP managers) that are allowed to read, create, or modify entries in the MIDCOM MIB module." ::= { midcomStatistics 2 } midcomSessionsTotal OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The summarized number of all current and past established MIDCOM sessions." ::= { midcomStatistics 3 } midcomRuleEntriesRejected OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of failed attempts to create an entry in the midcomRuleTable." ::= { midcomStatistics 4 } midcomRulesIncomplete OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION Quittek, Stiemerling, Srisuresh [Page 67]
Internet-Draft MIDCOM MIB May 2004 "The total number of policy rules that are incomplete. Policy rules are loaded via row entries in midcomRuleTable. This object counts policy rules that are loaded but not fully specified, i.e. the associated action (reserved or enable) is not set. Those rule are typically removed after sometime and counted." ::= { midcomStatistics 5 } midcomReserveRulesIncorrect OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy reserve rules that failed parameter check and entered state incorrectRequest(4)." ::= { midcomStatistics 6 } midcomReserveRulesRejected OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy reserve rules that failed while being processed and entered state requestRejected(6)." ::= { midcomStatistics 7 } midcomReserveRulesActive OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active policy reserve rules." ::= { midcomStatistics 8 } midcomReserveRulesExpired OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of expired policy reserve rules (entered termination state timedOut(9))." ::= { midcomStatistics 9 } midcomReserveRulesTerminatedOnRq OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current Quittek, Stiemerling, Srisuresh [Page 68]
Internet-Draft MIDCOM MIB May 2004 DESCRIPTION "The total number of policy reserve rules that were terminated on request (entered termination state terminatedOnRequest(10))." ::= { midcomStatistics 10 } midcomReserveRulesTerminated OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy reserve rules that were terminated, but not on request. (entered termination state terminated(11))." ::= { midcomStatistics 11 } midcomEnableRulesIncorrect OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy enable rules that failed parameter check and entered state incorrectRequest(4)." ::= { midcomStatistics 12 } midcomEnableRulesRejected OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy enable rules that failed while being processed and entered state requestRejected(6)." ::= { midcomStatistics 13 } midcomEnableRulesActive OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of currently active policy enable rules." ::= { midcomStatistics 14 } midcomEnableRulesExpired OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of expired policy enable rules (entered termination state timedOut(9))." ::= { midcomStatistics 15 } Quittek, Stiemerling, Srisuresh [Page 69]
Internet-Draft MIDCOM MIB May 2004 midcomEnableRulesTerminatedOnRq OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy enable rules that were terminated on request (entered termination state terminatedOnRequest(10))." ::= { midcomStatistics 16 } midcomEnableRulesTerminated OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of policy enable rules that were terminated, but not on request. (entered termination state terminated(11))." ::= { midcomStatistics 17 } midcomTransactionsRejected OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of rejected transactions." ::= { midcomStatistics 18 } midcomTransactionsFailed OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of failed transactions." ::= { midcomStatistics 19 } midcomTransactionsCompleted OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of completed transactions." ::= { midcomStatistics 20 } -- -- Notifications. The definition of midcomEvent makes notification -- registrations reversible (see STD 58, RFC 2578, Section 8.5). -- Quittek, Stiemerling, Srisuresh [Page 70]
Internet-Draft MIDCOM MIB May 2004 midcomEvent OBJECT IDENTIFIER ::= { midcomNotifications 0 } midcomSessionTermination NOTIFICATION-TYPE STATUS current DESCRIPTION "This notification can be generated for indicating that a session is terminated by the middlebox." ::= { midcomEvent 1 } midcomRuleEvent NOTIFICATION-TYPE OBJECTS { midcomRuleOperStatus, midcomRuleLifetime } STATUS current DESCRIPTION "This notification can be generated whenever the value of midcomRuleOperStatus enters one of the following states: reserved, enabled, any error state, any termination state. In addition, it can be generated when the lifetime of a rule was changed by successfully writing to object midcomRuleLifetime." ::= { midcomEvent 2 } midcomGroupEvent NOTIFICATION-TYPE OBJECTS { midcomGroupLifetime } STATUS current DESCRIPTION "This notification can be generated for indicating that the lifetime of all member rules of the group was changed by successfully writing to object midcomGroupLifetime. Note that this notification is only sent if the lifetime of a group was changed by successfully writing to object midcomGroupLifetime. No notification is sent - if a group's lifetime is changed by writing to object midcomRuleLifetime of any of its member policies, - if a group's lifetime expires (in this case notifications are sent for all member policies) - if the group is terminated by terminating the last of its member policies without writing to object midcomGroupLifetime." ::= { midcomEvent 3 } -- -- Conformance information -- midcomCompliances OBJECT IDENTIFIER ::= { midcomConformance 1 } midcomGroups OBJECT IDENTIFIER ::= { midcomConformance 2 } Quittek, Stiemerling, Srisuresh [Page 71]
Internet-Draft MIDCOM MIB May 2004 -- -- compliance statements -- -- This is the MIDCOM compliance definition ... -- midcomCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the MIDCOM MIB. Note that compliance with this compliance statement requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863]." MODULE -- this module MANDATORY-GROUPS { midcomSessionGroup, midcomRuleGroup, midcomNotificationsGroup, midcomCapabilitiesGroup } GROUP midcomGroupGroup DESCRIPTION "A compliant implementation does not have to implement the midcomGroupGroup." GROUP midcomConfigFirewallGroup DESCRIPTION "A compliant implementation does not have to implement the midcomConfigFirewallGroup." GROUP midcomResourceGroup DESCRIPTION "A compliant implementation does not have to implement the midcomResourceGroup." GROUP midcomStatisticsGroup DESCRIPTION "A compliant implementation does not have to implement the midcomStatisticsGroup." OBJECT midcomRuleInternalIpPrefixLength MIN-ACCESS read-only DESCRIPTION "Write access is not required. When write access is not supported return 128 as the value of this object. A value of 128 means that the function represented by this option is not supported." OBJECT midcomRuleExternalIpPrefixLength MIN-ACCESS read-only DESCRIPTION Quittek, Stiemerling, Srisuresh [Page 72]
Internet-Draft MIDCOM MIB May 2004 "Write access is not required. When write access is not supported return 128 as the value of this object. A value of 128 means that the function represented by this option is not supported." OBJECT midcomRuleMaxIdleTime MIN-ACCESS read-only DESCRIPTION "Write access is not required. When write access is not supported return 0 as the value of this object. A value of 0 means that the function represented by this option is not supported." OBJECT midcomConfigMaxLifetime MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT midcomConfigPersistentRules MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT midcomConfigIfEnabled MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT midcomConfigFirewallGroupId MIN-ACCESS read-only DESCRIPTION "Write access is not required." OBJECT midcomConfigFirewallPriority MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { midcomCompliances 1 } midcomSessionGroup OBJECT-GROUP OBJECTS { midcomSessionIndexNext, midcomSessionRuleGroupIndex, midcomSessionRuleNewIndex, midcomSessionStorageType, midcomSessionRowStatus } STATUS current DESCRIPTION "A collection of objects providing information about MIDCOM sessions." ::= { midcomGroups 1 } midcomRuleGroup OBJECT-GROUP OBJECTS { midcomRuleAdminStatus, Quittek, Stiemerling, Srisuresh [Page 73]
Internet-Draft MIDCOM MIB May 2004 midcomRuleOperStatus, midcomRuleStorageType, midcomRuleStorageTime, midcomRuleError, midcomRuleNatService, midcomRuleNatInterface, midcomRuleFlowDirection, midcomRuleMaxIdleTime, midcomRuleTransportProtocol, midcomRulePortRange, midcomRuleInternalIpVersion, midcomRuleExternalIpVersion, midcomRuleInternalIpAddr, midcomRuleInternalIpPrefixLength, midcomRuleInternalPort, midcomRuleExternalIpAddr, midcomRuleExternalIpPrefixLength, midcomRuleExternalPort, midcomRuleInsideIpAddr, midcomRuleInsidePort, midcomRuleOutsideIpAddr, midcomRuleOutsidePort, midcomRuleLifetime } STATUS current DESCRIPTION "A collection of objects providing information about policy rules." ::= { midcomGroups 2 } midcomGroupGroup OBJECT-GROUP OBJECTS { midcomGroupLifetime } STATUS current DESCRIPTION "A collection of objects providing information about policy rule groups." ::= { midcomGroups 3 } midcomCapabilitiesGroup OBJECT-GROUP OBJECTS { midcomConfigMaxLifetime, midcomConfigPersistentRules, midcomConfigIfBits, midcomConfigIfEnabled } STATUS current DESCRIPTION "A collection of objects providing information about Quittek, Stiemerling, Srisuresh [Page 74]
Internet-Draft MIDCOM MIB May 2004 the capabilities of a middlebox." ::= { midcomGroups 4 } midcomConfigFirewallGroup OBJECT-GROUP OBJECTS { midcomConfigFirewallGroupId, midcomConfigFirewallPriority } STATUS current DESCRIPTION "A collection of objects providing information about the firewall rule group and firewall rule priority to be used by firewalls loaded through MIDCOM." ::= { midcomGroups 5 } midcomResourceGroup OBJECT-GROUP OBJECTS { midcomRscNatInternalAddrBindMode, midcomRscNatInternalAddrBindId, midcomRscNatExternalAddrBindMode, midcomRscNatExternalAddrBindId, midcomRscNatSessionId1, midcomRscNatSessionId2, midcomRscFirewallRuleId } STATUS current DESCRIPTION "A collection of objects providing information about the used NAT and firewall resources." ::= { midcomGroups 6 } midcomStatisticsGroup OBJECT-GROUP OBJECTS { midcomSessionsRejected, midcomSessionsCurrent, midcomSessionsTotal, midcomRuleEntriesRejected, midcomRulesIncomplete, midcomReserveRulesIncorrect, midcomReserveRulesRejected, midcomReserveRulesActive, midcomReserveRulesExpired, midcomReserveRulesTerminatedOnRq, midcomReserveRulesTerminated, midcomEnableRulesIncorrect, midcomEnableRulesRejected, midcomEnableRulesActive, midcomEnableRulesExpired, midcomEnableRulesTerminatedOnRq, midcomEnableRulesTerminated, Quittek, Stiemerling, Srisuresh [Page 75]
Internet-Draft MIDCOM MIB May 2004 midcomTransactionsRejected, midcomTransactionsFailed, midcomTransactionsCompleted } STATUS current DESCRIPTION "A collection of objects providing statistical information about the MIDCOM server." ::= { midcomGroups 7 } midcomNotificationsGroup OBJECT-GROUP OBJECTS { midcomSessionTermination, midcomRuleEvent, midcomGroupEvent } STATUS current DESCRIPTION "The notifications emitted by the midcomMIB." ::= { midcomGroups 8 } END 8. Security Considerations Obviously, securing access to firewall and NAT configuration is extremely important for maintaining network security. This section first describes general security issues of the MIDCOM MIB and then discusses three concrete security threats: unauthorized middlebox configuration, unauthorized access to middlebox configuration information and unauthorized access to the MIDCOM service configuration. 8.1. General Security Issues There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. But also access to managed objects with a MAX-ACCESS clause of read-only may be considered sensitive or vulnerable. The support for SET and GET operations in a non-secure environment without proper protection can have a negative effect on network operations. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Quittek, Stiemerling, Srisuresh [Page 76]
Internet-Draft MIDCOM MIB May 2004 Compliant MIDCOM MIB implementations MUST support SNMPv3 security services including data integrity, data origin authentication and data confidentiality. It is REQUIRED that the implementations support the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 3414 [RFC3414] and the View- based Access Control Model RFC 3415 [RFC3415] is RECOMMENDED. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 3415 [RFC3415] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". This is supported by the midcomSessionTable, the midcomRuleTable and the midcomGroupTable. Each of them uses midcomSessionOwner as initial index. midcomSessionOwner has the syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in the three mentioned tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. 8.2. Unauthorized Middlebox Configuration The most dangerous threat to network security related to the MIDCOM MIB is unauthorized access to facilities for establishing policy rules. In such a case, unauthorized principals would write to the midcomRuleTable for opening firewall pinholes and/or for creating NAT maps, bindings and/or sessions. Establishing policies can be used to gain access to networks and systems that are protected by firewalls and/or NATs. If this protection is removed by unauthorized access to MIDCOM MIB policies, then the resulting degradation of network security can be severe. Confidential information protected by a firewall might Quittek, Stiemerling, Srisuresh [Page 77]
Internet-Draft MIDCOM MIB May 2004 become accessible to unauthorized principals, attacks exploiting security leaks of systems in the protected network might become possible from external networks and it might be possible to stop firewalls blocking denial of service attacks. MIDCOM MIB implementations MUST provide means for strict authentication, message integrity check and write access control to managed objects that can be used for establishing policy rules. These are objects in the midcomSessionTable and midcomGroupTable with a MAX-ACCESS clause of read-write and/or read-create and the read- only objects midcomSessionIndexNext and midcomSessionRuleNewIndex. Particularly sensitive are (1) read access to managed object midcomSessionRuleNewIndex, because reading it creates a new entry in the midcomRuleTable, and (2) write access to managed object midcomAdminStatus, because writing it causes policy rules to be established. Also writing to other managed objects in the two tables can vulnerate security if it interferes with the authorized establishment of a policy rule, for example by wildcarding a policy rule after the corresponding entry in the midcomRuleTable is created, but before the authorized owner establishes the rule by writing to midcomRuleAdminStatus. Not only unauthorized establishment, but also unauthorized lifetime extension of an existing policy rule may be considered sensitive or vulnerable in some network environments. Therefore, means for strict authentication, message integrity check and write access control to managed object midcomGroupLifetime MUST be provided by MIDCOM MIB implementations. 8.3. Unauthorized Access to Middlebox Configuration Information Another threat to network security is unauthorized access to entries in the midcomRuleTable. The entries contain information about existing pinholes in the firewall and/or about the current NAT configuration. This information can be used for attacking the internal network from outside. Therefore, a MIDCOM MIB implementation MUST also provide means for read access control to the midcomRuleTable. Also, a MIDCOM MIB implementation SHOULD provide means for protecting different authenticated MIDCOM agents from each other, such that an authenticated user can only read entries in the midcomRuleTable that have the same value of the midcomSessionOwner object as the midcomSessionOwner object of the clients current opens session has. Quittek, Stiemerling, Srisuresh [Page 78]
Internet-Draft MIDCOM MIB May 2004 8.4. Unauthorized Access to MIDCOM Service Configuration There are three objects with a MAX-ACCESS clause of read-write that configure the MIDCOM service: midcomConfigIfEnabled, midcomFirewallGroupId and midcomFirewallPriority. Unauthorized writing to object midcomConfigIfEnabled can cause serious interruptions of network service. Writing to midcomFirewallGroupId and/or midcomFirewallPriority can be used to increase or reduce the priority of firewall rules that are generated when a policy rule is established in the midcomRuleTable. Increasing the priority might permit firewall rules generated via the MIDCOM MIB to overrule basic security rules at the firewall that should have higher priority than the ones generated vis the MIDCOM MIB. Therefore also for these objects, means for strict control of write access MUST be provided by a MIDCOM MIB implementation. 9. Acknowledgements This memo is based on a long history of discussion within the MIDCOM MIB design team. Many thanks to Mary Barnes, Wes Hardaker, David Harrington and Tom Taylor for fruitful comments and recommendations. 10. Open Issues - firewall resource usage indication is generic. A more specific indication is required. - notification identifiers and transaction identifiers required by semantics are not discussed - So far there are no means for configuring which notifications to receive - better specification of failed and rejected transactions in the MIB module (midcomTransactionsRejected and midcomTransactionsFailed) - Request unused entries in rule table to be written to object midcomRuleAdminStatus within 60 seconds. Timeout for unused rule entries is aborted only by writing to midcomRuleAdminStatus - Is MaxIdleTime not an input parameter to PRR? - rename 'signaling objects/branch' to 'transaction objects/branch'? Quittek, Stiemerling, Srisuresh [Page 79]
Internet-Draft MIDCOM MIB May 2004 11. Normative References [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [RFC3304] Swale, R.P., Mart, P.A., Sijben, P., Brimm, S. and M. Shore, "Middlebox Communications (midcom) Protocol Requirements", RFC 3304, August 2002. [RFCXXXX] Stiemerling, M., Quittek, J. and T. Tailor, "Middlebox Communications (midcom) protocol semantics", RFC XXXX, YYYYmonth 2004, <draft-ietf-midcom-semantics-07.txt>. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3414] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002. [RFCXXYY] Raghunarayan, R., Pai, N., Rohit, R., Wang, C. and P. Srisuresh, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC XXYY, YYYYmonth 2004, <draft-ietf-nat-natmib-09.txt>. 12. Informative References [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Quittek, Stiemerling, Srisuresh [Page 80]
Internet-Draft MIDCOM MIB May 2004 [RFC3234] Carpenter, B., and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. 13. Authors' Addresses Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@netlab.nec.de Martin Stiemerling NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-13 Email: stiemerling@netlab.nec.de P. Srisuresh Caymas Systems, Inc. 1179-A North McDowell Blvd. Petaluma, CA 94954 USA Phone: +1 707 283-5063 Email: srisuresh@yahoo.com 14. IPR Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it Quittek, Stiemerling, Srisuresh [Page 81]
Internet-Draft MIDCOM MIB May 2004 has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 15. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Quittek, Stiemerling, Srisuresh [Page 82]
