GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc5190

Network Working Group J. Quittek Request for Comments: 5190 M. Stiemerling Category: Standards Track NEC

                                                          P. Srisuresh
                                                        Kazeon Systems
                                                            March 2008
     Definitions of Managed Objects for Middlebox Communication

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

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 5189.

Quittek, et al. Standards Track [Page 1] RFC 5190 MIDCOM MIB March 2008

Table of Contents

 1. Introduction ....................................................4
 2. The Internet-Standard Management Framework ......................4
 3. Overview ........................................................4
    3.1. Terminology ................................................5
 4. Realizing the MIDCOM Protocol with SNMP .........................6
    4.1. MIDCOM Sessions ............................................6
         4.1.1. Authentication and Authorization ....................6
    4.2. MIDCOM Transactions ........................................7
         4.2.1. Asynchronous Transactions ...........................7
         4.2.2. Configuration Transactions ..........................8
         4.2.3. Monitoring Transactions ............................11
         4.2.4. Atomicity of MIDCOM Transactions ...................12
                4.2.4.1. Asynchronous MIDCOM Transactions ..........12
                4.2.4.2. Session Establishment and
                         Termination Transactions ..................12
                4.2.4.3. Monitoring Transactions ...................13
                4.2.4.4. Lifetime Change Transactions ..............13
                4.2.4.5. Transactions Establishing New
                         Policy Rules ..............................14
         4.2.5. Access Control .....................................14
    4.3. Access Control Policies ...................................14
 5. Structure of the MIB Module ....................................15
    5.1. Transaction Objects .......................................16
         5.1.1. midcomRuleTable ....................................17
         5.1.2. midcomGroupTable ...................................19
    5.2. Configuration Objects .....................................20
         5.2.1. Capabilities .......................................20
         5.2.2. midcomConfigFirewallTable ..........................21
    5.3. Monitoring Objects ........................................22
         5.3.1. midcomResourceTable ................................22
         5.3.2. midcomStatistics ...................................24
    5.4. Notifications .............................................25
 6. Recommendations for Configuration and Operation ................26
    6.1. Security Model Configuration ..............................26
    6.2. VACM Configuration ........................................27
    6.3. Notification Configuration ................................28
    6.4. Simultaneous Access .......................................28
    6.5. Avoiding Idempotency Problems .............................29
    6.6. Interface Indexing Problems ...............................29
    6.7. Applicability Restrictions ................................30
 7. Usage Examples for MIDCOM Transactions .........................30
    7.1. Session Establishment (SE) ................................31
    7.2. Session Termination (ST) ..................................31
    7.3. Policy Reserve Rule (PRR) .................................31
    7.4. Policy Enable Rule (PER) after PRR ........................33
    7.5. Policy Enable Rule (PER) without Previous PRR .............34

Quittek, et al. Standards Track [Page 2] RFC 5190 MIDCOM MIB March 2008

    7.6. Policy Rule Lifetime Change (RLC) .........................35
    7.7. Policy Rule List (PRL) ....................................35
    7.8. Policy Rule Status (PRS) ..................................35
    7.9. Asynchronous Policy Rule Event (ARE) ......................36
    7.10. Group Lifetime Change (GLC) ..............................36
    7.11. Group List (GL) ..........................................36
    7.12. Group Status (GS) ........................................37
 8. Usage Examples for Monitoring Objects ..........................37
    8.1. Monitoring NAT Resources ..................................37
    8.2. Monitoring Firewall Resources .............................38
 9. Definitions ....................................................38
 10. Security Considerations .......................................85
    10.1. General Security Issues ..................................85
    10.2. Unauthorized Middlebox Configuration .....................86
    10.3. Unauthorized Access to Middlebox Configuration ...........87
    10.4. Unauthorized Access to MIDCOM Service Configuration ......88
 11. Acknowledgements ..............................................88
 12. IANA Considerations ...........................................88
 13. Normative References ..........................................88
 14. Informative References ........................................90

Quittek, et al. Standards Track [Page 3] RFC 5190 MIDCOM MIB March 2008

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", "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 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 [RFC5189] for communication between applications
 and middleboxes acting as firewalls, NATs, or a combination of both.
 The MIDCOM architecture and framework define 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 a MIDCOM
 agent and a middlebox.

Quittek, et al. Standards Track [Page 4] RFC 5190 MIDCOM MIB March 2008

 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.) affected 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 [RFC5189] 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 from its use in the MIDCOM framework: The SNMP
 manager corresponds to the MIDCOM agent and the SNMP agent
 corresponds to the MIDCOM middlebox, also called MIDCOM server.  In
 order to avoid confusion in this document specifying a MIB module, we
 replace the term 'MIDCOM agent' with '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.
                +---------+     MIDCOM      +-----------+
                | MIDCOM  |<~ ~ ~ ~ ~ ~ ~ ~>|  MIDCOM   |
                | Client  |   Transaction   | middlebox |
                |         |                 | (server)  |
                +---------+                 +-----------+
                     ^                            ^
                     |                            |
                     v                            v
                +---------+                 +-----------+
                |  SNMP   |      SNMP       |   SNMP    |
                | Manager |<===============>|   Agent   |
                +---------+    Protocol     +-----------+
                  Figure 1: Mapping of MIDCOM to SNMP

Quittek, et al. Standards Track [Page 5] RFC 5190 MIDCOM MIB March 2008

4. Realizing the MIDCOM Protocol with SNMP

 In order to realize middlebox communication as described in
 [RFC5189], 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 MIDCOM 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 available in SNMP need to be modeled.  Particularly, the
 middlebox needs to be able to authenticate MIDCOM clients, authorize
 access to policy rules, and send notification messages concerning
 policy rules to MIDCOM clients participating in a session.  In the
 MIDCOM-MIB module, authentication and access control are performed on
 a per-message basis using an SNMPv3 security model, such as the
 User-based Security Model (USM) [RFC3414], for authentication, and
 the View-based Access Control Model (VACM) [RFC3415] for access
 control.  Sending notifications to MIDCOM clients is controlled by
 access control models such as VACM and a mostly static configuration
 of objects in the SNMP-TARGET-MIB [RFC3413] and the SNMP-
 NOTIFICATION-MIB [RFC3413].
 This session model is static except that the MIDCOM client can switch
 on and off the generation of SNMP notifications that the middlebox
 sends.  Recommended configurations of VACM and the SNMP-TARGET-MIB
 and the SNMP-NOTIFICATION-MIB that can serve for modeling a session
 are described in detail in section 6.

4.1.1. Authentication and Authorization

 MIDCOM sessions are required for providing authentication,
 authorization, and encryption for messages exchanged between a MIDCOM
 client and a middlebox.  SNMPv3 provides these features on a per-
 message basis instead of a per-session basis applying a security
 model and an access control model, such as USM and VACM.  Per-message

Quittek, et al. Standards Track [Page 6] RFC 5190 MIDCOM MIB March 2008

 security mechanisms can be considered as overhead compared to per-
 session security mechanisms, but it certainly satisfies the security
 requirements of middlebox communication.
 For each authenticated MIDCOM client, access to the MIDCOM-MIB,
 particularly to policy rules, should be configured as part of the
 VACM configuration of the SNMP agent.

4.2. MIDCOM Transactions

 [RFC5189] 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.
 The SNMP terminology as defined in [RFC3411] does not use the concept
 of transactions, but of SNMP operations.  For the considerations in
 this section, we use the terms SNMP GET transaction and SNMP SET
 transaction.  An SNMP GET transaction consists of an SNMP Read Class
 operation and an SNMP Response Class operation.  An SNMP SET
 transaction consists of an SNMP Write Class operation and an SNMP
 Response Class operation.

4.2.1. Asynchronous Transactions

 Asynchronous transactions can easily be modeled by SNMP Notification
 Class operations.  An asynchronous transaction contains a
 notification message with one to three parameters.  The message can
 be realized as an SNMP Notification Class operation with the
 parameters implemented as managed objects contained in the
 notification.

Quittek, et al. Standards Track [Page 7] RFC 5190 MIDCOM MIB March 2008

             +--------------+  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 Class operation
 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 that SNMP notifications are usually sent as unreliable UDP
 packets and may be dropped before they reach their destination.  If a
 MIDCOM client is expecting an 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 a single 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 transaction is used; see Figure 3.  Completion of the last of
 the SNMP transactions indicates that all required parameters are set
 and that processing of the MIDCOM request message can start at the
 middlebox.

Quittek, et al. Standards Track [Page 8] RFC 5190 MIDCOM MIB March 2008

 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 or the SNMP reply
 message is lost, then the SNMP manager (the MIDCOM client) needs to
 take action, for example, by just repeating the SET transaction or by
 first checking the success of the initial write transaction with an
 SNMP GET transaction and then only repeating the SNMP SET transaction
 if necessary.
             +--------------+    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 transactions
                   Figure 3: MIDCOM request message
                    mapped to SNMP SET transactions
 The MIDCOM reply message can be modeled in two ways.  The first way
 is an SNMP Notification Class operation optionally followed by one or
 more SNMP GET transactions as shown in Figure 4.  The MIDCOM server
 informs the MIDCOM client about the end of processing the request by
 sending an SNMP notification.  If possible, the SNMP notification

Quittek, et al. Standards Track [Page 9] RFC 5190 MIDCOM MIB March 2008

 carries all reply parameters.  If this is not possible, then the SNMP
 manager has to perform additional SNMP GET transactions as long as
 necessary 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 GET transactions
                    Figure 4: MIDCOM reply message
       mapped to SNMP notification and optional GET transactions
 The second way replaces the SNMP Notification Class operation by a
 polling operation of the SNMP manager.  The manager polls status
 information at the SNMP agent using SNMP GET transactions until it
 detects the end of the processing of the request.  Then it uses one
 or more SNMP GET transactions to receive all of the reply parameters.
 Note that this second way requires more SNMP operations, but is more

Quittek, et al. Standards Track [Page 10] RFC 5190 MIDCOM MIB March 2008

 reliable than the first way using an SNMP Notification Class
 operation.

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.
             +--------------+    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, et al. Standards Track [Page 11] RFC 5190 MIDCOM MIB March 2008

 Since monitoring is a strength of SNMP, there are sufficient means to
 realize MIDCOM monitoring transactions simpler than MIDCOM
 configuration transactions.
 All MIDCOM monitoring transactions can be realized as a sequence of
 SNMP GET transactions.  The number of SNMP GET transactions required
 depends on the amount of information to be retrieved.

4.2.4. Atomicity of MIDCOM Transactions

 Given the realizations of MIDCOM transactions by means of SNMP
 transactions, atomicity of the MIDCOM transactions is not fully
 guaranteed anymore.  However, this section shows that atomicity
 provided by the MIB module specified in section 9 is still sufficient
 for meeting the MIDCOM requirements specified in [RFC3304].

4.2.4.1. Asynchronous MIDCOM Transactions

 There are two asynchronous MIDCOM transactions: Asynchronous Session
 Termination (AST) and Asynchronous Policy Rule Event (ARE).  The very
 static realization of MIDCOM sessions in the MIDCOM-MIB, as described
 by section 4.1, does not anymore support the asynchronous termination
 of a session.  Therefore, the AST transaction is not modeled.  For
 the ARE, atomicity is maintained, because it is modeled by a single
 atomic SNMP notification transaction.
 In addition, the MIDCOM-MIB supports an Asynchronous Group Event
 transaction, which is an aggregation of a set of ARE transactions.
 Also, this MIDCOM transaction is implemented by a single SNMP
 transaction.

4.2.4.2. Session Establishment and Termination Transactions

 The MIDCOM-MIB models MIDCOM sessions in a very static way.  The only
 dynamic actions within these transactions are enabling and disabling
 the generation of SNMP notifications at the SNMP agent.
 For the Session Establishment (SE) transaction, the MIDCOM client
 first reads the middlebox capabilities.  It is not relevant whether
 or not this action is atomic because a dynamic change of the
 middlebox capabilities is not to be expected.  Therefore, also non-
 atomic implementations of this action are acceptable.
 Then, the MIDCOM agent needs to enable the generation of SNMP
 notifications at the middlebox.  This can be realized by writing to a
 single managed object in the SNMP-NOTIFICATION-MIB [RFC3413].  But
 even other implementations are acceptable, because atomicity is not
 required for this step.

Quittek, et al. Standards Track [Page 12] RFC 5190 MIDCOM MIB March 2008

 For the Session Termination (ST) transaction, the only required
 action is disabling the generation of SNMP notifications at the
 middlebox.  As for the SE transaction, this action can be realized
 atomically by using the SNMP-NOTIFICATION-MIB, but also other
 implementations are acceptable because atomicity is not required for
 this action.

4.2.4.3. Monitoring Transactions

 Potentially, the monitoring transactions Policy Rule List (PRL),
 Policy Rule Status (PRS), Group List (GL), and Group Status (GS) are
 not atomic, because these transactions may be implemented by more
 than one SNMP GET operation.
 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
 protocol 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 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 the request message and the 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 notification message.  In order to prevent idempotency
 problems by retransmitting an SNMP request after a lost SNMP reply,
 it is RECOMMENDED that either snmpSetSerialNo (see [RFC3418]) is
 included in the corresponding SNMP SET request or the value of the
 SNMP retransmission timer be lower than the smallest requested
 lifetime value.  The same recommendation applies to the smallest
 requested value for the midcomRuleStorageTime.  MIDCOM client
 implementations MAY completely avoid this problem by configuring
 their SNMP stack such that no retransmissions are sent.

Quittek, et al. Standards Track [Page 13] RFC 5190 MIDCOM MIB March 2008

4.2.4.5. Transactions Establishing New Policy Rules

 Analogous to the monitoring transactions, the atomicity may not be
 given for Policy Reserve Rule (PRR) and Policy Enable Rule (PER)
 transactions.  Both transactions are potentially implemented using
 more than one SNMP SET operation and GET operation 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 first 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
 also be assumed that in most cases where clients share permissions,
 they act in a more or less coordinated way avoiding such
 interferences.
 All atomicity problems caused by using multiple SNMP SET transactions
 for implementing the MIDCOM request message can be avoided by
 transferring all request parameters with a single SNMP SET
 transaction.

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 authenticated principal, such as a USM user.  Then, the
 principal's access rights to all resources affected by the
 transaction are checked.  Access right control is realized by
 configuring the access control mechanisms, such as VACM, 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 are out of
 scope of this MIB module.

Quittek, et al. Standards Track [Page 14] RFC 5190 MIDCOM MIB March 2008

 However, if such an access control policy system is used, then the
 SNMP agent acts as a policy enforcement point.  An access control
 policy system must transform all active policies into configurations
 of, for example, the SNMP agent's View-based Access Control Model
 (VACM).
 The mechanisms of access control models, such as VACM, 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-MIB policy rules based on the concept
 of ownership.  For example, an access control policy can specify that
 MIDCOM-MIB 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 enforced, 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 may not be realizable using available SNMP mechanisms, but
 needs to be performed by the individual MIB module implementation.

5. Structure of the MIB Module

 The MIB module defined in section 9 contains three kinds of managed
 objects:
  1. Transaction objects

Transaction objects are required for implementing the MIDCOM

     protocol requirements defined in [RFC3304] and the MIDCOM
     protocol semantics defined in [RFC5189].
  1. Configuration objects

Configuration objects can be used for retrieving middlebox

     capability information (mandatory) and for setting parameters of
     the implementation of transaction objects (optional).
  1. Monitoring objects

The optional monitoring objects provide information about used

     resources and about MIDCOM transaction statistics.
 The transaction objects are organized in two tables: the
 midcomRuleTable and the midcomGroupTable.  Entity relationships of

Quittek, et al. Standards Track [Page 15] RFC 5190 MIDCOM MIB March 2008

 entries of these tables and the midcomResourceTable from the
 monitoring objects are illustrated by Figure 6.
                          +--------------------+
                          |  midcomRuleEntry   |
                          |     indexed by     |
                          |  midcomRuleOwner   |
                          |  midcomGroupIndex  |
                          |  midcomRuleIndex   |
                          +--------------------+
                      1...n |                | 1
                            |                |
                          1 |                | 1
         +--------------------+            +---------------------+
         |  midcomGroupEntry  |            | midcomResourceEntry |
         |     indexed by     |            |     indexed by      |
         |  midcomRuleOwner   |            |  midcomRuleOwner    |
         |  midcomGroupIndex  |            |  midcomGroupIndex   |
         +--------------------+            |  midcomRuleIndex    |
                                           +---------------------+
                                             |        |        |
                                             |        |        |
                                             v        v        v
                                            NAT   Firewall   other
                                            MIB      MIB      MIB
            Figure 6: Entity relationships of table entries
 A MIDCOM client can create and delete entries in the midcomRuleTable.
 Entries in the midcomGroupTable are generated automatically as soon
 as there is an entry in the midcomRuleTable using the
 midcomGroupIndex.  The midcomGroupTable can be used as shortcut for
 accessing all member rules with a single transaction.  MIDCOM clients
 can group policy rules for various purposes.  For example, they can
 assign a unique value for the midcomGroupIndex to all rules belonging
 to a single application or an application session served by the
 MIDCOM agent.
 The midcomResourceTable augments the midcomRuleTable by information
 on the relationship of entries of the midcomRuleTable to resources
 listed in other MIB modules, such as the NAT-MIB [RFC4008].

5.1. Transaction Objects

 The transaction objects are structured according to the MIDCOM
 semantics described in [RFC5189] into two subtrees, one for policy
 rule control and one for policy rule group control.

Quittek, et al. Standards Track [Page 16] RFC 5190 MIDCOM MIB March 2008

5.1.1. midcomRuleTable

 The midcomRuleTable contains information about policy rules including
 policy rules to be established, policy rules for which establishing
 failed, established policy rules, and terminated policy rules.
 Entries in this table are indexed by the combination of
 midcomRuleOwner, midcomGroupIndex, and midcomRuleIndex.  The
 midcomRuleOwner is the owner of the rule; the midcomGroupIndex is the
 index of the group of which the policy rule is a member.
 midcomRuleOwner is of type SnmpAdminString, a textual convention that
 allows for use of the SNMPv3 View-based Access Control Model (VACM
 [RFC3415]) and allows a management application to identify its
 entries.
 Entries in this table are created by writing to midcomRuleRowStatus.
 Entries are removed when both their midcomRuleLifetime and
 midcomRuleStorageTime are timed out by counting down to 0.  A MIDCOM
 client can explicitly remove an entry by setting midcomRuleLifetime
 and midcomRuleStorageTime to 0.
 The table contains the following columnar objects:
 o   midcomRuleIndex
     The index of this entry must be unique in combination with the
     midcomRuleOwner and the midcomGroupIndex of the entry.
 o   midcomRuleAdminStatus
     For establishing a new policy rule, a set of objects in this
     entry needs to be written first.  These objects are the request
     parameters.  Then, by writing either reserve(1) or enable(2) to
     this object, the MIDCOM-MIB implementation is triggered to start
     processing the parameters and tries to establish the specified
     policy rule.
 o   midcomRuleOperStatus
     This read-only object indicates the current status of the entry.
     The entry may have an initializing state, it may have a transient
     state while processing requests, it may have an error state after
     a request was rejected, it may have a state where a policy rule
     is established, or it may have a terminated state.
 o   midcomRuleStorageType
     This object indicates whether or not the policy rule is stored as
     volatile, non-volatile, or permanent.  Depending on the MIDCOM-
     MIB implementation, this object may be writable.

Quittek, et al. Standards Track [Page 17] RFC 5190 MIDCOM MIB March 2008

 o   midcomRuleStorageTime
     This object indicates how long the entry will still exist after
     entering an error state or a termination state.
 o   midcomRuleError
     This object is a string indicating the reason for entering an
     error state.
 o   midcomRuleInterface
     This object indicates the IP interface for which enforcement of a
     policy rule is requested or performed, respectively.
 o   midcomRuleFlowDirection
     This object indicates a flow direction for which a policy enable
     rule was requested or established, respectively.
 o   midcomRuleMaxIdleTime
     This object indicates the maximum idle time of the policy rule in
     seconds.  If no packet to which the policy rule applies passes
     the middlebox for the time specified by midcomRuleMaxIdleTime,
     then the policy rule enters a termination state.
 o   midcomRuleTransportProtocol
     This object indicates a transport protocol for which a policy
     reserve rule or policy enable rule was requested or established,
     respectively.
 o   midcomRulePortRange
     This object indicates a port range for which a policy reserve
     rule or policy enable rule was requested or established,
     respectively.
 o   midcomRuleLifetime
     This object indicates the remaining lifetime of an established
     policy rule.  The MIDCOM client can change the remaining lifetime
     by writing to it.
 Beyond the listed objects, the table contains 10 further objects
 describing address parameters.  They include the IP version, IP
 address, prefix length and port number for the internal address (A0),
 inside address (A1), outside address (A2), and external address (A3).
 These objects serve as parameters specifying a request or an
 established policy, respectively.
 A0, A1, A2, and A3 are address tuples defined according to the MIDCOM
 semantics [RFC5189].  Each of them identifies either a communication
 endpoint at an internal or external device or an allocated address at
 the middlebox.

Quittek, et al. Standards Track [Page 18] RFC 5190 MIDCOM MIB March 2008

       +----------+                                 +----------+
       | internal | A0    A1 +-----------+ A2    A3 | external |
       | endpoint +----------+ middlebox +----------+ endpoint |
       +----------+          +-----------+          +----------+
                   Figure 7: Address tuples A0 - A3
  1. A0 - internal endpoint: Address tuple A0 specifies a communication

endpoint of a device within the internal network, with respect to

    the middlebox.
  1. 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.
  1. 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.
  1. A3 - external endpoint: Address tuple A3 specifies a communication

endpoint of a device within the external network, with respect to

    the middlebox.
 The MIDCOM-MIB requires the MIDCOM client to specify address tuples
 A0 and A3.  This might be a problem for applications that are not
 designed in a firewall-friendly way.  An example is an FTP
 application that uses the PORT command (instead of the recommended
 PASV command).  The problem only occurs when the middlebox offers
 twice-NAT functionality, and it can be fixed following
 recommendations for firewall-friendly communication.

5.1.2. midcomGroupTable

 The midcomGroupTable has an entry per existing policy rule group.
 Entries in this table are created automatically when creating member
 entries in the midcomRuleTable.  Entries are automatically removed
 from this table when the last member entry is removed from the
 midcomRuleTable.  Entries cannot be created or removed explicitly by
 the MIDCOM client.

Quittek, et al. Standards Track [Page 19] RFC 5190 MIDCOM MIB March 2008

 Entries are indexed by the midcomRuleOwner of the rules that belong
 to the group and by a specific midcomGroupIndex.  This allows each
 midcomRuleOwner to maintain its own independent group namespace.
 An entry of the table contains the following objects:
 o   midcomGroupIndex
     The index of this entry must be unique in combination with the
     midcomRuleOwner of the entry.
 o   midcomGroupLifetime
     This object indicates the maximum of the remaining lifetimes of
     all established policy rules that are members of the group.  The
     MIDCOM client can change the remaining lifetime of all member
     policies by writing to this object.

5.2. Configuration Objects

 The configuration subtree contains middlebox capability and
 configuration information.  Some of the contained objects are
 (optionally) writable and can also be used for configuring the
 middlebox service.
 The capabilities subtree contains some general capability information
 and detailed information per supported IP interface.  The
 midcomConfigFirewallTable can be used to configure how the MIDCOM-MIB
 implementation creates firewall rules in its firewall modules.
 Note that typically, configuration objects are not intended to be
 written by MIDCOM clients.  In general, write access to these objects
 needs to be restricted more strictly than write access to transaction
 objects.

5.2.1. Capabilities

 Information on middlebox capabilities, i.e., capabilities of the
 MIDCOM-MIB implementation, is provided by the midcomCapabilities
 subtree of managed objects.  The following objects are defined:
 o   midcomConfigMaxLifetime
     This object indicates the maximum lifetime that this middlebox
     allows policy rules to have.
 o   midcomConfigPersistentRules
     This is a boolean object indicating whether or not the middlebox
     is capable of storing policy rules persistently.

Quittek, et al. Standards Track [Page 20] RFC 5190 MIDCOM MIB March 2008

     Further capabilities are provided by the midcomConfigIfTable per
     IP interface.  This table contains just two objects.  The first
     one is a BITS object called midcomConfigIfBits containing the
     following bit values:
 o   ipv4 and ipv6
     These two bit values provide information on which IP versions are
     supported by the middlebox at the indexed interface.
 o   addressWildcards and portWildcards
     These two bit values provide information on wildcarding supported
     by the middlebox at the indexed interface.
 o   firewall and nat
     These two bit values provide information on availability of
     firewall and NAT functionality at the indexed interface.
 o   portTranslation, protocolTranslation, and twiceNat
     These three bit values provide information on the kind of NAT
     functionality available at the indexed interface.
 o   inside
     This bit indicates whether or not the indexed interface is an
     inside interface with respect to NAT functionality.
 The second object, called midcomConfigIfEnabled, indicates whether
 the middlebox capabilities described by midcomConfigIfBits are
 available or not available at the indexed IP interface.
 The midcomConfigIfTable uses index 0 for indicating capabilities that
 are available for all interfaces.

5.2.2. midcomConfigFirewallTable

 The midcomConfigFirewallTable serves for configuring how policy rules
 created by MIDCOM clients are realized as firewall rules of a
 firewall implementation.  Particularly, the priority used for
 MIDCOM-MIB policy rules can be configured.  For a single firewall
 implementation at a particular IP interface, all MIDCOM-MIB policy
 rules are realized as firewall rules with the same priority.  Also, a
 firewall rule group name can be configured.  The table is indexed by
 the IP interface index.
 An entry of the table contains the following objects:
 o   midcomConfigFirewallGroupId
     This object indicates the firewall rule group to which all
     firewall rules of the MIDCOM server are assigned.

Quittek, et al. Standards Track [Page 21] RFC 5190 MIDCOM MIB March 2008

 o   midcomConfigFirewallPriority
     This object indicates the priority assigned to all firewall rules
     of the MIDCOM server.

5.3. Monitoring Objects

 The monitoring objects are structured into two subtrees: the resource
 subtree and the statistics subtree.  The resource subtree provides
 information about which resources are used by which policy rule.  The
 statistics subtree provides statistics about the usage of transaction
 objects.

5.3.1. midcomResourceTable

 Information about resource usage per policy rule is provided by the
 midcomResourceTable.  Each entry in the midcomResourceTable describes
 resource usage of exactly one policy rule.
 Resources are NAT resources and firewall resources, depending on the
 type of middlebox.  Used NAT resources include NAT bindings and NAT
 sessions.  NAT address mappings are not covered.  For firewalls,
 firewall filter rules are considered as resources.
 The values provided by the following objects on NAT binds and NAT
 sessions may refer to the detailed resource usage description in the
 NAT-MIB module [RFC4008].
 The values provided by the following objects on firewall rules may
 refer to more detailed firewall resource usage descriptions in other
 MIB modules.
 Entries in the midcomResourceTable are only valid if the
 midcomRuleOperStatus object of the corresponding entry in the
 midcomRuleTable has a value of either reserved(7) or enabled(8).
 An entry of the table contains the following objects:
 o   midcomRscNatInternalAddrBindMode
     This object indicates whether the binding of the internal address
     is an address NAT binding or an address-port NAT binding.
 o   midcomRscNatInternalAddrBindId
     This object identifies the NAT binding for the internal address
     in the NAT engine.
 o   midcomRscNatExternalAddrBindMode
     This object indicates whether the binding of the external address
     is an address NAT binding or an address-port NAT binding.

Quittek, et al. Standards Track [Page 22] RFC 5190 MIDCOM MIB March 2008

 o   midcomRscNatExternalAddrBindId
     This object identifies the NAT binding for the external address
     in the NAT engine.
 o   midcomRscNatSessionId1
     This object links to the first NAT session associated with one of
     the above NAT bindings.
 o   midcomRscNatSessionId2
     This object links to the optional second NAT session associated
     with one of the above NAT bindings.
 o   midcomRscFirewallRuleId
     This object indicates the firewall rule for this policy rule.
 The MIDCOM-MIB module does not require a middlebox to implement
 further specific middlebox (NAT, firewall, etc.) MIB modules as, for
 example, the NAT-MIB module [RFC4008].
 The resource identifiers in the midcomResourceTable may be vendor
 proprietary in the cases where the middlebox does not implement the
 NAT-MIB [RFC4008] or a firewall MIB.  The MIDCOM-MIB module affects
 NAT binding and sessions, as well as firewall pinholes.  It is
 intentionally not specified in the MIDCOM-MIB module how these NAT
 and firewall resources are allocated and managed, since this depends
 on the MIDCOM-MIB implementation and middlebox's capabilities.
 However, the midcomResourceTable is useful for understanding which
 resources are affected by which MIDCOM-MIB transaction.
 The midcomResourceTable is beneficial to the middlebox administrator
 in that the table lists all MIDCOM transactions and the middlebox
 specific resources to which these transactions refer.  For instance,
 multiple MIDCOM clients might end up using the same NAT bind, yet
 each MIDCOM client might define a Lifetime parameter and
 directionality for the bind that is specific to the transaction.
 MIDCOM-MIB implementations are responsible for impacting underlying
 middlebox resources so as to satisfy the sometimes overlapping
 requirements on the same resource from multiple MIDCOM clients.
 Managing these resources is not a trivial task for MIDCOM-MIB
 implementers.  It is possible that different MIDCOM-MIB policy rules
 owned by different MIDCOM clients share a NAT binding or a firewall
 rule.  Then common properties, for example, the lifetime of the
 resource, need to be managed such that all clients are served well
 and changes to these resources need to be communicated to all
 affected clients.  Also, dependencies between resources, for example,
 the precedence order of firewall rules, need to be considered

Quittek, et al. Standards Track [Page 23] RFC 5190 MIDCOM MIB March 2008

 carefully in order to avoid that different policy rules --
 potentially owned by different clients -- influence each other.
 MIDCOM clients may use the midcomResourceTable of the MIDCOM-MIB
 module in conjunction with the NAT-MIB module [RFC4008] to determine
 which resources of the NAT are used for MIDCOM.  The NAT-MIB module
 stores the configured NAT bindings and sessions, and MIDCOM clients
 can use the information of the midcomResourceTable to sort out those
 NAT resources that are used by the MIDCOM-MIB module.

5.3.2. midcomStatistics

 The statistics subtree contains a set of non-columnar objects that
 provide 'MIDCOM protocol statistics', i.e., statistics about the
 usage of transaction objects.
 o   midcomCurrentOwners
     This object indicates the number of different values for
     midcomRuleOwner for all current entries in the midcomRuleTable.
 o   midcomOwnersTotal
     This object indicates the summarized number of all different
     values that occurred for midcomRuleOwner in the midcomRuleTable
     current and in the past.
 o   midcomTotalRejectedRuleEntries
     This object indicates the total number of failed attempts to
     create an entry in the midcomRuleTable.
 o   midcomCurrentRulesIncomplete
     This object indicates the total number of policy rules that have
     not been fully loaded into a table row of the midcomRuleTable.
 o   midcomTotalIncorrectReserveRules
     This object indicates the total number of policy reserve rules
     that were rejected because the request was incorrect.
 o   midcomTotalRejectedReserveRules
     This object indicates the total number of policy reserve rules
     that were failed while being processed.
 o   midcomCurrentActiveReserveRules
     This object indicates the number of currently active policy
     reserve rules in the midcomRuleTable.
 o   midcomTotalExpiredReserveRules
     This object indicates the total number of expired policy reserve
     rules.

Quittek, et al. Standards Track [Page 24] RFC 5190 MIDCOM MIB March 2008

 o   midcomTotalTerminatedOnRqReserveRules
     This object indicates the total number of policy reserve rules
     that were terminated on request.
 o   midcomTotalTerminatedReserveRules
     This object indicates the total number of policy reserve rules
     that were terminated, but not on request.
 o   midcomTotalIncorrectEnableRules
     This object indicates the total number of policy enable rules
     that were rejected because the request was incorrect.
 o   midcomTotalRejectedEnableRules
     This object indicates the total number of policy enable rules
     that were failed while being processed.
 o   midcomCurrentActiveEnableRules
     This object indicates the number of currently active policy
     enable rules in the midcomRuleTable.
 o   midcomTotalExpiredEnableRules
     This object indicates the total number of expired policy enable
     rules.
 o   midcomTotalTerminatedOnRqEnableRules
     This object indicates the total number of policy enable rules
     that were terminated on request.
 o   midcomTotalTerminatedEnableRules
     This object indicates the total number of policy enable rules
     that were terminated, but not on request.

5.4. Notifications

 For informing MIDCOM clients about state changes of MIDCOM-MIB
 implementations, three notifications can be used.  They notify the
 MIDCOM client about state changes of individual policy rules or of
 groups of policy rules.  Different notifications are used for
 different kinds of transactions.
 For asynchronous transactions, unsolicited notifications are used.
 The only asynchronous transaction that needs to be modeled by the
 MIDCOM-MIB is the Asynchronous Policy Rule Event (ARE).  The ARE may
 be caused by the expiration of a policy rule lifetime, the expiration
 of the idle time, or an internal change in policy rule lifetime by
 the MIDCOM-MIB implementation for whatever reason.

Quittek, et al. Standards Track [Page 25] RFC 5190 MIDCOM MIB March 2008

 For configuration transactions, solicited notifications are used.
 This concerns the Policy Reserve Rule (PRR) transaction, the Policy
 Enable Rule (PER) transaction, the Policy Rule Lifetime Change (RLC)
 transaction, and the Group Lifetime Change (GLC) transaction.
 The separation between unsolicited and solicited notifications gives
 the implementer of a MIDCOM client some freedom to make design
 decisions on how to model the MIDCOM reply message as described at
 the end of section 4.2.2.  Depending on the choice, processing of
 solicited notifications may not be required.  In such a case,
 delivery of solicited notification may be disabled, for example, by
 an appropriate configuration of the snmpNotifyFilterTable such that
 solicited notifications are filtered differently to unsolicited
 notifications.
 o   midcomUnsolicitedRuleEvent
     This notification can be generated for indicating the change of a
     policy rule's state or lifetime.  It is used for performing the
     ARE transaction.
 o   midcomSolicitedRuleEvent
     This notification can be generated for indicating the requested
     change of a policy rule's state or lifetime.  It is used for
     performing PRR, PER, and RLC transactions.
 o   midcomSolicitedGroupEvent
     This notification can be generated for indicating the requested
     change of a policy rule group's lifetime.  It is used for
     performing the GLC transaction.

6. Recommendations for Configuration and Operation

 Configuring MIDCOM-MIB security is highly sensitive for obvious
 reasons.  This section gives recommendations for securely configuring
 the SNMP agent acting as MIDCOM server.  In addition, recommendations
 for avoiding idempotency problems are given and restrictions of
 MIDCOM-MIB applicability to a special set of applications are
 discussed.

6.1. Security Model Configuration

 Since controlling firewalls and NATs is highly sensitive, it is
 RECOMMENDED that SNMP Command Responders implementing the MIDCOM-MIB
 module use the authPriv security level for all users that may access
 managed objects of the MIDCOM-MIB module.

Quittek, et al. Standards Track [Page 26] RFC 5190 MIDCOM MIB March 2008

6.2. VACM Configuration

 Entries in the midcomRuleTable and the midcomGroupTable provide
 information about existing firewall pinholes and/or NAT sessions.
 They also could be used for manipulating firewall pinholes and/or NAT
 sessions.  Therefore, access control to these objects is essential
 and should be restrictive.
 It is RECOMMENDED that SNMP Command Responders instantiating an
 implementation of the MIDCOM-MIB module use VACM for controlling
 access to managed objects in the midcomRuleTable and the
 midcomGroupTable.
 It is further RECOMMENDED that individual MIDCOM clients, acting as
 SNMP Command Generators, only have access to an entry in the
 midcomRuleTable, the midcomResourceTable, or the midcomGroupTable, if
 they created the entry directly in the midcomRuleTable or indirectly
 in the midcomGroupTable and midcomResourceTable.  Exceptions to this
 recommendation are situations where access by multiple MIDCOM clients
 to managed objects is explicitly required.  One example is fail-over
 for MIDCOM agents where the stand-by MIDCOM agent needs the same
 access rights to managed objects as the currently active MIDCOM
 agent.  Another example is a supervisor MIDCOM agent that monitors
 activities of other MIDCOM agents and/or may be used by network
 management systems to modify entries in tables of the MIDCOM-MIB.
 For this reason, all three tables listed above have the
 midcomRuleOwner as initial index.  It is RECOMMENDED that MIDCOM
 clients acting as SNMP Command Generator have access to the
 midcomRuleTable and the midcomGroupTable restricted to entries with
 the initial index matching either their SNMP securityName or their
 VACM groupName.  It is RECOMMENDED that they do not have access to
 entries in these tables with initial indices other than their SNMP
 securityName or their VACM groupName.  It is RECOMMENDED that this
 VACM configuration is applied to read access, write access, and
 notify access for all objects in the midcomRuleTable and the
 midcomGroupTable.
 Note that less restrictive access rights MAY be granted to other
 users, for example, to a network management application, that
 monitors MIDCOM policy rules.

Quittek, et al. Standards Track [Page 27] RFC 5190 MIDCOM MIB March 2008

6.3. Notification Configuration

 For each MIDCOM client that has access to the midcomRuleTable, a
 notification target SHOULD be configured at a Command Responder
 instantiating an implementation of the MIDCOM-MIB.  It is RECOMMENDED
 that such a configuration be retrievable from the Command Responder
 via the SNMP-TARGET-MIB [RFC3413].
 For each entry of the snmpTargetAddrTable that is related to a MIDCOM
 client, there SHOULD be an individual corresponding entry in the
 snmpTargetParamsTable.
 An implementation of the MIDCOM-MIB SHOULD also implement the SNMP-
 NOTIFICATION-MIB [RFC3413].  An instance of an implementation of the
 MIDCOM-MIB SHOULD have an individual entry in the
 snmpNotifyFilterProfileTable for each MIDCOM client that has access
 to the midcomRuleTable.
 An instance of an implementation of the MIDCOM-MIB SHOULD allow
 MIDCOM clients to start and stop the generation of notifications
 targeted at themselves.  This SHOULD be realized by giving the MIDCOM
 clients write access to the snmpNotifyFilterTable.  If appropriate
 entries of the snmpNotifyFilterTable are established in advance, then
 this can be achieved by granting MIDCOM clients write access only to
 the columnar object snmpNotifyFilterType.
 It is RECOMMENDED that VACM be configured such that each MIDCOM agent
 can only access entries in the snmpTargetAddrTable, the
 snmpTargetParamsTable, the snmpNotifyFilterProfileTable, and the
 snmpFilterTable that concern that particular MIDCOM agent.
 Typically, read access to the snmpTargetAddrTable, the
 snmpTargetParamsTable, and the snmpNotifyFilterProfileTable is
 sufficient.  Write access may be required for objects of the
 snmpFilterTable.

6.4. Simultaneous Access

 Situations with two MIDCOM clients simultaneously modifying the same
 policy rule should be avoided.  For each entry in the
 midcomRuleTable, there should be only one client at a time that
 modifies it.  If two MIDCOM clients share the same midcomRuleOwner
 index of the midcomRuleTable, then conflicts can be avoided, for
 example, by
  1. scheduling access times, as, for example, in the fail-over case;
  2. using different midcomGroupIndex values per client; or
  3. using non-overlapping intervals for values of the

midcomRuleIndex per client.

Quittek, et al. Standards Track [Page 28] RFC 5190 MIDCOM MIB March 2008

6.5. Avoiding Idempotency Problems

 As already discussed in section 4.2.4.4, the following recommendation
 is given for avoiding idempotency problems.
 In general, idempotency problems can be solved by including
 snmpSetSerialNo (see [RFC3418]) in SNMP SET requests.
 In case this feature is not used, it is RECOMMENDED that the value of
 the SNMP retransmission timer of a MIDCOM client (acting as SNMP
 Command Generator) is lower than the smallest requested value for any
 rule lifetime or rule idle time in order to prevent idempotency
 problems with setting midcomRuleLifetime and midcomRuleMaxIdleTime
 when retransmitting an SNMP SET request after a lost SNMP reply.
 MIDCOM client implementations MAY completely avoid this problem by
 configuring their SNMP stack such that no retransmissions are sent.
 Similar considerations apply to MIDCOM-MIB implementations acting as
 Notification Originator when sending a notification
 (midcomUnsolicitedRuleEvent, midcomSolicitedRuleEvent or
 midcomSolicitedGroupEvent) containing the remaining lifetime of a
 policy rule or a policy rule group, respectively.

6.6. Interface Indexing Problems

 A well-known problem of MIB modules is indexing IP interfaces after a
 re-initialization of the managed device.  The index for interfaces
 provided by the ifTable (see IF-MIB in [RFC2863]) may change during
 re-initialization, for example, when physical interfaces are added or
 removed.
 The MIDCOM-MIB module uses the interface index for indicating at
 which interface which policy rule is (or is to be) applied.  Also,
 this index is used for indicating how policy rules are prioritized at
 certain interfaces.  The MIDCOM-MIB module specification requires
 that information provided is always correct.  This implies that after
 re-initialization, interface index values of policy rules or firewall
 configurations may have changed even though they still refer to the
 same interface as before the re-initialization.
 MIDCOM client implementations need to be aware of this potential
 behavior.  It is RECOMMENDED that before writing the value or using
 the value of indices that depend on the ifTable the MIDCOM client
 checks if the middlebox has been re-initialized recently.

Quittek, et al. Standards Track [Page 29] RFC 5190 MIDCOM MIB March 2008

 MIDCOM-MIB module implementations MUST track interface changes of IP
 interface indices in the ifTable.  This implies that after a re-
 initialization of a middlebox, a MIDCOM-MIB implementation MUST make
 sure that each instance of an interface index in the MIDCOM-MIB
 tables still points to the same interface as before the re-
 initialization.  For any instance for which this is not possible, all
 affected entries in tables of the MIDCOM-MIB module MUST be either
 terminated, disabled, or deleted, as specified in the DESCRIPTION
 clause of the respective object.  This concerns all objects in the
 MIDCOM-MIB module that are of type InterfaceIndexOrZero.

6.7. Applicability Restrictions

 As already discussed in section 5.1.1, the MIDCOM-MIB requires the
 MIDCOM client to specify address tuples A0 and A3.  This can be a
 problem for applications that do not have this information available
 when they need to configure the middlebox.  For some applications,
 there are usage scenarios where address information is only available
 for a single address realm, A0 and A1 in the private realm or A2 and
 A3 in the public realm.  An example is an FTP application using the
 PORT command (instead of the PASV command).  The problem occurs when
 the middlebox offers twice-NAT functionality.

7. Usage Examples for MIDCOM Transactions

 This section presents some examples that explain how a MIDCOM client
 acting as SNMP manager can use the MIDCOM-MIB module defined in this
 memo.  The purpose of these examples is to explain the steps that are
 required to perform MIDCOM transactions.  For each MIDCOM transaction
 defined in the MIDCOM semantics [RFC5189], a sequence of SNMP
 operations that realizes the transaction is described.
 The examples described below are recommended procedures for MIDCOM
 clients.  Clients may choose to operate differently.
 For example, they may choose not to receive solicited notifications
 on completion of a transaction, but to poll the MIDCOM-MIB instead
 until the transaction is completed.  This can be achieved by
 performing step 2 of the SE transaction (see below) differently.  The
 MIDCOM agent then creates an entry in the snmpNotifyFilterTable such
 that only the midcomUnsolicitedRuleEvent may pass the filter and is
 sent to the MIDCOM client.  In this case, the PER, PRR, and RLC
 transactions require a polling loop wherever in the example below the
 MIDCOM client waits for a notification.

Quittek, et al. Standards Track [Page 30] RFC 5190 MIDCOM MIB March 2008

7.1. Session Establishment (SE)

 The MIDCOM-MIB realizes most properties of MIDCOM sessions in a very
 static way.  Only the generation of notifications targeted at the
 MIDCOM client is enabled by the client for session establishment.
 1. The MIDCOM client checks the middlebox capabilities by reading
    objects in the midcomCapabilitiesGroup.
 2. The MIDCOM client enables generation of notifications on events
    concerning the policy rules controlled by the client.  If the
    SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3
    of this document, then the agent just has to change the value of a
    object snmpNotifyFilterType in the corresponding entry of the
    snmpNotifyFilterTable from included(1) to excluded(2).

7.2. Session Termination (ST)

 For terminating a session, the MIDCOM client just disables the
 generation of notifications for this client.
 1. The MIDCOM client disables generation of notifications on events
    concerning the policy rules controlled by the client.  If the
    SNMP-NOTIFICATION-MIB is supported as recommended by section 6.3
    of this document, then the agent just has to change the value of a
    object snmpNotifyFilterType in the corresponding entry of the
    snmpNotifyFilterTable from included(1) to excluded(2).

7.3. Policy Reserve Rule (PRR)

 This example explains steps that may be performed by a MIDCOM client
 to establish a policy reserve rule.
 1. The MIDCOM client creates a new entry in the midcomRuleTable by
    writing to midcomRuleRowStatus.  The chosen value for index object
    midcomGroupIndex determines the group membership of the created
    rule.  Note that choosing an unused value for midcomGroupIndex
    creates a new entry in the midcomGroupTable.
 2. The MIDCOM client sets the following objects in the new entry of
    the midcomRuleTable to specify all request parameters of the PRR
    transaction:
  1. midcomRuleMaxIdleTime
  2. midcomRuleInterface
  3. midcomRuleTransportProtocol
  4. midcomRulePortRange
  5. midcomRuleInternalIpVersion

Quittek, et al. Standards Track [Page 31] RFC 5190 MIDCOM MIB March 2008

  1. midcomRuleExternalIpVersion
  2. midcomRuleInternalIpAddr
  3. midcomRuleInternalIpPrefixLength
  4. midcomRuleInternalPort
  5. midcomRuleLifetime
    Note that several of these parameters have default values that can
    be used.
 3. The MIDCOM client sets the midcomRuleAdminStatus objects in the
    new row of the midcomRuleTable to reserve(1).
 4. The MIDCOM client awaits a midcomSolicitedRuleEvent notification
    concerning the new policy rule in the midcomRuleTable.  Waiting
    for the notification is timed out after a pre-selected maximum
    waiting time.  In case of a timeout while waiting for the
    notification or if the client does not use notifications, the
    MIDCOM client retrieves the status of the midcomRuleEntry by one
    or more SNMP GET operations.
 5. After receiving the midcomSolicitedRuleEvent notification, the
    MIDCOM client checks the lifetime value carried by the
    notification.  If it is greater than 0, the MIDCOM client reads
    all positive reply parameters of the PRR transaction:
  1. midcomRuleOutsideIpAddr
  2. midcomRuleOutsidePort
  3. midcomRuleMaxIdleTime
  4. midcomRuleLifetime
    If the lifetime equals 0, then the MIDCOM client reads the
    midcomRuleOperStatus and the midcomRuleError in order to analyze
    the failure reason.
 6. Optionally, after receiving the midcomSolicitedRuleEvent
    notification with a lifetime value greater than 0, the MIDCOM
    client may check the midcomResourceTable for the middlebox
    resources allocated for this policy reserve rule.  Note that PRR
    does not necessarily allocate any middlebox resource visible in
    the NAT-MIB module or in a firewall MIB module, since it does a
    reservation only.  If, however, the PRR overlaps with already
    existing PERs, then the PRR may be related to middlebox resources
    visible in other MIB modules.

Quittek, et al. Standards Track [Page 32] RFC 5190 MIDCOM MIB March 2008

7.4. Policy Enable Rule (PER) after PRR

 This example explains steps that may be performed by a MIDCOM client
 to establish a policy enable rule after a corresponding policy
 reserve rule was already established.
 1. The MIDCOM client sets the following objects in the row of the
    established PRR in the midcomRuleTable to specify all request
    parameters of the PER transaction:
  1. midcomRuleMaxIdleTime
  2. midcomRuleExternalIpAddr
  3. midcomRuleExternalIpPrefixLength
  4. midcomRuleExternalPort
  5. midcomRuleFlowDirection
    Note that several of these parameters have default values that can
    be used.
 2. The MIDCOM client sets the midcomRuleAdminStatus objects in the
    row of the established PRR in the midcomRuleTable to enable(1).
 3. The MIDCOM client awaits a midcomSolicitedRuleEvent notification
    concerning the new row in the midcomRuleTable.  Waiting for the
    notification is timed out after a pre-selected maximum waiting
    time.  In case of a timeout while waiting for the notification or
    if the client does not use notifications, the MIDCOM client
    retrieves the status of the midcomRuleEntry by one or more SNMP
    GET operations.
 4. After receiving the midcomSolicitedRuleEvent notification, the
    MIDCOM client checks the lifetime value carried by the
    notification.  If it is greater than 0, the MIDCOM client reads
    all positive reply parameters of the PER transaction:
  1. midcomRuleInsideIpAddr
  2. midcomRuleInsidePort
  3. midcomRuleMaxIdleTime
    If the lifetime equals 0, then the MIDCOM client reads the
    midcomRuleOperStatus and the midcomRuleError in order to analyze
    the failure reason.
 5. Optionally, after receiving the midcomSolicitedRuleEvent
    notification with a lifetime value greater than 0, the MIDCOM
    client may check the midcomResourceTable for the allocated
    middlebox resources for this policy enable rule.

Quittek, et al. Standards Track [Page 33] RFC 5190 MIDCOM MIB March 2008

7.5. Policy Enable Rule (PER) without Previous PRR

 This example explains steps that may be performed by a MIDCOM client
 to establish a policy enable rule for which no PRR transaction has
 been performed before.
 1. Identical to step 1 for PRR (section 7.3).
 2. Identical to step 2 for PRR (section 7.3).
 3. The MIDCOM client sets the following objects in the new row of the
    midcomRuleTable to specify all request parameters of the PER
    transaction:
  1. midcomRuleInterface
  2. midcomRuleFlowDirection
  3. midcomRuleTransportProtocol
  4. midcomRulePortRange
  5. midcomRuleInternalIpVersion
  6. midcomRuleExternalIpVersion
  7. midcomRuleInternalIpAddr
  8. midcomRuleInternalIpPrefixLength
  9. midcomRuleInternalPort
  10. midcomRuleExternalIpAddr
  11. midcomRuleExternalIpPrefixLength
  12. midcomRuleExternalPort
  13. midcomRuleLifetime
    Note that several of these parameters have default values that can
    be used.
 4. The MIDCOM client sets the midcomRuleAdminStatus objects in the
    new row of the midcomRuleTable to enable(1).
 5. Identical to step 4 for PRR (section 7.3).
 6. After receiving the midcomSolicitedRuleEvent notification, the
    MIDCOM client checks the lifetime value carried by the
    notification.  If it is greater than 0, the MIDCOM client reads
    all positive reply parameters of the PRR transaction:
  1. midcomRuleInsideIpAddr
  2. midcomRuleInsidePort
  3. midcomRuleOutsideIpAddr
  4. midcomRuleOutsidePort
  5. midcomRuleMaxIdleTime

Quittek, et al. Standards Track [Page 34] RFC 5190 MIDCOM MIB March 2008

    If the lifetime equals 0, then the MIDCOM client reads the
    midcomRuleOperStatus and the midcomRuleError in order to analyze
    the failure reason.
 7. Optionally, after receiving the midcomSolicitedRuleEvent
    notification with a lifetime value greater than 0, the MIDCOM
    client may check the midcomResourceTable for the allocated
    middlebox resources for this policy enable rule.

7.6. Policy Rule Lifetime Change (RLC)

 This example explains steps that may be performed by a MIDCOM client
 to change the lifetime of a policy rule.  Changing the lifetime to 0
 implies terminating the policy rule.
 1. The MIDCOM client issues a SET request for writing the desired
 lifetime to the midcomRuleLifetime object in the corresponding row of
 the midcomRuleTable.  This does not have any effect if the lifetime
 is already expired.
 2. The MIDCOM client awaits a midcomSolicitedRuleEvent notification
 concerning the corresponding row in the midcomRuleTable.  Waiting for
 the notification is timed out after a pre-selected maximum waiting
 time.  In case of a timeout while waiting for the notification or if
 the client does not use notifications, the MIDCOM client retrieves
 the status of the midcomRuleEntry by one or more SNMP GET operations.
 3. After receiving the midcomSolicitedRuleEvent notification MIDCOM
 client checks the lifetime value carried by the notification.

7.7. Policy Rule List (PRL)

 The SNMP agent can browse the list of policy rules by browsing the
 midcomRuleTable.  For each observed row in this table, the SNMP agent
 should check the midcomRuleOperStatus in order to find out if the row
 contains information about an established policy rule or of a rule
 that is under construction or already terminated.

7.8. Policy Rule Status (PRS)

 The SNMP agent can retrieve all status information and properties of
 a policy rule by reading the managed objects in the corresponding row
 of the midcomRuleTable.

Quittek, et al. Standards Track [Page 35] RFC 5190 MIDCOM MIB March 2008

7.9. Asynchronous Policy Rule Event (ARE)

 There are two different triggers for the ARE.  It may be triggered by
 the expiration of a policy rule's lifetime or the expiration of the
 idle time.  But beyond this, the MIDCOM-MIB implementation may
 terminate a policy rule at any time.  In all cases, two steps are
 required for performing this transaction:
 1. The MIDCOM-MIB implementation sends a midcomUnsolicitedRuleEvent
    notification containing a lifetime value of 0 to the MIDCOM client
    owning the rule.
 2. If the midcomRuleStorageTime object in the corresponding row of
    the midcomRuleTable has a value of 0, then the MIDCOM-MIB
    implementation removes the row from the table.  Otherwise, it sets
    in this row the midcomRuleLifetime object to 0 and changes the
    midcomRuleOperStatus object.  If the event was triggered by policy
    lifetime expiration, then the midcomRuleOperStatus is set to
    timedOut(9); otherwise, it is set to terminated(11).

7.10. Group Lifetime Change (GLC)

 This example explains steps that may be performed by a MIDCOM client
 to change the lifetime of a policy rule group.  Changing the lifetime
 to 0 implies terminating all member policies of the group.
 1. The MIDCOM client issues a SET request for writing the desired
    lifetime to the midcomGroupLifetime object in the corresponding
    row of the midcomGroupTable.
 2. The MIDCOM client waits for a midcomSolicitedGroupEvent
    notification concerning the corresponding row in the
    midcomGroupTable.  Waiting for the notification is timed out after
    a pre-selected maximum waiting time.  In case of a timeout while
    waiting for the notification or if the client does not use
    notifications, the MIDCOM client retrieves the status of the
    midcomGroupEntry by one or more SNMP GET operations.
 3. After receiving the midcomSolicitedRuleEvent notification, the
    MIDCOM client checks the lifetime value carried by the
    notification.

7.11. Group List (GL)

 The SNMP agent can browse the list of policy rule groups by browsing
 the midcomGroupTable.  For each observed row in this table, the SNMP
 agent should check the midcomGroupLifetime in order to find out if
 the group does contain established policies.

Quittek, et al. Standards Track [Page 36] RFC 5190 MIDCOM MIB March 2008

7.12. Group Status (GS)

 The SNMP agent can retrieve all member policies of a group by
 browsing the midcomRuleTable using the midcomGroupIndex of the
 particular group.  For retrieving the remaining lifetime of the
 group, the SNMP agent reads the midcomGroupLifetime object in the
 corresponding row of the midcomGroupTable.

8. Usage Examples for Monitoring Objects

 This section presents some examples that explain how a MIDCOM client
 can use the midcomResourceTable to correlate policy rules with the
 used middlebox resources.  One example is given for middleboxes
 implementing the NAT-MIB and another one is given for firewalls.

8.1. Monitoring NAT Resources

 When a rule in the midcomRuleTable is executed, it directly impacts
 the middlebox resources.  The midcomResourceTable provides the
 information on the relationships between the MIDCOM-MIB policy rules
 and the middlebox resources used for enforcing these rules.
 A MIDCOM-MIB policy rule will cause the creation or modification of
 up to two NAT bindings and up to two NAT sessions.  Two NAT bindings
 are impacted in the case of a session being subject to twice-NAT.
 Two NAT bindings may also be impacted when midcomRulePortRange is set
 to pair(2) in the policy rule.  In the majority of cases, where
 traditional NAT is implemented, only a single NAT binding may be
 adequate.  Note, however, that this BindId is set to 0 if the
 middlebox is implementing symmetric NAT function.  Two NAT sessions
 are created or modified only when the midcomRulePortRange is set to
 pair(2) in the policy rule.
 When support for the NAT-MIB module is also available at the
 middlebox, the parameters in the combination of the midcomRuleTable
 and the midcomResourceTable for a given rule can be used to index the
 corresponding BIND and NAT session resources effected in the NAT-MIB.
 These parameters are valuable to monitor the impact on the NAT
 module, even when the NAT-MIB module is not implemented at the
 middlebox.
 The impact of MIDCOM rules on the NAT resources is important because
 a MIDCOM rule not only can create BINDs and NAT sessions, but also is
 capable of modifying the NAT objects that already exist.  For
 example, FlowDirection and MaxIdleTime parameters in a MIDCOM rule
 directly affect the TranslationEntity and MaxIdleTime of the
 associated NAT bind object.  Likewise, MaxIdleTime in a MIDCOM rule

Quittek, et al. Standards Track [Page 37] RFC 5190 MIDCOM MIB March 2008

 has a direct impact on the MaxIdleTime of the associated NAT session
 object.  The lifetime parameter in the MIDCOM rule directly impacts
 the lifetime of all the impacted NAT BIND and NAT session objects.

8.2. Monitoring Firewall Resources

 When a MIDCOM-MIB policy rule is established at a middlebox with
 firewall capabilities, this may lead to the creation of one or more
 new firewall rules.  Note that in general a single firewall rule per
 MIDCOM-MIB policy rule will be sufficient.  For each policy rule, a
 MIDCOM client can explore the corresponding firewall filter rule by
 reading the midcomResourceEntry in the midcomResourceTable that
 corresponds to the midcomRuleEntry describing the rule.  The
 identification of the firewall filter rule is stored in object
 midcomRscFirewallRuleId.  The value of midcomRscFirewallRuleId may
 correspond directly to any firewall filter rule number or to an entry
 in a locally available firewall MIB module.

9. Definitions

 The following MIB module imports from [RFC2578], [RFC2579],
 [RFC2580], [RFC2863], [RFC3411], [RFC4001], and [RFC4008].
 MIDCOM-MIB DEFINITIONS ::= BEGIN
 IMPORTS
     MODULE-IDENTITY, OBJECT-TYPE,
     NOTIFICATION-TYPE, Unsigned32,
     Counter32, Gauge32, mib-2
         FROM SNMPv2-SMI                  -- RFC 2578
     TEXTUAL-CONVENTION, TruthValue,
     StorageType, RowStatus
         FROM SNMPv2-TC                   -- RFC 2579
     MODULE-COMPLIANCE, OBJECT-GROUP,
     NOTIFICATION-GROUP
         FROM SNMPv2-CONF                 -- RFC 2580
     SnmpAdminString
         FROM SNMP-FRAMEWORK-MIB          -- RFC 3411
     InetAddressType, InetAddress,
     InetPortNumber,
     InetAddressPrefixLength
         FROM INET-ADDRESS-MIB            -- RFC 4001

Quittek, et al. Standards Track [Page 38] RFC 5190 MIDCOM MIB March 2008

     InterfaceIndexOrZero
         FROM IF-MIB                      -- RFC 2863
     NatBindIdOrZero
         FROM NAT-MIB;                    -- RFC 4008
 midcomMIB MODULE-IDENTITY
     LAST-UPDATED "200708091011Z"  -- August 09, 2007
     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
         Co-editor:
           Juergen Quittek
           NEC Europe Ltd.
           Kurfuersten-Anlage 36
           69115 Heidelberg
           Germany
           Tel: +49 6221 4342-115
           Email: quittek@nw.neclab.eu
         Co-editor:
           Martin Stiemerling
           NEC Europe Ltd.
           Kurfuersten-Anlage 36
           69115 Heidelberg
           Germany
           Tel: +49 6221 4342-113
           Email: stiemerling@nw.neclab.eu
         Co-editor:
           Pyda Srisuresh
           Kazeon Systems, Inc.
           1161 San Antonio Rd.
           Mountain View, CA 94043
           U.S.A.
           Tel: +1 408 836-4773
           Email: srisuresh@yahoo.com"
     DESCRIPTION
         "This MIB module defines a set of basic objects for
          configuring middleboxes, such as firewalls and network

Quittek, et al. Standards Track [Page 39] RFC 5190 MIDCOM MIB March 2008

          address translators, in order to enable communication
          across these devices.
          Managed objects defined in this MIB module are structured
          in three kinds of objects:
            - transaction objects required according to the MIDCOM
              protocol requirements defined in RFC 3304 and according
              to the MIDCOM protocol semantics defined in RFC 3989,
            - configuration objects that can be used for retrieving or
              setting parameters of the implementation of transaction
              objects,
            - optional monitoring objects that provide information
              about used resource and statistics
          The transaction objects are organized in two subtrees:
            - objects modeling MIDCOM policy rules in the
              midcomRuleTable
            - objects modeling MIDCOM policy rule groups in the
              midcomGroupTable
          Note that typically, configuration objects are not intended
          to be written by MIDCOM clients.  In general, write access
          to these objects needs to be restricted more strictly than
          write access to objects in the transaction subtrees.
          Copyright (C) The Internet Society (2008).  This version
          of this MIB module is part of RFC 5190;  see the RFC
          itself for full legal notices."
     REVISION    "200708091011Z"  -- August 09, 2007
     DESCRIPTION "Initial version, published as RFC 5190."
     ::= { mib-2 171 }
  1. -
  2. - main components of this MIB module
  3. -
 midcomNotifications   OBJECT IDENTIFIER ::= { midcomMIB 0 }
 midcomObjects         OBJECT IDENTIFIER ::= { midcomMIB 1 }
 midcomConformance     OBJECT IDENTIFIER ::= { midcomMIB 2 }
  1. - Transaction objects required according to the MIDCOM
  2. - protocol requirements defined in RFC 3304 and according to
  3. - the MIDCOM protocol semantics defined in RFC 3989

midcomTransaction OBJECT IDENTIFIER ::= { midcomObjects 1 }

  1. - Configuration objects that can be used for retrieving
  2. - middlebox capability information (mandatory) and for

Quittek, et al. Standards Track [Page 40] RFC 5190 MIDCOM MIB March 2008

  1. - setting parameters of the implementation of transaction
  2. - objects (optional)

midcomConfig OBJECT IDENTIFIER ::= { midcomObjects 2 }

  1. - Optional monitoring objects that provide information about
  2. - used resource and statistics

midcomMonitoring OBJECT IDENTIFIER ::= { midcomObjects 3 }

  1. -
  2. - Transaction Objects
  3. -
  4. - Transaction objects are structured according to the MIDCOM
  5. - protocol semantics into two groups:
  6. - - objects modeling MIDCOM policy rules in the midcomRuleTable
  7. - - objects modeling MIDCOM policy rule groups in the
  8. - midcomGroupTable
  1. -
  2. - Policy rule subtree
  3. -
  4. - The midcomRuleTable lists policy rules
  5. - including policy reserve rules and policy enable rules.
  6. -
 midcomRuleTable OBJECT-TYPE
     SYNTAX      SEQUENCE OF MidcomRuleEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "This table lists policy rules.
          It is indexed by the midcomRuleOwner, the
          midcomGroupIndex, and the midcomRuleIndex.
          This implies that a rule is a member of exactly
          one group and that group membership cannot
          be changed.
          Entries can be deleted by writing to
          midcomGroupLifetime or midcomRuleLifetime
          and potentially also to midcomRuleStorageTime."
     ::= { midcomTransaction 3 }
 midcomRuleEntry OBJECT-TYPE
     SYNTAX      MidcomRuleEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "An entry describing a particular MIDCOM policy rule."

Quittek, et al. Standards Track [Page 41] RFC 5190 MIDCOM MIB March 2008

     INDEX { midcomRuleOwner, midcomGroupIndex, midcomRuleIndex }
     ::= { midcomRuleTable 1 }
 MidcomRuleEntry ::= SEQUENCE {
     midcomRuleOwner                   SnmpAdminString,
     midcomRuleIndex                   Unsigned32,
     midcomRuleAdminStatus             INTEGER,
     midcomRuleOperStatus              INTEGER,
     midcomRuleStorageType             StorageType,
     midcomRuleStorageTime             Unsigned32,
     midcomRuleError                   SnmpAdminString,
     midcomRuleInterface               InterfaceIndexOrZero,
     midcomRuleFlowDirection           INTEGER,
     midcomRuleMaxIdleTime             Unsigned32,
     midcomRuleTransportProtocol       Unsigned32,
     midcomRulePortRange               INTEGER,
     midcomRuleInternalIpVersion       InetAddressType,
     midcomRuleExternalIpVersion       InetAddressType,
     midcomRuleInternalIpAddr          InetAddress,
     midcomRuleInternalIpPrefixLength  InetAddressPrefixLength,
     midcomRuleInternalPort            InetPortNumber,
     midcomRuleExternalIpAddr          InetAddress,
     midcomRuleExternalIpPrefixLength  InetAddressPrefixLength,
     midcomRuleExternalPort            InetPortNumber,
     midcomRuleInsideIpAddr            InetAddress,
     midcomRuleInsidePort              InetPortNumber,
     midcomRuleOutsideIpAddr           InetAddress,
     midcomRuleOutsidePort             InetPortNumber,
     midcomRuleLifetime                Unsigned32,
     midcomRuleRowStatus               RowStatus
 }
 midcomRuleOwner OBJECT-TYPE
     SYNTAX      SnmpAdminString (SIZE (0..32))
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "The manager who owns this row in the midcomRuleTable.
          This object SHOULD uniquely identify an authenticated
          MIDCOM client.  This object is part of the table index to
          allow for the use of the SNMPv3 View-based Access Control
          Model (VACM, RFC 3415)."
     ::= { midcomRuleEntry 1 }
 midcomRuleIndex OBJECT-TYPE
     SYNTAX      Unsigned32 (1..4294967295)
     MAX-ACCESS  not-accessible

Quittek, et al. Standards Track [Page 42] RFC 5190 MIDCOM MIB March 2008

     STATUS      current
     DESCRIPTION
         "The value of this object must be unique in
          combination with the values of the objects
          midcomRuleOwner and midcomGroupIndex in this row."
     ::= { midcomRuleEntry 3 }
 midcomRuleAdminStatus OBJECT-TYPE
     SYNTAX      INTEGER {
                     reserve(1),
                     enable(2),
                     notSet(3)
                 }
     MAX-ACCESS  read-create
     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 a midcomRuleEntry is created without explicitly setting
          this object, its value will be notSet(3).
          However, a SET request can only set this object to either
          reserve(1) or enable(2).  Attempts to set this object to
          notSet(3) will always fail with an 'inconsistentValue'
          error.  Note that this error code is SNMP specific.  If the
          MIB module is used with other protocols than SNMP, errors
          with similar semantics specific to those protocols should
          be returned.
          When the midcomRuleAdminStatus object is set, then the
          MIDCOM-MIB implementation will try to read the respective
          relevant objects of the entry and try to achieve the
          corresponding midcomRuleOperStatus.
          Setting midcomRuleAdminStatus to value reserve(1) when
          object midcomRuleOperStatus has a value of reserved(7)
          does not have any effect on the policy rule.
          Setting midcomRuleAdminStatus to value enable(2) when
          object midcomRuleOperStatus has a value of enabled(8)
          does not have any effect on the policy rule.
          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.

Quittek, et al. Standards Track [Page 43] RFC 5190 MIDCOM MIB March 2008

          When object midcomRuleAdminStatus is set to reserve(1),
          then the following objects in the same entry are of
          relevance:
              - midcomRuleInterface
              - midcomRuleTransportProtocol
              - midcomRulePortRange
              - midcomRuleInternalIpVersion
              - midcomRuleExternalIpVersion
              - midcomRuleInternalIpAddr
              - midcomRuleInternalIpPrefixLength
              - midcomRuleInternalPort
              - midcomRuleLifetime
          MIDCOM-MIB implementation may also consider the value
          of object midcomRuleMaxIdleTime when establishing
          a reserve rule.
          When object midcomRuleAdminStatus is set to enable(2),
          then the following objects in the same entry are of
          relevance:
              - midcomRuleInterface
              - midcomRuleFlowDirection
              - midcomRuleMaxIdleTime
              - 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 the default value
          notSet(3)."
     DEFVAL { notSet }
     ::= { midcomRuleEntry 4 }
 midcomRuleOperStatus OBJECT-TYPE
     SYNTAX      INTEGER {
                     newEntry(1),
                     setting(2),
                     checkingRequest(3),
                     incorrectRequest(4),
                     processingRequest(5),

Quittek, et al. Standards Track [Page 44] RFC 5190 MIDCOM MIB March 2008

                     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:
  1. 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.
  1. setting(2) indicates that the entry has been already

modified after generating it, but no request was made

            yet.
  1. checkingRequest(3) indicates that midcomRuleAdminStatus

has recently been set and that the MIDCOM-MIB

            implementation is currently checking the parameters of
            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.
  1. 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.
  1. 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.
  1. requestRejected(6) indicates that a request to establish

Quittek, et al. Standards Track [Page 45] RFC 5190 MIDCOM MIB March 2008

            a policy rule specified by the entry was rejected.  The
            reason for rejection is indicated by the value of
            midcomRuleError.
  1. reserved(7) indicates that the entry describes an

established policy reserve rule.

            These values of MidcomRuleEntry are meaningful
            for a reserved policy rule:
                - midcomRuleMaxIdleTime
                - midcomRuleInterface
                - midcomRuleTransportProtocol
                - midcomRulePortRange
                - midcomRuleInternalIpVersion
                - midcomRuleExternalIpVersion
                - midcomRuleInternalIpAddr
                - midcomRuleInternalIpPrefixLength
                - midcomRuleInternalPort
                - midcomRuleOutsideIpAddr
                - midcomRuleOutsidePort
                - midcomRuleLifetime
  1. enabled(8) indicates that the entry describes an

established policy enable rule.

            These values of MidcomRuleEntry are meaningful
            for an enabled policy rule:
  1. midcomRuleFlowDirection
  2. midcomRuleInterface
  3. midcomRuleMaxIdleTime
  4. midcomRuleTransportProtocol
  5. midcomRulePortRange
  6. midcomRuleInternalIpVersion
  7. midcomRuleExternalIpVersion
  8. midcomRuleInternalIpAddr
  9. midcomRuleInternalIpPrefixLength
  10. midcomRuleInternalPort
  11. midcomRuleExternalIpAddr
  12. midcomRuleExternalIpPrefixLength
  13. midcomRuleExternalPort
  14. midcomRuleInsideIpAddr
  15. midcomRuleInsidePort
  16. midcomRuleOutsideIpAddr
  17. midcomRuleOutsidePort
  18. midcomRuleLifetime
  1. timedOut(9) indicates that the lifetime of a previously

established policy rule has expired and that the policy

            rule is terminated for this reason.

Quittek, et al. Standards Track [Page 46] RFC 5190 MIDCOM MIB March 2008

  1. 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.
  1. terminated(11) indicates that a previously established

policy rule was terminated by the MIDCOM-MIB

            implementation for a reason other than lifetime
            expiration or an explicit request from a MIDCOM client.
  1. 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(5)
          states are transient states, which will lead to either
          one of the error states or the reserved(7) state or the
          enabled(8) state.  MIDCOM-MIB implementations MAY return
          these values when checking or processing requests."
     DEFVAL { newEntry }
     ::= { midcomRuleEntry 5 }
 midcomRuleStorageType OBJECT-TYPE
     SYNTAX      StorageType
     MAX-ACCESS  read-create
     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.  Note that this
          error code is SNMP specific.  If the MIB module is used
          with other protocols than SNMP, errors with similar
          semantics specific to those protocols should be
          returned.
          If midcomRuleStorageType has the value permanent(4),
          then all objects in this row whose MAX-ACCESS value
          is read-create must be read-only."

Quittek, et al. Standards Track [Page 47] RFC 5190 MIDCOM MIB March 2008

     DEFVAL { volatile }
     ::= { midcomRuleEntry 6 }
 midcomRuleStorageTime OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "seconds"
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The value of this object specifies how long this row
          can exist in the midcomRuleTable after the
          midcomRuleOperStatus 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.
          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 midcomRuleOperStatus 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
          row is not available anymore.
          If object midcomRuleStorageType indicates that the policy
          rule has the storage type permanent(4), then this object has
          a constant value of 4294967295."
     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

Quittek, et al. Standards Track [Page 48] RFC 5190 MIDCOM MIB March 2008

          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'
          The semantics of these error messages and the corresponding
          behavior of the MIDCOM-MIB implementation are specified
          in sections 2.3.9 and 2.3.10 of RFC 3989."
     REFERENCE
         "RFC 3989, sections 2.3.9 and 2.3.10"
     DEFVAL { ''H }
     ::= { midcomRuleEntry 8 }
 midcomRuleInterface OBJECT-TYPE
     SYNTAX      InterfaceIndexOrZero
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "This object indicates the IP interface for which
          enforcement of a policy rule is requested or performed,
          respectively.
          The interface is identified by its index in the ifTable
          (see IF-MIB in RFC 2863).  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.

Quittek, et al. Standards Track [Page 49] RFC 5190 MIDCOM MIB March 2008

          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          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 NAT service is not 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.
          Note that the index of a particular interface in the
          ifTable may change after a re-initialization of the
          middlebox, for example, after adding another interface to
          it.  In such a case, the value of this object may change,
          but the interface referred to by the MIDCOM-MIB MUST still
          be the same.  If, after a re-initialization of the
          middlebox, the interface referred to before
          re-initialization cannot be uniquely mapped anymore to a
          particular entry in the ifTable, then the value of object
          midcomRuleOperStatus of the same entry MUST be changed to
          terminated(11).
          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 9 }
 midcomRuleFlowDirection OBJECT-TYPE
     SYNTAX      INTEGER {
                     inbound(1),
                     outbound(2),
                     biDirectional(3)
                 }
     MAX-ACCESS  read-create
     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

Quittek, et al. Standards Track [Page 50] RFC 5190 MIDCOM MIB March 2008

          the transport protocol (midcomRuleTransportProtocol
          has a 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 middlebox only unidirectional.
          A bidirectional flow is indicated by value
          biDirectional(3).
          If the transport protocol is TCP, the packet flow is
          always bidirectional, but the value of
          midcomRuleFlowDirection indicates that:
  1. inbound(1): bidirectional TCP packet flow.

First packet, with TCP SYN flag set, must arrive

              at an outside interface of the middlebox.
  1. outbound(2): bidirectional TCP packet flow.

First packet, with TCP SYN flag set, must arrive

              at an inside interface of the middlebox.
  1. biDirectional(3): bidirectional 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.
          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.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          If object midcomRuleOperStatus of the same entry has the
          value enabled(8), then this object indicates the enabled

Quittek, et al. Standards Track [Page 51] RFC 5190 MIDCOM MIB March 2008

          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."
     DEFVAL { outbound }
     ::= { midcomRuleEntry 10 }
 midcomRuleMaxIdleTime OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "seconds"
     MAX-ACCESS  read-create
     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 require
          an individual idle time and that instead, a default idle
          time chosen by the middlebox is used.
          A value of 4294967295 ( = 2^32 - 1 ) 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 others
          than newEntry(1), setting(2), or reserved(7) will always
          fail with an 'inconsistentValue' error.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          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

Quittek, et al. Standards Track [Page 52] RFC 5190 MIDCOM MIB March 2008

          may not be able to support maximum idle times and set the
          value of this object to zero when entering state
          enabled(8).
          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 11 }
 midcomRuleTransportProtocol OBJECT-TYPE
     SYNTAX      Unsigned32 (0..255)
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The transport protocol.
          Valid values for midcomRuleTransportProtocol
          other than zero are 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 an IP
          address only 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.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          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."

Quittek, et al. Standards Track [Page 53] RFC 5190 MIDCOM MIB March 2008

     DEFVAL { 0 }
     ::= { midcomRuleEntry 12 }
 midcomRulePortRange OBJECT-TYPE
     SYNTAX      INTEGER {
                     single(1),
                     pair(2)
                 }
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "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.  Requesting a consecutive pair of port numbers may
          be used by RTP [RFC3550] and may even be required to
          support older RTP applications.
          Writing to this object in any state other than
          newEntry(1), setting(2) or reserved(7) will always fail
          with an 'inconsistentValue' error.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          If object midcomRuleOperStatus of the same entry has a
          value of either reserved(7) or enabled(8), then this
          object will have the value that 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 }

Quittek, et al. Standards Track [Page 54] RFC 5190 MIDCOM MIB March 2008

     ::= { midcomRuleEntry 13}
 midcomRuleInternalIpVersion OBJECT-TYPE
     SYNTAX      InetAddressType
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "IP version of the internal address (A0) and the inside
          address (A1).  Allowed values are ipv4(1), ipv6(2),
          ipv4z(3), and ipv6z(4).
          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
          required 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.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          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 14 }
 midcomRuleExternalIpVersion OBJECT-TYPE
     SYNTAX      InetAddressType
     MAX-ACCESS  read-create
     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.

Quittek, et al. Standards Track [Page 55] RFC 5190 MIDCOM MIB March 2008

          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
          required 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.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          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 15 }
 midcomRuleInternalIpAddr OBJECT-TYPE
     SYNTAX      InetAddress
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The internal IP address (A0).
          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.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          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

Quittek, et al. Standards Track [Page 56] RFC 5190 MIDCOM MIB March 2008

          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 16 }
 midcomRuleInternalIpPrefixLength OBJECT-TYPE
     SYNTAX      InetAddressPrefixLength
     MAX-ACCESS  read-create
     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 prefix length
          of the internal IP address for which a reserve policy rule
          or an 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.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          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.

Quittek, et al. Standards Track [Page 57] RFC 5190 MIDCOM MIB March 2008

          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 17 }
 midcomRuleInternalPort OBJECT-TYPE
     SYNTAX      InetPortNumber
     MAX-ACCESS  read-create
     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 internal port
          number for which a reserve policy rule or an 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.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          If object midcomRuleOperStatus of the same entry has the
          value reserved(7) or enabled(8), then this object will
          have the value that 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 18 }
 midcomRuleExternalIpAddr OBJECT-TYPE
     SYNTAX      InetAddress
     MAX-ACCESS  read-create
     STATUS      current

Quittek, et al. Standards Track [Page 58] RFC 5190 MIDCOM MIB March 2008

     DESCRIPTION
         "The external IP address (A3).
          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.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          If object midcomRuleOperStatus of the same entry has the
          value enabled(8), then this object will have the value
          that 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 19 }
 midcomRuleExternalIpPrefixLength OBJECT-TYPE
     SYNTAX      InetAddressPrefixLength
     MAX-ACCESS  read-create
     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

Quittek, et al. Standards Track [Page 59] RFC 5190 MIDCOM MIB March 2008

          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
          prefix length of 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.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          If object midcomRuleOperStatus of the same entry has the
          value enabled(8), then this object will have the value
          that 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 20 }
 midcomRuleExternalPort OBJECT-TYPE
     SYNTAX      InetPortNumber
     MAX-ACCESS  read-create
     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.

Quittek, et al. Standards Track [Page 60] RFC 5190 MIDCOM MIB March 2008

          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          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 21 }
 midcomRuleInsideIpAddr OBJECT-TYPE
     SYNTAX      InetAddress
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The inside IP address at the middlebox (A1).
          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 22 }
 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.
          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 23 }
 midcomRuleOutsideIpAddr OBJECT-TYPE
     SYNTAX      InetAddress
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "The outside IP address at the middlebox (A2).
          The value of this object is relevant only if

Quittek, et al. Standards Track [Page 61] RFC 5190 MIDCOM MIB March 2008

          object midcomRuleOperStatus of the same entry has
          a value of either reserved(7) or enabled(8)."
     ::= { midcomRuleEntry 24 }
 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.
          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 }
 midcomRuleLifetime OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "seconds"
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The remaining lifetime in seconds of this policy rule.
          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), then this
          object 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).

Quittek, et al. Standards Track [Page 62] RFC 5190 MIDCOM MIB March 2008

          Writing to this object is processed by the MIDCOM-MIB
          implementation by choosing a lifetime value that is
          greater than 0 and less than or equal to the minimum of
          the requested value and the value specified by object
          midcomConfigMaxLifetime:
           0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
          where:
             - 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 value of object
               midcomConfigMaxLifetime
          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)
          will always fail with an 'inconsistentValue' error.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          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 26 }
 midcomRuleRowStatus OBJECT-TYPE
     SYNTAX      RowStatus
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "A control that allows entries to be added and removed from
          this table.

Quittek, et al. Standards Track [Page 63] RFC 5190 MIDCOM MIB March 2008

          Entries can also be removed from this table by setting
          objects midcomRuleLifetime and midcomRuleStorageTime of
          an entry to 0.
          Attempts to set a row notInService(2) where the value
          of the midcomRuleStorageType object is permanent(4) or
          readOnly(5) will result in an 'notWritable' error.
          Note that this error code is SNMP specific.  If the MIB
          module is used with other protocols than SNMP, errors with
          similar semantics specific to those protocols should be
          returned.
          The value of this object has no effect on whether other
          objects in this conceptual row can be modified."
     ::= { midcomRuleEntry 27 }
  1. -
  2. - Policy rule group subtree
  3. -
  4. - The midcomGroupTable lists all current policy rule groups.
  5. -
 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 or removed
          implicitly when entries in the midcomRuleTable are
          created or removed, respectively.  A group entry
          in this table only exists as long as there are
          member rules of this group in the midcomRuleTable.
          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 only be
          deleted by deleting all member policies in the
          midcomRuleTable.
          Setting midcomGroupLifetime will result in setting
          the lifetime of all policy members to the same value."
     ::= { midcomTransaction 4 }
 midcomGroupEntry OBJECT-TYPE

Quittek, et al. Standards Track [Page 64] RFC 5190 MIDCOM MIB March 2008

     SYNTAX      MidcomGroupEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "An entry describing properties of a particular
          MIDCOM policy rule group."
     INDEX { midcomRuleOwner, midcomGroupIndex }
     ::= { midcomGroupTable 1 }
 MidcomGroupEntry ::= SEQUENCE {
     midcomGroupIndex      Unsigned32,
     midcomGroupLifetime   Unsigned32
 }
 midcomGroupIndex OBJECT-TYPE
     SYNTAX      Unsigned32 (1..4294967295)
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "The index of this group for the midcomRuleOwner.
          A group is identified by the combination of
          midcomRuleOwner and midcomGroupIndex.
          The value of this index must be unique per
          midcomRuleOwner."
     ::= { midcomGroupEntry 2 }
 midcomGroupLifetime OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "seconds"
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "When retrieved, this object delivers 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 midcomRuleOwner 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

Quittek, et al. Standards Track [Page 65] RFC 5190 MIDCOM MIB March 2008

          midcomRuleTable.
          Writing to this object is processed by the MIDCOM-MIB
          implementation by choosing a lifetime value that is
          greater than 0 and less than or equal to the minimum of
          the requested value and the value specified by object
          midcomConfigMaxLifetime:
           0 <= lt_granted <= MINIMUM(lt_requested, lt_maximum)
          where:
             - 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 value of object
               midcomConfigMaxLifetime
          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 }
  1. -
  2. - Configuration Objects
  3. -
  4. - Configuration objects that can be used for retrieving
  5. - middlebox capability information (mandatory) and for
  6. - setting parameters of the implementation of transaction
  7. - objects (optional).
  8. -
  9. - Note that typically configuration objects are not intended
  10. - to be written by MIDCOM clients. In general, write access
  11. - to these objects needs to be restricted more strictly than
  12. - write access to transaction objects.
  13. -
  1. -
  2. - Capabilities subtree
  3. -
  4. - This subtree contains objects to which MIDCOM clients should
  5. - have read access.
  6. -
 midcomConfigMaxLifetime OBJECT-TYPE
     SYNTAX      Unsigned32
     UNITS       "seconds"

Quittek, et al. Standards Track [Page 66] RFC 5190 MIDCOM MIB March 2008

     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).
          A value of true(1) indicates that there may be
          entries in the midcomRuleTable with object
          midcomRuleStorageType set to value nonVolatile(3)."
     ::= { midcomConfig 2 }
 midcomConfigIfTable OBJECT-TYPE
     SYNTAX      SEQUENCE OF MidcomConfigIfEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "This table indicates capabilities of the MIDCOM-MIB
          implementation per IP interface.
          The table is indexed by the object midcomConfigIfIndex.
          For indexing a single interface, this object contains
          the value of the ifIndex object that is associated
          with the interface.  If an entry with
          midcomConfigIfIndex = 0 occurs, then bits set in
          objects of this entry apply to all interfaces for which
          there is no entry in this table with the interface's
          index."
     ::= { midcomConfig 3 }
 midcomConfigIfEntry OBJECT-TYPE
     SYNTAX      MidcomConfigIfEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "An entry describing the capabilities of a middlebox
          with respect to the indexed IP interface."

Quittek, et al. Standards Track [Page 67] RFC 5190 MIDCOM MIB March 2008

     INDEX { midcomConfigIfIndex }
     ::= { midcomConfigIfTable 1 }
 MidcomConfigIfEntry ::= SEQUENCE {
     midcomConfigIfIndex          InterfaceIndexOrZero,
     midcomConfigIfBits           BITS,
     midcomConfigIfEnabled        TruthValue
 }
 midcomConfigIfIndex OBJECT-TYPE
     SYNTAX      InterfaceIndexOrZero
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "The index of an entry in the midcomConfigIfTable.
          For values different from zero, this object
          identifies an IP interface by containing the same
          value as the ifIndex object associated with the
          interface.
          Note that the index of a particular interface in the
          ifTable may change after a re-initialization of the
          middlebox, for example, after adding another interface to
          it.  In such a case, the value of this object may change,
          but the interface referred to by the MIDCOM-MIB MUST still
          be the same.  If, after a re-initialization of the
          middlebox, the interface referred to before
          re-initialization cannot be uniquely mapped anymore to a
          particular entry in the ifTable, then the value of object
          midcomConfigIfEnabled of the same entry MUST be changed to
          false(2).
          If the object has a value of 0, then values
          specified by further objects of the same entry
          apply to all interfaces for which there is no
          explicit entry in the midcomConfigIfTable."
     ::= { midcomConfigIfEntry 1 }
 midcomConfigIfBits OBJECT-TYPE
     SYNTAX      BITS {
                     ipv4(0),
                     ipv6(1),
                     addressWildcards(2),
                     portWildcards(3),
                     firewall(4),
                     nat(5),
                     portTranslation(6),

Quittek, et al. Standards Track [Page 68] RFC 5190 MIDCOM MIB March 2008

                     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 respect to the referenced IP interface.
          If the index equals 0, then all set bits apply to all
          interfaces.
          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

Quittek, et al. Standards Track [Page 69] RFC 5190 MIDCOM MIB March 2008

          an inside interface with respect to NAT functionality.
          Otherwise, it is an outside interface.  This bit is only
          relevant if nat(5) is set.  An SNMP agent supporting both
          the MIDCOM-MIB module and the NAT-MIB module SHOULD ensure
          that the value of this object is consistent with the values
          of corresponding objects in the NAT-MIB module."
     ::= { 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 midcomConfigIfBits
          at the indexed IP interface.
          By writing to this object, the MIDCOM support for the
          entire IP interface can be switched on or off.  Setting
          this object to false(2) immediately 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
          midcomUnsolicitedRuleEvent to all MIDCOM clients that
          have access to one of the terminated rules."
     DEFVAL { true }
     ::= { midcomConfigIfEntry 3 }
  1. -
  2. - Firewall subtree
  3. -
  4. - This subtree contains the firewall configuration table
  5. -
 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 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

Quittek, et al. Standards Track [Page 70] RFC 5190 MIDCOM MIB March 2008

         priority.  Also, a firewall rule group name can be
         configured.
         The table is indexed by the object midcomConfigFirewallIndex.
         For indexing a single interface, this object contains the
         value of the ifIndex object that is associated with the
         interface.  If an entry with midcomConfigFirewallIndex = 0
         occurs, then bits set in objects of this entry apply to all
         interfaces for which there is no entry in this table for the
         interface's 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 { midcomConfigFirewallIndex }
     ::= { midcomConfigFirewallTable 1 }
 MidcomConfigFirewallEntry ::= SEQUENCE {
     midcomConfigFirewallIndex      InterfaceIndexOrZero,
     midcomConfigFirewallGroupId    SnmpAdminString,
     midcomConfigFirewallPriority   Unsigned32
 }
 midcomConfigFirewallIndex OBJECT-TYPE
     SYNTAX      InterfaceIndexOrZero
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
         "The index of an entry in the midcomConfigFirewallTable.
          For values different from 0, this object identifies an
          IP interface by containing the same value as the ifIndex
          object associated with the interface.
          Note that the index of a particular interface in the
          ifTable may change after a re-initialization of the
          middlebox, for example, after adding another interface to
          it.  In such a case, the value of this object may change,
          but the interface referred to by the MIDCOM-MIB MUST still
          be the same.  If, after a re-initialization of the
          middlebox, the interface referred to before
          re-initialization cannot be uniquely mapped anymore to a
          particular entry in the ifTable, then the entry in the

Quittek, et al. Standards Track [Page 71] RFC 5190 MIDCOM MIB March 2008

          midcomConfigFirewallTable MUST be deleted.
          If the object has a value of 0, then values specified by
          further objects of the same entry apply to all interfaces
          for which there is no explicit entry in the
          midcomConfigFirewallTable."
     ::= { midcomConfigFirewallEntry 1 }
 midcomConfigFirewallGroupId OBJECT-TYPE
     SYNTAX      SnmpAdminString
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
        "The firewall rule group to which all firewall rules are
         assigned that the MIDCOM server creates for the interface
         indicated by object midcomConfigFirewallIndex.  If the
         value of object midcomConfigFirewallIndex is 0, then all
         firewall rules of the MIDCOM server that are created for
         interfaces with no specific entry in the
         midcomConfigFirewallTable are assigned to the firewall
         rule group indicated by the value of this object."
     ::= { midcomConfigFirewallEntry 2 }
 midcomConfigFirewallPriority OBJECT-TYPE
     SYNTAX      Unsigned32
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
        "The priority assigned to all firewall rules that the
         MIDCOM server creates for the interface indicated by
         object midcomConfigFirewallIndex.  If the value of object
         midcomConfigFirewallIndex is 0, then this priority is
         assigned to all firewall rules of the MIDCOM server that
         are created for interfaces for which there is no specific
         entry in the midcomConfigFirewallTable."
     ::= { midcomConfigFirewallEntry 3 }
  1. -
  2. - Monitoring Objects
  3. -
  4. - Monitoring objects are structured into two groups,
  5. - the midcomResourceGroup providing information about used
  6. - resources and the midcomStatisticsGroup providing information
  7. - about MIDCOM transaction statistics.
  1. -
  2. - Resources subtree
  3. -

Quittek, et al. Standards Track [Page 72] RFC 5190 MIDCOM MIB March 2008

  1. - The MIDCOM resources subtree contains a set of managed
  2. - objects describing the currently used resources of NAT
  3. - and firewall implementations.
  4. -
  1. -
  2. - Textual conventions for objects of the resource subtree
  3. -
 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 (RFC 4008).  Value none(3) can
         be used to indicate that the policy rule does not use
         any NAT binding.
         "
     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 (RFC 4008).
         Value 0 can be used to indicate that the policy rule does
         not use any NAT binding."
     SYNTAX      Unsigned32
  1. -
  2. - The MIDCOM resource table
  3. -
 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 augments the

Quittek, et al. Standards Track [Page 73] RFC 5190 MIDCOM MIB March 2008

         midcomRuleTable."
     ::= { midcomMonitoring 1 }
 midcomResourceEntry OBJECT-TYPE
     SYNTAX      MidcomResourceEntry
     MAX-ACCESS  not-accessible
     STATUS      current
     DESCRIPTION
        "An entry describing a particular set of middlebox
         resources."
     AUGMENTS { midcomRuleEntry }
     ::= { midcomResourceTable 1 }
 MidcomResourceEntry ::= SEQUENCE {
     midcomRscNatInternalAddrBindMode   MidcomNatBindMode,
     midcomRscNatInternalAddrBindId     NatBindIdOrZero,
     midcomRscNatInsideAddrBindMode     MidcomNatBindMode,
     midcomRscNatInsideAddrBindId       NatBindIdOrZero,
     midcomRscNatSessionId1             MidcomNatSessionIdOrZero,
     midcomRscNatSessionId2             MidcomNatSessionIdOrZero,
     midcomRscFirewallRuleId            Unsigned32
 }
 midcomRscNatInternalAddrBindMode OBJECT-TYPE
     SYNTAX      MidcomNatBindMode
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "An indication of whether this policy rule uses an address
         NAT bind or an address-port NAT bind for binding the
         internal address.
         If the MIDCOM-MIB module is operated together with
         the NAT-MIB module (RFC 4008) then object
         midcomRscNatInternalAddrBindMode contains the same
         value as the corresponding object
         natSessionPrivateSrcEPBindMode of the NAT-MIB module."
     ::= { 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

Quittek, et al. Standards Track [Page 74] RFC 5190 MIDCOM MIB March 2008

         read this object to learn the corresponding NAT bind
         resource for this particular policy rule.
         If the MIDCOM-MIB module is operated together with
         the NAT-MIB module (RFC 4008) then object
         midcomRscNatInternalAddrBindId contains the same
         value as the corresponding object
         natSessionPrivateSrcEPBindId of the NAT-MIB module."
     ::= { midcomResourceEntry 5 }
 midcomRscNatInsideAddrBindMode OBJECT-TYPE
     SYNTAX      MidcomNatBindMode
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "An indication of whether this policy rule uses an address
         NAT bind or an address-port NAT bind for binding the
         external address.
         If the MIDCOM-MIB module is operated together with
         the NAT-MIB module (RFC 4008), then object
         midcomRscNatInsideAddrBindMode contains the same
         value as the corresponding object
         natSessionPrivateDstEPBindMode of the NAT-MIB module."
     ::= { midcomResourceEntry 6 }
 midcomRscNatInsideAddrBindId OBJECT-TYPE
     SYNTAX      NatBindIdOrZero
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "This object refers 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.
         If the MIDCOM-MIB module is operated together with the
         NAT-MIB module (RFC 4008), then object
         midcomRscNatInsideAddrBindId contains the same
         value as the corresponding object
         natSessionPrivateDstEPBindId of the NAT-MIB module."
     ::= { midcomResourceEntry 7 }
 midcomRscNatSessionId1 OBJECT-TYPE
     SYNTAX      MidcomNatSessionIdOrZero
     MAX-ACCESS  read-only

Quittek, et al. Standards Track [Page 75] RFC 5190 MIDCOM MIB March 2008

     STATUS      current
     DESCRIPTION
        "This object refers to the first allocated NAT session for
         this policy rule.  MIDCOM-MIB implementations can read this
         object to learn whether or not a NAT session for a
         particular policy rule is used.  A value of 0 means that no
         NAT session is allocated for this policy rule.  A value
         other than 0 refers to the NAT session."
    ::= { midcomResourceEntry 8 }
 midcomRscNatSessionId2 OBJECT-TYPE
     SYNTAX      MidcomNatSessionIdOrZero
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "This object refers to the second allocated NAT session for
         this policy rule.  MIDCOM-MIB implementations can read this
         object to learn whether or not a NAT session for a
         particular policy rule is used.  A value of 0 means that no
         NAT session is allocated for this policy rule.  A value
         other than 0 refers to the NAT session."
     ::= { midcomResourceEntry 9 }
 midcomRscFirewallRuleId OBJECT-TYPE
     SYNTAX      Unsigned32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "This object refers 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 refers to the firewall rule
         number within the firewall engine."
     ::= { midcomResourceEntry 10 }
  1. -
  2. - Statistics subtree
  3. -
  4. - The MIDCOM statistics subtree contains a set of managed
  5. - objects providing statistics about the usage of transaction
  6. - objects.
  7. -
 midcomStatistics      OBJECT IDENTIFIER ::= { midcomMonitoring 2 }

Quittek, et al. Standards Track [Page 76] RFC 5190 MIDCOM MIB March 2008

 midcomCurrentOwners OBJECT-TYPE
     SYNTAX      Gauge32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The number of different values for midcomRuleOwner
         for all current entries in the midcomRuleTable."
     ::= { midcomStatistics 1 }
 midcomTotalRejectedRuleEntries OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The total number of failed attempts to create an entry
         in the midcomRuleTable."
     ::= { midcomStatistics 2 }
 midcomCurrentRulesIncomplete OBJECT-TYPE
     SYNTAX      Gauge32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The current number of policy rules that are incomplete.
         Policy rules are loaded via row entries in the
         midcomRuleTable.  This object counts policy rules that are
         loaded but not fully specified, i.e., they are in state
         newEntry(1) or setting(2)."
     ::= { midcomStatistics 3 }
 midcomTotalIncorrectReserveRules OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The total number of policy reserve rules that failed
         parameter check and entered state incorrectRequest(4)."
     ::= { midcomStatistics 4 }
 midcomTotalRejectedReserveRules OBJECT-TYPE
     SYNTAX      Counter32
     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 5 }

Quittek, et al. Standards Track [Page 77] RFC 5190 MIDCOM MIB March 2008

 midcomCurrentActiveReserveRules OBJECT-TYPE
     SYNTAX      Gauge32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The number of currently active policy reserve rules."
     ::= { midcomStatistics 6 }
 midcomTotalExpiredReserveRules OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The total number of expired policy reserve rules
         (entered termination state timedOut(9))."
     ::= { midcomStatistics 7 }
 midcomTotalTerminatedOnRqReserveRules OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The total number of policy reserve rules that were
         terminated on request (entered termination state
         terminatedOnRequest(10))."
     ::= { midcomStatistics 8 }
 midcomTotalTerminatedReserveRules OBJECT-TYPE
     SYNTAX      Counter32
     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 9 }
 midcomTotalIncorrectEnableRules OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The total number of policy enable rules that failed
         parameter check and entered state incorrectRequest(4)."
     ::= { midcomStatistics 10 }
 midcomTotalRejectedEnableRules OBJECT-TYPE
     SYNTAX      Counter32

Quittek, et al. Standards Track [Page 78] RFC 5190 MIDCOM MIB March 2008

     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 11 }
 midcomCurrentActiveEnableRules OBJECT-TYPE
     SYNTAX      Gauge32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The number of currently active policy enable rules."
     ::= { midcomStatistics 12 }
 midcomTotalExpiredEnableRules OBJECT-TYPE
     SYNTAX      Counter32
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
        "The total number of expired policy enable rules
         (entered termination state timedOut(9))."
     ::= { midcomStatistics 13 }
 midcomTotalTerminatedOnRqEnableRules OBJECT-TYPE
     SYNTAX      Counter32
     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 14 }
 midcomTotalTerminatedEnableRules OBJECT-TYPE
     SYNTAX      Counter32
     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 15 }
  1. -
  2. - Notifications.
  3. -
 midcomUnsolicitedRuleEvent NOTIFICATION-TYPE

Quittek, et al. Standards Track [Page 79] RFC 5190 MIDCOM MIB March 2008

     OBJECTS     { midcomRuleOperStatus, midcomRuleLifetime }
     STATUS      current
     DESCRIPTION
         "This notification is generated whenever the value of
          midcomRuleOperStatus enters any error state or any
          termination state without an explicit trigger by a
          MIDCOM client."
     ::= { midcomNotifications 1 }
 midcomSolicitedRuleEvent NOTIFICATION-TYPE
     OBJECTS     { midcomRuleOperStatus, midcomRuleLifetime }
     STATUS      current
     DESCRIPTION
         "This notification is generated whenever the value
          of midcomRuleOperStatus enters one of the states
          {reserved, enabled, any error state, any termination state}
          as a result of a MIDCOM agent writing successfully to
          object midcomRuleAdminStatus.
          In addition, it is generated when the lifetime of
          a rule was changed by successfully writing to object
          midcomRuleLifetime."
     ::= { midcomNotifications 2 }
 midcomSolicitedGroupEvent NOTIFICATION-TYPE
     OBJECTS     { midcomGroupLifetime }
     STATUS      current
     DESCRIPTION
         "This notification is 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), or
            - if the group is terminated by terminating the last
              of its member policies without writing to object
              midcomGroupLifetime."
     ::= { midcomNotifications 3 }
  1. -
  2. - Conformance information
  3. -

Quittek, et al. Standards Track [Page 80] RFC 5190 MIDCOM MIB March 2008

 midcomCompliances OBJECT IDENTIFIER ::= { midcomConformance 1 }
 midcomGroups      OBJECT IDENTIFIER ::= { midcomConformance 2 }
  1. -
  2. - compliance statements
  3. -
  1. - This is the MIDCOM compliance definition …
  1. -
 midcomCompliance MODULE-COMPLIANCE
     STATUS      current
     DESCRIPTION
         "The compliance statement for implementations of the
          MIDCOM-MIB module.
          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 {
             midcomRuleGroup,
             midcomNotificationsGroup,
             midcomCapabilitiesGroup,
             midcomStatisticsGroup
     }
     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."
     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
        "Write access is not required.  When write access is
         not supported, return 128 as the value of this object.

Quittek, et al. Standards Track [Page 81] RFC 5190 MIDCOM MIB March 2008

         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 midcomRuleInterface
     MIN-ACCESS  read-only
     DESCRIPTION
        "Write access is not required."
     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 }
 midcomRuleGroup OBJECT-GROUP
     OBJECTS {
         midcomRuleAdminStatus,
         midcomRuleOperStatus,
         midcomRuleStorageType,
         midcomRuleStorageTime,
         midcomRuleError,
         midcomRuleInterface,
         midcomRuleFlowDirection,
         midcomRuleMaxIdleTime,
         midcomRuleTransportProtocol,
         midcomRulePortRange,
         midcomRuleInternalIpVersion,

Quittek, et al. Standards Track [Page 82] RFC 5190 MIDCOM MIB March 2008

         midcomRuleExternalIpVersion,
         midcomRuleInternalIpAddr,
         midcomRuleInternalIpPrefixLength,
         midcomRuleInternalPort,
         midcomRuleExternalIpAddr,
         midcomRuleExternalIpPrefixLength,
         midcomRuleExternalPort,
         midcomRuleInsideIpAddr,
         midcomRuleInsidePort,
         midcomRuleOutsideIpAddr,
         midcomRuleOutsidePort,
         midcomRuleLifetime,
         midcomRuleRowStatus,
         midcomGroupLifetime
     }
     STATUS      current
     DESCRIPTION
         "A collection of objects providing information about
          policy rules and policy rule groups."
     ::= { midcomGroups 1 }
 midcomCapabilitiesGroup OBJECT-GROUP
     OBJECTS {
         midcomConfigMaxLifetime,
         midcomConfigPersistentRules,
         midcomConfigIfBits,
         midcomConfigIfEnabled
     }
     STATUS      current
     DESCRIPTION
         "A collection of objects providing information about
          the capabilities of a middlebox."
     ::= { midcomGroups 2 }
 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 3 }
 midcomResourceGroup OBJECT-GROUP
     OBJECTS {

Quittek, et al. Standards Track [Page 83] RFC 5190 MIDCOM MIB March 2008

         midcomRscNatInternalAddrBindMode,
         midcomRscNatInternalAddrBindId,
         midcomRscNatInsideAddrBindMode,
         midcomRscNatInsideAddrBindId,
         midcomRscNatSessionId1,
         midcomRscNatSessionId2,
         midcomRscFirewallRuleId
     }
     STATUS      current
     DESCRIPTION
         "A collection of objects providing information about
          the used NAT and firewall resources."
     ::= { midcomGroups 4 }
 midcomStatisticsGroup OBJECT-GROUP
     OBJECTS {
         midcomCurrentOwners,
         midcomTotalRejectedRuleEntries,
         midcomCurrentRulesIncomplete,
         midcomTotalIncorrectReserveRules,
         midcomTotalRejectedReserveRules,
         midcomCurrentActiveReserveRules,
         midcomTotalExpiredReserveRules,
         midcomTotalTerminatedOnRqReserveRules,
         midcomTotalTerminatedReserveRules,
         midcomTotalIncorrectEnableRules,
         midcomTotalRejectedEnableRules,
         midcomCurrentActiveEnableRules,
         midcomTotalExpiredEnableRules,
         midcomTotalTerminatedOnRqEnableRules,
         midcomTotalTerminatedEnableRules
     }
     STATUS      current
     DESCRIPTION
         "A collection of objects providing statistical
          information about the MIDCOM server."
     ::= { midcomGroups 5 }

Quittek, et al. Standards Track [Page 84] RFC 5190 MIDCOM MIB March 2008

 midcomNotificationsGroup NOTIFICATION-GROUP
      NOTIFICATIONS {
          midcomUnsolicitedRuleEvent,
          midcomSolicitedRuleEvent,
          midcomSolicitedGroupEvent
      }
      STATUS    current
      DESCRIPTION
          "The notifications emitted by the midcomMIB."
      ::= { midcomGroups 6 }
 END

10. 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 module and
 then discusses three concrete security threats: unauthorized
 middlebox configuration, unauthorized access to middlebox
 configuration information, and unauthorized access to the MIDCOM
 service configuration.

10.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.
 Deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.
 Compliant MIDCOM-MIB implementations MUST support SNMPv3 security
 services including data integrity, identity authentication, data
 confidentiality, and replay protection.

Quittek, et al. Standards Track [Page 85] RFC 5190 MIDCOM MIB March 2008

 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 midcomRuleTable
 and the midcomGroupTable.  Each of them uses midcomRuleOwner as the
 initial index.  midcomRuleOwner has the syntax of SnmpAdminString,
 and can thus be trivially mapped to an SNMP securityName or a
 groupName as defined in VACM, in accordance with a security policy.
 All entries in the two 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.

10.2. Unauthorized Middlebox Configuration

 The most dangerous threat to network security related to the MIDCOM-
 MIB module 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
 become accessible to unauthorized principals, attacks exploiting

Quittek, et al. Standards Track [Page 86] RFC 5190 MIDCOM MIB March 2008

 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 midcomRuleTable and midcomGroupTable with a
 MAX-ACCESS clause of read-write and/or read-create.
 Particularly sensitive is write access to the managed object
 midcomRuleAdminStatus, because writing it causes policy rules to be
 established.
 Also, writing to other managed objects in the two tables can make
 security vulnerable 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.

10.3. Unauthorized Access to Middlebox Configuration

 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, for
 example, an authenticated user can only read entries in the
 midcomRuleTable for which the initial index midcomRuleOwner matches
 the client's SNMP securityName or VACM groupName.

Quittek, et al. Standards Track [Page 87] RFC 5190 MIDCOM MIB March 2008

10.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 module to overrule basic security rules at the firewall
 that should have higher priority than the ones generated via the
 MIDCOM-MIB module.
 Therefore, also for these objects, means for strict control of write
 access MUST be provided by a MIDCOM-MIB implementation.

11. Acknowledgements

 This memo is based on a long history of discussion within the MIDCOM
 MIB design team.  Many thanks to Mary Barnes, Jeff Case, Wes
 Hardaker, David Harrington, and Tom Taylor for fruitful comments and
 recommendations and to Juergen Schoenwaelder acting as a very
 constructive MIB doctor.

12. IANA Considerations

 IANA has assigned an OID for the MIB module in this document:
             Descriptor        OBJECT IDENTIFIER value
             ----------        -----------------------
             midcomMIB         { mib-2 171 }

13. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5189]  Stiemerling, M., Quittek, J., and T. Taylor, "Middlebox
            Communication (MIDCOM) Protocol Semantics", RFC 5189,
            March 2008.

Quittek, et al. Standards Track [Page 88] RFC 5190 MIDCOM MIB March 2008

 [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.
 [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
            MIB", RFC 2863, June 2000.
 [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.
 [RFC3413]  Levi, D., Meyer, P., and B. Stewart, "Simple Network
            Management Protocol Applications", STD 62, RFC 3413,
            December 2002.
 [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
            (USM) for version 3 of the Simple Network Management
            Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
 [RFC3418]  Presuhn, R., Ed., "Management Information Base (MIB) for
            the Simple Network Management Protocol (SNMP)", STD 62,
            RFC 3418, December 2002.
 [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
            Jacobson, "RTP: A Transport Protocol for Real-Time
            Applications", STD 64, RFC 3550, July 2003.
 [RFC4001]  Daniele, M., Haberman, B., Routhier, S., and J.
            Schoenwaelder, "Textual Conventions for Internet Network
            Addresses", RFC 4001, February 2005.
 [RFC4008]  Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and
            C. Wang, "Definitions of Managed Objects for Network
            Address Translators (NAT)", RFC 4008, March 2005.

Quittek, et al. Standards Track [Page 89] RFC 5190 MIDCOM MIB March 2008

14. 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.
 [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
            Issues", RFC 3234, February 2002.
 [RFC3303]  Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
            A. Rayhan, "Middlebox communication architecture and
            framework", RFC 3303, August 2002.
 [RFC3304]  Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
            "Middlebox Communications (midcom) Protocol Requirements",
            RFC 3304, August 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.

Quittek, et al. Standards Track [Page 90] RFC 5190 MIDCOM MIB March 2008

Authors' Addresses

 Juergen Quittek
 NEC Europe Ltd.
 Kurfuersten-Anlage 36
 69115 Heidelberg
 Germany
 Phone: +49 6221 4342-115
 EMail: quittek@nw.neclab.eu
 Martin Stiemerling
 NEC Europe Ltd.
 Kurfuersten-Anlage 36
 69115 Heidelberg
 Germany
 Phone: +49 6221 4342-113
 EMail: stiemerling@nw.neclab.eu
 Pyda Srisuresh
 Kazeon Systems, Inc.
 1161 San Antonio Rd.
 Mountain View, CA 94043
 U.S.A.
 Phone: +1 408 836 4773
 EMail: srisuresh@yahoo.com

Quittek, et al. Standards Track [Page 91] RFC 5190 MIDCOM MIB March 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights 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; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Quittek, et al. Standards Track [Page 92]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5190.txt · Last modified: 2008/03/24 18:36 (external edit)